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.

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.

Palabrasclave: Ingenier adelSoftwar e,Metodologagil,Modelo

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.

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.

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].

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.

Losintegrantesdelareuninresumieronlosprincipiossobre
losquesebasanlosmtodosalternativosencuatropostulados,
loquehaquedadodenominadocomoManiestogil[5].

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.

El manifiesto gil est fundamentado en los siguientes

valores:

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
gilesparadeniralosmtodosqueestabansurgiendocomo
alternativaalasmetodologasformales(CMMI,SPICE)alas
que consideraban excesivamente pesadas y rgidas por su
carcter normativo y fuerte dependencia de planicaciones
detalladaspreviasaldesarrollo.

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
trabajarjuntosalolargodelproyecto.
5.
Construirelproyectoentornoaindividuosmotivados.
Darleselentornoyelapoyoquenecesitanyconarenellos
paraconseguirnalizareltrabajo.
6.
Eldilogocaraacaraeselmtodomsecientey
efectivoparacomunicarinformacindentrodeunequipode

161
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

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

Lasimplicidadesesencial.

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].

11. Lasmejoresarquitecturas,requisitosydiseossurgen
delosequiposorganizadosporsmismos.

Tabla1.Comparacindelasmetodologastradicionalesylasgiles

Deacuerdoalatabla1sepuedeobservarquelasmetodologas
dedesarrollogilsonmsorientadasaprocesosdedesarrollo
desoftwaredepocassemanasdedesarrolloyconbajosniveles
deformalizacinenladocumentacinrequerida.

Control: Por su capacidad de adaptacin el proceso se

hacemenoscontroladoqueenlasmetodologastradicionales
que ejercen mayor control en el proceso por su nivel de
formalizacin.

Acontinuacinsedescribenconmayorniveldeespecicacin
lasprincipalessemejanzasydiferenciasdelasmetodologas
gilesylasmetodologaspesadas:

Documentacin:Enlasmetodologasgilesnosehacenfasis
en la documentacin ni en los artefactos adiferencia de las
metodologaspesadas.

Prcticasdedesarrollo:Enlasmetodologasdedesarrollo
gilseprocurarealizarlosprocesosdesoftwaredeacuerdo
a las prcticas que le han dado resultados al grupo. En las
metodologaspesadassedesarrolladeacuerdoalasnormas
sugeridasporlosestndaresdedesarrollo.

Equipo de trabajo: En las metodologas giles existen

bajonmerodeparticipantesyroles,porelcontrarioenlas
metodologaspesadassesugierenlosrolesqueproporcionan
lasnormas.

Adaptacin al cambio: En las metodologas giles por la

mismacapacidaddereaccinsonmsadaptablesaloscambios,
porelcontrarioenlasmetodologaspesadasporelnivelde
formalidadenlafasederequerimientossonmsresistentes
alcambio.

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.

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

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
aplicacinyslolsabacmofuncionaba.Siacaso,despus
dehacerelprogramahacaunujogramadelosantiguos,no
habaUML,orientacinaobjetosnicosasporelestilo.
Con el paso de los aos las aplicaciones fueron cada vez
msexigentes,loscomputadoresdisponandemsmemoriay
aparecieronlosentornosdeventanas.

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
implementarlaenunassemanas[2].
Aefectosdeplanicacin,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].

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.

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.

Luego se escriba lo qu se iba a hacer, para que los

programadores trabajaran con un objetivo comn y
organizado.

LapropuestaoriginaldeBeckincluyelossiguientesroles
[2]:

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

RolesXP

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

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:

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.

1.Elclientedeneelvalordenegocioaimplementar.

Figur a1.ProcesoXP

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

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
de reestructuracin del cdigo con el objetivo de remover
duplicacin de cdigo, mejorar su legibilidad, simplicarlo
yhacerlomsexibleparafacilitarlosposteriorescambios.
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.

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].

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
prctica.ElmritodeXPesintegrarlasdeunaformaefectiva
y complementarlas con otras ideas desde la perspectiva del
negocio,losvaloreshumanosyeltrabajoenequipo.

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

Figur a2.ClasicacindelasdiferentesmetodologasCristal[8]

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.
Alistairtambinponemuchopesoenlasrevisionesalnal
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 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
desarrollando.Comocasitodoslosotrosmtodos,CCconsiste
envalores,tcnicasyprocesos.Lossietevaloresopropiedades
deCCson:

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.

1. Entrega frecuente. Consiste en entregar software a los

clientesconfrecuencia,nosolamenteencompilarelcdigo.
Lafrecuenciadependerdelproyecto,peropuedeserdiaria,
semanalomensual.

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.

2.Comunicacinosmtica.Todosjuntosenelmismocuarto.
Una variante especial es disponer en la sala de un experto
diseadorseniorydiscutirrespectodeltemaquesetrate.

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
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
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
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].

167
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
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.

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
implementados.Estafaseincluyelacreacinmodicacin
delaarquitecturadelsistemayeldiseodealtonivel.
Juego
DesarrollodelosSprints:desarrollodeunanuevafuncionalidad
enconstantemiraalasvariablestiempo,requerimientoscalidad,
costoycompetencia.Lainteraccinconestasvariablesdeneel
naldeestafase.SonmltipleslosSprintsociclosusadospara
desarrollarelsistema.DentrodelSprintlaretroalimentacinse
obtieneconlasreunionesdiarias(ScrumMeetings)yelcontrol
delacurvadeprogreso.
Postjuego

LosSprintssonnolinealesyexibles.Puedenserusados
procesosdeconocimientoexplcito.Cuandonoexistenestos
conocimientos explcitos dentro del equipo, los errores y
pruebasseusanparacrearprocesosdeconocimiento.

Clausura: preparacin para la entrega, incluyendo la

documentacinnal,pruebayentrega.

DentrodelosSprintsserealizanreunionesdiariasde15
minutos(ScrumMeetings)enloscualescadadesarrollador
darepuestaatrespreguntas:

IV.ORIENTACIONESPARALAINGENIERADESOFTWARE
EDUCATIVOAPARTIRDEALGUNASCARACTERSTICASDE
LASMETODOLOGASDEDESARROLLOGIL

1.

Quhizodesdelaltimareunin?.

2.
Qudicultadesconcretastieneeneldesarrollode
latarea?
3.

Quvaahacerhastalaprximareunindiaria?

Elproyectoesabiertohastalafasedeclausura.Laentrega
puedeser replanicadaen cualquieradelas fasesanteriores
mantenindose abierto a la complejidad del ambiente, la
competencia,tiempo,calidadypresionesnancieras,durante
eldesarrollodedichasfases.

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

Laentregadelproyectoescalculadasobrelainuenciadel
ambiente.

3.Anlisis

LametodologaScrumestdiseadaparaserexibledurante
eldesarrollodelossistemas.Proveedemecanismosdecontrol

5.Implementacin

4.Diseo

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

6.Pruebas
7.Evaluacin

especicarlosnivelesdearticulacinentrelosdiferentespilares
comosemuestraenlagura7:

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
proponenlossiguientesperles:

Ungerentedeproyecto:Eselencargadodeestablecer,
operacionalizarycontrolarlaspolticasdelproyecto.

Unanalista:Eslapersonaencargadadeconstruirel
modelodeanlisis(funcional,datosydinmico)delsistema
desoftware.

Unexpertoenrequerimientos:Eslapersonaencargada
deidenticarlasfuncionalidadesquenecesitaelclienteenel
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 denicin de las polticas se puede empezar por
denirlospilaresconceptualesfundamentalessobreloscuales
se deben construir los procesos de desarrollo de software
educativo.Amaneradepropuestasesugierenlossiguientes
pilares:

Aspectoseducativos.

Aspectostecnolgicos.

Aspectosconceptuales.

Aspectosmetodolgicos.

Aspectosorganizacionales.

Esimportanteresaltarqueenlafasedeplaneacinsedeben

Figur a3.Pilaresconceptualesfaseplaneacin.

Entre los aspectos educativos se deben contemplar tems

como el modelo pedaggico que debe soportar el software
educativoarticuladoconelusodelasnuevastecnologas.Enla
especicacindeestepilarconceptualesdonderadicalamayor
diferenciaconunametodologautilizadaparaeldesarrollode
unsoftwaretradicional.
Deigualforma,enestesegmentosedebenespecicarlas
estrategiasdidcticasalascualesdeberesponderelsoftware
educativo.
Entre los aspectos tecnolgicos se deben describir los
componentes de hardware, software y comunicaciones que
soportanlaimplementacindelsoftwareeducativo.
Entre los aspectos conceptuales se deben especicar 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

169
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

por los desarrolladores. Conforme madurayse estabiliza la

denicindelsistema,losdesarrolladoresyelclienteseponen
deacuerdoenunaespecicacindelsistemaenformadecasos
deuso.Paracadacasodeusosedebenespecicarlosujos
bsicosyujosalternativosenformasencilla.
Laobtencinderequerimientosseenfocaenladescripcin
delpropsitodelsistema.Elcliente,losdesarrolladoresylos
usuariosidenticanunreaproblemaydenenunsistemaque
atacaelproblema.Ataldenicinselellamaespecicacin
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.

almacenamientodedatospersistentes,elujodecontrolglobal,
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.
Enformaespeccaenestaetapasedebegenerarunmodelo
dearquitecturaenformageneralyunalistaderequerimientos
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:

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

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:

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.

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
cuentaeneldiseocomputacional:

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
aportesencuantoametodologasdedesarrollodesoftware.
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.

Figur a6.Elementosdiseocomputacional

En este sentido la agilidad de los mtodos de desarrollo

softwaresepuedesintetizarenlacapacidadpararesponderal

171
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas

cambioyparasimplicarlosprocesos.
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.

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.

REFERENCIAS

[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.Agilemaniestoyexperiencias 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