etapas_explicadas

7/17/2019 etapas_explicadas

http://slidepdf.com/reader/full/etapasexplicadas 1/40

El ciclo de vida de un sistemade información

Un sistema de información es un sistema, automatizado o manual, que engloba a personas,máquinas y/o métodos organizados para recopilar, procesar, transmitir datos que representaninformación. Un sistema de información engloba la infraestructura, la organización, el

personal y todos los componentes necesarios para la recopilación, procesamiento,almacenamiento, transmisión, visualización, diseminación y organización de la información.

El ciclo de vida de un sistema

de información



19

El ciclo de vida de un sistema de información

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

Planificación............................................................................... Análisis.......................................................................................

Diseño......................................................................................

Implementación........................................................................

Pruebas....................................................................................

Instalación / Despliegue...........................................................

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

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

El ciclo de vida de una base de datos................................................El proceso de diseño de una base de datos......................................

ase !" Análisis de re#uerimientos..........................................

ase $" Diseño conceptual.......................................................

ase %" Elección del &'(D......................................................

ase )" Diseño lógico...............................................................

ase *" Diseño f+sico................................................................

ase ," Instalación y mantenimiento........................................Bibliografía............................................................................................

-as etapas del proceso de desarrollo de softare

Cualquier sistema de información 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

! "lanificación

! #nálisis

! $ise%o

! &mplementación

! "ruebas



19


! &nstalación o despliegue

! Uso y mantenimiento

'stas etapas son un refle(o del proceso que se sigue a la )ora de resolver cualquier tipo de problema. *a en +-, muc)o antes de que eistiese la &ngenier0a del Soft1are, el matemático2eorge "olya describió este proceso en su libro How to solve it 3el primero que describe lautilización de técnicas )eur0sticas en la resolución de problemas4. 5ásicamente, resolver un

problema requiere

! Comprender el problema 3análisis4

! "lantear una posible solución, considerando soluciones alternativas 3dise%o4! 6levar a cabo la solución planteada 3implementación4

! Comprobar que el resultado obtenido es correcto 3pruebas4

6as etapas adicionales de planificación, instalación y mantenimiento que aparecen en el ciclode vida de un sistema de información son necesarias en el mundo real porque el desarrollo deun sistema de información conlleva unos costes asociados 3lo que se )ace necesaria la

planificación4 y se supone que, una vez construido el sistema de información, éste deber0a poder utilizarse 3si no, no tendr0a sentido )aber invertido en su desarrollo4.

"ara cada una de las fases en que )emos descompuesto el ciclo de vida de un sistema deinformación se )an propuesto multitud de prácticas 7tiles, entendiendo por prácticas aquellosconceptos, principios, métodos y )erramientas que facilitan la consecución de los ob(etivos decada etapa.

'n los párrafos siguientes se mencionan algunas de las actividades que )an de realizarse encada una de las fases del ciclo de vida de un sistema de información

Planificación#ntes de que se le de oficialmente el pistoletazo de salida a un proyecto de desarrollo de unsistema de información, es necesario realizar una serie de tareas previas que influirándecisivamente en la finalización con éito del proyecto. 'stas tareas se conocen popularmentecomo el fuzzy front-end del proyecto al no estar su(etas a plazos. 6as tareas iniciales que serealizarán esta fase inicial del proyecto incluyen actividades tales como la determinación delámbito del proyecto, la realización de un estudio de viabilidad, el análisis de los riesgosasociados al proyecto, una estimación del coste del proyecto, su planificación temporal y laasignación de recursos a las distintas etapas del proyecto.



18

Diseño de Bases de Datos

Delimitación del ámbito del proecto

8esulta esencial determinar el ámbito del proyecto al comienzo del mismo. 9an deestablecerse de antemano qué cuestiones )an de resolverse durante la realización del proyectoy cuáles se de(arán fuera. :an importante es determinar los aspectos abarcados por el proyectocomo fi(ar aquéllos aspectos que no se incluirán en el proyecto. 'stos 7ltimos )an de indicarseepl0citamente. Si es necesario, se puede especificar todo aquello que se posponga )asta unaversión posterior del sistema. Si, en alg7n momento, fuese necesario incluir en el proyectoalg7n aspecto que no )ab0a sido considerado o que ya )ab0a sido descartado, es obligatoriorea(ustar la estimación del coste del proyecto y su planificación temporal.

Como resultado de la delimitación del ámbito del proyecto se obtiene un documento breve, de+ ó ; páginas, en el que se describe el problema que nuestro sistema de información pretenderesolver. 'ste documento, denominado a veces mission statement o project charter , debeeistir siempre en todo proyecto. 'n él se recogerá la descripción de más alto nivel de lafuncionalidad que tendrá nuestro sistema de información, sus caracter0sticas principales y susob(etivos clave. <bviamente, este documento debe formar parte del contrato que se firme conel cliente en el arranque oficial del proyecto.

#demás de ser breve, una buena descripción del proyecto debe superar con éito la pruebadel ascensor . $ebe estar escrito en un lengua(e que cualquiera pueda entender, evitando unvocabulario ecesivamente técnico. #demás, debe recoger todo lo que le contar0amos a unconocido en unos segundos acerca del proyecto en el que estamos traba(ando si nos locruzáramos por la calle o nos lo encontrásemos en un ascensor.

Estudio de viabilidad

Con recursos ilimitados 3tiempo y dinero4, casi cualquier proyecto se podr0a llevar a buen puerto. "or desgracia, en la vida real los recursos son más bien escasos, por lo que no todoslos proyectos son viables. 'n un conocido informe de +- 3el informe Chaos del StandishGroup4, se )izo un estudio para determinar el alcance de la conocida como =crisis crónica dela programación= y, en la medida de lo posible, identificar los principales factores que )acenfracasar proyectos de desarrollo de soft1are y los ingredientes clave que pueden ayudar areducir el 0ndice de fracasos. $e entre los proyectos analizados

! Sólo uno de cada seis se completó a tiempo, de acuerdo con su presupuesto y con todaslas caracter0sticas inicialmente especificadas.

! 6a mitad de los proyectos llegó a completarse eventualmente, costando más de lo previsto, tardando más tiempo del estimado inicialmente y con menos caracter0sticas delas especificadas al comienzo del proyecto.

! "or 7ltimo, más de un >?@ de los proyectos se canceló antes de completarse.



19


$ado que cinco de cada seis proyectos analizados no se a(ustaron al plan previsto, no es deetra%ar que resulte aconse(able realizar un estudio de viabilidad antes de comenzar el

desarrollo de un sistema de información para determinar si el proyecto es económica, técnicasy legalmente viable. $e )ec)o, lo primero que deber0amos )acer es plantearnos si la me(or opción es desarrollar un sistema informatizado o es preferible un sistema manual. #lgo as0debieron )acer los rusos cuando decidieron llevar lápices al espacio 3seg7n dicen, losamericanos gastaron una fortuna )asta que inventaron un bol0grafo que funcionaba enausencia de gravedad4.

#ntes de comenzar un proyecto, se deber0a evaluar la viabilidad económica, técnica y legaldel mismo. * no sólo eso, el resultado del estudio de viabilidad deber0a a(ustarse a la realidad.# Aerry Beinberg, un conocido consultor, se le ocurrió preguntar a los asistentes a unaconferencia suya, en el Congreso &nternacional de &ngenier0a del Soft1are de +D, cuántos

de ellos )ab0an participado en un estudio de viabilidad en el que se )ubiese determinado queel proyecto no era técnicamente viable. $e los mil quinientos asistentes, nadie levantó lamano.

!nálisis de riesgos

&ndependientemente de la precisión con la que )ayamos preparado nuestro proyecto, siemprese produce alg7n contratiempo que ec)e por tierra la me(or de las planificaciones. 's algoinevitable con lo que )emos de vivir y para lo cual disponemos de una )erramientaetremadamente 7til la gestión de riesgos, que tradicionalmente se descompone enevaluación de riesgos y control de riesgos.

6a evaluación de riesgos se utiliza para identificar =riesgos= que pueden afectar negativamente al plan de nuestro proyecto, estimar la probabilidad de que el riesgo sematerialice y analizar su posible impacto en nuestro proyecto. EFué suceder0a si alg7nmiembro clave del nuestro equipo abandona la empresa, se va de vacaciones, se pone enfermoo pide una ba(a por depresión causada por un entorno de traba(o )ostilG Ey si al final nosencontramos con alg7n problema de compatibilidad del sistema que )emos desarrollamos conla configuración de los equipos sobre los que )a de funcionarG Esi, inadvertidamente,

borramos o modificamos erróneamente alg7n que otro fic)ero claveG Esi nuestro ordenador seaver0aG

Una vez analizados los riesgos potencialmente más peligrosos, podemos recurrir a distintastécnicas de control de riesgos. "or e(emplo, podemos elaborar planes de contingencia para losriesgos que sean más probables y de consecuencias más desastrosas para el proyecto. < talvez seamos capaces de eliminar el riesgo de ra0z 3o mitigarlo4 si buscamos alguna alternativaen la que el riesgo identificado no pueda presentarse 3o se presente debilitado4.&ndependientemente de la solución por la que optemos, el análisis de riesgos nos ense%a que)emos de de(ar un margen para imprevistos previsibles y a%adir cierta )olgura a la

planificación de nuestro proyecto. 6as )ipótesis bara(adas al analizar riesgos potenciales pueden convertirse en realidad y nunca está de más de(ar algo de margen de maniobra.



18


Estimación

Sin duda, una de las tareas más peliagudas de cualquier proyecto de desarrollo de soft1are esla estimación inicial del coste de algo que a7n no conocemos. $e )ec)o, la realización demalas estimaciones )a sido identificada como una de las dos causas más comunes del fracasode un proyecto de desarrollo de soft1are 32lass, ;??>4. 6a otra es la eistencia derequerimientos inestables su(etos a continuos cambios.

Como di(o 5H)r, la predicción es dif0cil, especialmente si se trata del futuro. #demás, laestimación 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 estimación.#fortunadamente, eisten algunas reglas )eur0sticas que nos pueden ayudar a estimar con una

precisión razonable el coste y duración de un proyecto. 'l arte de una buena estimación está basado, fundamentalmente, en la eperiencia del estimador. 9aber participado en proyectosde similares caracter0sticas puede ser esencial para que seamos capaces de realizar una buenaestimación. :ambién podemos obtener resultados aceptables si tenemos en cuenta losiguiente

! Iunca se )a de realizar una estimación sobre la marc)a, por muc)o que nos presionen. Una respuesta apresurada sólo sirve para pillarnos los dedos y quedespués no podamos cumplir con las epectativas que nosotros mismos )emoscreado. Una estimación siempre )a de ser meditada, tras un estudio

pormenorizado de los distintos factores que pueden afectar a la realización denuestro proyecto.

! 6a incertidumbre en la estimación es inevitable, pero en ocasiones puedereducirse. Cuantos más datos )istóricos recopilemos y más precisa sea lainformación de la que dispongamos acerca de nuestro proyecto, me(or será nuestraestimación.

! 9emos de descomponer nuestro proyecto en tareas de la granularidad adecuada.'l error que se comete al estimar el con(unto de las actividades del proyecto esmayor que el que se comete cuando estimamos cada una de las actividades por separado. 6os errores que cometamos en las distintas estimaciones tenderán acompensarse 3la ley de los grandes n7meros en acción4.

! 's muy frecuente subestimar el esfuerzo necesario cuando descomponemos un problema comple(o en multitud de tareas. 'sto se debe a que, durante el transcursodel proyecto, también )an de realizarse otras muc)as tareas que probablemente)ayamos olvidado incluir en nuestra estimación. #demás, consideradas de formaindependiente, las distintas tareas del proyecto resultan aparentemente más fácilesde realizar de lo que en realidad son.

! 8esulta aconse(able utilizar varias técnicas de estimación y contrastar losresultados con ellas obtenidos. "or e(emplo, podemos realizar una estimación enfunción del coste un proyecto similar, utilizar alg7n modelo matemático de



19


estimación 3C<C<J< o similar4 y realizar una tercera estimacióndescomponiendo nuestro proyecto en tareas. Si los resultados obtenidos con las

distintas técnicas de estimación son similares, probablemente nuestra estimaciónsea buena.

Planificación temporal asignación de recursos

Una vez que )emos decidido seguir adelante con nuestro proyecto, )emos de planificar sutemporización. Una planificación ecesivamente detallada 3con el proyecto descompuesto entareas de un d0a, por e(emplo4 puede resultar contraproducente. Cualquier error de

planificación causado por alg7n imprevisto nos forzará a replanificar el resto del proyecto,retrasando a7n más nuestro proyecto. Una planificación por semanas suele ser razonable para

afrontar con comodidad las contingencias con las que nos vayamos encontrando sin tener queestar continuamente rea(ustando el plan del proyecto.

"ase lo que pase, la planificación del proyecto )a de rea(ustarse cada vez que cambien lascircunstancias del mismo. Si no se )a podido terminar una tarea en el tiempo inicialmenteestablecido, no nos vale suponer alegremente que posteriormente se recuperará el tiempo

perdido. 6os proyectos se retrasan poco a poco. $ebemos aprovec)ar las primeras se%ales dealarma y no esconderlas deba(o de la alfombra fingiendo que todo marc)a seg7n lo previsto.

:ampoco vale decir que algo está casi terminado. < lo está o no lo está. Si no lo está, el plan)a de a(ustarse a la situación real del proyecto. "ensar que algo está casi acabado sólo sirve

para darnos una falsa sensación de seguridad. #demás, el +?@ final de algo tiende a requerir el ?@ del tiempo, as0 que no nos sirve de nada saber que )emos realizado ?@ del esfuerzosi no podemos asegurar a qué parte corresponde el ;?@ que nos queda 3Ea la que se terminarápidamente o a la que consume la mayor parte de nuestro tiempoG4. Como dice un vie(oadagio =la primera mitad se lleva el ?@ del tiempoK la segunda, el ?@ restante=. Io usenunca en su planificación el )ec)o de que determinadas actividades del proyecto están casiterminadas.

6a planificación es fundamental en la gestión de un proyecto de desarrollo de soft1are."rocure siempre mantener su plan al d0a. Un plan que no se a(usta a la realidad no sirve demuc)o. Cuando alg7n retraso indique que posiblemente le será imposible cumplir los plazosestablecidos, )able con su cliente. # él le interesa saberlo y, aunque probablemente no se loagradezca, a la larga resultará beneficioso y usted )abrá cumplido con su obligación

profesional.

!lgunos errores comunes



18


Cuando las cosas no marc)en del todo bien, )emos de evitar tomar algunas medidasque lo 7nico que conseguirán es per(udicarnos. #qu0 van algunas de las más comunes

! #breviar las etapas iniciales del proceso de desarrollo de soft1are 3planificacióny análisis, generalmente4 para pasar directamente a la =construcción= del sistema.6os errores cometidos en las fases iniciales de un proyecto son muc)o máscostosos de corregir a la larga, por lo que abreviar las etapas iniciales tienegraves consecuencias.

! Io gestionar adecuadamente los cambios que inevitablemente ocurren durante el proyecto. :an malo es permitir cualquier cambio de forma indiscriminada comoser ecesivamente r0gidos a la )ora de no admitir cambios aunque éstos seanrazonables.

! 8educir la interacción con el cliente, ya que aparentemente sólo se dedica aentorpecer nuestro traba(o con sus continuos cambios de opinión y susepectativas poco realistas. Craso error. #l fin y al cabo, el cliente es la personacuyas necesidades )emos de descubrir y satisfacer.

! <lvidar que a%adir personal a un proyecto retrasado, por lo general, sólo loretrasa más 3la ley de 5rooLs4. 6a curva de aprendiza(e que se necesita paracomenzar a ser productivo )a de tenerse siempre en cuenta. #demás, Equién leresuelve las dudas al recién incorporadoG 'l tiempo que empleen los demásmiembros del equipo será tiempo que no podrán utilizar en otras cosas.

! Someter a los miembros de nuestro equipo a continuas interrupciones durante su (ornada de traba(o 3llamadas telefónicas, reuniones, consultas...4. 6as calidad deltraba(o intelectual depende de la capacidad del traba(ador de mantener su =estado

!lgunos errores comunes



19


de flu(o= 3un estado rela(ado de inmersión total en un problema que facilita su

comprensión y la generación de soluciones4. Se tarda unos + minutos enconseguir este estado, por lo que una simple interrupción cada +? minutos afectadrásticamente al rendimiento del traba(ador.

! 9acer traba(ar )oras etra a los miembros del equipo de desarrollo sólo sirve para disminuir su productividad 3traba(o realizado por unidad de tiempo4. :rasun larga (ornada de traba(o, la mente pierde su frescura y comete errores queluego tendrán que corregirse. E#divina cómoG Con más )oras etra.

! Io informar de peque%os retrasos pensando que más tarde se recuperará eltiempo perdido. 6a planificación temporal del proyecto debe ir a(ustándoseconforme vamos aprendiendo más cosas acerca del problema al que nos

enfrentamos. 'n el peor de los casos, se deben negociar algunos recortes con elcliente si éste desea mantener los plazos estipulados al comienzo del proyecto.

! Confiar ecesivamente en la me(ora de rendimiento que se producirá gracias aluso de una nueva )erramienta, tecnolog0a o metodolog0a 3error conocido como el=s0ndrome de la bala de plata= en )onor a un art0culo muy recomendable escrito

por Mred 5rooLs No silver bullets - Essence and accidents of Software

Engineering , Computer , +D4.

<bserve el tipo de errores comunes que aparece en la lista anterior. 'n general, no prestar la debida atención a las necesidades de los integrantes del equipo de desarrolloo a las del cliente garantiza que un proyecto no terminará con éito. 'l factor )umanoes más importante que el técnico.

!nálisis6o primero que debemos )acer para construir un sistema de información es averiguar qué eseactamente lo que tiene que )acer el sistema. 6a etapa de análisis en el ciclo de vida delsoft1are corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmentese necesita y se llega a una comprensión adecuada de los requerimientos del sistema 3lascaracter0sticas que el sistema debe poseer4.

!or "u# resulta esencial la etapa de an$lisis% Simplemente, porque si no sabemos con precisión qué es lo que se necesita, ning7n proceso de desarrollo nos permitirá obtenerlo. 'l problema es que, de primeras, puede que ni nuestro cliente sepa de primeras qué eseactamente lo que necesita. "or tanto, deberemos ayudarle a averiguarlo con ayuda dedistintas técnicas 3algunas de las cuales aprenderemos a utilizar más adelante4.

!or "u# es tan importante averiguar e&actamente cu$les son los re"uerimientos del sistema si el software es f$cilmente maleable 'aparentemente(% "orque el coste de construir correctamente un sistema de información a la primera es muc)o menor que el coste de



18


construir un sistema que )abrá que modificar más adelante. Cuanto antes se detecte un error,me(or. $istintos estudios )an demostrado que eliminar un error en las fases iniciales de un

proyecto 3en la etapa de análisis4 resulta de +? a +?? veces más económico que subsanarlo alfinal del proyecto. Conforme avanza el proyecto, el soft1are se va describiendo con un mayor nivel de detalle, se concreta cada vez más y se convierte en algo cada vez más r0gido.

Es posible determinar de antemano todos los re"uerimientos de un sistema de informaci)n%$esgraciadamente, no. $e )ec)o, una de las dos causas más comunes de fracaso en proyectosde desarrollo de soft1are es la inestabilidad de los requerimientos del sistema 3la otra es unamala estimación del esfuerzo requerido por el proyecto4. 'n el caso de una mala estimación,el problema se puede solucionar estableciendo ob(etivos más realistas. Sin embargo, en lasetapas iniciales de un proyecto, no disponemos de la información necesaria para determinar eactamente el problema que pretendemos resolver. "or muc)o tiempo que le dediquemos al

análisis del problema 3un fenómeno conocido como la parálisis del análisis4.6a inestabilidad de los requerimientos de un sistema es inevitable. Se estima que un ;@ delos requerimientos iniciales de un sistema cambian antes de que el sistema comience autilizarse. Juc)as prácticas resultan efectivas para gestionar adecuadamente losrequerimientos de un sistema y, en cierto modo, controlar su evolución. Un buen analistadeber0a tener una formación adecuada en

! :écnicas de elicitación de requerimientos.

! 9erramientas de modelado de sistemas.

! Jetodolog0as de análisis de requerimientos.

"#cnicas de elicitación de re$uerimientos

'n la fase de análisis, los errores más dif0ciles 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 epl0citamente. "or este motivo, elicitar los requerimientos deun sistema de información 3esto es, obtener de alg7n modo cuáles son realmente esosrequerimientos4 resulta una actividad esencial en cualquier proceso de desarrollo de soft1are.

6a elicitación de requerimientos requiere previamente la identificación de las personasafectadas por el proyecto, sus sta*eholders 3literalmente, los que apuestan algo4, lo queincluye desde el cliente que paga el proyecto )asta los usuarios finales de la aplicación, sinolvidarse de terceras personas y organizaciones relacionadas indirectamente con el sistemaque se va a desarrollar 3por e(emplo, empresas competidoras y organismos reguladores4.

'n la elicitación de requerimientos se recurre a distintas técnicas que favorezcan lacomunicación entre el analista y el resto de personas involucradas, como puede ser larealización de entrevistas 3en las que importa no sólo lo que se pregunta, sino cómo se



19


pregunta4, el dise%o de cuestionarios 3cuando no tenemos tiempo ni recursos para entrevistar personalmente a todo el mundo4 o el desarrollo de prototipos 3para recoger información que,

de otra forma, no obtendr0amos )asta las etapas finales del proyecto, cuando cualquier rectificación saldr0a muc)o más cara4. :ambién se puede observar el funcionamiento normaldel entorno en el que se instalará nuestro sistema o, incluso, participar activamente en él 3por e(emplo, desempe%ando temporalmente el traba(o de los usuarios de nuestro sistema4. "or 7ltimo, también podemos investigar por nuestra cuenta consultando documentos relacionadoscon el tema de nuestro proyecto o estudiando productos similares que ya eistan en elmercado.

%erramientas de modelado de sistemas

Un modelo, básicamente, no es más que una simplificación de la realidad. 'l uso de modelosen la construcción de sistemas de información resulta esencial por los siguientes motivos

! 6os modelos ayudan a comunicar la estructura de un sistema comple(o 3y, por tanto, acomunicarnos con las demás personas involucradas en un proyecto4.

! 6os modelos sirven para especificar el comportamiento deseado del sistema 3como gu0a para las etapas posteriores del proyecto4.

! 6os modelos nos ayudan a comprender me(or lo que estamos dise%ando 3por e(emplo, para detectar inconsistencias y corregirlas4.

! 6os modelos nos permiten descubrir oportunidades de simplificación 3a)orrarnostraba(o en el proyecto actual4 y de reutilización 3a)orrarnos traba(o en futuros

proyectos4.

'n resumidas cuentas, los modelos, entre otras cosas, facilitan el análisis de losrequerimientos del sistema, as0 como su posterior dise%o e implementación. Un modelo, endefinitiva, proporciona =los planos= de un sistema. 'l modelo )a de capturar =lo esencial=desde determinado punto de vista. 'n función de para qué queramos el modelo, lo )aremosmás o menos detallado, siempre de acuerdo a su relevancia y utilidad.

Un sistema de información es un sistema comple(o, por lo que a 3casi4 nadie se le ocurrir0aintentar describirlo utilizando un 7nico modelo. $e )ec)o, todo sistema puede describirsedesde distintos puntos de vista y nosotros utilizaremos distintos tipos de modelos dependiendodel aspecto del sistema en que deseemos centrar nuestra atención

! 'isten modelos estructurales que nos ayudan a la )ora de organizar un sistemacomple(o. "or e(emplo, un diagrama entidad/relación nos indica cómo se estructuran losdatos de un sistema de información, mientras que un diagrama de flu(o de datos nos dainformación acerca de cómo se descompone un sistema en subsistemas y del flu(o dedatos que eiste entre los distintos subsistemas.



18


! :ambién eisten modelos de comportamiento que nos permiten analizar y modelar ladinámica de un sistema. "or e(emplo, un diagrama de estados representa los distintos

estados en que puede encontrarse un sistema y cómo se puede pasar de un estado a otro,mientras que la descripción de un caso de uso nos ayuda a comprender la secuencia de pasos involucrada en la consecución de un ob(etivo concreto por parte de un usuario delsistema.

Jás adelante aprenderemos las notaciones asociadas a distintos tipos de modelos cuyautilización resulta recomendable en el dise%o de un sistema de información. #prenderemos susignificado, veremos su utilidad y ofreceremos algunos conse(os )eur0sticos acerca de sucorrecto uso.

Metodologías de análisis de re$uerimientos6as técnicas de elicitación de requerimientos y las )erramientas de modelado de sistemas delas que )emos )ablado en los párrafos anteriores deben utilizarse acompa%adas de unametodolog0a adecuada. 'n este conteto, una metodolog0a no es más que un con(unto deconvenciones que )an resultado 7tiles en la práctica y cuyo uso combinado se recomienda.

6as metodolog0as de análisis particulares, de las que )ay muc)as, usualmente están ligadas, o bien al uso de determinadas )erramientas 3por lo que el vendedor de la )erramienta seconvierte, muc)as veces, en el 7nico promotor de la metodolog0a4, o bien a empresas deconsultor0a concretas 3que ofrecen cursos de aprendiza(e de la metodolog0a que proponen4.

'n general, no obstante, la elección adecuada de las técnicas utilizadas dependerá de lasituación concreta en la que se encuentre nuestro proyecto. "or este motivo, lo más adecuadoes aprender cuantas más técnicas me(or y averiguar en qué situaciones resulta más efectivacada una de ellas.

DiseñoJientras que los modelos utilizados en la etapa de análisis representan los requisitos delusuario desde distintos puntos de vista 3el qué4, los modelos que se utilizan en la fase de

dise%o representan las caracter0sticas del sistema que nos permitirán implementarlo de formaefectiva 3el cómo4.

Un soft1are bien dise%ado debe e)ibir determinadas caracter0sticas. Su dise%o deber0a ser modular en vez de monol0tico. Sus módulos deber0an ser co)esivos 3encargarse de una tareaconcreta y sólo de una4 y estar débilmente acoplados entre s0 3para facilitar el mantenimientodel sistema4. Cada módulo deber0a ofrecer a los demás unos interfaces bien definidos 3alestilo del dise%o por contrato propuesto por 5ertrand Jeyer4 y ocultar sus detalles deimplementación 3siguiendo el principio de ocultación de información de "arnas4. "or 7ltimo,debe ser posible relacionar las decisiones de dise%o tomadas con los requerimientos del



19


sistema que las ocasionaron 3algo que se suele denominar =trazabilidad de losrequerimientos=4.

'n la fase de dise%o se )an de estudiar posibles alternativas de implementación para elsistema de información que )emos de construir y se )a de decidir la estructura general quetendrá el sistema 3su diseño arquitectónico4. 'l dise%o de un sistema es comple(o y el

proceso de dise%o )a de realizarse de forma iterativa. 6a solución inicial que propongamos probablemente no resulte la más adecuada para nuestro sistema de información, por lo quedeberemos refinarla. #fortunadamente, tampoco es necesario que empecemos desde cero.'isten auténticos catálogos de patrones de dise%o que nos pueden servir para aprender de loserrores que otros )an cometido sin que nosotros tengamos que repetirlos.

&gual que en la etapa de análisis creábamos distintos modelos en función del aspecto delsistema en que centrábamos nuestra atención, el dise%o de un sistema de información también

presenta distintas facetas

! "or un lado, es necesario abordar el diseño de la base de datos, un tema quetrataremos detalladamente más adelante.

! "or otro lado, también )ay que dise%ar las aplicaciones que permitirán al usuarioutilizar el sistema de información. :endremos que dise%ar la interfaz de usuariodel sistema y los distintos componentes en que se descomponen las aplicaciones.$e esto 7ltimo )ablaremos en las dos secciones siguientes.

!r$uitecturas multicapa

6a división de un sistema en distintas capas o niveles de abstracción es una de las técnicasmás comunes empleadas para construir sistemas comple(os. 'sta división se puede apreciar enel )ard1are, donde el dise%o de un sistema en un lengua(e de alto nivel como N9$6 oNerilog se traduce en un dise%o a nivel de registros lógicos 38:64K éste se implementamediante puertas lógicas, a partir de las cuales se obtiene un dise%o a nivel de transistoresK lostransistores, finalmente, se crean en un circuito integrado con una serie de máscaras. 6os

protocolos de red también se dise%an utilizando distintas capas la capa de aplicación 39::"4utiliza los servicios de la capa de transporte 3:C"4, la cual se implementa sobre la capa de red

3&"4 y as0 sucesivamente )asta llegar a la transmisión f0sica de los datos a través de alg7nmedio de transmisión.

'n realidad, el uso de capas es una forma más de la técnica de resolución de problemasconocida con el nombre de =divide y vencerás=, que se basa en descomponer un problemacomple(o en una serie de problemas más sencillos de forma que se pueda obtener la soluciónal problema comple(o a partir de las soluciones a los problemas más sencillos. #l dividir unsistema en capas, cada capa puede tratarse de forma independiente 3sin tener que conocer losdetalles de las demás4.



18


$esde el punto de vista de la &ngenier0a del Soft1are, la división de un sistema en capasfacilita el dise%o modular 3cada capa encapsula un aspecto concreto del sistema4 y permite la

construcción de sistemas débilmente acoplados 3si minimizamos las dependencias entrecapas, resultará más fácil sustituir la implementación de una capa sin afectar al resto delsistema4. #demás, el uso de capas también fomenta la reutilización 3p.e(. :C"/&" se utiliza enuna amplia variedad de aplicaciones, desde 9::" y M:" )asta telnet y SS94.

Como es lógico, la parte más dif0cil en la construcción de un sistema multicapa es decidir cuántas capas utilizar y qué responsabilidades asignarle a cada capa.

'n las arquiecturas cliente/servidor se suelen utilizar dos capas. 'n el caso de lasaplicaciones informáticas de gestión, esto se suele traducir en un servidor de bases de datos enel que se almacenan los datos y una aplicación cliente que contiene la interfaz de usuario y la

lógica de la aplicación.'l problema con esta descomposición es que la lógica de la aplicación suele acabar mezcladacon los detalles de la interfaz de usuario, dificultando las tareas de mantenimiento a que todosoft1are 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 primer momento.

Jantener la misma arquitectura y pasar la lógica de la aplicación al servidor tampoco resultauna solución demasiado acertada. Se puede implementar la lógica de la aplicación utilizando

procedimientos almacenados, pero éstos suelen tener que implementarse en lengua(esestructurados no demasiado versátiles. #demás, suelen ser lengua(es espec0ficos para cada

tipo de base de datos, por lo que la portabilidad del sistema se ve gravemente afectada.

6a solución, por tanto, pasa por crear nueva capa en la que se separe la lógica de la aplicaciónde la interfaz de usuario y del mecanismo utilizado para el almacenamiento de datos. 'lsistema resultante tiene tres capas

! 6a capa de presentación, encargada de interactuar con el usuario de la aplicaciónmediante una interfaz de usuario 3ya sea una interfaz 1eb, una interfaz Bindo1s ouna interfaz en l0nea de comandos, aunque esto 7ltimo suele ser menos )abitual enla actualidad4.

! 6a lógica de la aplicación Oa la que se suele )acer referencia como business logico domain logicP, usualmente implementada utilizando un modelo orientado aob(etos del dominio de la aplicación, es la responsable de realizar las tareas paralas cuales se dise%a el sistema.

! 6a capa de acceso a los datos, encargada de gestionar el almacenamiento de losdatos, generalmente en un sistema gestor de bases de datos relacionales, y de lacomunicación del sistema con cualquier otro sistema que realice tareas auiliares3p.e(. middle1are4.



19


Cuando el usuario del sistema no es un usuario )umano, se )ace evidente la similitud entre lascapas de presentación y de acceso a los datos. :eniendo esto en cuenta, el sistema puede verse

como un n7cleo 3lógica de la aplicación4 en torno al cual se crean una serie de interfaces conentidades eternas. 'sta vista simétrica del sistema es la base de la ar"uitectura he&agonal de#listair CocLburn.

Io obstante, aunque sólo fuese por las peculiaridades del dise%o de interfaces de usuario,resulta 7til mantener la vista asimétrica del soft1are como un sistema formado por tres capas."or e(emplo, la interfaz de usuario debe permitir que el usuario se pueda equivocar 3yrectificar de la manera menos traumática posible4 y estar especialmente dise%ada para agilizar su traba(o 3y nunca entorpecerlo4. #demás, suele ser recomendable diferenciar lo que sesuministra 3presentación4 de lo que se consume 3acceso a los servicios suministrados por otrossistemas4.

# pesar del atractivo de esta arquitectura con tres capas 3basta con pensar lo que facilitar0a laconversión de aplicaciones Bindo1s en aplicaciones 1eb4, esta arquitectura no se )aimpuesto del todo porque las )erramientas de desarrollo suelen estar dise%adas para construir aplicaciones cliente/servidor ligadas a alg7n productor de soft1are. $e )ec)o, puede resultar dif0cil 3e incluso imposible4 descomponer un sistema en tres capas con determinadas)erramientas de desarrollo.

&otas acerca del diseño de las aplicaciones

Si suponemos que )emos sido capaces de separar el n7cleo de la aplicación de sus distintos

interfaces, a7n nos queda por decidir cómo vamos a organizar la implementación de la lógicaasociada a la aplicación. Como en cualquier otra tarea de dise%o, tenemos que llegar a uncompromiso adecuado entre distintos intereses. "or un lado, nos gustar0a que el dise%oresultante fuese lo más sencillo posible. "or otro lado, ser0a deseable que nuestro dise%oestuviese bien preparado para soportar las modificaciones que )ayan de realizarse en elfuturo.

"or lo general, el dise%o de la lógica una aplicación se suele a(ustar a uno de los tressiguientes patrones de dise%o

! Rutinas 6a forma más simple de implementar cualquier sistema se basa enimplementar procedimientos y funciones que acepten y validen las entradasrecibidas de la capa de presentación, realicen los cálculos necesarios, utilicen losservicios de aquellos sistemas que )agan falta para completar la operación,almacenen los datos en las bases de datos y env0en una respuesta adecuada alusuario. 5ásicamente, cada acción que el usuario pueda realizar se traducirá en un

procedimiento que realizará todo lo que sea necesario al más puro estilo deldise%o estructurado tradicional. #unque este modelo sea simple y pueda resultar adecuado a peque%a escala, la evolución de las aplicaciones dise%adas de estaforma suele acabar siendo una pesadilla para las personas encargadas de sumantenimiento.



18


! Módulos de datos #nte la situación descrita en el párrafo anterior, lo usual esdividir el sistema utilizando los distintos con(untos de datos con los que traba(a la

aplicación para crear módulos más o menos independientes. $e esta forma, sefacilita la eliminación de lógica duplicada. $e )ec)o, muc)os de los entornos dedesarrollo visual de aplicaciones permiten definir módulos de datos queencapsulen los con(untos de datos con los que se traba(a y la lógica asociada aellos. 6as )erramientas de 5orland, $elp)i y CQQ5uilder, son un claro e(emplo,igual que el $eveloper de <racle. Jicrosoft, en su arquitectura $I# O$istributedinterIet #pplicationP, fomenta este estilo al emplear con(untos de datos 3resultadode e(ecutar consultas SF64 sobre los cuales operan directamente las distintascapas de una aplicación multicapa. 'n el caso de la plataforma .I':, la claseDataSet proporciona la base sobre la que se montar0a todo el dise%o de unaaplicación 3algo que obviamente facilita el Nisual Studio .I':4.

! Modelo del dominio Una tercera opción, la ideal para cualquier purista de laorientación a ob(etos, es crear un modelo orientado a ob(etos del dominio de laaplicación. 'n vez de que una rutina se encargue de todo lo que )aya que )acer

para completar una acción, cada ob(eto es responsable de realizar las tareas que leata%en directamente.

'n la práctica, no todo es blanco o negro. #unque empleemos un modelo orientado a ob(etosdel dominio de la aplicación, es )abitual crear una capa intermedia entre la capa de

presentación y la lógica de la aplicación a la que se suele denominar capa de servicio. 6ainterfaz de la capa de servicio incluirá métodos asociados a las distintas acciones que pueda

realizar el usuario, si bien, en vez de incluir en ella la lógica de la aplicación, la capa deservicio delega inmediatamente en los ob(etos responsables de cada tarea. 'n cierto modo, lacapa de servicio se encarga de la lógica espec0fica de la aplicación, de(ando para el modelodel dominio la lógica del dominio 3com7n a cualquier aplicación que se construya sobre elmismo dominio de aplicación4.

Cualquier aplicación sufre modificaciones de mayor o menor importancia a lo largo de su vida7til. $ic)as modificaciones alteran el dise%o inicial de la aplicación y tienden a aumentar suentrop0a. Si utilizamos rutinas para implementar la lógica de nuestra aplicación en el sentidotradicional, las modificaciones pueden suponer tener que revisar el código completo de laaplicación para descubrir lo que )ay que actualizar. 's como si tuviésemos una )abitacióncompletamente desordenada en la que )ay que encontrar algo en particular. 'n el caso de losmódulos de datos, el impacto de las modificaciones suele ser más fácil de determinar pero,a7n as0, podemos encontrarnos con sorpresas desagradables si todos los módulos de nuestraaplicación traba(an sobre un con(unto de datos cuya estructura debemos alterar ligeramente."or 7ltimo, si dise%amos un buen modelo orientado a ob(etos, la encapsulación proporcionada

por los ob(etos de nuestra aplicación permitirá que el impacto de las modificaciones sea decarácter local en la mayor0a de las ocasiones. 'n cierto modo, estamos limitando el aumentode la entrop0a al interior de los ca(ones 3algo que la mayor0a de nosotros tolera sin demasiados

problemas4.

'obre el acceso a los datos



19


'isten distintas formas en las que una aplicación implementada utilizando unlengua(e de programación de propósito general puede acceder a los datos, almacenados

por lo general en una base de datos relacional

! 6a primera opción que se nos puede ocurrir cuando dise%amos un sistemaorientado a ob(etos es utilizar un registros activos, ob(etos que encapsulandirectamente las estructuras de datos eternas 3p.e(. las tuplas de las tablas de la

base de datos4 e incorporan la lógica del dominio que les corresponda, aparte delas operaciones necesarias para obtener y guardar ob(etos en la base de datos.

! #lgo más adecuado puede resultar el empleo de gateways, clases auiliares quese corresponden con las tablas de la base de datos e implementan las operacionesnecesarias para manipular la base de datos OC8U$ Create, 8etrieve, Update R$eleteP. 'stas clases auiliares nos permiten no mezclar la lógica de laaplicación con el acceso a los datos eternos, tal como sucede si utilizamosregistros activos.

! 6a tercera opción 3y siempre )ay una tercera opción4 es la más comple(a pero lamás fleible O/R Mapping. Se basa en establecer una correspondencia entre elmodelo orientado a ob(etos del dominio y la representación de los distintosob(etos en una base de datos relacional. 'n las dos alternativas anteriores, losob(etos de la aplicación )an de ser conscientes de cómo se representan en la basede datos. 'n el caso del +, .apping , los ob(etos pueden ignorar la estructura dela base de datos y cómo se realiza la comunicación con la base de datos. 6a

inversión de control caracter0stica de esta opción independiza el modeloorientado a ob(etos del dominio de la capa de acceso a los datos se puedecambiar la base de datos sin tener que tocar el modelo orientado a ob(etos deldominio y viceversa. $e esta forma, se facilita el desarrollo, la depuración y laevolución de las aplicaciones.

Cuando para implementar la aplicación se utiliza una )erramienta de programaciónvisual 3tipo Nisual Studio .I':, CQQ5uilder, $elp)i o $eveloper4, generalmente no

podemos elegir la forma en que nuestra aplicación accederá a los datos. "ese a ello,siempre eiste cierto margen de maniobra que podemos aprovec)ar para dise%ar nuestro sistema lo me(or posible.

!viso

6as etapas posteriores del ciclo de vida de un sistema de información3implementación, pruebas, despliegue, uso y mantenimiento4 se describen acontinuación con menor grado de detalle que las anteriores 3planificación, análisis ydise%o4 porque su influencia es significativamente menor sobre el proceso de dise%o de

bases de datos.



18


(mplementación

Una vez que sabemos qué funciones debe desempe%ar nuestro sistema de información3análisis4 y )emos decidido cómo vamos a organizar sus distintos componentes 3dise%o4, es elmomento de pasar a la etapa de implementación, pero nunca antes. #ntes de escribir una solal0nea de código 3o de crear una tabla en nuestra base de datos4 es fundamental )aber comprendido bien el problema que se pretende resolver y )aber aplicado principios básicos dedise%o que nos permitan construir un sistema de información de calidad.

"ara la fase de implementación )emos de seleccionar las )erramientas adecuadas, un entornode desarrollo que facilite nuestro traba(o y un lengua(e de programación apropiado para el tipode sistema que vayamos a construir. 6a elección de estas )erramientas dependerá en gran

parte de las decisiones de dise%o que )ayamos tomado )asta el momento y del entorno en el

que nuestro sistema deberá funcionar.# la )ora de programar, deberemos procurar que nuestro código no resulte indescifrable. "araque nuestro código sea legible, )emos de evitar estructuras de control no estructuradas, elegir cuidadosamente los identificadores de nuestras variables, seleccionar algoritmos y estructurasde datos adecuadas para nuestro problema, mantener la lógica de nuestra aplicación lo mássencilla posible, comentar adecuadamente el teto de nuestros programas y, por 7ltimo,facilitar la interpretación visual de nuestro código mediante el uso de sangr0as y l0neas en

blanco que separen distintos bloques de código.

#demás de las tareas de programación asociadas a los distintos componentes de nuestrosistema, en la fase de implementación también )emos de encargarnos de la adquisición detodos los recursos necesarios para que el sistema funcione 3por e(emplo, las licencias de usodel sistema gestor de bases de datos que vayamos a utilizar4. Usualmente, tambiéndesarrollaremos algunos casos de prueba que nos permitan ir comprobando el funcionamientode nuestro sistema conforme vamos construyéndolo.

)ontrol de versiones

'n todo proyecto de desarrollo de soft1are resulta fundamental una adecuada gestiónde la configuración del soft1are 3SCJ, Software Configuration .anagement 4, másconocida vulgarmente por uno de sus aspectos, el control de versiones. $e )ec)o, esuna actividad clave en el nivel ; del CJJ 3Capability .aturity .odel 4, un modelo demadurez del proceso de desarrollo del soft1are en el cual el nivel + representa la

anarqu0a.

&ndependientemente de su importancia en el control del proceso de desarrollo desoft1are 3algo innegable4, su valor es incalculable para evitar pérdidas irreparables3siempre y cuando se )agan copias de seguridad de la base de datos de nuestra)erramienta de control de versiones4 y también para volver cómodamente a unaversión anterior de nuestro código si nuestras 7ltimas modificaciones del código noresultaron del todo acertadas.



19


Pruebas

'rrar es )umano y la etapa de pruebas tiene como ob(etivo detectar los errores que se )ayan podido cometer en las etapas anteriores del proyecto 3y, eventualmente, corregirlos4. 6o suyo,además, es )acerlo antes de que el usuario final del sistema los tenga que sufrir. $e )ec)o,una prueba es un éito cuando se detecta un error 3y no al revés, como nos gustar0a pensar4.

6a b7squeda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas,en función del conteto y de la fase del proyecto en la que nos encontremos

! 6as pruebas de unidad sirven para comprobar el correcto funcionamiento de uncomponente concreto de nuestro sistema. 's este tipo de pruebas, el =probador=debe buscar situaciones l0mite que epongan las limitaciones de laimplementación del componente, ya sea tratando éste como una ca(a negra3=pruebas de ca(a negra=4 o fi(ándonos en su estructura interna 3=pruebas de ca(a

blanca=4. 8esulta recomendable que, conforme vamos a%adiéndole nuevafuncionalidad a nuestras aplicaciones, vayamos creando nuevos tests con losmedir nuestro progreso y también repitamos los antiguos para comprobar que loque antes funcionaba sigue funcionando 3test de regresi)n4.

! 6as pruebas de integración son las que se realizan cuando vamos (untando loscomponentes que conforman nuestro sistema y sirven para detectar errores en susinterfaces. 'n algunas empresas, como Jicrosoft, se )ace una compilación diariautilizando los componentes del sistema tal como estén en ese momento 3daily

build 4 y se somete al sistema a una serie de pruebas básicas 3la prueba de )umo, smo*e test 4 que garanticen que el proyecto podrá seguir avanzando al d0asiguiente. 'l causante de que la compilación diaria falle suele tener que quedarse a)acer )oras etra para que sus compa%eros puedan seguir traba(ando al d0asiguiente...

! Una vez =finalizado= el sistema, se realizan pruebas alfa en el seno de laorganización encargada del desarrollo del sistema. 'stas 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 un producto en el mercado, también se suelen realizar pruebas beta. 'stas pruebaslas )acen usuarios finales del sistema a(enos al equipo de desarrollo y puedenresultar vitales para que un producto tenga éito en el mercado.

! 'n sistemas a medida, se suele realizar un test de aceptación que, si se supera conéito, marcará oficialmente el final del proceso de desarrollo y el comienzo de laetapa de mantenimiento.



18


! "or 7ltimo, a lo largo de todo el ciclo de vida del soft1are, se suelen )acer revisiones de todos los productos generados a lo largo del proyecto, desde el

documento de especificación de requerimientos )asta el código de los distintosmódulos de una aplicación. 'stas revisiones, de carácter más o menos formal,ayuden a verificar la corrección del producto revisado y también a validarlo3comprobar que se a(usta a los requerimientos reales del sistema4.

#unque es imposible garantizar la ausencia de errores en el soft1are, una adecuadacombinación de distintas técnicas de prueba puede ayudar más del ?@ de los errores que seencontrarán a lo largo de toda la vida del sistema. #unque podamos ser reacios a admitirlo, lonormal es que el -?@ de nuestro tiempo lo =perdamos= eliminando errores, mientras que sóloempleamos un ;?@ en la etapa de análisis, otro ;?@ en el dise%o y el ;?@ restante en laimplementación del sistema 38obert 2lass, /uilding "uality software, +;4.

#l realizar cualquiera de los tipos de prueba descritos, es importante recordar que eldesarrollo de soft1are es una actividad que se realiza en equipo, por lo que pueden surgir roces personales y disputas pol0ticas entre los miembros del equipo. 6as pruebas resultan

particularmente delicadas en este sentido, ya que su ob(etivo es, al fin y al cabo, encontrar defectos.

(nstalación * Despliegue

Una vez concluidas las etapas de desarrollo de un sistema de información 3análisis, dise%o,implementación y pruebas4, llega el instante de que poner el sistema en funcionamiento, suinstalación o despliegue.

$e cara a su instalación, )emos de planificar el entorno en el que el sistema debe funcionar,tanto )ard1are como soft1are equipos necesarios y su configuración f0sica, redes deinterconeión entre los equipos y de acceso a sistemas eternos, sistemas operativos3actualizados para evitar problemas de seguridad4, bibliotecas y componentes suministrados

por terceras partes, etcétera.

"ara asegurar el correcto funcionamiento del sistema, resulta esencial que tengamos en cuentalas dependencias que pueden eistir entre los distintos componentes del sistema y sus

versiones. Una aplicación puede que sólo funcione con una versión concreta de una bibliotecaauiliar. Un disco duro puede que sólo rinda al nivel deseado si instalamos un controlador concreto. Componentes que por separado funcionar0an correctamente, combinados causan

problemas, por lo que deberemos utilizar sólo combinaciones conocidas que no presenten problemas de compatibilidad.

Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintasfases, también )emos de planificar cuidadosamente la transición del sistema antiguo al nuevode forma que sus usuarios no sufran una disrupción en el funcionamiento del sistema. 'nocasiones, el sistema se instala f0sicamente en un entorno duplicado y la transición se )ace de



19


forma instantánea una vez que la nueva configuración funciona correctamente. Cuando el presupuesto no da para tanto, tal vez )aya que buscar un momento de ba(a utilización del

sistema para realizar la actualización 3por la noc)es o en fin de semana, por e(emplo4.

+so mantenimiento6a etapa de mantenimiento consume t0picamente del -? al ? por ciento de los recursos deuna empresa de desarrollo de soft1are. $e )ec)o, con un ?@ de media, es probablemente laetapa más importante del ciclo de vida del soft1are. $ada la naturaleza del soft1are, que ni serompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes

! 'liminar los defectos que se detecten durante su vida 7til 3mantenimientocorrectivo4, lo primero que a uno se le viene a la cabeza cuando piensa en elmantenimiento de cualquier cosa.

! #daptarlo a nuevas necesidades 3mantenimiento adaptativo4, cuando el sistema)a de funcionar sobre una nueva versión del sistema operativo o en un entorno)ard1are diferente, por e(emplo.

! #%adirle nueva funcionalidad 3mantenimiento perfectivo4, cuando se proponencaracter0sticas deseables que supondr0an una me(ora del sistema ya eistente.

$e las distintas facetas del mantenimiento, la eliminación de defectos sólo supone el +D@ delcoste de mantenimiento de un sistema, mientras que el dise%o e implementación de me(oras esresponsable del ?@ del coste de mantenimiento. 's decir, más de un tercio del coste total delsoft1are se emplea en a%adirle caracter0sticas a soft1are ya eistente 3el ?@ del ?@4. 6acorrección de errores supone, en contraste, =sólo= en torno al +?@ del coste total del soft1are.#7n menos cuanto me(ores sean las técnicas usadas en su desarrollo.

Se )a observado que, cuanto me(or sea el soft1are, más tendremos que invertir en sumantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos. 'ste )ec)o, que

puede parecer paradó(ico, se debe, simplemente, a que nuestro sistema se usará más 3a veces,de formas que no )ab0amos previsto4. "or tanto, nos llegarán más propuestas de modificación

y me(ora que si el sistema )ubiese quedado aparcado, cogiendo polvo, en alg7n rincón.Si eaminamos las tareas que se llevan a cabo durante la etapa de mantenimiento, nosencontramos que en el mantenimiento se repiten todas las etapas que ya )emos visto del ciclode vida de un sistema de información. #l tratar principalmente de cómo a%adirle nuevafuncionalidad a un sistema ya eistente, el mantenimiento repite =en miniatura= el ciclo devida completo de un sistema de información. 's más, a las tareas normales de desarrollo)emos de a%adirle una nueva, comprender el sistema que ya eiste, por lo que se podr0a decir que el mantenimiento de un sistema es más dif0cil que su desarrollo 32lass, ;??>4.



18


odelos de ciclo de vida

:odas las actividades descritas en las distintas secciones del apartado anterior están presentesen cualquier proyecto de desarrollo de soft1are 3además de otras muc)as relativas a la gestiónde un proyecto o a su control de calidad4. Sin embargo, las tareas concretas que se realicen 3ysu grado de rigor4 dependerán de la naturaleza del proyecto al que nos enfrentemos y de lascaracter0sticas de nuestro entorno de traba(o.

'l director de un proyecto, contando con el asesoramiento de los demás miembros del equipo,debe elegir los métodos y )erramientas más adecuados en cada momento para satisfacer lasnecesidades espec0ficas del proyecto, además de establecer las medidas oportunas que

permitan controlar la evolución del proyecto. 6as decisiones tomadas en este sentido )an de

tener como ob(etivo satisfacer los tiempos de entrega pactados con el cliente sin comprometer la calidad del producto final.

'isten distintas formas de organizar el orden concreto en el que se acometerán las distintasetapas del ciclo de vida de un sistema de información. 'n los siguientes párrafos se describenalgunas de las alternativas que deber0an tenerse en cuenta

)iclo de vida clásico

'l modelo de ciclo de vida clásico, también denominado =modelo en cascada=, se basa enintentar )acer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden,de una etapa a la siguiente sólo tras finalizar con éito las tareas de verificación y validación

propias de la etapa. Si resulta necesario, 7nicamente se da marc)a atrás )asta la faseinmediatamente anterior.

'ste modelo tradicional de ciclo de vida eige una aproimación secuencial al proceso dedesarrollo del soft1are. "or desgracia, esta aproimación presenta una serie de gravesinconvenientes, entre los que cabe destacar

! 6os proyectos reales raramente siguen el flu(o secuencial de actividades que propone

este modelo.

! Iormalmente, es dif0cil para el cliente establecer epl0citamente todos los requisitos alcomienzo del proyecto 3entre otras cosas, porque )asta que no vea evolucionar el

proyecto no tendrá una idea clara de qué es lo que realmente quiere4.

! Io )abrá disponible una versión operativa del sistema )asta llegar a las etapas

finales del proyecto, por lo que la rectificación cualquier decisión tomadaerróneamente en las etapas iniciales del proyecto supondrá un coste adicional



19


significativo, tanto económico como temporal 3y eso sin tener en cuenta la malaimpresión causada por un retraso en la fec)a de entrega4.

El ciclo de vida cl$sico0 .odelo 1en cascada12

:al cual, el modelo de ciclo de vida en cascada no nos indica nada acerca de la relacióncontractual eistente entre el cliente y la organización encargada del desarrollo de soft1are.$esde el punto de vista de una empresa de desarrollo de soft1are, formalizar la firma de uncontrato al final de la etapa de análisis, por e(emplo, puede ayudar a reducir el riesgo quesupone elaborar un presupuesto cuando a7n no se dispone de toda la información necesaria

para que la estimación del esfuerzo requerido por el proyecto sea lo suficientemente precisa.'ste tipo de contrato obliga a que el cliente se )aga cargo de los costes adicionales

ocasionados por cambios en los requerimientos, mientras que la empresa de desarrollo desoft1are deberá asumir los gastos ocasionados si el producto finalmente entregado no cumpletodas las condiciones pactadas a la firma del contrato.

"or desgracia, un modelo contractual como el descrito en el párrafo anterior no siempreresulta aceptable para el cliente, que puede verse obligado a invertir dinero a cambio de nada.'sto podr0a pasar si, tras la etapa de análisis, el proyecto se desestima por no ser técnica oeconómicamente viable. 's más, si el cliente acepta a rega%adientes la firma de un contrato alfinal de la etapa de análisis, la imagen de la empresa desarrolladora de soft1are puede verseseriamente deteriorada en cuanto sur(a cualquier tipo de problema.



18


"ara limar las asperezas que pueden surgir en la relación cliente!proveedor y me(orar elrendimiento del equipo del proyecto, )oy en d0a se suele recurrir a modelos iterativos como

los que se describirán a continuación.

Desarrollo de prototipos Iormalmente, el cliente es capaz de definir un con(unto general de ob(etivos para el sistemaque )emos de construir, pero no identifica los requisitos detallados. 'n otros casos, puede quenosotros no estemos seguros de la eficiencia de un algoritmo, de la capacidad de nuestrodise%o para soportar los requerimientos del sistema o de la forma en que debe dise%arse lainterfaz de usuario. 'n cualquiera de estas situaciones, resulta adecuado construir un

prototipo.

!rototipado

'l desarrollo de prototipos reduce el riesgo de que nuestro proyecto fracase y facilita laespecificación de requerimientos de productos que desconocemos. Sin embargo, tambiéntiene 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 eterno.'sto puede conducir a la consolidación de aspectos de ba(a calidad de un prototipo en elsistema final que se entrega si el prototipo no se desec)a a tiempo.

Mred 5rooLs nos aclara lo que )ay que )acer cuando un prototipo ya )a cumplido con su propósito 1En la mayor3a de los proyectos4 el primer sistema "ue se construye apenas resulta

utilizable2 !uede "ue sea demasiado lento4 demasiado grande4 dif3cil de usar o las tres cosas



19


a la vez2 No "ueda m$s remedio "ue comenzar de nuevo y construir una versi)n redise5ada

"ue resuelva los problemas222 Cuando se utiliza un concepto nuevo222 hay "ue construir un

sistema para desecharlo4 por"ue incluso la mejor planificaci)n no puede asegurar "ue vaya a salir bien la primera vez2 !or tanto4 la cuesti)n no es si hay "ue construir un sistema piloto y

desecharlo2 Se desechar$2 6a 7nica cuesti)n es si planificar de antemano la construcci)n de

algo "ue se va a desechar4 o prometer la entrega del desecho a los clientes2221 38he .ythical

.an-.onth, ='l m0tico )ombre!mes=, +D, uno de los libros de gestión de proyectos dedesarrollo de soft1are más populares que (amás se )an escrito4.

# veces, los prototipos desec)ables no se llegan a desec)ar. "ero los prototipos no siempreson desec)ables. 'n tal caso, estaremos utilizando un modelo iterativo de refinamiento de

prototipos en el que, tras varias iteraciones, seremos capaces de construir un sistema que seadapte me(or a las necesidades de nuestro cliente.

Modelos iterativos'n +-, el $epartamento de $efensa de 'stados Unidos 3el mayor contratista mundial de proyectos de desarrollo de soft1are4 cambió oficialmente sus estándares de desarrollo desoft1are y descartó el modelo en cascada para introducir el estándar -, que utiliza unmodelo iterativo de desarrollo de soft1are.

6os modelos iterativos consisten en descomponer un proyecto de desarrollo de soft1are en

una serie de subproyectos de menor envergadura. 'stos subproyectos deben dise%arse 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.'l cliente y los usuario finales abogarán por darle prioridad a las funciones más 7tiles delsistema 3o las más =vendibles=4. "or otro lado, los dise%adores del sistema deberán determinar las dependencias eistentes entre sus distintos componentes y priorizar aquéllos que suponganun riesgo mayor para la viabilidad final del proyecto. 6as prioridades de unos y otros )abránde consensuarse razonablemente y servirán para determinar el ámbito de los subproyectos en

que se descompondrá el proyecto inicial.6os modelos iterativos de desarrollo de soft1are permiten adelantar el momento en el que sedetermina si un proyecto es técnicamente viable o no 3con lo que se eliminan costesinnecesarios si, finalmente, el proyecto )ubiese de cancelarse4. :ambién promueven uname(or comunicación con el usuario/cliente, ya que se dispondrá antes de una versión operativadel sistema, aunque sea de funcionalidad reducida. 'stas versiones intermedias del productoayudan a la eliminación de malentendidos que pueden surgir en la etapa de elicitación derequerimientos. #demás, ayudan a que el usuario se forme una idea más clara de lo querealmente necesita.



18


,'ecuencial o iterativo-

'l modelo de desarrollo más adecuado para un proyectodependerá del tipo de sistema que se )a de construir

! 'n general, se elegirá un modelo secuencial cuando losrequerimientos se conocen bastante bien y son estables,cuando el dise%o será similar al de otros sistemas con losque tenemos eperiencia, cuando los integrantes delequipo de desarrollo ya se conocen y están familiarizadocon el entorno de desarrollo, o cuando el coste de tener que cambiar algo en las etapas finales del proyectoresultar0a pro)ibitivo.

! 'n la práctica, no obstante, los modelos iterativos seadaptan me(or a la realidad del desarrollo de soft1are3especialmente en sistemas medianos y grandes4. Iosdecantaremos por un modelo iterativo cuando losrequerimientos no se conocen con eactitud o se prevéque puedan cambiar en el futuro, cuando el dise%o delsistema es comple(o o no tiene precedentes para nosotros,cuando el proyecto en s0 es arriesgado económicamente ycuando podamos controlar el coste de futuros cambios enel sistema 3algo que siempre tendremos que )acer sitenemos en cuenta lo que aprendimos al estudiar la etapa

de mantenimiento4.

#l seguir un modelo iterativo, puede que le dediquemos muy poco tiempo a las etapas iniciales del ciclo de vida de unsistema, lo que puede causar una tasa de cambios tan alta queimpida que el proyecto progrese. $el mismo modo, si lesdedicamos demasiado tiempo, )asta el punto de seguir a pies

(untillas los requerimientos iniciales del sistema, puede queestemos negando la realidad con la que nos encontramos y, denuevo, impidamos que el proyecto progrese adecuadamente.

"ara planificar un proyecto que siga un modelo iterativo, primero se prepara unadescomposición a grandes rasgos del proyecto en una serie de iteraciones, cada una de lascuales se considerará como un proyecto independiente. 'n vez de realizar una planificacióndetallada de todo el proyecto, sólo se detallará el plan correspondiente a la primera iteración.S0 se establecerán las fec)as de inicio y finalización de las distintas iteraciones y se definiránlos ob(etivos principales de cada una de ellas. 6legado el caso, estos ob(etivos se puedenredefinir conforme avance el proyecto.



19


El modelo en espiral de /oehm

# lo largo de los a%os se )an propuesto multitud de modelos iterativos de desarrollo desoft1are. # continuación se describen algunos de los más conocidos

! 'l modelo en espiral de 5arry 5oe)m )ace especial )incapié en la prevención deriesgos. 'ste modelo define cuatro actividades principales planificación

3determinar los ob(etivos, alternativas y restricciones del proyecto4, análisis deriesgos 3análisis de alternativas e identificación/resolución de riesgos4, ingenier0a3desarrollo del producto4 y evaluación 3revisión por parte del cliente y valoraciónde los resultados obtenidos de cara a la siguiente iteración4. 'n cada iteraciónalrededor de la espiral se construyen versiones cada vez más completas delsoft1are.

! 6os modelos evolutivos 3como el modelo Evo de :om 2ilb o los modelos ágiles populares )oy en d0a, entre los que se encuentra la auto!denominadaprogramación extrema4 se caracterizan por realizar entregas por etapas delsistema. Usualmente, el proyecto se descompone en iteraciones de longitud fi(a3de + a semanas4 y cada iteración )a de proporcionar alg7n aspecto completo dela funcionalidad del sistema. Cada ciclo se concentra en las funciones de mayor valor a%adido. $e esta forma, si se cancelase el proyecto en cualquier momento, elusuario siempre tendrá lo máimo que se puede conseguir con los recursosinvertidos )asta el momento. &gualmente, se puede prorrogar el proyecto si seconsidera interesante seguir a%adiéndole funcionalidad al proyecto.

! :ambién eisten otros modelos, conocidos por el nombre de modelos deestabiliación y sincroniación, en los que se sigue la misma estrategia que enlos modelos iterativos pero sin llegar a realiza una entrega por etapas del sistema.



18


Tste es el caso, por e(emplo, del modelo de desarrollo de soft1are utilizadointernamente en empresas como Jicrosoft.

Marcos para el proceso de desarrollo de software

Como )emos visto, eiste una amplia variedad de propuestas en lo que respecta acómo organizar el proceso de desarrollo de soft1are. 6a mayor0a de las propuestas son

prescriptivas 3definen qué actividades )ay que realizar y en qué orden4, si bien algunas propuestas van más allá y definen marcos para organizar el con(unto de actividades ytareas involucradas en un proyecto de desarrollo de soft1are. 'stos marcos sugierenqué combinaciones de actividades son las más indicadas en cada etapa del proceso dedesarrollo de soft1are y cuáles deber0an ser los resultados que se obtengan de cada unade ellas. 6os siguientes son algunos de los más populares )oy en d0a

! 'l modelo !MM" 3Capability .aturity .odel - 9ntegrated , propuesto por el&nstituto de &ngenier0a del Soft1are de la Universidad de Carnegie!Jellon4identifica una serie de áreas clave en términos de ob(etivos espec0ficos y

prácticas necesarias para lograr esos ob(etivos. 6os ob(etivos establecen lascaracter0sticas que el proceso de desarrollo de soft1are debe tener para que lasactividades de cada área puedan ser efectivas. 'n cierto sentido, CJJ& viene aser como una certificación de calidad &S< ??? adaptada a proyectos dedesarrollo de soft1are. Una certificación de este tipo puede ayudar a conseguir determinados tipos de proyectos 3gubernamentales, principalmente4, si bien sólogarantiza que el proyecto se realiza siguiendo un proceso definido, no que lasdistintas tareas se realicen correctamente. $e )ec)o, el proceso puede estar

perfectamente definido y =certificado= sin ser el proceso adecuado para el proyecto que tengamos entre manos.

! 'l "roceso Unificado de 8ational 3R#$, ational :nified !rocess, propuestooriginalmente por una empresa llamada 8ational Soft1are Corporation que )oyes una división de &5J4 describe un marco adaptable para procesos iterativos dedesarrollo de soft1are. 'l ciclo de vida de un proyecto 8U" se divide en ciclosde desarrollo individuales que, a su vez, se descomponen en cuatro fases

principales 3incepción, elaboración, construcción y transición4. "ara cada una deestas fases, 8U" identifica qué disciplinas 3actividades4 son las más relevantes.Minalmente, en un proyecto concreto cada fase viene definida por una serie deob(etivos y se descompone en iteraciones de duración fi(a 3de, por e(emplo, >semanas4.

El ciclo de vida de una base de datos

Una base de datos no es más que un componente de un sistema de información. "or tanto, elciclo de vida del sistema de información incluye el ciclo de vida de la base de datos que forma

parte de él. 'n particular, desde el punto de vista de la base de datos, centraremos principalmente nuestra atención en las siguientes actividades



19


! %efinición del sistema $urante la etapa de análisis de requerimientos delsistema, nos fi(aremos especialmente en todos los requerimientos asociados a los

datos con los que )a de traba(ar nuestro sistema.

! %iseño de la base de datos 'l análisis de los requerimientos del sistema nos permitirá organizar los datos con los que nuestro sistema )abrá de traba(ar. 'ste proceso de dise%o, que está 0ntimamente ligado a la futura base de datos denuestro sistema, lo descompondremos en tres fases

%iseño conceptual 3descripción del esquema de la base de datos utilizando unmodelo de datos conceptual4.

%iseño lógico 3descripción de la base de datos con un modelo de datosimplementable, como puede ser el caso del modelo relacional4.

%iseño f&sico 3descripción de la base de datos a nivel interno, de acuerdo conlas caracter0sticas del sistema gestor de bases de datos que decidamosutilizar4.

! "mplementación de la base de datos 3la parte de la implementación del sistemacorrespondiente a la creación de la base de datos4.

! !arga o conversión de los datos Como parte de la instalación o despliegue delsistema, tendremos que introducir en la base de datos todos aquellos datos queresulten necesarios para que las aplicaciones de nuestro sistema de información

puedan funcionar. Como parte de esta inicializaci)n de la base de datos, puedeque resulte necesario etraer datos de otro sistema y convertirlos a un formatoadecuado para nuestro sistema 3entre otras cosas, porque el esquema de nuestra

base de datos probablemente diferirá del esquema de las bases de datos de las quese etraigan los datos necesarios para arrancar nuestro sistema4.

! !onversión de aplicaciones Si determinadas aplicaciones 3que ya eistiesenanteriormente al dise%o de nuestro sistema4 )an de seguir funcionando, dic)asaplicaciones deberán adaptarse al esquema de nuestra base de datos. "or tanto,como parte del mantenimiento de dic)as aplicaciones, tendremos que dise%ar losmecanismos adecuados para que estas aplicaciones puedan seguir funcionandocorrectamente sobre una base de datos diferente a la base de datos sobre la quefueron dise%adas inicialmente. # veces, podremos solucionar este problemacreando vistas adecuadas de nuestra base de datos para tales aplicaciones. <trasveces, tendremos que modificar la implementación de las aplicaciones antiguas e,incluso, re)acerlas casi por completo.

! 'erificación y validación Como en todo sistema de información, deberemosverificar que la base de datos y las aplicaciones funcionan correctamente. #demás,deberemos comprobar que el sistema construido se a(usta a las necesidades realesque promovieron su proyecto de desarrollo 3esto es, validar el sistema y susrequerimientos4.



18


! Operación( supervisión y mantenimiento Minalmente, una vez puesto enmarc)a el sistema, se llega a la etapa =final= del ciclo de vida de todo sistema de

información 3en la que, como ya vimos, se repetirá todo el ciclo cada vez quetengamos que realizar modificaciones sobre el sistema ya eistente4.

$e las actividades descritas en los párrafos anteriores, todas ellas relacionadas directamentecon la base o bases de datos utilizadas en un sistema de información, estudiaremos a fondo lascorrespondientes a las etapas iniciales del ciclo de vida de la base de datos. #ntes de estudiar técnicas concretas, no obstante, detallares algo más el proceso de dise%o que utilizaremos paraconstruir correctamente una base de datos.



19


El proceso de diseño de una base de datos

'l problema de dise%ar bases de datos consiste en dise%ar la estructura lógica y f0sica de una omás bases de datos para atender las necesidades de información de los usuarios de uncon(unto definido de aplicaciones. 'stos usuarios pueden pertenecer todos a una organizaciónconcreta 3como sucede con los traba(adores de una empresa o los funcionarios de unorganismo p7blico4, o bien formar parte de un colectivo con intereses comunes 3tal es el casode los usuarios de multitud de aplicaciones 1eb, desde un buscador como 2oogle )asta unservicio de información geográfica tipo "áginas #marillas4.

#ntes de pasar a ver la metodolog0a que utilizaremos para dise%ar bases de datos, )ay querecordar que el dise%o de bases de datos es sólo una de los procesos involucrados en la

construcción de un sistema de información. 2eneralmente, para construir un sistema deinformación se llevarán a cabo distintas actividades paralelas

! "or un lado, será necesario dise%ar el contenido y la estructura de la base de datos quedará soporte al sistema de información.

! "or otro, también será imprescindible dise%ar el con(unto de aplicaciones que le permitirán al usuario sacar partido del sistema de información.

:anto en las actividades relacionadas con los datos del sistema 3todo lo relativo a la base de

datos4 como en aquéllas relacionadas con los procesos del mundo real que el sistema trata deme(orar 3mediante un con(unto de aplicaciones4, resulta recomendable el uso de unametodolog0a apropiada.

'n esencia, la metodolog0a utilizada en un proyecto no es más que el con(unto deconvenciones que los integrantes de un equipo de traba(o acuerden emplear. 'sta definiciónincluir0a, por e(emplo, a la metodolog0a aSdJ utilizada por algunas empresas de desarrollo desoft1are 3una referencia irónica al )ec)o de ir )aciendo las cosas =a salto de mata=4. Sinembargo, por metodolog0a usualmente se entiende algo más. Si acudimos a un diccionario,encontraremos que una metodolog0a es un con(unto de métodos 3sic4, aplicados de formasistemática.

Una buena metodolog0a de dise%o )a de incluir todo lo que normalmente resulte necesario para obtener un buen dise%o. 2eneralmente, una metodolog0a, que implicará el uso demétodos y técnicas adecuadas a nuestro problema, se centrará en la coordinación de lasactividades que )an de realizarse. $e acuerdo con las etapas del ciclo de vida de un sistema deinformación, una metodolog0a de dise%o descompone el proceso de dise%o en una serie deetapas. "ara cada una de las etapas, propondrá el uso de determinadas técnicas y )erramientasde dise%o, as0 como la generación de una serie de documentos que facilitarán la transición deuna etapa a la siguiente.



18


# continuación, presentaremos las distintas fases en las que descompondremos el proceso dedise%o de bases de datos. "ara cada una de las fases, mencionaremos sus ob(etivos concretos,

las técnicas particulares que recomendamos utilizar en cada etapa y los documentos que sedeber0an obtener como resultado de cada una de ellas.

!'E' DEL D('E/0 DE B!'E' DE D!"0'

! #nálisis de requisitos

! $ise%o conceptual

! 'lección del sistema gestor de bases de datos

! $ise%o lógico

! $ise%o f0sico

! &nstalación y mantenimiento

ase 12 !nálisis de re$uerimientos

0b3etivo

8ecabar información sobre el uso que se le piensa dar a la base de datos.

"areas

'licitación de los requisitos del sistema

! &dentificación de las principales áreas de la aplicación y grupos de usuarios.

! 'studio y análisis de la documentación eistente relativa a las aplicaciones.

! 'studio del entorno de operación actual.

! 'studio del uso de la información 3transacciones, frecuencias y flu(os de datos4.

4esultados

$ocumento de especificación de requerimientos

! $escripción del sistema en lengua(e natural.



19


! 6ista de requerimientos 3organizados de forma (erárquica4.

! $iagramas de flu(o de datos 3$M$4.

! Casos de uso.

ase 52 Diseño conceptual

0b3etivo

"roducir un esquema conceptual de la base de datos 3independiente del sistema gestor de bases de datos que luego vayamos a utilizar4.

"areas

! Comprensión de la estructura, semántica, relaciones y restricciones asociados a losdatos que deben almacenarse en la base de datos.

! Jodelado de los datos del sistema 3obtención de una descripción estable de lo que

será el contenido de la base de datos4.! Comunicación entre usuarios finales, analistas y dise%adores para comprobar la

validez del modelo obtenido.

4esultados

! $iagrama '/8, diagrama C#S'VJet)od o diagrama de clases UJ6.

! $iccionario de metadatos.

ase 62 Elección del '7BD6a elección del sistema gestor de bases de datos que vayamos a utilizar se realiza en dosetapas

! "rimero se realiza la elección del modelo de datos, el tipo de sistema gestor de bases de datos que vamos a usar relacional, ob(eto!relacional, orientado a ob(etos,multidimensional...



18


! # continuación se elige el sistema gestor de bases de datos concreto 3y suversión4. "or e(emplo, si decidimos utilizar un sistema gestor de bases de datos

relacionales, podemos recurrir al gestor de bases de datos de <racle, al $5; de&5J, al SF6 Server de Jicrosoft, al &nterbase de 5orland o a cualquier otro delos muc)os sistemas gestores de bases de datos relacionales que eisten en elmercado.

'elección de un sistema gestor de bases de datos

Un sistema gestor de bases de datos 3S25$ o $5JS si nos atenemos a sus siglas eninglés4 es un producto soft1are con capacidad para definir, mantener y utilizar bases dedatos. 'l sistema de gestión de bases de datos que decidamos utilizar debe permitirnos,entre otras cosas, definir estructuras de almacenamiento adecuadas y acceder a los datosde forma eficiente y segura. # continuación se enumeran algunos de los aspectos en que

deber0amos fi(arnos para elegir un S25$ concreto

)actores t*cnicos

! <rganización de los datos independientemente de las aplicaciones que los vayan a usar3independencia lógica4 y de los fic)eros en los que vayan a almacenarse 3independenciaf0sica4.

! $atos y aplicaciones accesibles a los usuarios y a otras aplicaciones de la manera másamigable posible 3mediante lengua(es de consulta como SF6 o

Fuery!by!eample4.

! $atos gestionados de forma centralizada e independiente de las aplicaciones.

! Io redundancia 3los datos no deben estar duplicados4, consistencia e integridad.

! Miabilidad 3protección frente a fallos en el )ard1are4.

! Seguridad 3no todos los datos deben ser accesibles a todos los usuarios y el S25$ debeayudarnos a controlar esto4.

'elección de un sistema gestor de bases de datos



19


! Capacidad de replicación y distribución.

! $isponibilidad de )erramientas adecuadas de desarrollo de soft1are.

! "ortabilidad.

)actores no t*cnicos

! Coste de la adquisición del soft1are 3licencias de uso del S25$4.

! Coste del )ard1are necesario para el uso del S25$.

! Costes asociados al mantenimiento de la base de datos.

! Coste de creación y conversión de la base de datos.

! Coste de personal 3tanto de formación como de operación de la base de datos4.

! $isponibilidad de servicios por parte del proveedor del S25$.

ase 82 Diseño lógico

0b3etivoCrear el esquema conceptual de la base de datos 3y todos los esquemas eternos asociados alas distintas aplicaciones del sistema4 de acuerdo con el modelo de datos del sistema gestor de

base de datos elegido.

"areas

"ara realizar el dise%o lógico de la base de datos, )ay que transformar los esquemas obtenidosen el dise%o conceptual en un con(unto de estructuras propias del modelo abstracto de datos

elegido. 'n el caso de las bases de datos relacionales tendremos que realizar las siguientestareas

! "aso del diagrama '/8 3o equivalente4 a un con(unto de tablas.

! Iormalización de las tablas



18


4esultado

Un con(unto de estructuras propias del modelo abstracto de datos del S25$ elegido 3esto es,un con(unto de tablas si traba(amos con bases de datos relacionales4.

ase 92 Diseño físico

0b3etivo

'l dise%o f0sico de la base de datos consiste en elegir las estructuras de almacenamiento

apropiadas 3tablas, particiones de tablas, 0ndices...4 para que el rendimiento de la base dedatos sea el adecuado para las distintas aplicaciones a las que )a de dar servicio.

'obre el rendimiento de la base de datos

"or rendimiento de las aplicaciones se entiende el tiempo derespuesta del sistema a las peticiones del usuario, elaprovec)amiento del espacio de almacenamiento en discoutilizado por la base de datos, la productividad de lastransacciones de la base de datos y cualquier otro aspecto que

pueda afectar a la percepción del sistema por parte delusuario.

Usualmente, el rendimiento del sistema dependerá del tama%ode la base de datos, del n7mero de registros de cada tipo que)a de almacenar y del n7mero de usuarios que accederánconcurrentemente a la base de datos, as0 como de los patronesconcretos de inserción, actualización y obtención de datos.

"areas

! 'stimar adecuadamente los diferentes parámetros f0sicos de nuestra base de datos, para lo cual podemos recurrir a técnicas anal0ticas 3modelos matemáticos delrendimiento de un sistema4 y a técnicas eperimentales 3como la construcción de

prototipos, el uso de técnicas de simulación o la realización de pruebas de carga4.

! "reparar las sentencias $$6 correspondientes a las estructuras identificadasdurante la etapa de dise%o lógico de la base de datos.

4esultado

Un con(unto de sentencias $$6 escritas en el lengua(e del S25$ elegido 3incluyendo lacreación de 0ndices, la selección de parámetros f0sicos de la base de datos, etcétera4.



19


ase :2 (nstalación mantenimiento

Como en cualquier sistema de información, casi siempre resulta necesario modificar el dise%ode la base de datos, ya sea porque el rendimiento observado después de la implementación delsistema de bases de datos no sea el adecuado o porque )aya que introducir cambios en elesquema de la base de datos como consecuencia del mantenimiento del sistema deinformación. "or ambos motivos se incluye epl0citamente esta fase en el proceso de dise%ode bases de datos.

(nstalación puesta en marc;a

! 6a instalación de la base de datos suele ser responsabilidad del administrador de la base de datos 3$5# ;atabase <dministrator 4, que se encarga de recopilar todaslas sentencias $$6 necesarias para crear los distintos esquemas de la base dedatos.

! 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 implementación de rutinas deconversión, 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. $ic)as utilidades demonitorización recopilan información estad0stica del uso del sistema para suanálisis posterior, lo que nos facilitará todas las tareas relacionadas con laoptimización del rendimiento del sistema.

! Cuando los requisitos del sistema cambien y )aya que actualizar las aplicacionesde nuestro sistema de información, el esquema de la base de datos también se verásometido a algunas modificaciones.



18


Cuando se detecta un rendimiento deficiente del sistema, nosiempre es suficiente con a(ustar los parámetros de

configuración del sistema gestor de bases de datos.

'n ocasiones, basta con la reorganización de las estructurasinternas de la base de datos 3por e(emplo, mediante lacreación de los 0ndices adecuados4 pero también )ay veces enque resulta necesaria la creación de tablas redundantes 3vistasmaterializadas4. 'n estos casos, debemos ser especialmentecuidadosos para asegurar la consistencia de los datosalmacenados en la base de datos 3algo que, generalmente, se

puede conseguir mediante la implementación de disparadores

o triggers en el propio gestor de bases de datos4.



19


(ibliograf+a

8amez #. 'lmasri R S)amLant 5. Iavat)e 1=undamentos de Sistemas de /asesde ;atos1 , #ddison!Besley, ;??; O>W ediciónP. &S5I -D;?+

'n este libro se puede encontrar una buena descripción del proceso de dise%ode bases de datos, tal como lo acabamos de contar en la sección anterior.

8obert 6. 2lass 1=acts and =allacies of Software Engineering1 ,#ddison!Besley, ;??>. &S5I ?>;+++D-;

'l t0tulo original de este ecelente libro da una buena pista sobre lo que nos podemos encontrar al abrirlo =ifty-=ive =re"uently =orgotten =acts 'and a =ew =allacies( about Software Engineering O )ec)os com7nmente olvidados 3y unas cuantasfalacias4 sobre &ngenier0a del Soft1areP. #l editor pareció no gustarle el t0tulo original

para el libro =M= y éste fue modificado. 'speremos que no fuese porque su base de datosno admit0a un t0tulo tan largo...

Steve JcConnell 1apid ;evelopment0 8aming wild software schedules1 ,Jicrosoft "ress, +. &S5I ++??

'ste libro, bastante más ameno e informativo que la mayor parte de libros deteto de &ngenier0a del Soft1are 3aunque también algo más sesgado que ellos, a decir verdad4, incluye información relativa a una amplia variedad de técnicas 7tiles en lasdistintas etapas de un proyecto de desarrollo de soft1are. 'n particular, se puedeencontrar en él gran cantidad de información relativa a la fase de la planificación de un

proyecto y, también, a la gestión de un proyecto a lo largo de todo su ciclo de vida.

Bibliografía complementaria6os siguientes libros resultan altamente recomendables para aprender más acerca de las fasesdel ciclo de vida de un sistema de información que aqu0 apenas se )an mencionado

Jartin Mo1ler 1!atterns of Enterprise <pplication <rchitecture1 ,#ddison!Besley, ;??>. &S5I ?>;++;D-;?



18


'ste libro está dedicado 0ntegramente al dise%o de las aplicaciones que seutilizan en la gran mayor0a de los sistemas de información de cualquier

empresa. 'n particular, describe cómo crear arquitecturas multicapa utilizandotécnicas de dise%o orientado a ob(etos e incluye un catálogo de patrones dedise%o etremadamente 7til para cualquier dise%ador de aplicaciones de

gestión.

Steve JcConnell 1Code Complete0 < practical handboo* of softwareconstruction1 , Jicrosoft "ress, ;W edición, ;??-. &S5I ?D>+D?

Si el libro de Mo1ler cubre aspectos de dise%o de aplicaciones, el deJcConnell no se queda corto a la )ora de analizar todo lo relacionado con la construcciónde soft1are, desde el dise%o detallado de módulos de un programa )asta el uso de técnicasde optimización de código, sin olvidar 3casi4 ning7n detalle relativo al uso de variables oestructuras de control en un programa.

Cem Xaner, Aames 5ac) R 5ret "ettic)ord 16essons learned in software testing1 ,Biley Computer "ublis)ing, ;??;. &S5I ?-D+?++;-

6a etapa de pruebas suele estar peor vista que las de análisis, dise%o eimplementación, por lo que resulta algo más dif0cil encontrar buenos libros sobre el tema3entre otras cosas, por ser el destino inicial de muc)os al ser contratados por una empresa,tras lo cual suelen ascienden a programadores, de programadores a analistas, y deanalistas a (efes de proyecto4. 'ste libro, no obstante, es bastante bueno y tiene un estilosimilar al libro =M= de 8obert 2lass. #demás, incluye todas las referencias necesarias parael que desee profundizar más en el tema.

PD

6a etapa de mantenimiento esta a7n peor vista que la de pruebas y, acerca de ella, es prácticamente imposible encontrar una referencia en condiciones que cubra el temacon e)austividad. S0 eisten, no obstante, buenas monograf0as dedicadas a temasespec0ficos relacionados con el mantenimiento. Tste es el caso de >or*ing Effectively

with 6egacy Code de Jic)ael Meat)ers 3"rentice 9all ":8, ;??-, &S5I ?+>++DD?;4.

etapas_explicadas

Documents

Transcript of etapas_explicadas