Recurso online, que permitirá Recurso online, que permitirá desarrollar la propuesta.desarrollar la propuesta.

Desarrollo del sistema de información tradicionalDesarrollo del sistema de información tradicional

El ciclo de vida del sistema de información es la manera en que se construye el sistema de información. Debido a que casi siempre es más fácil realizar una secuencia de tareas pequeñas que una tarea grande, el ciclo de vida general se divide en una serie de pasos pequeños llamados fases. El número de fases varía de empresa a empresa, puede haber tan pocas como cuatro o tantas como ocho. Comúnmente hay seis fases, que se enlistan en la figura 1.1. Cada una de estas fases se describe a continuación con detalle.

1.1. Fase de requisitosFase de requisitos

2.2. Fase de análisisFase de análisis

3.3. Fase de diseñoFase de diseño

4.4. Fase de Fase de implementaciónimplementación

5.5. Fase de Fase de mantenimientomantenimiento

6.6. El retiroEl retiro

1) La fase de requisitos1) La fase de requisitos

En La fase de requisitos se extraen los requisitos del cliente. Es decir, el cliente y los futuros usuarios del sistema de información por desarrollar interactúan con el equipo de desarrollo de sistemas de información con el fin de determinar las necesidades del cliente. Los resultados de este estudio se presentan en forma de un documento de requisitos.

En el caso del sistema de información desarrollado por Jethro's Boot Emporium, el documento de requisitos enlista las necesidades de Jethro relacionadas con los pedidos automatizados, así como con sus necesidades respecto de detectar y reaccionar a las nuevas tendencias de la moda en botas. Debido a que el sistema de información de Jethro es relativamente sencillo, el documento de requisitos consta de sólo unas cuantas páginas, con una lista de necesidades específicas.

La segunda fase es la de análisis. El objetivo de ésta es preparar el documento de especificaciones. El documento de especificaciones (o las especificaciones) plantea lo que debe hacer el sistema de información. Si el sistema de información entregado satisface las especificaciones, entonces el cliente paga a los desabolladores lo que cuesta el sistema de información. Si no, los desabolladores Tienen que corregirlo hasta que cumpla con las especificaciones. Estas describen lo que el sistema de información es capaz de hacer.

Una vez que el cliente aprueba el documento de especificaciones, puede redactarse el plan de administración de proyectos. Este plan detallado incluye un presupuesto, las necesidades de personal y una lista de qué se entregará al cliente y cuándo.

2) La fase de análisis2) La fase de análisis

A diferencia del documento de requisitos relativamente informales, un documento de especificaciones en esencia es un contrato entre el cliente y los desarrolladores. Por lo tanto, en el caso del Jethro's Boot Emporium y Weslern Business Computer Solutions, el documento de especificaciones describe con detalle lo que hará el sistema. Especifica la entrada (el código de barras en las bolas) y las distintas salidas, incluyendo los pedidos generados en forma automática; informes que enlistan las ventas al público y las compras a los mayoristas. Además, el documento de especificaciones describe de manera precisa cómo el sistema determinará cuándo hay una nueva tendencia en la moda de las botas y cuántos pares adicionales se van a pedir si se detecta una nueva tendencia. Esta última parte del documento de especificaciones se basa en las fórmulas proporcionadas por Jethro.

2) La fase de análisis2) La fase de análisis

La fase de diseño viene a continuación. Aquí los miembros del equipo de desarrollo describen cómo se va a desarrollar el sistema de información. Por lo general, el sistema se divide en piezas pequeñas llamadas módulos. Cada módulo se diseña posteriormente con detalle; el equipo de desarrollo describe los algoritmos usados por el módulo (es decir, cómo el módulo realiza esta tarea) y las estructuras de datos dentro del módulo (es decir, los datos con los cuales va a operar el módulo). El resultado se presenta en forma de un documento de diseño.

3) La fase de diseño3) La fase de diseño

El sistema de información de Jethro se compone de varios módulos. Algunos de ellos manejan los pedidos automatizados con base en las ventas y algunos de los pedidos adicionales como una consecuencia de la detección de nuevas tendencias en la moda en botas.

Con el fin de apreciar la diferencia entre un documento de especificaciones y un documento de diseño, considere el informe de ventas que Jethro quiere imprimir al final de cada semana. El documento de especificaciones establece que el informe debe incluir las ventas semanales de botas de cada uno de los mayoristas y el total general de ventas. Es decir, el documento de especificaciones enlista lo que se va imprimir. Por otro lado, el documento de diseño establece en qué parte de la página va a aparecer el logo (esquina superior derecha), cuáles serán los encabezados de columna ("Fecha", "Mayorista" y "Ventas"), cuántos caracteres se utilizarán para el nombre del mayorista, cuántos espacios en blanco se deben dejar y luego cuántos dígitos se usarán para el total semanal de ventas de botas de ese mayorista y así por el estilo. En otras palabras, el diseño del informe establece cómo se va imprimir el informe.

3) La fase de diseño3) La fase de diseño

La cuarta fase es la de implementación. Los diseños de los módulos se entregan al equipo de programación para que los traduzcan en un lenguaje de programación apropiado. COBOL es el lenguaje de programación más usado en el mundo, en tanto que los sistemas de información modernos a menudo se implementan en C++ o Java. Los módulos se integran (se combinan) para formar el sistema de información completo.

4) La fase de implementación4) La fase de implementación

El sistema de información para el sistema de Jethro está en COBOL porque se diseñó hace más de 30 años, cuando la abrumadora mayoría de los sistemas se implementaban en COBOL.

Después de que se ha instalado el sistema de información, necesitará modificarse, ya sea para eliminar cualquier falla restante o porque necesita ampliarse de alguna manera. Esta quinta fase se llama fase de mantenimiento.

5) La fase de mantenimiento5) La fase de mantenimiento

En el caso del sistema de información desarrollado para Jethro's Boot Emporium, la primera operación de mantenimiento fue, lo cual no es sorprendente, desactivar la parte del programa que hacía un pedido automático de más botas cuando detectaba una nueva tendencia en la compra de éstas. En vez de ello, ahora el sistema imprimía un informe de modo que Jethro pudiera decidir si en realidad había una nueva tendencia o no, y en caso afirmativo pudiera decidir de cuántos pares de botas adicionales seria el pedido.

Finalmente, después de 10, 15 o más años de mantenimiento, un sistema de información se retira si ya no da un servicio útil. Esta fase sexta y final, el retiro, se muestra en la figura 1.1 junto con las fases anteriores del ciclo de vida de los sistemas de información.

6) El retiro6) El retiro

Parece que se omitieron tres fases importantes. Estas omisiones aparentes se abordan en las tres secciones siguientes.

¿Cómo es posible desarrollar un sistema de información administrativo sin un plan? La respuesta es simple: no se puede. Pero en ese caso, ¿por qué no hay una fase de planeación al principio del proyecto?

1.3 1.3 !Por qué no hay una fase de planeación!!Por qué no hay una fase de planeación!

La principal observación es que hasta saber exactamente qué se va a desarrollar, no hay manera de idear un plan detallado preciso. Por lo tanto, hay tres tipos de actividades de planeación que ocurren cuando se desarrolla un sistema de información:

• Primero, se lleva a cabo la planeación preliminar de modo que se puedan manejar las fases de análisis y requisitos.

1.3 1.3 !Por qué no hay una fase de planeación!!Por qué no hay una fase de planeación!

• Segundo, una vez que se sabe con precisión lo que se va a desarrollar, se idea el plan de administración de proyectos. Éste incluye el presupuesto, los requisitos de personal y un calendario detallado. Lo más pronto que puede idearse el plan de administración de proyectos es cuando el cliente ha aprobado el documento de especificación. Hasta ese momento la planeación tiene que ser preliminar y parcial.

• Tercero, a lo largo de todo el proyecto la administración necesita supervisar el plan de administración y estar al pendiente de

cualquier desviación. Por ejemplo, suponga que el pían de administración del proyecto específico establecía que la fase de diseño tardaría cuatro meses. Sin embargo, ya han pasado 12 meses y no parece que el proyecto esté muy avanzado.

1.3 1.3 !Por qué no hay una fase de planeación!!Por qué no hay una fase de planeación!

Es casi seguro que se debe abandonar y los fondos invertidos a la fecha se habrán desperdiciado. En vez de ello, la administración debe notar después de dos meses máximo que hay un problema serio con la fase de diseño. En ese momento se podría tomar una decisión de cuál es la mejor manera de proceder. Por lo general, el paso inicial en una situación como ésta es llamar a un consultor para determinar si el proyecto es factible y si el equipo de diseño es competente para realizar la tarea o si el riesgo en caso de continuar es muy grande. Con base en el reporte del consultor ahora se consideran varias alternativas, que incluyen la reducción del alcance del objetivo del sistema de información y luego diseñar e implantar uno menos ambicioso. El proyecto sólo debe cancelarse si todas las demás alternativas se consideran imprácticas. En el caso del proyecto específico, esta cancelación habría ocurrido 10 meses antes si la administración hubiera supervisado el plan de cerca, ahorrando, por consiguiente, una suma considerable de dinero.

1.3 1.3 !Por qué no hay una fase de planeación!!Por qué no hay una fase de planeación!

En otras palabras, no hay una fase de planeación separada. En vez de ello, las actividades de planeación se realizan a lo largo de todo el ciclo de vida.

No obstante, hay ocasiones en que las actividades de planeación predominan. Éstas incluyen el inicio del proyecto (planeación preliminar) e inmediatamente después el documento de especificaciones que ha aprobado el cliente (plan de administración de proyectos).

1.41.4 !Por qué no hay una fase de pruebas!!Por qué no hay una fase de pruebas!

¿Por qué no hay una fase de pruebas? Sin duda es esencial verificar con mucho cuidado un sistema de información después de que se ha desarrollado.

Lamentablemente, verificar el sistema de información una vez que está listo para ser entregado al cliente es demasiado tarde. Por ejemplo, si hay una falla en el documento de especificaciones, ésta se pasará al diseño y a la implementación. Suponga que el documento de especificaciones para Jethro's Boot Emporium incluye la frase incorrecta de que en Wyoming las botas están exentas de impuestos sobre ventas. Entonces el diseño del sistema de información no incluye el cálculo de los impuestos sobre ventas ni tampoco lo incluye la implementación. Si el sistema de información no se hubiera revisado hasta estar completo, entonces cuando la falla se descubriera finalmente sería necesario hacer cambios importantes al sistema.

1.41.4 !Por qué no hay una fase de pruebas!!Por qué no hay una fase de pruebas!

Primero, el documento de especificaciones habría tenido que corregirse para reflejar el hecho de que el impuesto sobre ventas sí se aplica a las botas.

Segundo, el diseño tendría que modificarse en los lugares apropiados.

Tercero, estos cambios también se hubieran tenido que hacer dentro del código. Sin embargo, si el documento de especificaciones se revisa antes de que se inicie el diseño, sólo se tendría que modificar el documento de especificaciones y únicamente en la parte que se refiere al impuesto sobre ventas. La conclusión obvia es que, además de revisar el sistema de información como un todo cuando esté completo (validación), el sentido común dicta que también debe revisarse al final de cada fase (verificación).

1.41.4 !Por qué no hay una fase de pruebas!!Por qué no hay una fase de pruebas!

Pero incluso esto no es suficiente. Se requiere la revisión continua de un sistema de información. No necesita decirle a un profesional de la tecnología de la información que se relaje mientras está desarrollando un sistema. De la misma manera, una verificación cuidadosa debe ser un acompañante automático de cada actividad de desarrollo del sistema de información. A la inversa, una fase de pruebas separada es incompatible con el objetivo de asegurar que un sistema esté lo más libre de fallas posible en cualquier momento.

1.5 ! Por qué no hay una fase de documentación !1.5 ! Por qué no hay una fase de documentación !

Del mismo modo que nunca debe haber una fase de planeación o una fase de pruebas separadas, nunca debería haber una fase de documentación separada. Por el contrario, en todo momento la documentación del sistema de información debe estar completa, ser correcta y estar actualizada.

Por ejemplo, durante la fase de análisis, el documento de especificaciones debe reflejar la versión actual de las especificaciones, lo mismo que para otras fases.

• Una razón por la cual es esencial asegurar que la documentación siempre esté actualizada es la gran renovación de personal en la industria de los sistemas de información. Por ejemplo, suponga que la documentación del diseño no se ha actualizado y que el jefe de diseñadores renuncia para tomar otro empleo. Ahora será sumamente difícil actualizar el documento de diseño para reflejar los cambios que se hicieron mientras se diseñaba el sistema.

1.5 ! Por qué no hay una fase de documentación !1.5 ! Por qué no hay una fase de documentación !

• Una segunda razón es que resulta casi imposible seguir los pasos de una fase específica a menos que la documentación de la fase anterior esté completa, sea correcta y esté actualizada. Por ejemplo, un documento de especificación incompleto debe dar como resultado un diseño incompleto y, por lo tanto, una implementación incompleta.

• Tercero, es virtualmente imposible probar si un programa funciona correctamente a menos que haya documentos que establezcan cómo se supone que se comportará ese programa. Por ejemplo, no habría sido posible probar la parte del programa que se encarga de la detección de una nueva tendencia en la compra de botas, a menos que el documento de especificaciones explicara con exactitud qué constituye una nueva tendencia y de cuántos pares de botas adicionales va a ser el pedido.

1.5 ! Por qué no hay una fase de documentación !1.5 ! Por qué no hay una fase de documentación !

• Cuarto, el mantenimiento es casi imposible a menos que haya una serie completa y correcta de documentación que describa de manera precisa qué hace la versión actual del sistema.

Por lo tanto, del mismo modo que no hay una fase de planeación o de pruebas separada, tampoco hay una fase de documentación separada. En vez de ello, la planeación, la aplica¬ción de pruebas y la documentación deben ser actividades que acompañen a todas las de¬más tareas mientras se construye un sistema de información.

1.6 Análisis y diseño de sistemas1.6 Análisis y diseño de sistemas

Dentro del contexto del desarrollo tradicional de sistemas de información, el término análisis de sistemas se refiere a las primeras dos fases (de requisitos y análisis) y diseño de sistemas se refiere a la tercera fase, la de diseño.

Por desgracia, la terminología del desarrollo tradicional de sistemas de información puede conducir fácilmente a una confusión:

• El término análisis por sí mismo se usa para denotar sólo la segunda fase. Es decir, mientras análisis de sistemas se refiere a la primera y segunda fases del desarrollo tradicional de sistemas de información, análisis se refiere sólo a la segunda. No hay duda de que estos dos

usos diferentes de la palabra "análisis" son muy confusos, pero simplemente no es posible cambiar la terminología utilizada en la tecnología de la información durante los 50 años anteriores.

1.6 Análisis y diseño de sistemas1.6 Análisis y diseño de sistemas

• El término analista de sistemas también se utiliza con dos sentidos diferentes. En algunas empresas la tarea de los analistas de sistemas es determinar las necesidades del cliente en relación a un sistema de información (fase de requisitos) y luego elaborar el documento de especificaciones para registrar formalmente lo que se debe desarrollar (fase de análisis). Luego, los diseñadores de sistemas planean el sistema que se quiere crear. No obstante, en la mayoría de las empresas no hay desarrolladores de sistemas independientes. Los analistas, por lo tanto, son responsables de las tres primeras fases, a saber, las de requisitos, análisis y diseño. En este libro se usa el término "analista de sistemas" en este segundo sentido debido a que es el método de uso más común en la industria de los sistemas de información.

1.7 Mantenimiento1.7 Mantenimiento

• Una concepción errónea común es que sólo un sistema de información malo debe modificarse después de la instalación. Por el contrario, los sistemas de información malos se botan a la basura, mientras los sistemas de información buenos se modifican durante muchos años. La figura 1.2 es un diagrama clave. Representa el porcentaje promedio de tiempo (= dinero) dedicado a un sistema antes de la instalación (desarrollo) y después de la instalación (mantenimiento) en la computadora del cliente [Hartón, 1998; Schach, 2002].

1.7 Mantenimiento1.7 Mantenimiento

Al observar la figura 1.2, es claro que, en promedio, por cada dólar gastado en desarrollo, se gastan dos en mantenimiento. De hecho, algunos expertos afirman que la figura 1.2 se queda corta y que por cada dólar gastado en desarrollo, se gastan tres o más en mantenimiento durante la vida del sistema de información [Yourdon, 1992]. Ya sea que la razón 1:2 calculada por lo bajo entre el dinero gastado en desarrollo y en mantenimiento que se muestra en figura 1.2 sea correcta, o que la razón real sea 1:3, es claro que el mantenimiento es la fase más importante del ciclo de vida del sistema de información.

1.7 Mantenimiento1.7 Mantenimiento

Hay tres actividades de mantenimiento principales:

• El mantenimiento correctivo es la reparación de las fallas del sistema de información, que con frecuencia están en el código, pero el

mantenimiento correctivo también incluye la reparación de todos los demás artefactos de un sistema de información, incluyendo el documento de especificaciones, el documento de diseño, los manuales, etcétera.• El mantenimiento perfectivo consiste en los cambios hechos al sistema de información debido a que el cliente desea ampliar las funciones del sistema. Por ejemplo, el cliente puede querer que el sistema tenga un tiempo de respuesta más corto o sea capaz de manejar la conversión de precios a euros además de a dólares.

1.7 Mantenimiento1.7 Mantenimiento

Hay tres actividades de mantenimiento principales:

• Cuando hay un cambio en el entorno en el cual opera el sistema de información, éste debe modificarse. A esto se le llama mantenimiento adaptativo. Por ejemplo, si el tipo de gravamen sobre ventas cambia, cualquier sistema de información relacionado con la compra y venta debe cambiar en consecuencia. Además, si el sistema de información debe cambiarse de modo que pueda correr en una computadora diferente o con un sistema operativo diferente, también se considera mantenimiento adaptativo.