UNI VERSI DAD REGI ONAL AUTÓNOMA DE LOS

ANDES ‘ ‘ UNI ANDES’ ’

TE MA DEL DOCUMENTO:

CI CLO VS METODOLOGI A

ESTUDI ANTE: J ONATHAN I SRAEL SALGUERO FLORES.

DOCENTE: BERNABÉ ORTEGA

2015

Puyo- Past aza

Ci cl os de vi da de desarroll o de siste ma

Ci cl o de Vi da del Soft ware.

Un model o de ci cl o de vi da defi ne el estado de l as f ases a través de l as cual es se mueve un proyect o de desarroll o de soft ware.

El pri mer ci cl o de vi da del soft ware, "Cascada", f ue defi ni do por Wi nst on Royce a fi nes del 70. Desde ent onces muchos equi pos de desarroll o han segui do este model o. Si n e mbargo, ya desde 10 a 15 años atrás, el model o cascada ha si do suj et o a nu merosas críticas, debi do a que es restri cti vo y rígi do, l o cual dificulta el desarroll o de proyect os de soft ware moderno. En su l ugar, muc hos model os nuevos de ci cl o de vi da han si do propuest os, i ncl uyendo model os que pretenden desarroll ar soft ware más rápi da ment e, o más i ncre ment al ment e o de una f or ma más evol uti va, o precedi endo el desarrollo a escal a t ot al con al gún conj unt o de prot oti pos rápi dos. Defi ni ci ón de un Model o de Ci cl o de Vi da.

Un model o de ci cl o de vi da de soft ware es una vi sta de l as acti vi dades que ocurren durant e el desarroll o de soft ware, i ntent a det er mi nar el orden de l as et apas i nvol ucradas y l os criteri os de transi ci ón asoci adas entre estas etapas.

Un model o de cicl o de vi da del soft ware:

Descri be l as fases pri nci pal es de desarroll o de software.

Defi ne l as fases pri mari as esperadas de ser ej ecutadas durant e esas fases.

Ayuda a admi ni strar el progreso del desarroll o, y

Provee un espaci o de t rabaj o para l a defi ni ci ón de un det all ado proceso de

desarroll o de soft ware.

Así, l os model os por una parte sumi ni stran una guí a para l os i ngeni eros de soft ware con el fi n de ordenar l as di versas acti vi dades t écni cas en el proyect o, por otra parte su mi ni stran un marco para l a ad mi ni straci ón del desarroll o y el mant eni mi ent o, en el senti do en que per mi ten esti mar recursos, defi nir punt os de control i nter medi os, monit orear el avance, etc.

Al ternati vas de Model os de Ci cl o de Vi da. -

Model o Cascada. -

Est e es el más bási co de t odos l os model os, y si rve co mo bl oque de construcci ón para l os de más model os de ci cl o de vi da. La vi si ón del model o cascada del desarrol l o de soft ware es muy si mpl e; di ce que el desarroll o de soft ware puede ser a través de una secuenci a si mpl e de f ases. Cada f ase ti ene un conj unt o de met as bi en defi ni das, y l as acti vi dades dentro de una f ase contri buye a l a satisfacci ón de met as de esa f ase o qui zás a una

subsecuenci a de met as de l a f ase. Las fl echas muestran el fl uj o de i nf or maci ón entre l as fases. La fl echa de avance muestra el fl uj o nor mal . Las fl echas haci a atrás represent an l a retroali ment aci ón.

El model o de cicl o de vi da cascada, capt ura al gunos pri nci pi os bási cos:

Pl anear un proyect o antes de e mbarcarse en él. Defi ni r el co mport a mi ento ext erno deseado del si ste ma ant es de di señar su

arquitect ura i nterna. Docu ment ar l os resultados de cada acti vi dad. Di señar un siste ma ant es de codificarl o. Testear un siste ma después de construi rl o.

Model o de Ci cl o de Vi da Cascada.

Una de l as contri buciones más i mportant es del model o cascada es para l os ad mi ni stradores, posi bilitándol es avanzar en el desarroll o, aunque en una escal a muy brut a.

Model o Espi ral. -

El model o espi ral de l os procesos soft ware es un model o del ci cl o de met a-vi da. En est e model o, el esf uerzo de desarroll o es i terati vo. Tan pront o co mo uno co mpl eta un esf uerzo de desarroll o, otro co mi enza. Ade más, en cada desarroll o ej ecutado, puedes segui r est os cuatros pasos:

1. Det er mi nar qué qui eres lograr.

2. Det er mi nar l as rut as alternati vas que puedes t o mar para l ograr estas met as. Por cada una, anali zar l os ri esgos y resultados fi nal es, y sel ecci onar l a mej or.

3. Segui r la alternati va sel ecci onada en el paso 2.

4. Est abl ecer qué ti enes termi nado.

La di mensi ón radi al en l a fi gura refl ej a cost os acumul ati vos i ncurri dos en el proyect o.

Observe mos un escenari o parti cul ar. Di ga mos que en este proyect o, nosotros vi aj are mos a resol ver un conj unt o parti cul ar de probl e mas del cli ente. Durant e el pri mer vi aj e al rededor de l a espi ral, anali za mos l a sit uaci ón y det er mi na mos que l os mayores ri esgos son l a i nterf az del usuario. Después de un cui dadoso análisis de l as f or mas alternati vas de di recci onar est o ( por ej e mpl o, construi r un si ste ma y esperar l o mej or, escri bi r una especificaci ón de requerimi ent os y esperar que el cli ente l o enti enda, y construi r un prot oti po), deter mi na mos que el mej or curso de acci ón es construi r un prot oti po.

Lo reali za mos. Luego provee mos el prot oti po al cli ente qui en nos pr ovee con retroali ment aci ón útil. Ahora, co menza mos el segundo vi aj e al rededor de l a espi ral. Est e ti e mpo deci di mos que el mayor ri esgo es ese mi edo a que muchos nuevos requeri mi ent os co mi encen a aparecer sólo después de que el si stema sea despl egado. Anali ce mos l as rut as alternati vas, y deci di mos que l a mej or aproxi maci ón es construi r un i ncre ment o del si ste ma que sati sfaga sólo l os requeri mi ent os mej or ent endi dos. Hagá mosl o ya. Después del despli egue, el cli ente nos provee de retroali ment aci ón que di rá si esta mos correct os con esos requeri mi ent os, pero 50 nuevos requeri mi ent os ahora se ori ginarán en l as cabezas de l os cli entes. Y el tercer vi aj e alrededor de l a espi ral comi enza.

El model o espi ral capt ura al gunos pri nci pi os bási cos: Deci di r qué probl e ma se qui ere resol ver antes de viaj ar a resol verl o. Exa mi nar tus múlti pl es alternati vas de acci ón y el egi r una de l as más convenientes. Eval uar qué ti enes hecho y qué ti enes que haber aprendi do después de hacer al go. No ser t an i ngenuo para pensar que el si ste ma que estás construyendo será " EL"

si ste ma que el cli ente necesita, y Conocer (co mprender) l os ni vel es de ri esgo, que tendrás que tol erar.

El model o espi ral no es una alternati va del model o cascada, ell os son compl et a ment e co mpati bl es.

Met odol ogí as de Desarroll o de Soft ware Ágil es

Con mucho, el desarroll o de soft ware es una acti vi dad caóti ca, frecuent e ment e

caracteri zada por l a f rase "codifica y corri ge". El soft ware se escri be con un pl an

subyacent e mí ni mo, y el di seño del si ste ma se adoqui na con muchas deci si ones a cort o

pl azo. Est o real ment e f unci ona muy bi en si el siste ma es pequeño, pero conf or me el

si ste ma crece ll ega a ser cada vez más difícil agregar nuevos aspect os al mis mo. Ade más

l os bugs ll egan a ser cada vez más f recuent es y más difícil es de corregi r. La seña tí pi ca de

tal si ste ma es una l arga f ase de pruebas después de que el si ste ma ha si do "co mpl etado".

Tal f ase l arga de pr uebas hace estragos con l os pl anes de pruebas y depurado l l egando a

ser i mposi bl e de i ncl ui r en el progra ma de trabaj o.

He mos vi vi do con este estil o de desarroll o por mucho ti e mpo, pero t a mbi én he mos t eni do

una alternati va desde hace mucho: Met odol ogí a. Las met odol ogí as i mponen un proceso

di sci pli nado sobre el desarroll o de soft ware con el fi n de hacerl o más predeci bl e y

efi ci ente. Lo hacen desarroll ando un proceso det allado con un f uerte énf asi s en pl anifi car

i nspi rado por otras di sci pli nas de l a i ngeni erí a.

Las met odol ogí as i ngeni eril es han estado presentes durant e mucho ti e mpo. No se han

di sti ngui do preci sa ment e por ser muy exitosas. Aún menos por su popul aridad. La críti ca

más f recuent e a estas met odol ogí as es que son burocráti cas. Hay t ant o que hacer para

segui r l a met odol ogí a que el rit mo ent ero del desarroll o se retarda.

Co mo una reacci ón a estas met odol ogí as, un nuevo grupo de met odol ogí as ha surgi do en

l os últi mos años. Durante al gún ti e mpo se conocían co mo met odol ogí as ligeras, pero el

tér mi no acept ado ahora es met odol ogí as ágil es. Para mucha gent e el encant o de est as

met odol ogí as ágil es es su reacci ón ant e l a burocraci a de l as met odol ogí as monu ment al es.

Est os nuevos mét odos buscan un j ust o medi o entre ni ngún proceso y de masi ado proceso,

proporci onando si mpl e ment e sufici ente proceso para que el esf uerzo val ga l a pena.

El resultado de t odo est o es que l os mét odos ágil es ca mbi an si gnificati va mente al gunos de

l os énf asi s de l os mét odos i ngeni eril es. La dif erenci a i nmedi ata es que son menos

ori ent ados al docu ment o, exi gi endo una canti dad más pequeña de docu ment aci ón para

una t area dada. De muchas maneras son más bi en ori ent ados al códi go: si gui endo un

ca mi no que di ce que l a parte i mportant e de l a docume nt aci ón es el códi go f uent e.

Si n e mbargo, éste no es el punt o i mportant e sobre l os mét odos ágil es. La f alta de

docu ment aci ón es un sí nto ma de diferenci as mucho más prof undas:

o Los mét odos ágil es son adapt abl es en l ugar de predi cti vos. Los mét odos

i ngeni eril es ti enden a i ntent ar pl anear una parte grande del proceso del soft ware en gran

det all e para un pl azo l argo de ti e mpo, est o f unci ona bi en hasta que l as cosas ca mbi an. Así

que su nat ural eza es resistirse al ca mbi o. Para l os mét odos ágil es, no obst ant e, el ca mbi o

es bi enveni do. I ntent an ser procesos que se adapt an y crecen en el ca mbi o, i ncl uso al

punt o de ca mbi arse ell os mi s mos.

o Los mét odos ágil es son ori entados a l a gent e y no ori ent ados al proceso. La met a

de l os mét odos i ngeni eriles es defi ni r un proceso que f unci onará bi en con cual qui era que

l o use. Los mét odos ágiles afir man que ni ngún proceso podrá nunca ma quill ar l as

habili dades del equi po de desarroll o, de modo que el papel del proceso es apoyar al equi po

de desarroll o en su trabajo. Explí cita ment e punt ual izan el trabaj ar a f avor de l a nat ural eza

hu mana en l ugar de en su contra y enf ati zan que el desarroll o de soft ware debe ser una

acti vi dad agradabl e.

En l as secci ones si gui ent es se verán estas dif erencias más en det all e, para di scerni r l o que

es un proceso adapt abl e y centrado en l a gent e, sus benefi ci os y desventaj as, y qué se

deberí a usar: sea como desarroll ador o como cli ente de soft ware.

¿ Qué es una Met odol ogí a Ágil?

Las Met odol ogí as Ágil es o ‘ ‘ligeras’ ’ constituyen un nuevo enf oque en el desarroll o de

soft ware, mej or acept ado por l os desarroll adores de e- proj ects que l as met odol ogí as

convenci onal es (I SO- 9000, CMM, etc) debi do a l a si mpli ci dad de sus regl as y prácti cas, su

ori ent aci ón a equi pos de desarroll o de pequeño t ama ño, su fl exi bili dad ant e l os ca mbi os y

su i deol ogí a de col aboración

Predi cti vo versus Adapt abl e

Separaci ón de Di seño y Construcci ón

La i nspi raci ón usual para las met odol ogí as han si do di sci pli nas co mo l as i ngeni erí as ci vil o

mecáni ca. Tal es di sci plinas enf ati zan que hay que pl anear ant es de construi r. Los

i ngeni eros trabaj an sobre una seri e de esque mas que i ndi can preci sa ment e qué hay que

construi r y co mo deben j unt arse estas cosas. Muchas deci si ones de di seño, co mo l a

ma nera de control ar l a carga sobre un puent e, se t oma n conf or me l os di buj os se producen.

Los di buj os se entregan ent onces a un grupo dif erent e, a menudo una co mpañí a dif erent e,

para ser construi dos. Se supone que el proceso de l a construcci ón segui rá l os di buj os. En l a

prácti ca l os construct ores se encuentran con al gunos probl e mas, pero ést os son

nor mal ment e poco i mportantes.

Co mo l os di buj os especifican l as pi ezas y cómo deben uni rse, act úan co mo l os

f unda ment os de un pl an de construcci ón det all ado. Di cho pl an defi ne l as t areas que

necesitan hacerse y l as dependenci as que exi sten entre estas t areas. Est o per mi t e un pl an

de trabaj o y un presupuest o de construcci ón razonabl e ment e predeci bl es. Ta mbi én di ce

en det all e có mo deben hacer su trabaj o l as personas que parti ci pan en l a construcci ón.

Est o per mi te que l a construcci ón requi era menos peri ci a i ntel ect ual, aunque se necesita a

me nudo mucha habili dad ma nual.

Así que l o que ve mos aquí son dos acti vi dades f unda ment al ment e dif erentes. El di seño,

qué es difícil de predeci r y requi ere personal caro y creati vo, y l a construcción que es más

fácil de predeci r. Una vez que t ene mos el di seño, pode mos pl anear l a construcci ón. Una

vez que t ene mos el pl an de construcci ón, pode mos ocuparnos de l a construcci ón de una

ma nera más predeci bl e. En i ngeni erí a ci vil l a construcci ón es mucho más cost osa y

tardada que el di seño y l a pl aneaci ón.

Así el acerca mi ent o de muchas met odol ogí as es: quere mos un pl an de trabaj o predeci bl e

que pueda usar gent e del más baj o ni vel. Para hacerl o debe mos separar el pl an de l a

construcci ón. Por consi guiente necesita mos ent ender có mo hacer el di seño de soft ware de

modo que l a construcci ón pueda ser sencill a una vez que el pl an esté hecho.

¿ Qué f or ma t o ma este pl an? Para muchos, éste es el papel de not aci ones de di seño co mo el

UML. Si pode mos hacer t odas l as deci si ones si gnificati vas usando UML, podemos ar mar un

pl an de construcci ón y ent onces pode mos dar planes a l os progra madores co mo una

acti vi dad de construcci ón.

Pero aquí surgen pregunt as cruci al es. ¿Es posibl e ar mar un pl an que sea capaz de

convertir el códi go en una acti vi dad de construcci ón predeci bl e? Y en t al caso, ¿es l a

construcci ón sufi ci ente ment e grande en cost o y ti e mpo para hacer val er l a pena est e

enf oque?

Todos est o trae a l a ment e más pregunt as. La pri mera es l a cuesti ón de cuán difí cil es

consegui r un di seño UML en un estado que pueda entregarse a l os progra madores. El

probl e ma con un di seño ti po UML es que puede parecer muy bueno en el papel, pero

resultar seri a ment e f alli do a l a hora de l a progra maci ón. Los model os que l os i ngeni eros

ci vil es usan está basado en muchos años de prácti ca guardados en códi gos i ngeni eril es.

Ade más l os probl e mas i mportantes, co mo el modo en que j uegan l as f uerzas, son dócil es al

análisis mat e máti co. La úni ca verificaci ón que pode mos hacer con l os di agramas UML es l a

revi si ón cui dadosa. Mi entras est o es útil trae errores al di seño que sól o se descubren

durant e l a codificaci ón y pruebas. I ncl uso l os di señadores experi ment ados, se sorprenden

a menudo cuando convi erten di chos di seños en software.

Ot ro probl e ma es el costo co mparati vo. Cuando se construye un puent e, el cost o del

esf uerzo en el pl an es aproxi mada ment e un 10 % del t otal, si endo el rest o l a construcci ón.

En soft ware l a canti dad de ti e mpo gastada codificando es mucho, mucho me nor. St eve

Mc Connell [ 2] sugi ere que para un proyect o grande, sól o 15 % del proyect o son códi go y

pruebas unitari as, una i nversi ón casi perf ecta de l as proporci ones de l a construcci ón del

puent e. Aun cuando se consi deren l as pruebas parte de l a construcci ón, el pl an es t odaví a

50 % del t otal. Est o genera una pregunt a i mportant e sobre l a nat ural eza del di seño en

soft ware co mparado con su papel en otras ra mas de l a i ngeni erí a.

Est a cl ase de pregunt as llevaron a J ack Reeves a sugeri r que de hecho el códi go f uent e es

un docu ment o de di seño y que l a f ase de construcci ón está en reali dad en l a co mpil aci ón y

el li gado. De hecho cual qui er cosa que pueda tratarse co mo construcci ón puede y debe

aut o mati zarse.

Est as i deas llevan a al gunas concl usi ones i mportantes:

oEn soft ware l a construcci ón es tan barata que es casi gratis.

oEn soft ware t odo el esf uerzo está en el di seño, de modo que requi ere de personas

creati vas y tal ent osas.

oLos procesos creati vos no se pl anean f ácil mente, de modo que l a previsi bili dad bi en

puede ser una met a i mposi bl e.

oDebe mos ser muy caut os al usar l a met áf ora de l a i ngeni erí a tradi ci onal para construi r

soft ware. Es un ti po diferent e de acti vi dad y por ende requi ere un proceso diferent e.

Bi bli ografí a

1. Aenor. 1990. Nor ma UNE 50- 106- 90. Docume nt aci ón. Di rectri ces para el

establ eci mi ent o y desarroll o de tesauros monoli ngües. Madri d: AENOR, 1990, 47 p.

2. Codi na, Ll uí s. 1994. Si stemes d' i nf or maci ó docu ment al: concepci ó, anàli si i disseny

de si ste mes de gesti ó document al a mb mi croordi nadors. Barcel ona: Pòrti c, 1994,

224 p.

3. Jackson, G. A. 1990. I ntroducci ón al di seño de bases de dat os rel aci onal es. Madri d:

Anaya, 1990, 203 p.

4. Van Sl ype, Georges. 1991. Los l enguaj es de i ndi zación: concepci ón, construcci ón y

utilizaci ón en l os si ste mas docu ment al es. Madrid: Fundaci ón Ger mán Sánchez

Rui pérez, 1991, 198 p.

5. Wal ker, D. W. 1991. Si ste mas de i nf or maci ón basados en ordenador. Barcel ona:

Marco mbo, 1991.

6. Yourdon, E. 1993. Análisis estruct urado moderno. Méxi co: Prenti ce- Hall

Hi spanoa meri cana, 1993, 735 p.