Sistemas de Informacin

Qu es un Sistema? Podemos definir a los sistemas como aquellos objetos compuestos de partes que interactan entre s. Partes que se interrelacionan, formando una totalidad. Un conglomerado o agregado es un objeto compuesto por partes que no interactan entre s. Simplemente son partes sumadas, pero que tambin forman un todo. Ejemplos de sistemas pueden ser el sistema solar, el cuerpo humano, el motor de un automvil y una empresa o grupo social. Ejemplos de un conglomerado pueden ser un saco de manzanas (en el supuesto que no nos interesa la posicin particular de las manzanas), el grupo humano que ocupa en un momento del da un microbs (partiendo de la base que no existe interaccin entre los pasajeros o en otras palabras que la conducta de un pasajero no afecta la conducta de otro). Tambin puede ser un conglomerado la suma de espectadores de un partido de ftbol. Se puede observar que mientras es fcil encontrar ejemplos de sistemas, en la casa de los conglomerados se ha tenido que limitar esos ejemplos a ciertas condiciones particulares: La independencia de las manzanas, y lo mismo para el caso de los pasajeros del bus. De esto se puede desprender que todo objeto es un sistema y que para ciertos problemas, o en algunas situaciones particulares, un sistema puede ser considerado como conglomerado. Del ejemplo del estadio se puede extraer una buena ilustracin de la diferencia entre sistema y conglomerado. Se dijo que los espectadores (supongamos, para simplificar, que sean individuos aislados y desconocidos unos de otros) forman un conglomerado. Sin embargo, los veintids jugadores, el rbitro y los dos jueces de lnea no son un conglomerado. Cul es la diferencia? Evidentemente que es la interaccin entre ellos. Si observamos la conducta de los espectadores, veremos que responden a ciertos parmetros fijos. Prendern cigarrillos (los que fuman), gritarn de alegra cuando su equipo logre marcar un tanto o al menos, manifestarn alguna conducta demostrativa de su gratificacin, se disgustarn frente a una actitud equivocada del rbitro (por lo menos los partidarios del equipo damnificado). Podemos entonces, fcilmente ver la conducta de algunos de ellos (una muestra representativa) y proyectar la conducta que desarrollarn los espectadores durante el partido.

Sin embargo, cada persona, como tambin los grupos de personas que van a ver el partido son sistemas, es decir, objetos compuestos de partes organizadas, estructuradas e interrelacionadas de una forma especial. Como podemos decir que el hombre es un sistema, se concluye que un conglomerado puede ser una suma de sistemas, siempre que stos no interacten entre s.

Otro aspecto que es conveniente destacar es la siguiente situacin: supngase que durante el entretiempo un, hincha de uno de los equipos rene a otros hinchas de ese mismo club y juntos organizan una "barra". El les ensea ciertos gritos de guerra y les indica que cuando l se ponga de pie y se vuelva hacia ellos, todos deben gritar y avivar al equipo, siguiendo un cierto esquema orden de "grito de guerra. Cuando esto se produce lo que est sucediendo es que el conglomerado (los hinchas dispersos e individualistas) se han, reunido para llevar a cabo una cierta interaccin con un objetivo bien determinado. An ms, han reglamentado la forma de interactuar. Ya no se puede hablar de conglomerado humano, sino de un sistema humano. De aqu, se puede concluir que un conglomerado puede convertirse, de acuerdo a las circunstancias. en un sistema. En otras palabras, un conglomerado es un sistema al que se le han inhibido ciertas interacciones en forma artificial. Cuando estas limitaciones desaparecen, entonces vuelven a transformarse en su estado inicial, es decir, en un sistema. Observando las caractersticas de conglomerados y sistemas, se puede concluir que la diferencia fundamental entre ambos conceptos es la interaccin entre sus partes componentes. Cuando las partes interactan estamos frente a un sistema. Cuando las partes no interactan entonces, nos encontramos frente a un conglomerado. En general, a los sistemas se les puede aplicar una serie de conceptos de la teora general de sistemas, tales como: sinergia, recursividad, autorregulacin, direccin por excepcin y autonoma relativa.

Sistemas Viables Para acercarnos ms a los viables. Un sistema abierto viable es aquel que es capaz de adaptarse dentro de ciertos lmites, a los cambios que se experimentan en el medio en que vive. As, por ejemplo, el sistema viable por excelencia parece ser el humano. El hombre es capaz de capaz de adaptarse a cambios climticos, econmicos. etc. Todo esto, por supuesto dentro de ciertos lmites "'fisiolgicos". Pero existen sistemas abiertos no viables, los que ante cambios en el medio, simplemente dejan de existir. Por ejemplo, una sequa o un cambio de clima seca los manantiales que proveen de agua a la cascada y sta desaparece. Tambin el mismo hombre deja de ser viable cuando los cambios que se desarrollan en su entorno van ms all de los lmites de su capacidad de adaptacin. Si un hombre es encerrado en una caja de fondos por un perodo prolongado, la disminucin del oxgeno termina por provocarle la muerte. El sistema no es capaz de adaptarse a una atmsfera con un bajo o nulo contenido de oxgeno y un alto contenido de CO2. 1.2 Los Subsistemas El uso de subsistemas, como la construccin por bloques, es bsico para analizar y desarrollar los sistemas. Esto requiere la comprensin de los principios que dictaminan la manera como se construyen los sistemas a partir de los subsistemas sistemas que son de nuestro inters debemos dividirlos en sistemas abiertos viables y no

hacer una nueva clasificacin y

1.21 Descomposicin Un sistema complejo es difcil de comprender cuando se considera como un todo, por lo tanto, el sistema se descompone o se factoriza en subsistemas. Los lmites e interfaces estn definidos de tal manera que la suma de los subsistemas constituye un sistema completo. Este proceso de descomposicin se contina con los subsistemas que se dividen en subsistemas ms pequeos hasta que el ms pequeo de los subsistemas tenga un tamao manejable. Los subsistemas resultantes de estos procesos generalmente tienen la forma de

estructura jerrquica (figura 1.1) En la jerarqua un subsistema es un elemento de un suprasistema (el sistema superior a l).

Sistem

Subsistema

Subsistema

Subsistema

A21

A22

C11

C12

Figura 1.1 Relaciones jerrquicas de los subsistemas.

Un ejemplo de descomposicin es la factorizacin de un sistema de procesamiento de datos en subsistemas. Un ejemplo de descomposicin podra ser el siguiente: 1. a) b) c) d) e) f) g) h) Subsistemas: Entrada de ventas y pedidos. Inventarios. Produccin. Personal y nmina. Compras. Contabilidad y control. Planeacin. Inteligencia.

2. Cada subsistema se puede dividir an ms. Por ejemplo, el subsistema de Personal y nmina podra dividirse en: a) b) c) d) e) Creacin y actualizacin de registras de personal y nmina. Informes de personal. Datos de entrada para nmina y validacin. Procesamiento de nmina de asalariados. Informes de nmina para la gerencia.

f) 3.

Informes de nmina para el sistema tributario estatal. Si la tarea es disear y programar un nuevo sistema, los subsistemas

(aplicaciones principales) definidos en (2) podran dividirse en subsistemas an ms pequeos o mdulos. Por ejemplo, el procesamiento peridico de la nmina podra ser descompuesto en mdulos tales como: clculo de las deducciones y el sueldo neto, registro de la nmina y preparacin de controles para auditoria. Impresin de cheques, registros y controles de salida, etc. (figura 1.2) La descomposicin en subsistemas se usa tanto en el anlisis del sistema actual como en el diseo e implementacin de un nuevo sistema. En ambos casas el investigador o diseador debe decidir como descomponerlo, por ejemplo, dnde ubicar los lmites. Las decisiones dependern de los objetivos de la descomposicin y tambin de las diferencias personales entre los diseadores. Esta ltima se podra minimizar.

Procesamiento peridico de la nomina

Calculo del sueldo total, deducciones y sueldo neto a pagar

Preparacin de los registros de nmina y de los controles de auditoria

Impresin de cheques

Calculo del sueldo total, deducciones y sueldo neto a pagar

Figura 1.2 Estructura jerrquica de un sistema de nmina.

El principio general de la descomposicin supone cohesin funcional. Los componentes estn considerados como parte del mismo subsistema si desempean o estn relacionados a la misma funcin. En diseo, la Identificacin de los subsistemas cohesionados funcionalmente es el primer caso. En consecuencia los lmites necesitan estar claramente especificados. las

interfaces simplificadas y establecidas las conexiones apropiadas entre los subsistemas.

1.2.2 Simplificacin El proceso de descomposicin podra conducir a un gran nmero de interfaces de subsistemas por definir. El nmero de interconexiones, si todos los subsistemas interactan, en general es n(n-1)/2 donde n es el nmero de subsistemas. Cada interconexin (ver figura 1.3) es un interfase potencial para la comunicacin entre los subsistemas. Cada interfaz implica la definicin de un paso de comunicacin.

A A

A A

B B

B B

Figura 1.3 Todos los sistemas interconectados.

La simplificacin es el proceso de organizar los subsistemas de manera tal que se reduzca el nmero de interconexiones (figura 1.4) . Algunos mtodos de simplificacin son: 1. Se establece que las agrupaciones de subsistemas interactan cada una con la otra, por lo tanto se define un simple paso de interfaz de un grupo hacia otros subsistemas o grupos de subsistemas (figura 1.4). 2. Se establecen los mtodos para el desacoplamiento de sistemas. de tal manera que la necesidad de la interconexin se reduzca.

A1

A1

B1

B1

A1

A1

B1

B1

Figura 1.4 Los sistemas conectados en grupo y stos, a su vez , interconectados con una interfaz simple.

1.2.3 Desacoplamiento Si dos diferentes subsistemas estn conectados de modo muy compacto se requiere entre ellos una coordinacin muy exacta. Por ejemplo, si la materia prima entra directamente a produccin en el momento en que llega a la fbrica, el sistema de materia prima se puede decir que est fuertemente acoplado. Bajo estas condiciones, las entregas de materia prima (insumos al sistema de produccin y salidas provenientes del sistema de materias primas), deben hacerse oportunamente con el fin de evitar demoras en la produccin, para prevenir que el material nuevo que llegue demasiado pronto, no tenga lugar dnde almacenarse. Tales acoplamientos tan compactos plantean una coordinacin muy fuerte y exigencias de oportunidad entre los dos sistemas. En razn de que es algo independiente, es difcil hacer que operen de una manera completamente sintonizada. La solucin es desacoplar o reducir conexiones de tal manera que los dos sistemas puedan operar en corto plazo con alguna medida de independencia. Un ejemplo de desacoplamiento es el de la figura1.5 que significa inventarios, almacenamientos intermedios o lneas de espera. En el ejemplo de los subsistemas de materias primas y produccin, el inventario de materias primas permite a los dos subsistemas operar independientemente en cierto sentido (en

el corto plazo). Las memorias intermedias de datos se utilizan en algunos sistemas de computacin y en algunos sistemas de comunicacin para compensar las diferentes relaciones de entradas y salidas de datos. Subsistema de materias primas Inventario
Uso de Inventario o almacenamiento intermedio

Subsistema produccin

Figura 1.5 Mecanismo de desacoplamiento para reducir la necesidad de comunicacin entre los subsistemas. Los problemas de acoplamiento compacto no slo se derivan de los problemas fsicos de la coordinacin de los movimientos de los recursos, sino tambin de los problemas de la comunicacin. Los diferentes mtodos de desacoplamiento reducen la necesidad de comunicacin y permiten a los subsistemas comunicarse sobre bases de excepcin. Solamente si el sistema comienza a operar por fuera de ciertos lmites hace que los otros subsistemas, con los cuales se interconectan necesiten estar informados. El empleo de mecanismos de desacoplamiento puede, por lo tanto, ser visto como una alternativa al incremento en las comunicaciones. Esto implica que una mejora en el sistema de informacin o de comunicacin puede aumentar la oportunidad para el acoplamiento compacto y puede reducir la necesidad de mecanismos de desacoplamiento. El proceso de desacoplamiento y el permitir a cada subsistema alguna independencia en el manejo de sus asuntos tiene muchos beneficios pero no se hace sin costo. Uno de stos es el costo mismo del mecanismo de desacoplamiento (inventarios, almacenamiento intermedio, lneas de espera recurso de holgura, estndares. etc.). Otros costos parten del hecho de que cada subsistema puede actuar de la mejor manera posible como un subsistema, pero la suma de sus acciones puede no ser ptima para su organizacin. Este es el problema de la sub optimizacin. 1.3.1 Eficiencia y efectividad organizacional Un problema organizacional corriente es como evaluar una unidad organizacional o actividad. Los conceptos de sistemas sugieren dos clases principales de medidas de desempeo: la eficiencia y la efectividad.

La relacin entre la efectividad y la eficiencia es que la efectividad es una medida de la "bondad" de la salida, mientras que la eficiencia es una medida de los recursos requeridos para obtener un resultado. La importancia de la dicotoma eficiencia-efectividad es que las organizaciones tienden a medir y a controlar la eficiencia ms que la efectividad. La razn es que las medidas de eficiencia tienden a ser ms fciles de obtener y ms precisas en su formulacin. Esto con frecuencia produce resultados incorrectos, pero eficientes. Por ejemplo, el desarrollo de un sistema de informacin para las aplicaciones se debe medir por la adhesin a un presupuesto y por el desarrollo de estndares (eficiencia), sin mirar hasta que punto las aplicaciones satisfacen las necesidades de los usuarios (efectividad). Por otro lado, el carcter jerrquico de las organizaciones se manifiesta entre otras formas, por la fragmentacin de los objetivos globales en una jerarqua de sub objetivos ms fciles de manejar. Pero esta fragmentacin de los objetivos globales introduce problemas de coordinacin, dado que el xito de cualquier sistema en cuanto al cumplimiento de responsabilidades asignadas, depende del funcionamiento conjunto de sus subsistemas. Cada subsistema recibe informacin que describe las acciones que le son asignadas y le induce a comportarse de un modo concordante con los objetivos globales de la organizacin. Esta coordinacin se alcanza principalmente mediante planes que estn destinados a hacer que la organizacin se comporte como un sistema coordinado, dirigido hacia un objetivo. Dentro de este contexto. El papel de la informacin en la organizacin es apoyar los procesos de coordinacin, planificacin y control. En otras palabras, apoyar la toma de decisiones asociadas a tales procesos. Este apoyo se manifiesta en el conocimiento del estado de la organizacin y su entorno, y posibles proyecciones o predicciones de su comportamiento y en la comunicacin de las acciones derivadas de las decisiones que se originan en tal conocimiento. 1.3.2 La planeacin organizacional. La planeacin es la funcin organizacional que provee la infraestructura para las actividades operacionales y la toma de decisiones. La misin organizacional se traduce en objetivos operacionales, mediante una jerarqua de las actividades de planeacin.

Debido a que la planificacin informal en las organizaciones por lo general es inconsistente e incompleta, se justifica la planeacin formal. Lo anterior, con la finalidad de concentrar las energas y actividades de la organizacin sobre la ejecucin de sus objetivos, reconciliar diferencias entre ellos y en los planes de las sub-reas y de los individuos dentro de la organizacin, y eliminar ambigedades en relacin con las actividades especficas a realizar. El plan formal adems de guiar la actividad. provee la base para la evaluacin de los resultados. Se pueden identificar tres niveles conceptuales en la planeacin de una organizacin (figura 1.7), que difieren en el nivel de responsabilidad identificada. el alcance de los temas y el horizonte de planeacin: Niveles de Administracin Planeacin estratgica Definicin Qu funcin desempear la organizacin y cmo ser en el futuro (5 aos)? El plan estratgico debe incluir los negocios y mercados presentes y futuros. La implementacin fsica de los planes estratgicos (1-5 aos) se refleja en los desembolsos de capital y el plan a largo plazo de personal. Asignacin de tareas a cada actividad, con el fin de Lograr los objetivos de los planes tcticos (1-12 meses). Presupuesto anual. Figura 1.7 Niveles de planificacin en una organizacin.

Planeacin Tctica (Control Administrativo) Planeacin operacional (Control operacional)

2.3 Enfoque del ciclo de vida para el desarrolla de sistemas de informacin

Los sistemas de aplicacin son altamente estructurados. La comprensin de la tarea del usuario y la experiencia del desarrollador, usualmente son altas. Estos factores sugieren una estrategia de

garanta interactiva lineal. Lo ms comn para esta clase de problemas es el modelo del ciclo de vida para el desarrollo de sistemas (figura 2.2), en el cual cada una de las etapas de desarrollo est bien definida, tiene estipulaciones directas en cuanto a los resultados intermedios, retroinformacin y cortes (o terminaciones).

Una idea bsica del ciclo de vida del desarrollo de sistemas es que hay un proceso bien definido en el cual: se percibe una aplicacin, se desarrolla y se realiza. El ciclo de vida le da estructura a un proceso creativo. Las fases en el ciclo de vida de desarrollo de un sistema proveen una base para la administracin y el control en razn de que definen los segmentos de flujo de trabajo para que se puedan identificar para propsitos

administrativos, y especificar los documentos u otras resultados intermedios que van a ser producidos en cada fase. El ciclo de desarrollo para sistemas de informacin para una aplicacin consta de tres etapas principales: Definicin. Desarrollo. Instalacin y operacin.

La primera etapa es el proceso que define los requerimientos de informacin para un sistema cuya relacin costo-efectividad es factible. En sta se obtienen los requerimientos de informacin, los cuales son traducidos al sistema fsico de formularios, procedimientos, programas, etc. mediante el diseo de sistema. El sistema resultante se prueba y se pone en operacin. Se debe tener en cuenta que ningn sistema es perfecto. De tal forma que siempre es necesario el mantenimiento de los cambios. Para completar el ciclo de vida debera saber una post-auditara del sistema, para evaluar qu tambin se desempea y qu tan bien satisface las especificaciones de costo y desempeo. Las tres etapas de definicin, desarrollo e instalacin y operacin (figura 2.3) pueden dividirse en pasos o fases ms pequeas. Al completar cada fase, se requiere la aceptacin formal por parte de los usuarios y del director de desarrollo del proyecto. Cada fase tambin debe tener como resultado una documentacin formal. Los porcentajes mostrados en la figura 2.4 dan una idea aproximada de la distribucin del esfuerzo en el ciclo de vida de desarrollo de los sistemas de

Informacin, desde la concepcin hasta que el sistema esta en operacin de manera apropiada.

Es importante destacar que sobre la terminacin de la codificacin de los programas y el comienzo de la prueba de los programas, la aplicacin estar Alrededor del 60% del total. Muchos errores en la estimacin de la fecha de terminacin del proyecto se pueden atribuir a fallas en la asignacin del tiempo adecuado para prueba de programas.

Etapas en el ciclo Definicin

Fases en el ciclo de la vida Propuesta.

Rango porcentual de esfuerzo 3-7

Determinacin de la factibilidad. Anlisis de los requerimientos de la informacin.

3 10 10 20

Desarrollo Instalacin y operacin

Diseo conceptual. Diseo fsico del sistema. Diseo fsico de la base de datos. Desarrollo de la programacin. Desarrollo de los procedimientos. Conversin. Operacin y mantenimiento. Post auditora. 10 25 37 20 40 5 15 10 20 -26

2.3.1 Etapa de definicin

Idealmente, un proyecto de desarrollo de sistemas se concibe como un componente del proceso de planeacin del sistema de informacin, pero una propuesta puede provenir de otras fuentes tales como los usuarios y el personal de procesamiento de datos. Despus de que un proyecto es propuesto, el prximo paso en la etapa de definicin es la determinacin de la factibilidad. Una vez que la alternativa propuesta est aprobada, la siguiente fase es el anlisis de los requerimientos de informacin. Al anlisis de los requerimientos le sigue una fase

de diseo conceptual, que produce un diseo de alto nivel haciendo nfasis en la aplicacin, tal como la ven los usuarios. Al finalizar la etapa de definicin se toman la mayora de las decisiones claves que influyen en el usuario. Aunque tal vez solamente un 25% del esfuerzo total se haya gastado, las decisiones importantes que conforman el resto del esfuerzo se encuentran en este lugar, por lo tanto, no debe despreciarse esta etapa si se quiere que las aplicaciones satisfagan a los usuarios. En un estudio realizado, se encontr que los proyectos que dedicaban ms tiempo a la fase de definicin (anlisis) fueron los ms exitosos. Se mejoraron tanto la satisfaccin del usuario como su capacidad para desarrollar la aplicacin dentro del presupuesto.

2.3.1.1 Definicin de la propuesta

La fase de definicin de la propuesta no es necesaria si la aplicacin fue definida como parte del planteamiento de los sistemas de informacin. De otra manera. Se puede emplear un procedimiento simple para la procura de una aplicacin. Las propuestas pueden ser para aplicaciones completamente nuevas o para mejorar aplicaciones existentes. La propuesta no debe ser corregida y es necesario un documento de una o dos paginas que ofrezca la suficiente justificacin para apoyar la decisin de proseguir con el anlisis de factibilidad. Sigue a continuacin la aprobacin de la gerencia, donde la Propuesta es revisada
por parte de la autoridad -esencial responsable por la asignacin de los recursos de

desarrollo del sistema de informacin (usuarios de la gerencia, un comit directivo o un ejecutivo del sistema de informacin).

2.3.1.2 Determinacin de la factibilidad

Cuando se propone una nueva aplicacin, normalmente se lleva a cabo el estudio de factibilidad antes de que sea aprobada para su desarrollo. Incluso si la

Aplicacin es parte del plan maestro del plan de informacin gerencial predefinido, igual debera completarse la fase de determinacin de la factibilidad, con el fin de evaluar los enfoques alternativos para su desarrollo, aunque la idea en general se haya aprobada con el resto del plan. Si una propuesta es sometida por fuera del plan, el estudio de factibilidad incluye el aspecto de si es consecuente con el plan existente y si debera forzar las prioridades de las otras aplicaciones ya planeadas. Hay cinco tipos de factibilidad, que dan por resultado el reconocimiento tanto de los beneficios como de los riesgos inherentes al desarrollo y a la implementacin del sistema de aplicacin propuesto: 1. Factibilidad tcnica: Se puede implementar la aplicacin propuesta con la tecnologa actual? El anlisis de los riesgos del proyecto con relacin a la factibilidad tcnica incluye no solamente si la tecnologa est disponible en el mercado, sino tambin "el

estado del arte-" tanto en trminos absolutos, como relativos a la sofisticacin tcnica actuar de la empresa. 2. Factibilidad econmica: Dar el sistema Beneficios mayores que los costos? El estudio de factibilidad presentan los beneficios tangibles de una manera formal. Tambin se presenta un anlisis relativamente detallado de los costos tanto para los desarrollos como para las operaciones de las diferentes alternativas. 3. Factibilidad de planeamiento: Es la probabilidad que la organizacin pueda completar el proceso oportunamente, en el tiempo permitido para su desarrollo. La adicin de recursos para el desarrollo no siempre reduce su duracin. En efecto, el aporte de personal no siempre se puede utilizar efectivamente, incluso puede impedir el desarrollo, en razn del tiempo que se gasta en la comunicacin. 4. Factibilidad motivacional: Es la probabilidad de que la organizacin est suficientemente motivada para apoyar el desarrollo e implementacin de la aplicacin con la participacin necesaria del usuario, los recursos, el tiempo de entrenamiento, etc. Usualmente, esta motivacin es demostrada por el propietario o por el defensor de la aplicacin, quien tiene suficiente poder en la organizacin para proveer los recursos y motivar a otros a ayudar y cooperar. 5. Factibilidad operacional: Trabajar bien el sistema cuando se instale? Este anlisis puede implicar una determinacin subjetiva del medio ambiente poltico y administrativo en el cual se realizar el sistema. En general, mientras mayores sean los requerimientos de cambio en el medio ambiente del usuario en que se instalar el sistema, mayores sern los riesgos de fracaso de su implementacin. El estudio de factibilidad se puede conformar de diferentes formas, tales como: 1. Grupo de evaluacin con representantes de los usuarios, de los sistemas de informacin y de otros grupos afectados por el sistema. La jefatura de grupo de e1 estudio puede ocupara un usuario o un representante de los sistemas de informacin. 2. Persona o grupo de evaluacin proveniente de los sistemas de Informacin. 3. Persona o grupo de evaluacin proveniente de los usuarios.

Cada una de las alternativas tiene ventajas y desventajas. y la seleccin del cuadro personal para la evaluacin puede depender del tipo de proyecto y de la cultura organizaciones con respecto a la responsabilidad. Por ejemplo, un grupo de evaluacin con muchos representantes tendr ventajas cuando la aplicacin produzca un impacto significativo en varios grupos o en las operaciones fundamentales de la organizacin. El informe de factibilidad cubre elementos tales como los siguientes: Descripcin general de la aplicacin Desarrollo esperado del calendario (planeamiento) Calendario de los recursos y presupuestos requeridos para el desarrollo. Calendario de los costos esperados y de los beneficios de las operaciones (factibilidad econmica). Resumen de la evaluacin con respecto a la factibilidad tcnica, motivacional, de

programacin y operacional Si el estudio de factibilidad incluye varias alternativas, el informa debera presentar el presupuesto, los beneficios esperados, los recursos requeridos en el calendario, etc., para cada una (incluyendo la alternativa de no hacer nada"). La seleccin est basada sobre la factibilidad relativa de cada una de las alternativas. El informe de factibilidad es revisado por la administracin de los sistemas de informacin y por el departamento que hace la solicitud. Una vez que el estudio de factibilidad se haya aceptado y sea aprobada una alternativa., se puede iniciar el anlisis de los requerimientos de informacin.

2.3.1.3 Anlisis de los requerimientos de informacin

Con el fin de obtener de manera efectiva un conjunto completo y correcto o de los requerimientos, es necesario utilizar uno o varios mtodos que tengan en cuenta hasta qu punto los requerimientos son conocidos, o por el contrario. Estn necesitando ser explorados o descubiertos. El resultado del anlisis de los requerimientos de informacin es un reporte que detalla los requerimientos de la aplicacin. Los requerimientos constan de elementos tales como los siguientes: Informes (incluye los datos elementales en los reportes) Consultas (tanto regulares como ad-hoc)

Esquema conceptual de la base de datos (a partir del modelamiento de los datos u otros anlisis) Requerimientos funcionales (incluyendo las caractersticas racionales) Requerimientos de interfaz del usuario

2.3.1.4 Diseo conceptual a diseo lgico En la definicin de la propuesta, se especificaron algunas necesidades del usuario. En la fase de anlisis de factibilidad, se identificaron requerimientos adicionales y se evaluaron algunas alternativas bastantes generales de diseo. La fase de anlisis de requerimientos de informacin produjo y document un conjunto ms detallado de los requerimientos. La fase de diseo conceptual establece un diseo ms completo orientado al usuario de la aplicacin. Es til dividir el diseo de la aplicacin en la fase de diseo conceptual y la fase de diseo fsico. Estas dos fases pueden tambin caracterizarse como diseo externo y diseo interno o diseo general y diseo detallado. El diseo conceptual hace nfasis en la aplicacin tal como es vista por quienes la operaran o utilizaron los resultados del sistema. El diseo fsico traduce aquellos requerimientos en especificaciones para la implementacin (realizacin) del sistema. El diseo conceptual establece las funciones de entrada y salida que ejecutar la aplicacin y la realizacin de auditora y controles. En trminos generales, el diseo conceptual trata las funciones reales de procesamiento como 'cajas negras. El diseo fsico especifica el procesamiento real dado el diseo conceptual. El diseo conceptual frente al diseo fsico, en el desarrollo de aplicaciones. son aproximadamente anlogos al modelo conceptual frente al modelo fsico en el desarrollo de base de datos. Los contenidos tpicos de un informe de diseo conceptual son los siguientes: Descripcin de la aplicacin orientada al usuario. Documentar el flujo de las actividades de la aplicacin de las unidades organizacionales que suministran

Las entradas y el uso de las salidas. Distingue las operaciones manuales de las operaciones automatizadas que ejecute el sistema aplicativo. Las entradas de la aplicacin con descripciones generales de cada una (pantalla de despliegue visual, documentos fuente, formularios, consultas, etc.). Resultados producidos por la aplicacin, la descripcin general de cada uno (pantalla de despliegue visual, respuestas a las consultas, salidas y comunicaciones impresas, etc.).

Las funciones que van a ser desempeadas por el sistema de aplicacin. Flujo general de procesamiento con relaciones a los programas principales, archivos, entradas y salidas.

Esquema de los manuales operacionales. manuales del usuario y materiales de entrenamiento necesarios para la aplicacin.

Procesos de auditora y control de procedimientos para asegurar la calidad en el uso y operacin de la aplicacin.

2.3.2 Etapa de desarrollo

La etapa de desarrollo del ciclo de vida se compone de cuatro clases de actividades, las cuales pueden darse, en alguna medida, de manera concurrente: el diseo fsico del sistema, el diseo fsico de la base de datos, el desarrollo de programas y el desarrollo de procedimientos.

2.3.2.1 Diseo fsico del sistema

La fase de diseo fsico del sistema, tambin llamado diseo interno o diseo detallado, consiste en actividades para preparar el diseo tcnico detallado de sistemas de aplicacin. El diseo fsico del sistema est basado en los requerimientos de informacin y el diseo conceptual. A la vez proporciona la base para el diseo fsico de la base de datos; el desarrollo de programas y el desarrollo de procedimientos. Los resultados de la fase de diseo del sistema fsico son las especificaciones y los diseo para lo siguiente: Diseo de sistema fsico que muestra el flujo de trabajo, los programas y las funciones del usuario. El diseo de control muestra los controles que se van a implementar en varios puntos en el flujo de procesamiento. Especificaciones de equipo (hardware) para las aplicaciones si se requiere equipo nuevo. Estructura global de los programas requeridos por la aplicacin, con la especificacin de los requerimientos. en relacin con las funciones que sern desempeadas por cada programa. Seguridad y medidas de respaldo. Una prueba de la aplicacin o el plan para la garanta de calidad del resto del desarrollo.

El trabajo de diseo fsico del sistema se lleva a cabo por analistas de sistemas y otro personal tcnico (como los especialistas en control, el personal de garanta de calidad, los especialistas en comunicacin de datos, etc.). Los usuarios pueden participar en esta fase, pero muchos de los trabajos requieren expertos en procesamiento de datos en lugar de expertos en las funciones del usuario. El trabajo de la fase de diseo del sistema fsico consiste en tomar un nivel bastante alto de requerimientos orientados a los usuarios, en la fase de diseo conceptual, y producir un diseo tcnico especfico. Este proceso es el que generalmente se defini como "caja negra", produciendo las salidas requeridas a partir de las entradas definidas en el diseo conceptual. Existe cierto nmero de mtodos diferentes que un analista puede emplear, los cuales ayudan a reducir la complejidad y el costo de desarrolla de los sistemas aplicativos y mejorar la confiabilidad y modificabilidad de los diseos. Generalmente, las tcnicas de diseo del sistema fsico alcanzan la simplicidad subdividiendo el sistema de aplicacin en pequeos mdulos. Los mdulos del sistema pueden ser programas o procedimientos que son subsecciones de los programas. La complejidad del sistema se reduce en razn de que cada mdulo se puede desarrollar. codificar y probar en forma relativamente independiente de los otros. La confiabilidad y la modificabilidad se mejoran porque un cambio (ya sea un cambio en las especificaciones, una mejora o una reparacin) puede hacerse al mdulo del sistema con efectos mnimos y bien entendidos sobre el resto del sistema. Algunas tcnicas disponibles para el diseo lgico y diseo fsico de un sistema se resumen en la figura 2.5.

Tcnica

Descripcin

Diseo Descendente Una unidad de procesamiento (sistema, programa, mdulo) se defina en trminos muy general, luego se parte en refinamientos cada vez ms pequeos. El diseo se representa como un diagrama jerrquico (figura 2.6). El programa resultante tambin tiene una jerarqua estructurada. DISEO FSICO

Anlisis estructurado

Cada subsistema se defina mediante la funcin especfica que realiza. El nfasis est en el desacoplamiento o en la minimizacin de integracin entre ellos. Cada subsistema es altamente cohesivo, lo que significa que todos los elementos en su interior estn relacionados funcionalmente. La transformacin de los datos se representa mediante el diagrama de flujo de datos (figura2.7). DISEO LGICO

Figura 2.5 Tcnicas de diseo (diseo conceptual y diseo fsico

2.3.2.2 Diseo fsico de la base de datos El enfoque para disear la base de datos fsica para una aplicacin depende de la base de datos actual y del enfoque que se siga para la determinacin de los requerimientos de la base de datos. Hay tres enfoques principales para alcanzar los requerimientos de los datos dentro de una aplicacin. 1. Crear un nuevo archivo fsico o base de datos: Esto es apropiado si ninguna base de datos se utiliza o ninguna base de datos est dedicada a la aplicacin. Se deben exigir nuevos datos y se debe disear y crear el archivo o la base de datos a partir de los datos recolectados especficamente para la aplicacin.

2.22 2. Uso y modificacin de la actual base de datos: Este mtodo es apropiado si se sigue una estrategia evolutiva para el desarrollo de la base de datos. Puede requerir funciones especiales designadas por el administrador de la base de datos, tanto para reestructurar la base de datos existente como tambin para agregar los datos necesarios. 3. Acceso a una base de datos actual por medio de un esquema del usuario: Este mtodo es posible si un modelo conceptual completo de una empresa, se utiliz como

base para el diseo de la base de datos fsica, anticipando las necesidades de las nuevas aplicaciones. La tercera alternativa supone que un modelo de datos completo de la empresa anticipar mayores requerimientos de la aplicacin. La segunda alternativa es ms probable si se sigui el enfoque del modelamiento de datos para la definicin de la base de datos. Afortunadamente, una de las ventajas de los sistemas de administracin de la base de datos es que es que sta se puede reestructurar para acomodar los requerimientos evolutivos de la aplicacin.

2.3.2.3 Desarrollo de programas

Una salida principal del proceso de diseo fsico es un conjunto de especificaciones de las tareas de programacin. La meta de la fase de desarrollo de programas es codificar y probar los programas que requiere la aplicacin. Los problemas que se encuentran durante la fase de programacin son tpicamente un resultado de la ausencia de especificaciones completas suministradas durante el diseo conceptual o fsico. Otro problema en esta fase es la prueba inadecuada de programas con anterioridad a la prueba del sistema y a la conversin. Algunas tcnicas de desarrollo de programacin reducen la complejidad de la programacin y ayudan en la correccin de los programas que se estn ejecutando. Ejemplos importantes son la modularidad, la programacin estructurada, los generadores de aplicaciones y los paquetes de aplicaciones hechos a la medida. El concepto de modularidad se entiende como la prctica de subdividir un programa en pequeos mdulos relativamente bien definidos. Ayuda a reducir la complejidad en los programas y mejora la confiabilidad y la modificabilidad. En la programacin estructurada, un conjunto pequeo de estructuras bsicas de codificacin se utiliza para todos los programas y, generalmente, da por resultado programas que son dirigidos dentro del flujo de lgica. La programacin estructurada est relacionada con la modularidad, ya que el uso de las estructuras de codificacin asegura mdulos bien definidos. El uso correcto de las estructuras de codificacin se traduce en

cdigos que no requieren GO-TO. Las tres estructuras de codificacin principales de la programacin estructurada se ilustran en la figura 2.8. La prueba representa un factor crtico para el desarrollo de la aplicacin. Puede gastar entre el 15% y el 50% del esfuerzo de desarrollo total, de acuerdo al tamao y a la complejidad de la aplicacin. Hay tres fases en la prueba de programas. Secuencia A Selecci Repetici Prueba de la condicin Verdader

Prueba de la condicin

B Falso C D E

Figura 2.8 Estructura bsica para la programacin estructurado.

1. Prueba del mdulo: Cada mdulo del programa se prueba usando rutinas artificiales (o procedimientos) para llamar a otros mdulos. 2. Prueba de integracin: Grupos de mdulos de programas que se prueban conjuntamente para determinar si la interfaz es adecuada. Esto se puede dar de manera incrementar, a medida que se desarrollan hasta que sea aprobado el sistema completo.

3. Prueba del sistema: Esto implica la prueba de un conjunto completo d programas de aplicacin. Existe un debate sobre qu es lo que constituye una prueba de programas correcta o adecuada. Algunos errores se revelan solamente despus de que el sistema est en produccin. Los criterios para la programacin correcta varan ampliamente y tienden a estar relacionados con el mtodo de generacin de datos de prueba.

Es til distinguir entre confiabilidad y grado de correccin de programas. Un programa correcto satisface las especificaciones: un programa confiable opera de una manera aceptable bajo entrada de datos determinados y no determinados. Un enfoque alternativo al desarrollo de la aplicacin, con un alto potencial de resultados en productividad, es la adquisicin de paquetes generalizados de software y modificarlos para que satisfagan las necesidades especiales de la organizacin. Hay dos enfoques alternativos para utilizar los paquetes de software generalizado de aplicaciones: 1. Adaptar la organizacin al paquete: Los procedimientos de software de aplicaciones estn fijados y los procedimientos de operacin de las organizaciones se modifican para concordar con el software. Esta alternativa puede ser deseable para una organizacin con complicaciones donde no hay requerimientos organizacionales nicos y significativos donde el entrenamiento interno es menos costoso que la modificacin del software. Otra

situacin es cuando los lmites en los costos de urgencia de implementar el sistema, deja fuera los beneficios que se pueden obtener solamente con demora y costos extras asociados al desarrollo de aplicaciones nicas. Las empresas pequeas, por ejemplo, pueden muchas veces permitirse el costo de conformarse y adecuarse a un paquete, pero no el costo de desarrollarlo individualmente. 2. Adaptar el paquete a las necesidades organizacionales : Las tendencias recientes, aceptadas por los vendedores de software y por los compradores, ha sido suministrar paquetes que se puedan modificar de manera fcil en razn de su diseo modular, para adecuarse a los requerimientos organizacionales individuales. El incremento en el costo de desarrollo de software con relacin a los paquetes, justifica el costo de adquisicin para modificarlo. Cuando se elige la alternativa de adquirir paquetes de software en usar de desarrollarlos dentro de la empresa. es importante tener corrcietas las especificaciones exactas del diseo del sistema.

2.3.2.4 Desarrollo de procedimientos

El desarrollo de procedimientos (manuales, hojas de instruccin. formatos de entrada, ayudas HELP por pantalla, etc.) se puede realizar de manera concurrente, con los desarrollos de la programacin. Los procedimientos deben escribirse para todo el personal que tenga contacto con el sistema. Este incluye lo siguiente: Usuarios primarios: Esto incluye las instrucciones sobre cmo interpretar un informe, cmo seleccionar las diferentes opciones para un informe, etc. Si el usuario puede interactuar con el sistema en forma directa, como consultas en lnea, incluye las instrucciones detalladas para el acceso al sistema y la formulacin de diferentes tipos de consultas. 2. Usuarios secundarios: Esto incluye las instrucciones detalladas de cmo ingresar cada clase de entrada. Est ms orientada hacia "cmo hacer" y menos a "qu es lo que se hace" para diferentes entradas. 3. Personal para la operacin del computador: Existen procedimientos de mantenimiento que, en general, son ejecutados por los operadores del computador y/o personal de control. Los procedimientos incluyen la elaboracin de sistemas de archivos de respaldo, el mantenimiento de la documentacin del programa, etc. 4. Procedimientos de capacitacin: En algunos casos, durante la etapa de implementacin y en la subsiguiente etapa de entrenamiento, se desarrolla un manual de entrenamiento de salida por pantalla. Uno de los dos grupos puede tener la responsabilidad de escribir los procedimientos: los anlisis o los usuarios. las ventajas de los procedimientos escritos por el analista son la precisin el control del proyectos sobre la terminacin y la confirmacin de la documentacin global. Sus desventajas son la tendencia del analista a escribir en la jerga tcnica o con abreviaturas tcnicas y suponer que los usuarios tienen el conocimiento del ambiente tecnolgico. Las ventajas de que los procedimientos sean escritos por los usuarios, son el nivel apropiado de descripcin tcnica e instrucciones que son comprensibles. Sus desventajas son la de asegurar que las instrucciones sean Completas y claras. Una estrategia combinada, es aquella en que el analista y el usuario trabajan en mutua colaboracin para producir un manual tcnicamente correcto y comprensible. Un manual de procedimientos efectivo, es aquel que comunica bien y que se puede referenciar fcilmente, debe estar bien diseado. Y es importante que stos se conserven actualizados para coincidir con los cambios al sistema de informacin. En la figura 2.9 se muestran algunos ejemplos

2.27

La tcnica ms usada en la representacin de los procedimientos es el grfico narrativo (figura 2.10). Consiste en un diagrama cae columnas, cada uno de los cuales representa una unidad organizacional de la empresa y seala adems los documentos que se intercambian entre las diferentes opciones.

2.3.3 Etapa de instalacin y operacin La tercera etapa del ciclo de vida de desarrollo de un sistema de informacin, comienza con la conversin al nuevo sistema de aplicacin. El resto del ciclo de vida de desarrollo del sistema se refiere a la actividad del sistema en USO. Peridicamente, se practica una post-auditora del sistema. Producto de esta actividad, el sistema se puede modificar, mejorar o reemplazar.

2.3.3.1 Conversin

La conversin al nuevo sistema de aplicacin, comienza despus de que todos los programas y los procedimientos se han preparado y probado individualmente. Se alistan tres actividades principales para la conversin verdadera: prueba de aceptacin, construccin de archivos y la capacitacin del usuario.

1. La prueba de aceptacin: Es la prueba de terminacin de la aplicacin y la comparacin con las especificaciones. Se identifican las diferencias entre lo que esperaban los usuarios y lo que el sistema entrega, y se solucionan. 2. La construccin de archivos: Se refiere a la coleccin y conversin en formatos legibles por la mquina, de todos los datos nuevos que exige la aplicacin. Se puede emplear programas para conversin de archivos ad-hoc. Se debera disponer de suficiente tiempo y recursos humanos para limpiar los datos, esto es, eliminar las inexactitudes y las inconsistencias y lograr que los datos estn completos. 3. El entrenamiento o capacitacin del usuario: Puede ser un esfuerzo relativamente directo o crtico, de acuerdo al grado en que el nuevo sistema aplicativo influya en los trabajos existentes. El entrenamiento del usuario, es un factor importante para vencer su resistencia al nuevo sistema. La conversin del antiguo sistema al nuevo, tiene lugar despus de que haya terminado la prueba de aceptacin, la construccin de archivos y el entrenamiento del usuario. La conversin se puede cumplir de varias formas. El mtodo ms cuidadoso es correr en paralelo el antiguo y nuevo sistema. El nuevo sistema se corre bajo las condiciones actuales y los resultados se comparan con los del sistema antiguo, en cuanto a confiabilidad y exactitud. Despus de que el nuevo sistema ha sealado resultados consistentes durante un perodo razonable de tiempo, se deja en operacin

definitivamente y el viejo sistema se da de baja. La desventaja de este mtodo es que es costoso, tanto las mquinas como los empleados trabajan el doble del tiempo. Si el procesamiento paralelo de los sistemas nuevos y antiguos no es factible, el nuevo sistema se debera probar bajo condiciones simuladas de un volumen completo. Con frecuencia esto se denomina "la quemazn de los puentes", en razn de que usualmente es imposible regresar a las operaciones del sistema antiguo una vez que se haya cortado con l. Los problemas con el nuevo sistema son corregidos por la "fuerza bruta", ya que no hay alternativa disponible. La conversin debera hacerse en forma gradual, slo una parte del sistema a la vez.

2.3.3.2 Operacin y mantenimiento La incorporacin del nuevo sistema trae consigo un vuelco en el procesamiento de la informacin. el que, Tiene que ser aprobado no slo por el usuario, sino tambin por el grupo del sistema operacional y el grupo de mantenimiento. Estos ltimos deberan avalar que el sistema cumple con las normas de documentacin y mantenimiento necesarias. Los cambios posteriores en la aplicacin son manejados por mantenimiento. El mantenimiento de una aplicacin se puede clasificar como reparaciones y mejoras. Reparaciones: Son necesarias cuando la aplicacin es defectuosa por codificacin incompleta e incorrecta. Las reparaciones dominan la actividad de mantenimiento durante los primeros meses de operacin.

Mejoras: Son ampliaciones o adiciones que se van requiriendo. Despus que se ha pasado la etapa de reparacin, las mejoras dominan la actividad de mantencin.

Por ltimo, cabe destacar que algunas veces el mantenimiento es hecho por los mismos desarrolladores del sistema, pero muchas otras veces se opta por un grupo de mantenimiento aparte para que asuma tal responsabilidad.

2.3.3.3 Post-Auditora Una parte deseable del cielo de vida de desarrollo de un sistema es una revisin de la aplicacin despus de un perodo de operacin. El equipo de auditora debera estar compuesto por representante de los usuarios, del grupo de desarrollo, del grupo de mantenimiento y del grupo de operaciones. Este equipo revisa la operacin, el uso, los costos y los beneficios de la aplicacin.