1.3. 1.3.
ETAP ETAPAS AS DEL DEL PROC PROCESO ESO DE DESA DESARROL RROLLO LO DEL SOFTW SOFTWARE ARE
Cualquier sistema de informacin !a "asando "or una serie de fases a lo lar#o de su !ida. Su ciclo de !ida com"rende una serie de eta"as entre las que se encuentran las si#uientes$ % Plani&cacin % An'lisis % Dise(o % )m"lementacin % Prue*as % )nstalacin o des"lie#ue % +so , mantenimiento. Esta Estas s eta" eta"a as son son un ree-e eo del "roceso que se si#ue a la /ora de resol!er cualquier ti"o de "ro*lema. 0a en 124 muc/o antes de que e5istiese la )n#enier6a del Soft7are4 Soft7are4 el matem'tico 8eor#e 8eor#e Pol,a descri*i descri*i este "roceso en su li*ro 9o7 to sol!e it :el "rimero que descri*e la utili;acin de t'sicamente4 resol!er un "ro*lema requiere$ % Com"render el "ro*lema :an'lisis= % Plantear una "osi*le solucin4 considerando soluciones alternati!as :dise(o= % Lle!ar a ca*o la solucin "lanteada :im"lementacin= % Com"ro*ar que el resultado o*tenido es correcto :"rue*as= Las eta"as eta"as adici adiciona onales les de "lani& "lani&cac cacin in44 instal instalaci acin n , manten mantenimi imient ento o que a"arecen en el ciclo de !ida de un sistema de informacin son necesarias en el mundo real "orque el desarrollo de un sistema de informacin conlle!a unos costes asociados :lo que se /ace necesaria la "lani&cacin= , se su"one que4 una !e; construido el sistema de informacin4
'm*ito del "ro,ecto4 la reali;acin de un estudio de !ia*ilidad4 el an'lisis de los ries#os asociados al "ro,ecto4 una estimacin del coste del "ro,ecto4 su "lani&cacin tem"oral , la asi#nacin de recursos a las distintas eta"as del "ro,ecto. Delimitacin del 'm*ito del "ro,ecto Resulta esencial determinar el 'm*ito del "ro,ecto al comien;o del mismo. 9an de esta*lecerse de antemano qu< cuestiones /an de resol!erse durante la reali;acin del "ro,ecto , cu'les se dear'n fuera. Tan im"ortante es determinar los as"ectos a*arcados "or el "ro,ecto como &ar aqu
% La mitad de los "ro,ectos lle# a com"letarse e!entualmente4 costando m's de lo "re!isto4 tardando m's tiem"o del estimado inicialmente , con menos caracter6sticas de las es"eci&cadas al comien;o del "ro,ecto. % Por ?ltimo4 m's de un 3B de los "ro,ectos se cancel antes de com"letarse. Dado que cinco de cada seis "ro,ectos anali;ados no se austaron al "lan "re!isto4 no es de e5tra(ar que resulte aconsea*le reali;ar un estudio de !ia*ilidad antes de comen;ar el desarrollo de un sistema de informacin "ara determinar si el "ro,ecto es econmica4 t
de ries#os nos ense(a que /emos de dear un mar#en "ara im"re!istos "re!isi*les , a(adir cierta /ol#ura a la "lani&cacin de nuestro "ro,ecto. Las /i"tesis *araadas al anali;ar ries#os "otenciales "ueden con!ertirse en realidad , nunca est' de m's dear al#o de mar#en de manio*ra. Estimacin Sin duda4 una de las tareas m's "elia#udas de cualquier "ro,ecto de desarrollo de soft7are es la estimacin inicial del coste de al#o que a?n no conocemos. De /ec/o4 la reali;acin de malas estimaciones /a sido identi&cada como una de las dos causas m's comunes del fracaso de un "ro,ecto de desarrollo de soft7are :8lass4 @BB3=. La otra es la e5istencia de requerimientos inesta*les suetos a continuos cam*ios. Como dio >J/r4 la "rediccin es dif6cil4 es"ecialmente si se trata del futuro. Adem's4 la estimacin del coste asociado se suele reali;ar en el "eor momento "osi*le$ al comien;o4 cuando menos conocemos del "ro,ecto , ma,or es el mar#en del error de la estimacin. Afortunadamente4 e5isten al#unas re#las /eur6sticas que nos "ueden a,udar a estimar con una "recisin ra;ona*le el coste , duracin de un "ro,ecto. El arte de una *uena estimacin est' *asado4 fundamentalmente4 en la e5"eriencia del estimador. 9a*er "artici"ado en "ro,ectos de similares caracter6sticas "uede ser esencial "ara que seamos ca"aces de reali;ar una *uena estimacin. Tam*i
% Resulta aconsea*le utili;ar !arias t
cual se intenta descu*rir qu< es lo que realmente se necesita , se lle#a a una com"rensin adecuada de los requerimientos del sistema :las caracter6sticas que el sistema de*e "oseer=. GPor qu< resulta esencial la eta"a de an'lisisI Sim"lemente4 "orque si no sa*emos con "recisin qu< es lo que se necesita4 nin#?n "roceso de desarrollo nos "ermitir' o*tenerlo. El "ro*lema es que4 de "rimeras4 "uede que ni nuestro cliente se"a de "rimeras qu< es e5actamente lo que necesita. Por tanto4 de*eremos a,udarle a a!eri#uarlo con a,uda de distintas t
En la fase de an'lisis4 los errores m's dif6ciles de corre#ir son los causados "or requerimientos ausentes4 #eneralmente en la forma de su"osiciones que se dan "or sa*idas "ero nunca se lle#an a "lasmar e5"l6citamente. Por este moti!o4 elicitar los requerimientos de un sistema de informacin :esto es4 o*tener de al#?n modo cu'les son realmente esos requerimientos= resulta una acti!idad esencial en cualquier "roceso de desarrollo de soft7are. La elicitacin de requerimientos requiere "re!iamente la identi&cacin de las "ersonas afectadas "or el "ro,ecto4 sus staNe/olders :literalmente4 los que a"uestan al#o=4 lo que inclu,e desde el cliente que "a#a el "ro,ecto /asta los usuarios &nales de la a"licacin4 sin ol!idarse de terceras "ersonas , or#ani;aciones relacionadas indirectamente con el sistema que se !a a desarrollar :"or eem"lo4 em"resas com"etidoras , or#anismos re#uladores=. En la elicitacin de requerimientos se recurre a distintas t
qu< queramos el modelo4 lo /aremos m's o menos detallado4 siem"re de acuerdo a su rele!ancia , utilidad. +n sistema de informacin es un sistema com"leo4 "or lo que a :casi= nadie se le ocurrir6a intentar descri*irlo utili;ando un ?nico modelo. De /ec/o4 todo sistema "uede descri*irse desde distintos "untos de !ista , nosotros utili;aremos distintos ti"os de modelos de"endiendo del as"ecto del sistema en que deseemos centrar nuestra atencin$ % E5isten modelos estructurales que nos a,udan a la /ora de or#ani;ar un sistema com"leo. Por eem"lo4 un dia#rama entidadrelacin nos indica cmo se estructuran los datos de un sistema de informacin4 mientras que un dia#rama de -uo de datos nos da informacin acerca de cmo se descom"one un sistema en su*sistemas , del -uo de datos que e5iste entre los distintos su*sistemas. % Tam*i
modular en !e; de monol6tico. Sus mdulos de*er6an ser co/esi!os :encar#arse de una tarea concreta , slo de una= , estar d<*ilmente aco"lados entre s6 :"ara facilitar el mantenimiento del sistema=. Cada mdulo de*er6a ofrecer a los dem's unos interfaces *ien de&nidos :al estilo del dise(o "or contrato "ro"uesto "or >ertrand e,er= , ocultar sus detalles de im"lementacin :si#uiendo el "rinci"io de ocultacin de informacin de Parnas=. Por ?ltimo4 de*e ser "osi*le relacionar las decisiones de dise(o tomadas con los requerimientos del sistema que las ocasionaron :al#o que se suele denominar tra;a*ilidad de los requerimientos=. En la fase de dise(o se /an de estudiar "osi*les alternati!as de im"lementacin "ara el sistema de informacin que /emos de construir , se /a de decidir la estructura #eneral que tendr' el sistema :su dise(o arquitectnico=. El dise(o de un sistema es com"leo , el "roceso de dise(o /a de reali;arse de forma iterati!a. La solucin inicial que "ro"on#amos "ro*a*lemente no resulte la m's adecuada "ara nuestro sistema de informacin4 "or lo que de*eremos re&narla. Afortunadamente4 tam"oco es necesario que em"ecemos desde cero. E5isten aut
soluciones a los "ro*lemas m's sencillos. Al di!idir un sistema en ca"as4 cada ca"a "uede tratarse de forma inde"endiente :sin tener que conocer los detalles de las dem's=. Desde el "unto de !ista de la )n#enier6a del Soft7are4 la di!isin de un sistema en ca"as facilita el dise(o modular :cada ca"a enca"sula un as"ecto concreto del sistema= , "ermite la construccin de sistemas d<*ilmente aco"lados :si minimi;amos las de"endencias entre ca"as4 resultar' m's f'cil sustituir la im"lementacin de una ca"a sin afectar al resto del sistema=. Adem's4 el uso de ca"as tam*i
Cuando el usuario del sistema no es un usuario /umano4 se /ace e!idente la similitud entre las ca"as de "resentacin , de acceso a los datos. Teniendo esto en cuenta4 el sistema "uede !erse como un n?cleo :l#ica de la a"licacin= en torno al cual se crean una serie de interfaces con entidades e5ternas. Esta !ista sim
Si su"onemos que /emos sido ca"aces de se"arar el n?cleo de la a"licacin de sus distintos interfaces4 a?n nos queda "or decidir cmo !amos a or#ani;ar la im"lementacin de la l#ica asociada a la a"licacin. Como en cualquier otra tarea de dise(o4 tenemos que lle#ar a un com"romiso adecuado entre distintos intereses. Por un lado4 nos #ustar6a que el dise(o resultante fuese lo m's sencillo "osi*le. Por otro lado4 ser6a desea*le que nuestro dise(o estu!iese *ien "re"arado "ara so"ortar las modi&caciones que /a,an de reali;arse en el futuro. Por lo #eneral4 el dise(o de la l#ica una a"licacin se suele austar a uno de los tres si#uientes "atrones de dise(o$ % Rutinas$ La forma m's sim"le de im"lementar cualquier sistema se *asa en im"lementar "rocedimientos , funciones que ace"ten , !aliden las entradas reci*idas de la ca"a de "resentacin4 realicen los c'lculos necesarios4 utilicen los ser!icios de aquellos sistemas que /a#an falta "ara com"letar la o"eracin4 almacenen los datos en las *ases de datos , e n!6en una res"uesta adecuada al usuario. >'sicamente4 cada accin que el usuario "ueda reali;ar se traducir' en un "rocedimiento que reali;ar' todo lo que sea necesario al m's "uro estilo del dise(o estructurado tradicional. Aunque este modelo sea sim"le , "ueda resultar adecuado a "eque(a escala4 la e!olucin de las a"licaciones dise(adas de esta forma suele aca*ar siendo una "esadilla "ara las "ersonas encar#adas de su mantenimiento.
% dulos de datos$ Ante la situacin descrita en el "'rrafo anterior4 lo usual es di!idir el sistema utili;ando los distintos conuntos de datos con los que tra*aa la a"licacin "ara crear mdulos m's o menos inde"endientes. De esta forma4 se facilita la eliminacin de l#ica du"licada. De /ec/o4 muc/os de los entornos de desarrollo !isual de a"licaciones "ermiten de&nir mdulos de datos que enca"sulen los conuntos de datos con los que se tra*aa , la l#ica asociada a ellos. Las /erramientas de >orland4 Del"/i , C>uilder4 son un claro eem"lo4 i#ual que el De!elo"er de Oracle. icrosoft4 en su arquitectura DKA QDistri*uted interKet A""lication4 fomenta este estilo al em"lear conuntos de datos :resultado de eecutar consultas SHL= so*re los cuales o"eran directamente las distintas ca"as de una a"licacin multica"a. En el caso de la "lataforma .KET4 la clase DataSet "ro"orciona la *ase so*re la que se montar6a todo el dise(o de una a"licacin :al#o que o*!iamente facilita el isual Studio .KET=. % odelo del dominio$ +na tercera o"cin4 la ideal "ara cualquier "urista de la orientacin a o*etos4 es crear un modelo orientado a o*etos del dominio de la a"licacin. En !e; de que una rutina se encar#ue de todo lo que /a,a que /acer "ara com"letar una accin4 cada o*eto es res"onsa*le de reali;ar las tareas que le ata(en directamente. En la "r'ctica4 no todo es *lanco o ne#ro. Aunque em"leemos un modelo orientado a o*etos del dominio de la a"licacin4 es /a*itual crear una ca"a intermedia entre la ca"a de "resentacin , la l#ica de la a"licacin a la que se suele denominar ca"a de ser!icio. La interfa; de la ca"a de ser!icio incluir' m
E5isten distintas formas en las que una a"licacin im"lementada utili;ando un len#uae de "ro#ramacin de "ro"sito #eneral "uede acceder a los datos4 almacenados "or lo #eneral en una *ase de datos relacional$ % La "rimera o"cin que se nos "uede ocurrir cuando dise(amos un sistema orientado a o*etos es utili;ar un re#istros acti!os4 o*etos que enca"sulan directamente las estructuras de datos e5ternas :".e. las tu"las de las ta*las de la *ase de datos= e incor"oran la l#ica del dominio que les corres"onda4 a"arte de las o"eraciones necesarias "ara o*tener , #uardar o*etos en la *ase de datos. % Al#o m's adecuado "uede resultar el em"leo de #ate7a,s4 clases au5iliares que se corres"onden con las ta*las de la *ase de datos e im"lementan las o"eraciones necesarias "ara mani"ular la *ase de datos QCR+D$ Create4 Retrie!e4 +"date Delete. Estas clases au5iliares nos "ermiten no me;clar la l#ica de la a"licacin con el acceso a los datos e5ternos4 tal como sucede si utili;amos re#istros acti!os. % La tercera o"cin :, siem"re /a, una tercera o"cin= es la m's com"lea "ero la m's -e5i*le$ OR a""in#. Se *asa en esta*lecer una corres"ondencia entre el modelo orientado a o*etos del dominio , la re"resentacin de los distintos o*etos en una *ase de datos relacional. En las dos alternati!as anteriores4 los o*etos de la a"licacin /an de ser conscientes de cmo se re"resentan en la *ase de datos. En el caso del OR a""in#4 los o*etos "ueden i#norar la estructura de la *ase de datos , cmo se reali;a la comunicacin con la *ase de datos. La in!ersin de control caracter6stica de esta o"cin inde"endi;a el modelo orientado a o*etos del dominio de la ca"a de acceso a los datos$ se "uede cam*iar la *ase de datos sin tener que tocar el modelo orientado a o*etos del dominio , !ice!ersa. De esta forma4 se facilita el desarrollo4 la de"uracin , la e!olucin de las a"licaciones. Cuando "ara im"lementar la a"licacin se utili;a una /erramienta de "ro#ramacin !isual :ti"o isual Studio .KET4 C>uilder4 Del"/i o De!elo"er=4 #eneralmente no "odemos ele#ir la forma en que nuestra a"licacin acceder' a los datos. Pese a ello4 siem"re e5iste cierto mar#en de manio*ra que "odemos a"ro!ec/ar "ara dise(ar nuestro sistema lo meor "osi*le. )m"lementacin +na !e; que sa*emos qu< funciones de*e desem"e(ar nuestro sistema de informacin :an'lisis= , /emos decidido cmo !amos a or#ani;ar sus distintos com"onentes :dise(o=4 es el momento de "asar a la eta"a de im"lementacin4 "ero nunca antes. Antes de escri*ir una sola l6nea de cdi#o :o de crear una ta*la en nuestra *ase de datos= es fundamental /a*er com"rendido *ien el "ro*lema que se "retende resol!er , /a*er a"licado "rinci"ios *'sicos de dise(o que nos "ermitan construir un sistema de informacin de calidad. Para la fase de im"lementacin /emos de seleccionar las /erramientas adecuadas4 un entorno de desarrollo que facilite nuestro tra*ao , un len#uae
de "ro#ramacin a"ro"iado "ara el ti"o de sistema que !a,amos a construir. La eleccin de estas /erramientas de"ender' en #ran "arte de las decisiones de dise(o que /a,amos tomado /asta el momento , del entorno en el que nuestro sistema de*er' funcionar. A la /ora de "ro#ramar4 de*eremos "rocurar que nuestro cdi#o no resulte indescifra*le. Para que nuestro cdi#o sea le#i*le4 /emos de e!itar estructuras de control no estructuradas4 ele#ir cuidadosamente los identi&cadores de nuestras !aria*les4 seleccionar al#oritmos , estructuras de datos adecuadas "ara nuestro "ro*lema4 mantener la l#ica de nuestra a"licacin lo m's sencilla "osi*le4 comentar adecuadamente el te5to de nuestros "ro#ramas ,4 "or ?ltimo4 facilitar la inter"retacin !isual de nuestro cdi#o mediante el uso de san#r6as , l6neas en *lanco que se"aren distintos *loques de cdi#o. Adem's de las tareas de "ro#ramacin asociadas a los distintos com"onentes de nuestro sistema4 en la fase de im"lementacin tam*i
% Las "rue*as de unidad sir!en "ara com"ro*ar el correcto funcionamiento de un com"onente concreto de nuestro sistema. Es este ti"o de "rue*as4 el "ro*ador de*e *uscar situaciones l6mite que e5"on#an las limitaciones de la im"lementacin del com"onente4 ,a sea tratando uildin# qualit, soft7are4 1@=. Al reali;ar cualquiera de los ti"os de "rue*a descritos4 es im"ortante recordar que el desarrollo de soft7are es una acti!idad que se reali;a en equi"o4 "or lo
que "ueden sur#ir roces "ersonales , dis"utas "ol6ticas entre los miem*ros del equi"o. Las "rue*as resultan "articularmente delicadas en este sentido4 ,a que su o*eti!o es4 al &n , al ca*o4 encontrar defectos. )nstalacin Des"lie#ue +na !e; concluidas las eta"as de desarrollo de un sistema de informacin :an'lisis4 dise(o4 im"lementacin , "rue*as=4 lle#a el instante de que "oner el sistema en funcionamiento4 su instalacin o des"lie#ue. De cara a su instalacin4 /emos de "lani&car el entorno en el que el sistema de*e funcionar4 tanto /ard7are como soft7are$ equi"os necesarios , su con&#uracin f6sica4 redes de intercone5in entre los equi"os , de acceso a sistemas e5ternos4 sistemas o"erati!os :actuali;ados "ara e!itar "ro*lemas de se#uridad=4 *i*liotecas , com"onentes suministrados "or terceras "artes4 etc
% Ada"tarlo a nue!as necesidades :mantenimiento ada"tati!o=4 cuando el sistema /a de funcionar so*re una nue!a !ersin del sistema o"erati!o o en un entorno /ard7are diferente4 "or eem"lo. % A(adirle nue!a funcionalidad :mantenimiento "erfecti!o=4 cuando se "ro"onen caracter6sticas desea*les que su"ondr6an una meora del sistema ,a e5istente. De las distintas facetas del mantenimiento4 la eliminacin de defectos slo su"one el 1 del coste de mantenimiento de un sistema4 mientras que el dise(o e im"lementacin de meoras es res"onsa*le del UB del coste de mantenimiento. Es decir4 m's de un tercio del coste total del soft7are se em"lea en a(adirle caracter6sticas a soft7are ,a e5istente :el UB del UB=. La correccin de errores su"one4 en contraste4 slo en torno al 1B del coste total del soft7are. A?n menos cuanto meores sean las t
1 >er;al4 Fernando. Lifec,cle."df.
