RevistaAvancesenSistemaseInformtica,Vol.5No.

2,Juniode2008,Medelln,ISSN16577663
LasMetodologasdeDesarrollogilcomounaOportunidad
paralaIngenieradelSoftwareEducativo
TheMethodologiesofAgileDevelopmentlikeanOpportunity
fortheEngineeringofEducativeSoftware
Recibidopararevisin3deAbrilde2008,Aceptado19deMayode2008,Versinnal24deMayode2008
ResumenLa ingenier a del soft war e educa t ivo se viene
convir tiendoenunreadeestudioconaltosnivelesdeaplicacin
debido a que cada vez los pr ocesos de desar rollo de sistemas de
softwar eeducativosellevanacaboempleandometodologasdela
Ingenier adelsoftwar e.
Las aplicaciones de softwar e educativo desar r olladas en pocas
pasadasen la gr an mayor a de los casossur gan de esfuer zos de
docentesconalgunosconocimientoseninfor mticaoensudefecto
deingenier osconalgunosinter esesenelsect oreducativo.
Otrofactorimpor tanteaanalizaresquelasmetodologasofrecidas
por la ingenier adelsoftware educativoson demasiado pesadas,
entonces debido a est e ar gumento en el pr esente documento se
est udianlos enfoques tr adicionales,los enfoques moder nos y las
metodologas giles par a ofr ecer una pr opuesta metodolgica
menospesadapar alaingenier adelsoftwareeducativo.
Palabrasclave: Ingenier adelSoftwar e,Metodologagil,Modelo
Pedaggico,DiseoEducativo,DiseoComputacional.
Abstr act Educat ional softwar e engineer ing is becoming a
r esear ch eldwith high levelsofapplicationduetothefactthat
thedevelopmentprocessesofeducationalcomputer softwareare
increasinglyapplyingsoft war eengineer ingmethodologies.
Mostpr eviouseducationalsoftwareapplicationsarosefromeither
the effor ts of teacher s with some knowledge of computing or
systemsengineer swithinter estsintheeducationalsector.
Anotherimpor tantissuewhichneedstobeanalyzedisthefactthat,
inthepast,educationalsoftwar eengineer ingmet hodologieswere
tooheavy.Duetothisar gument,inthiswor kbothtr aditionaland
moder nmethodologiesaswellasfastandeffectivemethodologies
will be st udied in or der to put for war d a mor e manageable
methodologicalpr oposalforeducationalsoftwar eengineer ing.
Keywords:Softwar eEngineer ing,FastMethodology,Pedagogical
Model,EducationalDesign,ComputerDesign.
AilinOrjuelaDuarte,MSc.,MauricioRojasC.,MSc.
GrupodeinvestigacinCICOM,UniversidaddePamplona,Colombia
aorjuela@unipamplona.edu.co,mrojas@unipamplona.edu.co
I.INTRODUCCIN
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
esenciales deestas metodologas para adaptarlas al contexto
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].
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 cuanto a los objetivos, la investigacin documental se
orienthacialaidenticacindemetodologasdediseo,que
contienenlosmtodos,lasherramientasylosprocedimientos
especficos para la construccin de software. Despus de
160
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663
esta fase se articulan las caractersticas de las metodologas
gilesparaproponeralgunasorientacionesparaelprocesode
desarrollodesoftwareeducativo.
Elrestodelpresentedocumentoestorganizadocomosigue.
Enlaseccin2seintroducenlasprincipalescaractersticasde
lasmetodologasgiles,recogidasenelManiestoysehace
unacomparacinconlastradicionales.Laseccin3secentra
eneXtremeProgramming(XP),presentandosuscaractersticas
particulares, el proceso que se sigue y las prcticas que
propone y se citan otras metodologas giles, 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 los apartes que se describen estn 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 The Agile 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
en Salt Lake City para tratar sobre tcnicas y procesos para
desarrollarsoftware.EnlareuninseacueltrminoMtodos
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:
Alindividuoylasinteraccionesdel equipodedesarrollo
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 el cliente y el equipo de desarrollo. 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. El dilogocara acaraes elmtodo msecientey
efectivoparacomunicarinformacindentrodeunequipode
161
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
desarrollo.
7. El software que funciona es la medida principal de
progreso.
8. Los procesos giles promueven un desarrollo
sostenible.
9. La atencin continua a la calidad tcnica y al buen
diseomejoralaagilidad.
10. Lasimplicidadesesencial.
11. Lasmejoresarquitecturas,requisitosydiseossurgen
delosequiposorganizadosporsmismos.
Tabla1.Comparacindelasmetodologastradicionalesylasgiles
12. Enintervalosregulares,elequiporeexionarespecto
a cmo llegar a ser ms efectivo, y segn esto ajusta su
comportamiento[5].
C. Compar a cin entre metodologas giles y
metodologastradicionales
Enlatabla1semuestranlasprincipalesdiferenciasdelas
metodologas giles con respecto a las tradicionales. Estas
diferencias hacen referencia de igual manera a aspectos
organizacionalesyalprocesodedesarrollo[5].
Deacuerdoalatabla1sepuedeobservarquelasmetodologas
dedesarrollogilsonmsorientadasaprocesosdedesarrollo
desoftwaredepocassemanasdedesarrolloyconbajosniveles
deformalizacinenladocumentacinrequerida.
Acontinuacinsedescribenconmayorniveldeespecicacin
lasprincipalessemejanzasydiferenciasdelasmetodologas
gilesylasmetodologaspesadas:
Prcticas de desarrollo: En las metodologas de desarrollo
gil se procura realizar los procesos de software de acuerdo
a las prcticas que le han dado resultados al grupo. En las
metodologas pesadas se desarrolla de acuerdo a las normas
sugeridasporlosestndaresdedesarrollo.
Adaptacin al cambio: En las metodologas giles por la
mismacapacidaddereaccinsonmsadaptablesaloscambios,
porelcontrarioenlasmetodologaspesadasporelnivelde
formalidadenlafasederequerimientossonmsresistentes
alcambio.
Control: Por su capacidad de adaptacin el proceso se
hacemenoscontroladoqueenlasmetodologastradicionales
que ejercen mayor control en el proceso por su nivel de
formalizacin.
Documentacin:Enlasmetodologasgilesnosehacenfasis
en la documentacin ni en los artefactos a diferencia de las
metodologaspesadas.
Equipo de trabajo: En las metodologas giles existen
bajo nmero de participantes y roles, por el contrario en las
metodologaspesadassesugierenlosrolesqueproporcionan
lasnormas.
En conclusin de acuerdo a la tabla se da prioridad: a los
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
eranmssencillasque lasactuales.Erasucienteunoodos
programadores,quedeacuerdoasusconocimientosyenun
plazo razonable de tiempo eran capacesdehacer programas
tiles.Elprogramadoreraunaespeciedemagoquehacasu
aplicacinyslolsabacmofuncionaba.Siacaso,despus
dehacerelprogramahacaunujogramadelosantiguos,no
habaUML,orientacinaobjetosnicosasporelestilo.
Con el paso de los aos las aplicaciones fueron cada vez
msexigentes,loscomputadoresdisponandemsmemoriay
aparecieronlosentornosdeventanas.
Lo anterior origin que los programas aumentaran su
tamao y se complicaran enormemente, requiriendo varios
desarrolladoresytiemposmslargos.Todoestollevconsigo
la necesidad de ms organizacin y documentacin. En este
contexto,aparecieronlasmetodologasdedesarrollopesadas
(lasquesebasanenescribirmuchadocumentacin).Antesde
hacerunprograma,fuenecesarioescribirquesequerahacer,
deformaqueseasegurabaunacuerdoentreelclienteylos
desarrolladoresacercadeloquesequerahacer.
Luego se escriba lo qu se iba a hacer, para que los
programadores t rabajaran con un objetivo comn y
organizado.
De algunaforma,todaestaorganizaciny documentacin
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
quehabamenos papeleo,las cosaseran ms sencillas ylos
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
como especialmente adecuada para proyectos con requisitos
imprecisosymuycambiantes[2].
Car acter sticas
Acontinuacinsedescribenlascaractersticasesencialesde
XPorganizadasenlosapartadossiguientes:historiasdeusuario,
roles,procesoyprcticas.
LasHistor iasdeUsuar io
Corresponden a la tcnica utilizada para especicar los
requisitosdelsoftware.Setratadeformatosenloscuales el
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].
A efectos de planicacin,las historias puedenserde una
a tres semanas de tiempo de programacin (para no superar
el tamao de una iteracin). Las historias de usuario son
descompuestas en tareas de programacin (Task Card) y
asignadasalosprogramadoresparaserimplementadasdurante
unaiteracin[2].
Una historia de usuario en forma general puede contener
los siguientes tems, los cuales pueden variar de acuerdo al
equipo de desarrollo. Estos aspectos pueden ser: fecha, tipo
de actividad (nueva, correccin, mejora), prueba funcional,
nmerodehistoria,prioridadtcnicaydelcliente,referencia
aotrahistoriaprevia,riesgo,estimacintcnica,descripcin,
notasyunalistadeseguimientoconlafecha,estado,cosaspor
terminarycomentarios.
RolesXP
Lapropuesta originalde Beck incluye los siguientes roles
[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 seguimient o (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.
Gest or (Big boss). Es el vnculo entre clientes y
programadores, ayudaa que el equipo trabaje efectivamente
creando las condiciones adecuadas. Su labor esencial es de
coordinacin.
ProcesoXP
Elciclodedesarrolloconsisteenlossiguientespasos:
1.Elclientedeneelvalordenegocioaimplementar.
2. El programador estima el esfuerzo necesario para su
implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus
prioridadesylasrestriccionesdetiempo.
4.Elprogramadorconstruyeesevalordenegocio.
5.Vuelvealpaso1.
Entodaslasiteracionesdeesteciclotantoelclientecomoel
programadoraprenden.Nosedebepresionaralprogramadora
realizarmstrabajoqueelestimado,yaqueseperdercalidad
enelsoftwareonosecumplirnlosplazos.
Delamismaformaelclientetienelaobligacindemanejarel
mbitodeentregadelproducto,paraasegurarsequeelsistema
tengaelmayorvalordenegocioposibleconcadaiteracin.
Figur a1.ProcesoXP
El ciclo de vida ideal de XP consiste de seis fases [2]:
Exploracin,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. Producir rpidamente versionesdel
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
y hacerloms exible para facilitarlosposteriores cambios.
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
problema que debe corregirse. El trabajo extra desmotiva al
equipo.
Client e insitu. El cliente tiene que estar presente y
disponibletodo eltiempoparael equipo. ste es unodelos
principalesfactoresdexitodelproyectoXP.Elclienteconduce
constantemente el trabajo hacialo que aportarmayor valor
de negocio y los programadores pueden resolver de manera
inmediatacualquierdudaasociada.Lacomunicacin orales
msefectivaquelaescrita.
Estndaresdeprogramacin.XPenfatizaquelacomunicacin
de los programadores es a travs 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
especican los antecedentes de la metodologa, continuando
condenicionesqueayudanaestructurarlafundamentacin
terica y se termina con las caractersticas esenciales de los
diferentestiposdeCrystal.
Antecedentes
Enlosiniciosde1990,enunestudiorealizadoenIBMse
llegalossiguientesacuerdos(Cockburn,2001):
Losequiposexitososenfatizabanquenohabanseguido
mtodos formales ni herramientas CASE y que haban
estimuladolacomunicacinylostest.
Los equipos con problemas no entendan sus fallas o si
habancumplidoconlosmtodosformales.
Laconclusin:Menosnfasisenladocumentacinexhaustiva
y ms en versiones que corran y puedan ser probadas. Lo
primero son promesas, lo segundo hechos. Cada proyecto
necesitasuspropiosmtodos.
Alistair Cockburn en lugar de partir solamente de su
experienciapersonalparaconstruirunateoradecmodeben
hacerselascosas,complementasuexperienciadirectaconla
bsquedaactivadeproyectosparavercmotrabajan.
lhaexploradoafondolosmtodosgiles,haciendonfasis
enlafamiliademetodologasCrystal.Esunafamiliaporque
creequelosdiferentestiposdeproyectosrequierendiferentes
tiposdemetodologas.lmiraestavariacinalolargodedos
ejes:elnmerodepersonasenelproyecto,ylasconsecuencias
deloserrores.Cadametodologaencajaenunapartediferente,
demodoqueparaunproyectode40personasquepuedeperder
dinerodiscrecionalmentetieneunametodologadiferenteala
deunproyectovitaldeseispersonas[8].
Figur a2.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
mejoramiento continuo en formaautomtica.Su asercines
queel desarrollo iterativo estpara encontrarlosproblemas
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, por lo que se deben invertir esfuerzos en mejorar sus
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
Las personas, como dispositivos activos, tienen modos de
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
integrantes Amarillo, para 8 a 20 Naranja, para 20 a 50
Rojo,para50a100.Lamsexhaustivamentedocumentadaes
CrystalClear(CC),yeslaquesehadedescribiracontinuacin.
CC puedeser usado en proyectos pequeos. El otro mtodo
elaboradoenprofundidadeselNaranja,aptoparaproyectos
de duracin estimada en 2 aos. Los otros dos an se estn
desarrollando.Comocasitodoslosotrosmtodos,CCconsiste
envalores,tcnicasyprocesos.Lossietevaloresopropiedades
deCCson:
1. Entrega frecuente. Consiste en entregar software a los
clientesconfrecuencia,nosolamenteencompilarelcdigo.
Lafrecuenciadependerdelproyecto,peropuedeserdiaria,
semanalomensual.
2.Comunicacinosmtica.Todosjuntosenelmismocuarto.
Una variante especial es disponer en la sala de un experto
diseadorseniorydiscutirrespectodeltemaquesetrate.
3.Mejorareexiva.Tomarseunpequeotiempo(unaspocas
horas cada o una vez al mes) para pensar bien qu se est
haciendo,cotejarnotas,reexionar,discutir.
4. Seguridadpersonal.Hablar con loscompaeroscuando
algomolestadentrodelgrupo.
5.Foco.Saberloqueseesthaciendoytenerlatranquilidad
yeltiempoparahacerlo.
6.Fcilaccesoausuariosexpertos.Teneralgunacomunicacin
conexpertosdesarrolladores.
CrystalClearnorequiereningunaestrategiaotcnica,pero
siempreestiltenerunascuantasamanoparaempezar.Las
estrategiascomunesaotrasMetodologasgiles,son:
1. Exploracinde360.Vericar otomarunamuestra del
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
algnlugarqueel equipo pueda observar mientras trabaja o
camina.Tienequesercomprensibleparaelobservadorcasual,
entendidadeunvistazoyrenovadaperidicamenteparaque
valgalapenavisitarla.
Encuantoalastcnicas,sefavorecen:
1.Entrevistasdeproyectos.Sesueleentrevistaramsdeun
responsableparatenervisionesmsricas.
2. Talleres de reexin. El equipo debe detenerse treinta
minutos o una hora para reexionar sobre sus convenciones
detrabajo,discutirinconvenientesymejorasyplanearparael
perodosiguiente.
3. Planeamiento Blitz. Una tcnica puede ser el Juego de
PlaneamientodeXP.Enestejuego,seponentarjetasindexadas
en una mesa, con una historia de usuario o funcin visible
en cada una. El grupo nge que no hay dependencias entre
tarjetas,ylasalineaensecuenciasdedesarrollopreferidas.Los
programadoresescribenencadatarjetaeltiempoestimadopara
desarrollar cadafuncin.El patrocinador delusuarioescribe
la secuencia de prioridades, teniendo en cuenta los tiempos
referidosyelvalordenegociodecadafuncin.Lastarjetasse
agrupanenperodosdetressemanasllamadositeracionesquese
agrupanenentregas,usualmentenomslargasdetresmeses.
4. Estimacin Delphi con estimaciones de pericia. En el
procesoDelphiserenenlosexpertosresponsablesyproceden
como en un remate para proponer el tamao del sistema, su
166
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663
tiempodeejecucin,lafechadelasentregassegndependencias
tcnicasydenegociosyparaequilibrarlasentregasenpaquetes
deigualtamao.
5.Encuentrosdiariosdepie.Lapalabraclaveesbrevedad,
cinco a diez minutos como mximo. No se trata de discutir
problemas,sinodeidenticarlos.
6. Miniatura de procesos. Una forma de presentar Crystal
Clearpuedeconsumirentre90minutosyunda.Laideaesque
lagentepuedadegustarlanuevametodologa.
7. Grcos de quemado. Su nombre viene de los grcos
de quemado decaloras de losregmenesdietticosse usan
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 prioridades cambian bruscamente 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 versin de Crystal Clear establece proximidad, pero cada
quiense enfoca asu trabajoasignado,prestandoun ojoalo
quehacesucompaero,quientienesupropiamquina.Esta
esunaampliacindelaComunicacinOsmticaalcontexto
delaprogramacin[10].
Hay ocho roles nominados en CC: Patrocinador, Usuario
Experto, Diseador Principal, DiseadorProgramador,
Experto en Negocios, Coordinador, Vericador, Escritor. En
Crystal Naranja se agregan aun ms roles: Diseador de IU
(Interfaz de Usuario), Diseador de Base de 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. Debe familiarizarse con el uso del sistema,
sugeriratajosdeteclado,modosdeoperacin,informacina
visualizarsimultneamente,navegacin.
3.DiseadorPrincipal.ProducelaDescripcinArquitectnica.
Sesupone quedebeseralmenosunprofesionaldeNivel3.
(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, los Borradoresde Pantallas, elModelo Comn de
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 destaca la reunin diaria
de 15 minutos del equipo de desarrollo 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
totalmente conocidos hasta que el usuario no lo haya usado
[12].
En Scrum inicialmente planean el contexto y un estimado
amplio de la entrega. Despus desarrollan el estimado de la
entrega basndose en desarrollo del ambiente del proyecto.
ElprocesodeciclodevidadeScrumreconocequeelproceso
de desarrollo fundamental est completamente indenido y
usa mecanismos decontrol paraperfeccionarla exibilidad,
manipularloimpredecibleyelcontroldelriesgo[15].
Car acter sticasdelproceso
LascaractersticasesencialesdelprocesodeScrumson:
Laprimerayltimafase(planicacinyclausura)consisten
en procesos denidos, donde todos los procesos, entradas y
salidas estnbiendenidas.Elconocimientode cmohacer
estosprocesosesexplcitoysetratadehacerunrepositoriode
todaslasactividadesarealizar(BacklogSystem).
SedesarrollaniteracionesmensualesllamadasSprint.El
equipodedesarrollodecidequefuncionalidadincluironoen
cadaiteracinestimndoseeltiemponecesarioparaterminar
lastareas.LafasedelSprintesunprocesoemprico.Muchos
de los procesos en esta fase no estn identicados o no son
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?
Elproyectoesabiertohastalafasedeclausura.Laentrega
puede ser replanicada en cualquiera de las fases anteriores
mantenindose abierto a la complejidad del ambiente, la
competencia,tiempo,calidadypresionesnancieras,durante
eldesarrollodedichasfases.
Laentregadelproyectoescalculadasobrelainuenciadel
ambiente.
LametodologaScrumestdiseadaparaserexibledurante
eldesarrollodelossistemas.Proveedemecanismosdecontrol
paraplanicarunaentregadelproductoymanejarlasvariables
enelprogresodelproyecto.Estopermitelaorganizacinpara
cambiar el proyecto y las entregas en cualquier punto del
desarrollo,entregandolaversinmsapropiada.
LametodologaScrumliberaalosdesarrolladoresainventar
las ms ingeniosas soluciones durante el proyecto, 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
Clausura: preparacin para la entrega, incluyendo la
documentacinnal,pruebayentrega.
IV.ORIENTACIONESPARALAINGENIERADESOFTWARE
EDUCATIVOAPARTIRDEALGUNASCARACTERSTICASDE
LASMETODOLOGASDEDESARROLLOGIL
Estaseccintienecomoobjetivoarticulardiferentestpicos
delaingenieradelsoftwarecomosonelenfoqueclsico,los
enfoquesmodernosylasmetodologasdedesarrollogilpara
proponeralgunasorientacionesparaelprocesodedesarrollo
desoftwareeducativo.Paracumplirconelobjetivoseplantean
una serie de fases o etapas por las cuales debe transitar el
procesodedesarrollodesoftwareeducativo,entrelascuales
proponemos:
1.Planeacin
2.Obtencinderequerimientos
3.Anlisis
4.Diseo
5.Implementacin
168
RevistaAvancesenSistemaseInformtica,Vol.5No.2,Juniode2008,Medelln,ISSN16577663
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.
De igual forma,eneste segmentose debenespecicarlas
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
contenidosque se pretenden transmitir a travs delsoftware
educativo.
Entrelosaspectosmetodolgicos se debendescribir todas
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
los docentes y estudiantes que van utilizar el sistema, luego
desarrollan escenarios visionarios en donde se describe la
funcionalidadqueproporcionarelsistemafuturo.Elcliente
ylosusuariosvalidanladescripcindelsistemarevisandolos
escenarios y probando prototipos pequeos proporcionados
6.Pruebas
7.Evaluacin
Planeacin
Durantelaplaneacinseproponelaconformacindelequipo
detrabajoyelestablecimientodelaspolticasdetrabajodel
proyecto, estas polticas deben estar enmarcadas en su gran
porcentajealfortalecimientodelosprocesosdeenseanzay
aprendizajeyalaincorporacindelasnuevastecnologasen
los ambienteseducativos. Es de vital importancia establecer
polticasencuantoaltrabajodelequipocomoson:elnfasisen
lacomunicacindelequipo,elnfasisenlaincorporacincasi
permanentedeldocentey/oestudianteenelequipo,elnfasis
eneldesarrolloincrementalatravsdeiteracionescortas.Es
deespecialimportanciaelfactordecolaboracinconelcliente
queenestecasoserialainstitucineducativa,eldocentey/o
el estudiante.Para la conformacin delequipo de trabajo se
proponenlossiguientesperles:
Ungerentedeproyecto:Eselencargadodeestablecer,
operacionalizarycontrolarlaspolticasdelproyecto.
Unanalista:Eslapersonaencargadadeconstruirel
modelodeanlisis(funcional,datosydinmico)delsistema
desoftware.
Unexpertoenrequerimientos:Eslapersonaencargada
deidenticarlasfuncionalidadesquenecesitaelclienteenel
sistema.
Undiseador:Esla personaencargada deconstruir
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.A manera depropuesta sesugieren los siguientes
pilares:
Aspectoseducativos.
Aspectostecnolgicos.
Aspectosconceptuales.
Aspectosmetodolgicos.
Aspectosorganizacionales.
Esimportanteresaltarqueenlafasedeplaneacinsedeben
especicarlosnivelesdearticulacinentrelosdiferentespilares
comosemuestraenlagura7:
169
LasMetodologasdeDesarrollogilcomounaOportunidadparalaIngenieradelSoftwareEducativoOrjuelayRojas
por los desarrolladores. Conforme madura y se 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, consistente y vericable. El anlisis se diferencia
delaobtencinderequerimientosenquelosdesarrolladores
se enfocan en la estructuracin y formalizacin de los
requerimientos obtenidosde los usuarios.Aunque puede ser
queelmodelodeanlisisnoseacomprensibleparalosusuarios
y el cliente, ayuda a que los desarrolladores veriquen la
especicacindelsistemaproducidadurantelaobtencinde
requerimientos.
Comoproductodeestafasesedebeproducirunmodelode
clasessiesnecesarioacompaadodelrenamientodelmodelo
de casos de uso generado en la fase anterior, estos modelos
deben ser desarrollados solo a nivel de diagramas de UML
solosedebenespecicarconmayordetalleencasodequelos
clienteslorequieren.
Diseo
El diseo de sistemas es la transformacin del modelo de
anlisisenunmodelodediseodelsistema.Duranteeldiseo
delsistemalosdesarrolladoresdenenlosobjetivosdediseo
del proyecto y descomponen el sistema en subsistemas ms
pequeosquepuedenserrealizadosporequiposindividuales.
Los desarrolladores tambin seleccionan estrategias para la
construccin del sistema, como la plataforma de hardware
y software en la que se ejecutar el sistema, la estrategia de
almacenamientodedatospersistentes,elujodecontrolglobal,
la poltica de control 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 resolver los interrogantes que se reeren al alcance,
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.
El modelo pedaggicoa utilizarenla implementacin del
software educativo debe estar articulado con aspectos de
relevante importancia como los contenidos, el ambiente o
contextoenelcualsedebendesarrollarloscontenidos.
Enformageneral,sepuedenvisualizarlosaspectosquese
debenteneren cuenta enel diseo educativo delasiguiente
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
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
deevaluacinquepuedenseractividadesdentro delsistema
conlos cualesse puedanmedirel niveldecumplimiento de
losobjetivosparacadaunodeloscontenidosquesepretenden
desarrollarenelsistema.
CONCLUSIONES
Losmtodosgilessonunareaccinalasformastradicionales
de desarrollo de software, admitiendo la necesidad de
una alternativa al desarrollo de software orientado a la
documentacinycentradosenelproceso.
Los mtodos giles de desarrollo de software han surgido
muyrecientementecomotendenciasnoampliamenteaceptadas
aun, pero con buena probabilidad de lograr interesantes
aportes en cuanto a metodologas de desarrollo de software.
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.
La propuesta metodolgica para el desarrollo de software
educativo describe un conjunto de fases 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
generacin de artefactos segn exijan los requerimientos de
losclientes.
En forma general se puede afirmar que la propuesta
metodolgica permite adaptarse a procesos 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. BalancingAgility and discipline.A guide
forthePerplexed.AddisonWesley.2003.
[4]Bruegge,B.,Dutoit,A.Ingenieradesoftwareorientadaaobjetos.
PearsonEducacin.Mxico,2002.
[5] Cans, J., Letelier, P. y Penads, M. Metodologas giles en el
desarrollo de Software. Universidad Politcnica de Valencia,
Valencia,2003.
[6] Caro, G.Agile maniesto y experiencias personales. Memorias
JornadasdeGerencia.ACIS.Bogot2004.
[7]Cockburn,A.Selecting aProjects Methodology,,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