Ciclo de vida de los sistemas de informacin Un sistema de informacin es el conjunto de recursos que permiten recoger, gestion ar, controlar

y difundir la informacin de toda una empresa u organizacin. Desde los aos setenta, los sistemas de bases de datos han ido reemplazando a los sistemas de ficheros en los sistemas de informacin de las empresas. Al mismo tiem po, se ha ido reconociendo la gran importancia que tienen los datos que stas mane jan, convirtindose en uno de sus recursos ms importantes. Esto ha hecho que muchas empresas tengan departamentos que se encarguen de gestionar toda su informacin, que estar almacenada en una base de datos. Aparecen los papeles de administrador de datos y administrador de la base de datos, que son las personas encargadas de supervisar y controlar todas las actividades relacionadas con los datos de la e mpresa y con el ciclo de vida de las aplicaciones de bases de datos, respectivam ente. Un sistema de informacin est formado por los siguientes componentes: La base de datos. El SGBD. Los programas de aplicacin. Los dispositivos fsicos (ordenadores, dispositivos de almacenamiento, etc.). El personal que utiliza y que desarrolla el sistema. La base de datos es un componente fundamental de un sistema de informacin. El cic lo de vida de un sistema de informacin est ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de informa cin tambin se le denomina ciclo de vida de desarrollo del software. Las etapas tpic as del ciclo de vida de desarrollo del software son: planificacin, recoleccin y anl isis de los requisitos, diseo (incluyendo el diseo de la base de datos), creacin de prototipos, implementacin, prueba, conversin y mantenimiento. Este ciclo de vida hace nfasis en la identificacin de las funciones que realiza la empresa y en el de sarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el c iclo de vida de desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo. Por esta razn, el anlisis estructurado hace nfasis en los diagramas de flujo de dat os, siguiendo el movimiento de los datos a travs de una secuencia de transformaci ones, y refinando stas a travs de una serie de niveles. Lo mismo ocurre en el diseo estructurado, que ve a un sistema como una funcin que se descompone sucesivament e en niveles o subfunciones. Concentrndose en las funciones se infravaloran los datos y, en especial, la estru ctura de los datos que son manipulados por las funciones. El resultado es que es tos sistemas tienen valor durante poco tiempo en relacin con las necesidades de l os usuarios a largo plazo. Esto sucede debido a que al poco tiempo de haber inst alado un sistema, las funciones implementadas son en realidad un subconjunto de las funciones que los usuarios realmente desean. Casi inmediatamente, los usuari os descubren una gran variedad de servicios adicionales que quisieran incorporar al sistema. Estas necesidades causan problemas a los sistemas obtenidos con un diseo orientado a funciones, puesto que este diseo puede requerir una revisin impor tante para acomodar las funciones adicionales. En contraste, el enfoque orientado a datos centra el foco de atencin en el anlisis de los datos utilizados por las funciones. Esto tiene dos ventajas. La primera es que los datos son una parte considerablemente ms estable que las funciones. La segunda ventaja es que la propia estructura de un esquema de base de datos requ iere de un anlisis sofisticado de los datos y de sus relaciones. Una vez que se h aya construido un esquema para la base de datos que sea lgico, podran disearse tant as funciones como fuera necesario para sacar provecho del mismo. Sin embargo, si n un esquema tal, la base de datos slo podra ser til para una nica aplicacin. Por lo tanto, el enfoque orientado a funciones puede ser bueno para el desarrollo a cor to plazo, pero pierde su valor real a largo plazo. Usando un enfoque orientado a

datos, los datos pasan a ser los cimientos sobre los cuales se puede construir una gran variedad de funciones diferentes. Por lo tanto, en este captulo se van a estudiar cada una de las etapas del ciclo de vida de desarrollo del software desde la perspectiva del desarrollo de una ap licacin de bases de datos, siguiendo un enfoque orientado a datos. Las etapas del ciclo de vida de una aplicacin de bases de datos son las siguiente s: Planificacin del proyecto. Definicin del sistema. Recoleccin y anlisis de los requisitos. Diseo de la base de datos. Seleccin del SGBD. Diseo de la aplicacin. Prototipado. Implementacin. Conversin y carga de datos. Prueba. Mantenimiento. Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realiment acin. Por ejemplo, los problemas que se encuentran en la etapa del diseo de la bas e de datos pueden requerir una recoleccin de requisitos adicional y su posterior anlisis. A continuacin, se muestran las tareas ms importantes que se realizan en cada etapa . 1. Planificacin del proyecto Esta etapa conlleva la planificacin de cmo se pueden llevar a cabo las etapas del ciclo de vida de la manera ms eficiente. Hay tres componentes principales: el tra bajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para p agar por todo ello. Como apoyo a esta etapa, se necesitar un modelo de datos corp orativo en donde se muestren las entidades principales de la empresa y sus relac iones, y en donde se identifiquen las principales reas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relacin. En este modelo se tiene que mostrar tambin qu datos comparten las distintas reas funcionale s de la empresa. La planificacin de la base de datos tambin incluye el desarrollo de estndares que e specifiquen cmo realizar la recoleccin de datos, cmo especificar su formato, qu docu mentacin ser necesaria y cmo se va a llevar a cabo el diseo y la implementacin. El de sarrollo y el mantenimiento de los estndares puede llevar bastante tiempo, pero s i estn bien diseados, son una base para el personal informtico en formacin y para me dir la calidad, adems, garantizan que el trabajo se ajusta a unos patrones, indep endientemente de las habilidades y la experiencia del diseador. Por ejemplo, se p ueden establecer reglas sobre cmo dar nombres a los datos, lo que evitar redundanc ias e inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la empresa como, por ejemplo, qu datos deben tratars e de modo confidencial. 2. Definicin del sistema En esta etapa se especifica el mbito y los lmites de la aplicacin de bases de datos , as como con qu otros sistemas interacta. Tambin hay que determinar quienes son los usuarios y las reas de aplicacin.

3. Recoleccin y anlisis de los requisitos En esta etapa se recogen y analizan los requerimientos de los usuarios y de las r eas de aplicacin. Esta informacin se puede recoger de varias formas: Entrevistando al personal de la empresa, concretamente, a aquellos que son consi derados expertos en las reas de inters. Observando el funcionamiento de la empresa. Examinando documentos, sobre todo aquellos que se utilizan para recoger o visual izar informacin. Utilizando cuestionarios para recoger informacin de grandes grupos de usuarios. Utilizando la experiencia adquirida en el diseo de sistemas similares. La informacin recogida debe incluir las principales reas de aplicacin y los grupos de usuarios, la documentacin utilizada o generada por estas reas de aplicacin o gru pos de usuarios, las transacciones requeridas por cada rea de aplicacin o grupo de usuarios y una lista priorizada de los requerimientos de cada rea de aplicacin o grupo de usuarios. Esta etapa tiene como resultado un conjunto de documentos con las especificacion es de requisitos de los usuarios, en donde se describen las operaciones que se r ealizan en la empresa desde distintos puntos de vista. La informacin recogida se debe estructurar utilizando tcnicas de especificacin de r equisitos, como por ejemplo tcnicas de anlisis y diseo estructurado y diagramas de flujo de datos. Tambin las herramientas CASE ( Computer-Aided Software Engineerin g) pueden proporcionar una asistencia automatizada que garantice que los requisi tos son completos y consistentes. 4. Diseo de la base de datos Esta etapa consta de tres fases: diseo conceptual, diseo lgico y diseo fsico de la ba se de datos. La primera fase consiste en la produccin de un esquema conceptual, q ue es independiente de todas las consideraciones fsicas. Este modelo se refina de spus en un esquema lgico eliminando las construcciones que no se pueden representa r en el modelo de base de datos escogido (relacional, orientado a objetos, etc.) . En la tercera fase, el esquema lgico se traduce en un esquema fsico para el SGBD escogido. La fase de diseo fsico considera las estructuras de almacenamiento y lo s mtodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria. Los objetivos del diseo de la base de datos son: Representar los datos que requieren las principales reas de aplicacin y los grupos de usuarios, y representar las relaciones entre dichos datos. Proporcionar un modelo de datos que soporte las transacciones que se vayan a rea lizar sobre los datos. Especificar un esquema que alcance las prestaciones requeridas para el sistema. Hay varias estrategias a seguir para realizar el diseo: de abajo a arriba, de arr iba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a a rriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrate gia de arriba a abajo es ms apropiada cuando se trata de bases de datos complejas . Se comienza con un esquema con entidades de alto nivel, que se van refinando p ara obtener entidades de bajo nivel, atributos y relaciones. La estrategia de de ntro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que s e parte de los conceptos principales y se va extendiendo el esquema para conside rar tambin otros conceptos, asociados con los que se han identificado en primer l ugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a a bajo, con un esquema de divide y vencers. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada part e se obtiene un subesquema. Estos subesquemas se integran despus para obtener el

modelo final. 5. Seleccin del SGBD Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de informacin. Esta eleccin se debe hace r en cualquier momento antes del diseo lgico. 6. Diseo de la aplicacin En esta etapa se disean los programas de aplicacin que usarn y procesarn la base de datos. Esta etapa y el diseo de la base de datos, son paralelas. En la mayor part e de los casos no se puede finalizar el diseo de las aplicaciones hasta que se ha terminado con el diseo de la base de datos. Por otro lado, la base de datos exis te para dar soporte a las aplicaciones, por lo que habr una realimentacin desde el diseo de las aplicaciones al diseo de la base de datos. En esta etapa hay que asegurarse de que toda la funcionalidad especificada en lo s requisitos de usuario se encuentra en el diseo de la aplicacin. Habr algunos prog ramas que utilicen y procesen los datos de la base de datos. Adems, habr que disear las interfaces de usuario, aspecto muy importante que se sue le ignorar. El sistema debe ser fcil de aprender, fcil de usar, ser directo y esta r ``dispuesto a perdonar''. Si la interface no tiene estas caractersticas, el sis tema dar problemas, sin lugar a dudas. 7. Prototipado Esta etapa, que es opcional, es para construir prototipos de la aplicacin que per mitan a los diseadores y a los usuarios probar el sistema. Un prototipo es un mod elo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la fu ncionalidad del sistema final, pero es suficiente para que los usuarios puedan u tilizar el sistema e identificar qu aspectos estn bien y cules no son adecuados, ad ems de poder sugerir mejoras o la inclusin de nuevos elementos. Este proceso permi te que quienes disean e implementan el sistema sepan si han interpretado correcta mente los requisitos de los usuarios. Otra ventaja de los prototipos es que se c onstruyen rpidamente. Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologas. 8. Implementacin En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, as como los programas de aplicacin. La implementacin de la base de datos se realiza mediante las sentencias del lenguaje de definicin de datos (L DD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la ba se de datos, los ficheros en donde se almacenarn los datos y las vistas de los us uarios. Los programas de aplicacin se implementan utilizando lenguajes de tercera o cuart a generacin. Partes de estas aplicaciones son transacciones sobre la base de dato s, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD. La s sentencias de este lenguaje se pueden embeber en un lenguaje de programacin anf itrin como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. En e sta etapa, tambin se implementan los mens, los formularios para la introduccin de d atos y los informes de visualizacin de datos. Para ello, el SGBD puede disponer d e lenguajes de cuarta generacin que permiten el desarrollo rpido de aplicaciones m ediante lenguajes de consultas no procedurales, generadores de informes, generad ores de formularios, generadores de grficos y generadores de aplicaciones.

Tambin se implementan en esta etapa todos los controles de seguridad e integridad . Algunos de estos controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante utilidades del SGBD o mediante programas d e aplicacin. 9. Conversin y carga de datos Esta etapa es necesaria cuando se est reemplazando un sistema antiguo por uno nue vo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es ne cesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicacin del sistema antiguo tambin se convierten para que se puedan utilizar en el sistema nuevo. 10. Prueba En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe disear una batera de tests con datos reales, que se deben llevar a cabo de manera metdica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para e ncontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrir los er rores en los programas de aplicacin y en la estructura de la base de datos. Adems, demostrar que los programas ``parecen'' trabajar tal y como se especificaba en l os requisitos y que las prestaciones deseadas ``parecen'' obtenerse. Por ltimo, e n las pruebas se podr hacer una medida de la fiabilidad y la calidad del software desarrollado. 11. Mantenimiento Una vez que el sistema est completamente implementado y probado, se pone en march a. El sistema est ahora en la fase de mantenimiento en la que se llevan a cabo la s siguientes tareas: Monitorizacin de las prestaciones del sistema. Si las prestaciones caen por debaj o de un determinado nivel, puede ser necesario reorganizar la base de datos. Mantenimiento y actualizacin del sistema. Cuando sea necesario, los nuevos requis itos que vayan surgiendo se incorporarn al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar. Diseo de bases de datos En este apartado se describen con ms detalle los objetivos de cada una de las eta pas del diseo de bases de datos: diseo conceptual, diseo lgico y diseo fsico. La metod ologa a seguir en cada una de estas etapas se describe en los tres captulos que si guen a ste.