UNIDAD II EL CICLO DE VIDA DE SISTEMAS Y SUS ETAPAS

Transcripción

1 UNIDAD II EL CICLO DE VIDA DE SISTEMAS Y SUS ETAPAS 1.1 Qué son los sistemas informáticos? Un sistema informático utiliza ordenadores para almacenar datos, procesarlos y ponerlos a disposición de quien se considere oportuno. Un sistema puede ser tan simple como: una persona tiene un microordenador y le introduce datos tan elementales, como por ejemplo las ventas diarias de una pequeña empresa, se produce una entrada por cada venta y en ella se declara el elemento vendido, por ejemplo un yogur, la cantidad de elementos vendidos, por ejemplo cuatro y el precio de venta unitario, por ejemplo 0.17 euros. Cada entrada se almacena como un registro de un fichero en el disco. Al finalizar el día se puede obtener un informe de las ventas y las tendencias. El usuario puede utilizar esta información para la gestión de almacén o planificar campañas publicitarias. Habitualmente una empresa tiene más de un ordenador, por ejemplo uno para la gestión de ventas y otro para la contabilidad y procesos asociados. Sin embargo la mayor parte de los sistemas son más complejos. Los sistemas de información tienen muchas cosas en común, la mayoría de ellos están formados por: - Personas son un componente esencial en cualquier sistema de información, producen y utilizan la información de sus actividades diarias para decidir lo que se debe hacer. Las decisiones pueden ser rutinarias o complejas. - Procedimientos, los sistemas de información deben soportar diversas clases de actividades del usuario, por eso han de establecerse procedimientos que aseguren que los datos correctos llegan a las personas adecuadas en su momento justo. - Equipo, es decir los ordenadores y todos los dispositivos necesarios. 1.2 Ingeniería del software Según la definición del IEEE, "software es la suma total de los programas de ordenador, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo" y "un producto de software es un producto diseñado para un usuario". En este contexto, la Ingeniería de Software (SE del inglés "Software Engineering") es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software. Su origen se debe a que el entorno actual de desarrollo de sistemas software viene adoleciendo de: Retrasos considerables en la planificación Poca productividad Elevadas cargas de mantenimiento Demandas cada vez más desfasadas con las ofertas Baja calidad y fiabilidad del producto Dependencia de los realizadores Esto es lo que se ha denominado comúnmente "crisis del software", que se ha originado históricamente en los siguientes pasos: - Primera Fase. Los albores ( ) Programar no es una tarea diferenciada del diseño de una máquina Uso de lenguaje máquina y ensamblador

2 - Segunda Fase. El florecimiento ( ) Aparecen multitud de lenguajes. Era posible hacer casi todo - Tercera Fase. La crisis ( ) Desarrollo inacabable de grandes programas Ineficiencia, errores, coste impredecible. Nada es posible - Cuarta Fase. Innovación conceptual ( ) Fundamentos de programación Verificación de programas. Metodologías de diseño - Quinta Fase. El diseño es el problema (1980-?) Entornos de programación Especificación formal. Programación automática Cómo se define crisis? La palabra crisis se define en el diccionario como "un punto decisivo en el curso de algo; momento, etapa, o evento decisivo o crucial". Sin embargo para el software no ha habido ningún punto crucial, sólo una lenta evolución. La crisis en la industria del software ha permanecido durante muchos años, lo cual parece una contradicción para el término. Lo que si se podría decir es que hay un problema crónico en el desarrollo de software. Ello ha venido originado por una falta de: Formalismo y metodología Herramientas de soporte Administración eficaz Actualmente está surgiendo una gran expectativa ante la evolución de la Ingeniería del Software, al ir apareciendo nuevos métodos y herramientas formales que van a permitir en el futuro un planteamiento de ingeniería en el proceso de elaboración de software. Dicho planteamiento vendrá a paliar la demanda creciente por parte de los usuarios, permitiendo dar respuesta a los problemas de: Administración Calidad Productividad Fácil mantenimiento Este último es uno de los grandes problemas, pues puede llegar a suponer un importe superior al 60% del total del coste del software. Las nuevas metodologías suponen un enfoque integral del problema, abarcando todas las fases, que en su mayoría no se consideraba en los desarrollos tradicionales. En particular son fundamentales la reducción de costes y plazos, así como la calidad del producto final. Estas tecnologías constituyen la denominada "Ingeniería del Software", que se puede definir como "el tratamiento sistemático de todas las fases del ciclo de vida del software". Hay otras definiciones, pero todas inciden en la importancia de una disciplina de ingeniería para el desarrollo de software. Definición del término "Ingeniería del Software" El término Ingeniería, se define en el Diccionario de la Real Academia Española de la Lengua, como: 1. Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energía. 2. Profesión y ejercicio del ingeniero y el término ingeniero se define como: Persona que profesa o ejerce la ingeniería. La Real Academia de Ciencias Exactas, Físicas y Naturales de España, define el término Ingeniería como "Conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre"

3 Evidentemente, al ser una nueva ingeniería, no está incluida su definición en las referencias citadas, aunque si reúne sus propiedades. Revisando definiciones, a nivel internacional, se pueden citar como adecuadas, las siguientes: Definición 1: Es el estudio de los principios y metodologías para desarrollo de sistemas de software. Definición 2: Es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de ordenador y la documentación adecuada para desarrollar, operar y mantenerlos. Definición 3: Se trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable. Definición 4: La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y man- tenimiento de software. Seguidamente se dan algunas definiciones ampliamente aceptadas dentro de la informática: DEFINICIONES DE BOE HM - Software es el conjunto de programas, procedimientos y documentación asociados a un sistema, y particularmente a un sistema computacional. - Ingeniería es la aplicación de la ciencia y las matemáticas mediante lo cual las propiedades de la materia y las fuentes de energía de la naturaleza se hacen útiles al hombre en estructuras, máquinas, productos, sistemas y procesos. - Ingeniería de software es la aplicación de la ciencia y las matemáticas mediante la cual la capacidad de los equipos computacionales se hacen útiles al hombre a través de programas de computador, procedimientos y la documentación asociada. DEFINICION DE BAUER Ingenier ía del Software es el establecimiento y uso de firmes principios y métodos de ingeniería para la obtención económica de software fiable y que funcione en máquinas reales. Durante los primeros años de la informática, el software se consideraba como un añadido. La programación era un "arte", para el que no existían metodologías, era un proceso que se realizaba sin ninguempresas dedicadas al desarrollo y distribución masiva del mismo. El origen na planificación. En esta época toda la programación se desarrollaba a medida para cada aplicación, y en consecuencia tenía muy poca difusión, habitualmente quien lo escribía era porque lo necesitaba, y era quien lo mantenía. En una segunda época (a partir de mitad de la década de 1960) se estableció el software como producto y aparecieron las del término Ingeniería del Software, se atribuye a dos conferencias organizadas por la OTAN en 1967 y La tercera era comenzó a mediados de la década de 1970, época en la que los sistemas informáticos aumentaron mucho en su complejidad, y nacieron las redes de ordenadores. Esto supuso mucha presión para los desarrolladores, aunque los ordenadores para uso personal, apenas estaban difundidos. Esta época acabó con la aparición de los microprocesadores. La cuarta era de la evolución de los sistemas informáticos, comienza hacia 1990 y se dirige al impacto colectivo de los ordenadores y el software, en todos los entornos. La industria del software tiene un gran peso en la economía mundial. Aparecen las técnicas de redes neuronales, junto con la lógica difusa.

4 La industria envejece En los años 50 y 60 del siglo XX, muchos comentaristas especializados criticaban a la industria del metal en EE.UU. por la falta de inversión en las fábricas. Las fábricas habían comenzado a deteriorar- la industria del metal perdió una parte de mercado muy significativa, se, no se aplicaban los métodos de producción modernos, la calidad quedaba en entredicho, y sin embargo el coste del producto final subía, como consecuencia la competencia externa ganó una cuota de mercado considerable. La dirección de esas industrias no decidió invertir capital para mantenerse competitivas en el entorno industrial. Como consecuencia, beneficiando a las industrias extranjeras, que tenían fábricas más modernas en todos sus aspectos. Actualmente la industria del software está en una situación análoga. A todos los niveles se tiene una "fábrica de software" que envejece, hay miles de aplicaciones basadas en software en una situación crí- de lo contrario no serán competitivos en este nuevo siglo. tica y necesitan su renovación urgente, aunque con la llegada del año 2000 y sus temidos efectos, parte del software se puso al día. El futuro no pasa por "reparar" lo que está mal, y cambiar la imagen de las aplicaciones, se necesita una reingeniería o reestructuración, Desa- Hoy en día el software tiene un doble papel. Es un producto, pero simultáneamente es el vehículo para hacer entrega de un producto. Como producto permite el uso del hardware, ya sea, por ejemplo, un ordenador personal, un teléfono móvil. Como vehículo utilizado para hacer entrega del producto, actúa como base de control, por ejemplo un sistema operativo, o un sistema gestor de redes. El software hace entrega de lo que se considera como el producto más importante del siglo veintiuno, la información. El software transforma datos personales para que sean más útiles en un entorno local, gestiona información comercial para mejorar la competitividad, proporciona el acceso a redes a nivel mundial, y ofrece el medio de adquirir información en todas sus formas. Actualmente se considera la Ingeniería del Software como una nueva área de la ingeniería, y la profesión de ingeniero informático es una de las más demandadas. La palabra ingeniería tiene una connotación de prestigio que provoca que muchas ramas del conocimiento tiendan a autodenominarse así. La ingeniería del software trata áreas muy diversas de la informática y de las ciencias de la computación, aplicables a un amplio espectro de campos, tales como negocios, investigación científi- de ca, medicina, producción, logística, banca, meteorología, derecho, redes, entre otras muchas. Sin embargo, es frecuente que en la práctica diaria profesional no se incluya prácticamente ninguna de las recomendaciones más elementales de la ingeniería del software. Es habitual que el desarrollo software se parezca más al descontrol del cuento de «si los programadores fueran albañiles...» que a una idílica y bien organizada "factoría de software" (concepto de gran vigencia a fines de los ochenta). De hecho, las evaluaciones de los procesos productivos de software realizadas a raíz de los modelos de procesos de software confirman que el desarrollo de software suele estar básicamente en estado caótico. Y no sólo en pequeñas empresas de países como España, sino en grandes proyectos en naciones como EE UU y Japón. Como ejemplo de que la ingeniería del software es en la actualidad imprescindible, la revista satírica inglesa Private Eye dio detalles sobre importantes proyectos de software que han dado resultados mamecánica como buscar un gato negro en una habitación iluminada. los. Entre ellos destacan los del servicio de ambulancias Asinfor de Londres, el servicio de sanidad regional de Wessex, la Sociedad para los derechos de autor y el sistema de manejo de equipajes del aeropuerto de Denver. De una forma humorística se hace la siguiente comparación con otras ingenierías: - Ingeniería - Ingeniería química como buscar un gato negro en una habitación oscura. - Ingeniería software como buscar un gato negro en una habitación oscura donde no hay ningún gato. - Ingeniería de sistemas como buscar un gato negro en una habitación oscura donde no hay gato y alguien dice!!! Lo encontré!!!.

5 fortunadamente, muchos directores de empresas no están dispuestos a comprometer los recursos, pues piensan que en funcionando una aplicación, no es necesario nada más. 1.3 Ciclo de desarrollo El software es un elemento ware: lógico, por lo que tiene unas características muy diferentes a las del hard- El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se en- cuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación. A mediados de la década de 1980, se introdujo el concepto de "fábrica de software", que recomienda el uso de herramientas para el desarrollo automático del software. Si se representa gráficamente la proporción de fallos en función del tiempo, para el hardware se tiene la figura conocida como "curva de bañera". Al principio de su vida hay bastantes fallos (normalmente por defectos de diseño y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto de: mala calidad, suciedad, malos tratos, temperaturas extremas y otras causas. El hardware empieza a estropearse. Cuando un componente hardware se estropea, se cambia por otro que actúa como una "pieza de repuesto", mientras que para el software, no es habitual este proceso, lo cual significa que el mantenimiento de los programas es muy complejo. El software no se estropea. La gráfica de fallos en función del tiempo, tendría forma de caída desde el principio, hasta mantenerse estable por tiempo casi indefinido. El software no es susceptible a los ma- les del entorno que provocan el deterioro del hardware. Los efectos no detectados harán que falle el programa durante las primeras etapas de su vida, sin embargo una vez corregidas, no se producen nuevos errores. Aunque no se estropea, si puede deteriorarse. Esto sucede debido a los cambios que se efectúan durante su vida. La mayoría del software se construye a medida, en vez de ensamblar componentes previamente creados. Por contra en el hardware se dispone de todo tipo de circuitos integrados, para fabricar de manera rápida un equipo completo. Los ingenieros de software no disponen de esta comodidad, aunque ya se están dando los primeros pasos en esta dirección, que facilitaría tanto el desarrollo de aplicaciones informáticas. La formalización del proceso de desarrollo se define como un marco de referencia denominado ciclo de desarrollo del software o ciclo de vida del desarrollo del software o ciclo de vida del desarrollo. Se puede describir como, "el período de tiempo que comienza con la decisión de desarrollar un producto software y finaliza cuando se ha entregado éste". Este ciclo, por lo general incluye las fases:

6 1. Requisitos 2. Diseño 3. Implantación 4. Prueba 5. Instalación 6. Aceptación En la figura anterior cada área está asociada a una actividad específica del desarrollo, y se le asigna un porcentaje de incidencia (que suele variar en cada caso) en el costo del desarrollo que corresponde al número en ella inscrito. El área designada operaciones comprende las actividades comúnmente asociadas al desarrollo de sistemas de información administrativos, mientras que el resto corresponde a actividades asociadas al desarrollo de software como producto. El ciclo de desarrollo software se utiliza para estructurar las actividades que se llevan a cabo en el desarrollo de un producto software. A pesar de que no hay acuerdo acerca del uso y la forma del modelo, este sigue siendo útil para la comprensión y el control del proceso. Seguidamente se exponen las distintas aproximaciones de desarrollo de software, en función del tipo de ciclo de vida: A) Aproximación Convencional Se introdujo por Winston Royce en la década de 1970, como una técnica rígida para mejorar la cali- de software. Tradicionalmente es conocido como "modelo en dad y reducir los costos del desarrollo cascada", porque su filosofía es completar cada paso con un alto grado de exactitud, antes de iniciar el siguiente. Esquemáticamente se puede representar como: FACTIBILIDAD: Definir un concepto preferente para el producto de software y determinar su factibilidad de ciclo de vida y superioridad frente a otros conceptos. REQUERIMIENTOS: Elaborar una especificación completa y validada de las funciones requeridas, sus interfaces y el rendimiento del producto de software. DISEÑO: Elaborar una especificación completa y validada de la arquitectura global hardware-softwamanuales de usuarios y planes de re, de la estructura de control y de la estructura de datos del producto, así como un esquema de los test. DISEÑO DETALLADO: Elaborar una especificación completa y verificada de la estructura de control, de la estructura de datos, de las interfaces de relación, dimensionamiento y algoritmos claves de cada componente de programa (rutina con un máximo de 100 instrucciones fuentes). CODIFICACION: Construir un conjunto completo y verificado de componentes de programas. INTEGRACION: Hacer funcionar el producto de software compuesto de componentes de programa. IMPLEMENTACION: Hacer funcionar el sistema global hardware-software incluyendo conversión de programas y datos, instalación y capacitación.

7 OPERACION Y MANTENCION: Hacer funcionar una nueva versión del sistema global. TRANSICION: Realizar una sucesión limpia de este a otros eventuales productos. En cada caso, "verificación" tienen la acepción: establecer la verdad de la correspondencia entre un producto de software y su especificación. Es decir: ESTAMOS CONSTRUYENDO CORRECTAMENTE EL PRODUCTO? Los principales problemas que se han detectado en esta aproximación son debidos a que se comienza estableciendo todos los requisitos del sistema: En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos. En otras hay cambio de parecer de los usuarios sobre las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables los verdaderos requisitos no se reflejen en el producto final Otro de los problemas de esta aproximación es que los resultados no se ven hasta muy avanzado el proyecto, por lo tanto la realización de modificaciones, si ha habido un error, es muy costosa. Esta aproximación es la más empleada por los ingenieros informáticos, aunque ha sido muy criticada, y de hecho se ha puesto en duda su eficacia. Entre los problemas que se pueden encontrar con este modelo, se tienen: - Los proyectos raras veces siguen el modelo secuencial que se supone. Los cambios pueden causar confusión. - Es difícil disponer en principio de todos los requisitos. Este modelo presenta dificultades en el momento de acomodar estas incertidumbres. - La versión operativa de los programas no está disponible hasta que el proyecto está muy avanzado. Un error importante puede ser desastroso, si se descubre al final del proceso. - Los responsables del desarrollo siempre se retrasan innecesariamente. Algunos integrantes del equipo de desarrollo han de esperar a otros para completar tareas pendientes. B) Aproximación prototipo Es habitual que en un proyecto software no se identifiquen los requisitos detallados de entrada, pro- no se está seguro de la eficiencia de un algoritmo, o de la forma en cesamiento o salida. En otros casos que se ha de implantar la interfaz hombre-máquina. En casos así, lo habitual es construir un prototipo, que idealmente sirviera como mecanismo para identificar los requisitos del software. Esta aproximación consiste en realizar la fase de definición de requisitos del sistema en base a estos tres factores: Un alto grado de iteración Un muy alto grado de participación del usuario Un uso extensivo de prototipos Las premisas clave de esta aproximación son: Que los prototipos constituyen un medio mejor de comunicación que los modelos en papel Que la iteración es necesaria para canalizar, en la dirección correcta, el proceso de aprendizaje. Esta aproximación se enfoca a mejorar la efectividad del proceso de desarrollo y no a mejorar la eficacia de ese proceso. El problema, es que los usuarios finales, ven lo que parece ser una versión de trabajo del software, sin considerar que no es la versión definitiva y por lo tanto no se han considerado aspectos de calidad o facilidad de mantenimiento. Cuando se les dice, que el producto es a partir de entonces cuando se debe de empezar a "fabricar", no lo entiende y empieza de nuevo con ajustes, lo cual hace este proceso muy lento.

8 C) Aproximación evolutiva

9 En esta aproximación el énfasis está en lograr un sistema flexible y que se pueda expandir de forma que se pueda realizar muy rápidamente una versión modificada del sistema cuando los requisitos cambien. Se diferencia de la aproximación anterior, en que en esta los requisitos cambian continuamente, lo cual implicaría en el caso previo que las iteraciones no tendrían fin. D) Aproximación incremental Es un concepto muy parecido al de desarrollo evolutivo, y frecuentemente comprendido en la aproximación del desarrollo evolutivo. Se comienza el desarrollo del sistema para satisfacer un subconjunto de requisitos especificados. Las últimas versiones prevén los requisitos que faltan. De esta forma se logra una rápida disponibilidad del sistema, que aunque incompleto, es utilizable y satisface algunas de las necesidades básicas de información. La diferencia con la aproximación anterior es que en este caso cada versión parte de una previa sin cambios pero con nuevas funciones, mientras que la aproximación evolutiva cada vez se desarrolla una nueva versión de todo el sistema. Un ejemplo de este paradigma se tiene en el desarrollo de una aplicación sencilla, como es un editor de textos. En el primer incremento se podría desarrollar con un reducido conjunto de funciones, como las funciones básicas de gestión de archivos. En un segundo incremento, se puede incluir la gestión avanzada de textos. Y en un tercer incremento se pondría la corrección ortográfica. E) Aproximación espiral Nace con el objetivo de captar lo mejor de la aproximación convencional y de la de prototipo, añadiendo un nuevo componente, el análisis de riesgos. Esquemáticamente se puede ilustrar mediante una espiral, con cuatro cuadrantes que definen actividades. En la primera vuelta de la espiral se definen los objetivos, las alternativas y las restricciones y se analizan y se identifican los riesgos. Si como consecuencia del análisis de riesgo se observa que hay incertidumbre sobre el problema entonces en la actividad correspondiente a la ingeniería se aplicará la aproximación prototipo cuyo beneficio principal es el de reducir la incertidumbre de la naturaleza del problema de información y los requerimientos que los usuarios establecen para la solución a ese problema. Al final de esta primera vuelta alrededor de la espiral el usuario evalúa los productos obtenidos y puede sugerir modificaciones. Se comenzaría avanzando alrededor del camino de la espiral realizando las cuatro actividades indicadas a continuación. En cada vuelta de la espiral, la actividad de ingeniería se desarrolla mediante la aproximación convencional o ciclo de desarrollo en cascada o mediante la aproximación de prototipos.

10 Actividades Acciones Planificación Determinación de alternativas, identificación y resolución de riesgos Ingeniería Desarrollo y verificación del producto de siguiente nivel Evaluación del cliente Valoración de los resultados del proceso de desarrollo F) Aproximación basada en transformaciones Con la aparición de las herramientas CASE junto con los generadores de código, el ciclo de desarrollo software en cascada ha cambiado a un ciclo de vida basado en transformaciones. CASE (Computer Aided Software Engineering), en castellano "Ingeniería de software Asistida por Computadora", es un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información. La utilización de herramientas CASE afecta a todas las fases del ciclo de vida del software. Este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema, seguidamente existe un proceso de transformación que hace que la especificación se convierta en un diseño lógico del sistema. Posteriormente, este sufre otro proceso de transformación para lograr un diseño físico, es decir que responda a la tecnología destino. La tecnología CASE propone que estos procesos de transformación sean lo más automatizables posible. Sus ventajas son: Posibilidad de comprobación de errores en etapas iniciales de desarrollo Posibilidad de realizar el mantenimiento en el ámbito de especificación Soporte de rastreabilidad de los requisitos Soporte de reusabilidad Potencia la especificación orientada al problema 1.4. Metodología CASE para el desarrollo de sistemas Introducción Los sistemas informáticos, al agilizar y optimizar el almacenamiento, difusión y procesamiento de la información, mejoran la producción de las organizaciones que los emplean para la automatización de sus funciones. Sin embargo, si no se tienen en cuenta ciertos elementos en el diseño e implantación, no siempre la automatización significa un aumento de la producción. Hay que considerar por un lado, que hay un costo asociado a la adquisición de nueva tecnología conciertas funciones sistente en equipos y programas; y por otro, que aún teniendo la tecnología más moderna, la automatización puede ser ineficiente y no operativa si no se realizó previamente un análisis de las necesidades de la organización, de las diferentes ofertas tecnológicas en el mercado y un diseño de los sistemas adecuado tanto a las funciones de la organización como a la tecnología empleada. Por ejemplo, en la actualidad es muy común automatizar de manera independiente de una organización utilizando computadoras personales y paquetes comerciales económicos. En un principio este tipo de sistemas pueden satisfacer las necesidades de la función automatizada, pero posteriormente cuando es necesario contar con accesos flexibles de información consistente y que englobe todas las funciones de la organización, dichos sistemas se vuelven inadecuados, otra posibilidad es que debido a la falta de un dimensionamiento previo del sistema, el equipo adquirido puede resultar a corto plazo insuficiente u obsoleto. Por lo tanto, antes de iniciar una automatización es importante tener en cuenta que:

11 Con el fin de tener una visión desde los puntos de vista de la dirección corporativa, se analizan las diferentes funciones que realiza la organización y sus necesidades de información a todos niveles, durante esta etapa se realizan una serie de entrevistas con la dirección y los responsables de los depar- a) Las organizaciones son complejas y realizan diversas funciones que están relacionadas entre si, que sus necesidades de manejo de información cambian y crecen, y que además del manejo operativo de la información hay una necesidad de contar con un acceso global que permita una mejor toma de decisiones b) La tecnología es muy cambiante, cada vez hay mayor variedad de equipos y sistemas mas po- derosos de costos diversos, lo que complica la selección de la tecnología adecuada c) El diseño, la programación y la operación de los sistemas requieren de especialistas Por lo antes mencionado, si se pretende que realmente una automatización no solamente redunde en una mejora de la producción sino que además resulte una inversión rentable en cuanto a la adquisición de una tecnología adecuada, es necesario contar con una metodología de desarrollo de sistemas. Dado que el desarrollo de sistemas de información es una actividad compleja, ésta puede dividirse para su estudio en las siguientes etapas: 1. Definición y análisis de los requerimientos del usuario. 2. Diseño del sistema y de la base de datos. 3. Implantación y prueba de módulos. 4. Integración y prueba del sistema. 5. Operación y mantenimiento. Como estas etapas a su vez son muy elaboradas, han surgido varias metodologías que permiten realizarlas de una manera estructurada. El método CASE (Computer Aided Systems Engineering) plantea una secuencia de etapas que es aproximadamente equivalente a la citada arriba, pero es más detallada, y además proporciona para cada etapa su descripción, definición de objetivos y metas, productos de la etapa, factores críticos de éxito, y la lista de tareas que conviene realizar. Además es posible auxiliarse de herramientas CASE que facilitan grandemente la puesta en práctica del método. Esta tecnología ha sido utilizada para el diseño de diversos sistemas que se han desarrollado. A continuación presentamos la metodología CASE Etapas en el método CASE La metodología CASE se basa en un análisis y desarrollo del tipo descendiente ("topdown") en que el ciclo de vida de un sistema se compone de las siguientes etapas (ver figura 1): 1. Estrategia 2. Análisis 3. Diseño 4.1 Construcción 4.2 Documentación 5. Transición 6. Producción Figura 1. Etapas del m étodo CASE. 1. Estrategia. Esta es una de las etapas más importantes, ya que tiene por objetivo lograr un entendimiento claro de las necesidades de la organización y del ambiente en que operará el sistema o sistemas a implantar.

12 tamentos. Así a partir de esta información se realiza así un primer modelado de los requerimientos del sistema de información adecuado a las necesidades de la organización. Posteriormente para la definición de una primera versión de la arquitectura del sistema, además de los requerimientos antes obtenidos, se toman en cuenta las tecnologías disponibles y los sistemas de información ya existentes en operación. En la figura 2 se muestra este proceso. Figura 2. Etapa de Estrategia Los resultados de esta etapa son, un conjunto de modelos de la empresa, un conjunto de recomenda- ciones, y un plan acordado de desarrollo de los sistemas de información, la elaboración de este últi- se hará de acuerdo las necesidades actuales y futuras de la organización, tomando en cuenta res- mo tricciones operativas, financieras y técnicas. 2. Análisis La etapa de análisis toma y verifica los descubrimientos de la etapa de estrategia y expande estos en suficiente detalle para asegurar la precisión de los modelos de la empresa, posibilitando un funda- para el diseño, dentro del alcance de la organización y tomando en cuenta sistemas mento sólido existentes. Figura 3. Etapa de Análisis Con el fin de obtener un refinamiento de los modelos, durante esta etapa se realiza otra serie de entrevistas ya no a un nivel directivo como en la anterior, sino a un nivel operativo y técnico. Con la participación los responsables de la operación de las funciones que serán automatizadas se realiza un aná- lisis detallado de sus requerimientos específicos en cuanto a objetivos, subfunciones, información, datos, etc. Así, en esta etapa a partir de los modelos de la organización obtenidos en la anterior y del producto del análisis de ésta, se genera el modelado del sistema.

13 Los modelos básicos de esta etapa son: El de entidad/relación, que modela mediante relaciones lógicas todos los datos involucrados en el sis- (consulta o modificación) sean tema, de tal manera que cualquier tipo de explotación posibles. El funcional, que modela las diferentes servicios que ofrecerá el sistema mediante una organización y clasificación de las diversas funciones y subfunciones que fueron identificadas en el análisis. Como resultados de esta etapa, además del modelo de entidad/relación y el funcional, se definen las restricciones que tendrá el sistema y la estrategia que se seguirá en la etapa de transición. El proceso de esta etapa y sus resultados se muestran en la figura Diseño La etapa de diseño toma los requerimientos y el modelado de la etapa de análisis y determina la mede satisfacerlos, logrando niveles de servicios acordados, dados el ambiente técnico y las jor manera decisiones previas en los niveles requeridos de automatización. Es decir que del diseño conceptual se pasa al diseño final que será utilizado para la implantación, por ejemplo en esta etapa, el modelo entidad/relación será transformado en un diseño de base de datos, y en especificaciones de almacenamiento y el modelo de funcional, en módulos y manuales de procedimientos. Figura 4. Etapa de Diseño El diseño final del sistema integra tres diseños, el de la base de datos, el de la aplicación y el de la red además se elaboran los planes de prueba y de transición y se realizan los diseños de los sistemas de auditoria y control, y el de respaldos y recuperación. Los resultados de esta etapa lo constituyen, la arquitectura del sistema, el diseño de la base de datos, la especificación de los programas, la especificación de los manuales de procedimientos. En la figura 4 se muestra esta etapa. 4.1 Construcción A partir del diseño final generado en la anterior etapa, en esta de construcción, se codificarán y proba- usando herramientas apropiadas. Esta etapa involucra planeación, diseño rán los nuevos programas, de la estructura del sistema, codificacion de abajo a arriba (prueba de unidades y enlaces), pruebas de arriba a abajo (prueba del sistema) y un enfoque disciplinado en la realización del trabajo y en el control de versiones del sistema y pruebas. Los resultados de esta etapa son los programas probados y la base de datos afinada. Los resultados de esta etapa lo constituyen los programas probados y las bases de datos afinada, en la siguiente figura se muestra el proceso de esta etapa.

14 Figura 5. Etapa de Construcción 4.2 Documentación Uno de los productos fundamentales para un uso y un mantenimiento efectivos y eficientes de los sis- programados son los manuales. Esta metodología incluye una etapa dedicada a esta actividad temas tan importante y hace hincapié para que en su elaboración se consideren el estilo de trabajo y las necesidades propias de los usuarios que utilizarán y mantendrán el sistema. Esta etapa se realiza al mismo tiempo que la de construcción. Los manuales, resultados de esta etapa, se elaboran a partir de las especificaciones de diseño, de los programas realizados y del análisis del estilo de trabajo y nivel de competencia de los usuarios y operadores de los sistemas. En la figura 6 se muestra el proceso de esta etapa. Figura 6. Etapa de Documentación 5. Transición La implantación de sistemas no necesariamente implica la sustitución total de lo s antiguos subsiste- mas y de sus bases de datos correspondientes. En ciertos casos, por razones operativas y/o económi- cas, los nuevos sistemas integran algunos de los antiguos; pero como quiera que sea, la introducción ya sea de un sistema completamente nuevo o un sistema que integra ya existentes implica un nuevo tipo de uso y de operación que deberá ser asimilado y aprendido por los usuarios y operadores. Por esta razón, el desarrollo de un sistema no se termina con su programación; antes de su liberación para su uso, se debe prever un período de transición que deberá incluir la alimentación de las nuevas bases de datos, la capacitación de los usuarios y el desarrollo de pruebas. En esta metodología la transición conforma una de sus etapas y en ella se realizan se realizan todas las tareas necesarias para la implementación y proporciona un periodo inicial de soporte al sistema. La transición debe llevarse a cabo con una interrupción mínima de la organización, y debe dejar a los usuarios confiados y listos para explotar el nuevo sistema. El resultado final de esta etapa es un reporte que muestre que las pruebas fueron satisfactorias, en la figura siguiente se muestra el proceso de esta etapa.

15 Figura 7. Etapa de Transición 6. Producción Finalmente, en la etapa de producción se asegura que el sistema funcione correctamente en la mayoría de los casos, y con intervención mínima de los administradores del sistema. Para esto se realizan nuereevalúan los resultados y se hacen refinamientos del sistema, los cambios necesarios vas pruebas, se deberán ser introducidos sin afectar a los usuarios, y deberá conseguirse la máxima confianza de los usuarios. El resultado de esta etapa un sistema listo para su operación. CONCLUSIONES Figura 8. Etapa de Producción Cada sistema a desarrollar debe ser tratado con la metodología que mejor se adapte a los objetivos del análisis un producto final de calidad. Como analistas de sistemas debemos mantenernos a la par de los últimos avances en cuanto a las metodologías y tendencias dentro del incesante mundo del manejo de la Información. Conforme pasa el tiempo el perfil del analista de sistemas irá incorporando nuevas posibilidades y deberes dentro de las organizaciones, lo que nos afirma que durante mucho tiempo tendremos trabajo, claro, manteniéndonos en la excelencia. BIBLIOGRAFÍA Consideramos que es fundamental el uso de una metodología en el desarrollo de sistemas, para lograr una real satisfacción de los usuarios y ampliar la vida útil de los sistemas de información. Además, la realización de las etapas de estrategia, análisis, diseño y documentación, permiten contar con productos que serán invaluables para la extensión y mantenimiento de los sistemas informáticos, adaptándo- los a la evolución natural de las organizaciones. [1] Barker, R. (1990). Case Method. AddisonWesley. [2] Barker, R. (1990). Case Method: Entity Relationship Modelling. AddisonWesley. [3] Barker, R. and Wesley. Longman, C. (1992). Case Method: function and process modelling. Addison- [4] Sommerville, I. (1992). Software Engineering. AddisonWesley.