LasMetodologasdeDesarrollogilcomounaOportunidad

paralaIngenieradelSoftwareEducativo

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

Recibidopararevisin3deAbrilde2008,Aceptado19deMayode2008,Versinnal24deMayode2008

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

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.
E 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
Maniestogil[1].

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 cheldwithhighlevelsofapplicationduetothefactthat
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.
Por un lado, para muchos equipos de desarrollo el uso de
metodologastradicionaleslesresultamuylejanoasuformade
trabajoactualconsiderandolasdicultadesdesuintroduccin
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
elevadasimplicacinsindejardeladoelaseguramientoenla
calidaddelproducto.Lasmetodologasgilessecentranenel
factorhumanoyelproductosoftwareesdecir,ellasledanmayor
valoralindividuo,alacolaboracindelclienteyaldesarrollo
incrementaldelsoftwareconiteracionesmuycortas.
En cuantoa losobjetivos, la investigacindocumentalse
orienthacialaidenticacindemetodologasdediseo,que
contienenlosmtodos,lasherramientasylosprocedimientos
especficos para la construccin de software. Despus de

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,recogidasenelManiestoysehace
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
En este segmento del artculo se presentan los aspectos
ms relevantes de las metodologas de desarrollo gil,
entre losapartes que sedescribenestn los antecedentes, el
maniesto 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.
ElpuntodepartidafueelManiestogil,undocumentoque
resumelalosofagil[5].
B.Maniestogil
Enmarzode2001diecisietecrticosdelosmodelosdemejora
deldesarrollodesoftwarebasadosenprocesos,convocadospor
KentBeck,quienhabapublicadounpardeaosantesExtreme
ProgrammingExplained,libroenelqueexponaunanueva
metodologadenominadaExtremeProgramming,sereunieron
enSalt LakeCitypara tratarsobretcnicasyprocesospara
desarrollarsoftware.EnlareuninseacueltrminoMtodos trabajarjuntosalolargodelproyecto.
gilesparadeniralosmtodosqueestabansurgiendocomo
alternativaalasmetodologasformales(CMMI,SPICE)alas
que consideraban excesivamente pesadas y rgidas por su
carcter normativo y fuerte dependencia de planicaciones
detalladaspreviasaldesarrollo.
Losintegrantesdelareuninresumieronlosprincipiossobre
losquesebasanlosmtodosalternativosencuatropostulados,
loquehaquedadodenominadocomoManiestogil[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.
Esmejorcrearelequipoyquesteconguresupropioentorno
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,laplanicacinnodebeserestrictasino
exibleyabierta[5].
Los valores anteriores inspiran los doce principios del
maniesto.Soncaractersticasquediferencianunprocesogil
deunotradicional.Losdosprimerosprincipiossongenerales
yresumengranpartedelespritugil.Elrestotienenquever
conelprocesoaseguiryconelequipodedesarrollo,encuanto
metasalograryorganizacindelmismo.
Losprincipiosdelmaniestogilson:
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
5. Construirelproyectoentornoaindividuosmotivados.
Darleselentornoyelapoyoquenecesitanyconarenellos
paraconseguirnalizareltrabajo.
6. Eldilogocaraacaraeselmtodomsecientey
efectivoparacomunicarinformacindentrodeunequipode

LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
desarrollo.
7. El softwarequefunciona eslamedidaprincipalde
progreso.
8. Los procesos giles promueven un desarrollo
sostenible.
9. Laatencincontinuaalacalidadtcnicayalbuen
diseomejoralaagilidad.
10. Lasimplicidadesesencial.
11. Lasmejoresarquitecturas,requisitosydiseossurgen
delosequiposorganizadosporsmismos.
Tabla1.Comparacindelasmetodologastradicionalesylasgiles
Deacuerdoalatabla1sepuedeobservarquelasmetodologas
dedesarrollogilsonmsorientadasaprocesosdedesarrollo
desoftwaredepocassemanasdedesarrolloyconbajosniveles
deformalizacinenladocumentacinrequerida.
Acontinuacinsedescribenconmayorniveldeespecicacin
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.
161
12. Enintervalosregulares,elequiporeexionarespecto
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].
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 masicacin del uso del computador
personal,dadoquelasexpectativasynecesidadesporpartede
losusuariossehicieronmsurgentesyfrecuentes.Fueascomo
acomienzodelos90surgieronpropuestasmetodolgicaspara
lograrresultadosmsrpidoseneldesarrollodesoftwaresin
disminuirsucalidad.
Enestesegmentodelartculosedescribenlascaractersticas
esencialesdelasmetodologasgilesmsutilizadascomoson
XP,CRYSTALySCRUM.
Antecedentes
En pocas anteriores en las cuales slo haba pantallas
de texto, no haba entornos de ventanas, las aplicaciones
eranmssencillasquelasactuales.Erasucienteunoodos
programadores,quedeacuerdoasusconocimientosyenun
plazorazonabledetiempoerancapacesdehacerprogramas
tiles.Elprogramadoreraunaespeciedemagoquehacasu implementarlaenunassemanas[2].
aplicacinyslolsabacmofuncionaba.Siacaso,despus
dehacerelprogramahacaunujogramadelosantiguos,no atressemanasdetiempo deprogramacin(parano superar
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].
Denicin
XP es una metodologa gil centrada en potenciar las
relacionesinterpersonalescomoclaveparaelxitoendesarrollo
desoftware,promoviendoeltrabajoenequipo,preocupndose
por el aprendizaje de los programadores, y propiciando un
buenclimadetrabajo.XPsebasaenrealimentacincontinua
entreelclienteyelequipodedesarrollo,comunicacinuida
entre todos los participantes, simplicidad en las soluciones
implementadasycorajeparaenfrentarloscambios.XPsedene
comoespecialmenteadecuadaparaproyectos conrequisitos
imprecisosymuycambiantes[2].
Car acter sticas
Acontinuacinsedescribenlascaractersticasesencialesde
XPorganizadasenlosapartadossiguientes:historiasdeusuario,
roles,procesoyprcticas.
LasHistor iasdeUsuar io
Corresponden a la tcnica utilizada para especicar 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 sucientemente
comprensibleydelimitadaparaquelosprogramadorespuedan
Aefectosdeplanicacin,lashistoriaspuedenserdeuna
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.Vericaelgradodeaciertoentrelas
estimacionesrealizadasyeltiemporealdedicado,paramejorar
futurasestimaciones.Realizaelseguimientodelprogresode

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.Elclientedeneelvalordenegocioaimplementar.
El ciclo de vida ideal de XP consiste de seis fases [2]:
Exploracin,PlanicacindelaEntrega(Release),Iteraciones,
Produccin,MantenimientoyMuertedelProyecto.
Pr cticasXP
LaprincipalsuposicinqueserealizaenXPeslaposibilidad
dedisminuirlamticacurvaexponencialdelcostodelcambioa
lolargodelproyecto,losucienteparaqueeldiseoevolutivo
funcione.Estoseconsiguegraciasalastecnologasdisponibles
para ayudar en el desarrollo de software y a la aplicacin
disciplinadadelassiguientesprcticas[2]:
El juego de la planicacin. 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
163
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
la funcionalidad del sistema. Esta versin ya constituye un
resultado de valor para el negocio. Una entrega no debera
tardarmsde3meses.
Metfor a.Elsistemaesdenidomedianteunametfora
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
modicacindelsistema.
164
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663

Refactorizacin(Refactor ing).Esunaactividadconstante mtodos formales ni herramientas CASE y que haban

de reestructuracin del cdigo con el objetivo de remover estimuladolacomunicacinylostest.
duplicacin de cdigo, mejorar su legibilidad, simplicarlo
Losequipos con problemas no entendan susfallas osi
yhacerlomsexibleparafacilitarlosposteriorescambios.
habancumplidoconlosmtodosformales.
Se mejora la estructura interna del cdigo sin alterar su
comportamientoexterno[13]. Laconclusin:Menosnfasisenladocumentacinexhaustiva
y ms en versiones que corran y puedan ser probadas. Lo
Progr amacinenparejas.Todalaproduccindecdigo
primero son promesas, lo segundo hechos. Cada proyecto
deberealizarsecontrabajoenparejasdeprogramadores.Esto
necesitasuspropiosmtodos.
conlleva ventajas implcitas (menor tasa de errores, mejor
diseo,mayorsatisfaccindelosprogramadores). Alistair Cockburn en lugar de partir solamente de su
experienciapersonalparaconstruirunateoradecmodeben
Propiedad colectiva del cdigo. Cualquier programador
hacerselascosas,complementasuexperienciadirectaconla
puede cambiar cualquier parte del cdigo en cualquier
bsquedaactivadeproyectosparavercmotrabajan.
momento.
lhaexploradoafondolosmtodosgiles,haciendonfasis
Integr acincontinua.Cadapiezadecdigoesintegrada
enlafamiliademetodologasCrystal.Esunafamiliaporque
enelsistemaunavezqueestlista.As,elsistemapuedellegar
creequelosdiferentestiposdeproyectosrequierendiferentes
aserintegradoyconstruidovariasvecesenunmismoda.
tiposdemetodologas.lmiraestavariacinalolargodedos
40hor asporsemana.Sedebetrabajarunmximode40 ejes:elnmerodepersonasenelproyecto,ylasconsecuencias
horasporsemana.Nosetrabajanhorasextrasendossemanas deloserrores.Cadametodologaencajaenunapartediferente,
seguidas. Si esto ocurre, probablemente est ocurriendo un demodoqueparaunproyectode40personasquepuedeperder
problemaquedebe corregirse.Eltrabajo extradesmotiva al dinerodiscrecionalmentetieneunametodologadiferenteala
equipo. deunproyectovitaldeseispersonas[8].
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 benecio de las prcticas se consigue con su
aplicacinconjuntayequilibradapuestoqueseapoyanunas
enotras.LamayoradelasprcticaspropuestasporXPnoson
novedosassinoqueenalgunaformayahabansidopropuestas
eningenieradelsoftwareeinclusodemostradosuvalorenla Figur a2.ClasicacindelasdiferentesmetodologasCristal[8]
prctica.ElmritodeXPesintegrarlasdeunaformaefectiva
y complementarlas con otras ideas desde la perspectiva del
negocio,losvaloreshumanosyeltrabajoenequipo. La familia de metodologas Crystal comparten con la XP
B.Crystal unaorientacinhumana,peroestacentralizacinenlagente
se hace de una manera diferente.Alistair considera que las
En este segmento del artculo se describen los aspectos personasencuentrandifcilseguirunprocesodisciplinado,as
principalesdelametodologaCrystal.Enprimerainstanciase quemsqueseguirlaaltadisciplinadelaXP,Alistairexplora
especicanlosantecedentesdelametodologa,continuando lametodologamenosdisciplinadaqueaunpodratenerxito,
condenicionesqueayudanaestructurarlafundamentacin intercambiandoconscientementeproductividadporfacilidadde
tericayseterminacon lascaractersticas esencialesdelos ejecucin.lconsideraqueaunqueCrystalesmenosproductivo
diferentestiposdeCrystal. quelaXP,mspersonasserncapacesdeseguirlo.
Antecedentes Alistairtambinponemuchopesoenlasrevisionesalnal
Enlosiniciosde1990,enunestudiorealizadoenIBMse de la iteracin, animando al proceso a aplicar tcnicas de
llegalossiguientesacuerdos(Cockburn,2001): mejoramientocontinuoenformaautomtica.Suasercines
queeldesarrolloiterativoestparaencontrarlosproblemas
Losequiposexitososenfatizabanquenohabanseguido

LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
temprano, y entonces permitir corregirlos. Esto pone ms
nfasis en la gente supervisando su proceso y anndolo
conformedesarrollan[8].
Deniciones
Setratadeunconjuntodemetodologasparaeldesarrollode
softwarecaracterizadasporestarcentradasenlaspersonasque
componenelequipoylareduccinalmximodelnmerode
artefactosproducidos.Eldesarrollodesoftwareseconsidera
unjuegocooperativodeinvencinycomunicacin,limitado
porlosrecursosautilizar.Elequipodedesarrolloesunfactor
clave,porloquesedebeninvertiresfuerzosenmejorarsus
habilidades y destrezas, as como tener polticas de trabajo
en equipo denidas. Estas polticas dependern del tamao
delequipo,establecindoseunaclasicacinporcolores,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,conabilidad,proteccin
legal,entreotros.
Las personas se comunican mejor cara a cara, con la
preguntaylarespuestaenelmismoespaciodetiempo.
Elfactormssignicativoescomunicacin.
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 en una mesa, con una historia de usuario o funcin visible
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.
165
3.Mejorareexiva.Tomarseunpequeotiempo(unaspocas
horas cada o una vez al mes) para pensar bien qu se est
haciendo,cotejarnotas,reexionar,discutir.
4.Seguridadpersonal.Hablarconloscompaeroscuando
algomolestadentrodelgrupo.
5.Foco.Saberloqueseesthaciendoytenerlatranquilidad
yeltiempoparahacerlo.
6.Fcilaccesoausuariosexpertos.Teneralgunacomunicacin
conexpertosdesarrolladores.
CrystalClearnorequiereningunaestrategiaotcnica,pero
siempreestiltenerunascuantasamanoparaempezar.Las
estrategiascomunesaotrasMetodologasgiles,son:
1.Exploracinde360.Vericarotomarunamuestradel
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
modica.
5. Radiadores de informacin. Es una lmina pegada en
algnlugarqueelequipopuedaobservarmientrastrabajao
camina.Tienequesercomprensibleparaelobservadorcasual,
entendidadeunvistazoyrenovadaperidicamenteparaque
valgalapenavisitarla.
Encuantoalastcnicas,sefavorecen:
1.Entrevistasdeproyectos.Sesueleentrevistaramsdeun
responsableparatenervisionesmsricas.
2. Talleres de reexin. El equipo debe detenerse treinta
minutosounahoraparareexionarsobresusconvenciones
detrabajo,discutirinconvenientesymejorasyplanearparael
perodosiguiente.
3. Planeamiento Blitz. Una tcnica puede ser el Juego de
PlaneamientodeXP.Enestejuego,seponentarjetasindexadas
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,sinodeidenticarlos.
6. Miniaturade procesos.Unaforma depresentarCrystal
Clearpuedeconsumirentre90minutosyunda.Laideaesque
lagentepuedadegustarlanuevametodologa.
7. Grcos de quemado. Sunombre vienedelos grcos
dequemadodecalorasdelosregmenesdietticosseusan
tambinenScrum.Setratadeunatcnicadegracacinpara
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,llamadaasporquesereerealagregadodetems
conaltaprioridadeneltopedelaslistasdetrabajospendientes,
esperandoquelosdemselementossehundanbajolalneade
otacinloselementosqueestnsobrelalneaseentregarnen Visualizacin.
laiteracinsiguiente,losqueestnpordebajoenlasrestantes.
EnotrasMetodologasgileslaListaTmpananoesotracosa
queungrcoderetraso.Losgrcosdequemadoilustranla
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,Vericador,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
ydenelatotalidaddelproyecto.
2.UsuarioExperto.JuntoconelExpertoenNegociosproduce
laListadeActoresObjetivosyelArchivodeCasosdeUsoy
Requerimientos.Debefamiliarizarseconeluso delsistema,
sugeriratajosdeteclado,modosdeoperacin,informacina
visualizarsimultneamente,navegacin.
3.DiseadorPrincipal.ProducelaDescripcinArquitectnica.
SesuponequedebeseralmenosunprofesionaldeNivel3.
(EnMetodologasgilessedenentresnivelesdeexperiencia:
Nivel 1 es capaz de seguir los procedimientos Nivel 2
es capaz de apartarse de los procedimientos especcos 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
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
delEquipoylosResultadosdelTallerdeReexin[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].

LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
El Scrum se ha desarrollado teniendo como principios
fundamentales:
ElprincipiodeincertidumbredeZivenlaingeniera
delsoftware:laincertidumbreesinherenteeinevitableenel
procesodedesarrollodeproductosdesoftware[16].
PrincipioderequisitosindenidosdeHumphrey: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 indenido y
usamecanismosdecontrolparaperfeccionarlaexibilidad,
manipularloimpredecibleyelcontroldelriesgo[15].
Car acter sticasdelproceso
LascaractersticasesencialesdelprocesodeScrumson:
Laprimerayltimafase(planicacinyclausura)consisten implementados.Estafaseincluyelacreacinmodicacin
en procesos denidos, donde todos los procesos, entradas y
salidasestnbiendenidas.Elconocimientodecmohacer
estosprocesosesexplcitoysetratadehacerunrepositoriode
todaslasactividadesarealizar(BacklogSystem).
SedesarrollaniteracionesmensualesllamadasSprint.El
equipodedesarrollodecidequefuncionalidadincluironoen
cadaiteracinestimndoseeltiemponecesarioparaterminar
lastareas.LafasedelSprintesunprocesoemprico.Muchos
de losprocesosen estafasenoestnidenticadoso noson
controlados.
LosSprintssonnolinealesyexibles.Puedenserusados
procesosdeconocimientoexplcito.Cuandonoexistenestos
conocimientos explcitos dentro del equipo, los errores y
pruebasseusanparacrearprocesosdeconocimiento.
DentrodelosSprintsserealizanreunionesdiariasde15
minutos(ScrumMeetings)enloscualescadadesarrollador
darepuestaatrespreguntas:
1. Quhizodesdelaltimareunin?.
2. Qudicultadesconcretastieneeneldesarrollode
latarea?
3. Quvaahacerhastalaprximareunindiaria? desoftwareeducativo.Paracumplirconelobjetivoseplantean
Elproyectoesabiertohastalafasedeclausura.Laentrega
puedeser replanicadaen cualquieradelas fasesanteriores
mantenindose abierto a la complejidad del ambiente, la
competencia,tiempo,calidadypresionesnancieras,durante
eldesarrollodedichasfases.
Laentregadelproyectoescalculadasobrelainuenciadel
ambiente.
LametodologaScrumestdiseadaparaserexibledurante
eldesarrollodelossistemas.Proveedemecanismosdecontrol
167
paraplanicarunaentregadelproductoymanejarlasvariables
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
unamagnicaoportunidaddeentrenamientoenelambiente.
Fases
LasdiferentesfasesdelScrumconsistenen:
Prejuego
Planicacin: denicin 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
delaarquitecturadelsistemayeldiseodealtonivel.
Juego
DesarrollodelosSprints:desarrollodeunanuevafuncionalidad
enconstantemiraalasvariablestiempo,requerimientoscalidad,
costoycompetencia.Lainteraccinconestasvariablesdeneel
naldeestafase.SonmltipleslosSprintsociclosusadospara
desarrollarelsistema.DentrodelSprintlaretroalimentacinse
obtieneconlasreunionesdiarias(ScrumMeetings)yelcontrol
delacurvadeprogreso.
Postjuego
Clausura: preparacin para la entrega, incluyendo la
documentacinnal,pruebayentrega.
IV.ORIENTACIONESPARALAINGENIERADESOFTWARE
EDUCATIVOAPARTIRDEALGUNASCARACTERSTICASDE
LASMETODOLOGASDEDESARROLLOGIL
Estaseccintienecomoobjetivoarticulardiferentestpicos
delaingenieradelsoftwarecomosonelenfoqueclsico,los
enfoquesmodernosylasmetodologasdedesarrollogilpara
proponeralgunasorientacionesparaelprocesodedesarrollo
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 especicarlosnivelesdearticulacinentrelosdiferentespilares
comosemuestraenlagura7:
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 Figur a3.Pilaresconceptualesfaseplaneacin.
proponenlossiguientesperles:
Entre los aspectos educativos se deben contemplar tems
Ungerentedeproyecto:Eselencargadodeestablecer, como el modelo pedaggico que debe soportar el software
operacionalizarycontrolarlaspolticasdelproyecto. educativoarticuladoconelusodelasnuevastecnologas.Enla
especicacindeestepilarconceptualesdonderadicalamayor
Unanalista:Eslapersonaencargadadeconstruirel
diferenciaconunametodologautilizadaparaeldesarrollode
modelodeanlisis(funcional,datosydinmico)delsistema
unsoftwaretradicional.
desoftware.
Deigualforma,enestesegmentosedebenespecicarlas
Unexpertoenrequerimientos:Eslapersonaencargada
estrategiasdidcticasalascualesdeberesponderelsoftware
deidenticarlasfuncionalidadesquenecesitaelclienteenel
educativo.
sistema.
Entre los aspectos tecnolgicos se deben describir los
Undiseador:Eslapersonaencargadadeconstruir
componentes de hardware, software y comunicaciones que
laarquitecturadelsistemajuntoconsusrespectivasmaquetas
soportanlaimplementacindelsoftwareeducativo.
yrutasdenavegacin.
Entre los aspectos conceptuales se deben especicar los
UnexpertoenInformticaeducativa:Eslapersona
contenidosquesepretendentransmitiratravsdelsoftware
encargadadeemitirconceptosrelacionadosconlosmodelos
educativo.
pedaggicos apropiados para la construccin de software
educativo. Entrelosaspectosmetodolgicossedebendescribirtodas
aquellas actividades y estrategias que deben acompaar
Un desarrollador o varios dependiendo del tamao
el uso del software educativo en el proceso de enseanza
delproyecto:Sonlaspersonasencargadasdeimplementarlas
aprendizaje.
funcionalidadesdelsistema.
Losaspectosorganizacionalesdebendetallartodasaquellas
Elcliente(docenteoestudiante):Sonlaspersonasque
actividades relacionadas con la gestin que garanticen el
vanautilizaryprobarelsistema.
correctoprocesodedesarrolloeimplementacindelsoftware
Entre la denicin de las polticas se puede empezar por educativo.
denirlospilaresconceptualesfundamentalessobreloscuales
Obtencinderequerimientos
se deben construir los procesos de desarrollo de software
educativo.Amaneradepropuestasesugierenlossiguientes Un requerimiento es una caracterstica que debe tener el
pilares: sistema o una restriccin que debe satisfacer para que sea
aceptado por el cliente. En esta fase nos enfocamos en la
Aspectoseducativos.
obtencinderequerimientosbasadosenescenariosycasosde
Aspectostecnolgicos. uso.Losdesarrolladoresobtienenlosrequerimientosapartir
de entrevistas con los usuarios que en este caso pueden ser
Aspectosconceptuales.
losdocentesy estudiantesquevanutilizarelsistema,luego
Aspectosmetodolgicos. desarrollan escenarios visionarios en donde se describe la
Aspectosorganizacionales. funcionalidadqueproporcionarelsistemafuturo.Elcliente
ylosusuariosvalidanladescripcindelsistemarevisandolos
Esimportanteresaltarqueenlafasedeplaneacinsedeben escenarios y probando prototipos pequeos proporcionados

LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
por los desarrolladores. Conforme madurayse estabiliza la
denicindelsistema,losdesarrolladoresyelclienteseponen
deacuerdoenunaespecicacindelsistemaenformadecasos
deuso.Paracadacasodeusosedebenespecicarlosujos que incluye una descripcin clara de cada una de estas
bsicosyujosalternativosenformasencilla.
Laobtencinderequerimientosseenfocaenladescripcin
delpropsitodelsistema.Elcliente,losdesarrolladoresylos
usuariosidenticanunreaproblemaydenenunsistemaque
atacaelproblema.Ataldenicinselellamaespecicacin dearquitecturaenformageneralyunalistaderequerimientos
delsistema.
Como producto de esta fase se debe producir un modelo
de casos de uso acompaado de un documento donde se
especiquenlosrequerimientosnofuncionales.
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 vericable.
El cliente y el usuario estn involucrados, por lo general,
en esta actividad, en especial cuando se necesita cambiar
la especicacin 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, consistenteyvericable.El anlisisse diferencia
delaobtencinderequerimientosenquelosdesarrolladores
se enfocan en la estructuracin y formalizacin de los
requerimientosobtenidosdelosusuarios.Aunquepuedeser
queelmodelodeanlisisnoseacomprensibleparalosusuarios
y el cliente, ayuda a que los desarrolladores veriquen la
especicacindelsistemaproducidadurantelaobtencinde
requerimientos.
Comoproductodeestafasesedebeproducirunmodelode
clasessiesnecesarioacompaadodelrenamientodelmodelo
de casos de usogeneradoen lafaseanterior,estosmodelos
deben ser desarrollados solo a nivel de diagramas de UML
solosedebenespecicarconmayordetalleencasodequelos
clienteslorequieren.
Diseo
Eldiseo desistemas esla transformacindelmodelode
anlisisenunmodelodediseodelsistema.Duranteeldiseo
delsistemalosdesarrolladoresdenenlosobjetivosdediseo
delproyectoydescomponen elsistema ensubsistemas ms
pequeosquepuedenserrealizadosporequiposindividuales.
Los desarrolladores tambin seleccionan estrategias para la
construccin del sistema, como la plataforma de hardware
ysoftwareenlaqueseejecutarelsistema,laestrategiade
169
almacenamientodedatospersistentes,elujodecontrolglobal,
la polticadecontrol de acceso y el manejo de condiciones
defrontera.Elresultadodeldiseodelsistemaesunmodelo
estrategias,unadescomposicinensubsistemasyundiagrama
de organizacin que representa la correspondencia entre el
hardwareyelsoftwaredelsistema.
Enformaespeccaenestaetapasedebegenerarunmodelo
nofuncionalesuobjetivosdediseo.
Enestaetapadediseosedebehacernfasisentrestiposde
diseoadicionalquesonlossiguientes:
1. Diseoeducativo
2. Diseodecomunicacin
3. Diseocomputacional
Diseoeducativo
Debe resolverlos interrogantesquesereerenalalcance,
contenidoytratamientoquedebesercapazdeapoyarelsistema.
En este tipo de diseo se debe prestar especial atencin al
modelo pedaggico para disear las actividades del sistema
deacuerdoalmodeloofusindemodelossobreloscualesse
quiereimplementarelsistema.
Apartirdelasnecesidadesdelosusuariosnalesdelsistema
se debe implementar el sistema que responda a ellas y al
contextoenelquesedesenvuelveelusuarional.
Sedebeutilizarunapropuestademodelopedaggicoquesirva
comoejetransversalenelprocesodeenseanzaaprendizaje
quesevaasoportarconelsistemadesoftware.Estemodelo
pedaggicodebeservircomomedioparaincorporaralusuario
nalloscontenidosquenecesitaparaalcanzarelperlquese
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
Enestaseseccinsepretendeespecicarlaformacomose
comunicaelusuarioconelprograma,estableciendodispositivos
ycdigosomensajes.Bsicamenteestafasecorrespondealo
quecomnmentesedenominadiseodeinterfaces.
Enlagurasedescribenlosaspectosquesedebenteneren
cuentaeneldiseodecomunicacin:
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.
Enlagurasedescribenlosaspectosquesedebenteneren aportesencuantoametodologasdedesarrollodesoftware.
cuentaeneldiseocomputacional:
Figur a6.Elementosdiseocomputacional
Enlaguraseobservaqueparaeldiseocomputacionalse
debenmaterializarlasfuncionalidadesdetodoslosusuariosa
travsdediagramasdecasosdeuso,deigualformasedeben
especicar 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, especicado por los modelos del
sistema,yelcomportamientoobservadodelsistema.
Las pruebas son el proceso de anlisis de un sistema, o
componentedeunsistema,paradetectarlasdiferenciasentre
el comportamiento especicado (requerido) y el observado
(existente). El objetivo de las pruebas es aumentar la
conabilidaddelsistema.
Entrminoseducativosserecomiendarealizarpruebaspilotos
ypruebasdecampoconpotencialesusuariosdelsistemaycon
otrosdesarrolladoresdiferentesalasdelequipo.
Evaluacin
Es de vital importancia para los procesos de enseanza
aprendizajedeterminarenlafasederequerimientosinstrumentos
deevaluacinquepuedenseractividadesdentrodelsistema
conloscualessepuedanmedirelniveldecumplimientode
losobjetivosparacadaunodeloscontenidosquesepretenden
desarrollarenelsistema.
CONCLUSIONES
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
Estas tendencias se conocen tambin con el nombre de
mtodoslivianosysonapropiadosparapequeosequiposde
desarrollo.
Laagilidadsepuededenircondoscaracterizaciones[11]:
Agilidad es la habilidad para crear y responder a
cambiosdeacuerdoalosbeneciosenunambientedenegocios
turbulento.
Agilidadeslahabilidadparabalancearexibilidady
estabilidad.
En este sentido la agilidad de los mtodos de desarrollo
softwaresepuedesintetizarenlacapacidadpararesponderal
 171
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

cambioyparasimplicarlosprocesos. REFERENCIAS
[1]Abrahamsson,P.,Salo,O.,Ronkainen,J.,Warsta,J..Agilesoftware
La propuesta metodolgica para el desarrollo de software
developmentmethodsReviewandanalysis..VTTPublications.
educativodescribe un conjunto defases que permiten guiar 2002.
el proceso de desarrollo de productos software que apoyen [2]Beck,K..ExtremeProgrammingExplained.EmbraceChange,
el proceso enseanzaaprendizaje. Esta propuesta tiene la Pearson Education, 1999. Traducido al espaol como: Una
particularidad que permite articular aspectos educativos, explicacin de la programacin extrema.Aceptar el cambio,
tecnolgicos,conceptuales,metodolgicosyorganizacionales AddisonWesley,2000.
deunamanerarpidasincaerenprincipiosdelasmetodologas [3]Boehm,B.Turner,R.BalancingAgilityanddiscipline.Aguide
tradicionalescomoeslaorientacinalproceso. forthePerplexed.AddisonWesley.2003.
[4]Bruegge,B.,Dutoit,A.Ingenieradesoftwareorientadaaobjetos.
De igual forma, la propuesta permite adaptar procesos PearsonEducacin.Mxico,2002.
de desarrollo que requieran altos niveles de documentacin [5]Cans,J.,Letelier,P.yPenads,M.Metodologasgilesenel
y orientacin al proceso, adicionalmente tambin permite desarrollo de Software. Universidad Politcnica de Valencia,
adaptarseaproyectosdedesarrollodesoftwareeducativode Valencia,2003.
grantamao. [6]Caro,G.Agilemaniestoyexperiencias personales.Memorias
JornadasdeGerencia.ACIS.Bogot2004.
De acuerdo a las caractersticas de las metodologas de [7]Cockburn,A.SelectingaProjectsMethodology,,Humansand
desarrollo gil como son el avance iterativo e incremental, Technology,IEEESOFTWAREJuly/August2000.
permitetenerrpidamenteprototiposfuncionalesquepueden [8] Cockbun,A. .Agile Software Development..AddisonWesley.
ser probados y evaluados en forma conjunta por un equipo 2001.
[9]Fowler,M.,Beck,K.,Brant,J.Refactoring:ImprovingtheDesign
conformadoporclientesydesarrolladores.
ofExistingCode.AddisonWesley.1999.
La propuesta metodolgica esta orientada a la generacin [10]Gutierrez,Joaquin.Metodologasgiles.UniversidadPablode
de prototipos funcionales en cada iteracin y no tanto a la Olavide.2007.
produccindeartefactos.Sinembargo,sepuedeadaptarala [11]Highsmith,J.AgileProjectManagement,2003
generacindeartefactos segn exijan los requerimientos de [12] Humphrey, W.S., Managing the Software Process,Addison
Wesley,Reading,MA,1989.
losclientes. [13]PoppendieckM.,PoppendieckT.LeanSoftwareDevelopment:
En forma general se puede afirmar que la propuesta AnAgileToolkitforSoftwareDevelopmentManagers.Addison
metodolgicapermite adaptarse aprocesos de desarrollo de Wesley.2003.
software educativo de diferentes tamaos, requerimientos y [14]Pressman,R.SoftwareEngineering:APractitionersApproach.
McGrawHill.2005.
nivelesdecomplejidad.
[15]Schwaber,k.AgileProjectManagementwithScrum(Microsoft
Professional).Mar10,2004.
[16]Ziv,H.yD.J.Richardson:,ICSE97,XIXInternationalConference
Lapropuestametodolgicaoconjuntodefasesdedesarrollo onSoftwareEngineering,23deagostode1996.
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.
172
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663