ciclovida

5/24/2018 ciclovida

1/42

El ciclo de vida de un sistemade informacin

Un sistema de informacin es un sistema, automatizado o manual, que engloba a personas,mquinas y/o mtodos organizados para recopilar, procesar, transmitir datos que representaninformacin. Un sistema de informacin engloba la infraestructura, la organizacin, elpersonal y todos los componentes necesarios para la recopilacin, procesamiento,almacenamiento, transmisin, visualizacin, diseminacin y organizacin de la informacin.

5/24/2018 ciclovida

2/42

El ciclo de vida de un sistemade informacin

Las etapas del proceso de desarrollo de software ..............3

Planificacin............................................................... 4

Anlisis....................................................................... 9

Diseo...................................................................... 12

Implementacin........................................................ 18

Pruebas.................................................................... 19

Instalacin / Despliegue........................................... 20

Uso y mantenimiento ............................................... 21

Modelos de ciclo de vida ......................................................23

El ciclo de vida de una base de datos .................................30

El proceso de diseo de una base de datos.......................32

Fase 1: Anlisis de requerimientos.......................... 33

Fase 2: Diseo conceptual...................................... 34

Fase 3: Eleccin del SGBD..................................... 35

Fase 4: Diseo lgico.............................................. 36

Fase 5: Diseo fsico............................................... 37

Fase 6: Instalacin y mantenimiento....................... 38

Bibliografa.............................................................................40

2 Diseo de Bases de Datos

Fernando Berzal
mailto:[email protected]:[email protected]

5/24/2018 ciclovida

3/42

Las etapas del proceso de desarrollo de software

Cualquier sistema de informacin va pasando por una serie de fases a lo largo de su vida. Suciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:

- Planificacin

- Anlisis

- Diseo- Implementacin

- Pruebas

- Instalacin o despliegue

- Uso y mantenimiento

Estas etapas son un reflejo del proceso que se sigue a la hora de resolver cualquier tipo de

problema. Ya en 1945, mucho antes de que existiese la Ingeniera del Software, el matemticoGeorge Polya describi este proceso en su libro How to solve it(el primero que describe lautilizacin de tcnicas heursticas en la resolucin de problemas). Bsicamente, resolver unproblema requiere:

- Comprender el problema (anlisis)

- Plantear una posible solucin, considerando soluciones alternativas (diseo)

- Llevar a cabo la solucin planteada (implementacin)

- Comprobar que el resultado obtenido es correcto (pruebas)

Las etapas adicionales de planificacin, instalacin y mantenimiento que aparecen en el ciclode vida de un sistema de informacin son necesarias en el mundo real porque el desarrollo deun sistema de informacin conlleva unos costes asociados (lo que se hace necesaria laplanificacin) y se supone que, una vez construido el sistema de informacin, ste deberapoder utilizarse (si no, no tendra sentido haber invertido en su desarrollo).

Para cada una de las fases en que hemos descompuesto el ciclo de vida de un sistema deinformacin se han propuesto multitud de prcticas tiles, entendiendo por prcticas aquellos

3El ciclo de vida de un sistema de informacin

http://elvex.ugr.es/
http://csharp.ikor.org/http://csharp.ikor.org/

5/24/2018 ciclovida

4/42

conceptos, principios, mtodos y herramientas que facilitan la consecucin de los objetivos decada etapa.

En los prrafos siguientes se mencionan algunas de las actividades que han de realizarse encada una de las fases del ciclo de vida de un sistema de informacin:

Planificacin

Antes de que se le de oficialmente el pistoletazo de salida a un proyecto de desarrollo de unsistema de informacin, es necesario realizar una serie de tareas previas que influirndecisivamente en la finalizacin con xito del proyecto. Estas tareas se conocen popularmente

como el fuzzy front-enddel proyecto al no estar sujetas a plazos. Las tareas iniciales que serealizarn esta fase inicial del proyecto incluyen actividades tales como la determinacin delmbito del proyecto, la realizacin de un estudio de viabilidad, el anlisis de los riesgosasociados al proyecto, una estimacin del coste del proyecto, su planificacin temporal y laasignacin de recursos a las distintas etapas del proyecto.

Delimitacin del mbito del proyecto

Resulta esencial determinar el mbito del proyecto al comienzo del mismo. Han deestablecerse de antemano qu cuestiones han de resolverse durante la realizacin del proyecto

y cules se dejarn fuera. Tan importante es determinar los aspectos abarcados por el proyectocomo fijar aqullos aspectos que no se incluirn en el proyecto. Estos ltimos han de indicarseexplcitamente. Si es necesario, se puede especificar todo aquello que se posponga hasta unaversin posterior del sistema. Si, en algn momento, fuese necesario incluir en el proyectoalgn aspecto que no haba sido considerado o que ya haba sido descartado, es obligatorioreajustar la estimacin del coste del proyecto y su planificacin temporal.

Como resultado de la delimitacin del mbito del proyecto se obtiene un documento breve, de1 2 pginas, en el que se describe el problema que nuestro sistema de informacin pretenderesolver. Este documento, denominado a veces mission statement o project charter, debeexistir siempre en todo proyecto. En l se recoger la descripcin de ms alto nivel de lafuncionalidad que tendr nuestro sistema de informacin, sus caractersticas principales y susobjetivos clave. Obviamente, este documento debe formar parte del contrato que se firme conel cliente en el arranque oficial del proyecto.

Adems de ser breve, una buena descripcin del proyecto debe superar con xito la pruebadel ascensor. Debe estar escrito en un lenguaje que cualquiera pueda entender, evitando unvocabulario excesivamente tcnico. Adems, debe recoger todo lo que le contaramos a unconocido en unos segundos acerca del proyecto en el que estamos trabajando si nos locruzramos por la calle o nos lo encontrsemos en un ascensor.


Fernando Berzal

5/24/2018 ciclovida

5/42

Estudio de viabilidadCon recursos ilimitados (tiempo y dinero), casi cualquier proyecto se podra llevar a buenpuerto. Por desgracia, en la vida real los recursos son ms bien escasos, por lo que no todoslos proyectos son viables. En un conocido informe de 1994 (el informe Chaos del StandishGroup), se hizo un estudio para determinar el alcance de la conocida como "crisis crnica dela programacin" y, en la medida de lo posible, identificar los principales factores que hacenfracasar proyectos de desarrollo de software y los ingredientes clave que pueden ayudar areducir el ndice de fracasos. De entre los proyectos analizados:

- Slo uno de cada seis se complet a tiempo, de acuerdo con su presupuesto y con

todas las caractersticas inicialmente especificadas.- La mitad de los proyectos lleg a completarse eventualmente, costando ms de lo

previsto, tardando ms tiempo del estimado inicialmente y con menoscaractersticas de las especificadas al comienzo del proyecto.

- Por ltimo, ms de un 30% de los proyectos se cancel antes de completarse.

Dado que cinco de cada seis proyectos analizados no se ajustaron al plan previsto, no es deextraar que resulte aconsejable realizar un estudio de viabilidad antes de comenzar eldesarrollo de un sistema de informacin para determinar si el proyecto es econmica, tcnicas

y legalmente viable. De hecho, lo primero que deberamos hacer es plantearnos si la mejoropcin es desarrollar un sistema informatizado o es preferible un sistema manual. Algo asdebieron hacer los rusos cuando decidieron llevar lpices al espacio (segn dicen, losamericanos gastaron una fortuna hasta que inventaron un bolgrafo que funcionaba enausencia de gravedad).

Antes de comenzar un proyecto, se debera evaluar la viabilidad econmica, tcnica y legaldel mismo. Y no slo eso, el resultado del estudio de viabilidad debera ajustarse a la realidad.A Jerry Weinberg, un conocido consultor, se le ocurri preguntar a los asistentes a unaconferencia suya, en el Congreso Internacional de Ingeniera del Software de 1987, cuntos deellos haban participado en un estudio de viabilidad en el que se hubiese determinado que elproyecto no era tcnicamente viable. De los mil quinientos asistentes, nadie levant la mano.

Anlisis de riesgos

Independientemente de la precisin con la que hayamos preparado nuestro proyecto, siemprese produce algn contratiempo que eche por tierra la mejor de las planificaciones. Es algoinevitable con lo que hemos de vivir y para lo cual disponemos de una herramientaextremadamente til: la gestin de riesgos, que tradicionalmente se descompone enevaluacin de riesgos y control de riesgos.



5/24/2018 ciclovida

6/42

La evaluacin de riesgos se utiliza para identificar "riesgos" que pueden afectarnegativamente al plan de nuestro proyecto, estimar la probabilidad de que el riesgo sematerialice y analizar su posible impacto en nuestro proyecto. Qu sucedera si algnmiembro clave del nuestro equipo abandona la empresa, se va de vacaciones, se pone enfermoo pide una baja por depresin causada por un entorno de trabajo hostil? y si al final nosencontramos con algn problema de compatibilidad del sistema que hemos desarrollamos conla configuracin de los equipos sobre los que ha de funcionar? si, inadvertidamente,borramos o modificamos errneamente algn que otro fichero clave? si nuestro ordenador seavera?

Una vez analizados los riesgos potencialmente ms peligrosos, podemos recurrir a distintastcnicas de control de riesgos. Por ejemplo, podemos elaborar planes de contingencia para losriesgos que sean ms probables y de consecuencias ms desastrosas para el proyecto. O tal

vez seamos capaces de eliminar el riesgo de raz (o mitigarlo) si buscamos alguna alternativaen la que el riesgo identificado no pueda presentarse (o se presente debilitado).Independientemente de la solucin por la que optemos, el anlisis de riesgos nos ensea quehemos de dejar un margen para imprevistos previsibles y aadir cierta holgura a laplanificacin de nuestro proyecto. Las hiptesis barajadas al analizar riesgos potencialespueden convertirse en realidad y nunca est de ms dejar algo de margen de maniobra.

Estimacin

Sin duda, una de las tareas ms peliagudas de cualquier proyecto de desarrollo de software es

la estimacin inicial del coste de algo que an no conocemos. De hecho, la realizacin demalas estimaciones ha sido identificada como una de las dos causas ms comunes del fracasode un proyecto de desarrollo de software (Glass, 2003). La otra es la existencia derequerimientos inestables sujetos a continuos cambios.

Como dijo Bhr, la prediccin es difcil, especialmente si se trata del futuro. Adems, laestimacin del coste asociado se suele realizar en el peor momento posible: al comienzo,cuando menos conocemos del proyecto y mayor es el margen del error de la estimacin.Afortunadamente, existen algunas reglas heursticas que nos pueden ayudar a estimar con unaprecisin razonable el coste y duracin de un proyecto. El arte de una buena estimacin estbasado, fundamentalmente, en la experiencia del estimador. Haber participado en proyectos

de similares caractersticas puede ser esencial para que seamos capaces de realizar una buenaestimacin. Tambin podemos obtener resultados aceptables si tenemos en cuenta losiguiente:

- Nunca se ha de realizar una estimacin sobre la marcha, por mucho que nospresionen. Una respuesta apresurada slo sirve para pillarnos los dedos y quedespus no podamos cumplir con las expectativas que nosotros mismos hemoscreado. Una estimacin siempre ha de ser meditada, tras un estudiopormenorizado de los distintos factores que pueden afectar a la realizacin denuestro proyecto.


Fernando Berzal

5/24/2018 ciclovida

7/42

- La incertidumbre en la estimacin es inevitable, pero en ocasiones puede

reducirse. Cuantos ms datos histricos recopilemos y ms precisa sea lainformacin de la que dispongamos acerca de nuestro proyecto, mejor ser nuestraestimacin.

- Hemos de descomponer nuestro proyecto en tareas de la granularidad adecuada.El error que se comete al estimar el conjunto de las actividades del proyecto esmayor que el que se comete cuando estimamos cada una de las actividades porseparado. Los errores que cometamos en las distintas estimaciones tendern acompensarse (la ley de los grandes nmeros en accin).

- Es muy frecuente subestimar el esfuerzo necesario cuando descomponemos unproblema complejo en multitud de tareas. Esto se debe a que, durante eltranscurso del proyecto, tambin han de realizarse otras muchas tareas queprobablemente hayamos olvidado incluir en nuestra estimacin. Adems,consideradas de forma independiente, las distintas tareas del proyecto resultanaparentemente ms fciles de realizar de lo que en realidad son.

- Resulta aconsejable utilizar varias tcnicas de estimacin y contrastar losresultados con ellas obtenidos. Por ejemplo, podemos realizar una estimacin enfuncin del coste un proyecto similar, utilizar algn modelo matemtico deestimacin (COCOMO o similar) y realizar una tercera estimacindescomponiendo nuestro proyecto en tareas. Si los resultados obtenidos con lasdistintas tcnicas de estimacin son similares, probablemente nuestra estimacin

sea buena.

Planificacin temporal y asignacin de recursos

Una vez que hemos decidido seguir adelante con nuestro proyecto, hemos de planificar sutemporizacin. Una planificacin excesivamente detallada (con el proyecto descompuesto entareas de un da, por ejemplo) puede resultar contraproducente. Cualquier error deplanificacin causado por algn imprevisto nos forzar a replanificar el resto del proyecto,retrasando an ms nuestro proyecto. Una planificacin por semanas suele ser razonable paraafrontar con comodidad las contingencias con las que nos vayamos encontrando sin tener queestar continuamente reajustando el plan del proyecto.

Pase lo que pase, la planificacin del proyecto ha de reajustarse cada vez que cambien lascircunstancias del mismo. Si no se ha podido terminar una tarea en el tiempo inicialmenteestablecido, no nos vale suponer alegremente que posteriormente se recuperar el tiempoperdido. Los proyectos se retrasan poco a poco. Debemos aprovechar las primeras seales dealarma y no esconderlas debajo de la alfombra fingiendo que todo marcha segn lo previsto.

Tampoco vale decir que algo est casi terminado. O lo est o no lo est. Si no lo est, el planha de ajustarse a la situacin real del proyecto. Pensar que algo est casi acabado slo sirve



5/24/2018 ciclovida

8/42

para darnos una falsa sensacin de seguridad. Adems, el 10% final de algo tiende a requerirel 90% del tiempo, as que no nos sirve de nada saber que hemos realizado 80% del esfuerzosi no podemos asegurar a qu parte corresponde el 20% que nos queda (a la que se terminarpidamente o a la que consume la mayor parte de nuestro tiempo?). Como dice un viejoadagio: "la primera mitad se lleva el 90% del tiempo; la segunda, el 90% restante". No usenunca en su planificacin el hecho de que determinadas actividades del proyecto estn casiterminadas.

La planificacin es fundamental en la gestin de un proyecto de desarrollo de software.Procure siempre mantener su plan al da. Un plan que no se ajusta a la realidad no sirve demucho. Cuando algn retraso indique que posiblemente le ser imposible cumplir los plazosestablecidos, hable con su cliente. A l le interesa saberlo y, aunque probablemente no se loagradezca, a la larga resultar beneficioso y usted habr cumplido con su obligacin

profesional.

Algunos errores comunes

Cuando las cosas no marchen del todo bien, hemos de evitar tomar algunas medidasque lo nico que conseguirn es perjudicarnos. Aqu van algunas de las ms comunes:

- Abreviar las etapas iniciales del proceso de desarrollo de software (planificaciny anlisis, generalmente) para pasar directamente a la "construccin" del sistema.Los errores cometidos en las fases iniciales de un proyecto son mucho mscostosos de corregir a la larga, por lo que abreviar las etapas iniciales tienegraves consecuencias.

- No gestionar adecuadamente los cambios que inevitablemente ocurren durante elproyecto. Tan malo es permitir cualquier cambio de forma indiscriminada comoser excesivamente rgidos a la hora de no admitir cambios aunque stos seanrazonables.

- Reducir la interaccin con el cliente, ya que aparentemente slo se dedica aentorpecer nuestro trabajo con sus continuos cambios de opinin y susexpectativas poco realistas. Craso error. Al fin y al cabo, el cliente es la personacuyas necesidades hemos de descubrir y satisfacer.

- Olvidar que aadir personal a un proyecto retrasado, por lo general, slo loretrasa ms (la ley de Brooks). La curva de aprendizaje que se necesita paracomenzar a ser productivo ha de tenerse siempre en cuenta. Adems, quin leresuelve las dudas al recin incorporado? El tiempo que empleen los demsmiembros del equipo ser tiempo que no podrn utilizar en otras cosas.

- Someter a los miembros de nuestro equipo a continuas interrupciones durante sujornada de trabajo (llamadas telefnicas, reuniones, consultas...). Las calidad deltrabajo intelectual depende de la capacidad del trabajador de mantener su "estado


Fernando Berzal

5/24/2018 ciclovida

9/42

Algunos errores comunes

de flujo" (un estado relajado de inmersin total en un problema que facilita sucomprensin y la generacin de soluciones). Se tarda unos 15 minutos enconseguir este estado, por lo que una simple interrupcin cada 10 minutos afectadrsticamente al rendimiento del trabajador.

- Hacer trabajar horas extra a los miembros del equipo de desarrollo slo sirvepara disminuir su productividad (trabajo realizado por unidad de tiempo). Trasun larga jornada de trabajo, la mente pierde su frescura y comete errores queluego tendrn que corregirse. Adivina cmo? Con ms horas extra.

- No informar de pequeos retrasos pensando que ms tarde se recuperar el

tiempo perdido. La planificacin temporal del proyecto debe ir ajustndoseconforme vamos aprendiendo ms cosas acerca del problema al que nosenfrentamos. En el peor de los casos, se deben negociar algunos recortes con elcliente si ste desea mantener los plazos estipulados al comienzo del proyecto.

- Confiar excesivamente en la mejora de rendimiento que se producir gracias aluso de una nueva herramienta, tecnologa o metodologa (error conocido como el"sndrome de la bala de plata" en honor a un artculo muy recomendable escritopor Fred Brooks: No silver bullets - Essence and accidents of SoftwareEngineering,Computer, 1987).

Observe el tipo de errores comunes que aparece en la lista anterior. En general, noprestar la debida atencin a las necesidades de los integrantes del equipo de desarrolloo a las del cliente garantiza que un proyecto no terminar con xito. El factor humanoes ms importante que el tcnico.

Anlisis

Lo primero que debemos hacer para construir un sistema de informacin es averiguar qu esexactamente lo que tiene que hacer el sistema. La etapa de anlisis en el ciclo de vida delsoftware corresponde al proceso mediante el cual se intenta descubrir qu es lo que realmentese necesita y se llega a una comprensin adecuada de los requerimientos del sistema (lascaractersticas que el sistema debe poseer).

Por qu resulta esencial la etapa de anlisis? Simplemente, porque si no sabemos conprecisin qu es lo que se necesita, ningn proceso de desarrollo nos permitir obtenerlo. Elproblema es que, de primeras, puede que ni nuestro cliente sepa de primeras qu esexactamente lo que necesita. Por tanto, deberemos ayudarle a averiguarlo con ayuda dedistintas tcnicas (algunas de las cuales aprenderemos a utilizar ms adelante).



5/24/2018 ciclovida

10/42

Por qu es tan importante averiguar exactamente cules son los requerimientos del sistemasi el software es fcilmente maleable (aparentemente)? Porque el coste de construircorrectamente un sistema de informacin a la primera es mucho menor que el coste deconstruir un sistema que habr que modificar ms adelante. Cuanto antes se detecte un error,mejor. Distintos estudios han demostrado que eliminar un error en las fases iniciales de unproyecto (en la etapa de anlisis) resulta de 10 a 100 veces ms econmico que subsanarlo alfinal del proyecto. Conforme avanza el proyecto, el software se va describiendo con un mayornivel de detalle, se concreta cada vez ms y se convierte en algo cada vez ms rgido.

Es posible determinar de antemano todos los requerimientos de un sistema de informacin?Desgraciadamente, no. De hecho, una de las dos causas ms comunes de fracaso en proyectosde desarrollo de software es la inestabilidad de los requerimientos del sistema (la otra es unamala estimacin del esfuerzo requerido por el proyecto). En el caso de una mala estimacin,

el problema se puede solucionar estableciendo objetivos ms realistas. Sin embargo, en lasetapas iniciales de un proyecto, no disponemos de la informacin necesaria para determinarexactamente el problema que pretendemos resolver. Por mucho tiempo que le dediquemos alanlisis del problema (un fenmeno conocido como la parlisis del anlisis).

La inestabilidad de los requerimientos de un sistema es inevitable. Se estima que un 25% delos requerimientos iniciales de un sistema cambian antes de que el sistema comience autilizarse. Muchas prcticas resultan efectivas para gestionar adecuadamente losrequerimientos de un sistema y, en cierto modo, controlar su evolucin. Un buen analistadebera tener una formacin adecuada en:

- Tcnicas de elicitacin de requerimientos.

- Herramientas de modelado de sistemas.

- Metodologas de anlisis de requerimientos.

Tcnicas de elicitacin de requerimientos

En la fase de anlisis, los errores ms difciles de corregir son los causados por"requerimientos ausentes", generalmente en la forma de suposiciones que se dan por sabidas

pero nunca se llegan a plasmar explcitamente. Por este motivo, elicitar los requerimientos deun sistema de informacin (esto es, obtener de algn modo cules son realmente esosrequerimientos) resulta una actividad esencial en cualquier proceso de desarrollo de software.

La elicitacin de requerimientos requiere previamente la identificacin de las personasafectadas por el proyecto, sus stakeholders (literalmente, los que apuestan algo), lo queincluye desde el cliente que paga el proyecto hasta los usuarios finales de la aplicacin, sinolvidarse de terceras personas y organizaciones relacionadas indirectamente con el sistemaque se va a desarrollar (por ejemplo, empresas competidoras y organismos reguladores).


Fernando Berzal

5/24/2018 ciclovida

11/42

En la elicitacin de requerimientos se recurre a distintas tcnicas que favorezcan lacomunicacin entre el analista y el resto de personas involucradas, como puede ser larealizacin de entrevistas (en las que importa no slo lo que se pregunta, sino cmo sepregunta), el diseo de cuestionarios (cuando no tenemos tiempo ni recursos para entrevistarpersonalmente a todo el mundo) o el desarrollo de prototipos (para recoger informacin que,de otra forma, no obtendramos hasta las etapas finales del proyecto, cuando cualquierrectificacin saldra mucho ms cara). Tambin se puede observar el funcionamiento normaldel entorno en el que se instalar nuestro sistema o, incluso, participar activamente en l (porejemplo, desempeando temporalmente el trabajo de los usuarios de nuestro sistema). Porltimo, tambin podemos investigar por nuestra cuenta consultando documentos relacionadoscon el tema de nuestro proyecto o estudiando productos similares que ya existan en elmercado.

Herramientas de modelado de sistemas

Un modelo, bsicamente, no es ms que una simplificacin de la realidad. El uso de modelosen la construccin de sistemas de informacin resulta esencial por los siguientes motivos:

- Los modelos ayudan a comunicar la estructura de un sistema complejo (y, portanto, a comunicarnos con las dems personas involucradas en un proyecto).

- Los modelos sirven para especificar el comportamiento deseado del sistema(como gua para las etapas posteriores del proyecto).

- Los modelos nos ayudan a comprender mejor lo que estamos diseando (porejemplo, para detectar inconsistencias y corregirlas).

- Los modelos nos permiten descubrir oportunidades de simplificacin (ahorrarnostrabajo en el proyecto actual) y de reutilizacin (ahorrarnos trabajo en futurosproyectos).

En resumidas cuentas, los modelos, entre otras cosas, facilitan el anlisis de losrequerimientos del sistema, as como su posterior diseo e implementacin. Un modelo, endefinitiva, proporciona "los planos" de un sistema. El modelo ha de capturar "lo esencial"

desde determinado punto de vista. En funcin de para qu queramos el modelo, lo haremosms o menos detallado, siempre de acuerdo a su relevancia y utilidad.

Un sistema de informacin es un sistema complejo, por lo que a (casi) nadie se le ocurriraintentar describirlo utilizando un nico modelo. De hecho, todo sistema puede describirsedesde distintos puntos de vista y nosotros utilizaremos distintos tipos de modelos dependiendodel aspecto del sistema en que deseemos centrar nuestra atencin:

- Existen modelos estructuralesque nos ayudan a la hora de organizar un sistemacomplejo. Por ejemplo, un diagrama entidad/relacin nos indica cmo se



5/24/2018 ciclovida

12/42

estructuran los datos de un sistema de informacin, mientras que un diagrama de

flujo de datos nos da informacin acerca de cmo se descompone un sistema ensubsistemas y del flujo de datos que existe entre los distintos subsistemas.

- Tambin existen modelos de comportamiento que nos permiten analizar ymodelar la dinmica de un sistema. Por ejemplo, un diagrama de estadosrepresenta los distintos estados en que puede encontrarse un sistema y cmo sepuede pasar de un estado a otro, mientras que la descripcin de un caso de uso nosayuda a comprender la secuencia de pasos involucrada en la consecucin de unobjetivo concreto por parte de un usuario del sistema.

Ms adelante aprenderemos las notaciones asociadas a distintos tipos de modelos cuya

utilizacin resulta recomendable en el diseo de un sistema de informacin. Aprenderemos susignificado, veremos su utilidad y ofreceremos algunos consejos heursticos acerca de sucorrecto uso.

Metodologas de anlisis de requerimientos

Las tcnicas de elicitacin de requerimientos y las herramientas de modelado de sistemas delas que hemos hablado en los prrafos anteriores deben utilizarse acompaadas de unametodologa adecuada. En este contexto, una metodologa no es ms que un conjunto deconvenciones que han resultado tiles en la prctica y cuyo uso combinado se recomienda.

Las metodologas de anlisis particulares, de las que hay muchas, usualmente estn ligadas, obien al uso de determinadas herramientas (por lo que el vendedor de la herramienta seconvierte, muchas veces, en el nico promotor de la metodologa), o bien a empresas deconsultora concretas (que ofrecen cursos de aprendizaje de la metodologa que proponen).

En general, no obstante, la eleccin adecuada de las tcnicas utilizadas depender de lasituacin concreta en la que se encuentre nuestro proyecto. Por este motivo, lo ms adecuadoes aprender cuantas ms tcnicas mejor y averiguar en qu situaciones resulta ms efectivacada una de ellas.

Diseo

Mientras que los modelos utilizados en la etapa de anlisis representan los requisitos delusuario desde distintos puntos de vista (el qu), los modelos que se utilizan en la fase dediseo representan las caractersticas del sistema que nos permitirn implementarlo de formaefectiva (el cmo).

Un software bien diseado debe exhibir determinadas caractersticas. Su diseo debera sermodular en vez de monoltico. Sus mdulos deberan ser cohesivos (encargarse de una tarea


Fernando Berzal

5/24/2018 ciclovida

13/42

concreta y slo de una) y estar dbilmente acoplados entre s (para facilitar el mantenimientodel sistema). Cada mdulo debera ofrecer a los dems unos interfaces bien definidos (alestilo del diseo por contrato propuesto por Bertrand Meyer) y ocultar sus detalles deimplementacin (siguiendo el principio de ocultacin de informacin de Parnas). Por ltimo,debe ser posible relacionar las decisiones de diseo tomadas con los requerimientos delsistema que las ocasionaron (algo que se suele denominar "trazabilidad de losrequerimientos").

En la fase de diseo se han de estudiar posibles alternativas de implementacin para elsistema de informacin que hemos de construir y se ha de decidir la estructura general quetendr el sistema (su diseo arquitectnico). El diseo de un sistema es complejo y elproceso de diseo ha de realizarse de forma iterativa. La solucin inicial que propongamosprobablemente no resulte la ms adecuada para nuestro sistema de informacin, por lo que

deberemos refinarla. Afortunadamente, tampoco es necesario que empecemos desde cero.Existen autnticos catlogos de patrones de diseo que nos pueden servir para aprender de loserrores que otros han cometido sin que nosotros tengamos que repetirlos.

Igual que en la etapa de anlisis crebamos distintos modelos en funcin del aspecto delsistema en que centrbamos nuestra atencin, el diseo de un sistema de informacin tambinpresenta distintasfacetas:

- Por un lado, es necesario abordar el diseo de la base de datos, un tema quetrataremos detalladamente ms adelante.

- Por otro lado, tambin hay que disear lasaplicacionesque permitirn al usuarioutilizar el sistema de informacin. Tendremos que disear la interfaz de usuariodel sistema y los distintos componentes en que se descomponen las aplicaciones.De esto ltimo hablaremos en las dos secciones siguientes.

Arquitecturas multicapa

La divisin de un sistema en distintas capas o niveles de abstraccin es una de las tcnicasms comunes empleadas para construir sistemas complejos. Esta divisin se puede apreciar enel hardware, donde el diseo de un sistema en un lenguaje de alto nivel como VHDL oVerilog se traduce en un diseo a nivel de registros lgicos (RTL); ste se implementamediante puertas lgicas, a partir de las cuales se obtiene un diseo a nivel de transistores; lostransistores, finalmente, se crean en un circuito integrado con una serie de mscaras. Losprotocolos de red tambin se disean utilizando distintas capas: la capa de aplicacin (HTTP)utiliza los servicios de la capa de transporte (TCP), la cual se implementa sobre la capa de red(IP) y as sucesivamente hasta llegar a la transmisin fsica de los datos a travs de algnmedio de transmisin.

En realidad, el uso de capas es una forma ms de la tcnica de resolucin de problemasconocida con el nombre de "divide y vencers", que se basa en descomponer un problema



5/24/2018 ciclovida

14/42

complejo en una serie de problemas ms sencillos de forma que se pueda obtener la solucinal problema complejo a partir de las soluciones a los problemas ms sencillos. Al dividir unsistema en capas, cada capa puede tratarse de forma independiente (sin tener que conocer losdetalles de las dems).

Desde el punto de vista de la Ingeniera del Software, la divisin de un sistema en capasfacilita el diseo modular (cada capa encapsula un aspecto concreto del sistema) y permite laconstruccin de sistemas dbilmente acoplados (si minimizamos las dependencias entrecapas, resultar ms fcil sustituir la implementacin de una capa sin afectar al resto delsistema). Adems, el uso de capas tambin fomenta la reutilizacin (p.ej. TCP/IP se utiliza enuna amplia variedad de aplicaciones, desde HTTP y FTP hasta telnet y SSH).

Como es lgico, la parte ms difcil en la construccin de un sistema multicapa es decidir

cuntas capas utilizar y qu responsabilidades asignarle a cada capa.En las arquiecturas cliente/servidor se suelen utilizar dos capas. En el caso de lasaplicaciones informticas de gestin, esto se suele traducir en un servidor de bases de datos enel que se almacenan los datos y una aplicacin cliente que contiene la interfaz de usuario y lalgica de la aplicacin.

El problema con esta descomposicin es que la lgica de la aplicacin suele acabar mezcladacon los detalles de la interfaz de usuario, dificultando las tareas de mantenimiento a que todosoftware se ve sometido y destruyendo casi por completo la portabilidad del sistema, quequeda ligado de por vida a la plataforma para la que se dise su interfaz en un primermomento.

Mantener la misma arquitectura y pasar la lgica de la aplicacin al servidor tampoco resultauna solucin demasiado acertada. Se puede implementar la lgica de la aplicacin utilizandoprocedimientos almacenados, pero stos suelen tener que implementarse en lenguajesestructurados no demasiado verstiles. Adems, suelen ser lenguajes especficos para cadatipo de base de datos, por lo que la portabilidad del sistema se ve gravemente afectada.

La solucin, por tanto, pasa por crear nueva capa en la que se separe la lgica de la aplicacinde la interfaz de usuario y del mecanismo utilizado para el almacenamiento de datos. Elsistema resultante tiene tres capas:

- La capa depresentacin, encargada de interactuar con el usuario de la aplicacinmediante una interfaz de usuario (ya sea una interfaz web, una interfaz Windowso una interfaz en lnea de comandos, aunque esto ltimo suele ser menos habitualen la actualidad).

- Lalgica de la aplicacin[a la que se suele hacer referencia comobusiness logico domain logic], usualmente implementada utilizando un modelo orientado aobjetos del dominio de la aplicacin, es la responsable de realizar las tareas paralas cuales se disea el sistema.


Fernando Berzal

5/24/2018 ciclovida

15/42

- La capa de acceso a los datos, encargada de gestionar el almacenamiento de los

datos, generalmente en un sistema gestor de bases de datos relacionales, y de lacomunicacin del sistema con cualquier otro sistema que realice tareas auxiliares(p.ej. middleware).

Cuando el usuario del sistema no es un usuario humano, se hace evidente la similitud entre lascapas de presentacin y de acceso a los datos. Teniendo esto en cuenta, el sistema puede versecomo un ncleo (lgica de la aplicacin) en torno al cual se crean una serie de interfaces conentidades externas. Esta vista simtrica del sistema es la base de la arquitectura hexagonaldeAlistair Cockburn.

No obstante, aunque slo fuese por las peculiaridades del diseo de interfaces de usuario,

resulta til mantener la vista asimtrica del software como un sistema formado por tres capas.Por ejemplo, la interfaz de usuario debe permitir que el usuario se pueda equivocar (yrectificar de la manera menos traumtica posible) y estar especialmente diseada para agilizarsu trabajo (y nunca entorpecerlo). Adems, suele ser recomendable diferenciar lo que sesuministra (presentacin) de lo que se consume (acceso a los servicios suministrados por otrossistemas).

A pesar del atractivo de esta arquitectura con tres capas (basta con pensar lo que facilitara laconversin de aplicaciones Windows en aplicaciones web), esta arquitectura no se haimpuesto del todo porque las herramientas de desarrollo suelen estar diseadas para construiraplicaciones cliente/servidor ligadas a algn productor de software. De hecho, puede resultardifcil (e incluso imposible) descomponer un sistema en tres capas con determinadasherramientas de desarrollo.

Notas acerca del diseo de las aplicaciones

Si suponemos que hemos sido capaces de separar el ncleo de la aplicacin de sus distintosinterfaces, an nos queda por decidir cmo vamos a organizar la implementacin de la lgicaasociada a la aplicacin. Como en cualquier otra tarea de diseo, tenemos que llegar a uncompromiso adecuado entre distintos intereses. Por un lado, nos gustara que el diseoresultante fuese lo ms sencillo posible. Por otro lado, sera deseable que nuestro diseoestuviese bien preparado para soportar las modificaciones que hayan de realizarse en elfuturo.

Por lo general, el diseo de la lgica una aplicacin se suele ajustar a uno de los tressiguientes patrones de diseo:

- Rutinas: La forma ms simple de implementar cualquier sistema se basa enimplementar procedimientos y funciones que acepten y validen las entradasrecibidas de la capa de presentacin, realicen los clculos necesarios, utilicen losservicios de aquellos sistemas que hagan falta para completar la operacin,



5/24/2018 ciclovida

16/42

almacenen los datos en las bases de datos y enven una respuesta adecuada al

usuario. Bsicamente, cada accin que el usuario pueda realizar se traducir en unprocedimiento que realizar todo lo que sea necesario al ms puro estilo deldiseo estructurado tradicional. Aunque este modelo sea simple y pueda resultaradecuado a pequea escala, la evolucin de las aplicaciones diseadas de estaforma suele acabar siendo una pesadilla para las personas encargadas de sumantenimiento.

- Mdulos de datos: Ante la situacin descrita en el prrafo anterior, lo usual esdividir el sistema utilizando los distintos conjuntos de datos con los que trabaja laaplicacin para crear mdulos ms o menos independientes. De esta forma, sefacilita la eliminacin de lgica duplicada. De hecho, muchos de los entornos dedesarrollo visual de aplicaciones permiten definir mdulos de datos queencapsulen los conjuntos de datos con los que se trabaja y la lgica asociada aellos. Las herramientas de Borland, Delphi y C++Builder, son un claro ejemplo,igual que el Developer de Oracle. Microsoft, en su arquitectura DNA [DistributedinterNet Application], fomenta este estilo al emplear conjuntos de datos (resultadode ejecutar consultas SQL) sobre los cuales operan directamente las distintascapas de una aplicacin multicapa. En el caso de la plataforma .NET, la claseDataSetproporciona la base sobre la que se montara todo el diseo de unaaplicacin (algo que obviamente facilita el Visual Studio .NET).

- Modelo del dominio: Una tercera opcin, la ideal para cualquier purista de laorientacin a objetos, es crear un modelo orientado a objetos del dominio de la

aplicacin. En vez de que una rutina se encargue de todo lo que haya que hacerpara completar una accin, cada objeto es responsable de realizar las tareas que leataen directamente.

En la prctica, no todo es blanco o negro. Aunque empleemos un modelo orientado a objetosdel dominio de la aplicacin, es habitual crear una capa intermedia entre la capa depresentacin y la lgica de la aplicacin a la que se suele denominar capa de servicio. Lainterfaz de la capa de servicio incluir mtodos asociados a las distintas acciones que puedarealizar el usuario, si bien, en vez de incluir en ella la lgica de la aplicacin, la capa deservicio delega inmediatamente en los objetos responsables de cada tarea. En cierto modo, lacapa de servicio se encarga de la lgica especfica de la aplicacin, dejando para el modelo

del dominio la lgica del dominio (comn a cualquier aplicacin que se construya sobre elmismo dominio de aplicacin).

Cualquier aplicacin sufre modificaciones de mayor o menor importancia a lo largo de suvida til. Dichas modificaciones alteran el diseo inicial de la aplicacin y tienden a aumentarsu entropa. Si utilizamos rutinas para implementar la lgica de nuestra aplicacin en elsentido tradicional, las modificaciones pueden suponer tener que revisar el cdigo completode la aplicacin para descubrir lo que hay que actualizar. Es como si tuvisemos unahabitacin completamente desordenada en la que hay que encontrar algo en particular. En elcaso de los mdulos de datos, el impacto de las modificaciones suele ser ms fcil de


Fernando Berzal

5/24/2018 ciclovida

17/42

determinar pero, an as, podemos encontrarnos con sorpresas desagradables si todos losmdulos de nuestra aplicacin trabajan sobre un conjunto de datos cuya estructura debemosalterar ligeramente. Por ltimo, si diseamos un buen modelo orientado a objetos, laencapsulacin proporcionada por los objetos de nuestra aplicacin permitir que el impacto delas modificaciones sea de carcter local en la mayora de las ocasiones. En cierto modo,estamos limitando el aumento de la entropa al interior de los cajones (algo que la mayora denosotros tolera sin demasiados problemas).

Sobre el acceso a los datos

Existen distintas formas en las que una aplicacin implementada utilizando unlenguaje de programacin de propsito general puede acceder a los datos, almacenadospor lo general en una base de datos relacional:

- La primera opcin que se nos puede ocurrir cuando diseamos un sistemaorientado a objetos es utilizar un registros activos, objetos que encapsulandirectamente las estructuras de datos externas (p.ej. las tuplas de las tablas de labase de datos) e incorporan la lgica del dominio que les corresponda, aparte delas operaciones necesarias para obtener y guardar objetos en la base de datos.

- Algo ms adecuado puede resultar el empleo de gateways, clases auxiliares quese corresponden con las tablas de la base de datos e implementan las operacionesnecesarias para manipular la base de datos [CRUD: Create, Retrieve, Update &Delete]. Estas clases auxiliares nos permiten no mezclar la lgica de laaplicacin con el acceso a los datos externos, tal como sucede si utilizamosregistros activos.

- La tercera opcin (y siempre hay una tercera opcin) es la ms compleja pero lams flexible:O/R Mapping. Se basa en establecer una correspondencia entre elmodelo orientado a objetos del dominio y la representacin de los distintosobjetos en una base de datos relacional. En las dos alternativas anteriores, losobjetos de la aplicacin han de ser conscientes de cmo se representan en la basede datos. En el caso del O/R Mapping, los objetos pueden ignorar la estructura dela base de datos y cmo se realiza la comunicacin con la base de datos. Lainversin de control caracterstica de esta opcin independiza el modelo

orientado a objetos del dominio de la capa de acceso a los datos: se puedecambiar la base de datos sin tener que tocar el modelo orientado a objetos deldominio y viceversa. De esta forma, se facilita el desarrollo, la depuracin y laevolucin de las aplicaciones.

Cuando para implementar la aplicacin se utiliza una herramienta de programacinvisual (tipo Visual Studio .NET, C++Builder, Delphi o Developer), generalmente nopodemos elegir la forma en que nuestra aplicacin acceder a los datos. Pese a ello,siempre existe cierto margen de maniobra que podemos aprovechar para disearnuestro sistema lo mejor posible.



5/24/2018 ciclovida

18/42

Aviso

Las etapas posteriores del ciclo de vida de un sistema deinformacin (implementacin, pruebas, despliegue, uso ymantenimiento) se describen a continuacin con menor gradode detalle que las anteriores (planificacin, anlisis y diseo)porque su influencia es significativamente menor sobre elproceso de diseo de bases de datos.

Implementacin

Una vez que sabemos qu funciones debe desempear nuestro sistema de informacin(anlisis) y hemos decidido cmo vamos a organizar sus distintos componentes (diseo), es elmomento de pasar a la etapa de implementacin, pero nunca antes. Antes de escribir una solalnea de cdigo (o de crear una tabla en nuestra base de datos) es fundamental habercomprendido bien el problema que se pretende resolver y haber aplicado principios bsicos dediseo que nos permitan construir un sistema de informacin de calidad.

Para la fase de implementacin hemos de seleccionar las herramientas adecuadas, un entornode desarrollo que facilite nuestro trabajo y un lenguaje de programacin apropiado para el tipode sistema que vayamos a construir. La eleccin de estas herramientas depender en gran

parte de las decisiones de diseo que hayamos tomado hasta el momento y del entorno en elque nuestro sistema deber funcionar.

A la hora de programar, deberemos procurar que nuestro cdigo no resulte indescifrable. Paraque nuestro cdigo sea legible, hemos de evitar estructuras de control no estructuradas, elegircuidadosamente los identificadores de nuestras variables, seleccionar algoritmos y estructurasde datos adecuadas para nuestro problema, mantener la lgica de nuestra aplicacin lo mssencilla posible, comentar adecuadamente el texto de nuestros programas y, por ltimo,facilitar la interpretacin visual de nuestro cdigo mediante el uso de sangras y lneas enblanco que separen distintos bloques de cdigo.

Adems de las tareas de programacin asociadas a los distintos componentes de nuestrosistema, en la fase de implementacin tambin hemos de encargarnos de la adquisicin detodos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de usodel sistema gestor de bases de datos que vayamos a utilizar). Usualmente, tambindesarrollaremos algunos casos de prueba que nos permitan ir comprobando el funcionamientode nuestro sistema conforme vamos construyndolo.


Fernando Berzal

5/24/2018 ciclovida

19/42

Control de versiones

En todo proyecto de desarrollo de software resulta fundamental una adecuada gestinde la configuracin del software (SCM, Software Configuration Management), msconocida vulgarmente por uno de sus aspectos, el control de versiones. De hecho, esuna actividad clave en el nivel 2 del CMM (Capability Maturity Model), un modelo demadurez del proceso de desarrollo del software en el cual el nivel 1 representa laanarqua.

Independientemente de su importancia en el control del proceso de desarrollo desoftware (algo innegable), su valor es incalculable para evitar prdidas irreparables(siempre y cuando se hagan copias de seguridad de la base de datos de nuestraherramienta de control de versiones) y tambin para volver cmodamente a unaversin anterior de nuestro cdigo si nuestras ltimas modificaciones del cdigo noresultaron del todo acertadas.

Pruebas

Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se hayanpodido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo,adems, es hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho,

una prueba es un xito cuando se detecta un error (y no al revs, como nos gustara pensar).

La bsqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas,en funcin del contexto y de la fase del proyecto en la que nos encontremos:

- Las pruebas de unidadsirven para comprobar el correcto funcionamiento de uncomponente concreto de nuestro sistema. Es este tipo de pruebas, el "probador"debe buscar situaciones lmite que expongan las limitaciones de laimplementacin del componente, ya sea tratando ste como una caja negra("pruebas de caja negra") o fijndonos en su estructura interna ("pruebas de cajablanca"). Resulta recomendable que, conforme vamos aadindole nueva

funcionalidad a nuestras aplicaciones, vayamos creando nuevos tests con losmedir nuestro progreso y tambin repitamos los antiguos para comprobar que loque antes funcionaba sigue funcionando (test de regresin).

- Las pruebas de integracinson las que se realizan cuando vamos juntando loscomponentes que conforman nuestro sistema y sirven para detectar errores en susinterfaces. En algunas empresas, como Microsoft, se hace una compilacin diariautilizando los componentes del sistema tal como estn en ese momento (dailybuild) y se somete al sistema a una serie de pruebas bsicas (la prueba de humo,smoke test) que garanticen que el proyecto podr seguir avanzando al da



5/24/2018 ciclovida

20/42

siguiente. El causante de que la compilacin diaria falle suele tener que quedarse a

hacer horas extra para que sus compaeros puedan seguir trabajando al dasiguiente...

- Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de laorganizacin encargada del desarrollo del sistema. Estas pruebas, realizadas desdeel punto de vista de un usuario final, pueden ayudar a pulir aspectos de la interfazde usuario del sistema

- Cuando el sistema no es un producto a medida, sino que se vender como unproducto en el mercado, tambin se suelen realizar pruebas beta. Estas pruebaslas hacen usuarios finales del sistema ajenos al equipo de desarrollo y puedenresultar vitales para que un producto tenga xito en el mercado.

- En sistemas a medida, se suele realizar un test de aceptacin que, si se superacon xito, marcar oficialmente el final del proceso de desarrollo y el comienzo dela etapa de mantenimiento.

- Por ltimo, a lo largo de todo el ciclo de vida del software, se suelen hacerrevisiones de todos los productos generados a lo largo del proyecto, desde eldocumento de especificacin de requerimientos hasta el cdigo de los distintosmdulos de una aplicacin. Estas revisiones, de carcter ms o menos formal,ayuden a verificar la correccin del producto revisado y tambin a validarlo(comprobar que se ajusta a los requerimientos reales del sistema).

Aunque es imposible garantizar la ausencia de errores en el software, una adecuadacombinacin de distintas tcnicas de prueba puede ayudar ms del 90% de los errores que seencontrarn a lo largo de toda la vida del sistema. Aunque podamos ser reacios a admitirlo, lonormal es que el 40% de nuestro tiempo lo "perdamos" eliminando errores, mientras que sloempleamos un 20% en la etapa de anlisis, otro 20% en el diseo y el 20% restante en laimplementacin del sistema (Robert Glass, Building quality software, 1992).

Al realizar cualquiera de los tipos de prueba descritos, es importante recordar que eldesarrollo de software es una actividad que se realiza en equipo, por lo que pueden surgirroces personales y disputas polticas entre los miembros del equipo. Las pruebas resultan

particularmente delicadas en este sentido, ya que su objetivo es, al fin y al cabo, encontrardefectos.

Instalacin / Despliegue

Una vez concluidas las etapas de desarrollo de un sistema de informacin (anlisis, diseo,implementacin y pruebas), llega el instante de que poner el sistema en funcionamiento, suinstalacin o despliegue.


Fernando Berzal

5/24/2018 ciclovida

21/42

De cara a su instalacin, hemos de planificar el entorno en el que el sistema debe funcionar,tanto hardware como software: equipos necesarios y su configuracin fsica, redes deinterconexin entre los equipos y de acceso a sistemas externos, sistemas operativos(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministradospor terceras partes, etctera.

Para asegurar el correcto funcionamiento del sistema, resulta esencial que tengamos en cuentalas dependencias que pueden existir entre los distintos componentes del sistema y susversiones. Una aplicacin puede que slo funcione con una versin concreta de una bibliotecaauxiliar. Un disco duro puede que slo rinda al nivel deseado si instalamos un controladorconcreto. Componentes que por separado funcionaran correctamente, combinados causanproblemas, por lo que deberemos utilizar slo combinaciones conocidas que no presentenproblemas de compatibilidad.

Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintasfases, tambin hemos de planificar cuidadosamente la transicin del sistema antiguo al nuevode forma que sus usuarios no sufran una disrupcin en el funcionamiento del sistema. Enocasiones, el sistema se instala fsicamente en un entorno duplicado y la transicin se hace deforma instantnea una vez que la nueva configuracin funciona correctamente. Cuando elpresupuesto no da para tanto, tal vez haya que buscar un momento de baja utilizacin delsistema para realizar la actualizacin (por la noches o en fin de semana, por ejemplo).

Uso y mantenimiento

La etapa de mantenimiento consume tpicamente del 40 al 80 por ciento de los recursos deuna empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente laetapa ms importante del ciclo de vida del software. Dada la naturaleza del software, que ni serompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes:

- Eliminar los defectos que se detecten durante su vida til (mantenimientocorrectivo), lo primero que a uno se le viene a la cabeza cuando piensa en elmantenimiento de cualquier cosa.

- Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistemaha de funcionar sobre una nueva versin del sistema operativo o en un entornohardware diferente, por ejemplo.

- Aadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponencaractersticas deseables que supondran una mejora del sistema ya existente.

De las distintas facetas del mantenimiento, la eliminacin de defectos slo supone el 17% delcoste de mantenimiento de un sistema, mientras que el diseo e implementacin de mejoras esresponsable del 60% del coste de mantenimiento. Es decir, ms de un tercio del coste total del



5/24/2018 ciclovida

22/42

software se emplea en aadirle caractersticas a software ya existente (el 60% del 60%). Lacorreccin de errores supone, en contraste, "slo" en torno al 10% del coste total del software.An menos cuanto mejores sean las tcnicas usadas en su desarrollo.

Se ha observado que, cuanto mejor sea el software, ms tendremos que invertir en sumantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos. Este hecho, quepuede parecer paradjico, se debe, simplemente, a que nuestro sistema se usar ms (a veces,de formas que no habamos previsto). Por tanto, nos llegarn ms propuestas de modificaciny mejora que si el sistema hubiese quedado aparcado, cogiendo polvo, en algn rincn.

Si examinamos las tareas que se llevan a cabo durante la etapa de mantenimiento, nosencontramos que en el mantenimiento se repiten todas las etapas que ya hemos visto del ciclode vida de un sistema de informacin. Al tratar principalmente de cmo aadirle nueva

funcionalidad a un sistema ya existente, el mantenimiento repite "en miniatura" el ciclo devida completo de un sistema de informacin. Es ms, a las tareas normales de desarrollohemos de aadirle una nueva, comprender el sistema que ya existe, por lo que se podra decirque el mantenimiento de un sistema es ms difcil que su desarrollo (Glass, 2003).


Fernando Berzal

5/24/2018 ciclovida

23/42

Modelos de ciclo de vida

Todas las actividades descritas en las distintas secciones del apartado anterior estn presentesen cualquier proyecto de desarrollo de software (adems de otras muchas relativas a la gestinde un proyecto o a su control de calidad). Sin embargo, las tareas concretas que se realicen (ysu grado de rigor) dependern de la naturaleza del proyecto al que nos enfrentemos y de lascaractersticas de nuestro entorno de trabajo.

El director de un proyecto, contando con el asesoramiento de los dems miembros del equipo,

debe elegir los mtodos y herramientas ms adecuados en cada momento para satisfacer lasnecesidades especficas del proyecto, adems de establecer las medidas oportunas quepermitan controlar la evolucin del proyecto. Las decisiones tomadas en este sentido han detener como objetivo satisfacer los tiempos de entrega pactados con el cliente sin comprometerla calidad del producto final.

Existen distintas formas de organizar el orden concreto en el que se acometern las distintasetapas del ciclo de vida de un sistema de informacin. En los siguientes prrafos se describenalgunas de las alternativas que deberan tenerse en cuenta:

Ciclo de vida clsicoEl modelo de ciclo de vida clsico, tambin denominado "modelo en cascada", se basa enintentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden,de una etapa a la siguiente slo tras finalizar con xito las tareas de verificacin y validacinpropias de la etapa. Si resulta necesario, nicamente se da marcha atrs hasta la faseinmediatamente anterior.

Este modelo tradicional de ciclo de vida exige una aproximacin secuencial al proceso dedesarrollo del software. Por desgracia, esta aproximacin presenta una serie de gravesinconvenientes, entre los que cabe destacar:

- Los proyectos reales raramente siguen el flujo secuencial de actividades quepropone este modelo.

- Normalmente, es difcil para el cliente establecer explcitamente todos losrequisitos al comienzo del proyecto (entre otras cosas, porque hasta que no veaevolucionar el proyecto no tendr una idea clara de qu es lo que realmentequiere).

- No habr disponible una versin operativa del sistema hasta llegar a las etapas



5/24/2018 ciclovida

24/42

finales del proyecto, por lo que la rectificacin cualquier decisin tomada

errneamente en las etapas iniciales del proyecto supondr un coste adicionalsignificativo, tanto econmico como temporal (y eso sin tener en cuenta la malaimpresin causada por un retraso en la fecha de entrega).

El ciclo de vida clsico: Modelo "en cascada".

Tal cual, el modelo de ciclo de vida en cascada no nos indica nada acerca de la relacincontractual existente entre el cliente y la organizacin encargada del desarrollo de software.Desde el punto de vista de una empresa de desarrollo de software, formalizar la firma de un

contrato al final de la etapa de anlisis, por ejemplo, puede ayudar a reducir el riesgo quesupone elaborar un presupuesto cuando an no se dispone de toda la informacin necesariapara que la estimacin del esfuerzo requerido por el proyecto sea lo suficientemente precisa.Este tipo de contrato obliga a que el cliente se haga cargo de los costes adicionalesocasionados por cambios en los requerimientos, mientras que la empresa de desarrollo desoftware deber asumir los gastos ocasionados si el producto finalmente entregado no cumpletodas las condiciones pactadas a la firma del contrato.

Por desgracia, un modelo contractual como el descrito en el prrafo anterior no siempreresulta aceptable para el cliente, que puede verse obligado a invertir dinero a cambio de nada.Esto podra pasar si, tras la etapa de anlisis, el proyecto se desestima por no ser tcnica o


Fernando Berzal

5/24/2018 ciclovida

25/42

econmicamente viable. Es ms, si el cliente acepta a regaadientes la firma de un contrato alfinal de la etapa de anlisis, la imagen de la empresa desarrolladora de software puede verseseriamente deteriorada en cuanto surja cualquier tipo de problema.

Para limar las asperezas que pueden surgir en la relacin cliente-proveedor y mejorar elrendimiento del equipo del proyecto, hoy en da se suele recurrir a modelos iterativos comolos que se describirn a continuacin.

Desarrollo de prototipos

Normalmente, el cliente es capaz de definir un conjunto general de objetivos para el sistema

que hemos de construir, pero no identifica los requisitos detallados. En otros casos, puede quenosotros no estemos seguros de la eficiencia de un algoritmo, de la capacidad de nuestrodiseo para soportar los requerimientos del sistema o de la forma en que debe disearse lainterfaz de usuario. En cualquiera de estas situaciones, resulta adecuado construir unprototipo.

Prototipado

El desarrollo de prototipos reduce el riesgo de que nuestro proyecto fracase y facilita laespecificacin de requerimientos de productos que desconocemos. Sin embargo, tambintiene sus inconvenientes: el cliente puede pensar que el prototipo es el sistema definitivo,ignorando que un prototipo no es un sistema acabado aunque tenga el mismo aspecto externo.Esto puede conducir a la consolidacin de aspectos de baja calidad de un prototipo en el



5/24/2018 ciclovida

26/42

sistema final que se entrega si el prototipo no se desecha a tiempo.

Fred Brooks nos aclara lo que hay que hacer cuando un prototipo ya ha cumplido con supropsito:"En la mayora de los proyectos, el primer sistema que se construye apenas resultautilizable. Puede que sea demasiado lento, demasiado grande, difcil de usar o las tres cosasa la vez. No queda ms remedio que comenzar de nuevo y construir una versin rediseadaque resuelva los problemas... Cuando se utiliza un concepto nuevo... hay que construir unsistema para desecharlo, porque incluso la mejor planificacin no puede asegurar que vaya asalir bien la primera vez. Por tanto, la cuestin no es si hay que construir un sistema piloto ydesecharlo. Se desechar. La nica cuestin es si planificar de antemano la construccin dealgo que se va a desechar, o prometer la entrega del desecho a los clientes..."(The MythicalMan-Month, "El mtico hombre-mes", 1975, uno de los libros de gestin de proyectos dedesarrollo de software ms populares que jams se han escrito).

A veces, los prototipos desechables no se llegan a desechar. Pero los prototipos no siempreson desechables. En tal caso, estaremos utilizando un modelo iterativo de refinamiento deprototipos en el que, tras varias iteraciones, seremos capaces de construir un sistema que seadapte mejor a las necesidades de nuestro cliente.

Modelos iterativos

En 1994, el Departamento de Defensa de Estados Unidos (el mayor contratista mundial de

proyectos de desarrollo de software) cambi oficialmente sus estndares de desarrollo desoftware y descart el modelo en cascada para introducir el estndar 498, que utiliza unmodelo iterativo de desarrollo de software.

Los modelos iterativos consisten en descomponer un proyecto de desarrollo de software enuna serie de subproyectos de menor envergadura. Estos subproyectos deben disearse de talforma que cada uno de ellos aporte funcionalidad nueva para el sistema desde el punto devista del usuario final del mismo.

Usualmente, las personas involucradas en el proyecto establecen prioridades entre losrequerimientos iniciales del sistema para decidir qu parte del mismo se construir primero.El cliente y los usuario finales abogarn por darle prioridad a las funciones ms tiles del

sistema (o las ms "vendibles"). Por otro lado, los diseadores del sistema debern determinarlas dependencias existentes entre sus distintos componentes y priorizar aqullos que suponganun riesgo mayor para la viabilidad final del proyecto. Las prioridades de unos y otros habrnde consensuarse razonablemente y servirn para determinar el mbito de los subproyectos enque se descompondr el proyecto inicial.

Los modelos iterativos de desarrollo de software permiten adelantar el momento en el que sedetermina si un proyecto es tcnicamente viable o no (con lo que se eliminan costesinnecesarios si, finalmente, el proyecto hubiese de cancelarse). Tambin promueven unamejor comunicacin con el usuario/cliente, ya que se dispondr antes de una versin operativa


Fernando Berzal

5/24/2018 ciclovida

27/42

del sistema, aunque sea de funcionalidad reducida. Estas versiones intermedias del productoayudan a la eliminacin de malentendidos que pueden surgir en la etapa de elicitacin derequerimientos. Adems, ayudan a que el usuario se forme una idea ms clara de lo querealmente necesita.

Secuencial o iterativo?

El modelo de desarrollo ms adecuado para un proyectodepender del tipo de sistema que se ha de construir:

- En general, se elegir un modelo secuencial cuando losrequerimientos se conocen bastante bien y son estables,

cuando el diseo ser similar al de otros sistemas con losque tenemos experiencia, cuando los integrantes delequipo de desarrollo ya se conocen y estn familiarizadocon el entorno de desarrollo, o cuando el coste de tenerque cambiar algo en las etapas finales del proyectoresultara prohibitivo.

- En la prctica, no obstante, los modelos iterativos seadaptan mejor a la realidad del desarrollo de software(especialmente en sistemas medianos y grandes). Nosdecantaremos por un modelo iterativo cuando losrequerimientos no se conocen con exactitud o se prevque puedan cambiar en el futuro, cuando el diseo delsistema es complejo o no tiene precedentes para nosotros,cuando el proyecto en s es arriesgado econmicamente ycuando podamos controlar el coste de futuros cambios enel sistema (algo que siempre tendremos que hacer sitenemos en cuenta lo que aprendimos al estudiar la etapade mantenimiento).

Al seguir un modelo iterativo, puede que le dediquemos muypoco tiempo a las etapas iniciales del ciclo de vida de un

sistema, lo que puede causar una tasa de cambios tan alta queimpida que el proyecto progrese. Del mismo modo, si lesdedicamos demasiado tiempo, hasta el punto de seguir a piesjuntillas los requerimientos iniciales del sistema, puede queestemos negando la realidad con la que nos encontramos y, denuevo, impidamos que el proyecto progrese adecuadamente.

Para planificar un proyecto que siga un modelo iterativo, primero se prepara unadescomposicin a grandes rasgos del proyecto en una serie de iteraciones, cada una de lascuales se considerar como un proyecto independiente. En vez de realizar una planificacin



5/24/2018 ciclovida

28/42

detallada de todo el proyecto, slo se detallar el plan correspondiente a la primera iteracin.S se establecern las fechas de inicio y finalizacin de las distintas iteraciones y se definirnlos objetivos principales de cada una de ellas. Llegado el caso, estos objetivos se puedenredefinir conforme avance el proyecto.

El modelo en espiral de Boehm

A lo largo de los aos se han propuesto multitud de modelos iterativos de desarrollo desoftware. A continuacin se describen algunos de los ms conocidos:

- Elmodelo en espiralde Barry Boehm hace especial hincapi en la prevencin deriesgos. Este modelo define cuatro actividades principales: planificacin(determinar los objetivos, alternativas y restricciones del proyecto), anlisis deriesgos (anlisis de alternativas e identificacin/resolucin de riesgos), ingeniera(desarrollo del producto) y evaluacin (revisin por parte del cliente y valoracinde los resultados obtenidos de cara a la siguiente iteracin). En cada iteracinalrededor de la espiral se construyen versiones cada vez ms completas del

software.

- Losmodelos evolutivos(como el modelo Evode Tom Gilb o los modelos gilespopulares hoy en da, entre los que se encuentra la auto-denominadaprogramacin extrema) se caracterizan por realizar entregas por etapas delsistema. Usualmente, el proyecto se descompone en iteraciones de longitud fija(de 1 a 6 semanas) y cada iteracin ha de proporcionar algn aspecto completo dela funcionalidad del sistema. Cada ciclo se concentra en las funciones de mayorvalor aadido. De esta forma, si se cancelase el proyecto en cualquier momento, elusuario siempre tendr lo mximo que se puede conseguir con los recursos


Fernando Berzal

5/24/2018 ciclovida

29/42

invertidos hasta el momento. Igualmente, se puede prorrogar el proyecto si se

considera interesante seguir aadindole funcionalidad al proyecto.- Tambin existen otros modelos, conocidos por el nombre de modelos de

estabilizacin y sincronizacin, en los que se sigue la misma estrategia que enlos modelos iterativos pero sin llegar a realiza una entrega por etapas del sistema.ste es el caso, por ejemplo, del modelo de desarrollo de software utilizadointernamente en empresas como Microsoft.

Marcos para el proceso de desarrollo de software

Como hemos visto, existe una amplia variedad de propuestas en lo que respecta a

cmo organizar el proceso de desarrollo de software. La mayora de las propuestas sonprescriptivas (definen qu actividades hay que realizar y en qu orden), si bien algunaspropuestas van ms all y definen marcos para organizar el conjunto de actividades ytareas involucradas en un proyecto de desarrollo de software. Estos marcos sugierenqu combinaciones de actividades son las ms indicadas en cada etapa del proceso dedesarrollo de software y cules deberan ser los resultados que se obtengan de cada unade ellas. Los siguientes son algunos de los ms populares hoy en da:

- El modelo CMMI (Capability Maturity Model - Integrated, propuesto por elInstituto de Ingeniera del Software de la Universidad de Carnegie-Mellon)identifica una serie de reas clave en trminos de objetivos especficos yprcticas necesarias para lograr esos objetivos. Los objetivos establecen lascaractersticas que el proceso de desarrollo de software debe tener para que lasactividades de cada rea puedan ser efectivas. En cierto sentido, CMMI viene aser como una certificacin de calidad ISO 9000 adaptada a proyectos dedesarrollo de software. Una certificacin de este tipo puede ayudar a conseguirdeterminados tipos de proyectos (gubernamentales, principalmente), si bien slogarantiza que el proyecto se realiza siguiendo un proceso definido, no que lasdistintas tareas se realicen correctamente. De hecho, el proceso puede estarperfectamente definido y "certificado" sin ser el proceso adecuado para elproyecto que tengamos entre manos.

- El Proceso Unificado de Rational (RUP, Rational Unified Process, propuestooriginalmente por una empresa llamada Rational Software Corporation que hoyes una divisin de IBM) describe un marco adaptable para procesos iterativos dedesarrollo de software. El ciclo de vida de un proyecto RUP se divide en ciclosde desarrollo individuales que, a su vez, se descomponen en cuatro fasesprincipales (incepcin, elaboracin, construccin y transicin). Para cada una deestas fases, RUP identifica qu disciplinas (actividades) son las ms relevantes.Finalmente, en un proyecto concreto cada fase viene definida por una serie deobjetivos y se descompone en iteraciones de duracin fija (de, por ejemplo, 3semanas).



5/24/2018 ciclovida

30/42

El ciclo de vida de una base de datos

Una base de datos no es ms que un componente de un sistema de informacin. Por tanto, elciclo de vida del sistema de informacin incluye el ciclo de vida de la base de datos que formaparte de l. En particular, desde el punto de vista de la base de datos, centraremosprincipalmente nuestra atencin en las siguientes actividades:

- Definicin del sistema: Durante la etapa de anlisis de requerimientos delsistema, nos fijaremos especialmente en todos los requerimientos asociados a los

datos con los que ha de trabajar nuestro sistema.

- Diseo de la base de datos: El anlisis de los requerimientos del sistema nospermitir organizar los datos con los que nuestro sistema habr de trabajar. Esteproceso de diseo, que est ntimamente ligado a la futura base de datos denuestro sistema, lo descompondremos en tres fases:

Diseo conceptual(descripcin del esquema de la base de datos utilizandoun modelo de datos conceptual).

Diseo lgico (descripcin de la base de datos con un modelo de datosimplementable, como puede ser el caso del modelo relacional).

Diseo fsico (descripcin de la base de datos a nivel interno, de acuerdocon las caractersticas del sistema gestor de bases de datos que decidamosutilizar).

- Implementacin de la base de datos(la parte de la implementacin del sistemacorrespondiente a la creacin de la base de datos).

- Carga o conversin de los datos: Como parte de la instalacin o despliegue delsistema, tendremos que introducir en la base de datos todos aquellos datos queresulten necesarios para que las aplicaciones de nuestro sistema de informacinpuedan funcionar. Como parte de esta inicializacin de la base de datos, puede

que resulte necesario extraer datos de otro sistema y convertirlos a un formatoadecuado para nuestro sistema (entre otras cosas, porque el esquema de nuestrabase de datos probablemente diferir del esquema de las bases de datos de las quese extraigan los datos necesarios para arrancar nuestro sistema).

- Conversin de aplicaciones: Si determinadas aplicaciones (que ya existiesenanteriormente al diseo de nuestro sistema) han de seguir funcionando, dichasaplicaciones debern adaptarse al esquema de nuestra base de datos. Por tanto,como parte del mantenimiento de dichas aplicaciones, tendremos que disear losmecanismos adecuados para que estas aplicaciones puedan seguir funcionando


Fernando Berzal

5/24/2018 ciclovida

31/42

correctamente sobre una base de datos diferente a la base de datos sobre la que

fueron diseadas inicialmente. A veces, podremos solucionar este problemacreando vistas adecuadas de nuestra base de datos para tales aplicaciones. Otrasveces, tendremos que modificar la implementacin de las aplicaciones antiguas e,incluso, rehacerlas casi por completo.

- Verificacin y validacin: Como en todo sistema de informacin, deberemosverificar que la base de datos y las aplicaciones funcionan correctamente.Adems, deberemos comprobar que el sistema construido se ajusta a lasnecesidades reales que promovieron su proyecto de desarrollo (esto es, validar elsistema y sus requerimientos).

- Operacin, supervisin y mantenimiento: Finalmente, una vez puesto enmarcha el sistema, se llega a la etapa "final" del ciclo de vida de todo sistema deinformacin (en la que, como ya vimos, se repetir todo el ciclo cada vez quetengamos que realizar modificaciones sobre el sistema ya existente).

De las actividades descritas en los prrafos anteriores, todas ellas relacionadas directamentecon la base o bases de datos utilizadas en un sistema de informacin, estudiaremos a fondo lascorrespondientes a las etapas iniciales del ciclo de vida de la base de datos. Antes de estudiartcnicas concretas, no obstante, detallares algo ms el proceso de diseo que utilizaremos paraconstruir correctamente una base de datos.



5/24/2018 ciclovida

32/42

El proceso de diseo de una base de datos

El problema de disear bases de datos consiste en disear la estructura lgica y fsica de una oms bases de datos para atender las necesidades de informacin de los usuarios de unconjunto definido de aplicaciones. Estos usuarios pueden pertenecer todos a una organizacinconcreta (como sucede con los trabajadores de una empresa o los funcionarios de unorganismo pblico), o bien formar parte de un colectivo con intereses comunes (tal es el casode los usuarios de multitud de aplicaciones web, desde un buscador como Google hasta unservicio de informacin geogrfica tipo Pginas Amarillas).

Antes de pasar a ver la metodologa que utilizaremos para disear bases de datos, hay querecordar que el diseo de bases de datos es slo una de los procesos involucrados en laconstruccin de un sistema de informacin. Generalmente, para construir un sistema deinformacin se llevarn a cabo distintas actividades paralelas:

- Por un lado, ser necesario disear el contenido y la estructura de la base de datosque dar soporte al sistema de informacin.

- Por otro, tambin ser imprescindible disear el conjunto de aplicaciones que lepermitirn al usuario sacar partido del sistema de informacin.

Tanto en las actividades relacionadas con los datos del sistema (todo lo relativo a la base dedatos) como en aqullas relacionadas con los procesos del mundo real que el sistema trata demejorar (mediante un conjunto de aplicaciones), resulta recomendable el uso de unametodologa apropiada.

En esencia, la metodologa utilizada en un proyecto no es ms que el conjunto deconvenciones que los integrantes de un equipo de trabajo acuerden emplear. Esta definicinincluira, por ejemplo, a la metodologa ASDM utilizada por algunas empresas de desarrollode software (una referencia irnica al hecho de ir haciendo las cosas "a salto de mata"). Sinembargo, por metodologa usualmente se entiende algo ms. Si acudimos a un diccionario,

encontraremos que una metodologa es un conjunto de mtodos (sic), aplicados de formasistemtica.

Una buena metodologa de diseo ha de incluir todo lo que normalmente resulte necesariopara obtener un buen diseo. Generalmente, una metodologa, que implicar el uso demtodos y tcnicas adecuadas a nuestro problema, se centrar en la coordinacin de lasactividades que han de realizarse. De acuerdo con las etapas del ciclo de vida de un sistema deinformacin, una metodologa de diseo descompone el proceso de diseo en una serie deetapas. Para cada una de las etapas, propondr el uso de determinadas tcnicas y herramientasde diseo, as como la generacin de una serie de documentos que facilitarn la transicin deuna etapa a la siguiente.


Fernando Berzal

5/24/2018 ciclovida

33/42

A continuacin, presentaremos las distintas fases en las que descompondremos el proceso dediseo de bases de datos. Para cada una de las fases, mencionaremos sus objetivos concretos,las tcnicas particulares que recomendamos utilizar en cada etapa y los documentos que sedeberan obtener como resultado de cada una de ellas.

FASES DEL DISEO DE BASES DE DATOS

- Anlisis de requisitos

- Diseo conceptual

- Eleccin del sistema gestor de bases de datos

- Diseo lgico

- Diseo fsico

- Instalacin y mantenimiento

Fase 1: Anlisis de requerimientos

Objetivo

Recabar informacin sobre el uso que se le piensa dar a la base de datos.

Tareas

Elicitacin de los requisitos del sistema:

- Identificacin de las principales reas de la aplicacin y grupos de usuarios.

- Estudio y anlisis de la documentacin existente relativa a las aplicaciones.

- Estudio del entorno de operacin actual.

- Estudio del uso de la informacin (transacciones, frecuencias y flujos de datos).



5/24/2018 ciclovida

34/42

ResultadosDocumento de especificacin de requerimientos:

- Descripcin del sistema en lenguaje natural.

- Lista de requerimientos (organizados de forma jerrquica).

- Diagramas de flujo de datos (DFD).

- Casos de uso.

Fase 2: Diseo conceptual

Objetivo

Producir un esquema conceptual de la base de datos (independiente del sistema gestor debases de datos que luego vayamos a utilizar).

Tareas

- Comprensin de la estructura, semntica, relaciones y restricciones asociados alos datos que deben almacenarse en la base de datos.

- Modelado de los datos del sistema (obtencin de una descripcin estable de lo queser el contenido de la base de datos).

- Comunicacin entre usuarios finales, analistas y diseadores para comprobar lavalidez del modelo obtenido.

Resultados

- Diagrama E/R, diagrama CASE*Method o diagrama de clases UML.

- Diccionario de metadatos.


Fernando Berzal

5/24/2018 ciclovida

35/42

Fase 3: Eleccin del SGBDLa eleccin del sistema gestor de bases de datos que vayamos a utilizar se realiza en dosetapas:

- Primero se realiza laeleccin del modelo de datos, el tipo de sistema gestor debases de datos que vamos a usar: relacional, objeto-relacional, orientado a objetos,multidimensional...

- A continuacin se elige el sistema gestor de bases de datos concreto (y suversin). Por ejemplo, si decidimos utilizar un sistema gestor de bases de datosrelacionales, podemos recurrir al gestor de bases de datos de Oracle, al DB2 deIBM, al SQL Server de Microsoft, al Interbase de Borland o a cualquier otro delos muchos sistemas gestores de bases de datos relacionales que existen en elmercado.

Seleccin de un sistema gestor de bases de datos

Un sistema gestor de bases de datos (SGBD o DBMS si nos atenemos a sus siglas eningls) es un producto software con capacidad para definir, mantener y utilizar basesde datos. El sistema de gestin de bases de datos que decidamos utilizar debe

permitirnos, entre otras cosas, definir estructuras de almacenamiento adecuadas yacceder a los datos de forma eficiente y segura. A continuacin se enumeran algunosde los aspectos en que deberamos fijarnos para elegir un SGBD concreto:

Factores tcnicos

- Organizacin de los datos independientemente de las aplicaciones que los vayana usar (independencia lgica) y de los ficheros en los que vayan a almacenarse(independencia fsica).

- Datos y aplicaciones accesibles a los usuarios y a otras aplicaciones de la manera

ms amigable posible (mediante lenguajes de consulta como SQL oQuery-by-example).

- Datos gestionados de forma centralizada e independiente de las aplicaciones.

- No redundancia (los datos no deben estar duplicados), consistencia e integridad.

- Fiabilidad (proteccin frente a fallos en el hardware).

- Seguridad (no todos los datos deben ser accesibles a todos los usuarios y elSGBD debe ayudarnos a controlar esto).



5/24/2018 ciclovida

36/42

Seleccin de un sistema gestor de bases de datos

- Capacidad de replicacin y distribucin.

- Disponibilidad de herramientas adecuadas de desarrollo de software.

- Portabilidad.

Factores no tcnicos

- Coste de la adquisicin del software (licencias de uso del SGBD).

- Coste del hardware necesario para el uso del SGBD.

- Costes asociados al mantenimiento de la base de datos.

- Coste de creacin y conversin de la base de datos.

- Coste de personal (tanto de formacin como de operacin de la base de datos).

- Disponibilidad de servicios por parte del proveedor del SGBD.

Fase 4: Diseo lgico

Objetivo

Crear el esquema conceptual de la base de datos (y todos los esquemas externos asociados alas distintas aplicaciones del sistema) de acuerdo con el modelo de datos del sistema gestor debase de datos elegido.

Tareas

Para realizar el diseo lgico de la base de datos, hay que transformar los esquemas obtenidosen el diseo conceptual en un conjunto de estructuras propias del modelo abstracto de datoselegido. En el caso de las bases de datos relacionales tendremos que realizar las siguientestareas:

- Paso del diagrama E/R (o equivalente) a un conjunto de tablas.

- Normalizacin de las tablas


Fernando Berzal

5/24/2018 ciclovida

37/42

ResultadoUn conjunto de estructuras propias del modelo abstracto de datos del SGBD elegido (esto es,un conjunto de tablas si trabajamos con bases de datos relacionales).

Fase 5: Diseo fsico

Objetivo

El diseo fsico de la base de datos consiste en elegir las estructuras de almacenamientoapropiadas (tablas, particiones de tablas, ndices...) para que el rendimiento de la base dedatos sea el adecuado para las distintas aplicaciones a las que ha de dar servicio.

Sobre el rendimiento de la base de datos

Por rendimiento de las aplicaciones se entiende el tiempo derespuesta del sistema a las peticiones del usuario, elaprovechamiento del espacio de almacenamiento en discoutilizado por la base de datos, la productividad de las

transacciones de la base de datos y cualquier otro aspecto quepueda afectar a la percepcin del sistema por parte delusuario.

Usualmente, el rendimiento del sistema depender del tamaode la base de datos, del nmero de registros de cada tipo queha de almacenar y del nmero de usuarios que accedernconcurrentemente a la base de datos, as como de los patronesconcretos de insercin, actualizacin y obtencin de datos.

Tareas

- Estimar adecuadamente los diferentes parmetros fsicos de nuestra base de datos,para lo cual podemos recurrir a tcnicas analticas (modelos matemticos delrendimiento de un sistema) y a tcnicas experimentales (como la construccin deprototipos, el uso de tcnicas de simulacin o la realizacin de pruebas de carga).

- Preparar las sentencias DDL correspondientes a las estructuras identificadasdurante la etapa de diseo lgico de la base de datos.



5/24/2018 ciclovida

38/42

ResultadoUn conjunto de sentencias DDL escritas en el lenguaje del SGBD elegido (incluyendo lacreacin de ndices, la seleccin de parmetros fsicos de la base de datos, etctera).

Fase 6: Instalacin y mantenimiento

Como en cualquier sistema de informacin, casi siempre resulta necesario modificar el diseode la base de datos, ya sea porque el rendimiento observado despus de la implementacin delsistema de bases de datos no sea el adecuado o porque haya que introducir cambios en el

esquema de la base de datos como consecuencia del mantenimiento del sistema deinformacin. Por ambos motivos se incluye explcitamente esta fase en el proceso de diseode bases de datos.

Instalacin y puesta en marcha

- La instalacin de la base de datos suele ser responsabilidad del administrador dela base de datos (DBA: Database Administrator), que se encarga de recopilartodas las sentencias DDL necesarias para crear los distintos esquemas de la base

de datos.- Una vez creados estos esquemas, se procede a la carga inicial de los datos en la

base de datos, para lo cual puede ser necesaria la implementacin de rutinas deconversin, tal como vimos al describir el ciclo de vida de una base de datos.

Mantenimiento

- Casi todos los sistemas gestores de bases de datos incluyen alguna utilidad quenos permite supervisar el funcionamiento del sistema. Dichas utilidades demonitorizacin recopilan informacin estadstica del uso del sistema para suanlisis posterior, lo que nos facilitar todas las tareas relacionadas con laoptim

Documents

ciclovida