Make your own free website on Tripod.com

ipn_.jpg

Ciclo de Vida

Home | Conceptos | Desarrollo del Sistema | Ciclo de Vida | Tablas del Modelo Entidad-Relacion | Normalizacion | Entidad-Relacion

Ciclo de vida de un Sistema de Informacion
 
CICLO DE VIDA ESTRUCTURADO
 
ESTUDIO
 
La etapa de Estudio de viabilidad o estudio inicial. 
Su principal objetivo es el estudio e identificación de las deficiencias actuales en el ambiente del usuario (a través de relevamientos, en cuentas), establecer nuevos objetivos, y proponer "escenarios" viables
 
ANALISIS
Conforme a las alternativas generadas por el estudio, en esta etapa se "Modelan" las necesidades del usuario a través de DIAGRAMAS especiales (DFD, ER),dando como resultado las Especificaciones estructuradas. 
 
DISEÑO
En esta etapa se "diseña" el sistema, determinando los módulos componentes del Sistema, de acuerdo a una jerarquía apropiada, a los procesadores (hardware) y a la función
 
IMPLANTACION (DESARROLLO)
Esta actividad incluye la codificación e integración de los módulos con técnicas de programación estructurada
 
GENERACIÓN DEL TEST DE ACEPTACIÓN
Consiste en preparar un conjunto de casos para efectuar las pruebas del sistema
 
GARANTIA DE CALIDAD
En esta etapa se efectúa el TEST final de aceptación del Sistema
 
DESCRIPCION DE PROCEDIMIENTO
Consiste en la elaboración de la "descripción formal" del nuevo sistema: Manuales del Usuario, Manuales del Sistema, Manuales de procedimiento
 
CONVERSIÓN DE LA BASE DE DATOS
Esta actividad sólo se realiza cuando existen sistemas funcionando
 
INSTALACION
Es la actividad FINAL.
 
Estas técnicas están basadas en los sistemas de información, ahora veamos como se aplica en una base de datos.

 

Ciclo de Vida de una Base de Datos

        Durante el Ciclo de Vida del Desarrollo de Sistemas, los profesionales se encuentran en la búsqueda de soluciones a través de la arquitectura de datos y del diseño de las aplicaciones del sistema de información.

         Para ello, es conveniente precisar que entendemos por:

Diseño de la Aplicación: corresponde al diseño lógico que define los requerimientos de información actual y futura, funciones a ejecutar, elementos de datos, seguridad, claves, relaciones, etc.

Diseño de Base de Datos: corresponde al Diseño físico que provee estructuras y métodos de acceso para implantar la aplicación, rendimiento, copia de respaldo (backup), recuperación (restore), seguridad, etc.

Ejemplo 1

Consideraciones Típicas de Diseño

        Por lo general, existen una serie de consideraciones típicas que deben adoptarse para realizar el diseño de base de datos. Estas son por lo general las siguientes:

Flexibilidad y complejidad de las necesidades de usuarios.

Seguridad

Rendimiento

Tiempo de desarrollo

Independencia de datos

Almacenamiento (espacio) en disco

Tiempo de mantenimiento

Tiempo de backup y recuperación

          En consecuencia, durante el diseño de base de datos se debe BALANCEAR la "rapidez del tiempo de respuesta" y "espacio de almacenamiento" con la "facilidad de uso".

Aproximaciones del Diseño

Cuando se entra en la fase de diseño, surgen una serie de alternativas o aproximaciones que se realizan mentalmente, estas son:

a) Aproximación Intuitiva del Diseño, en donde se trata de responder:

1. ¿Qué‚ datos se necesitan?

2. ¿Qué‚ relación hay entre ellos?

3. ¿Cómo se recuperan los datos?

4. ¿Cuáles son las claves?

5. ¿Cuáles son las claves de acceso rápido?

6. Dibuje la base de datos y optimice.

b) Aproximación Funcional, tratando de responder:

1. ¿Qué funciones se ejecutarán?

2. ¿Qué información se necesitará para cada función?

3. Agrupar información por función

4. Identificar relaciones

5. Dibujar la base de datos y optimizar.

Decisiones Comunes en el Diseño

        Paralelamente al proceso mental de diseño, surgen una serie de consideraciones referidas a:

1) Selección de clave de acceso.

1. ¿Cómo buscan datos los usuarios?

2. ¿Qué‚ otras claves se necesitan para acceso rápido o frecuente?

        Debe considerarse: ¿Cuántas? ¿Cuán rápido? ¿Cuán frecuente? y su impacto en el rendimiento (performance).

2) Selección de accesos.

1. ¿Cómo se relaciona cada ítem con todos los demás?

2. ¿Qué‚ se necesita para describir una entidad?

3. ¿Qué‚ se necesita para ejecutar una función?

        Para lo cual es necesario establecer las relaciones:

Uno a Uno (1::1)

Uno a Muchos (1::n)

Muchos a Muchos (n::m)

3) Selección de definición física de accesos.

        Si las claves de acceso son numerosas e impredecibles, entonces la definición debe ser automática.

         Si los valores de las claves deben ser validados, entonces la definición debe ser manual.

         Si es necesario almacenar datos adicionales con la clave, entonces la definición debe ser manual.

4) Selección de la capacidad de almacenamiento.

1. ¿Cuál es la capacidad necesaria para almacenar todos los registros?

2. ¿Cuánto y cuán rápido crecerá la base de datos?

          Teniendo en cuenta consideraciones tales como:

Espacio en disco

Tipo de acceso físico

Tiempo de obtención de la copia de respaldo y recuperación (backup / restore)

5) Selección de Tipo de usuario (único versus múltiples).

1. ¿Debe tener alguna función acceso exclusivo a base de datos?

2. ¿Los usuarios en consulta deben ser protegidos de las modificaciones de otros?

3. ¿Los usuarios que modifican deben ser protegidos de otras modificaciones?

        Teniendo en cuenta las consideraciones:

Impacto en rendimiento (performance)

Modos de acceso (apertura de base de datos)

Niveles de bloqueo (locking)

6) Selección del tipo de transacción (Batch versus On-line).

1. ¿La información que manipula es estética y/o dinámica?

2. ¿Cuán actualizada debe ser la información?

3. ¿Las modificaciones a datos "clave" debe realizarse On-line?

        Teniendo en cuenta las consideraciones:

Impacto en el rendimiento (performance)

Necesidad de los usuarios

7) Selección del proceso de copia de respaldo (backup) y recuperación.

1. ¿Cuán críticos son estos datos para la operación del negocio de la empresa?

2. ¿Cuán seguido deben estar los datos disponibles para los usuario? (horas por día, días por semana, etc.)

3. ¿Qué pérdida de datos podríamos soportar en el caso de una falla catastrófica?

4. ¿Cuánto tiempo podemos perder en la recuperación?

        Teniendo en cuenta las consideraciones:

Tiempo de backup / restore

Impacto en rendimiento de logging.

Metodología

        Es una colección de técnicas basadas sobre una filosofía común o una forma de trabajo, que se establece en conjunto sobre una plataforma llamada Ciclo de Vida del Desarrollo de Sistemas o simplemente Ciclo de Vida.

      La metodología corresponde a un conjunto de modelos, lenguajes y otras herramientas que nos facilitan la representación de los datos de cada fase del proceso (análisis, diseño, construcción, etc.) junto con las reglas que permiten el paso de una fase a la siguiente.

Técnica

        Es un procedimiento para realizar alguna parte significativa del Ciclo de Vida de Desarrollo de Sistemas. Se han desarrollado muchas técnicas, por ejemplo para la definición de requerimientos, para diseño de base de datos, para diseño computacional de aplicaciones, para diseño de programas, para desarrollo de pruebas de implantación, para prototipos, y muchas más.

        Para Edward Yourdon, las técnicas son procedimientos similares a las recetas de un "Libro de Cocina" que ayudan a los profesionales a ir desde una hoja de papel (pantalla), a un bien organizado modelo o diseño relacionado a un sistema o componente del mismo.

Herramienta

        Las técnicas utilizan a menudo una variedad de herramientas que se desarrollan para tal fin; es decir, una herramienta es cualquier recurso particular a disposición de la metodología para realizar las operaciones que en ella se prevea. Estas generalmente están orientadas a: Diagramas, como expresiones gráficas para modelar los requerimientos y la arquitectura del sistema de información o componente del mismo.

        Entre los más usados tenemos:

Diagrama de Flujo de Datos (Data Flow Diagram)

Diagrama de Entidad Relación (Entity Relation Diagram)

Diagrama de Descomposición Funcional (Functional Decomposition Diagram)

Diagramas para O-O (de clases, de objetos, etc.)

       

        Formatos, que corresponden a documentos estandarizados para facilitar la documentación y comunicación.

        Repositorio, Diccionario o Enciclopedia, que es una base de datos utilizada como soporte en el Ciclo de Vida del Desarrollo de Sistemas de Información con base de datos. Permiten describir y registrar las características o atributos de cada componente u objeto de un sistema o base de datos.

        Especificaciones Lógicas, que permiten definir las unidades procedurales de un sistema o primitivas (funciones básicas) como lo llaman algunos autores. Por ejemplo: tablas de decisión, diagramas de acción, etc.

        Ken Orr dice: "Las herramientas tienen significado o toman vida dentro del contexto de la técnica o método del cual forman parte. Los diagramas por si solos pueden ser mal interpretados o usados fuera de su contexto, sin comprender el propósito para el cual fueron creados, ello puede llevar a confusiones y de ser así el desarrollo efectuado en base a aquellas premisas podría conducir a resultados incorrectos".

 

Herramientas para la gestión completa de Bases de Datos

        Las herramientas ofrecen potentes funciones para la automatización y el mantenimiento del ciclo de vida completo de una base de dato Realiza de forma transparente, las tareas más tediosas y repetitivas.

Ejemplo 2

Fase de Diseño

        Disponen de una sofisticada interfaz visual que le permite diseñar de forma precisa las bases de datos, capturando todos los detalles de la información que debe manejar. Los mecanismos de automatización y mantenimiento ayudan a completar el análisis y diseño de las bases de datos de manera completa e íntegra. Puede contener:

· Ingeniería inversa y directa

· Completas funciones gráficas para manejar proyectos complejos

· Funciones de adaptación de los diferentes editores y diccionarios de datos

· Potentes mecanismos de automatización de las relaciones de las bases de datos, claves, índices, etc.

· Mecanismos de herencia de atributos definibles por usuario

· Validación de objetos de la base de datos

Fase de Presentación

            Una vez completado el diseño de la base de datos, se generan diagramas de alta calidad, destinados a la presentación de su diseño desde diferentes puntos de vista y con varios niveles de detalle. Permite adaptar la presentación de cara a sus clientes o compañeros, facilitando así el proceso iterativo de análisis, diseño y presentación. La presentación permite:

· Controlar los colores, letras, anotaciones y otros elementos gráficos

· Resaltar gráficamente las relaciones padre/hijo

· Dividir su diseño en múltiples diagramas más manejables

· Incrustar un diagrama en otro

· Almacenar múltiples visualizaciones para un mismo diagrama

· Utilizar funciones de navegación y zoom

Fase de Documentación

        Una vez presentado el modelo de datos, es muy importante documentar su diseño, ya que éste constituye los cimientos de su futura aplicación. Aquí se pueden automatizar las tareas para la impresión de diagramas e informes con sus propios comentarios y atributos personales.

Fase de Generación del Código

           Tras haber documentado ampliamente el proyecto, es necesario la generación de todo el código relacionado con la base de datos como:

· Código DDL (Data Definition Language) para crear la base de datos

· Triggers y procedimientos almacenados para garantizar la integridad de los datos

· Vistas y consultas para extraer datos

· Código orientado a objeto que ofrece todos aquellos metadatos que su aplicación front-end pueda precisar.

Fase de Gestión de los Datos Físicos

        Se debe tener la capacidad de establecer un enlace directo entre el dominio conceptual y los datos físicos, de manera que resulta inmediato mover datos de una base de datos a otra, generar datos de prueba, y ver y editar datos físicos garantizando su integridad. Se debe poder:

· Migrar automáticamente los datos de una base de datos a otra diferente, construyendo la nueva base de datos si es necesario y realizando las oportunas conversiones.

· Validar los datos físicos para comprobar si cumplen las restricciones del modelo, se respeta la unicidad, no existen registros huérfanos y los campos enumerados contienen valores correctos, entre otras cosas.

· Ver y editar datos físicos.

Fase de Mantenimiento

        Finalmente, la aplicación está instalada y funcionando. De todas formas, es muy probable que su diseño requiera modificaciones y mejoras en un breve espacio de tiempo.

        Puesto que un modelo se compone de muchos metadatos interrelacionados, cualquier cambio puede tener muchas implicaciones. Por ejemplo, cuando añade un nuevo elemento a una clave primaria, es necesario crear claves foráneas, modificar o crear índices primarios y foráneos, cambiar reglas de integridad referencial, modificar vistas y triggers, etc.

Aspectos comunes

           De los ciclos de vida anteriores podemos observar que en los dos casos existe el diseño como primer punto, refiriéndose a grandes rasgos cómo va a ser nuestra futura base de datos. Incluyendo todos los campos de información necesaria que se va a utilizar, las descripciones, el rendimiento que se desea tener, la complejidad, el almacenamiento.

           Todo esto servirá para darnos una idea de cómo tendremos una base de datos, y poder saber si es factible o no llevarla a cabo.

        El segundo punto del primer ejemplo del ciclo de vida se refiere a las aproximaciones del diseño y en el segundo ejemplo a la fase de presentación. En la primera se trata por medio de preguntas mejorar el diseño anterior y abarcar más para poder concretar la base de datos al igual que representar por medios gráficos como quedaría la base de datos en un futuro. El segundo caso genera diagramas de alta calidad con diferentes puntos de vista para poder escoger la mejor presentación, También se eligen colores, texturas, letras, anotaciones entre otros.

            En el tercer punto del primer ejemplo se trata de las decisiones comunes en el diseño. En donde paralelamente al proceso mental de diseño, surgen una serie de consideraciones referidas a la selección de clave de acceso, selección de accesos, selección de definición física de accesos, selección de capacidad de almacenamiento, selección de tipo de usuario, selección del tipo de transacción, selección del proceso de copia de respaldo y recuperación. Todo esto se refiera a cómo hacer efectivo e implantar el punto uno y dos que hablaban del diseño. Ya se decide como realizar lo estudiado, la administración que se va a llevar, el mantenimiento. Es decir en el tercer punto del primer ejemplo se engloban muchas actividades que terminan por crear la base de datos.

          El tercer punto del segundo ejemplo nos habla de la documentación que es donde se empiezan a generar los cimientos de lo que será nuestra base de datos.

           El cuarto punto del segundo ejemplo es la generación del código, es aquí donde surge la base de datos y se puede llevar a cabo con diferentes lenguajes.

         El quinto punto se refiere al gestor de la base de datos físicos que es el encargado de poder realizar los enlaces directos entre el dominio conceptual y los datos físicos, de manera que resulte inmediato mover datos de una base de datos a otra, siempre y cuando se garantice su integridad.

           El sexto punto es el mantenimiento. Este punto es muy importante después de haber implantado y terminado la base de datos ya que ayuda a que no decaiga y se siga realizando todo a como se dispuso en su diseño e implementación. También es necesario el mantenimiento en caso de crecimiento o necesidad de hacer campos nuevos.

        Por conclusión tenemos que todo método es factible siempre y cuando se construya una base de datos con transparencia, integridad y automatizada. Sin importar el número de pasos que llegue a tener su método. Además que es de suma importancia tener mantenimiento continuo en las bases de datos, para estar monitoreando sus actividades y determinar si son necesarios cambios o no.

Propuesta del ciclo de vida del desarrollo de la base de datos

 

Estudiar necesidades

Definición de requisitos

Diseño

Presentación

Documentación

Implementación

Mantenimiento

=^..^=