1 94

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

4 a fase de anlisis
Una vez completada la planificacin y establecido el mecanismo de control, el equipo de proyecto pasa al anlisis del sistema existente. El anlisis de sistemas es el estudio de un sistema existente con el propsito de disear un sistema nuevo o mejorado. Durante la fase de anlisis, el analista de sistemas sigue trabajando con el gerente, y el comit director de M I S interviene en puntos cruciales, como se muestra en la figura 8.4.

1. Anunciar el estudio de sistemas

Cuando una c o m p a a implementa una nueva aplicacin de computadora, la gerencia toma medidas para asegurar la cooperacin de los empleados. Una preocupacin inicial son los temores de los empleados respecto a la forma como la computadora podra afectar su trabajo. La mejor forma de combatir estos temores es comunicar a los empleados (1) las razones que tiene la c o m p a a para iniciar el proyecto y (2) los beneficios que el nuevo sistema acarrear tanto para la c o m p a a como para los empleados. La gerencia puede reunirse con los empleados en sesiones individuales o de grupo y puede usar material escrito como memorandos y boletines de la c o m p a a para anunciar el estudio. En el caso de compaas cuyas operaciones estn dispersas, los anuncios tambin pueden hacerse mediante videocintas.

2. Organizar el equipo de proyecto

Se rene el equipo de proyecto que realizar el estudio de sistema. Muchas compaas tienen como poltica nombrar a un usuario, no a un especialista en informacin, como jefe del proyecto. Es crucial para el xito del proyecto que los usuarios desempeen papeles activos, no pasivos.

FIGURA 8.4
La fase de anlisis

Comit director de MIS

Gerente

nalista de sistemas

Preparar la propuesta de diseo

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA DE LOS SISTEMAS

95

3. Definir las necesidades de informacin

Los analistas se enteran de las necesidades de informacin de los usuarios realizando diversas actividades de recoleccin de informacin, que incluyen entrevistas personales, observaciones, bsquedas de archivo y encuestas. De todos estos mtodos, la entrevista personal es la preferida, por las razones siguientes:: I Ofrece la oportunidad de tener comunicacin en ambas direcciones y de observar el lenguaje corporal. Estimula entusiasmo por el proyecto de parte tanto de los usuarios como de los especialistas en informacin. Establece un vnculo de confianza mutua entre los usuarios y los especialistas en informacin. Proporciona a los participantes en el proyecto la oportunidad de expresar diferentes opiniones, incluso opuestas.

ste es el punto del SLC en el que el analista rene la d o c u m e n t a c i n del sistema existente. El analista revisa la d o c u m e n t a c i n que se haya preparado cuando se cre el sistema actual y aade d o c u m e n t a c i n nueva si es necesario. La d o c u m e n t a c i n incluye diagramas de flujo, diagramas de flujo de datos y otras descripciones grficas y narrativas de procesos y datos. A menudo se usa el trmino diccionario de proyecto para describir toda la documentacin que define un sistema. La tendencia es mantener el diccionario del proyecto en forma electrnica, no en papel.

4. Definir los criterios de desempeo del sistema

Una vez definidas las necesidades de informacin del gerente, ya es posible especificar en trminos exactos q u es lo que debe lograr el sistema: los criterios de d e s e m p e o . Por ejemplo, un gerente de mercadotecnia que necesita un informe mensual de gastos puede insistir en los criterios de desempeo siguientes: I El informe debe prepararse tanto en forma impresa como en pantalla. El informe debe estar listo no ms de tres das despus de fin de mes. El informe debe comparar los ingresos y gastos reales y presupuestados, tanto para el mes inmediato anterior como para el a o a la fecha. Desde luego, estas especificaciones slo se adoptarn como criterios de desempeo si el equipo de proyecto conviene en que son alcanzables.

5. Preparar la propuesta de diseo

El analista de sistemas proporciona al gerente la oportunidad de tomar una segunda decisin, ya sea en contra o en favor. Aqu, el gerente debe aprobar la fase de diseo, y el apoyo para esa decisin est incluido en la propuesta de diseo. En la figura 8.5 se incluye un formato sencillo para este documento.

6. Aprobar o rechazar el proyecto de diseo

El gerente y el comit director de M I S evalan la propuesta de diseo y determinan si darn o no su aprobacin. En algunos casos, puede pedirse al equipo que realice otro anlisis y que vuelva a presentar la propuesta de diseo; o bien, puede abandonarse el proyecto. Si se da la aprobacin, el proyecto pasa a la fase de diseo.

196

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

FIGURA 8.5
Sinopsis de una propuesta de diseo Resumen ejecutivo Introduccin Definicin del problema Objetivos y restricciones del sistema Criterios de desempeo Posibles sistemas alternativos Proyecto de diseo recomendado 7.1 Tareas a realizar 7.2 Recursos humanos requeridos 7.3 Programa de trabajo 7.4 Costo estimado 8. Impacto esperado del sistema 8.1 Impacto sobre la estructura de organizacin de la compaa 8.2 Impacto sobre las operaciones de la compaa 8.3 Impacto sobre los recursos de la compaa 9. Plan de desarrollo general (fases de anlisis, diseo e implementacin) 10. Resumen 1. 2. 3. 4. 5. 6. 7.

a fase de diseo
Ya que se entiende el sistema existente y los requisitos que debe cumplir el nuevo sistema, el equipo de proyecto puede abordar el diseo del nuevo sistema. El d i s e o de sistemas es la determinacin de los procesos y datos que un nuevo sistema requiere. Si el sistema es computarizado, el diseo puede incluir una especificacin de los tipos de equipo que se usarn. Los pasos de la fase de diseo se muestran en la figura 8.6.

1. Preparar el diseo de sistema detallado

El analista trabaja con el usuario y documenta el diseo del nuevo sistema empleando herramientas como las que se describen en los apndices. En la tabla 8.2 se listan las herramientas que ms se usan. Algunas de las herramientas permiten al analista preparar la d o c u m e n t a c i n de manera descendente, comenzando con el panorama general e introduciendo gradualmente m s detalles. Este enfoque descendente es una caracterstica del d i s e o estructurado, en el que el diseo pasa del nivel de sistema al nivel de subsistemas. Las figura 8.7 y 8.8 ilustran este proceso descendente. La figura 8.7 es un diagrama de flujo de datos ( D F D , data flow diagram), que muestra c m o los flujos de datos vinculan cuatro sistemas de procesamiento de datos. Explicaremos los detalles de la diagramacin de flujos de datos en el apndice B. La figura 8.8 muestra c m o uno de los subsistemas, el de captura de pedidos, se documenta con mayor detalle. El sistema de captura de pedidos consiste en cuatro subsistemas, numerados del 1.1.1 al 1.1.4, que pueden documentarse en niveles todava ms bajos del sistema. Cada una de las flechas de las figuras representa un flujo de datos y puede documentarse con una entrada en el diccionario de datos. El diccionario de datos es la descripcin formal del contenido de una base de datos. Proporciona un lenguaje c o m n que todos los creadores de sistemas pueden usar para describir los recursos de datos de una c o m p a a . La figura 8.9 es una entrada de diccionario de flujo de datos para los flujos de datos de rdenes de venta de las figuras 8.7 y 8.8.

2. Identificar configuraciones alternativas del sistema

El analista debe identificar ahora la configuracin no la marca n i el m o d e l o - del equipo de c m p u t o que mejor permitir al sistema realizar el procesamiento. La identificacin es un proceso secuencial que inicia con la identificacin de diversas combinaciones que pueden llevar a cabo cada tarea. En la tabla 8.3 se listan algunas combinaciones que p o d r a n considerarse para el sistema de captura de pedidos.

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA DE LOS SISTEMAS

9Z

El analista elimina las combinaciones de equipos que obviamente son incompatibles o inaceptables, reduciendo las alternativas a un n m e r o razonable. En la tabla 8.4 se identifican tres alternativas para estudiarlas detalladamente.

3. Evaluar configuraciones alternativas del sistema

El analista, trabajando en estrecha colaboracin con el gerente, evala las alternativas. Se selecciona la que mejor permite al subsistema satisfacer los criterios de desempeo, dadas las restricciones. Utilizando el sistema de captura de pedidos como ejemplo, supongamos que se escoge la Alternativa 3.

TABLA 8.2
Herramientas de ms utilizadas documentacin Modelado de datos Diagrama de entidades-relaciones Diccionario de datos Forma de diseo de pantalla/impresora Sistema de flujo del programa Diagrama de flujo del programa Diagrama de flujo de datos Ingls estructurado Modelo de relacin de objetos Especificacin de clases

Modelado de procesos

Modelado de objetos

1 98

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

FIGURA 8.7
Diagrama de flujo de datos de cuatro subsistemas de procesamiento de datos Avisos de rdenes de venta rechazadas

1 l
1.1 Captura de pedidos

Pedidos aceptados

1
Artculos surtidos 1.2 Inventarios

Archivo de eliminaciones de bitcora Pagos de los clientes

Facturas Estados de cuenta

f
Datos de inventarios a . contabilidad Datos de compra Artculos recibidos

1.3 I Pedidos facturados Facturacin

1.4 Cuentas por cobrar

Datos de cuentas por cobrar a contabilidad

Los otros tres subsistemas de la figura 8.7 -facturacin, inventarios y cuentas por cobrar- se evalan de la misma manera.

4. Seleccionar la mejor configuracin

El analista evala todas las configuraciones de subsistemas y ajusta la mezcla de dispositivos para que todos los subsistemas se ajusten a una sola configuracin. Cuando termina, el analista presenta la recomendacin al gerente para su aprobacin. Si el gerente aprueba la configuracin, se busca la aprobacin del comit director de M I S . El resultado de este proceso de diseo es una configuracin de equipo, como la que se muestra en la figura 8.10, que es la que mejor permite al sistema alcanzar sus objetivos dentro de sus restricciones. Esta especificacin de sistema ser la base para los trabajos que se efecten en la fase de implementacin.

5. Preparar la propuesta de implementacin

El analista prepara una propuesta de i m p l e m e n t a c i n que bosqueja los trabajos de implementacin por realizar, los beneficios esperados y los costos. En la figura 8.11 se muestra un formato.

6. Aprobar o rechazar la implementacin del sistema

La decisin de continuar con la fase de implementacin tiene especial importancia, porque la implementacin incrementar considerablemente el n m e r o de participantes. Si los beneficios esperados del sistema exceden los costos, se aprobar la implementacin.

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA DE LOS SISTEMAS

99

FIGURA 8.8
Diagrama de flujo de datos del sistema de captura de pedidos

rdenes de venta

Rechazos editados

rdenes de venta rechazadas editadas

1.1.1
Avisos de rdenes de venta rechazadas I Editar datos de pedidos Pedidos editados Archivo de crdito de clientes

1.1.2
Pedidos editados y verificados Calcular verificacin de crdito

Datos de crdito I

f
Pedidos aceptados

Rechazos por crdito Datos de pedidos

1.1.3
Asentar pedidos

Ordenes de venta rechazadas por crdito

Pedidos terminados

1.1.4
Marcar pedidos surtidos

Fecha de surtido I

Bitcora de pedidos

4 a fase de implementacin
I m p l e m e n t a c i n es la adquisicin e integracin de los recursos fsicos y conceptuales que producen un sistema funcional. Las tareas se muestran en la figura 8.12. Las flechas de dos puntas que conectan los pasos 3 a 7 indican que esas tareas pueden realizarse al mismo tiempo.

1. Planear la implementacin
Ahora que slo queda una fase de desarrollo antes de que el nuevo sistema entre en funciones, los gerentes y los especialistas en informacin entienden muy bien lo que se necesitar hacer para implementar el diseo del sistema. Ellos pueden utilizar estos conocimientos para crear un plan de implementacin muy detallado.

2. Anunciar la implementacin
El proyecto de implementacin se anuncia a los empleados de forma similar a como se anunci el estudio del sistema. El propsito de este anuncio es informar a los empleados de la decisin de implementar el nuevo sistema y solicitar su cooperacin.

200

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

3. Obtener los recursos de hardware

E l diseo del sistema se presenta a los proveedores de los tipos de equipos de cmputo incluidos en la configuracin aprobada. A cada proveedor se le proporciona una solicitud de propuesta ( R F P , request farproposal) que se bosqueja en la figura 8.13. L a descripcin del diseo de sistemas de la Seccin 3 permite a los proveedores seleccionar las unidades de cmputo

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA DE LOS SISTEMAS

201

TABLA 8.3
Las opciones de hardware hacen posibles mltiples configuraciones del sistema

Elementos del sistema Entrada

Alternativas Terminal con teclado Voz Lector ptico Cinta magntica Disco magntico Cinta magntica Disco magntico Cinta magntica Disco magntico Cinta magntica Disco magntico Impresora de lneas Terminal con teclado Audio Por lotes En lnea

Bitcora de pedidos Archivo de crdito de clientes Archivo de pedidos rechazados Archivo de pedidos aceptados Aviso de pedidos rechazados

Procesamiento

ms apropiadas para la tarea. E l programa de instalacin de la Seccin 4 les dice a los proveedores cundo se deber entregar el equipo y prepararse para su uso. Si los proveedores deciden competir por el pedido, preparan una propuesta por escrito, como la que se bosqueja en la figura 8.14. L a Seccin 6 explica c m o el equipo propuesto permitir al sistema satisfacer sus criterios de desempeo. Una vez que se han recibido y analizado todas las propuestas, el comit director de M I S selecciona el proveedor o proveedores. Los especialistas en informacin proporcionan apoyo para esta decisin estudiando las propuestas y haciendo recomendaciones. Una vez que se aprueba la decisin, la compaa hace los pedidos.

4. Obtener los recursos de software

Cuando una compaa decide crear su propio software de aplicacin, el programador usa la documentacin preparada por el analista de sistemas como punto de partida. E l programador podra preparar documentacin ms detallada, como ingls estructurado (seudocdigo) o dia-

TABLA 8.4
Alternativas seleccionadas para un estudio detallado

Alternativa 1 2 3

Entrada Lector Terminal con teclado Terminal con teclado

Bitcora de pedidos Cinta magntica Disco magntico Disco magntico

Archivo de c r d i t o de clientes Disco magntico Disco magntico Disco magntico

Archivo de pedidos aceptados y rechazados Cinta magntica Cinta magntica Disco magntico

Archivos de pedidos completos Cinta magntica Cinta magntica Cinta magntica

Aviso de pedidos rechazados Impresora de lnea Impresora de lnea Tenrnal con teclado

202

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

FIGURA 8.10
La configuracin seleccionada de equipo 4 unidades de cinta magntica

80 terminales

4 unidades de disco magntico

gramas de flujo de programa. Se realiza la codificacin y se prueban los programas. El producto final es una biblioteca de programas de aplicacin. Si se compra software de aplicacin preescrito, la seleccin del proveedor de software puede seguir el mismo procedimiento que se emplea para seleccionar los proveedores de hardware: una RFP y las propuestas.

FIGURA 8.11
Sinopsis de una propuesta de implementacin

Resumen ejecutivo Introduccin Definicin del problema Objetivos y restricciones del sistema Criterios de desempeo Diseo del sistema 6.1 Descripcin resumida 6.2 Configuracin de equipo 7. Proyecto de implementacin recomendado 7.1 Tareas a realizar 7.2 Recursos humanos requeridos 7.3 Programa de trabajo 7.4 Costo estimado 8. Impacto esperado del sistema 8.1 Impacto sobre la estructura de organizacin de la compaa 8.2 Impacto sobre las operaciones de la compaa 8.3 Impacto sobre los recursos de la compaa 9. Plan de implementacin general 10. Resumen

1. 2. 3. 4. 5. 6.

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA DE LOS SISTEMAS

203

FIGURA 8.12
La fase de implementacin

Aprobar o rechazar el corte y cambio al nuevo sistema

10

Corte y cambio al nuevo sistema

5. Preparar la base de datos

E l administrador de base de datos (DBA) se encarga de todas las actividades relacionadas con los datos, incluida la preparacin de la base de datos. E n algunos casos se hace necesario recolectar datos nuevos; en otros es preciso modificar el formato de los datos existentes para que se ajusten al nuevo diseo de sistema. Se llevan a cabo estas tareas y se introducen los datos en la base de datos.

204

PARTE TRES TEORA Y METODOLOGAS DE SISTEMAS

FIGURA 8.13
Sinopsis de una solicitud de propuesta

Si ia c o m p a a no est usando ya un sistema de administracin de bases de datos ( D B M S , datbase management systerr), el D B A desempear un papel clave en la seleccin de ese software. El software de D B M S se describir en el captulo 10.

6. Preparar las instalaciones risicas

Si el hardware del nuevo sistema no cabe en las instalaciones existentes, ser necesario realizar una construccin nueva o una remodelacin. U n cuarto de computadora que aloja a una mainframe o a una minicomputadora grande requiere una combinacin compleja de piso levantado, controles especiales de temperatura y humedad, medidas de seguridad, equipo para deteccin y extincin de incendios, y cosas por el estilo. La construccin de tales instalaciones debe programarse de manera que coincida con el plan general del proyecto.

7. Educar a los participantes y usuarios

Lo m s probable es que el nuevo sistema afecte a mucha gente. Algunos harn que el sistema funcione. stos son los participantes, e incluyen los capturistas de datos, codificadores y otro personal de oficina y administrativo. Otras personas usarn las salidas del sistema. A toda esta gente es preciso educarla en cuanto al papel que desempearn en el sistema.

8. Preparar la propuesta de corte y cambio

El proceso de suspender el uso del sistema antiguo e iniciar el uso del nuevo se llama corte y cambio. Cuando se hace evidente que todos los trabajos de desarrollo se estn acercando a su conclusin, el equipo de proyecto recomienda al gerente realizar el corte y cambio. La propuesta puede adoptar la forma de un memorando o de un informe oral.

FIGURA 8.14
Sinopsis de una propuesta de proveedor

CAPTULO 8 METODOLOGAS DEL CICLO DE VIDA D E LOS SISTEMAS

205

Puntos sobresalientes en MIS

El momento debe ser oportuno para el corte y para el amblo

Uno de los ms grandes proyectos de cmputo que alguna vez intent Harcourt Brace & Company de Orlando, Florida, fue su sistema COPS. COPS es el acrnimo de Customer Order Processing System (Sistema de Procesamiento de Pedidos de Clientes), y se encarga de captura de pedidos, inventarios y facturacin. En 1988 Harcourt Brace decidi implementar COPS y contrat a Andersen Consulting para crear un plan de proyecto. Los trabajos de planificacin requirieron un ao. Harcourt Brace no contaba con un comit director de MIS en ese entonces, pero form un comit especial de revisin de COPS para supervisar el proyecto. El jefe del proyecto se transfiri a IS de un rea usuaria, y se arm el resto del equipo de proyecto. El corte y cambio estaba programado para abril de 1991. Al acercarse la fecha del corte y cambio, se hizo evidente que el nuevo sistema no estara listo. Los usuarios identificaron varios defectos del diseo del nuevo sistema que era preciso corregir. El comit de revisin de COPS aclar al personal de IS que el corte y cambio no se efectuara antes de haberse corregido todos los defectos. El corte y cambio se pospuso hasta noviembre de 1991, y luego hasta febrero de 1992: aproximadamente cuatro aos despus de haberse tomado la decisin de iniciar el proyecto. Por fin, el comit qued satisfecho de que el momento era apropiado para implementar el nuevo sistema, y se dio la seal de proceder. El sistema se implemento y funcion como se quera que funcionara. Este relato es importante por dos razones. Primera, lustra el periodo de tiempo tan largo que puede requerirse para implementar un sistema, incluso uno en el que el problema se entiende bien, como es el caso de un sistema de informacin contable. Segunda, se destaca el hecho de que la gerencia de alto nivel no autorizar el corte y cambio hasta que est absolutamente segura de que el sistema est listo para la compaa y la compaa est lista para el sistema. Por qu cree usted que la gerencia de alto nivel haya escogido a alguien de un rea usuaria como efe del proyecto? Qu podra hacerse para minimizar la probabilidad de que los usuarios detecten errores en el diseo de un nuevo sistema? Resulta ventajoso tener un comit director gerencial especial para cada proyecto grande en lugar de un comit director para todos los proyectos? Tiene limitaciones este enfoque?

9. Aprobar o rechazar el corte y cambio al nuevo sistema

El gerente y el comit director de M I S revisan la situacin del proyecto y aprueban o bien rechazan la recomendacin. Si la gerencia aprueba la recomendacin, fija la fecha para el corte y cambio. Si la gerencia rechaza la recomendacin, especifica las acciones por realizar y las tareas por terminar antes de que vuelva a considerar el corte y cambio; luego, se fija una nueva fecha.