Los nuevos sistemas de información son el fruto de un proceso de solución de problemas organizacionales. Se crea un nuevo sistema de información como solución para cierto tipo de problema o conjunto de problemas que la organización percibe y a los que debe hacer frente. El problema puede ser por ejemplo que los gerentes y empleados se den cuenta de que la organización no se desempeña tan bien como se esperaba, o que debería aprovechar las nuevas oportunidades para trabajar de una manera más exitosa.
En este foro encontrarás lo siguiente:
Análisis de sistemas.
Diseño de sistemas.
Comprensión del proceso de desarrollo de sistemas.
Modelado y diseño de sistemas: las metodologías estructuradas y orientada a objetos.
Las actividades que contribuyen para producir una solución de sistema de información para un problema u oportunidad organizacional se denominan desarrollo de sistemas. El cual es un tipo estructurado de problema que se resuelve con distintas actividades, que consisten en análisis de sistemas, diseño de sistemas, programación, prueba, conversión, además de producción y mantenimiento.
La siguiente figura ilustra el proceso de desarrollo de sistemas. Las actividades de desarrollo de sistemas que se describen se realizan por lo general en orden secuencial. Sin embargo, tal vez haya que repetir algunas de las actividades, o quizás otras se realicen al mismo tiempo, dependiendo de la metodología de creación de sistemas que se emplee.
ANÁLISIS DE SISTEMAS.
El análisis de sistemas es el análisis de un problema que una firma trata de resolver mediante un sistema de información. Consiste en definir el problema, identificar sus causas, especificar la solución e identificar los requerimientos de información que debe cumplir una solución de sistemas.
El analista de sistemas crea un mapa de la organización y los sistemas existentes, en el cual se identifica a los propietarios y usuarios principales de los datos, junto con el hardware y software existente. Después el analista de sistemas detalla los problemas de los sistemas existentes. Al examinar los documentos, papeles y procedimientos, observar las operaciones del sistema y entrevistar a los usuarios clave de los sistemas, el analista puede identificar las áreas problemáticas y los objetivos que lograría una solución.
A menudo es necesario crear un nuevo sistema de información o mejorar uno existente. El análisis de sistemas también ofrece un estudio de viabilidad para determinar si esa solución es viable, o si se puede alcanzar desde un punto de vista financiero, técnico y organizacional. El estudio de viabilidad determina si se espera que el sistema propuesto sea una buena inversión, si está disponible la tecnología necesaria para el sistema, si los especialistas en sistemas de información de la firma pueden operarlo, y si la organización puede manejar los cambios introducidos por el sistema.
Por lo general, el proceso de análisis de sistemas identifica varias soluciones alternativas para la organización y evalúa la viabilidad de cada una de ellas. Un informe de propuesta de sistemas por escrito describe los costos y beneficios, además de las ventajas y desventajas, de cada alternativa. Es responsabilidad de la gerencia determinar qué mezcla de costos, beneficios, características técnicas e impactos organizacionales representa la alternativa más deseable.
Establecimiento de los requerimientos de información.
Tal vez la tarea más desafiante del analista de sistemas sea definir los requerimientos específicos de información que debe cumplir la solución del sistema seleccionado. En el nivel más básico, los requerimientos de información de un nuevo sistema implican identificar quién necesita qué información, en dónde, cuándo y cómo. El análisis de los requerimientos describe con cuidado los objetivos del sistema nuevo o modificado y desarrolla una descripción detallada de las funciones que debe realizar el nuevo sistema.
Un análisis de requerimientos mal realizado es una de las principales causas de fallas en el sistema y de los costos elevados en el desarrollo de sistemas.
Un sistema diseñado con base en el conjunto incorrecto de requerimientos se tendrá que descartar debido al mal desempeño, o tendrá que sufrir modificaciones considerables. Algunos problemas no requieren una solución de sistema de información, sino que necesitan un ajuste en la administración, una capacitación adicional o el refinamiento de los procedimientos organizacionales existentes. Si el problema está relacionado con la información, tal vez aún sea necesario realizar un análisis de sistemas para diagnosticar el problema y llegar a la solución apropiada.
DISEÑO DE SISTEMAS.
El análisis de sistemas describe lo que debería hacer un sistema para cumplir con los requerimientos de información, y el diseño de sistemas muestra cómo cumplirá con este objetivo.
El diseño de un sistema de información es el plan o modelo general para ese sistema. Al igual que el plano de construcción de un edificio o una casa, consiste en todas las especificaciones que dan al sistema su forma y estructura.
El diseñador de sistemas detalla las especificaciones del sistema que ofrecerán las funciones que se identificaron durante el análisis de sistemas. Estas especificaciones deben lidiar con todos los componentes administrativos, organizacionales y tecnológicos de la solución del sistema. La siguiente tabla lista los tipos de especificaciones que se producen durante el diseño de sistemas.
Al igual que las casas o los edificios, los sistemas de información pueden tener muchos posibles diseños. Cada diseño representa una mezcla única de todos los componentes técnicos y organizacionales. Lo que hace que un diseño sea superior a los otros es la facilidad y eficiencia con la que cumple los requerimientos del usuario dentro de un conjunto específico de restricciones técnicas, organizacionales, financieras y de tiempo.
La función de los usuarios finales.
Los requerimientos de información de los usuarios controlan todo el esfuerzo de creación del sistema. Los usuarios deben tener el suficiente control sobre el proceso de diseño para asegurar que el sistema refleje sus prioridades de negocios y sus necesidades de información, no las predisposiciones del personal técnico. Al trabajar en el diseño aumenta la comprensión y aceptación de los usuarios para con el sistema.
El hecho de que el usuario no participe lo suficiente en el esfuerzo de diseño es una de las principales causas de que fallen los sistemas. Sin embargo, algunos sistemas requieren más participación de los usuarios que otros.
COMPRESIÓN DEL PROCESO DE DESARROLLO DE SISTEMAS.
El resto de las etapas en el proceso de desarrollo de sistemas traducen las especificaciones de la solución que se establecieron durante el análisis y el diseño de sistemas en un sistema de información completo y operacional. Estas etapas concluyentes consisten en: programación, prueba, conversión, producción y mantenimiento.
Programación.
Durante la etapa de programación, las especificaciones del sistema que se prepararon durante la etapa de diseño se traducen en código de programa de software. En la actualidad, muchas organizaciones ya no necesitan encargarse de su propia programación para los nuevos sistemas. En cambio, compran el software que cumple con los requerimientos de un nuevo sistema a través de fuentes externas, como los paquetes de software de un distribuidor de software comercial, los servicios de software de un proveedor de servicios de aplicación o subcontratan firmas que desarrollan software de aplicación personalizado para sus clientes.
Prueba.
Se debe realizar una prueba exhaustiva y detallada para determinar si el sistema produce o no los resultados correctos. La prueba responde a la pregunta: ¿Producirá el sistema los resultados deseados bajo condiciones conocidas?. Algunas compañías están empezando a usar servicios de computación en la nube para este trabajo.
En la planificación de proyectos de sistemas, es una tradición subestimar la cantidad de tiempo necesaria para responder a esta pregunta. El proceso de prueba consume tiempo: hay que preparar con cuidado los datos de prueba, revisar los resultados y hacer las correcciones en el sistema. En algunos casos, tal vez sea necesario rediseñar partes del sistema. Si se pasa por alto esta etapa los riesgos resultantes son enormes.
Podemos dividir la prueba de un sistema de información en tres tipos de actividades: prueba de unidad, prueba de sistema y prueba de aceptación.
La prueba de unidad, o prueba de programa, consiste en probar cada programa por separado en el sistema. Una creencia popular es que el propósito de dicha prueba es garantizar que los programas estén libres de errores, pero en realidad esta meta es imposible. Debemos ver la prueba como un medio de localizar errores en los programas y enfocarnos en encontrar todas las formas para hacer que falle un programa. Una vez señalados, los problemas se pueden corregir.
La prueba de sistema evalúa el funcionamiento del sistema de información como un todo. Trata de determinar si los módulos discretos funcionarán en conjunto según lo planeado, y si existen discrepancias entre la forma en que funciona el sistema en realidad y la manera en que se concibió. Entre las áreas a examinar están el tiempo de desempeño, la capacidad de almacenamiento de archivos y el manejo de cargas pico, las capacidades de recuperación y reinicio, y los procedimientos manuales.
La prueba de aceptación provee la certificación final de que el sistema está listo para usarse en un entorno de producción. Los usuarios evalúan las pruebas de sistemas y la gerencia las revisa. Cuando todas las partes están satisfechas de que el nuevo sistema cumple con sus estándares, se acepta de manera formal para su instalación.
El equipo de desarrollo de sistemas trabaja con los usuarios para idear un plan de prueba sistemático. El plan de prueba abarca todas las preparaciones para la serie de pruebas que acabamos de describir.
La siguiente figura muestra un ejemplo de un plan de prueba. La condición general a evaluar es un cambio de registro. La documentación consiste en una serie de pantallas del plan de prueba que se mantienen en una base de datos (tal vez una base de datos en una PC), la cual se adapta de manera ideal a este tipo de aplicación.
La conversión es el proceso de cambiar del sistema anterior al nuevo. Se pueden emplear cuatro estrategias principales de conversión: la estrategia paralela, la estrategia de reemplazo directo, la estrategia de estudio piloto y la estrategia de metodología en fases.
En una estrategia paralela, tanto el sistema anterior como su reemplazo potencial se operan en conjunto durante un tiempo, hasta que todos estén seguros de que el nuevo funciona de manera correcta. Ésta es la metodología de conversión más segura ya que, en caso de errores o interrupciones en el procesamiento, todavía es posible usar el sistema anterior como respaldo. Sin embargo, esta metodología es muy costosa y tal vez se requieran personal o recursos adicionales para operar el sistema adicional.
En la estrategia de reemplazo directo se sustituye el sistema anterior en su totalidad con el nuevo, en un día programado con anterioridad. Es una metodología muy riesgosa que puede llegar a ser más costosa que operar dos sistemas en paralelo, en caso de que se encuentren problemas graves en el nuevo sistema. Aquí no hay otro sistema de respaldo. El costo de los traslados, las interrupciones y de las correcciones puede llegar a ser enorme.
La estrategia de estudio piloto introduce el nuevo sistema a sólo un área limitada de la organización, como un solo departamento o una sola unidad operacional. Cuando esta versión piloto está completa y trabaja de manera uniforme, se instala en el resto de la organización, ya sea de manera simultánea o en etapas.
La estrategia de metodología en fases introduce el nuevo sistema en etapas, ya sea con base en las funciones o las unidades organizacionales.
Por ejemplo, si el sistema se introduce con base en la función, un nuevo sistema de nómina podría empezar con trabajadores por horas que reciban un pago semanal, para seis meses después agregar empleados asalariados (que reciben pago mensual) al sistema. Si éste se introduce con base en la unidad organizacional, podrían convertirse primero las oficinas corporativas, seguidas de las unidades de operación periféricas cuatro meses después.
Para cambiar de un sistema antiguo a uno nuevo es necesario capacitar a los usuarios finales para que utilicen el nuevo sistema. La documentación detallada que muestre cómo funciona el sistema, desde un punto de vista tanto técnico como para el usuario final, se completa durante el tiempo de conversión para usarla en las operaciones diarias y en la capacitación.
La falta de capacitación y documentación adecuadas contribuye a que el sistema fracase, por lo que esta parte del proceso de desarrollo de sistemas es muy importante.
Producción y mantenimiento.
Una vez que se instala el nuevo sistema y se completa el proceso de conversión, se dice que está en producción. Durante esta etapa, tanto los usuarios como los especialistas técnicos usarán el sistema para determinar qué tan bien ha cumplido con sus objetivos originales, y para decidir si hay que hacer alguna revisión o modificación. En ciertos casos, se prepara un documento formal de auditoría posimplementación. Una vez que el sistema se pone a punto, hay que darle mantenimiento mientras está en producción para corregir errores, cumplir con los requerimientos o mejorar la eficiencia del procesamiento. Los cambios en hardware, software, en la documentación o los procedimientos de un sistema en producción para corregir errores, cumplir con los nuevos requerimientos o mejorar la eficiencia del procesamiento se denominan mantenimiento.
Cerca del 20 por ciento del tiempo dedicado al mantenimiento se utiliza para depurar o corregir problemas de emergencia en producción. Otro 20 por ciento trata con los cambios en los datos, archivos, informes, hardware o software del sistema. Sin embargo, el 60 por ciento de todo el trabajo de mantenimiento consiste en realizar mejoras para los usuarios, mejorar la documentación y volver a codificar los componentes del sistema para obtener una mayor eficiencia en el procesamiento. La cantidad de trabajo en la tercera categoría de los problemas de mantenimiento se podría reducir de manera considerable por medio de mejores prácticas de análisis y diseño de sistemas. La siguiente tabla sintetiza las actividades de desarrollo de sistemas.
MODELADO Y DISEÑO DE SISTEMAS: LAS METODOLOGÍAS ESTRUCTURADAS Y ORIENTADAS A OBJETOS.
Existen metodologías alternativas para modelar y diseñar sistemas. Las metodologías estructuradas y el desarrollo orientado a objeto son las más prominentes.
Metodologías estructuradas.
Las metodologías estructuradas se utilizan para documentar, analizar y diseñar sistemas de información desde la década de 1970. Estructurado se refiere al hecho de que las técnicas son paso a paso, en donde cada movimiento se basa en el anterior. Las metodologías estructuradas son arriba-abajo; progresan desde el nivel más alto y abstracto hasta el nivel más bajo de detalle: de lo general a lo específico.
Los métodos de desarrollo estructurado son orientados al proceso; su enfoque primordial es en modelar los procesos, o las acciones que capturan, almacenan, manipulan y distribuyen datos a medida que éstos fluyen a través de un sistema. Estos métodos separan los datos de los procesos. Hay que escribir un procedimiento de programación separado cada vez que alguien desea realizar una acción sobre una pieza específica de datos. Los procedimientos actúan sobre los datos que el programa les transfiere.
La principal herramienta para representar los procesos componentes de un sistema y el flujo de datos entre ellos es el diagrama de flujo de datos (DFD). El cual ofrece un modelo gráfico lógico del flujo de la información, ya que particiona un sistema en módulos que muestran niveles de detalle manejables. Especifica de manera rigurosa los procesos o transformaciones que ocurren dentro de cada módulo y las interfaces que exIsten entre ellos.
La siguiente figura muestra un diagrama de flujo de datos simple para un sistema de registro de cursos universitarios por correo. Las cajas redondeadas representan procesos, los cuales describen la transformación de los datos. El cuadro representa una entidad externa: un originador o receptor de información ubicado fuera de los límites del sistema que se va a modelar. Los rectángulos abiertos representan almacenes de datos, que son inventarios manuales o automatizados de los datos. Las flechas representan flujos de datos, que muestran el movimiento entre los procesos, las entidades externas y los almacenes de datos. Contienen paquetes de datos con el nombre o contenido de cada flujo de datos que se menciona a un lado de la flecha.
Este diagrama de flujo de datos muestra que los estudiantes envían formularios de registro con su nombre, número de identificación y los números de los cursos que desean tomar. En el proceso 1.0, el sistema verifica que cada curso seleccionado esté todavía abierto, para lo cual revisa el archivo de cursos de la universidad. El archivo distingue los cursos abiertos de los que se cancelaron o están llenos. Así, el proceso 1.0 determina cuál de las selecciones del estudiante se puede aceptar o rechazar. El proceso 2.0 inscribe al estudiante en los cursos en que fue aceptado. Actualiza el archivo de cursos de la universidad con el nombre del estudiante y su número de identificación, y vuelve a calcular el tamaño de la clase. Si se llegó al máximo número de inscripciones, el número de ese curso se marca como cerrado. El proceso 2.0 también actualiza el archivo maestro de estudiantes de la universidad con la información sobre los nuevos alumnos o los cambios de dirección. Después, el proceso 3.0 envía a cada estudiante candidato una carta de confirmación-de-registro con una lista de los cursos en los que se registró, en donde también indica los cursos en los que no se pudo completar el registro.
Los diagramas se pueden utilizar para describir procesos de nivel superior, así como los detalles de nivel inferior. Por medio de los diagramas de flujo de datos nivelados, es posible descomponer un proceso complejo en niveles sucesivos de detalle. Se puede dividir todo un sistema en subsistemas con un diagrama de flujo de datos de alto nivel. Cada subsistema a su vez se puede dividir en subsistemas adicionales con diagramas de flujo de datos de segundo nivel, y los subsistemas de nivel inferior se pueden dividir otra vez hasta llegar al nivel más bajo de detalle.
Otra herramienta para el análisis estructurado es el diccionario de datos, que contiene información sobre piezas individuales y agrupamientos de datos dentro de un sistema.
El diccionario de datos define el contenido de los flujos de datos y los almacenes de éstos, de modo que los constructores de sistemas comprendan con exactitud qué piezas contienen. Las especificaciones del proceso describen la transformación que ocurre dentro del nivel más bajo de los diagramas de flujo de datos. Expresan la lógica para cada proceso.
En la metodología estructurada, el diseño del software se modela mediante el uso de diagramas de estructura jerárquica. El diagrama de estructura es un diagrama arriba abajo que muestra cada nivel de diseño, su relación con los otros niveles y su posición en la estructura de diseño en general. El diseño considera primero la función principal de un programa o sistema, después divide esa función en subfunciones y descompone cada subfunción hasta llegar al nivel más bajo de detalle. La siguiente figura muestra un diagrama de estructura de alto nivel para un sistema de nómina. Si un diseño tiene demasiados niveles para ajustarse en un diagrama de estructura, se puede dividir todavía más en varios diagramas de estructura más detallados. Un diagrama de estructura puede documentar un programa, un sistema (un conjunto de programas) o parte de un programa.
Desarrollo orientado a objetos.
Los métodos estructurados son útiles para modelar procesos, pero no manejan bien el modelado de los datos. Además, tratan a los datos y a los procesos como entidades separadas en forma lógica, mientras que en el mundo real dicha separación parece algo antinatural. Se utilizan distintas convenciones de modelado para el análisis (el diagrama de flujo de datos) y para el diseño (el diagrama de estructura).
El desarrollo orientado a objetos lidia con estas cuestiones; utiliza el objeto como la unidad básica del análisis y diseño de sistemas. Un objeto combina datos y los procesos específicos que operan sobre ellos. Sólo las operaciones o métodos asociados con un objeto pueden acceder a los datos que se encapsulan en ese objeto o modificarlos. En vez de pasar datos a los procedimientos, los programas envían un mensaje para que un objeto realice una operación que ya está incrustada en él. El sistema se modela como una colección de objetos y las relaciones entre ellos. Puesto que la lógica de procesamiento reside dentro de los objetos en vez de estar en programas de software separados, deben colaborar entre sí para hacer que el sistema funcione.
El modelado orientado a objetos se basa en los conceptos de clase y herencia. Los objetos que pertenecen a cierta clase, o las categorías generales de objetos similares, tienen las características de esa clase. A su vez, las clases de objetos pueden heredar la estructura y los comportamientos de una clase más general, y después agregar variables y comportamientos únicos para cada objeto. Para crear nuevas clases de objetos hay que elegir una clase existente y especificar en qué forma difiere la nueva clase de la clase existente, en vez de empezar cada vez desde cero.
En la siguiente figura podemos ver cómo funcionan las clases y la herencia; en esta figura se ilustran las relaciones entre clases concernientes a los empleados y la forma en que reciben su sueldo. Empleado es el ancestro común, o superclase, de las otras tres clases. Asalariado, PorHoras y Temporal son subclases de Empleado. El nombre de la clase está en el compartimiento superior, los atributos para cada una están en la parte media de cada cuadro y la lista de operaciones se encuentra en la porción inferior de cada cuadro. Las características compartidas por todos los empleados (identificación, nombre, dirección, fecha de contratación, puesto y sueldo) se almacenan en la superclase Empleado, mientras que cada subclase almacena características específicas para ese tipo particular de empleado. Por ejemplo, las características específicas para los empleados por horas son sus tarifas por hora y las tarifas por horas extra. Una línea continua desde la subclase a la superclase es una ruta de generalización, la cual muestra que las subclases Asalariado, PorHoras y Temporal tienen características comunes que se pueden generalizar en la superclase Empleado.
El desarrollo orientado a objetos es más iterativo e incremental que el desarrollo estructurado tradicional. Durante el análisis, los creadores de sistemas documentan los requerimientos funcionales del sistema y especifican sus propiedades más importantes, además de lo que debe hacer el sistema propuesto. Las interacciones entre el sistema y sus usuarios se analizan para identificar objetos, entre las cuales se incluyen tanto datos como procesos. La fase de diseño orientado a objetos describe cómo se comportarán los objetos y cómo interactuarán entre sí. Los objetos similares se agrupan para formar una clase, y las clases se agrupan en jerarquías en las que una subclase hereda los atributos y métodos de su superclase.
Para implementar el sistema de información se traduce el diseño en código de programa, proceso en el que se reutilizan las clases que ya están disponibles en una biblioteca de objetos de software reutilizables y se agregan las nuevas clases que se crean durante la fase de diseño orientado a objetos. La implementación también puede implicar la creación de una base de datos orientada a objetos. El sistema resultante se debe probar y evaluar con detenimiento.
Como los objetos son reutilizables, el desarrollo orientado a objetos podría reducir en forma potencial el tiempo y costo de escribir software, ya que las organizaciones pueden reutilizar los objetos de software que ya se hayan creado como bloques básicos para otras aplicaciones. Es posible crear nuevos sistemas al usar algunos objetos existentes, modificar otros y agregar unos cuantos nuevos. Se han desarrollado marcos de trabajo orientados a objetos para proveer aplicaciones reutilizables semicompletas que la organización pueda personalizar aún más para convertirlas en aplicaciones terminadas.
Ingeniería de software auxiliada por computadora.
La ingeniería de software auxiliada por computadora (CASE), algunas veces conocida como ingeniería de sistemas auxiliada por computadora, provee herramientas de software para automatizar las metodologías que acabamos de describir para reducir la cantidad de trabajo repetitivo que necesita realizar el desarrollador. Las herramientas CASE también facilitan la creación de una documentación clara y la coordinación de los esfuerzos de desarrollo en equipo. Los miembros del equipo pueden compartir su trabajo con facilidad al acceder a los archivos de los demás para revisar o modificar lo que ya se ha hecho. También se pueden lograr beneficios modestos de productividad si las herramientas se utilizan de manera apropiada.
Las herramientas CASE cuentan con herramientas de gráficos automatizadas para producir tablas y diagramas, generadores de pantallas e informes, diccionarios de datos, herramientas para informes extensos, herramientas de análisis y comprobación, generadores de código y generadores de documentación. En general, las herramientas CASE tratan de incrementar la productividad y la calidad al:
Hacer valer una metodología de desarrollo y una disciplina de diseño estándar.
Mejorar la comunicación entre los usuarios y los especialistas técnicos.
Organizar y correlacionar los componentes de diseño y proveer acceso rápido a ellos mediante un almacén de diseño.
Automatizar las porciones tediosas y propensas a errores del análisis y diseño.
Automatizar la generación de código y el despliegue de la prueba y el control.
Las herramientas CASE contienen características para validar diagramas de diseño y especificaciones. Por ende, las herramientas CASE soportan el diseño iterativo al automatizar las revisiones y los cambios, y al proveer habilidades para crear prototipos. Un almacén de información CASE guarda toda la información definida por el análisis durante el proyecto. El almacén indica los diagramas de flujo de datos, los diagramas de estructura, los diagramas entidad-relación, las definiciones de datos, las especificaciones de los procesos, los formatos de las pantallas e informes, las notas y comentarios, y los resultados de las pruebas.
Para usarse con efectividad, las herramientas CASE requieren una disciplina organizacional. Cada miembro de un proyecto de desarrollo se debe adherir a un conjunto común de convenciones de nomenclatura y estándares, así como a una metodología de desarrollo. Las mejores herramientas CASE respetan los métodos y estándares comunes, lo cual puede provocar que se dejen de usar en situaciones en donde no exista una disciplina organizacional.
