INDICE

INTRODUCCIN...............................................................................................................2 CAPITULO 1. INGENIERA DEL SOFTWARE.......................................................................3 El Software el Pro!e"o..................................................................................................3

1.1 Caractersticas del software...........................................................................................3 1.2 Componentes del software............................................................................................4 1.3 Aplicaciones del software.............................................................................................5 1.4 Ingeniera del Software.................................................................................................6 1.5 Sistemas Basados en Computadora............................................................................... 1.6 Ingeniera de la informaci!n.......................................................................................11 1." Ingeniera de productos...............................................................................................11
2. Ge"t#$% &e 'ro e!to" &e "oftware.............................................................................11

2.1 #lanificaci!n de pro$ectos..........................................................................................13 2.2 Acti%idades asociadas a la planificaci!n de pro$ectos de software............................14 2.3 &stimaci!n del pro$ecto de software..........................................................................15 2.4 'odelos empricos de estimaci!n ..............................................................................16 2.5 (erramientas autom)ticas de estimaci!n....................................................................1"
3. A%(l#"#" &e "#"te)a"..................................................................................................1*

3.1 Identificaci!n de las necesidades *an)lisis de re+uisitos,...........................................13.2 &studio de la %ia.ilidad...............................................................................................21 3.3 An)lisis t/cnico $ econ!mico......................................................................................22 3.4 'odelado de la ar+uitectura del sistema.....................................................................23 3.5 &specificaci!n del sistema..........................................................................................23 3.6 Creaci!n de prototipos del software...........................................................................24
1.+ D#"e,o &e "#"te)a".................................................................................................2-

1.4.1 0ise1o de datos........................................................................................................25 1.4.2 0ise1o ar+uitect!nico...............................................................................................26 1.4.3 0ise1o de la interfa2.................................................................................................2" 4.4 0ise1o procedimental..................................................................................................2" 1.4.4 Ar+uitectura del software.........................................................................................21.4.6 Criterios para e%aluar la calidad del dise1o.............................................................21.- De"arrollo &e "oftware ..........................................................................................2. 1./ Pr0e1a &el "oftware..............................................................................................2.

1.6.1 3.4eti%os de la prue.a..............................................................................................35 1.6.2 6erificaci!n $ %alidaci!n.........................................................................................35

1.* I)'la%ta!#$% ..........................................................................................................32

1.".1 Capacitaci!n de usuarios del sistema.......................................................................35 1.".2 &%aluaci!n del sistema.............................................................................................31

1.3 4a%te%#)#e%to ......................................................................................................31 1.. Cal#&a& &el Software...............................................................................................32

1. .1 7actores de calidad del software..............................................................................33 1.15.2 Bi.liografa............................................................................................................34 5.2 Bi.liografa.................................................................................................................34

INTRODUCCIN 8as t/cnicas de modelaci!n de o.4etos constitu$en una nue%a forma de pensar acerca de los pro.lemas9 empleando di%ersos modelos +ue se organi2an a partir del mundo real. 8os modelos orientados a o.4etos son :tiles para comprender los pro.lemas9 comunicarse con los e;pertos de la aplicaci!n9 modelar la empresa9 documentar $ dise1ar programas $ .ases de datos. 8a esencia del desarrollo orientado a o.4etos es la identificaci!n $ organi2aci!n de conceptos del dominio de la aplicaci!n $ no de su representaci!n final en un lengua4e de programaci!n. &l desarrollo orientado a o.4etos es un proceso conceptual9 es una forma de pensar $ no una t/cnica de programaci!n. . Sus .eneficios ma$ores proceden de la a$uda +ue ofrecen a +uienes constru$en las especificaciones9 a los desarrolladores $ a los clientes para +ue e;presen conceptos a.stractos $ se comuni+uen unos con otros. &l Lenguaje Unificado de Modelado (UML Unified Modeling Language) es un lengua4e gr)fico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. #roporciona una forma est)ndar de descri.ir los planos del sistema9 cu.riendo las cosas conceptuales tales como< procesos de negocio $ funciones del sistema9 as como las cosas concretas tales como< clases escritas en un lengua4e de programaci!n9 es+uemas de .ases de datos $ componentes reutili2a.les. 8a metodologa de an)lisis $ dise1o orientados a o.4etos 3'= es un proceso para la producci!n organi2ada de software orientado a o.4etos9 consta de una serie de etapas o pasos a seguir +ue se organi2an dentro de un ciclo de %ida con %arias fases de desarrollo9 $ +ue %an desde la formulaci!n inicial del pro.lema9 pasando por el an)lisis9 dise1o9 implementaci!n $ prue.a del software9 $ una fase adicional de mantenimiento si es necesaria. &st) .asada en el uso de una notaci!n orientada a o.4etos para descri.ir clases $ relaciones a lo largo de todo el ciclo %ital. &n el presente material se e;pone en su primera parte un resumen de la Ingeniera del Software, pasando por las diferentes etapas del ciclo de %ida del desarrollo de un software. &n su segunda parte se presenta el lengua4e de representaci!n gr)fica UML9 de manera +ue usted pueda dominar el %oca.ulario9 reglas $ especificaciones del lengua4e9 as como usarlo para resol%er pro.lemas. &n su tercera parte se presenta un resumen de la metodologa 3'= de an)lisis $ dise1o orientados a o.4etos9 con el o.4eti%o de +ue se cono2can los distintos pasos a seguir en la creaci!n de software. .

CAPITULO 1. INGENIERA DEL SOFTWARE El Software y el Proce o. >?u/ es realmente el software@ &l software es un producto +ue permite la utili2aci!n de la potencia del Aardware inform)tico en su ma$or medida9 produciendo $ gestionando informaci!n9 mostr)ndola $ modific)ndola. &s la .ase de control de la computadora *sistemas operati%os,9 la comunicaci!n de informaci!n *redes,9 $ Aasta de la creaci!n $ control de otros softwares *Aerramientas de desarrollo $ entornos,. &ntrega informaci!n *considerada por mucAos el producto m)s importante, $ proporciona el medio de ad+uirirla9 gestiona informaci!n comercial en %istas a me4orar la competiti%idad9 permite el acceso a las redes de comunicaci!n *Internet,. Su papel Aa cam.iado mucAo desde las d/cadas anteriores a la actualidad9 pro%ocado esto por las grandes me4oras en el Aardware $ los cam.ios en las ar+uitecturas inform)ticas9 como son el aumento de la capacidad de memoria $ de almacenamiento. Sin em.argo9 persisten $ aumentan un con4unto de pro.lemas relacionados con el software. &ntre ellos tenemos +ue los a%ances del Aardware de4an atr)s la capacidad de producir software para alcan2ar el potencial del mismo9 la demanda de nue%os programas es m)s grande +ue la capacidad de producci!n de software $ por tanto no se cu.ren las necesidades del mercado $ los negocios9 la sociedad es cada %e2 m)s dependiente de la fia.ilidad del software $ sus fallos pro%ocan da1os econ!micos $ a %eces Aumanos grandes9 por lo cual se lucAa por un software de alta calidad $ fia.ilidad. &l software puede considerarse como< 1. instrucciones *programas de computadoras, +ue cuando se e4ecutan proporcionan la funci!n $ el rendimiento deseados9 2. estructuras de datos +ue permiten a los programas manipular adecuadamente la informaci!n9 $ 3. documentos +ue descri.en la operaci!n $ el uso de programas. 1.1 Caracter! t"ca #el oftware #ara poder comprender lo +ue es el software *$ consecuentemente la ingeniera del software,9 es importante e;aminar las caractersticas del software +ue lo diferencian de otras cosas +ue los Aom.res pueden construir. Cuando se constru$e Aardware9 el proceso creati%o Aumano se traduce finalmente en una forma fsica. &l software es un elemento del sistema +ue es l!gico9 en lugar de fsico9 por tanto el software tiene caractersticas considera.lemente distintas a las del Aardware< l software se desarrolla, no se fa!rica en un sentido cl"sico. Aun+ue e;isten similitudes entre el desarrollo del software $ la construcci!n del Aardware9 am.as acti%idades son diferentes9 en ellas la .uena calidad se ad+uiere mediante un .uen

dise1o9 pero la fase de construcci!n del Aardware puede introducir pro.lemas de calidad +ue no e;isten *o son f)cilmente corregi.les, en el software. Am.as acti%idades dependen de las personas $ re+uieren de m/todos de construcci!n del producto final9 pero la relaci!n entre las personas dedicadas $ el tra.a4o reali2ado es completamente diferente para el software9 as como los m/todos utili2ados. l software no se #estropea$% 8os fallos iniciales en el Aardware una %e2 corregidos Aacen +ue la tasa de fallos .a4e a un ni%el donde permanece Aasta un perodo de tiempo en +ue los componentes de Aardware sufren los efectos acumulati%os de la suciedad9 la %i.raci!n9 los malos tratos9 las temperaturas e;tremas $ mucAos otros males e;ternos. Sencillamente9 el Aardware comien2a a estropearse. &l software no es suscepti.le a los males del entorno +ue Aacen +ue el Aardware se estropee. 8os defectos no detectados Aar)n +ue falle el programa durante las primeras etapas de su %ida pero estos se corrigen. 8a implicaci!n es clara9 el software no se estropea9 pero se deteriora9 pues sufre cam.ios *mantenimientos, en su %ida $ conforme se Aacen los cam.ios9 es .astante pro.a.le +ue se introdu2can nue%os defectos9 Aaciendo +ue se solicite otro cam.io. 8entamente9 el ni%el mnimo de fallos comien2a a crecerB el software se %a deteriorando de.ido a los cam.ios. Cada fallo en el software indica un error en el dise1o o en el proceso mediante el +ue se tradu4o el dise1o a c!digo m)+uina e4ecuta.le. #or tanto9 el mantenimiento en el software es m)s comple4o +ue en el Aardware9 pues para este :ltimo se cuenta con pie2as de repuesto9 lo cual no es as en el caso del software. La mayora del software se construye a medida, en vez de ensam!lar componentes e&istentes. #ara el dise1o $ construcci!n de Aardware de control para un producto .asado en un microprocesador el ingeniero constru$e un es+uema de la circuitera digital9 Aace alg:n an)lisis fundamental para asegurar +ue se reali2a la funci!n adecuada $ %a al cat)logo de %entas de componentes digitales e;istentes9 donde cada circuito integrado tiene un n:mero de pie2a9 una funci!n definida $ %)lida9 una interfa2 .ien definida $ un con4unto est)ndar de criterios de integraci!n9 selecciona cada componente9 $ solicita la compra. #ara el software no se dispone de esa comodidad +ue aca.amos de descri.ir. Con pocas e;cepciones9 no e;isten cat)logos de componentes de software. Se puede comprar software $a desarrollado9 pero s!lo como una unidad completa9 no como componentes +ue pueden reensam.larse en nue%os programas9 aun+ue $a se est) comen2ando a %er las primeras implementaciones con /;ito de este concepto. 1.$ Co%&o'e'te #el oftware A medida +ue la disciplina del software e%oluciona9 se crea un grupo de componentes de dise1o est)ndar. 8os componentes reutili2a.les se Aan creado para +ue el ingeniero pueda concentrarse en elementos %erdaderamente inno%adores de un dise1o. &n el mundo del Aardware9 la reutili2aci!n de componentes es una parte natural del proceso de ingeniera. &n el mundo del software9 es algo +ue toda%a se tiene +ue lograr en una escala amplia.

8a reutili2aci!n es una caracterstica importante para un componente de software de alta calidad. &l componente de.era dise1arse e implementarse para +ue pueda %ol%er a ser reutili2ado en mucAos programas diferentes. &n los a1os sesenta se constru$eron .i.liotecas de su.rutinas cientficas reutili2a.les en una amplia serie de aplicaciones cientficas $ de ingeniera. &sas .i.liotecas de su.rutinas reutili2a.an de forma efecti%a algoritmos .ien definidos9 pero tenan un dominio de aplicaci!n limitado. (o$ en da9 se Aa e;tendido la %isi!n de reutili2aci!n para a.arcar no s!lo los algoritmos9 sino tam.i/n estructuras de datos. 8os componentes reutili2a.les modernos encapsulan tanto datos como procesos +ue se aplican a los datos9 permitiendo al ingeniero del software crear nue%as aplicaciones a partir de las partes reutili2a.les. 1.( A&l"cac"o'e #el oftware &l software puede aplicarse en cual+uier situaci!n en la +ue se Aa$a definido pre%iamente un con4unto especfico de pasos procedimentales 0os factores importantes a considerar para determinar la naturale2a de una aplicaci!n de software son< el contenido y determinismo de la informaci'n. &l contenido se refiere al significado $ a la forma de la informaci!n de entrada $ de salida. &l determinismo de la informaci!n se refiere a la predeci.ilidad del orden $ del tiempo de llegada de los datos. Cn programa de ingeniera acepta datos +ue est)n en un orden predefinido9 e4ecuta el algoritmo sin interrupci!n $ produce los datos resultantes en un informe o formato gr)fico. &l software9 seg:n tipos de aplicaciones9 se pueden clasificar como< Software de sistemas. &s un con4unto de programas +ue Aan sido escritos para ser%ir a otros programas. Algunos programas de sistemas *por e4emplo9 compiladores9 editores $ utilidades de gesti!n de arcAi%os, procesan estructuras de informaci!n comple4as9 pero determinadas. 3tras aplicaciones de sistemas9 como ciertos componentes del sistema operati%o9 utilidades de mane4o de perif/ricos $ procesadores de telecomunicaciones procesan datos en gran medida indeterminados. Software de tiempo real. 'ide9 anali2a $ controla sucesos del mundo real conforme ocurren. &ntre sus elementos se inclu$en< un componente de ad+uisici!n de datos +ue recolecta $ da formato a la informaci!n reci.ida del entorno e;terno9 un componente de an)lisis +ue transforma la informaci!n seg:n lo re+uiera la aplicaci!n9 un componente de controlDsalida +ue responda al entorno e;terno $ un componente de monitori2aci!n +ue coordina todos los dem)s componentes9 de forma +ue pueda mantenerse la respuesta en tiempo real. Software de gestin. &l procesamiento de informaci!n comercial constitu$e la ma$or de las )reas de aplicaci!n del software. 8os Esistemas discretosF *n!minas9 in%entarios9 etc., Aan e%olucionado Aacia el software de sistemas de informaci!n de gesti!n *SIG,9 +ue accede a una o m)s .ases de datos grandes +ue contienen informaci!n comercial.

 Software de ingeniera y cientfico. &st) caracteri2ado por los algoritmos de Emane4o de n:merosF. 8as aplicaciones %an desde la astronoma a la %ulcanologa9 desde el an)lisis de la presi!n de los automotores a la din)mica or.ital de las lan2aderas espaciales $ desde la .iologa molecular a la fa.ricaci!n autom)tica. Sin em.argo9 las nue%as aplicaciones del )rea de ingeniera $ ciencia se Aan ale4ado de los algoritmos con%encionales num/ricos. &l dise1o asistido por computadoras *del ingl/s CA0,9 la simulaci!n de sistemas $ otras aplicaciones interacti%as9 Aan comen2ado a coger caractersticas del software de tiempo real e incluso del software de sistemas. Software empotrado. 8os productos inteligentes se Aan con%ertido en algo com:n en casi todos los mercados de consumo e industriales. &l software empotrado reside en memoria de s!lo lectura $ se utili2a para controlar productos $ sistemas de los mercados industriales $ de consumo. &l software empotrado puede e4ecutar funciones mu$ limitadas $ curiosas9 por e4emplo9 el control de las teclas de un Aorno de microondas. Software de computadoras personales. &ste mercado Aa florecido en la pasada d/cada. &l procesamiento de te;tos9 las Ao4as de c)lculo9 los gr)ficos por computadora9 multimedia9 entretenimientos9 gesti!n de .ases de datos9 aplicaciones financieras9 de negocios $ personales9 $ redes o acceso a .ases de datos e;ternas son algunas de los cientos de aplicaciones. Software de Inteligencia Artificial. &ste Aace uso de algoritmos no num/ricos para resol%er pro.lemas comple4os para los +ue no son adecuados el c)lculo o el an)lisis directo. Actualmente9 el )rea m)s acti%a de la IA es la de los sistemas e;pertos o .asados en el conocimiento. 3tras )reas de aplicaci!n para este software son el reconocimiento de patrones *im)genes $ %o2,9 la prue.a de teoremas $ los 4uegos. &n los :ltimos a1os se Aa desarrollado una nue%a rama del software de IA llamada redes neuronales artificiales. 1.) I'*e'"er!a #el Software 8a Ingeniera del Software es un )rea de la inform)tica +ue ofrece m/todos $ t/cnicas para desarrollar $ mantener software de calidad +ue resuel%an pro.lemas de todo tipo. 8a Ingeniera del Software es una nue%a ingeniera. Cna selecci!n de las definiciones de HIngeniera del SoftwareI se muestra a continuaci!n< (efinici'n de )ritz *auer, +,-./ Ingeniera del Software trata del esta!lecimiento de principios y m0todos de la ingeniera a fin de o!tener software de modo renta!le 1ue sea fia!le y tra!aje en ma1uinas reales% 8a ma$ora de los lectores tienden a seguir esta definici!n. Aun+ue no dice so.re los aspectos t/cnicos de la calidad del software9 no se enfrenta directamente con la necesidad de la satisfacci!n del cliente9 omite la menci!n de la importancia de mediciones $ m/tricasB

tampoco e;presa la importancia de un proceso a%an2ado. Sin em.argo9 la definici!n de Bauer nos proporciona una lnea .ase. &l I&&& JI&&& 3K Aa desarrollado una definici!n m)s completa< Ingeniera del software/ (+) La aplicaci'n de un enfo1ue sistem"tico, disciplinado y cuantifica!le 2acia el desarrollo, operaci'n y mantenimiento del software3 es decir, la aplicaci'n de ingeniera al software% (.) l estudio de enfo1ues como en (+)% Proce o+ %,to#o y -erra%"e'ta 8a ingeniera del software es una tecnologa multicapa. Cual+uier enfo+ue de ingeniera de.e descansar so.re un empe1o de organi2aci!n de calidad. 8a gesti!n total de calidad $ las filosofas similares fomentan una cultura continua de me4oras de procesos9 la +ue conduce :ltimamente al desarrollo de enfo+ues cada %e2 m)s ro.ustos para la ingeniera del software. &l fundamento de la ingeniera del software es la capa proceso. &l proceso de la ingeniera del software es la uni!n +ue mantiene 4untas las capas de tecnologa $ +ue permite un desarrollo racional $ oportuno de la ingeniera del software. &l proceso define un marco de tra.a4o para un con4unto de )reas cla%e de proceso +ue se de.e esta.lecer para la entrega efecti%a de la tecnologa de la ingeniera del software. 8as )reas cla%e del proceso forman la .ase del control de gesti!n de pro$ectos del software $ esta.lece el conte;to en el +ue se aplican los m/todos t/cnicos9 se producen resultados del tra.a4o *modelos9 documentos9 datos9 informes9 formularios9 etc.,9 se esta.lecen Aitos9 se asegura la calidad $ el cam.io se gestiona adecuadamente. 8os m0todos de la ingeniera del software indican c!mo construir t/cnicamente el software. A.arcan un con4unto de tareas +ue inclu$en an)lisis de re+uisitos9 dise1o9 construcci!n de programas9 prue.as $ mantenimiento. 8as 2erramientas de la ingeniera del software proporcionan un soporte autom)tico o semiautom)tico para el proceso $ para los m/todos. Cuando se integran Aerramientas para +ue la informaci!n creada por una Aerramienta la pueda utili2ar otra9 se esta.lece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computadora *Computer Aided Software &ngineering9 CAS&,. CAS& com.ina software9 Aardware $ una .ase de datos de ingeniera del software. 8a ingeniera es el an)lisis9 dise1o9 construcci!n9 %erificaci!n $ gesti!n de entidades. A la entidad se le de.e reali2ar $ responder las siguientes preguntas< >Cu)l es el pro.lema a resol%er@ >Cu)les son las caractersticas de la entidad utili2adas para resol%er el pro.lema@ >C!mo se reali2ar) la entidad *$ la soluci!n,@ >C!mo se construir) la entidad@

"

>?u/ enfo+ue se %a a utili2ar para no contemplar los errores +ue se cometieron en el dise1o $ en la construcci!n de la entidad@ >C!mo se apo$ar) la entidad cuando usuarios soliciten correcciones9 adaptaciones $ me4oras de la entidad@

&n el curso s!lo nos %amos a centrar en una sola entidad< el software de computadoras. #ara construir la ingeniera del software adecuadamente9 se de.e definir un proceso de desarrollo de software9 formado por tres fases< 7ase de definici!n se centra so.re el +u/. 7ase de desarrollo se centra en el c!mo. 7ase de mantenimiento se centra en el cam.io +ue %a asociado a la correcci!n.

1.).$ .o#elo #e &roce o #e oftware. #ara resol%er los pro.lemas reales un ingeniero de software o un e+uipo de ingenieros de.en incorporar una estrategia de desarrollo +ue acompa1e al proceso9 m/todos9 Aerramientas $ fases gen/ricas del proceso del software. =odo el desarrollo del software se puede caracteri2ar como un .ucle de resoluci!n de pro.lemas donde se encuentran cuatro etapas distintas< Status +uo< estado actual de sucesos. 0efinici!n de pro.lemas< identifica el pro.lema especfico a resol%er. 0esarrollo t/cnico< resuel%e el pro.lema a tra%/s de la aplicaci!n de alguna tecnologa. Integraci!n de soluciones< ofrece los resultados a los +ue solicitan la soluci!n en primer lugar.

Basado en estas cuatro etapas se tienen %arios modelos de procesos de software. .o#elo l"'eal ec/e'c"al0 llamado tam.i/n ciclo de %ida cl)sico9 sugiere un enfo+ue sistem)tico $ secuencial del desarrollo del software9 $ consta de las acti%idades siguientes< Ingeniera y modelado del sistema4informaci'n/ el software siempre forma parte de un sistema m)s grande9 Aa$ +ue determinar de ese sistema +ue re+uisitos forman parte del software9 $ su cone;i!n con otros elementos como personas o .ases de datos. 5n"lisis de los re1uisitos del software/ parte de esto se logra en el paso anterior9 en este paso ese proceso de reuni!n de re+uisitos se intensifica $ se centra solamente en el software9 el analista de.e comprender el dominio del pro.lema para poder construirlo9 $ el cliente documenta $ repasa los re+uisitos del sistema. (ise6o/ es un proceso de %arios pasos +ue se centra en cuatro atri.utos distintos de un programa< estructura de datos9 ar+uitectura del software9 representaciones de interfa29 $ los detalles procedimentales o algoritmos. &ste proceso traduce los re+uisitos en una representaci!n del software +ue se pueda e%aluar por calidad antes de la generaci!n de c!digo9 $ al igual +ue los re+uisitos se documenta9 lo +ue forma parte de la configuraci!n del software.
-

 7eneraci'n de c'digo o implementaci'n/ &ste paso lle%a a ca.o la tarea de traducci!n del dise1o a una forma legi.le por la m)+uina. Si el dise1o es detallado este paso es casi mec)nico. 8rue!as/ 0espu/s de la generaci!n comien2an las prue.as del programa9 centrada en los procesos l!gicos internos del software9 $ en los e;ternos funcionales9 para detectar errores $ compro.ar +ue la entrada definida produce los resultados deseados. Mantenimiento/ es casi seguro +ue el software sufra cam.ios luego de su entrega al cliente9 pro%ocado por causas como dispositi%os nue%os disponi.les9 o necesidad de me4oras funcionales o de rendimiento. .o#elo #e co' tr/cc"1' #e &rotot"&o 0 este modelo comien2a con la recolecci!n de re+uisitos9 donde analista $ cliente definen las necesidades9 luego aparece un dise1o r)pido9 +ue se centra en la representaci!n de los aspectos %isi.les al usuario9 este dise1o lle%a a la construcci!n de un prototipo9 +ue es e%aluado por el usuario9 $ este lo utili2a para refinar los re+uisitos +ue desea del software. &ste prototipo se puede utili2ar en el desarrollo del software final o puede descartarse $ reali2ar una ingeniera del software en %istas a la calidad $ la facilidad de mantenimiento. .o#elo DRA/ el modelo de desarrollo r)pido de aplicaciones es un modelo de desarrollo lineal secuencial con un ciclo de desarrollo e;tremadamente corto. #ara esto se desarrolla un enfo+ue de construcci!n .asado en componentes9 lo +ue permite reducir el ciclo de entrega del producto final9 pero es recomenda.le solamente en los casos en +ue la aplicaci!n se puede modulari2ar adecuadamente9 $ enfati2a el desarrollo de componentes de programas reutili2a.les9 +ue son la piedra angular de las tecnologas de o.4etos. .o#elo #e &roce o e2ol/t"2o 0 estos modelos son iterati%os $ permiten a los ingenieros desarrollar %ersiones cada %e2 m)s completas del software. .o#elo "'cre%e'tal< com.ina el ciclo de %ida cl)sico con la filosofa interacti%a de construcci!n de prototipos9 en cada incremento o secuencia lineal +ue se reali2a se logra una parte del o.4eti%o9 $ se %an entregando %ersiones sucesi%as del software. .o#elo e' e &"ral< este modelo com.ina la naturale2a de la construcci!n de prototipos con los aspectos controlados del modelo lineal secuencial9 se desarrolla el software en cada etapa o espiral como un prototipo +ue e%al:a el cliente $ +ue es el punto de partida de la pr!;ima iteraci!n. .o#elo #e e' a%3la4e #e co%&o'e'te < este incorpora mucAas caractersticas del modelo en espiral9 $ configura las aplicaciones a partir de componentes $a e;istentes +ue son reutili2ados. 1.5 S" te%a 6a a#o e' Co%&/ta#ora 8a Ingeniera del Software es una consecuencia de un proceso llamado Ingeniera de Sistemas de 9omputadoras%

&l proceso de ingeniera del software es denominado ingeniera de la informaci'n cuando el conte;to del tra.a4o de ingeniera se enfoca a una empresa. Cuando Aa$ +ue construir un producto9 el proceso se denomina ingeniera de producto. Am.as ingenieras de la informaci!n $ de producto intentan poner orden al desarrollo de sistemas .asados en computadoras9 tanto la ingeniera de la informaci!n como la de producto tra.a4an para asignar un papel al software de computadora $ para esta.lecer los enlaces +ue unen al software con otros elementos de un sistema .asado en computadora. 8a pala.ra EsistemaF es uno de los t/rminos m)s usados del l/;ico t/cnico. &l diccionario Le.ster define EsistemaF como Eun con4unto o disposici!n de cosas relacionadas de manera +ue forman una unidad o u todo org)nico... un con4unto de AecAos9 principios9 reglas9 etc.9 clasificadas $ dispuestas de manera ordenada mostrando un plan l!gico de uni!n de las partes... un m/todo o plan de clasificaci!n o disposici!n... una manera esta.lecida de Aacer algoB m/todoB procedimiento...F. Se define un Sistema *asado en 9omputadoras como un conjunto o arreglo de elementos 1ue est"n organizados para realizar un o!jetivo predefinido procesando informaci'n% 1.5.1 Ele%e'to #e /' " te%a 3a a#o e' co%&/ta#ora Software. #rogramas de computadora9 estructuras de datos $ su documentaci!n +ue sir%en para Aacer efecti%o el m/todo l!gico9 procedimiento o control re+uerido. :ardware. 0ispositi%os electr!nicos +ue proporcionan capacidad de c)lculo $ dispositi%os electromec)nicos *&4.< sensores9 motores9 .om.as, +ue proporcionan una funci!n e;terna. 8ersonas. Son los usuarios $ operadores del Aardware $ software.

*ase de datos. Cna gran colecci!n de informaci!n organi2ada a la +ue se accede por medio del software. (ocumentaci'n% 'anuales9 formularios $ otra informaci!n descripti%a +ue retrata el empleo $Do operaci!n del sistema. 8rocedimientos% 8os pasos +ue definen el empleo especfico de cada elemento del sistema o el conte;to procedimental en +ue reside el sistema. =odos estos elementos se com.inan de %arias maneras para transformar la informaci!n. 8a ingeniera de sistemas de computadoras es un proceso de modelado. &l ingeniero crea modelos +ue< 0efinan los procesos +ue satisfagan las necesidades. Mepresenten el comportamiento de los procesos
15

0efinan e;plcitamente las entradas de informaci!n al modelo Mepresenten todas las uniones *inclu$endo las salidas, +ue permitan al ingeniero entender me4or la %isi!n. 1.7 I'*e'"er!a #e la "'for%ac"1' 8a meta de la ingeniera de la informaci!n es definir ar+uitectura +ue permitan a las empresas emplear la informaci!n efica2mente. Se de.en anali2ar $ dise1ar tres ar+uitecturas diferentes dentro del conte;to de o.4eti%os $ metas de negocio< Ar+uitectura de datos Ar+uitectura de aplicaciones Infraestructura de la tecnologa

8a ar1uitectura de datos proporciona una estructura para las necesidades de informaci!n de un negocio o de una funci!n de negocio. 8os o.4etos de datos flu$en entre las funciones de negocio9 est)n organi2ados dentro de una .ase de datos $ son transformados para proporcionar informaci!n +ue satisfaga las necesidades del negocio. 8a ar1uitectura de aplicaci'n comprende a+uellos elementos de un sistema +ue transforma o.4etos dentro de la ar+uitectura de datos por alg:n prop!sito del negocio. 6amos a considerar +ue la ar+uitectura de aplicaci!n es el sistema de programas *software, +ue reali2a esta transformaci!n. . 8a infraestructura de la tecnologa proporciona el fundamento de la ar+uitectura de datos $ de aplicaciones. 8a infraestructura comprende el Aardware $ el software empleados para dar soporte a las aplicaciones $ datos. . 1.8 I'*e'"er!a #e &ro#/cto 8a meta de la ingeniera de productos es traducir el deseo de un cliente9 de un con4unto de capacidades definidas9 en un producto operati%o. #ara conseguir esta meta9 la ingeniera de producto *como la ingeniera de la informaci!n, de.e crear una ar+uitectura $ una infraestructura. 8a ar+uitectura comprende cuatro componentes de sistema distintos< software9 Aardware9 datos *.ases de datos, $ personas. Se esta.lece una infraestructura de soporte e inclu$e la tecnologa re+uerida para unir los componentes $ la informaci!n *p. e4.< documentos9 C0NM3'9 %deo, +ue se emplea para dar soporte a los componentes.

$. Ge t"1' #e &royecto #e oftware 8a gesti!n efica2 de un pro$ecto de software se centra en las tres OpO< personal, pro!lema y proceso% &l orden no es ar.itrario. &l gestor +ue se ol%ida de +ue el tra.a4o de ingeniera
11

del software es un esfuer2o Aumano intenso nunca tendr) /;ito en la gesti!n de pro$ectos. Cn gestor +ue no fomenta una minuciosa comunicaci!n con el cliente al principio de la e%oluci!n del pro$ecto se arriesga a construir una elegante soluci!n para un pro.lema e+ui%ocado. 7inalmente9 el administrador +ue presta poca atenci!n al proceso corre el riesgo de arro4ar m/todos t/cnicos $ Aerramientas eficaces al %aco. Per o'al 8a necesidad de contar con personal para el desarrollo del software altamente preparado $ moti%ado se %iene discutiendo desde los a1os 65. &l proceso del software $ todos los pro$ectos de software lo componen participantes +ue pueden clasificarse en una de cinco categoras< 1. 2. 3. 4. ;% Ge tore /&er"ore , +ue definen los aspectos de negocios +ue a menudo tienen una significati%a influencia en el pro$ecto. Ge t"o'e 9t,c'"co : #el &royecto, +ue de.en planificar9 moti%ar9 organi2ar $ controlar a los profesionales +ue reali2an el tra.a4o de software. Profe "o'ale + +ue proporcionan las capacidades t/cnicas necesarias para la ingeniera de un producto o aplicaci!n. Clientes, +ue especifican los re+uisitos para la ingeniera del software. Usuarios finales, +ue interaccionan con el software una %e2 +ue se Aa entregado para la producci!n9

Pro3le%a Antes de poder planificar un pro$ecto9 se de.eran esta.lecer sus o.4eti%os $ su )m.ito9 se de.eran considerar soluciones alternati%as e identificar las dificultades t/cnicas $ de gesti!n. Sin esta informaci!n9 es imposi.le definir unas estimaciones ra2ona.les *$ e;actas, del costo9 una %aloraci!n efecti%a del riesgo9 una su.di%isi!n realista de las tareas del pro$ecto o una planificaci!n del pro$ecto ase+ui.le +ue proporcione una indicaci!n fia.le del progreso. &l desarrollador de software $ el cliente de.en reunirse para definir los o.4eti%os del pro$ecto $ su )m.ito. &n mucAos casos9 esta acti%idad empie2a como parte del proceso de ingeniera del sistema $ contin:a como el primer paso en el an)lisis de los re+uisitos del software. 8os o.4eti%os identifican las metas generales del pro$ecto sin considerar c!mo se conseguir)n. &l )m.ito identifica los datos primarios9 funciones $ comportamientos +ue caracteri2an el pro.lema9 $ m)s importante9 intenta a!ordar estas caractersticas de una manera cuantitati%a. Cna %e2 +ue se Aan entendido los o.4eti%os $ el )m.ito del pro$ecto9 se consideran las soluciones alternati%as. Aun+ue se estudia con poco detalle9 las alternati%as permiten a los gestores $ a los profesionales seleccionar el E'e4orF enfo+ue9 dadas las limitaciones

12

impuestas por las fecAas lmite de entrega9 restricciones del presupuesto9 disponi.ilidad de personal9 interfaces t/cnicas $ otros mucAos factores. Proce o Cn proceso de software proporciona la estructura desde la +ue se puede esta.lecer un detallado plan para el desarrollo del software. Cn pe+ue1o n:mero de actividades estructurales se puede aplicar a todos los pro$ectos de software9 sin tener en cuenta su tama1o o comple4idad. 0iferentes conjuntos de tareas9 Aitos9 entregas $ garanta de calidad permite a las acti%idades estructurales adaptarse a las caractersticas del pro$ecto de software $ a los re+uisitos del e+uipo del pro$ecto. 7inalmente9 las acti%idades protectoras tales como garanta de calidad del software9 gesti!n $ configuraci!n del software $ medici!n cu.ren el modelo de proceso $ se desarrollan a todo lo largo del mismo. $.1 Pla'"f"cac"1' #e &royecto &l proceso de gesti!n de pro$ecto de software comien2a con un con4unto de acti%idades +ue se denominan planificaci'n del proyecto% 8a primera de estas acti%idades es la estimaci'n% Siempre +ue estimamos9 ecAamos un %istazo al futuro $ aceptamos resignados cierto grado de incertidum.re. Aun+ue la estimaci!n es m)s un arte +ue una ciencia9 es una acti%idad importante +ue no de.e lle%arse a ca.o de forma descuidada. &;isten t/cnicas :tiles para la estimaci!n de costes $ de tiempos. P9 dado +ue la estimaci!n es la .ase de todas las dem)s acti%idades de planificaci!n del pro$ecto $ sir%e como gua para una .uena ingeniera del software9 no es en a.soluto aconse4a.le em.arcarse sin ella. 8a estimaci!n de recursos9 costes9 $ planificaci!n temporal de un esfuer2o en desarrollo de software re+uiere e;periencia9 acceder a una .uena informaci!n Aist!rica $ el cora4e de confiar en medidas cuantitati%as cuando todo lo +ue e;iste son datos cualitati%os. 8a estimaci!n conlle%a un riesgo inAerente $ es este riesgo el +ue lle%a a la incertidum.re. &n la estimaci!n se toman en cuenta adem)s del procedimiento t/cnico a utili2ar en el pro$ecto9 los recursos9 costos $ planificaci!n. &l tama1o del pro$ecto constitu$e un factor importante +ue puede afectar la precisi!n de las estimaciones. &n la medida +ue el tama1o aumenta9 se incrementa m)s r)pido la independencia de los elementos del software. $.1.1 O34et"2o #e la &la'"f"cac"1' #el &royecto &l o.4eti%o de la planificaci!n del pro$ecto de software es .rindar un entorno de tra.a4o +ue facilite al gestor Aacer estimaciones de recursos9 costos $ planificaci!n temporal. 8as estimaciones se reali2an al comien2o de un pro$ecto de software9 $ de.en ser actuali2adas en la medida +ue el pro$ecto a%an2a. 8as estimaciones de.eran definir las escenas del me4or $ peor caso9 de forma tal +ue se puedan definir me4or los limites de los resultados del pro$ecto.

13

$.$ Act"2"#a#e a oc"a#a a la &la'"f"cac"1' #e &royecto #e oftware. $.$.1 ;%3"to #el Software. 8a primera acti%idad +ue se lle%a a ca.o durante la planificaci!n del pro$ecto de software es el "m!ito del software% &l )m.ito se define respondiendo las siguientes cuestiones. Co'te<to. >C!mo enca4a el software a construir en un sistema9 producto o conte;to de negocios ma$or $ +ue limitaciones se imponen como resultado del conte;to@ O34et"2o #e "'for%ac"1'. >?u/ o.4etos de datos %isi.les al cliente se o.tienen del software@ >?u/ o.4etos de datos son re+ueridos de entrada@ F/'c"1' y re'#"%"e'to. >?u/ funci!n reali2a el software para transformar la informaci!n de entrada en una salida@ >(a$ caractersticas de rendimiento especiales +ue a.ordar@ 0urante esta etapa9 se de.en e%aluar la funci!n $ el rendimiento +ue se asignaron al software durante la Ingeniera del Sistema de Computadora9 con el prop!sito de esta.lecer un )m.ito de pro$ecto +ue no sea am.iguo9 e incomprensi.le para directi%os $ t/cnicos &l )m.ito del software descri.e la funci!n9 el rendimiento9 las restricciones9 las interfaces $ la fia.ilidad9 se e%al:an las funciones del )m.ito $ en algunos casos se refinan para dar m)s detalles antes del comien2o de la estimaci!n. 8as restricciones de rendimiento a.arcan los re+uisitos de tiempo de respuesta $ procesamiento9 identifican los lmites del software originados por el Aardware e;terno9 por la memoria disponi.le $ por otros sistemas e;istentes. Cn prerre+uisito para la estimaci!n es el )m.ito del software9 un elemento importante a tener en cuenta es la o.tenci!n de la informaci!n necesaria para el software9 donde el analista $ el cliente se re:nen $ mediante la reali2aci!n de preguntas llegan a precisar $ determinar los limites del sistema para su desarrollo9 as como a una me4or comprensi!n por el analista de sistema. $.$.$ Rec/r o 8a segunda acti%idad de la planificaci!n del desarrollo de software es la estimaci'n de los recursos re+ueridos para lle%ar a ca.o el desarrollo de software9 esto simula a una pir)mide donde las Aerramientas *Aardware $ software,9 son la .ase $ proporciona la infraestructura de soporte al esfuer2o de desarrollo9 en segundo ni%el se encuentran los componentes reutili2a.les9 $ en la parte m)s alta de la pir)mide se encuentran los recursos Aumanos. 8as caractersticas de cada recurso est)n dadas por< 0escripci!n del recurso. Informes de la disponi.ilidad. 7ecAa en la +ue se re+uiere el recurso. =iempo +ue ser) aplicado el recurso.
14

<ecursos :umanos 8os recursos Aumanos son la cantidad de personas necesarias para el desarrollo de un pro$ecto de software9 s!lo puede ser determinado despu/s de Aacer una estimaci!n del esfuer2o de desarrollo *por e4emplo personas mes o personas a1os,9 tam.i/n se selecciona la posici!n dentro de la organi2aci!n $ la especialidad +ue desempe1ar) cada profesional durante el desarrollo del software. <ecursos de software reutiliza!les Cual+uier estudio so.re recursos de software estara incompleto sin estudiar la reutili2aci!n9 o sea9 la creaci!n $ la reutili2aci!n de .lo+ues de construcci!n de software. Se sugieren cuatro categoras de recursos de software a tener en cuenta durante la planificaci!n< 1. Componentes $a desarrollados 2. Componentes $a e;perimentados. 3. Componentes con e;periencia parcial 4. Componentes nue%os <ecursos de entorno &l entorno es donde se apo$a el pro$ecto de software9 conocido como entorno de ingeniera del software *&IS,9 el cual incorpora Aardware $ software. &l Aardware proporciona una plataforma con las Aerramientas *software, necesarias para desarrollar los productos +ue son el resultado de una .uena pr)ctica de la ingeniera del software. Como la ma$ora de las organi2aciones de software tienen aspectos +ue re+uieren acceso a &IS9 un planificador de pro$ecto de.e determinar la %entana temporal re+uerida para el Aardware $ el software9 $ %erificar +ue estos recursos estar)n disponi.les. Cuando se le aplica la ingeniera a un sistema .asado en computadora9 el e+uipo de software puede re+uerir acceso a los elementos en desarrollo por otros e+uipos de ingeniera. $.( E t"%ac"1' #el &royecto #e oftware. &l coste del software constitua un pe+ue1o porcenta4e del coste total de los sistemas .asados en computadora. &n la actualidad9 el software constitu$e el elemento m)s caro de la ma$ora de los sistemas inform)ticos. Cn gran error en la estimaci!n del coste puede ser lo +ue mar+ue la diferencia entre .eneficios $ p/rdidas9 $ so.repasarse en el coste puede ser catastr!fico en el e+uipo de desarrollo. 8a estimaci!n del coste $ del esfuer2o del software nunca ser) una ciencia e;acta. Son demasiadas las %aria.les Aumanas9 t/cnicas9 de entorno9 polticas +ue pueden afectar al coste final del software $ al esfuer2o aplicado para desarrollarlo.

15

8as siguientes opciones son :tiles para reali2ar estimaciones seguras de costes $ esfuer2os< 1. 2. 3. 4. 0e4e la estimaci!n para m)s adelante *l!gico +ue podemos reali2ar una estimaci!n al cien por cien fia.le luego de Aa.er terminado el pro$ecto,. Guiar las estimaciones en pro$ectos similares $a concluidos. Csar t/cnicas de descomposici!n relati%amente sencillas para generar las estimaciones de coste $ de esfuer2o del pro$ecto. Mealice un modelo emprico para el c)lculo de costes $ esfuer2os del software.

8amenta.lemente9 la primera opci!n9 aun+ue atracti%a9 no es pr)ctica9 de.ido a +ue las estimaciones de costes se Aan de reali2ar a priori. Qo o.stante9 Aa$ +ue reconocer +ue cuanto m)s tiempo transcurra9 m)s elementos conocemos9 $ cuanto m)s sepamos9 menor ser) la pro.a.ilidad de cometer gra%es errores en las estimaciones. 8a segunda opci!n funciona si el pro$ecto actual es .astante similar a los esfuer2os anteriores $ si otras influencias del pro$ecto son similares. 8as opciones restantes son m/todos %ia.les para la estimaci!n del pro$ecto de software. 8as t/cnicas de descomposici!n utili2an un enfo+ue de Edi%ide $ %encer)sF para la estimaci!n del pro$ecto de software. Se pueden utili2ar los modelos empricos de estimaci!n como complemento de las t/cnicas de descomposici!n9 ofreciendo un enfo+ue de estimaci!n potencialmente %alioso por derecAo propio $.(.1 T,c'"ca #e e t"%ac"1'. E t"%ac"1' 3a a#a e' el &roce o. 8a estimaci!n .asada en el proceso es la t/cnica m)s com:n para estimar un pro$ecto9 es decir9 el proceso se descompone en un con4unto relati%amente pe+ue1o de tareas9 $ en el esfuer2o necesario para estimar cada tarea. &sta estimaci!n se inicia con una delineaci!n de las funciones del software o.tenidas a partir del )m.ito del pro$ecto. Se me2clan las funciones del pro.lema $ las acti%idades del proceso. #or :ltimo9 se calculan los costos $ el esfuer2o de cada funci!n $ en general la del proceso de software. $.) .o#elo e%&!r"co #e e t"%ac"1' 8os datos empricos +ue soportan la ma$ora de los modelos de estimaci!n se o.tienen de una muestra limitada de pro$ectos. #or esta ra2!n9 el modelo de estimaci!n no es adecuado para todas las clases de software $ en todos los entornos de desarrollo. #or tanto9 los resultados o.tenidos de dicAos modelos se de.en utili2ar con prudencia $.).1 .o#elo COCO.O Barr$ BoeAm9 en su li.ro cl)sico so.re economa de la Ingeniera del Software9 introduce una 4erar+ua de modelos de estimaci!n de Software con el nom.re de C3C3'3 *Constructi%e Cost 'odel, o modelo constructi%o de costos. 8a 4erar+ua de modelos de BoeAm esta formada por<

16

.o#elo I. &s el modelo C3C3'3 .)sico +ue calcula el esfuer2o $ el costo del desarrollo de software en funci!n del tama1o del programa9 e;presado en las lneas estimadas. .o#elo II. &s el modelo intermedio +ue calcula el esfuer2o del desarrollo de software en funci!n del tama1o del programa $ de un con4unto de conductores de costos +ue inter%ienen en la e%aluaci!n su.4eti%a del producto9 del Aardware9 del personal $ de los atri.utos del pro$ecto. .o#elo III. &s el modelo a%an2ado +ue incorpora las caractersticas de la %ersi!n intermedia $ lle%a a ca.o una e%aluaci!n del impacto de los conductores de costos en cada caso *an)lisis9 dise1o9 etc., del proceso de ingeniera de Software. $.5 =erra%"e'ta a/to%>t"ca #e e t"%ac"1' 8as t/cnicas de descomposici!n $ los modelos empricos de estimaci!n se pueden implementar con software9 las Aerramientas autom)ticas de estimaci!n permiten al planificador estimar costes $ esfuer2os9 $ lle%ar a ca.o un an)lisis del tipo E+u/ pasa siF con importantes %aria.les del pro$ecto9 como es la fecAa de entrega $ la selecci!n de personal. 8as Aerramientas autom)ticas de estimaci!n re+uieren una o m)s clases de datos como< Cna estimaci!n cuantitati%a del tama1o del pro$ecto o de la funcionalidad. Caractersticas cualitati%as del pro$ecto< comple4idad9 la fia.ilidad re+uerida $ el grado de criticidad del negocio. 0escripci!n del personal de desarrollo $Do del entorno de desarrollo. Con estos datos9 el modelo implementado por la Aerramienta autom)tica de estimaci!n .rinda estimaciones del esfuer2o re+uerido para lle%ar a ca.o el pro$ecto9 los costes9 la carga de personal9 la duraci!n $ en algunos casos9 la planificaci!n temporal de desarrollo $ el riesgo asociado. (. A'>l" " #e " te%a &l an)lisis de sistemas se lle%a a ca.o con los siguientes o.4eti%os< Identificar la necesidad del cliente. &%aluar el concepto del sistema para esta.lecer la %ia.ilidad. Meali2ar el an)lisis t/cnico $ econ!mico. Asignar funciones al Aardware9 software9 personal9 .ases de datos $ otros elementos del sistema. &sta.lecer restricciones de presupuesto $ planificaci!n temporal.

1"

Crear una definici!n del sistema +ue forme el fundamento de todo el tra.a4o de ingeniera.

#ara alcan2ar los o.4eti%os de la etapa del an)lisis se re+uiere de un amplio conocimiento del )rea de Aardware9 software9 administraci!n de .ases de datos $ de la ingeniera Aumana para interactuar con el personal +ue solicita la reali2aci!n del sistema. 8os m/todos de an)lisis se relacionan por un con4unto de principios operati%os< l. $. (. ). 5. 0e.e representarse $ entenderse el dominio de informaci!n de un pro.lema. 0e.en definirse las funciones +ue de.e reali2ar el software. 0e.e representarse el comportamiento del software *como consecuencia de acontecimientos e;ternos,. 0e.en di%idirse los modelos +ue representan informaci!n9 funci!n $ comportamiento de manera +ue se descu.ran los detalles por capas *o 4er)r+uicamente,. &l proceso de an)lisis de.era ir desde la informaci!n esencial Aasta el detalle de la implementaci!n.

Adem)s de los principios operati%os de an)lisis mencionados anteriormente9 se sugiere un con4unto de principios directrices para la Eingeniera de re+uisitosF< &ntender el pro.lema antes de empe2ar a crear el modelo de an)lisis. (a$ tendencia a precipitarse en .usca de una soluci!n9 incluso antes de entender el pro.lema. 0esarrollar prototipos +ue permitan al usuario entender como ser) la interacci!n Aom.reNm)+uina. Como el concepto de calidad del software se .asa a menudo en la opini!n so.re la Eamiga.ilidadF de la interfa29 el desarrollo de prototipos *$ la iteraci!n +ue se produce, es altamente recomenda.le. Megistrar el origen $ la ra2!n de cada re+uisito. &ste es el primer paso para esta.lecer un seguimiento Aasta el cliente Cse m:ltiples planteamientos de re+uisitos. 8a construcci!n de modelos de datos9 funcionales $ de comportamiento le proporcionan al ingeniero del software tres puntos de %ista diferentes. &sto reduce la pro.a.ilidad de +ue se ol%ide algo $ aumenta la pro.a.ilidad de reconocer la falta de consistencia. 0ar prioridad a los re+uisitos. 8as fecAas a4ustadas de entrega pueden impedir la implementaci!n de todos los re+uisitos del software. Si se aplica un modelo de proceso incremental9 se de.en identificar los re+uisitos +ue se %an a entregar en la primera entrega. =ra.a4ar para eliminar la am.igRedad. Como la ma$ora de los re+uisitos est)n descritos en un lengua4e natural9 a.unda la oportunidad de am.igRedades. &l empleo de re%isiones t/cnicas formales es una manera de descu.rir $ eliminar la am.igRedad.

(.1 I#e't"f"cac"1' #e la 'ece "#a#e 9a'>l" " #e re?/" "to :

1-

8o primero en el an)lisis del sistema es la identificaci!n de la necesidad del usuario9 donde el analista se re:ne con el cliente $ usuarios finales para entender los o.4eti%os del producto $ definir las metas necesarias para alcan2arlos. Cna %e2 +ue se Aan identificado las metas glo.ales9 el analista pasa a la e%aluaci!n de la informaci!n suplementaria< =ecnologa para construir el sistema. Mecursos especiales de desarrollo $ fa.ricaci!n necesarios. 8mites de presupuesto $ de planificaci!n temporal. Si el nue%o sistema es un producto a desarrollar para %enderlo a mucAos clientes9 se de.e anali2ar< >Cu)l es el mercado potencial del producto@ >C!mo es comparati%amente este producto con los de la competencia@ >?u/ posici!n ocupa este producto en la lnea general de producci!n de la compa1a@ &l an)lisis de re+uisitos permite al ingeniero del software *analista, la definici!n del software $ construir los modelos de los dominios de datos9 funcional $ de comportamiento +ue %an a ser tratados por el software. &l an)lisis de re+uisitos proporciona modelos al dise1ador del software +ue pueden traducirse en el dise1o de datos9 ar+uitect!nico9 de interfa2 $ procedimental. &l an)lisis de re+uisitos del software puede di%idirse en cinco )reas< Meconocimiento del pro.lema &%aluaci!n $ sntesis 'odelado &specificaci!n Me%isi!n. &l analista estudia la especificaci!n del sistema. &s importante entender el software en el conte;to de un sistema $ re%isar el )m.ito del software +ue se emple! para generar las estimaciones de la planificaci!n. Se de.e esta.lecer la comunicaci!n para el an)lisis de manera +ue nos garantice el reconocimiento del pro.lema. &l o.4eti%o del analista es el reconocimiento de los elementos .)sicos del pro.lema tal $ como los perci.e el usuario o el cliente. &n la e%aluaci!n del pro.lema $ la sntesis de la soluci!n el analista de.e definir todos los o.4etos de datos o.ser%a.les e;ternamente9 e%aluar el flu4o $ contenido de la informaci!n9 definir $ ela.orar todas las funciones del software9 entender el comportamiento del software en el conte;to de sistema. &stas tareas sir%en para descri.ir el pro.lema de manera +ue se pueda sinteti2ar un enfo+ue o soluci!n glo.al. 0urante la acti%idad de e%aluaci!n $ sntesis de la soluci!n9 el analista crea modelos del sistema para entender el flu4o de datos $ de control9 el tratamiento funcional. &n esta etapa no es posi.le una especificaci!n detallada del sistema9 el cliente puede no estar seguro de lo +ue +uiere9 el desarrollador puede no estar seguro de +ue un enfo+ue especfico consiga apropiadamente el funcionamiento $ rendimiento adecuados.
1

Cna %e2 +ue se Aan identificado las metas glo.ales9 el analista pasa a la e%aluaci!n de la informaci!n suplementaria< >&;iste la tecnologa para construir el sistema@ >?u/ recursos especiales de desarrollo $ fa.ricaci!n ser)n necesarios@ >?u/ lmites se Aan puesto al presupuesto $ a la planificaci!n temporal@ Si el nue%o sistema es un producto a desarrollar para %enderlo a mucAos clientes9 se plantean adem)s las siguientes cuestiones< >Cu)l es el mercado potencial del producto@ >C!mo es comparati%amente este producto con los de la competencia@ >?u/ posici!n ocupa este producto en la lnea general de producci!n de la compa1a@ 8a informaci!n reunida durante el paso de identificaci!n de necesidades es especificada en un documento conceptual del sistema% &l documento conceptual original es preparado a %eces por el cliente antes de las reuniones con el analista. In%aria.lemente9 la comunicaci!n clienteNanalista origina modificaciones en el documento. 8a t/cnica de an)lisis m)s usada para cu.rir el Aueco de comunicaci!n entre el cliente $ el desarrollador $ para empe2ar el proceso de comunicaci!n es lle%ar a ca.o una reuni!n o entre%ista preliminar. &l primer con4unto de cuestiones de conte;to li.re se enfoca so.re el cliente9 los o.4eti%os generales $ los .eneficios esperados. #or e4emplo9 el analista podra preguntar< >?ui/n est) detr)s de la solicitud de este tra.a4o@ >?ui/n utili2ar) la soluci!n@ >Cu)l ser) el .eneficio econ!mico del /;ito de una soluci!n@ >(a$ alguna otra alternati%a para la soluci!n +ue necesita@

&l siguiente con4unto de preguntas permite al analista o.tener un me4or entendimiento del pro.lema $ al cliente comentar sus opiniones so.re la soluci!n< >C!mo caracteri2ara una E.uenaF salida *resultado, generada para una .uena soluci!n@ >A +u/ tipo de pro.lema*s, %a dirigida esta soluci!n@ >#uede mostrarme *o descri.irme, el entorno en +ue se utili2ar) la soluci!n@ >(a$ aspectos o restricciones especiales del rendimiento +ue afecten a la manera de enfocar la soluci!n@

&l :ltimo con4unto de preguntas se concentra en la eficacia de la reuni!n. Gauge $ Lein.erg las denominan E'etaNpreguntasF $ proponen la siguiente lista *a.re%iada,< >&s usted la persona adecuada para responder a estas preguntas@ >Sus respuestas son EoficialesF@ >Son adecuadas mis preguntas para el pro.lema +ue tiene ustedO@ >&sto$ preguntando demasiado@ >(a$ alguien m)s +ue pueda proporcionar informaci!n adicionalO@ >(a$ algo m)s +ue de.era preguntarle@

25

&stas preguntas *$ otras, a$udar)n a Eromper el AieloF e iniciar la comunicaci!n tan esencial para el /;ito del an)lisis. #ero el formato de reuni!n tipo Epregunta $ respuestaF no es un enfo+ue +ue Aa$a tenido mucAo /;ito. 0e AecAo9 esta sesi!n de preguntas $ respuestas de.era emplearse solamente en el primer encuentro $ sustituirse despu/s por una modalidad +ue com.ine elementos de resoluci!n del pro.lema9 negociaci!n $ especificaci!n. (.$ E t/#"o #e la 2"a3"l"#a# =odos los pro$ectos son posi.les en caso de tener infinitos recursos $ tiempo. 0esafortunadamente el desarrollo de un sistema .asado en computadoras es mu$ pro.a.le +ue e;ista escase2 de recursos $ de fecAas de entrega. #or lo +ue es necesario e%aluar la %ia.ilidad de un pro$ecto cuanto antes. 8a %ia.ilidad $ el an)lisis de riesgo est)n relacionados de mucAas maneras. Si el riesgo del pro$ecto es alto9 la %ia.ilidad de producir software de calidad se reduce. Anali2aremos lo siguiente< @"a3"l"#a# eco'1%"ca. &s la e%aluaci!n de los costos de desarrollo9 con relaci!n a los ingresos netos o .eneficios o.tenidos del sistema desarrollado. @"a3"l"#a# t,c'"ca. &s el an)lisis $ estudio de funciones9 rendimiento $ restricciones +ue puedan afectar la reali2aci!n de un sistema acepta.le. @"a3"l"#a# le*al. &s la determinaci!n de cual+uier posi.ilidad de infracci!n9 %iolaci!n o responsa.ilidad legal en +ue se podra incurrir al desarrollar el sistema. Alter'at"2a . Cna e%aluaci!n de los enfo+ues alternati%os del desarrollo del sistema.

Qo es necesario un estudio de %ia.ilidad para sistemas en +ue la 4ustificaci!n econ!mica es o.%ia9 el riesgo t/cnico es .a4o9 se esperan pocos pro.lemas legales $ no e;iste ninguna alternati%a ra2ona.le. 8a 4ustificaci!n econ!mica es generalmente la consideraci!n fundamental para la ma$ora de los sistemas. Inclu$e una amplia gama de aspectos a tener en cuenta como son el an)lisis de costesD.eneficios9 las estrategias de ingresos de la empresa a largo pla2o9 el impacto en otros productos o centros de .eneficios9 costo de recursos necesarios para el desarrollo $ crecimiento potencial del mercado. 8a %ia.ilidad tecnol!gica es frecuentemente el )rea m)s difcil de %alorar en esta etapa del proceso de ingeniera del producto. Como los o.4eti%os9 funciones $ rendimiento son poco claros9 cual+uier cosa parece posi.le si se Aacen las suposiciones correctas. &s esencial +ue el proceso de an)lisis $ definici!n se realice en paralelo con una %aloraci!n de la %ia.ilidad t/cnica. 0e esta manera se pueden 4u2gar especificaciones concretas a medida +ue se esta.lecen.

21

8as consideraciones +ue est)n asociadas normalmente con la %ia.ilidad t/cnica son< R"e *o #e #e arrollo. >#uede dise1arse el elemento del sistema de manera +ue se consigan la funci!n $ rendimiento necesarios dentro de las restricciones descu.iertas durante el an)lisis@ D" &o'"3"l"#a# #e rec/r o . >=enemos disponi.le una plantilla cualificada para desarrollar el elemento del sistema en cuesti!n@ >=enemos disponi.les otros recursos necesarios *Aardware $ software, para construir el sistema@ Tec'olo*!a. >(a progresado la tecnologa respecti%a Aasta un punto +ue sea capa2 de soportar el sistema@ 8a %ia.ilidad legal comprende una gama mu$ amplia de aspectos +ue inclu$en contratos9 responsa.ilidades legales9 infracciones $ un mont!n de trampas frecuentemente desconocidas para el personal t/cnico. &l grado con +ue se consideran las alternati%as est) a menudo limitado por restricciones de tiempo $ costesB sin em.argo9 no de.era despreciarse una %ariaci!n legtima por no estar Esu.%encionadaF. &l estudio de %ia.ilidad es re%isado primero por el 4efe del pro$ecto *para %alorar la fia.ilidad del contenido, $ por la direcci!n *para %alorar el estado del pro$ecto,. &l estudio de.era concluir en una decisi!n Eadelante D a.andonamosF. (.( A'>l" " t,c'"co y eco'1%"co. Cna informaci!n importante contenida en un estudio de %ia.ilidad es el an)lisis de costoD .eneficio< una %aloraci!n de la 4ustificaci!n econ!mica para un pro$ecto de sistema .asado en computadora. &l an)lisis costes .eneficios determina los costes para el desarrollo del pro$ecto $ los pondera con los .eneficios tangi.les *medi.les directamente en dinero, $ .eneficios intangi.les del sistema. &l an)lisis costoD.eneficio es complicado por criterios +ue %aran con las caractersticas del sistema a desarrollar9 el tama1o relati%o del pro$ecto $ los .eneficios esperados de la in%ersi!n como parte del plan estrat/gico de la compa1a. Adem)s9 mucAos .eneficios o.tenidos de los sistemas .asados en computadora son intangi.les *por e4emplo9 me4or calidad de dise1o gracias a una optimi2aci!n frecuente9 ma$or satisfacci!n del cliente gracias al control programa.le $ me4ores decisiones de negocio gracias a los datos de %entas preanali2ados $ reformateados,. 8as comparaciones cuantitati%as directas pueden ser difciles de conseguir. 0urante el an)lisis t/cnico9 el analista e%al:a los principios t/cnicos del sistema al mismo tiempo +ue se recoge informaci!n adicional so.re el rendimiento9 fia.ilidad9 caractersticas de mantenimiento $ producti%idad.

22

&l an)lisis t/cnico empie2a con una %aloraci!n de la %ia.ilidad t/cnica del sistema propuesto. >?u/ tecnologas se re+uieren para lograr el funcionamiento $ rendimiento del sistema@ >?u/ nue%os materiales9 m/todos9 algoritmos o procesos se necesitan $ cu)l es su riesgo de desarrollo@ >C!mo afectar)n estos aspectos tecnol!gicos a los costes@

(.) .o#ela#o #e la ar?/"tect/ra #el " te%a. 8os sistemas .asados en computadora pueden moderarse como la transformaci!n de la informaci!n empleando una ar+uitectura del tipo entradaNprocesoNsalida. #ara desarrollar el modelo de sistema9 se emplea un es+uema de ar+uitectura9 donde el ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del es+uema< *1, Interfa2 de usuario9 *2, entrada9 *3, tratamiento $ control del sistema9 *4, salida $ *5, mantenimiento $ autocompro.aci!n. Como casi todas las t/cnicas de modelado usadas en la ingeniera del software $ de sistemas9 el es+uema de ar+uitectura permite al analista crear una 4erar+ua en detalle. &n la parte alta de la 4erar+ua reside el diagrama de conte;to de la ar+uitectura *0CA,. &l diagrama de conte;to Eesta.lece el lmite de informaci!n entre el sistema +ue se est) implementando $ el entorno en +ue %a a operarF. &s decir9 el 0CA define todos los suministradores e;ternos de informaci!n +ue emplea el sistema9 todos los consumidores e;ternos de informaci!n creados por el sistema $ todas las entidades +ue se comunican a tra%/s de la interfa2 o reali2an mantenimiento $ autocompro.aci!n. &l ingeniero de sistemas refina el diagrama de conte;to de ar+uitectura con m)s detalle9 $ se identifican los su.sistemas principales +ue permiten funcionar al sistema. (.5 E &ec"f"cac"1' #el " te%a. 8as especificaciones del sistema se registran en un documento +ue sir%e de .ase para ingeniera Aardware9 software9 .ase de datos9 e ingeniera (umana. &n este documento se descri.en las funciones $ rendimiento de un sistema .asado en computadoras $ las dificultades +ue se pueden presentar durante su desarrollo. Al concluir la etapa del an)lisis se reali2an las especificaciones de los re+uisitos del software. #uede decirse +ue un pro$ecto de desarrollo de un sistema de informaci!n comprende %arios pasos durante la etapa del an)lisis9 el cual facilita traducir las necesidades del cliente en un modelo de sistema +ue Aace uso de %arios componentes< software9 Aardware9 personas9 .ase de datos9 documentaci!n $ procedimientos

23

(.7 Creac"1' #e &rotot"&o #el oftware. &l an)lisis Aa$ +ue Aacerlo independientemente del paradigma de ingeniera del software +ue se apli+ue9 sin em.argo9 la forma +ue toma este an)lisis %ara. &n algunos casos es posi.le aplicar los principios operati%os del an)lisis $ o.tener un modelo de software del +ue se pueda desarrollar un dise1o. &n otras situaciones9 se reali2an recopilaciones de re+uisitos9 se aplican los principios del an)lisis $ se constru$e un modelo del software a fa.ricar denominado prototipo para +ue lo %alore el cliente $ el desarrollador. 7inalmente9 Aa$ circunstancias +ue re+uieren la construcci!n de un prototipo al comien2o del an)lisis9 $a +ue el modelo es el :nico medio a tra%/s del cual se pueden o.tener efica2mente los re+uisitos. &l modelo e%oluciona despu/s Aacia la producci!n del software. &l paradigma de creaci!n de prototipos puede ser cerrado o a.ierto. &l enfo+ue cerrado se denomina a menudo prototipo desec2a!le% &ste prototipo sir%e :nicamente como una .asta demostraci!n de los re+uisitos. 0espu/s se desecAa9 $ se Aace una ingeniera del software con un paradigma diferente. Cn enfo+ue a.ierto9 denominado prototipo evolutivo, emplea el prototipo como primera parte de una acti%idad de an)lisis a la +ue seguir) el dise1o $ la construcci!n. &l prototipo del software es la primera e%oluci!n del sistema terminado. Antes de poder elegir un enfo+ue a.ierto o cerrado9 es necesario determinar si se puede crear un prototipo del sistema a construir. &n general9 cual+uier aplicaci!n +ue cree pantallas %isuales din)micas9 interact:e intensamente con el ser Aumano9 o demande algoritmos de procesamiento de com.inaciones +ue de.an crearse de manera progresi%a9 es un .uen candidato para la creaci!n de un prototipo. Sin em.argo9 estas )reas de aplicaci!n de.en ponderarse con la comple4idad de la aplicaci!n. Si una aplicaci!n candidato *una con las caractersticas rese1adas anteriormente, %a a re+uerir el desarrollo de decenas de miles de lneas de c!digo antes de poder reali2ar cual+uier funci!n demostra.le9 es mu$ pro.a.le +ue sea demasiado comple4a para crear un prototipo. Si se puede Aacer una partici!n a su comple4idad9 puede ser posi.le crear prototipos de porciones del software. Como el cliente de.e interactuar con el prototipo en fases posteriores9 es esencial +ue *1, se destinen recursos del cliente a la e%aluaci!n $ refinamiento del prototipo9 $ *2, el cliente sea capa2 de tomar decisiones inmediatas so.re los re+uisitos. &;iste un con4unto de seis cuestiones +ue a$udar)n en la selecci!n del enfo+ue de creaci!n de prototipos< 1. >&ntiende el cliente $ el desarrollador el dominio de la aplicaci!n para la +ue se %a a construir el software@ 2. >Se puede modelar el pro.lema@ 3. >&st) el cliente suficientemente seguro de los re+uisitos .)sicos del sistema@ 4. >&st)n suficientemente esta.lecidos los re+uisitos $ tienen posi.ilidad de ser ra2ona.lemente esta.les@ 5. >(a$ re+uisitos am.iguos@

24

6. >(a$ contradicciones en los re+uisitos@ 1.) D" eAo #e " te%a &l dise1o se Aa descrito como un proceso multifase en el +ue se sinteti2an representaciones de la estructura de datos9 estructura del programa9 caractersticas de la interfa2 $ detalles procedimentales desde los re+uisitos de la informaci!n. &l dise1o del software es el n:cleo t/cnico del proceso de ingeniera del software $ se aplica independientemente del paradigma de desarrollo utili2ado. Cada uno de los elementos del modelo de an)lisis proporciona informaci!n necesaria para crear un modelo de dise1o. 8os re+uisitos del software9 manifestados por los datos $ los modelos funcionales $ de comportamiento9 componen la fase de dise1o. 'ediante el empleo de uno de los m/todos de dise1o la fase de dise1o produce< 0ise1o de datos 0ise1o ar+uitect!nico 0ise1o de interfa2 0ise1o procedimental.

1.).1 D" eAo #e #ato . &l dise6o de datos es la primera *$ alguien dira +ue la m)s importante, de las cuatro acti%idades de dise1o +ue se lle%an a ca.o durante la ingeniera del software. &l impacto de la estructura de datos en la estructura del programa $ la comple4idad procedimental Aace +ue el dise1o de los datos tenga una profunda influencia en la calidad del software. 8os conceptos de ocultaci!n de informaci!n $ a.stracci!n de datos proporcionan el fundamento para un enfo+ue del dise1o de datos. &l proceso de dise1o de datos lo resume Lasserman JLAS-5K< 8a acti%idad principal del dise1o de datos es seleccionar representaciones l!gicas de o.4etos de datos *estructuras de datos, identificadas durante la fase de definici!n $ especificaci!n de re+uisitos. &l proceso de selecci!n puede incluir el an)lisis de estructuras alternati%as para determinar el dise1o m)s efica2 o puede incluir simplemente el empleo de un con4unto de m!dulos *un Epa+ueteF, +ue proporcione las operaciones deseadas so.re alguna representaci!n de un o.4eto. Cna acti%idad relacionada importante durante el dise1o es identificar a+uellos m!dulos del programa +ue de.en operar directamente so.re las estructuras de datos l!gicas. 0e esta manera se puede restringir el alcance de efecto de las decisiones indi%iduales so.re el dise1o de datos.

25

Independientemente de las t/cnicas de dise1o +ue se emplean9 datos .ien dise1ados pueden conducir a una me4or estructura $ modularidad del programa9 $ a una menor comple4idad procedimental. Lasserman Aa propuesto un con4unto de principios +ue pueden emplearse para especificar $ dise1ar datos. &n realidad9 el dise1o de datos empie2a durante la creaci!n del modelo de an)lisis. Mecordando +ue el an)lisis de re+uisitos $ el dise1o a menudo se solapan9 consideramos el siguiente con4unto de principios JLAS-5K para la especificaci!n de datos< 1. 8os principios del an)lisis sistem)tico aplicados a la funci!n $ al comportamiento de.eran aplicarse tam.i/n a los datos. =odas las estructuras de datos $ las operaciones a lle%ar a ca.o en cada una de ellas de.eran estar claramente identificadas. 2. Se de.era esta.lecer un diccionario de datos $ usarlo para definir el dise1o de los datos $ del programa. 3. 8as decisiones de dise1o de datos de .a4o ni%el de.eran de4arse para el final del proceso de dise1o. 4. 8a representaci!n de las estructuras de datos de.eran conocerla s!lo a+uellos m!dulos +ue de.an Aacer uso directo de los datos contenidos dentro de la estructura. 5. 0e.era desarrollarse una .i.lioteca de estructuras de datos :tiles $ de las operaciones +ue se les pueden aplicar. 8as estructuras de datos $ las operaciones de.eran considerarse como recursos para el dise1o del software. 6. Cn dise1o del software $ un lengua4e de programaci!n de.eran soportar la especificaci!n $ reali2aci!n de los tipos a.stractos de datos. &l dise1o de datos transforma el modelo de dominio de la informaci!n9 creado durante el an)lisis9 en las estructuras de datos necesarias para implementar el software. 8os o.4etos de datos $ las relaciones definidas en el diagrama entidadNrelaci!n $ el contenido detallado de datos del diccionario de datos proporciona la .ase para la acti%idad de dise1o de datos. 1.).$ D" eAo ar?/"tect1'"co &l o.4eti%o del dise6o ar1uitect'nico es desarrollar una estructura de programa modular $ representar las relaciones de control entre los m!dulos. Adem)s9 el dise1o ar+uitect!nico com.ina la estructura del programa $ las estructuras de datos9 definiendo interfaces +ue permiten el flu4o de datos a tra%/s del programa. &l dise1o orientado al flu4o de datos es un m/todo de dise1o ar+uitect!nico +ue permite una c!moda transici!n desde el modelo de an)lisis a una descripci!n del dise1o de la estructura del programa. 8a transici!n desde el flu4o de informaci!n *representado como un diagrama de flu4o de datos, a una estructura se reali2a en un proceso de cinco pasos< *1, se esta.lece el tipo de flu4o de informaci!nB *2, se indican los lmites del flu4oB *3, se con%ierte el 070 en la estructura del programaB *4, se define la 4erar+ua de control descomponi/ndola mediante
26

particionamiento3 y *5, se refina la estructura resultante usando medidas $ Aeursticas de dise1o. &l tipo de flu4o de informaci!n es lo +ue determina el m/todo de con%ersi!n re+uerido en el paso 3. 1.).( D" eAo #e la "'terfaB &l dise1o ar+uitect!nico proporciona al ingeniero del software una imagen de la estructura del programa. Como el plano para una casa9 el dise1o general no est) completo sin la representaci!n de las puertas9 %entanas $ cone;iones a ser%icios para agua9 electricidad $ tel/fono *sin mencionar la tele%isi!n por ca.le,. 8as Epuertas9 %entanas $ cone;iones a ser%iciosF para el software de computadora componen el dise1o de la interfaz del sistema. &l dise1o de la interfa2 se concentra en tres )reas importantes< *1, el dise1o de interfaces entre los m!dulos softwareB *2, el dise1o de interfaces entre el software $ otros productores $ consumidores no Aumanos de informaci!n *por e4emplo9 otras entidades e;ternas,B $ *3, el dise1o de la interfa2 entre el Aom.re *&4. el usuario, $ la computadora. &l dise1o de la interfa2 de usuario tiene tanto +ue %er con el estudio de las personas como con los aspectos de la tecnologa. >?ui/n es el usuario@ >C!mo aprende el usuario a interactuar con el nue%o sistema .asado en computadora@>C!mo interpreta el usuario la informaci!n producida por el sistema@ >?u/ es lo +ue espera el usuario del sistema@ Sstas son unas pocas de las cuestiones +ue de.en Aacerse $ contestarse como parte del dise1o de la interfa2 de usuario. &l proceso general para dise1ar la interfa2 de usuario empie2a con la creaci!n de diferentes modelos de funci!n del sistema *tal $ como se perci.e desde fuera,. Se definen las tareas orientadas al Aom.re $ a la m)+uina9 re+ueridas para conseguir la funci!n del sistemaB se consideran los aspectos de dise1o aplica.les a todos los dise1os de interfa2B se usan Aerramientas para crear el prototipo e implementar el modelo de dise1o $ se e%al:a la calidad del resultado. &l dise1o de interfa2 descri.e c!mo se comunica el software consigo mismo9 con los sistemas +ue operan con /l $ con los operadores +ue lo emplean. Cna interfa2 implica un flu4o de informaci!n. #or tanto9 los diagramas de flu4o de datos $ control proporcionan la informaci!n necesaria para el dise1o de la interfa2. ).) D" eAo &roce#"%e'tal &l dise6o procedimental se reali2a despu/s de los dise1os de datos9 ar+uitect!nico $ de interfa2. &n un mundo ideal9 la especificaci!n procedimental necesaria para definir los detalles de los algoritmos se e;presara en un lengua4e natural. 0espu/s de todo9 todos los miem.ros de una organi2aci!n de desarrollo de software Aa.lan un lengua4e natural *en

2"

teora9 al menos,9 las personas fuera del mundo del software podran entender me4or la especificaci!n9 $ no sera necesario un nue%o aprendi2a4e. 0esgraciadamente9 Aa$ un pe+ue1o pro.lema. &l dise1o procedimental de.e especificar los detalles procedimentales sin am.igRedades9 $ la falta de am.igRedad en el lengua4e natural no es natural. Con un lengua4e natural podemos escri.ir un con4unto de pasos procedimentales de demasiadas formas diferentes. 8a importancia del dise1o del software se puede decir con una sola pala.ra< calidad. &l dise1o es el lugar donde se fomenta la calidad en el desarrollo del software. &l dise1o nos proporciona representaciones del software en las +ue se pueden %alorar la calidad. &l dise1o es la :nica manera de traducir con precisi!n los re+uisitos del cliente en un sistema o producto software &l dise1o del software es un proceso $ un modelo a la %e2. &l modelo del dise1o es el e+ui%alente a los planos de una casa para un ar+uitecto. &mpie2a representando la totalidad de lo +ue se %a a construir *e4emplo9 una representaci!n tridimensional de la casa, $ lentamente lo %a refinando para proporcionar una directri2 para construir cada detalle 1.).) Ar?/"tect/ra #el oftware 8a ar+uitectura del software contri.u$e a Ela estructura glo.al del software del sistemaF. &n su forma m)s simple9 la ar+uitectura es la estructura 4er)r+uica de los componentes del programa *m!dulos,9 la manera de interactuar de estos componentes9 $ la estructura de los datos usados por estos componentes. 8a relaci!n de control entre los m!dulos se e;presa de la siguiente manera< un m!dulo +ue controla otro m!dulo se dice +ue es superior a /lB in%ersamente9 un m!dulo controlado por otro se dice +ue es inferior. 8a 4erar+ua de control tam.i/n representa dos caractersticas sutilmente diferentes de la ar+uitectura del software< %isi.ilidad $ conecti%idad. 8a %isi.ilidad indica el con4unto de componentes de programa +ue pueden in%ocarse o usarse sus datos por un componente dado9 incluso cuando esto se reali2a indirectamente. 8a conecti%idad indica el con4unto de componentes +ue son in%ocados directamente o usados sus datos por un componente determinado. 8a modularidad 4uega un papel importante en el dise1o9 se Aa con%ertido en un enfo+ue admitido en todas las disciplinas de la ingeniera. Cn dise1o modular reduce la comple4idad9 facilita los cam.ios $ Aace m)s f)cil la implementaci!n al fomentar el desarrollo en paralelo de diferentes partes de un sistema. 1.).7 Cr"ter"o &ara e2al/ar la cal"#a# #el #" eAo. 0e.e tener una estructura 4er)r+uica +ue Aaga un uso inteligente del control entre los componentes del software.

2-

0e.e ser modular9 o sea Aacer una partici!n l!gica del software en elementos +ue realicen funciones $ su.funciones especificas. 0e.e contener a.stracciones de datos $ procedimientos. 8os m!dulos de.en presentar caractersticas de funcionamiento independiente. 8as interfaces no de.en ser comple4as para las cone;iones entre los m!dulos $ el entorno e;terior. 0e.e Aacerse usando un m/todo seg:n la informaci!n o.tenida durante el an)lisis de re+uisitos de Software.

1.5 De arrollo #e oftware 8a fase de desarrollo se centra en el c!mo9 durante el desarrollo un ingeniero del software intenta definir c!mo Aan de dise1arse las estructuras de datos9 c!mo Aa de implementarse la funci!n como una ar+uitectura del software9 c!mo Aan de implementarse detalles procedimentales9 c!mo Aan de caracteri2arse las interfaces9 c!mo Aa de traducirse el dise1o en un lengua4e de programaci!n $ c!mo Aa de reali2arse la prue.a. 8os encargados de desarrollar software pueden instalar software comprado a terceros o escri.ir programas dise1ados a la medida del solicitante. 8a elecci!n depende del costo de cada alternati%a9 del tiempo disponi.le para escri.ir el software $ de la disponi.ilidad de los programadores. 8os programadores son responsa.les de la documentaci!n de los programas $ de e;plicar su codificaci!n9 esta documentaci!n es esencial para pro.ar el programa $ Aacer el mantenimiento. 1.7 Pr/e3a #el oftware 8uego de generar el c!digo se comien2an las prue.as del programa9 este paso se centra en los procesos l!gicos internos del software9 asegurando +ue todas las sentencias $ procesos e;ternos funcionales se Aan compro.ado9 se reali2an las prue.as para la detecci!n de errores $ el sentirse seguro de +ue las entradas produ2can resultados reales de acuerdo con los resultados re+ueridos. 8a prue.a a.arca un con4unto de acti%idades +ue se pueden planificar por adelantado $ lle%ar a ca.o sistem)tica. Se de.e definir en el proceso de la ingeniera del software una plantilla para la prue.a del software< es decir9 un con4unto de pasos en los +ue podamos situar los m/todos especficos de dise1o de casos de prue.a. &;isten %arias estrategias de prue.a del software9 todas proporcionan al desarrollador de software una plantilla para la prue.a $ tienen las caractersticas generales siguientes< 8a prue.a comien2a en el ni%el de m!dulo $ tra.a4a EAacia fueraF9 Aacia la integraci!n de todo el sistema .asado en computadora.
2

Seg:n el momento son apropiadas diferentes t/cnicas de prue.a. 8a prue.a la lle%a a ca.o el responsa.le del desarrollo del software $ *para grandes pro$ectos, un grupo independiente de prue.as.

Cna estrategia de prue.a del software de.e incluir prue.as de .a4o ni%el +ue %erifi+uen +ue todos los pe+ue1os segmentos de c!digo fuente se Aan implementado correctamente9 as como prue.as de alto ni%el +ue %aliden las principales funciones del sistema frente a los re+uisitos del cliente. Cna estrategia de.e proporcionar una gua al profesional $ proporcionar un con4unto de Aitos para el 4efe de pro$ecto. 1.7.1 O34et"2o #e la &r/e3a. 8a prue.a es un proceso de e4ecuci!n de un programa con la intenci!n de descu.rir un error. Cn .uen caso de prue.a es a+uel +ue tiene una alta pro.a.ilidad de mostrar un error no descu.ierto Aasta entonces. Cna prue.a tiene /;ito si descu.re un error no detectado Aasta entonces.

1.7.$ @er"f"cac"1' y 2al"#ac"1' 8a prue.a del software es un elemento de un tema m)s amplio +ue9 a menudo9 se le conoce como %erificaci!n $ %alidaci!n. 8a %erificaci!n se refiere al con4unto de acti%idades +ue aseguran +ue el software implementa correctamente una funci!n especfica. 8a %alidaci!n se refiere a un con4unto diferente de acti%idades +ue aseguran +ue el software construido se a4usta a los re+uisitos del cliente. 1.8 I%&la'tac"1' 8a implantaci!n es la :ltima etapa del desarrollo de sistemas. &s el resultado de instalar el software $ e+uipamiento nue%o9 $ lle%ar a ca.o el proceso automati2ado. #ara implantar el sistema de informaci!n Aa$ +ue estar .ien seguro +ue el sistema sea operacional9 o sea9 +ue funcione de acuerdo a los re+uerimientos del an)lisis. A pesar de +ue el sistema est/ .ien dise1ado $ cuente con interfaces adecuadas9 es importante para la implantaci!n reali2ar una .uena capacitaci!n a todos los usuarios para su puesta en e;plotaci!n $ garanti2ar el mantenimiento. 1.8.1 Ca&ac"tac"1' #e / /ar"o #el " te%a 0urante la fase de implementaci!n es responsa.ilidad del analista la capacitaci!n de los usuarios del sistema comen2ando desde las personas +ue capturan los datos Aasta a+uellos
35

+ue toman las decisiones sin usar una computadora. &s recomenda.le no incluir durante el entrenamiento a grupos de personas de Aa.ilidad e intereses de tra.a4o diferentesB $a +ue am.os grupos +uedaran perdidos. A pesar de +ue una empresa puede contratar los ser%icios de instructores e;ternos9 el analista es la persona +ue puede ofrecer la me4or capacitaci!n de.ido a +ue conoce al usuario del sistema $ al sistema me4or +ue cual+uier otro. Qo o.stante la organi2aci!n puede contratar otros ser%icios de capacitaci!n como son< 6endedores< Son a+uellos +ue proporcionan capacitaci!n gratuita fuera de la empresa de uno o dos das. Instructor pagado e;ternamente< Son a+uellos +ue pueden ense1ar todo acerca de las computadoras9 en caso necesario para algunos usuarios. Instructores en casa< &st)n familiari2ados con el personal $ pueden adecuar los materiales a sus necesidades9 pero le faltara e;periencia en Sistemas de Informaci!n +ue es realmente la necesidad del usuario.

1.8.$ E2al/ac"1' #el " te%a. 8a e%aluaci!n del sistema se lle%a a ca.o para identificar puntos d/.iles $ fuertes del mismo. &sta e%aluaci!n se lle%a en cual+uiera de las siguientes dimensiones< E2al/ac"1' o&erac"o'al0 Se e%al:a la manera en +ue funciona el sistema9 facilidad de uso9 tiempo de respuesta ante una petici!n9 formatos en +ue se muestra la informaci!n de entradas $ salidas9 $ el ni%el de utilidad. I%&acto or*a'"Bac"o'al0 Se miden los .eneficios operacionales para la empresa en )reas tales como las finan2as9 eficiencia en el desempe1o la.oral e impacto competiti%o. Se e%al:a el impacto9 rapide2 $ organi2aci!n en el flu4o de informaci!n interna $ e;terna. De e%&eAo #el #e arrollo0 Se e%al:a el proceso de desarrollo adecuado considerando criterios como9 tiempo $ esfuer2o en el desarrollo de acuerdo al presupuesto $ est)ndares $ otros criterios de administraci!n de pro$ectos. Se reali2a la %aloraci!n de los m/todos $ Aerramientas usados en el desarrollo del sistema. 1.C .a'te'"%"e'to

31

&s l!gico +ue el software sufra cam.ios despu/s de ser entregado al cliente. Se producir)n cam.ios por+ue se Aan encontrado errores9 por+ue el software de.e adaptarse para a4ustarse a los cam.ios de su entorno e;terno o por+ue el cliente re+uiere me4oras funcionales o de rendimiento. 8a fase de mantenimiento se centra en el cam.io +ue %a asociado a la correcci!n de errores9 a las adaptaciones re+ueridas a medida +ue e%oluciona el entorno del software9 $ a cam.ios de.idos a las me4oras producidas por los re+uisitos cam.iantes del cliente. &sta fase %uel%e a aplicar los pasos de las fases de definici!n $ de desarrollo9 pero en el conte;to del software $a e;istente. 0urante la fase de mantenimiento se encuentran cuatro tipos de cam.ios< Correcc"1'. A pesar de lle%ar a ca.o las me4ores acti%idades de garanta de calidad9 es mu$ pro.a.le +ue el cliente descu.ra defectos en el software. &l mantenimiento correcti%o modifica el software para corregir los defectos. A#a&tac"1'. Con el paso del tiempo9 es pro.a.le +ue cam.ie el entorno original *e4emplo< C#C9 el sistema operati%o9 las reglas de empresa9 las caractersticas e;ternas de productos, para el +ue se desarroll! el software. &l mantenimiento adaptati%o produce modificaci!n en el software para acomodarlo a los cam.ios de su entorno e;terno. .e4ora. Conforme se utilice el software9 el clienteDusuario puede descu.rir funciones adicionales +ue %an a producir .eneficios. &l mantenimiento perfecti%o lle%a al software m)s all) de sus re+uisitos funcionales originales. Pre2e'c"1'. &l software de computadora se deteriora de.ido al cam.io9 $ por esto el mantenimiento pre%enti%o tam.i/n llamado reingeniera del software9 se de.e conducir para permitir +ue el software sir%a para las necesidades de los usuarios finales. &n esencia9 el mantenimiento pre%enti%o Aace cam.ios en programas de computadora a fin de +ue se puedan corregir9 adaptar $ me4orar m)s f)cilmente. &l mantenimiento aun+ue en tiempo fue despreciada su importancia9 es considerado en la actualidad uno de los pro.lemas m)s riguroso en el desarrollo del software. 'ucAos in%estigadores sugieren +ue el costo de mantenimiento m)s de la mitad de los costos $ recursos glo.ales del desarrollo total del software. 1.D Cal"#a# #el Software =odas las metodologas $ Aerramientas tienen un :nico fin +ue es producir software de gran calidad% #odemos considerar la calidad del software como< =La concordancia entre los re1uisitos funcionales y de rendimiento e&plcitamente esta!lecidos con los est"ndares de desarrollo e&plcitamente documentados y con las
32

caractersticas implcitas profesionalmente>%

1ue

se

espera

de

todo

software

desarrollado

8os re1uisitos del software son la .ase de las medidas de calidad. 8a falta de concordancia con los re+uisitos es una falta de calidad. 8os est)ndares o metodologas definen un con4unto de criterios de desarrollo +ue guan la forma en +ue se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre Aa.r) falta de calidad. &;isten algunos re1uisitos implcitos o e&pectativas +ue a menudo no se mencionan9 o se mencionan de forma incompleta *por e4emplo el deseo de un .uen mantenimiento, +ue tam.i/n pueden implicar una falta de calidad. Aseguramiento de calidad del software (Software Quality Assurance) &l aseguramiento de calidad del software es el conjunto de actividades planificadas y sistem"ticas necesarias para aportar la confianza en 1ue el producto (software) satisfacer" los re1uisitos dados de calidad% &l aseguramiento de calidad del software se dise1a para cada aplicaci!n antes de comen2ar a desarrollarla $ no despu/s. &l aseguramiento de calidad del software est) presente en< '/todos $ Aerramientas de an)lisis9 dise1o9 programaci!n $ prue.a. Inspecciones t/cnicas formales en todos los pasos del proceso de desarrollo del software. &strategias de prue.a multiescala. Control de la documentaci!n del software $ de los cam.ios reali2ados. #rocedimientos para a4ustarse a los est)ndares *$ de4ar claro cuando se est) fuera de ellos,. 'ecanismos de medida *m/tricas,. Megistro de auditorias $ reali2aci!n de informes.

1.D.1 Factore #e cal"#a# #el oftware 8a construcci!n de software de calidad re+uiere el cumplimiento de numerosas caractersticas. &ntre ellas se destacan< ficiencia< 8a eficiencia del software est) dada por la capacidad de Aacer un .uen uso de los recursos +ue manipula. ?ransporta!ilidad (8orta!ilidad)< 8a porta.ilidad es la facilidad con +ue un software puede ser transportado so.re diferentes sistemas fsicos $ l!gicos. @erifica!ilidad< 8a %erifica.ilidad es la facilidad de %erificaci!n de un software9 es la capacidad de soportar los procedimientos de %alidaci!n $ facilitar 4uegos de prue.as ! ensa$os de programas.

33

Integridad< 8a integridad es la capacidad de un software de proteger sus propios componentes contra los procesos +ue no tengan derecAo de acceso. )"cil de utilizar< Cn software es f)cil de utili2ar si se puede comunicar con /l de manera c!moda. 9orrecci'n< Capacidad de los productos de software de reali2ar e;actamente las tareas definidas en su especificaci!n. <o!ustez< Capacidad de los productos de software de funcionar incluso en condiciones anormales. &tensi!ilidad< 7acilidad +ue tienen los productos de adaptarse a cam.ios en su especificaci!n. #ara esto es .ueno seguir principios de dise1o simple $ descentrali2ado. <eutilizaci'n< Capacidad de los productos para ser reutili2ados en parte o en su totalidad en nue%as aplicaciones. 9ompati!ilidad< 7acilidad de los productos de ser com.inados con otros.

1.1E.$ 6"3l"o*raf!a. #ara profundi2ar los conocimientos ad+uiridos en este captulo9 puede consultar la siguiente literatura< #ressman M.< Ingeniera del Software. Cn enfo+ue pr)ctico. Cuarta &dici!n. 'c Graw (ill. 1 ". 'e$er B.< <eusa!le Software/ ?2e *ase A!ject Ariented 9omponent Li!rares, #renticeN(all9 1 5. JI&&& 3K I&&& &st)ndar Collection< Software &ngineering9 I&&& Standard 615.12N 59 I&&& 1 3. JLAS-5K Lasserman A< #rinciples of S$stematics 0ata 0esign and Implementation9 en Software 0esign =Aecni+ues *#ressman and Laserman ed., tercera edicion9 I&&& Computer Societ$ #ress9 1 -59 2-"N2 3.

5.$ 6"3l"o*raf!a. #ara profundi2ar los conocimientos ad+uiridos en este captulo9 puede consultar la siguiente literatura<

34

'odelado $ dise1o orientados a o.4etos. 'etodologa 3'= . #rentice (all. 1 Mum.augA9 Tim $ otros. 3.4ectN3riented 'odeling and 0esign. #rentice (all. 1 Mum.augA9 BlaAa9 et. al. 1.

An)lisis $ 0ise1o orientado a o.4etos con aplicaciones. Ben4aming Cummings 1 BoocA9 Grad$. Ingeniera del Software. Cn enfo+ue pr)ctico. 'c Graw (ill. 1 Moger #ressman. www.rational.com " Cuarta &dici!n

35