LasMetodologasdeDesarrollogilcomounaOportunidad paralaIngenieradelSoftwareEducativo TheMethodologiesofAgileDevelopmentlikeanOpportunity fortheEngineeringofEducativeSoftware

AilinOrjuelaDuarte,MSc.,MauricioRojasC.,MSc. GrupodeinvestigacinCICOM,UniversidaddePamplona,Colombia aorjuela@unipamplona.edu.co,mrojas@unipamplona.edu.co

Recibidopararevisin3deAbrilde2008,Aceptado19deMayode2008,Versin nal24deMayode2008

Resu men L a in gen ier a d el soft wa r e ed u ca t ivo se vien e

convir tiendoenunreadeestudioconaltosnivelesdeaplicacin debido aquecadavezlospr ocesosde desar rollodesistemasde softwar eeducativosellevanacaboempleandometodologasdela Ingenier adelsoftwar e. Las aplicaciones de softwar e educativo desar r olladas en pocas pasadasenlagr anmayor adeloscasossur gandeesfuer zosde docentesconalgunosconocimientoseninfor mticaoensudefecto deingenier osconalgunosinter esesenelsectoreducativo. Otrofactorimpor tanteaanalizaresquelasmetodologasofrecidas porlaingenier adelsoftwareeducativosondemasiadopesadas, entonces debido a este ar gumento en el pr esente documento se estudianlosenfoquestr adicionales,losenfoquesmoder nosylas metodologas giles par a ofr ecer una pr opuesta metodolgica menospesadapar alaingenier adelsoftwareeducativo.

I.INTRODUCCIN

ste trabajo tiene como prospectiva dos objetivos, el primero de ellos pretende brindar una descripcin del marcotericodereferenciadelasmetodologasdedesarrollo gil presentando algunas como: XP, CRYSTAL, SCRUM. El segundo objetivo busca analizar algunas caractersticas esencialesdeestasmetodologasparaadaptarlasalcontexto delaingenieradelsoftwareeducativo. Enlacomunidaddelaingenieradelsoftware,seestviviendo con intensidad un debate abierto entre los partidarios de las metodologas tradicionales (referidas como metodologas pesadas) y aquellos que apoyan las ideas emanadas del Mani estogil[1]. Por un lado, para muchos equipos de desarrollo el uso de metodologastradicionaleslesresultamuylejanoasuformade trabajoactualconsiderandolasdi cultadesdesuintroduccin e inversin asociada en trminos de formacin y compra de herramientas. Por otro, las caractersticas de los proyectos paraloscualeslasmetodologasgileshansidoespecialmente pensadasseajustanaunampliorangodeproyectosdedesarrollo desoftwareaquellosenloscualeslosequiposdedesarrolloson pequeos,conplazosreducidos,requisitosvoltiles,basadosen nuevastecnologas. Estas metodologas estn especialmente orientadas para proyectosquenecesitandeunasolucinalamedida,conuna elevadasimpli cacinsindejardeladoelaseguramientoenla calidaddelproducto.Lasmetodologasgilessecentranenel factorhumanoyelproductosoftwareesdecir,ellasledanmayor valoralindividuo,alacolaboracindelclienteyaldesarrollo incrementaldelsoftwareconiteracionesmuycortas. En cuantoa losobjetivos, la investigacindocumentalse orienthacialaidenti cacindemetodologasdediseo,que contienenlosmtodos,lasherramientasylosprocedimientos especficos para la construccin de software. Despus de

Palabrasclave: Ingenier adelSoftwar e,Metodologagil,Modelo

Pedaggico,DiseoEducativo,DiseoComputacional. Ab str act Edu cat iona l softwa r e en gin eer ing is b ecomin g a r esear ch eldwithhighlevelsofapplicationduetothefactthat thedevelopmentprocessesofeducationalcomputer softwareare increasinglyapplyingsoftwar eengineer ingmethodologies. Mostpr eviouseducationalsoftwareapplicationsarosefromeither the effor ts of teacher s with some knowledge of computing or systemsengineer swithinter estsintheeducationalsector. Anotherimpor tantissuewhichneedstobeanalyzedisthefactthat, inthepast,educationalsoftwar eengineer ingmethodologieswere tooheavy.Duetothisar gument,inthiswor kbothtr aditionaland moder nmethodologiesaswellasfastandeffectivemethodologies will b e st udied in or der to pu t for war d a m or e ma nagea ble methodologicalpr oposalforeducationalsoftwar eengineer ing.

Keywords: Softwar eEngineer ing,FastMethodology,Pedagogical

Model,EducationalDesign,ComputerDesign.

RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

160
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

esta fase se articulan las caractersticasde lasmetodologas gilesparaproponeralgunasorientacionesparaelprocesode desarrollodesoftwareeducativo. Elrestodelpresentedocumentoestorganizadocomosigue. Enlaseccin2seintroducenlasprincipalescaractersticasde lasmetodologasgiles,recogidasenelMani estoysehace unacomparacinconlastradicionales.Laseccin3secentra eneXtremeProgramming(XP),presentandosuscaractersticas particulares, el proceso que se sigue y las prcticas que proponeysecitanotrasmetodologasgiles,enumerndose susprincipalescaractersticas.Laseccin4presentaalgunas caractersticasdelasmetodologasdedesarrollogilaplicadas al proceso de desarrollo de software educativo. Finalmente aparecenlasconclusionesyreferencias.
II.METODOLOGASDEDESARROLLOGIL

Losintegrantesdelareuninresumieronlosprincipiossobre losquesebasanlosmtodosalternativosencuatropostulados, loquehaquedadodenominadocomoMani estogil[5]. El manifiesto gil est fundamentado en los siguientes valores: Alindividuoylasinteraccionesdelequipodedesarrollo sobre el proceso y las herramientas. Las personas son el principal factor de xito de un proyecto software. Es ms importanteconstruirunbuenequipodetrabajoqueconstruirel entorno.Muchasvecessecometeelerrordeconstruirprimero elentornoyesperarqueelequiposeadapteautomticamente. Esmejorcrearelequipoyquestecon guresupropioentorno dedesarrolloenbaseasusnecesidades. Desarrollar software que funciona ms que conseguir unabuenadocumentacin.Lareglaaseguiresnoproducir documentosamenosqueseannecesariosdeformainmediata paratomarundecisinimportante.Estosdocumentosdeben sercortosycentrarseenlofundamental. Lacolaboracinconelclientemsquelanegociacinde uncontrato.Seproponequeexistaunainteraccinconstante entre elcliente y el equipo dedesarrollo.Esta colaboracin entre ambos ser la que marque la marcha del proyecto y aseguresuxito. Responderaloscambiosmsqueseguirestrictamenteun plan.Lahabilidadderesponderaloscambiosquepuedansurgir alolargodelproyecto(enlosrequisitos,enlatecnologa,en elequipo)esotrofactorquedeterminaelxitoofracasodel mismo.Porlotanto,laplani cacinnodebeserestrictasino exibleyabierta[5]. Los valores anteriores inspiran los doce principios del mani esto.Soncaractersticasquediferencianunprocesogil deunotradicional.Losdosprimerosprincipiossongenerales yresumengranpartedelespritugil.Elrestotienenquever conelprocesoaseguiryconelequipodedesarrollo,encuanto metasalograryorganizacindelmismo. Losprincipiosdelmani estogilson: 1. Laprioridadessatisfaceralclientemediantetempranas ycontinuasentregasdesoftwarequeleaporteunvalor. 2. Dar la bienvenida a los cambios. Se capturan los cambiosparaqueelclientetengaunaventajacompetitiva. 3. Entregarfrecuentementesoftwarequefuncionedesde unpardesemanasaunpardemeses,conelmenorintervalo detiempoposibleentreentregas. 4. La gente del negocio y los desarrolladores deben trabajarjuntosalolargodelproyecto. 5. Construirelproyectoentornoaindividuosmotivados. Darleselentornoyelapoyoquenecesitanycon arenellos paraconseguir nalizareltrabajo. 6. Eldilogocaraacaraeselmtodomse cientey efectivoparacomunicarinformacindentrodeunequipode

En este segmento del artculo se presentan los aspectos ms relevantes de las metodologas de desarrollo gil, entre losapartes que sedescribenestn los antecedentes, el mani esto gil, comparacin entre metodologas giles vs. Tradicionales.

A.Antecedentes
En febrero de 2001, tras una reunin celebrada en Utah EEUU,naceeltrminogilaplicadoaldesarrollodesoftware. Suobjetivofueesbozarlosvaloresyprincipiosquedeberan permitir a los equipos desarrollar software rpidamente y respondiendoaloscambiosquepuedansurgiralolargodel proyecto[3]. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidosydirigidosporladocumentacinquesegeneraencada unadelasactividades. Tras esta reunin se cre TheAgile Alliance [8], una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudaralasorganizacionesparaqueadoptendichosconceptos. ElpuntodepartidafueelMani estogil,undocumentoque resumela losofagil[5].

B.Mani estogil
Enmarzode2001diecisietecrticosdelosmodelosdemejora deldesarrollodesoftwarebasadosenprocesos,convocadospor KentBeck,quienhabapublicadounpardeaosantesExtreme ProgrammingExplained,libroenelqueexponaunanueva metodologadenominadaExtremeProgramming,sereunieron enSalt LakeCitypara tratarsobretcnicasyprocesospara desarrollarsoftware.EnlareuninseacueltrminoMtodos gilesparade niralosmtodosqueestabansurgiendocomo alternativaalasmetodologasformales(CMMI,SPICE)alas que consideraban excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de plani caciones detalladaspreviasaldesarrollo.

161
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

desarrollo. 7. El softwarequefunciona eslamedidaprincipalde progreso. 8. Los procesos giles promueven un desarrollo sostenible. 9. Laatencincontinuaalacalidadtcnicayalbuen diseomejoralaagilidad. 10. Lasimplicidadesesencial.

12. Enintervalosregulares,elequipore exionarespecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento[5].

C. Compa r a cin entre metodologa s giles y metodologastradicionales

Enlatabla1semuestranlasprincipalesdiferenciasdelas metodologas giles con respecto a las tradicionales. Estas diferencias hacen referencia de igual manera a aspectos organizacionalesyalprocesodedesarrollo[5].

11. Lasmejoresarquitecturas,requisitosydiseossurgen delosequiposorganizadosporsmismos.

Tabla1.Comparacindelasmetodologastradicionalesylasgiles

Deacuerdoalatabla1sepuedeobservarquelasmetodologas dedesarrollogilsonmsorientadasaprocesosdedesarrollo desoftwaredepocassemanasdedesarrolloyconbajosniveles deformalizacinenladocumentacinrequerida. Acontinuacinsedescribenconmayorniveldeespeci cacin lasprincipalessemejanzasydiferenciasdelasmetodologas gilesylasmetodologaspesadas: Prcticasdedesarrollo:Enlasmetodologasdedesarrollo gilseprocurarealizarlosprocesosdesoftwaredeacuerdo a las prcticas que le han dado resultados al grupo. En las metodologaspesadassedesarrolladeacuerdoalasnormas sugeridasporlosestndaresdedesarrollo. Adaptacin al cambio: En las metodologas giles por la mismacapacidaddereaccinsonmsadaptablesaloscambios, porelcontrarioenlasmetodologaspesadasporelnivelde formalidadenlafasederequerimientossonmsresistentes alcambio.

Control: Por su capacidad de adaptacin el proceso se hacemenoscontroladoqueenlasmetodologastradicionales que ejercen mayor control en el proceso por su nivel de formalizacin. Documentacin:Enlasmetodologasgilesnosehacenfasis en la documentacin ni en los artefactos adiferencia de las metodologaspesadas. Equipo de trabajo: En las metodologas giles existen bajonmerodeparticipantesyroles,porelcontrarioenlas metodologaspesadassesugierenlosrolesqueproporcionan lasnormas. Enconclusindeacuerdoalatablasedaprioridad:alos individuos y las interacciones ms que a los procesos y a las herramientas, a los sistemas funcionando antes que a la documentacin detallada, a la colaboracin con el cliente antes que la negociacin de contratos, a la respuesta al cambioantesqueseguirelplan.

162
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663
III.PRINCIPALESMETODOLOGASGILES

Lasmetodologasgilesresuelvenlosproblemassurgidos, posteriormente, a la masi cacin del uso del computador personal,dadoquelasexpectativasynecesidadesporpartede losusuariossehicieronmsurgentesyfrecuentes.Fueascomo acomienzodelos90surgieronpropuestasmetodolgicaspara lograrresultadosmsrpidoseneldesarrollodesoftwaresin disminuirsucalidad. Enestesegmentodelartculosedescribenlascaractersticas esencialesdelasmetodologasgilesmsutilizadascomoson XP,CRYSTALySCRUM.

buenclimadetrabajo.XPsebasaenrealimentacincontinua entreelclienteyelequipodedesarrollo,comunicacin uida entre todos los participantes, simplicidad en las soluciones implementadasycorajeparaenfrentarloscambios.XPsede ne comoespecialmenteadecuadaparaproyectos conrequisitos imprecisosymuycambiantes[2]. Car acter sticas Acontinuacinsedescribenlascaractersticasesencialesde XPorganizadasenlosapartadossiguientes:historiasdeusuario, roles,procesoyprcticas. LasHistor iasdeUsuar io

Antecedentes En pocas anteriores en las cuales slo haba pantallas de texto, no haba entornos de ventanas, las aplicaciones eranmssencillasquelasactuales.Erasu cienteunoodos programadores,quedeacuerdoasusconocimientosyenun plazorazonabledetiempoerancapacesdehacerprogramas tiles.Elprogramadoreraunaespeciedemagoquehacasu aplicacinyslolsabacmofuncionaba.Siacaso,despus dehacerelprogramahacaun ujogramadelosantiguos,no habaUML,orientacinaobjetosnicosasporelestilo. Con el paso de los aos las aplicaciones fueron cada vez msexigentes,loscomputadoresdisponandemsmemoriay aparecieronlosentornosdeventanas. Lo anterior origin que los programas aumentaran su tamao y se complicaran enormemente, requiriendo varios desarrolladoresytiemposmslargos.Todoestollevconsigo lanecesidaddemsorganizacinydocumentacin.Eneste contexto,aparecieronlasmetodologasdedesarrollopesadas (lasquesebasanenescribirmuchadocumentacin).Antesde hacerunprograma,fuenecesarioescribirquesequerahacer, deformaqueseasegurabaunacuerdoentreelclienteylos desarrolladoresacercadeloquesequerahacer. Luego se escriba lo qu se iba a hacer, para que los programadores trabajaran con un objetivo comn y organizado. Dealgunaforma,todaestaorganizacinydocumentacin quitpartedelencantodelaprogramacin.Losprogramadores, envezdededicarsealoquesesuponequelesgusta:programar deban dedicar gran parte de su tiempo a hacer y leer documentos,reuniones,entreotros. Tratando un poco de recuperar los viejos tiempos, en el quehabamenospapeleo,lascosaseranmssencillasylos programadores hacan lo que les gustaba, naci una nueva metodologadedesarrollo,laprogramacinextrema[2]. De nicin XP es una metodologa gil centrada en potenciar las relacionesinterpersonalescomoclaveparaelxitoendesarrollo desoftware,promoviendoeltrabajoenequipo,preocupndose por el aprendizaje de los programadores, y propiciando un

Corresponden a la tcnica utilizada para especi car los requisitosdelsoftware.Setratadeformatosenloscualesel clientedescribebrevementelascaractersticasqueelsistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y exible. Cada historia de usuario es lo su cientemente comprensibleydelimitadaparaquelosprogramadorespuedan implementarlaenunassemanas[2]. Aefectosdeplani cacin,lashistoriaspuedenserdeuna atressemanasdetiempo deprogramacin(parano superar el tamao de una iteracin). Las historias de usuario son descompuestas en tareas de programacin (Task Card) y asignadasalosprogramadoresparaserimplementadasdurante unaiteracin[2]. Una historia de usuario en forma general puede contener los siguientes tems, los cuales pueden variar de acuerdo al equipo de desarrollo.Estos aspectos puedenser:fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmerodehistoria,prioridadtcnicaydelcliente,referencia aotrahistoriaprevia,riesgo,estimacintcnica,descripcin, notasyunalistadeseguimientoconlafecha,estado,cosaspor terminarycomentarios. RolesXP LapropuestaoriginaldeBeckincluyelossiguientesroles [2]: Programador.Elprogramadorescribelaspruebasunitarias yproduceelcdigodelsistema. Cliente. Escribe las historias de usuario y las pruebas funcionalesparavalidarsuimplementacin.Adems,asigna la prioridad a las historias de usuario y decide cules se implementanencadaiteracincentrndoseenaportarmayor valoralnegocio. Encar gadodepr uebas(Tester ).Ayudaalclienteaescribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientasdesoporteparapruebas. Encar gado de seguimiento (Tr acker ). Proporciona realimentacinalequipo.Veri caelgradodeaciertoentrelas estimacionesrealizadasyeltiemporealdedicado,paramejorar futurasestimaciones.Realizaelseguimientodelprogresode

163
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

cadaiteracin. Entrenador(Coach).Esresponsabledelprocesoglobal. Debe proveer guas al equipo de forma que se apliquen las prcticasXPysesigaelprocesocorrectamente. Consultor . Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. G est or (Big b oss). Es el vnculo entre clientes y programadores,ayudaaqueelequipotrabajeefectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. ProcesoXP Elciclodedesarrolloconsisteenlossiguientespasos: 1.Elclientede neelvalordenegocioaimplementar.

2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente seleccionaqu construir, de acuerdo con sus prioridadesylasrestriccionesdetiempo. 4.Elprogramadorconstruyeesevalordenegocio. 5.Vuelvealpaso1. Entodaslasiteracionesdeesteciclotantoelclientecomoel programadoraprenden.Nosedebepresionaralprogramadora realizarmstrabajoqueelestimado,yaqueseperdercalidad enelsoftwareonosecumplirnlosplazos. Delamismaformaelclientetienelaobligacindemanejarel mbitodeentregadelproducto,paraasegurarsequeelsistema tengaelmayorvalordenegocioposibleconcadaiteracin.

Figur a1.ProcesoXP

El ciclo de vida ideal de XP consiste de seis fases [2]: Exploracin,Plani cacindelaEntrega(Release),Iteraciones, Produccin,MantenimientoyMuertedelProyecto. Pr cticasXP LaprincipalsuposicinqueserealizaenXPeslaposibilidad dedisminuirlamticacurvaexponencialdelcostodelcambioa lolargodelproyecto,losu cienteparaqueeldiseoevolutivo funcione.Estoseconsiguegraciasalastecnologasdisponibles para ayudar en el desarrollo de software y a la aplicacin disciplinadadelassiguientesprcticas[2]: El juego de la plani cacin. Hay una comunicacin frecuente entre el cliente y los programadores. El equipo tcnicorealizaunaestimacindelesfuerzorequeridoparala implementacindelashistoriasdeusuarioylosclientesdeciden sobreelmbitoytiempodelasentregasydecadaiteracin. Entregaspequeas.Producirrpidamenteversionesdel sistema que sean operativas, aunque no cuenten con toda

la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardarmsde3meses. Metfor a.Elsistemaesde nidomedianteunametfora o un conjunto de metforas compartidas por el cliente y el equipodedesarrollo.Unametforaesunahistoriacompartida quedescribecmodeberafuncionarelsistema(conjuntode nombres que acten como vocabulario para hablar sobre el dominiodelproblema,ayudandoalanomenclaturadeclases ymtodosdelsistema). Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinadodelproyecto. Pr uebas. La produccin de cdigo est dirigida por las pruebasunitarias.stassonestablecidasporelclienteantesde escribirseelcdigoysonejecutadasconstantementeantecada modi cacindelsistema.

164
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

Refactorizacin(Refactor ing).Esunaactividadconstante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simpli carlo yhacerloms exibleparafacilitarlosposteriorescambios. Se mejora la estructura interna del cdigo sin alterar su comportamientoexterno[13]. Progr amacinenparejas.Todalaproduccindecdigo deberealizarsecontrabajoenparejasdeprogramadores.Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo,mayorsatisfaccindelosprogramadores). Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Integr acincontinua.Cadapiezadecdigoesintegrada enelsistemaunavezqueestlista.As,elsistemapuedellegar aserintegradoyconstruidovariasvecesenunmismoda. 40hor asporsemana.Sedebetrabajarunmximode40 horasporsemana.Nosetrabajanhorasextrasendossemanas seguidas. Si esto ocurre, probablemente est ocurriendo un problemaquedebe corregirse.Eltrabajo extradesmotiva al equipo. Cliente insitu. El cliente tiene que estar presente y disponibletodoeltiempoparaelequipo.steesunodelos principalesfactoresdexitodelproyectoXP.Elclienteconduce constantementeeltrabajohacialoqueaportarmayorvalor de negocio y losprogramadores pueden resolver de manera inmediatacualquierdudaasociada.Lacomunicacinorales msefectivaquelaescrita. Estndaresdeprogramacin.XPenfatizaquelacomunicacin de los programadoreses atravs del cdigo, con lo cual es indispensablequesesiganciertosesquemasdeprogramacin paramantenerelcdigolegible. El mayor bene cio de las prcticas se consigue con su aplicacinconjuntayequilibradapuestoqueseapoyanunas enotras.LamayoradelasprcticaspropuestasporXPnoson novedosassinoqueenalgunaformayahabansidopropuestas eningenieradelsoftwareeinclusodemostradosuvalorenla prctica.ElmritodeXPesintegrarlasdeunaformaefectiva y complementarlas con otras ideas desde la perspectiva del negocio,losvaloreshumanosyeltrabajoenequipo.

mtodos formales ni herramientas CASE y que haban estimuladolacomunicacinylostest. Losequipos con problemas no entendan susfallas osi habancumplidoconlosmtodosformales. Laconclusin:Menosnfasisenladocumentacinexhaustiva y ms en versiones que corran y puedan ser probadas. Lo primero son promesas, lo segundo hechos. Cada proyecto necesitasuspropiosmtodos. Alistair Cockburn en lugar de partir solamente de su experienciapersonalparaconstruirunateoradecmodeben hacerselascosas,complementasuexperienciadirectaconla bsquedaactivadeproyectosparavercmotrabajan. lhaexploradoafondolosmtodosgiles,haciendonfasis enlafamiliademetodologasCrystal.Esunafamiliaporque creequelosdiferentestiposdeproyectosrequierendiferentes tiposdemetodologas.lmiraestavariacinalolargodedos ejes:elnmerodepersonasenelproyecto,ylasconsecuencias deloserrores.Cadametodologaencajaenunapartediferente, demodoqueparaunproyectode40personasquepuedeperder dinerodiscrecionalmentetieneunametodologadiferenteala deunproyectovitaldeseispersonas[8].

Figur a2.Clasi cacindelasdiferentesmetodologasCristal[8]

B.Crystal
En este segmento del artculo se describen los aspectos principalesdelametodologaCrystal.Enprimerainstanciase especi canlosantecedentesdelametodologa,continuando conde nicionesqueayudanaestructurarlafundamentacin tericayseterminacon lascaractersticas esencialesdelos diferentestiposdeCrystal. Antecedentes Enlosiniciosde1990,enunestudiorealizadoenIBMse llegalossiguientesacuerdos(Cockburn,2001): Losequiposexitososenfatizabanquenohabanseguido

La familia de metodologas Crystal comparten con la XP unaorientacinhumana,peroestacentralizacinenlagente se hace de una manera diferente.Alistair considera que las personasencuentrandifcilseguirunprocesodisciplinado,as quemsqueseguirlaaltadisciplinadelaXP,Alistairexplora lametodologamenosdisciplinadaqueaunpodratenerxito, intercambiandoconscientementeproductividadporfacilidadde ejecucin.lconsideraqueaunqueCrystalesmenosproductivo quelaXP,mspersonasserncapacesdeseguirlo. Alistairtambinponemuchopesoenlasrevisionesal nal de la iteracin, animando al proceso a aplicar tcnicas de mejoramientocontinuoenformaautomtica.Suasercines queeldesarrolloiterativoestparaencontrarlosproblemas

165
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

temprano, y entonces permitir corregirlos. Esto pone ms nfasis en la gente supervisando su proceso y a nndolo conformedesarrollan[8]. De niciones Setratadeunconjuntodemetodologasparaeldesarrollode softwarecaracterizadasporestarcentradasenlaspersonasque componenelequipoylareduccinalmximodelnmerode artefactosproducidos.Eldesarrollodesoftwareseconsidera unjuegocooperativodeinvencinycomunicacin,limitado porlosrecursosautilizar.Elequipodedesarrolloesunfactor clave,porloquesedebeninvertiresfuerzosenmejorarsus habilidades y destrezas, as como tener polticas de trabajo en equipo de nidas. Estas polticas dependern del tamao delequipo,establecindoseunaclasi cacinporcolores,por ejemploCrystalClear(3a8miembros)yCrystalOrange(25 a50miembros)[9]. Car acter sticas Laspersonas,comodispositivosactivos,tienen modosde xito y modos de fallo. Los siguientes son los principales [10]: Cuandoelnmerodepersonasaumenta,tambinaumenta lanecesidaddecoordinar. Cuandoelpotencialdedaosseincrementa,latolerancia avariacionesseveafectada. Lasensibilidaddeltiempoenquesedebeestarenelmercado vara:avecesestetiempodebeacortarsealmximoysetoleran defectos,otrasseenfatizalaauditoria,con abilidad,proteccin legal,entreotros. Las personas se comunican mejor cara a cara, con la preguntaylarespuestaenelmismoespaciodetiempo. Elfactormssigni cativoescomunicacin. Los mtodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versin del proceso, y todas sesitanentornoaunncleoidntico.Haycuatrovariantes de metodologas: Crystal Clear para equipos de 8 o menos integrantesAmarillo, para 8 a 20 Naranja, para 20 a 50 Rojo,para50a100.Lamsexhaustivamentedocumentadaes CrystalClear(CC),yeslaquesehadedescribiracontinuacin. CCpuedeserusadoenproyectospequeos.Elotromtodo elaboradoenprofundidadeselNaranja,aptoparaproyectos de duracin estimadaen 2aos.Losotros dos anse estn desarrollando.Comocasitodoslosotrosmtodos,CCconsiste envalores,tcnicasyprocesos.Lossietevaloresopropiedades deCCson: 1. Entrega frecuente. Consiste en entregar software a los clientesconfrecuencia,nosolamenteencompilarelcdigo. Lafrecuenciadependerdelproyecto,peropuedeserdiaria, semanalomensual. 2.Comunicacinosmtica.Todosjuntosenelmismocuarto. Una variante especial es disponer en la sala de un experto diseadorseniorydiscutirrespectodeltemaquesetrate.

3.Mejorare exiva.Tomarseunpequeotiempo(unaspocas horas cada o una vez al mes) para pensar bien qu se est haciendo,cotejarnotas,re exionar,discutir. 4.Seguridadpersonal.Hablarconloscompaeroscuando algomolestadentrodelgrupo. 5.Foco.Saberloqueseesthaciendoytenerlatranquilidad yeltiempoparahacerlo. 6.Fcilaccesoausuariosexpertos.Teneralgunacomunicacin conexpertosdesarrolladores. CrystalClearnorequiereningunaestrategiaotcnica,pero siempreestiltenerunascuantasamanoparaempezar.Las estrategiascomunesaotrasMetodologasgiles,son: 1.Exploracinde360.Veri carotomarunamuestradel valordenegociosdelproyecto,losrequerimientos,elmodelo dedominio,latecnologa,elplandelproyectoyelproceso. 2. Victoria temprana. Es mejor buscar pequeos triunfos inicialesqueaspiraraunagranvictoriatarda. 3. Esqueleto ambulante. Es una transaccin que debe ser simpleperocompleta. 4. Rearquitectura incremental. Se ha demostrado que no es conveniente interrumpir el desarrollo para corregir la arquitectura. Ms bien la arquitectura debe evolucionar en etapas,manteniendoelsistemaenejecucinmientrasellase modi ca. 5. Radiadores de informacin. Es una lmina pegada en algnlugarqueelequipopuedaobservarmientrastrabajao camina.Tienequesercomprensibleparaelobservadorcasual, entendidadeunvistazoyrenovadaperidicamenteparaque valgalapenavisitarla. Encuantoalastcnicas,sefavorecen: 1.Entrevistasdeproyectos.Sesueleentrevistaramsdeun responsableparatenervisionesmsricas. 2. Talleres de re exin. El equipo debe detenerse treinta minutosounahoraparare exionarsobresusconvenciones detrabajo,discutirinconvenientesymejorasyplanearparael perodosiguiente. 3. Planeamiento Blitz. Una tcnica puede ser el Juego de PlaneamientodeXP.Enestejuego,seponentarjetasindexadas en una mesa, con una historia de usuario o funcin visible en cada una. El grupo nge que no hay dependencias entre tarjetas,ylasalineaensecuenciasdedesarrollopreferidas.Los programadoresescribenencadatarjetaeltiempoestimadopara desarrollarcadafuncin.Elpatrocinadordelusuarioescribe la secuencia de prioridades, teniendo en cuenta los tiempos referidosyelvalordenegociodecadafuncin.Lastarjetasse agrupanenperodosdetressemanasllamadositeracionesquese agrupanenentregas,usualmentenomslargasdetresmeses. 4. Estimacin Delphi con estimaciones de pericia. En el procesoDelphiserenenlosexpertosresponsablesyproceden comoenunremateparaproponereltamaodelsistema,su

166
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

tiempodeejecucin,lafechadelasentregassegndependencias tcnicasydenegociosyparaequilibrarlasentregasenpaquetes deigualtamao. 5.Encuentrosdiariosdepie.Lapalabraclaveesbrevedad, cincoa diezminutos comomximo. No se tratadediscutir problemas,sinodeidenti carlos. 6. Miniaturade procesos.Unaforma depresentarCrystal Clearpuedeconsumirentre90minutosyunda.Laideaesque lagentepuedadegustarlanuevametodologa. 7. Gr cos de quemado. Sunombre vienedelos gr cos dequemadodecalorasdelosregmenesdietticosseusan tambinenScrum.Setratadeunatcnicadegra cacinpara descubrirdemorasyproblemastempranamenteenelproceso, evitando que se descubra demasiado tarde que todava no se sabe cunto falta. Para ello se hace una estimacin del tiempo faltante para programar lo que resta al ritmo actual, lo cual sirve para tener dominio de proyectos en los cuales las prioridadescambianbruscamente y con frecuencia. Esta tcnicaseasociaconalgunosrecursosingeniosos,comolaLista Tmpana,llamadaasporquesere erealagregadodetems conaltaprioridadeneltopedelaslistasdetrabajospendientes, esperandoquelosdemselementossehundanbajolalneade otacinloselementosqueestnsobrelalneaseentregarnen laiteracinsiguiente,losqueestnpordebajoenlasrestantes. EnotrasMetodologasgileslaListaTmpananoesotracosa queungr coderetraso.Losgr cosdequemadoilustranla velocidaddelproceso,analizandoladiferenciaentrelaslneas proyectadasyefectivasdecadaentrega. 8. Programacin lado a lado. Mucha gente siente que la programacinenparesdeXPinvolucraunapresinexcesiva la versindeCrystal Clear establece proximidad,pero cada quienseenfocaasutrabajoasignado,prestandounojoalo quehacesucompaero,quientienesupropiamquina.Esta esunaampliacindelaComunicacinOsmticaalcontexto delaprogramacin[10]. Hay ocho roles nominados en CC: Patrocinador, Usuario Experto, Diseador Principal, DiseadorProgramador, Experto enNegocios,Coordinador,Veri cador,Escritor. En Crystal Naranjaseagreganaunms roles:DiseadordeIU (Interfaz deUsuario), DiseadordeBasede Datos, Experto enUso,FacilitadorTcnico,Analista/DiseadordeNegocios, Arquitecto, Mentor de Diseo, Punto de Reutilizacin. A continuacin se describen los artefactos de los que son responsableslosrolesdeCC: 1. Patrocinador. Produce la Declaracin de Misin con PrioridadesdeCompromiso(Tradeoff).Consiguelosrecursos yde nelatotalidaddelproyecto. 2.UsuarioExperto.JuntoconelExpertoenNegociosproduce laListadeActoresObjetivosyelArchivodeCasosdeUsoy Requerimientos.Debefamiliarizarseconeluso delsistema, sugeriratajosdeteclado,modosdeoperacin,informacina visualizarsimultneamente,navegacin. 3.DiseadorPrincipal.ProducelaDescripcinArquitectnica.

SesuponequedebeseralmenosunprofesionaldeNivel3. (EnMetodologasgilessede nentresnivelesdeexperiencia: Nivel 1 es capaz de seguir los procedimientos Nivel 2 es capaz de apartarse de los procedimientos espec cos y encontrar otros distintos Nivel 3 es capaz de manejar con uidez, mezclar e inventar procedimientos). El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programadormsexperto. 4.DiseadorProgramador.Produce,juntoconelDiseador Principal,losBorradoresdePantallas,elModeloComnde Dominio,lasNotasyDiagramasdeDiseo,elCdigoFuente, elCdigodeMigracin,lasPruebasyelSistemaEmpaquetado. UnprogramaenCCesdiseoyprogramasusprogramadores sondiseadoresprogramadores.EnCCundiseadorqueno programenotienecabida. 5. Experto en Negocios. Junto con el Usuario Experto producelaListadeActoresObjetivosyelArchivodeCasos deUsoyRequerimientos.Debeconocerlasreglasypolticas delnegocio. 6.Coordinador.Conlaayudadelequipo,produceelMapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la ListadeRiesgos,elPlanyEstadodeIteracinylaAgendade Visualizacin. 7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas. 8.Escritor.ProduceelManualdeUsuario.ElEquipocomo GrupoesresponsabledeproducirlaEstructurayConvenciones delEquipoylosResultadosdelTallerdeRe exin[10]. C. SCRUM

Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmenteindicadaparaproyectosconunrpidocambiode requisitos.Susprincipalescaractersticassepuedenresumiren dos.Eldesarrollodesoftwareserealizamedianteiteraciones, denominadasSprint,conunaduracinde30das.Elresultado decadaSprintesunincrementoejecutablequesemuestraal cliente.Lasegundacaractersticaimportantesonlasreuniones a lo largo del proyecto,entre ellas destacalareunin diaria de 15 minutos del equipodedesarrollo para coordinacin e integracin[10]. Antecedentes Estametodologatomasunombredeunaposicinentrelazada encrculoquetomanlosintegrantesdelosequiposderugbypara tomardecisionessobreeljuego.Susprincipiosfundamentales fuerondesarrolladosenprocesosdereingenieraporGoldratt, TakeuchiyNonakaenladcadade1980yaplicadosalproceso dedesarrollodesoftwareporJeffSutherlanden1993,siendo formalizado con la colaboracin de Ken Schwaber en una presentacin en OOSPLA 96. Los principios de la misma han evolucionado con las contribuciones de varios autores fundamentalmenteCohn,BeedleySchwaber[10].

167
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

El Scrum se ha desarrollado teniendo como principios fundamentales: ElprincipiodeincertidumbredeZivenlaingeniera delsoftware:laincertidumbreesinherenteeinevitableenel procesodedesarrollodeproductosdesoftware[16]. Principioderequisitosinde nidosdeHumphrey:para un nuevo sistema de software, los requerimientos no sern totalmenteconocidoshastaque el usuarionolohayausado [12]. EnScruminicialmenteplaneanelcontextoyunestimado ampliodelaentrega. Despusdesarrollan elestimadode la entrega basndose en desarrollo del ambiente del proyecto. ElprocesodeciclodevidadeScrumreconocequeelproceso de desarrollo fundamental est completamente inde nido y usamecanismosdecontrolparaperfeccionarla exibilidad, manipularloimpredecibleyelcontroldelriesgo[15]. Car acter sticasdelproceso LascaractersticasesencialesdelprocesodeScrumson: Laprimerayltimafase(plani cacinyclausura)consisten en procesos de nidos, donde todos los procesos, entradas y salidasestnbiende nidas.Elconocimientodecmohacer estosprocesosesexplcitoysetratadehacerunrepositoriode todaslasactividadesarealizar(BacklogSystem). SedesarrollaniteracionesmensualesllamadasSprint.El equipodedesarrollodecidequefuncionalidadincluironoen cadaiteracinestimndoseeltiemponecesarioparaterminar lastareas.LafasedelSprintesunprocesoemprico.Muchos de losprocesosen estafasenoestnidenti cadoso noson controlados. LosSprintssonnolinealesy exibles.Puedenserusados procesosdeconocimientoexplcito.Cuandonoexistenestos conocimientos explcitos dentro del equipo, los errores y pruebasseusanparacrearprocesosdeconocimiento. DentrodelosSprintsserealizanreunionesdiariasde15 minutos(ScrumMeetings)enloscualescadadesarrollador darepuestaatrespreguntas: 1. Quhizodesdelaltimareunin?.

paraplani carunaentregadelproductoymanejarlasvariables enelprogresodelproyecto.Estopermitelaorganizacinpara cambiar el proyecto y las entregas en cualquier punto del desarrollo,entregandolaversinmsapropiada. LametodologaScrumliberaalosdesarrolladoresainventar las ms ingeniosas soluciones durante elproyecto, mientras aprendenyelambientecambia.Losequiposdedesarrolladores (idealmentealrededorde7miembros)puedenintercambiarlos conocimientosacercadelosprocesosdedesarrollo,siendoesto unamagni caoportunidaddeentrenamientoenelambiente. Fases LasdiferentesfasesdelScrumconsistenen: Prejuego Plani cacin: de nicin de una nueva entrega basndose en un Backlog conocido junto a un costo y cronograma estimados.Siunnuevosistemaempiezaadesarrollarse,esta faseconsisteenconceptualizacinyanlisis. Arquitectura: Disea cmo los artculos del Backlog son implementados.Estafaseincluyelacreacinmodi cacin delaarquitecturadelsistemayeldiseodealtonivel. Juego DesarrollodelosSprints:desarrollodeunanuevafuncionalidad enconstantemiraalasvariablestiempo,requerimientoscalidad, costoycompetencia.Lainteraccinconestasvariablesde neel naldeestafase.SonmltipleslosSprintsociclosusadospara desarrollarelsistema.DentrodelSprintlaretroalimentacinse obtieneconlasreunionesdiarias(ScrumMeetings)yelcontrol delacurvadeprogreso. Postjuego Clausura: preparacin para la entrega, incluyendo la documentacin nal,pruebayentrega.

IV.ORIENTACIONESPARALAINGENIERADESOFTWARE EDUCATIVOAPARTIRDEALGUNASCARACTERSTICASDE LASMETODOLOGASDEDESARROLLOGIL

2. Qudi cultadesconcretastieneeneldesarrollode latarea? 3. Quvaahacerhastalaprximareunindiaria?

Elproyectoesabiertohastalafasedeclausura.Laentrega puedeser replani cadaen cualquieradelas fasesanteriores mantenindose abierto a la complejidad del ambiente, la competencia,tiempo,calidadypresiones nancieras,durante eldesarrollodedichasfases. Laentregadelproyectoescalculadasobrelain uenciadel ambiente. LametodologaScrumestdiseadaparaser exibledurante eldesarrollodelossistemas.Proveedemecanismosdecontrol

Estaseccintienecomoobjetivoarticulardiferentestpicos delaingenieradelsoftwarecomosonelenfoqueclsico,los enfoquesmodernosylasmetodologasdedesarrollogilpara proponeralgunasorientacionesparaelprocesodedesarrollo desoftwareeducativo.Paracumplirconelobjetivoseplantean una serie de fases o etapas por las cuales debe transitar el procesodedesarrollodesoftwareeducativo,entrelascuales proponemos: 1.Planeacin 2.Obtencinderequerimientos 3.Anlisis 4.Diseo 5.Implementacin

168
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

6.Pruebas 7.Evaluacin Planeacin Durantelaplaneacinseproponelaconformacindelequipo detrabajoyelestablecimientodelaspolticasdetrabajodel proyecto, estas polticas deben estar enmarcadas en su gran porcentajealfortalecimientodelosprocesosdeenseanzay aprendizajeyalaincorporacindelasnuevastecnologasen losambienteseducativos.Esdevitalimportanciaestablecer polticasencuantoaltrabajodelequipocomoson:elnfasisen lacomunicacindelequipo,elnfasisenlaincorporacincasi permanentedeldocentey/oestudianteenelequipo,elnfasis eneldesarrolloincrementalatravsdeiteracionescortas.Es deespecialimportanciaelfactordecolaboracinconelcliente queenestecasoserialainstitucineducativa,eldocentey/o elestudiante.Paralaconformacindelequipodetrabajose proponenlossiguientesper les: Ungerentedeproyecto:Eselencargadodeestablecer, operacionalizarycontrolarlaspolticasdelproyecto. Unanalista:Eslapersonaencargadadeconstruirel modelodeanlisis(funcional,datosydinmico)delsistema desoftware. Unexpertoenrequerimientos:Eslapersonaencargada deidenti carlasfuncionalidadesquenecesitaelclienteenel sistema. Undiseador:Eslapersonaencargadadeconstruir laarquitecturadelsistemajuntoconsusrespectivasmaquetas yrutasdenavegacin. UnexpertoenInformticaeducativa:Eslapersona encargadadeemitirconceptosrelacionadosconlosmodelos pedaggicos apropiados para la construccin de software educativo. Un desarrollador o varios dependiendo del tamao delproyecto:Sonlaspersonasencargadasdeimplementarlas funcionalidadesdelsistema. Elcliente(docenteoestudiante):Sonlaspersonasque vanautilizaryprobarelsistema. Entre la de nicin de las polticas se puede empezar por de nirlospilaresconceptualesfundamentalessobreloscuales se deben construir los procesos de desarrollo de software educativo.Amaneradepropuestasesugierenlossiguientes pilares: Aspectoseducativos. Aspectostecnolgicos. Aspectosconceptuales. Aspectosmetodolgicos. Aspectosorganizacionales.

especi carlosnivelesdearticulacinentrelosdiferentespilares comosemuestraenla gura7:

Figur a3.Pilaresconceptualesfaseplaneacin.

Entre los aspectos educativos se deben contemplar tems como el modelo pedaggico que debe soportar el software educativoarticuladoconelusodelasnuevastecnologas.Enla especi cacindeestepilarconceptualesdonderadicalamayor diferenciaconunametodologautilizadaparaeldesarrollode unsoftwaretradicional. Deigualforma,enestesegmentosedebenespeci carlas estrategiasdidcticasalascualesdeberesponderelsoftware educativo. Entre los aspectos tecnolgicos se deben describir los componentes de hardware, software y comunicaciones que soportanlaimplementacindelsoftwareeducativo. Entre los aspectos conceptuales se deben especi car los contenidosquesepretendentransmitiratravsdelsoftware educativo. Entrelosaspectosmetodolgicossedebendescribirtodas aquellas actividades y estrategias que deben acompaar el uso del software educativo en el proceso de enseanza aprendizaje. Losaspectosorganizacionalesdebendetallartodasaquellas actividades relacionadas con la gestin que garanticen el correctoprocesodedesarrolloeimplementacindelsoftware educativo. Obtencinderequerimientos Un requerimiento es una caracterstica que debe tener el sistema o una restriccin que debe satisfacer para que sea aceptado por el cliente. En esta fase nos enfocamos en la obtencinderequerimientosbasadosenescenariosycasosde uso.Losdesarrolladoresobtienenlosrequerimientosapartir de entrevistas con los usuarios que en este caso pueden ser losdocentesy estudiantesquevanutilizarelsistema,luego desarrollan escenarios visionarios en donde se describe la funcionalidadqueproporcionarelsistemafuturo.Elcliente ylosusuariosvalidanladescripcindelsistemarevisandolos escenarios y probando prototipos pequeos proporcionados

Esimportanteresaltarqueenlafasedeplaneacinsedeben

169
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

por los desarrolladores. Conforme madurayse estabiliza la de nicindelsistema,losdesarrolladoresyelclienteseponen deacuerdoenunaespeci cacindelsistemaenformadecasos deuso.Paracadacasodeusosedebenespeci carlos ujos bsicosy ujosalternativosenformasencilla. Laobtencinderequerimientosseenfocaenladescripcin delpropsitodelsistema.Elcliente,losdesarrolladoresylos usuariosidenti canunreaproblemayde nenunsistemaque atacaelproblema.Atalde nicinselellamaespeci cacin delsistema. Como producto de esta fase se debe producir un modelo de casos de uso acompaado de un documento donde se especi quenlosrequerimientosnofuncionales. En metodologas tradicionales se trata de cumplir con requerimientos no funcionales sin que lleguen a convertirse enelejecentraldelproductosoftware.Paralaingenieradel softwareeducativoesderelevanteimportancialadeterminacin derequerimientosdeescenariosypersonajesdebidoaqueestos elementossonlosmediosatravsdeloscualeselniovaa adquirirloscontenidosdelaprendizaje. Anlisis El anlisis da como resultado un modelo del sistema que pretende ser correcto, completo, consistente y veri cable. El cliente y el usuario estn involucrados, por lo general, en esta actividad, en especial cuando se necesita cambiar la especi cacin del sistema y cuando se necesita recopilar informacinadicional. El anlisis se enfoca en la produccin de un modelo del sistema, llamada el modelo de anlisis, que es correcto, completo, consistenteyveri cable.El anlisisse diferencia delaobtencinderequerimientosenquelosdesarrolladores se enfocan en la estructuracin y formalizacin de los requerimientosobtenidosdelosusuarios.Aunquepuedeser queelmodelodeanlisisnoseacomprensibleparalosusuarios y el cliente, ayuda a que los desarrolladores veri quen la especi cacindelsistemaproducidadurantelaobtencinde requerimientos. Comoproductodeestafasesedebeproducirunmodelode clasessiesnecesarioacompaadodelre namientodelmodelo de casos de usogeneradoen lafaseanterior,estosmodelos deben ser desarrollados solo a nivel de diagramas de UML solosedebenespeci carconmayordetalleencasodequelos clienteslorequieren. Diseo Eldiseo desistemas esla transformacindelmodelode anlisisenunmodelodediseodelsistema.Duranteeldiseo delsistemalosdesarrolladoresde nenlosobjetivosdediseo delproyectoydescomponen elsistema ensubsistemas ms pequeosquepuedenserrealizadosporequiposindividuales. Los desarrolladores tambin seleccionan estrategias para la construccin del sistema, como la plataforma de hardware ysoftwareenlaqueseejecutarelsistema,laestrategiade

almacenamientodedatospersistentes,el ujodecontrolglobal, la polticadecontrol de acceso y el manejo de condiciones defrontera.Elresultadodeldiseodelsistemaesunmodelo que incluye una descripcin clara de cada una de estas estrategias,unadescomposicinensubsistemasyundiagrama de organizacin que representa la correspondencia entre el hardwareyelsoftwaredelsistema. Enformaespec caenestaetapasedebegenerarunmodelo dearquitecturaenformageneralyunalistaderequerimientos nofuncionalesuobjetivosdediseo. Enestaetapadediseosedebehacernfasisentrestiposde diseoadicionalquesonlossiguientes: 1. 2. 3. Diseoeducativo Diseodecomunicacin Diseocomputacional

Diseoeducativo Debe resolverlos interrogantesquesere erenalalcance, contenidoytratamientoquedebesercapazdeapoyarelsistema. En este tipo de diseo se debe prestar especial atencin al modelo pedaggico para disear las actividades del sistema deacuerdoalmodeloofusindemodelossobreloscualesse quiereimplementarelsistema. Apartirdelasnecesidadesdelosusuarios nalesdelsistema se debe implementar el sistema que responda a ellas y al contextoenelquesedesenvuelveelusuario nal. Sedebeutilizarunapropuestademodelopedaggicoquesirva comoejetransversalenelprocesodeenseanzaaprendizaje quesevaasoportarconelsistemadesoftware.Estemodelo pedaggicodebeservircomomedioparaincorporaralusuario nalloscontenidosquenecesitaparaalcanzarelper lquese buscaenuneducando. Elmodelopedaggicoautilizarenlaimplementacindel software educativo debe estar articulado con aspectos de relevante importancia como los contenidos, el ambiente o contextoenelcualsedebendesarrollarloscontenidos. Enformageneral,sepuedenvisualizarlosaspectosquese debentenerencuentaeneldiseoeducativodelasiguiente manera:

Figur a4.Elementosdeldiseoeducativo.

170
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

Como se puede observar en la gura anterior el diseo educativo est basado fundamentalmente en el modelo pedaggico a emplear o definido para la situacin de aprendizaje. Diseodecomunicacin Enestaseseccinsepretendeespeci carlaformacomose comunicaelusuarioconelprograma,estableciendodispositivos ycdigosomensajes.Bsicamenteestafasecorrespondealo quecomnmentesedenominadiseodeinterfaces. Enla gurasedescribenlosaspectosquesedebenteneren cuentaeneldiseodecomunicacin:

Enla guraseobservaqueparaeldiseocomputacionalse debenmaterializarlasfuncionalidadesdetodoslosusuariosa travsdediagramasdecasosdeuso,deigualformasedeben especi car el modelo de datos del sistema si es necesario y por ltimo el modelo dinmico por medio de diagramas de secuencia. Implementacin Durantelaimplementacinsepretendetraducirlosdiferentes modelosdiseadosenlasetapasanterioresencdigofuente.En formaparalelasedebenintegrarcadaunodelossubsistemas desarrolladosenformasegmentada. Pr uebas Laspruebassonelprocesodeencontrardiferenciasentreel comportamiento esperado, especi cado por los modelos del sistema,yelcomportamientoobservadodelsistema. Las pruebas son el proceso de anlisis de un sistema, o componentedeunsistema,paradetectarlasdiferenciasentre el comportamiento especi cado (requerido) y el observado (existente). El objetivo de las pruebas es aumentar la con abilidaddelsistema. Entrminoseducativosserecomiendarealizarpruebaspilotos ypruebasdecampoconpotencialesusuariosdelsistemaycon otrosdesarrolladoresdiferentesalasdelequipo. Evaluacin Es de vital importancia para los procesos de enseanza aprendizajedeterminarenlafasederequerimientosinstrumentos deevaluacinquepuedenseractividadesdentrodelsistema conloscualessepuedanmedirelniveldecumplimientode losobjetivosparacadaunodeloscontenidosquesepretenden desarrollarenelsistema.
CONCLUSIONES

Figur a5.Elementosdiseodecomunicacin

Diseocomputacional Tomando como punto de partida las necesidades de los usuarios se establece qu funcionalidades debe cumplir el sistemadesoftwareeducativo.Enestesegmentotambinse deben materializar los requerimientos no funcionalidades que surgen de los clientes, usuarios y del propio modelo pedaggico. Eneldiseocomputacionalsedebendescribirlosusuarios del sistema complementados con las funcionalidades a las cuales tienen acceso, para luego implementar mdulos de acuerdoaldiseomsapropiadoquesoportelosrequerimientos funcionalesynofuncionalesdelsistema. En forma general, en el diseo computacional se deben materializarlosmodelosfuncional,declasesydinmico. Enla gurasedescribenlosaspectosquesedebenteneren cuentaeneldiseocomputacional:

Losmtodosgilessonunareaccinalasformastradicionales de desarrollo de software, admitiendo la necesidad de una alternativa al desarrollo de software orientado a la documentacinycentradosenelproceso. Losmtodos gilesdedesarrollodesoftware han surgido muyrecientementecomotendenciasnoampliamenteaceptadas aun, pero con buena probabilidad de lograr interesantes aportesencuantoametodologasdedesarrollodesoftware. Estas tendencias se conocen tambin con el nombre de mtodoslivianosysonapropiadosparapequeosequiposde desarrollo. Laagilidadsepuedede nircondoscaracterizaciones[11]: Agilidad es la habilidad para crear y responder a cambiosdeacuerdoalosbene ciosenunambientedenegocios turbulento. Agilidadeslahabilidadparabalancear exibilidady estabilidad.

Figur a6.Elementosdiseocomputacional

En este sentido la agilidad de los mtodos de desarrollo softwaresepuedesintetizarenlacapacidadpararesponderal

171
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

cambioyparasimpli carlosprocesos. La propuesta metodolgica para el desarrollo de software educativodescribe un conjunto defases que permiten guiar el proceso de desarrollo de productos software que apoyen el proceso enseanzaaprendizaje. Esta propuesta tiene la particularidad que permite articular aspectos educativos, tecnolgicos,conceptuales,metodolgicosyorganizacionales deunamanerarpidasincaerenprincipiosdelasmetodologas tradicionalescomoeslaorientacinalproceso. De igual forma, la propuesta permite adaptar procesos de desarrollo que requieran altos niveles de documentacin y orientacin al proceso, adicionalmente tambin permite adaptarseaproyectosdedesarrollodesoftwareeducativode grantamao. De acuerdo a las caractersticas de las metodologas de desarrollo gil como son el avance iterativo e incremental, permitetenerrpidamenteprototiposfuncionalesquepueden ser probados y evaluados en forma conjunta por un equipo conformadoporclientesydesarrolladores. La propuesta metodolgica esta orientada a la generacin de prototipos funcionales en cada iteracin y no tanto a la produccindeartefactos.Sinembargo,sepuedeadaptarala generacindeartefactos segn exijan los requerimientos de losclientes. En forma general se puede afirmar que la propuesta metodolgicapermite adaptarse aprocesos de desarrollo de software educativo de diferentes tamaos, requerimientos y nivelesdecomplejidad.

REFERENCIAS

Lapropuestametodolgicaoconjuntodefasesdedesarrollo ofreceunaalternativadesolucinalproblemadescritoenel hechodequemuchosproyectosdesoftwareeducativosellevan acabosinningnejeconductorquepermitaorientarelproceso dedesarrollo,enotrassituacionesestosproyectossondeun tamaopequeoquenopermitenlautilizacindemetodologas tradicionales que son muy orientadas a la generacin de artefactosylospresupuestosdetiemponosontanlargos. La propuesta en mencin tiene como uno de sus valores agregados la capacidad de adaptarse a diferentes tipos de proyectos de desarrollo de software educativo, es decir, a proyectos de diferentes tamaos, caractersticas, nivel de educacin y de diferente tipo (multimedia, micromundo, videojuego,animacin,dilogosanimados). Enmetodologastradicionalesempleadasporlaingeniera del software educativo no se le da el valor necesario a los aspectos educativos y/o didcticos, en caractersticas tales como el modelo pedaggico que deba soportar el producto desoftwareeducativo.Enotrostrabajossesugierenalgunos macroalgoritmosquepuedenguiarelprocesodedesarrollode softwareeducativobasadosendiferentesmodelospedaggicos lo cual se convierte en un conjunto de alternativas para los educadoresyparalosdesarrolladores.

[1]Abrahamsson,P.,Salo,O.,Ronkainen,J.,Warsta,J..Agilesoftware developmentmethodsReviewandanalysis..VTTPublications. 2002. [2]Beck,K..ExtremeProgrammingExplained.EmbraceChange, Pearson Education, 1999. Traducido al espaol como: Una explicacin de la programacin extrema.Aceptar el cambio, AddisonWesley,2000. [3]Boehm,B.Turner,R.BalancingAgilityanddiscipline.Aguide forthePerplexed.AddisonWesley.2003. [4]Bruegge,B.,Dutoit,A.Ingenieradesoftwareorientadaaobjetos. PearsonEducacin.Mxico,2002. [5]Cans,J.,Letelier,P.yPenads,M.Metodologasgilesenel desarrollo de Software. Universidad Politcnica de Valencia, Valencia,2003. [6]Caro,G.Agilemani estoyexperiencias personales.Memorias JornadasdeGerencia.ACIS.Bogot2004. [7]Cockburn,A.SelectingaProjectsMethodology,,Humansand Technology,IEEESOFTWAREJuly/August2000. [8] Cockbun,A. .Agile Software Development..AddisonWesley. 2001. [9]Fowler,M.,Beck,K.,Brant,J.Refactoring:ImprovingtheDesign ofExistingCode.AddisonWesley.1999. [10]Gutierrez,Joaquin.Metodologasgiles.UniversidadPablode Olavide.2007. [11]Highsmith,J.AgileProjectManagement,2003 [12] Humphrey, W.S., Managing the Software Process,Addison Wesley,Reading,MA,1989. [13]PoppendieckM.,PoppendieckT.LeanSoftwareDevelopment: AnAgileToolkitforSoftwareDevelopmentManagers.Addison Wesley.2003. [14]Pressman,R.SoftwareEngineering:APractitionersApproach. McGrawHill.2005. [15]Schwaber,k.AgileProjectManagementwithScrum(Microsoft Professional).Mar10,2004. [16]Ziv,H.yD.J.Richardson:,ICSE97,XIXInternationalConference onSoftwareEngineering,23deagostode1996.

172
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663