CICLO DE VIDA DE DESARROLLO DE SISTEMAS
Anuncio
1 CICLO DE VIDA DE DESARROLLO DE SISTEMA (CVDS) Asumir el reto de desarrollar e implantar un sistema de información 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 información exitosos fue desarrollado el ciclo de vida del desarrollo de sistemas (CVDS) que “es el conjunto de fases o actividades que realizan los analistas, diseñadores, programadores y usuarios finales para desarrollar e implantar un sistema de información.” 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 situación actual con el objetivo de elaborar un sistema de información o alguna aplicación informática; en todo caso se trata de una herramienta de gestión de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistema. En términos generales el grupo de analistas, diseñadores y programadores enfrentan el escenario de resolver un problema para un grupo de usuarios finales, donde los miembros del departamento de sistemas lo denominan genéricamente con el nombre Proyecto. Fase 1----Investigación Preliminar: comienza con la solicitud por parte de la gerencia, la administración, un grupo de usuarios o los especialistas de sistemas en mejorar un proceso, aplicar una norma o aprovechar una oportunidad para mejorar la organización, 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) Aclaración de la solicitud b) Estudio de factibilidad c) Aprobación de la solicitud. a) Aclaración 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 están formuladas de manera clara, pero representan la voz de la organización 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. 2 b) Estudio de factibilidad: El desarrollo de un sistema de Información suele ser caro, así antes de iniciar cualquier proyecto se debe hacer un estudio de viabilidad; “que es una investigación rápida 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 pequeño equipo de personas que pertenecen a la organización o asesores externos y que se verán afectados por el proyecto y que no debe durar más de 8 días hábiles. En la investigación preliminar se estudian los siguientes aspectos: b.1) Factibilidad Técnica: Consiste en determinar si dentro o fuera de la organización existe la tecnología y el recurso humano capacitado para poder desarrollar el proyecto. b.2) Factibilidad Económica. Consiste en determinar si los costos de desarrollo e implantación del sistema se justifican en función 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 están en capacidad de usar apropiadamente el sistema, o cuanto tiempo se requerirá para formar el personal en el uso apropiado del nuevo sistema de información. 3 b.4) Factibilidad de Calendario: Consiste en dar respuesta a la siguientes pregunta:¿Puede la solución desarrollarse e implantarse en un plazo aceptable?, es decir, la construcción del sistema puede desarrollarse en un tiempo razonable para recuperar la inversión y satisfacer a los usuarios finales. Al finalizar esta etapa el grupo de trabajo debe entregar un informe con todas las posibles alternativas de solución acompañadas con su estudio de factibilidad y el plan de desarrollo correspondiente. c) Aprobación de la solicitud Consiste en que la alta gerencia administrativa después de escuchar el informe de factibilidad tome la decisión para continuar o no con el proyecto. Aceptar la recomendación Enmendar la recomendación Devolver las recomendaciones Rechazar todos los proyectos En resumen en esta primera etapa el analista se involucra en al identificación de los problemas y las oportunidades que ofrece la empresa a nivel de desarrollo de sistemas de información. En muchas ocasiones la empresa ya tiene detectadas sus áreas débiles y se llama al analista ya con ciertos objetivos previstos. Esta etapa es crítica, ya que nadie desea perder el tiempo resolviendo el problema equivocado. 4 1. Determinación de Requerimientos: Después de realizar la investigación preliminar, el analista tiene que plantear los requerimientos del usuario para el nuevo sistema; es decir, las necesidades y características que deberá cubrir el nuevo sistema. Para identificar los requerimientos de información se utilizan varias técnicas o herramientas como los son documentos, la entrevista, los cuestionarios, etcétera. 2. Diseño del sistema: El Diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos de información. 3. Desarrollo de Software: Consiste en escribir los programas necesarios para el sistema. Los programadores son responsables de la documentación de los programas, que también se realiza durante esta etapa, así como explicar el funcionamiento de los mismos y por qué ciertos procedimientos se codifican de determinada forma. La documentación 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. Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios. Dependiendo del tamaño de la organización y del riesgo asociado al uso del nuevo sistema se puede comenzar la operación del sistema sólo en un área de la empresa. Es recomendable que trabajen paralelamente el anterior sistema y el nuevo para comparar los resultados obtenidos. La evaluación del sistema se lleva a cabo para identificar sus puntos débiles y fuertes. Aunque en algunas ocasiones este proceso de evaluación no recibe la importancia que merece, si se realiza de forma adecuada proporciona mucha información 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 tecnología de la información que viene a resolver uno o varios problemas puntuales de procesamiento de información; comprometer al usuario permite evitar errores en la construcción del sistema, además 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 Organización: Toda organización debe tener una Visión y Misión específica, las cuales son su constante motivación; así la Administración es encargada de definir las Políticas, Normas, Metas y Estrategias para cumplir con esos principios, de tal manera que cuando se desarrollan los sistemas de información 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 Organización. 1.3.- Aplicar un método de resolución de problemas: En el momento que el analista estudia la situación 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 solución de sistemas en forma eficiente se debe usar un método, con el cual se busca evitar que se pierdan detalles en la construcción de un nuevo sistema; así El Ciclo de Vida de Desarrollo de Sistemas es ante todo un método para resolver problemas, que le permite al analista estudiar en detalle la situación actual y construir en detalle una solución, el cual consta de las siguientes actividades: 1. Investigación preliminar 2. Determinación de los requerimientos del sistema 3. Diseño del sistema 4. Desarrollo de software 5. Prueba de los sistemas 6. Implantación y evaluación 6 En términos generales dichas fases o actividades se pueden resumir en: 1. Análisis 2. Diseño 3. Desarrollo de Software 4. Implantación Análisis Diseño Desarrollo de Software Implantación SISTEMA DE INFORMACÓN o PROBLEMA 1.4.- Justificar los sistemas como una inversión de capital: Los sistemas de información son ante todo una inversión de capital, pues los propietarios o la organización deben pagar: luz, agua, teléfono, personal, discos, hojas, etc...para su realización; 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 organización invierte para no recoger esa inversión a un corto o mediano plazo. 7 1.5.- Diseñar el sistema para el crecimiento: La vida útil de un nuevo sistema debe ser visto como una solución a largo plazo, por lo tanto debe ser diseñado 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 entropía del sistema. 2.- Análisis: 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 información 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. Investigación Preliminar 2.2. Determinación de requerimientos 8 2.1.- La Investigación preliminar 2.2) Determinación de los Requerimientos: La siguiente fase del análisis consiste en conocer y estudiar en detalle la situación actual, para llegar a una compresión más 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 básicos de la situación actual Obtener el diccionario de datos de la situación actual Definir las fortalezas, oportunidades, amenazas y debilidades del sistema actual (ANÁLISIS DE LA SITUACIÓN ACTUAL) Determinar los Requerimientos ser incorporados en el sistema propuesto. Aprender cómo funciona el sistema actual se requiere de la participación activa de los propietarios, los usuarios(Directos e Indirectos), pues incrementa su sentido de responsabilidad y propiedad del sistema de información 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 información al usuario para la toma de decisiones; paralelamente se estructura el diccionario de datos de la situación actual. Para realizar los D.F.Ds. el analista conversa con varias personas para reunir detalles relacionados con los procesos de la organización, 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 más de las siguientes técnicas de investigación de hechos: Elaboración de Entrevistas Reunión y discusión en grupos Observación 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 características o Entradas/Salidas que deben ser incluidas en el nuevo sistema, entre las cuales se puede señalar: 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 Análisis del Sistema Actual, es decir, un listado de las Fortalezas y Debilidades del Sistema actual a) Actividades de la Determinación 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 planificación de proyectos 9 Anticipar problemas Prever un característica del nuevo sistema Definir procesos, datos y controles mas rápido Optimizar el tiempo a.2) Determinar el objetivo del sistema: Consiste en definir específicamente 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 depósitos y las personas del sistema actual, a través de algún modelo que represente el sistema para definir cuales serán las características esenciales que deben ser incluidas en el nuevo sistema. 10 b) Los Requerimientos son: b.1) Básicos: Son aquellas actividades o procesos indispensables que permiten cumplir con los objetivos del sistema. Datos Proc 1. Proc 2. Proc 3. Información Así POR CADA PROCESO BÁSICO 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, cómo lo hace paso a paso y donde guarda los datos y/o la información; 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: ¿Cuál es el nombre del proceso? ¿Cuáles son los pasos o actividades del proceso? ¿Dónde se realizan los pasos? ¿Quiénes realizan .los pasos? ¿Quiénes emplean la información resultante? ¿Con cuánta frecuencia se realizan? Identificar que datos ingresan al proceso: Consiste en determinar que datos y/o información utiliza el proceso para llevar a cabo sus actividades. Determinar que Información es generada: Consiste en determinar que datos y/o Información da como resultado el proceso. Datos Proceso Información Frecuencia: Se debe determinar el número de veces que se presenta el proceso en el tiempo. Ejemplos: mensualmente, cada 15 días, cada tres meses, etc... 11 Volumen: Consiste en determinar qué cantidad de unidades son procesadas. Ejemplos: 15 solicitudes, 50 ventas, 70’000 abonos, etc.... Identificar los Controles empleados: Consiste en identificar los puntos donde se establece un supervisión con los datos; en otras palabras, para establecer una comparación 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 estándares preestablecidos? ¿Quién se encarga de supervisar? ¿Cómo se detectan los errores? ¿Cada cuanto se presentan los errores? ¿Cómo se corrigen los errores? ¿Qué datos se originan de fuentes externas y por qué? ¿Cómo 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 Decisión: A diferencia de las actividades de transacción, las relacionadas con las decisiones no siguen ningún procedimiento específico; es mas, las decisiones siempre se toman en base al resultado de los sistemas de transacción, 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 estadísticas de los aprobados y reprobados por sección 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 creación de una nueva sección, el jefe de departamento debe tener en sus manos buena cantidad de información para poder tomar la decisión mas acertada, es decir crear la sección con X cantidad de alumnos.. Se recomienda plantearse las siguientes preguntas: ¿Qué Información se usa para tomar decisiones? ¿Cuál es la fuente de la información? ¿Qué sistema de transacción produce la información que es usada en la toma de decisiones y por qué? ¿Qué otros datos son necesarios y por qué? ¿Quién toma las decisiones y por qué? b.3) De Organización: En las Organizaciones cada departamento, sección, área depende uno de otro para brindar servicios o bienes a sus clientes, por consiguiente el trabajo de un departamento afecta al de los demás. El analista de sistemas debe determinar cuáles 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 organización. Fase 1: Análisis de Necesidades Durante el análisis 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 solución y definir su funcionalidad. La fase 1 comienza cuando se identifica una necesidad para un sistema nuevo o modificado. Por ejemplo, los usuarios podrían quejarse de que el sistema actual es difícil de usar. Los procedimientos simples requieren demasiados pasos, y el sistema se cae repetitivamente, con la consecuencia de una perdida de 13 información. Opcionalmente, un administrador se podría acercar de Informática para pedir un reporte que actualmente no es producido por el sistema. Los analistas de sistemas comienzan entonces una investigación preliminar, hablando con los usuarios y los administradores del departamento afectado. El primer reto es definir el problema con precisión. Con el problema exactamente definido, el departamento de Informática puede decidir si va a tomar el proyecto(la decisión de “ir o no ir”. Cuando una decisión para proceder está tomada, los analistas de sistemas llevan acabo una investigación concienzuda del sistema actual y sus limitaciones. Trabajan con la gente directamente involucrada con el problema para documentar cómo puede resolverse. El conocimiento reunido en relación al sistema actual se documenta de varias maneras diferentes. Algunos analistas usan diagramas de flujo de datos, los cuales muestran flujo de información a través del sistema(VER GRAFICO DE EJEMPLO). Podrían usar algoritmos estructurados para describir alternativas y acciones del sistema actual. Otra opción es presentar las acciones que se toman bajo diferentes condiciones en un árbol de decisión(VER EJEMPLO). La representación gráfica es más fácil de comprender que un a lista. Con esta base, los analistas están listos para considerar varias soluciones al problema. Podrían llamar científicos de computación del departamento de Informática 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 solución rápidamente, el equipo del departamento de Informática podría considerar soluciones que fueran menos ideales, sin embargo, tiene la ventaja de un rápido cambio de posición. Al finalizar la fase 1, equipo recomienda una solución para ser adoptada. Los analistas usan la información que ya reunieron con los usuarios del sistema para determinar qué características debe haber en la solución (Qué reportes deberían generarse, en qué forma serán emitidos y qué herramientas especiales se necesitan). Mediante la fase de análisis de necesidades, permanecen enfocados en “qué” debería hacer el sistema, no “cómo” serán implementadas las características. Fase 2: Diseño del sistema Durante la segunda fase, Diseño del sistema, el equipo de proyecto encara el “cómo” de la solución elegida. Por ejemplo, una aplicación de la base de datos debería ser capaz de aceptar información de los usuarios y almacenarla. Éstas son funciones generales, pero ¿Cómo las implementará el equipo? Por ejemplo, ¿Cuántas pantallas de entrada son necesarias y cómo se verán? ¿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 combinación de diseño descendente y ascendente para responder esas preguntas. En el Diseño 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 más y más pequeñas. Cada una de estas actividades será programada en la siguiente fase CVDS. En el Diseño Ascendente, el quipo comienza con los detalles ( Por ejemplo, los reportes que serán 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 específicos para la salida –por ejemplo, cheques para pago de nómina, los cuales deben contener ciertas piezas de información-. A través de la fase 2, el administrador del equipo del proyecto revisa el progreso en el diseño de diferentes componentes del sistema. Al final de la fase se lleva a cabo una revisión más amplia, involucrado 14 normalmente al departamento que será afectado y a la administración superior. Si el diseño pasa la inspección, el desarrollo comienza. En algunos casos la revisión pone de relieve problemas con la solución general, y el equipo debe regresar a analizar o terminar el proyecto. Muchas herramientas están disponibles para ayudar a los equipos a través de los pasos del diseño de sistemas. La mayoría de estas herramientas también pueden usarse durante de la fase de desarrollo, o, incluso, durante el análisis. Por ejemplo, muchos equipos usan modelos de funcionamiento llamados Prototipos para explorar la vista y percepción de las pantallas en relación con los usuarios. También usan aplicaciones de software especiales para crear esos prototipos rápidamente, así como para crear diagramas, escribir código y administrar el esfuerzo de desarrollo. Estas aplicaciones entran en la categoría de herramientas de ingeniería de software asistidas por computadora(CASE). En otras palabras, el software de cómputo está usándose para desarrollar otro software de cómputo más confiable y rápidamente. 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 específicos del sistema general. Si un componente está creándose, los programadores escriben el código necesario o usan herramientas CASE (Si es posible) para acelerar el proceso de desarrollo. Para los componentes comprados, los programadores deben personalizar el código según sea necesario para hacer que el componente encaje dentro del nuevo sistema. Hay dos rutas alternativas a través de la fase 3:La ruta de la adquisición o la ruta del desarrollo local. Tan temprano como la fase 1, análisis de necesidades, el equipo del proyecto podría darse cuenta de que algunos o todos los componentes necesarios del sistema están 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 más rápido 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 podrían necesitar ser personalizados para encajar dentro del sistema general de información. 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 adquisición como de desarrollo local a través del CVDS al mismo tiempo. Los redactores técnicos trabajan con los programadores para producir la documentación técnica para el sistema. La documentación técnica es sumamente distinta de la documentación para el usuario, en ella se describe a los usuarios finales cómo usar el sistema; en cambio, la documentación técnica incluye información acerca de las características técnicas del software y de la programación, acerca del flujo de información y del procesamiento a través del sistema, y acerca del diseño y disposición 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. Además, la documentación técnica 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 documentación para el usuario, y los arquitectos de asistencia al usuario comienzan a plantear la arquitectura del sistema de ayuda en línea. Estos esfuerzos normalmente no son terminados hasta llegar a las primeras etapas de la fase de puesta en práctica. Poner a prueba es una parte integral de las fases 3 y 4 (Desarrollo y puesta en práctica). El enfoque típico 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 instalación, 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 aceptación, 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 “información viva”- . Esto ayuda a asegurase de que el sistema puede manejar el flujo de información esperado sobre una base diaria después que le sistema se pone en línea. Sin embargo, los programadores también debieran probar el sistema con datos inválidos o condiciones de excepción. Por ejemplo, ¿Qué pasa cuando un usuario teclea mal “1X33345” en vez de “1333345” dentro de un campo que solamente acepta información numérica? 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: Implementación En la fase de Implementación, 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. Después, los usuarios comienzan a usar el sistema para realizar trabajo, no sólo para proporcionar retroalimentación en el desarrollo del sistema. El proceso de cambiar del antiguo sistema al nuevo se llama conversión. Los profesionales de los sistemas de información deben manejar cuidadosamente este proceso para evitar perder o corromper datos y frustrar a los usuarios que tratan de realizar su trabajo. La conversión puede ser: • Conversión Directa: Todos los usuarios dejan de usar el sistema antiguo al mismo tiempo y después comienzan a usar el nuevo. Esta opción es rápida, pero puede ser destructiva. Además, la presión sobre el personal de soporte puede resultar excesiva. • Conversión en paralelo: Los usuarios continúan usando el sistema antiguo mientras que una cantidad creciente de información es procesada mediante el nuevo sistema. Las salidas de los dos sistemas son comparadas, y si están de acuerdo se hace el cambio. Esta opción es útil para más pruebas reales del nuevo sistema, pero es muy desgastante porque ambos sistemas están operando al mismo tiempo. • Conversión en Fases: Los usuarios comienza a usar el nuevo sistema componente por componente. Esta opción sólo funciona para sistemas que pueden ser divididos en compartimientos o módulos. • Conversión piloto: El personal usa el nuevo sistema en un solo sitio piloto y luego la organización completa hace el cambio. A pesar que este nuevo enfoque podría llevar más tiempo que los otros tres, da oportunidad al personal de soporte para probar concienzudamente la respuesta del usuario al sistema, y estarán mejor preparados cuando muchas personas hagan la conversión. Los capacitadotes y el personal de soporte tienen un papel significativo durante la conversión. Los cursos de capacitación generalmente involucran conferencias del tipo de salón de clase, sesiones de manos a la obra con datos de muestra y capacitación basada en computadoras, con la cual los usuarios pueden trabajar en su propio tiempo. Fase 5: Mantenimiento 16 Después que los sistemas de información son implementados, los profesionales del Departamento de Informática proporcionan soporte durante la fase de mantenimiento. Monitorean varios índices de la ejecución del sistema, como el tiempo de respuesta, para asegurarse que el sistema se desempeña según se pretendía. También 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, podría reconocer situaciones donde un pequeño cambio en el sistema podría permitirles ser más efectivos. O el administrador de un departamento usuario podría requerir cambios debido a nuevas disposiciones en el estado o en las regulaciones federales de la industria. Los errores en el sistema también se corrigen durante la fase 5. Con frecuencia los sistemas se instalan en un ambiente de usuario con errores de programación o diseño ya conocidos. Normalmente estoe errores han sido identificados como no críticos, o no suficientemente importantes para retrasar la instalación. Los programadores tiene listas de tales errores para corregirlos durante la fase de mantenimiento. En adición, el uso diario del sistema podría resaltar errores más serios para que los programadores los arreglen. Durante el lapso de vida restante del sistema se realizan regularmente cambios o actualizaciones. Sin embargo, en algún punto las reparaciones al sistema ya no cubren los requerimientos del usuario, los cuales podrían haber cambiado radicalmente desde que el sistema fue instalado. Los profesionales del departamento de Informática o los administradores de un departamento usuario comienzan a pedir una modificación importante o un nuevo sistema. En ese momento, el CVDS ha regresado a su punto inicial y la fase de análisis comienza de nuevo. REFERENCIAS BIBLIOGRÁFICAS 1.- Análisis y Diseño de Sistemas, Centro de Computación Profesional de México(CCPM), McGraw-Hill Interamericana, Editores S.A. de C.V., Agosto 2001, páginas 4-23. 2.- Introducción a la Computación, Peter Norton, McGraw-Hill Interamericana, Tercera Edición,Marzo 2001, páginas 402-431.
