Calidad de Software

Evaluacin de la calidad de cdigo usando TDD
en el desarrollo de la lgica de negocio

de un sistema de informacin
para un club deportivo

Autor
Francisco Jos Gmez-Caldito Viseas

Tutor
Jos Juan Hernndez Cabrera
(Departamento de Informtica y Sistemas)

Las Palmas de Gran Canaria, a 26 de noviembre de 2!"

A mis padres, que son la razn principal por la que, despus de
tantos aos, me embarcara de nueo en la !niersidad
A Jos Juan, mi tutor, que me conenci de que superara mis
inse"uridades # aceptara un $raba%o de Fin de Grado que de erdad me iba
a ensear a ser un me%or pro&esional
A mi esposa Jacqueline, por a"uantarme todos esos d'as que
entraba en (ataque de pnico)
A los tipos que crearon *tac+ ,er&lo-, # a todos aquellos que
o&recen sus aportaciones, sin las cuales me .abr'a encontrado ms de una
ez en un calle%n sin salida/
0 por 1ltimo, aunque no menos importante, a la "ente de
23epend, por esa licencia 4Academic *ponsor5 que me .a permitido
realizar el estudio usando su impresionante .erramienta, # a 6o7anne, que
tan amablemente me .a atendido en todos mis correos/
8uc.as "racias a todos/

#val$aci%n de la calidad del c%di&o $sando 'DD en el desarrollo de la l%&ica de ne&ocio
de $n sistema de informaci%n para $n cl$b deportivo

P&ina ( de !)*

INDICE
PRLOGO ................................................................................................................................................... 7
INTRODUCION ............................................................................................................................................ 9
1. OBJETIVOS ............................................................................................................................................ 11
!+!+ ,-.#'I/,S D#L P0,1#C', ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !!
2. COMPETENCIAS CUBIERTAS .................................................................................................................. 13
3. APORTACIONES..................................................................................................................................... 15
. NORMATIVA ! LEGISLACION................................................................................................................. 17
*+!+ L#GISL2CI34 G#4#02L +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !)
9/:/:/ ;,<3///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :=
9/:/>/ 3erec.o de Cita//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :?
*+2+ 4,052'I/2S 2PLIC2D2S 2L P0,1#C', +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !6
9/>/:/ *in"le @uro <a#ments Area A*@<AB/////////////////////////////////////////////////////////////////////////////////////////////// :C
*+2+!+!+ Los 2de$dos Directos -sicos S#P2 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2!
5. ESTADO ACTUAL ................................................................................................................................... 27
(+!+ L,S P0,-L#52S D# L2S 5#',D,L,G72S CL8SIC2S+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2)
D/:/:/ 3e los requisitos al producto &inal//////////////////////////////////////////////////////////////////////////////////////////////// >=
D/:/>/ @l tel&ono roto///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// >?
D/:/E/ @l modelo en cascada/////////////////////////////////////////////////////////////////////////////////////////////////////////////////// >C
D/:/9/ ;os modelos eolutios //////////////////////////////////////////////////////////////////////////////////////////////////////////////// E>
(+2+ L2 92L'#042'I/2 8GIL:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ "*
". EL AGISLISMO ....................................................................................................................................... 35
6+!+ #L 524I;I#S', 8GIL +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ "(
6+2+ #L 2GILIS5, 1 S<S =#0025I#4'2S ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ")
F/>/:/ *C6!8///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 9:
F/>/>/ Ge.aiod-3rien 3eelopement AG33B //////////////////////////////////////////////////////////////////////////////////////// 99
F/>/E/ $33 ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// D:
F/>/9/ 6e&actorizacin, code qualit# # clases *,;H3/////////////////////////////////////////////////////////////////////////////// D=
F/>/D/ 8tricas de Cdi"o ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// FI
F/>/F/ Clean Code /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// FD
F/>/=/ *o&t-are Cra&tmans.ip //////////////////////////////////////////////////////////////////////////////////////////////////////////////// FC
7. AN#LISIS ............................................................................................................................................... 71
)+!+ 0C4GC 5#5-#0S 5242G#5#4'++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ )!
=/:/:/ 6equisitos///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// =:
=/:/>/ Historias de usuario ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////// =>
=/:/E/ 6estricciones impuestas por el pro#ecto////////////////////////////////////////////////////////////////////////////////////// =>
)+!+"+!+ Por las caracter>sticas del est$dio +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ )2
)+!+"+2+ Desarrollo sin 9persistencia de datos+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ )"
=/:/9/ 3ia"ramas de Clases # 3ependencias////////////////////////////////////////////////////////////////////////////////////////// =F
)+2+ 4D#P#4D 5#'0ICS 0#P,0'#0++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ )6
$. RE%UISITOS DE &ARD'ARE ! SO(T'ARE ............................................................................................ 79
?+!+ 4D#P#4D 5#'0ICS 0#P,0'#0++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ )6
9. DESARROLLO ! &ERRAMIENTAS ........................................................................................................... $1
6+!+ #L SIS'#52 D# D#S200,LL,++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ?!
C/:/:/ Hard-are ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// ?:
C/:/>/ *o&t-are/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// ?:


P&ina 6 de !)*
6+2+ =#0025I#4'2S D# D#S200,LL,++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ?2
C/>/:/ Git///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// ?>
6+2+!+!+ GI' +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ?"
6+2+!+2+ Git=<-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ?6
6+2+!+"+ SmartGit ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ?6
C/>/>/ *pecFlo-////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// CE
C/>/E/ 8*$ests////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :II
C/>/9/ 2Coer//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :ID
C/>/D/ 23epend //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :IF
1). RESULTADOS DE LA EVALUACION DEL CDIGO................................................................................. 115
!+!+ S,-0# L2 5#',D,L,G72 D# #/2L<2CI34++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !!(
!+2+ 0#S<L'2D,S++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !!)
:I/>/:/ Con&ormidad con los requisitos//////////////////////////////////////////////////////////////////////////////////////////////// ::=
!+"+ ;I2-ILID2D ('#S'#D C,D#)+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !!?
!+*+ L#GI-ILID2D (CL#24 C,D#) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !!6
!+(+ ;L#@I-ILID2D 1 0#<S2-ILID2D (P0I4CIPI,S ,,D)+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ !2*
:I/D/:/ Co.esin/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :>9
:I/D/>/ Acoplamiento/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// :>=
:I/D/E/ Abstraccin e Hnestabilidad////////////////////////////////////////////////////////////////////////////////////////////////////// :EE
11. CONCLUSIONES................................................................................................................................. 135
ANE*O 1 ................................................................................................................................................. 137
BIBLIOGRA(+A......................................................................................................................................... 1""
RE(ERENCIAS .......................................................................................................................................... 1"$


P&ina ) de !)*
Prlogo
4o es frec$ente A$e t$ trabaBo te permita estar al tanto de los contin$os cambios en este
m$ndo de la informtica+ 'e centras en t$ especialidad (la m>a es la de 2dministraci%n de
Sistemas de Informaci%n) y en poco tiempo estas completamente obsoleto en c$alA$ier
otra rama+ 2s> A$e, tras aCos de aislamiento, cada veD A$e volv>a a pasar por la
<niversidad, A$edaba conmocionado por el al$vi%n de n$evos desc$brimientos A$e se
a&olpaban por entrar en mi cerebro+
,c$rri% por primera veD c$ando realicE el Proyecto de ;in de Carrera de la Diplomat$ra+
;$e $n trabaBo de 2nlisis y DiseCo+ #n aA$ella Epoca la Diplomat$ra no incl$>a
asi&nat$ras de In&enier>a de SoftFare, y para mi res$lt% $na verdadera revelaci%n+ Por fin
encaBaban todas las pieDas+ 0es$ltaba absol$tamente nat$ral la sec$encia 2nlisisGDiseCoG
Implementaci%n, y aprend> $n mEtodo formal A$e me permit>a aplicar s$s pasos de
manera simple y difana, la 5etodolo&>a en Cascada+ Cada $na de s$s etapasH primero
adA$ieres los reA$isitos, l$e&o diseCas todo y lo representas mediante $na
doc$mentaci%n completa, y, por Iltimo, se pasan estos doc$mentos al eA$ipo de
desarrollo, A$e lo implementa+ Cada $no de los rolesH el in&eniero, al A$e eA$iparaba con
$n arA$itecto A$e Jace los planos, el Befe de eA$ipo, A$e era el apareBador A$e coordina,
y los pro&ramadores, A$e eran los obreros+ 'odo se antoBaba raDonable, indisc$tible+ 5e
convert> en $n adalid de la 5Etrica "+
1, tras m$cJos aCos, v$elvo a pisar la <niversidad para la 2daptaci%n al Grado+ Lle&a el
momento del ';GK y recibo el maDaDo A$e Jace tambalear mis convicciones+ Se revela
ante m> la eListencia de $na n$eva radicalmente distinta de afrontar ciertos proyectos de
desarrollo de softFare+ #l mismo t$tor A$e me il$min% Jac>a tantos aCos en el camino de
los mEtodos formales me va des&ranando, en $na tarde de principios de verano, $na idea
simple, la del Desarrollo Diri&ido por 'est+ #s $na idea m$y atractiva, la de desarrollar
9sobre se&$ro:+ #ncaBa m$y bien en ese Iltimo paso, el de implementaci%n+ Pero 42o5, me
dice, M2o se trata de eso/ $,3, el desarrollo, de principio a &in, se .ace con base en $335+
5e A$edo desorientado+ NSin $na anlisis y diseCo >nte&ro previoO NSin $n arA$itectoO
NSin $n apareBadorO NSin planos detalladosO 5i edificio constr$ido a lo lar&o de aCos se
derr$mba+ NC%mo p$ede al&o nacer de ese caosO 4<orque se basa en otros conceptos, en
otras ideas, en otras .erramientas5, replica+ Le m$estro mi escepticismo, mi reticencia, mi
inse&$ridad ante la idea de afrontar al&o tan radicalmente distinto estando yo tan
anclado, tan oLidado como me encontraba+ #l me eLplica, me ar&$menta, me pers$ade+
5e anima+ 4<rubalo5+ Le Jice caso y lo Je probado+ N1 saben A$eOK P5e &$staQ
Creo A$e a $stedes podr>a pasarles lo mismo+


P&ina ? de !)*


P&ina 6 de !)*
INTRODUCION

R$iD lo A$e ms deber>a preoc$par a $n In&eniero del SoftFare, es la idea de la Calidad+
2 veces, obsesionados por c$mplir los plaDos y fact$rar, deBamos este concepto $n poco
de lado, sin darnos c$enta, p$es nos centramos tan solo en dos factores del mismo, los
Inicos A$e el cliente va a poder apreciar
6obustezJ #l softFare no debe presentar fallos c$ando se enc$entre en
prod$cci%n
Con&ormidadJ R$e c$mpla con los reA$isitos A$e se Jan descrito
contract$almente+
#n las metodolo&>as clsicas, de la A$e el 5odelo en Cascada es A$iD s$ mayor
eLponente, lo A$e normalmente nos certifica el departamento de R$ality 2s$rance es
A$e Jemos se&$ido los procedimientos establecidos en la doc$mentaci%n del proyecto y
A$e, por tanto, si&$iendo la idea de la Calidad de Procesos, el prod$cto final deber>a estar
correcto+ <nas pr$ebas finales, de parte de los compaCeros de R$ality Control, y 9sello al
canto:+
Pero, Iltimamente, Jan s$r&ido otro tipo de metodolo&>as, llamadas "iles, no tan
centradas en la doc$mentaci%n, A$e proclaman conse&$ir $n softFare de mayor 9calidad:+
NSin $n soporte doc$mental sobre el A$e basarnos para emitir veredictoONC%mo definir
A$E es el R$ality Code entoncesONC%mo medirloO
Para los se&$idores de las 5etodolo&>as 8&iles, la ar&$mentaci%n es simple+ S$ softFare
res$lta de meBor calidad por varias raDonesH
6obustezJ La manera de desarrollar en el 9a&ilismo: implica la contin$a
comprobaci%n del mismo+ #n las metodolo&>as clsicas a veces el softFare
res$ltante es dif>cilmente testable en s$ inte&ridad, y los errores no s$r&en Jasta
A$e el $so contin$ado los Jace patentes+ <sando 'estGDriven Developement, el
softFare no es A$e sea fcilmente testable, es A$e est completamente testado,
al !S+


P&ina ! de !)*
Con&ormidadJ Las metodolo&>as &iles no &arantiDan A$e el softFare c$mpla con la
doc$mentaci%n eLJa$stiva del contrato, sino A$e &arantiDa A$e c$mple con lo A$e
el cliente realmente desea+ #s ciertos tipos de desarrollos es relativamente
compleBo A$e todos los reA$isitos de $s$ario emerBan desde el primer anlisis+ #l
cliente no tiene m$y claro A$e necesita, o c%mo el softFare p$ede ay$darle+ Las
metodolo&>as &iles facilitan al $s$ario final softFare operativo cada poco tiempo,
A$e Este p$ede $tiliDar, y estn especialmente diseCadas para aceptar
s$&erencias, cambios en los reA$isitos, y adatarse+ Por ello se llaman :a&iles:+ 4o
A$iere decir esto A$e no eLista $na fase inicial de #specificaci%n de 0eA$isitos, ni
m$cJo menos, sino A$e saben adaptarse dinmicamente a la entrada de los
n$evos+
Pero, adems, eListen otros factores A$e Jacen A$e el softFare sea intr'nsecamente de
mayor calidad con el 9a&ilismo:H
;e"ibilidadJ <n c%di&o no es ms le&ible porA$e estE ms doc$mentado o
comentado+ <n c%di&o es ms le&ible c$ando, sencillamente, es ms fcil de
entender y se&$ir+ Claridad, simplicidad, ele&ancia+ Las metodolo&>as &iles, como
veremos, por s$ propia nat$raleDa, necesitan prod$cir c%di&o ms le&ible+
Fle7ibilidadH 4$evamente, la propia nat$raleDa del desarrollo &il eLi&e fleLibilidad
en el c%di&o+ 1 la fleLibilidad emana de se&$ir de forma firme los principios del
DiseCo ,rientado a ,bBetos, lo A$e &arantiDa la mLima reusabilidad y
portabilidad del c%di&o+ C%di&o A$e es, &ormalmente, de mayor calidad+
#n el presente 'rabaBo de ;in de Grado nos Jemos planteado la c$esti%n de la valideD de
estas afirmaciones+ =emos realiDado $n proyecto si&$iendo las ideas del a&ilismo, al
menos en la medida de lo posible, p$es, al ser $n trabaBo personal, no Ja eListido $n
eA$ipo con el A$e comprobar el f$ncionamiento de, por eBemplo, el SC0<5+ Pero s> nos
Jemos lanDado al desarrollo 'DD, y Jemos eLperimentado el -DD+ =emos probado
n$evas Jerramientas de desarrollo, y Jemos se&$ido, &racias a al&$nas mEtricas de
c%di&o, la evol$ci%n y el res$ltado final+
2A$> presentamos el res$ltado de todos estos meses, en $na memoria en la A$e podemos
apreciar c$atro partes principalesH
Descripci%n inicial de los problemas de las metodolo&>as clsicas
#Lposici%n de los conceptos del a&ilismo, y c%mo dan sol$ci%n a los problemas
anteriores
Presentaci%n de las Jerramientas $tiliDadas d$rante el desarrollo+
0es$ltados
#speramos, con todo ello, poder responder a la c$esti%n A$e en$nciamos en el t>t$lo de
n$estro 'rabaBo de ;in de GradoH KCmo es la calidad del cdi"o resultante en un
desarrollo $33L


P&ina !! de !)*
1. OBJETIVOS
1.1. Objetivos del proyecto
#l obBetivo principal del act$al 'rabaBo de ;in de Grado es realiDar $n desarrollo parcial de
$na aplicaci%n, en partic$lar al&$nas bibliotecas de clases relacionadas con fact$raci%n en
la &esti%n de $n cl$b deportivo, si&$iendo las prop$estas del A"ilismo y las tEcnicas 'DD
('est Driven Developement), eval$ando la calidad del c%di&o res$ltante desde los p$ntos
de vistaH
CualitatioJ #l desarrollo es eminentemente emp>rico+ La meBor manera de eval$ar
$n mEtodo es probarlo, y Jacer $na eLposici%n en la memoria de todo el proceso,
ar&$mentando problemas Jallados y las ventaBas encontradas+
CuantitatioJ 'oda la evol$ci%n del proyecto estar monitoriDada a travEs de
mEtricas obBetivas de c%di&o+ DicJas mEtricas se eLpondrn y comentarn en los
res$ltados+
2l mismo tiempo, como en c$alA$ier proyecto de fin de carrera, podemos enfocarlo a
travEs de dos obBetivos espec>ficosH
(or,-r.
o E/ u0 1ro23/o 43 -1r30456-73. 'odo proyecto de ;in de Carrera, como
refleBan las competencias, est pensado para formarte como $n meBor
profesional+ Desde el principio mi t$tor me deB% claro A$e este era el reto
esencial del proyecto+ #n el ms simple de los casos, $n proyecto es $n
entrenamiento, $na &imnasia, $n adiestramiento A$e te prepara para la
vida laboral+ La mayor>a de las veces es adems $n proceso de
desc$brimiento, donde eLploras n$evos campos &$iado por t$ t$tor+ 1, si
Jay s$erte, ser $n proyecto de investi&aci%n, donde desc$bres cosas
realmente n$evas A$e compartir con otros+
o E/ u0 3/tu45o 45482t52o. 'odo ';G A$eda finalmente p$blicado para A$e
otros aprendan a travEs de t$ trabaBo+ #n este caso el proyecto es
principalmente didctico, con al&$nos toA$es de investi&aci%n a travEs de
est$dio con mEtricas+ #s $na &$>a t$torial sobre c%mo empeDar a aplicar el
a&ilismo, donde los lectores podrn ver eBemplos prcticos de $so de estas
metodolo&>as y Jerramientas para A$e p$edan afrontar s$s propios
proyectos+
I,193,30t-r. 2 veces el res$ltado de $n ';G es $n prod$cto final A$e p$ede ser
$tiliDado a nivel de prod$cci%n+ #n n$estro caso el desarrollo no f$e ms A$e $n
instr$mento para n$estro est$dio+ Sin embar&o, se Jan implementado al&$nos
prod$ctos finalesH


P&ina !2 de !)*
o Se Ja desarrollado todo el procedimiento de env>o de ade$dos directos
S#P2 se&In IS,222 @5L+ #sta normativa entra en vi&or en ;ebrero de
2!*, y todas las empresas A$e emitan recibos Jan de adaptarse a las
mismas, por lo A$e esta implementaci%n en CT p$ede res$ltarles
tremendamente Itil+
o ;inalmente, y a$nA$e no f$era parte inicial del proyecto, para el est$dio
de las mEtricas Je desarrollado $na aplicaci%n completa A$e, Jaciendo
$so de la 2PI de el softFare 4Depend, presenta cifras, estad>sticas y
&rficas de las mismas, eLtrayEndolas 9in sit$: del c%di&o f$ente y del
Jist%rico de anlisis previos realiDados+


P&ina !" de !)*
2. COMPETENCIAS CUBIERTAS
Las competencias c$biertas en el presente proyecto Jan sidoH
Co,13t3025-/ 2o,u03/
CHHI:J Capacidad para disear, desarrollar, seleccionar # ealuar aplicaciones #
sistemas in&ormticos, ase"urando su &iabilidad, se"uridad # calidad, con&orme a
principios ticos # a la le"islacin # normatia i"ente
#ste ';G es, precisamente, $n est$dio sobre eval$aci%n de calidad en $n
desarrollo de softFare A$e nosotros mismos Jemos implementado,
centrndonos en elementos tales como la fiabilidad del c%di&o+ D$rante el
desarrollo del mismo se Ja tenido en c$enta la normativa vi&ente en c$estiones
referentes a la privacidad, no JabiEndose $sado para la car&a del sistema nin&In
dato personal real
CHHI>J Capacidad para plani&icar, concebir, desple"ar # diri"ir pro#ectos, sericios #
sistemas in&ormticos en todos los mbitos, liderando su puesta en marc.a # su
me%ora continua # alorando su impacto econmico # social/
Para la correcta realiDaci%n de este 'rabaBo, el al$mno debi% realiDar $na
correcta planificaci%n, direcci%n y eBec$ci%n del proyecto, apoyado por s$ t$tor+
#l proyecto es, adems, $na &$>a para ay$dar a otros profesionales para
planificar, concebir, desple&ar y diri&ir proyectos con 9metodolo&>as &iles:+
CHHIEJ Capacidad para comprender la importancia de la ne"ociacin, los .bitos
de traba%o e&ectios, el lideraz"o # las .abilidades de comunicacin en todos los
entornos de desarrollo de so&t-are/
<no de los principales principios del 2&ilismo es Mvalorar a los individ$os y s$
interacci%nU, por lo A$e la adA$isici%n de esta competencia es vital en &r$pos de
desarrollo A$e si&an esta prctica+ D$rante todo el ';G se Ja JecJo JincapiE en
este valor, y en la idea de 9SoftFare CraftmansJip:+
CHHI9J Capacidad para elaborar el plie"o de condiciones tcnicas de una instalacin
in&ormtica que cumpla los estndares # normatias i"entes/
2l no tratarse este ';G del desarrollo de $n prod$cto con destino a prod$cci%n,
sino de $n est$dio de metodolo&>as, esta capacidad tan solo Ja sido
tan&encialmente c$bierta como res$ltado de los anlisis comparativos+
CHH:FJ Conocimiento # aplicacin de los principios, metodolo"'as # ciclos de ida de la
in"enier'a de so&t-are/
2l tratarse de $n est$dio sobre los res$ltados de la aplicaci%n de $na n$eva
metodolo&>a, Jasta cierto p$nto emer&ente, podemos afirmar A$e esta Ja sido
la competencia principal c$bierta por el proyecto


P&ina !* de !)*
Co,13t3025-/ 43 9- I0:3053r;- 439 /o<t=-r3
H*I:J Capacidad para desarrollar, mantener # ealuar sericios # sistemas so&t-are
que satis&a"an todos los requisitos del usuario # se comporten de &orma &iable #
e&iciente, sean asequibles de desarrollar # mantener # cumplan normas de
calidad, aplicando las teor'as, principios, mtodos # prcticas de la in"enier'a del
so&t-are/
#l presente proyecto es $n est$dio de In&enier>a de SoftFare donde se evalIa,
mediante $n desarrollo parcial, las capacidades de $na metodolo&>a para crear
softFare c$ya caracter>stica principal es, precisamente, s$ perfecto aB$ste a los
reA$isitos de $s$ario y s$ fiabilidad, por lo A$e, B$nto a la competencia CII!6,
conforman el nIcleo del aprendiDaBe+
Co,13t3025-/ 439 Tr->-7o 43 (50 43 Gr-4o
$FGI:J @%ercicio ori"inal a realizar indiidualmente # presentar # de&ender ante un
tribunal uniersitario, consistente en un pro#ecto en el mbito de las tecnolo"'as
espec'&icas de la Hn"enier'a en Hn&ormtica de naturaleza pro&esional en el que se
sinteticen e inte"ren las competencias adquiridas en las enseanzas/
<na veD presentado el presente 'rabaBo de ;in de Grado, el al$mno realiDar la
debida presentaci%n y defensa del mismo ante el trib$nal, con lo A$e se
c$mplir la primera parte de este reA$isito+ La se&$nda parte viene &arantiDada
por la aprobaci%n en s$ momento por la comisi%n del doc$mento ';G!, donde
se eLpon>a el contenido del ';G+


P&ina !( de !)*
3. APORTACIONES
#l presente proyecto es $n est$dio, y como tal, s$ obBetivo es aportar conocimientos,
tanto al propio est$diante como a la com$nidad de profesionales de la in&enier>a, sobre
el 2&ilismo, s$s principios, c%mo aplicarlos, y los res$ltados A$e de s$ aplicaci%n se
obtienen+
Por tanto, presenta aportaciones al entorno socioGecon%mico, tEcnico y cient>fico a varios
nivelesH
Co,o 1ro?32to 43 50@3/t5:-25A0. Presentamos res$ltados tanto c$alitativos (en
forma de disc$si%n ar&$mentada) como c$antitativos (en forma de res$ltados
medibles mediante mEtricas de c%di&o) sobre el $so del 2&ilismo+
Co,o 1ro?32to <or,-t5@o. #l proyecto s$pone $na &$>a de aprendiDaBe en varios
camposH
o Aprendiza%e de metodolo"'as "ilesJ Se eLponen los conceptos en los A$e
se basan, se m$estra c%mo constr$ir $n proyecto si&$iendo dicJo modelo,
y se enseCa como inte&rar y $tiliDar las Jerramientas necesarias en $n
&r$po de desarrollo A$e desee empeDar a pro&ramar si&$iendo este
paradi&ma+
o Aprendiza%e de la A<H de 23ependJ 4Depend es $na potent>sima
Jerramienta de anlisis de c%di&o, como ya veremos+ Pero $na de las
caracter>sticas A$e le definen es A$e ofrece $na ma&n>fica 2PI a travEs de
la c$al s$s f$nciones se p$eden inte&rar completamente en c$alA$ier
sistema de desarrollo+ Como parte del proyecto se Ja implementado $na
Jerramienta A$e facilita la adA$isici%n de mEtricas y &rficas de
res$ltados++
o Aprendiza%e de la normatia *@<A para el en'o de adeudos domiciliadosJ
#n febrero de 2!* deBarn de estar en vi&or las normativas del ConseBo
S$perior -ancario A$e re&>an el env>o de pa&os domiciliados en #spaCa
se&In el C$aderno !6+ 2 partir de esta fecJa solo se podr $sar las
especificaciones indicadas a nivel e$ropeo por el S#P2, A$e incl$yen $na
compleBa normativa para adaptar el env>o de recibos domiciliados al
estndar IS,222 @5L+ Para el presente proyecto se Ja implementado
$na librer>a en CT A$e realiDa dicJa f$nci%n, incl$yendo esta memoria, en
la parte de normativa, $na descripci%n, res$men y referencia de enlaces a
las diferentes f$entes+
Por otra parte, a$nA$e no f$e s$ obBeto principal, el ';G aporta al&$nos prod$ctos
terminados A$e p$eden $sarse como base para desarrollos propiosH
<na aplicaci%n para monitoriDar en tiempo real las mEtricas de c%di&o y Jacer
representaciones &rficas de las mismas $sando la 2PI de 4Depend+ Si bien lo


P&ina !6 de !)*
primero (las mEtricas) se pod>an se&$ir desde el 4Depend, esta iba a ser $na &ran
aportaci%n, ya A$e el 4Depend *+( no incl$>a f$nciones de representaci%n de
&rficas de evol$ci%n+ La n$eva versi%n ( de 4Depend, lanDada en oct$bre de esta
aCo 2!", Ja aCadido $na poderosa f$ncionalidad de representaci%n de &rficas
de todo tipo
<na librer>a para la implementaci%n de env>o S#P2 en CT+ Por m$cJo A$e b$sA$E
en s$ momento, no encontrE nin&$na librer>a pIblica A$e realiDara este trabaBo+
#spero con sinceridad A$e mi aportaci%n sea de $tilidad a la com$nidad+


P&ina !) de !)*
4. NORMATIVA Y LEGISLACION
Se&$idamente referimos tanto la le&islaci%n &eneral A$e p$diera afectar al desarrollo del
proyecto y la propia memoria presentada, como normativa espec>fica A$e se Ja debido
se&$ir como reA$erimiento del softFare implementado+
4.1. Legislacin general
4.1.1. LOPD
Incl$ir la le&islaci%n vi&ente sobre proyectos informticos A$e afecten al ';G (ley de
protecci%n de datos, leyes sobre se&$ridad,K)
La ;e# ,r"nica :DM:CCC de :E de diciembre de <roteccin de 3atos de Carcter <ersonal
A;,<3B
:
, tiene por obBeto &arantiDar y prote&er, en lo A$e concierne al tratamiento de los
datos personales, las libertades pIblicas y los derecJos f$ndamentales de las personas
f>sicas, y especialmente de s$ Jonor e intimidad familiar+
#l tratamiento de datos de carcter personal se ri&e por esta ley de ac$erdo al art>c$lo
2+!, A$e estableceH
;a presente ;e# ,r"nica ser de aplicacin a los datos de carcter personal
re"istrados en soporte &'sico, que los .a"a susceptibles de tratamiento, # a toda
modalidad de uso posterior de estos datos por los sectores p1blico # priado/
Se re&ir por la presente Ley ,r&nica todo tratamiento de datos de carcter
personalH
a) C$ando el tratamiento sea efect$ado en territorio espaCol en el marco de las
actividades de $n establecimiento del responsable del tratamiento+
b) C$ando el responsable del tratamiento no estE establecido en territorio
espaCol, pero le sea de aplicaci%n la le&islaci%n espaCola en c$mplimiento de
normas de DerecJo Internacional pIblico+
c) C$ando el responsable del tratamiento no estE establecido en territorio de la
<ni%n #$ropea y $tilice en el tratamiento de datos medios sit$ados en
territorio espaCol, salvo A$e tales medios se $tilicen Inicamente con fines de
trnsito+
#n el art>c$lo " de la L,PD, se realiDa la si&$iente definici%n de Vdatos de carcter
personalVH
3atos de carcter personalJ cualquier in&ormacin concerniente a personas &'sicas
identi&icadas o identi&icables/


P&ina !? de !)*
#n el presente trabaBo no vamos a implementar nin&In softFare A$e deba ase&$rarse o
&arantiDar el c$mplimiento de estas medidas, pero tanto para los test como en los
ficJeros de pr$eba @5L se necesita car&ar el sistema con eBemplos+ DicJos eBemplos Jan
sido especialmente esco&idos para no incl$ir datos reales de personas f>sicas+ #n al&$nos
casos, incl$ye al&$nos datos pIblicos de personas B$r>dicas, A$e no estn reco&idas en
esta ley+
Por tanto, podemos concl$ir A$e el presente desarrollo se aB$sta a la L,PD+
4.1.2. Derecho de Cita
2 lo lar&o de este est$dio se Jan ido incorporando fra&mentos de obras de otros a$tores
con el obBetivo de enriA$ecer s$stancialmente n$estro conocimiento sobre la materia
tratada+
#l V43r32Bo 43 25t-C es $n concepto le&al A$e limita los derecJos de $n creador
intelect$al respecto al $so de parte de s$ obra para fines docentes o de investi&aci%n+
#n #spaCa, este derecJo est re&$lado en el art>c$lo "2 del 'eLto 0ef$ndido de la Ley de
Propiedad Intelect$al ('0LPI) se&In el Decreto Le&islativo !W!666, de !2 de abril+ #ste
art>c$lo posibilita la incl$si%n, en $na creaci%n propia fra&mentos de obras de otros
a$tores, de nat$raleDa escrita, sonora o a$diovis$al, siempre A$e la obra reprod$cida ya
Jaya sido div$l&ada y s$ incl$si%n se realice para s$ anlisis, comentario o B$icio cr>tico+
Para poder aco&erse a esta norma es necesario A$e se emplee con fines docentes o de
investi&aci%n+
Desde el p$nto de vista de la normativa internacional, #l V derecJo de citaV con fines
docentes est re&$lada por el art>c$lo ! del Convenio de -erna para la Protecci%n de las
,bras Literarias y 2rt>sticas
2
, Na condicin de que se .a"an con&orme a los usos .onrados
# en la medida %usti&icada por el &in que se persi"a/N
2s> mismo, destacar A$e se reserva a las le&islaciones nacionales la fac$ltad de
a$toriDarlo+
#n el mbito de la <ni%n #$ropea, la Directiva 2!W26WC#
"
, relativa a la armoniDaci%n de
determinados aspectos de los derecJos de a$tor y derecJos afines a los derecJos de
a$tor en la sociedad de la informaci%n, reconoce el derecJo de cita con fines docentes en
s$ art>c$lo (+"H
"a) cuando el uso tenga nicamente por objeto la ilustracin con fines educativos o de
investigacin cientfica, siempre que, salvo en los casos en que resulte imposible, se
indique la fuente, con inclusin del nombre del autor, y en la medida en que est
justificado por la finalidad no comercial perseguida"


P&ina !6 de !)*
4.2. Normativas aplicadas al proyecto
4.2.1. Single Euro Payments Area (SEPA)
La creaci%n de la <ni%n #con%mica y 5onetaria y la introd$cci%n de los billetes y
monedas en e$ros Jan sido Jitos decisivos para la eListencia de $n mercado Inico en la
<ni%n #$ropea+ Desde s$ introd$cci%n, en enero de 22, en todos los pa>ses de la
e$roDona es posible realiDar pa&os en efectivo en la misma moneda con la comodidad y
sencilleD con la A$e se efect$aban anteriormente los pa&os en las respectivas monedas
nacionales+ 4o obstante, en el mbito de los pa&os A$e no se Jacen en efectivo,
permanece $na sit$aci%n de fra&mentaci%n A$e, en Iltima instancia, dific$lta la
c$lminaci%n de ese obBetivo+
Para contrib$ir a paliar esta sit$aci%n nace la Do0- E052- 43 P-:o/ 30 Euro/
*
, conocida
baBo el acr%nimo S#P2 (de la terminolo&>a in&lesa Sin&le #$ro Payments 2rea)+
F%uG 3/ 9- SEPAH
La S#P2 es la Dona en la A$e ci$dadanos, empresas y otros a&entes econ%micos p$eden
Jacer y recibir pa&os en e$ros, con las mismas condiciones bsicas, derecJos y
obli&aciones, y ello con independencia de s$ $bicaci%n y de A$e esos pa&os impliA$en o
no procesos transfronteriDos+
La S#P2 s$pondr $n n$evo escenario caracteriDado por $na armoniDaci%n en la forma de
Jacer pa&os en e$ros principalmente mediante el empleo de tres &randes tipos de
instr$mentosH las transferencias, los ade$dos domiciliados y las tarBetas de pa&o+
C-9304-r5o 43 30tr-4- 30 @5:or 439 SEPA
La Comisi%n #$ropea
(
estableci% los f$ndamentos le&ales del n$evo marco a travEs de la
Directiva 2)W6*WC#
6
sobre servicios de pa&o en el mercado interior+
#sta directiva Ja sido trasp$esta a la le&islaci%n espaCola en 26, mediante la Ley de
Servicios de Pa&o
)
+
2$nA$e la mi&raci%n Jacia los n$evos estndares S#P2 ya Ja comenDado, y act$almente
coeListen con los esA$emas nacionales, la reciente adopci%n del 0e&lamento C#
26W2!2, establece el 1 43 <3>r3ro 43 2)1 como fecJa l>mite para A$e las
transferencias y ade$dos nacionales sean reemplaDados por los n$evos instr$mentos
S#P2+


P&ina 2 de !)*
Do043 302o0tr-r 50<or,-25A0 /o>r3 39 SEPA
2dems de la p&ina principal del #$ropean Payments Co$ncil (#PC)
?
, podemos encontrar
informaci%n eLJa$stiva en el -anco Central #$ropeo
6
+ 2l mismo tiempo, el -anco de
#spaCa Ja creado $na p&ina
1)
donde reIne toda la informaci%n eListente en espaCol,
orientada tanto a empresas A$e necesiten realiDar s$s transacciones se&In este estndar,
como para las entidades de crEdito+
Por otra parte casi todos loa bancos y caBas ofrecen a s$s clientes, a travEs de s$s servicios
onGline, acceso a informaci%n relativa al S#P2+
I0/tru,30to/ 439 SEPA
2 travEs del se Jan definido los instr$mentos S#P2 para transferencias y ade$dos
directos, B$nto con $n conB$nto de normas y estndares A$e deben ser c$mplidos por los
proveedores de servicios de pa&o+
Se detallan a contin$aci%n cada $no de estos instr$mentos de pa&oH
Tr-0/<3r3025-/. La transferencia S#P2 es $n instr$mento de pa&o bsico para
efect$ar abonos en e$ros, sin l>mite de importe, entre c$entas bancarias de
clientes en el mbito de la S#P2, de forma totalmente electr%nica y a$tomatiDada+
T-r73t-/. La Xona Ynica de Pa&os en #$ros (S#P2) establece $n marco &eneral en
el A$e los tit$lares de tarBetas p$eden Jacer pa&os y retirar efectivo en e$ros
dentro de la S#P2, con la misma facilidad y comodidad A$e en s$s pa>ses de
ori&en+
A43u4o/ D5r32to/ >8/52o/. #l ade$do directo es $n servicio de pa&o destinado a
efect$ar $n car&o en la c$enta del de$dor+ La operaci%n de pa&o es iniciada por el
acreedor, sobre la base del consentimiento dado por el de$dor al acreedor, y
transmitida por Este a s$ proveedor de servicios de pa&o+
A43u4o/ D5r32to/ B2B. #n el ade$do directo -2-, el de$dor y el acreedor tendrn
A$e ser obli&atoriamente empresas o a$t%nomos (no cons$midores) A$e Jan
acordado $tiliDar el servicio de ade$dos directos -2- para los pa&osWcobros
relativos a s$s transacciones comerciales+
ISO2))22
Dentro de la normativa del S#P2 $no de los elementos ms importantes era definir
eLactamente como se transmitir>an los mensaBes entre los intervinientes en el procesoH
#ntidades bancarias (-anZ) del acreedor y del de$dor
#misor (Creditor)


P&ina 2! de !)*
De$dor (Debtor)
Para ello, el #PC decidi% adoptar para la S#P2 los estndares IS,222
!!
+ #stos f$eron
creados por el IS,W'C6?
!2
y describen $na plataforma comIn para el desarrollo de
mensaBes $sandoH
$na metodolo&>a de modelado para capt$rar, con $na sintaLis independiente del
rea de ne&ocio financiera, el fl$Bo de transacciones y s$s mensaBes asociados
$n diccionario centraliDado de los elementos $sados en las com$nicaciones
financieras
$n conB$nto re&las para convertir los modelos de mensaBes en esA$emas @5L o
2S4!, dependiendo de si se prefiere $sar $na sintaLis IS, 222 @5L o basada en
2S4+!+
Por tanto, para cada $na de los servicios S#P2 (transferencias, ade$dosK), el #PC Ja
p$blicado $na serie de normas y pa$tas para implementar los mensaBes A$e Jan de
intercambiarse los actores si&$iendo el correspondiente estndar IS,222+
4.2.1.1. Los Adeudos Directos Bsicos SEPA
Como prctica de -DDW'DD vamos a implementar $no de los servicios S#P2H el env>o de
recibos domiciliados+
'anto el esA$ema bsico como el -2- $tiliDan el estndar IS,222 a la Jora de
transmitir s$s mensaBes+ #l #PC especifica, a travEs de s$s doc$mentos, como
implementar, baBo IS,222, los detalles de de los mismos (;i&$ra *G!)
#n partic$lar nos centraremos para n$estro desarrollo en los 2de$dos Directos mediante
el #sA$ema -sico, p$es es el A$e $tiliDan normalmente las empresas para remesar s$s
recibos domiciliados a s$s clientes, ya A$e el -2- est diseCado para intercambio entre
empresas o a$t%nomos, no para partic$lares+
Las dos sitios principales donde obtener la re&$laci%n sobre los mismos son la p&ina Feb
A$e a ellos dedica el #PC
!"
(en in&les) y la p&ina Feb del -anco de #spaCa
!*

#l doc$mento principal sobre de los ade$dos directos es el *epa Core 3irect 3ebit *c.eme
6uleboo+ A@<CI:F-IFB
:D
, donde se reco&e toda la informaci%n referente aH
2lcance de la normativa
0oles de los actores (emisores, de$dores, entidades de crEditoK)
0e&lamento y operativas de ne&ocio (reco&ida de a$toriDaciones, formas y plaDos
de entre&a de los mensaBesK)
'ratamiento del esA$ema para el S#P2


P&ina 22 de !)*
(5:ur- I1. #sA$ema de los doc$mentos A$e definen los estndares para los env>os S#P2
I0t3r2-,>5o 43 ,30/-73/ 43 -43u4o/ 45r32to/ 30 SEPA
#n n$estro caso, de todo lo anterior, nos focaliDaremos en c%mo implementar los
mensaBes intercambiados entre los actores+ #n partic$lar, los A$e el emisor intercambia
con s$ banco (ordenar los ade$dos, solicitar retrocesiones, recibir las devol$ciones)+
/eamos $n esA$ema de los mismos (;i&$ra *G2)H
Los mensaBes A$e $n emisor de ade$dos intercambia con s$ banco sonH
Del emisor al bancoH
o Presentaci%n de los ade$dos directos
o 0etrocesiones para reinte&rar el importe al de$dor en caso de ade$do
indebido
Del banco al emisor
o 0ecJaDos de operacionesWmensaBes enviados
o Devol$ciones
SEPA Direct Debit Core
SDD
SEPA Direct Debit Bank to Bank
SDD B2B
Core Rulebook v.6.1
(EPC016-06)
Core Rulebook v4.1
(EPC222-07)
Inter-Bank
(EPC114-06)
Customer-to-Bank
(EPC130-08)
E-Mandate
(EPC002-09)
Advanced-Mandate
(EPC296-10)
SCHEMAS
Implementation
Guidelines
E-Mandate
(EPC129-09)
Advanced-Mandate
(EPC315-10)
Inter-Bank
(EPC301-07)
Customer-to-Bank
(EPC131-08)
Advanced-Mandate
(EPC315-10)
SCHEMAS
Implementation
Guidelines
Inter-Bank
(EPC301-07)
Advanced-Mandate
(EPC315-10)
Customer-to-Bank
(EPC131-08)
Inter-Bank
(EPC301-07)
Advanced-Mandate
(EPC315-10)
E-Mandate
(EPC129-09)
Inter-Bank
(EPC301-07)
Customer-to-Bank
(EPC131-08)
ISO 20022
Payment Initiation Messages
(pain.xxx.xxx.xxx)
Third Version September 2009
SEPA Direct Debit Core
SDD
SEPA Direct Debit Bank to Bank
SDD B2B
Core Rulebook v.6.1
(EPC016-06)
Core Rulebook v4.1
(EPC222-07)
Inter-Bank
(EPC114-06)
Customer-to-Bank
(EPC130-08)
E-Mandate
(EPC002-09)
Advanced-Mandate
(EPC296-10)
SCHEMAS
Implementation
Guidelines
E-Mandate
(EPC129-09)
Advanced-Mandate
(EPC315-10)
Inter-Bank
(EPC301-07)
Customer-to-Bank
(EPC131-08)
Advanced-Mandate
(EPC315-10)
SCHEMAS
Implementation
Guidelines
Inter-Bank
(EPC301-07)
Advanced-Mandate
(EPC315-10)
Customer-to-Bank
(EPC131-08)
Inter-Bank
(EPC301-07)
Advanced-Mandate
(EPC315-10)
E-Mandate
(EPC129-09)
Inter-Bank
(EPC301-07)
Customer-to-Bank
(EPC131-08)
ISO 20022
Payment Initiation Messages
(pain.xxx.xxx.xxx)
Third Version September 2009


P&ina 2" de !)*
(5:ur- I2. Intercambio de mensaBes de ade$dos directos S#P2

#stos mensaBes se definen a travEs de los diferentes esA$emas S#P2, y s$
correspondiente formato de mensaBes IS, 222@5L
#sA$ema 2de$do Directo S#P2 #stndares IS, 222 @5L
DSI)3 Presentaci%n de los 2de$dos
Directos
C$stomerDirectDebitInitiation/2
J1-50.))$.))1.)2)
DSI)5 0ecJaDos de operacionesWmensaBes
presentados
C$stomerPaymentStat$s0eport/"
(1-50.))2.))1.)3)
DSI)5 Devol$ciones
C$stomerPaymentStat$s0eport/"
(1-50.))2.))1.)3)
DSI)7 0etrocesi%n para reinte&rar el
importe al de$dor en caso de ade$do
indebido
C$stomerPayment0eversal/2
(1-50.))7.))1.)2)
Implementation G$idelines
S#P2 #PC C$stomerG'oG-anZ Implementation G$idelines (#PC!"G?)
T->9- I1. 0elaciones entre los esA$emas S#P2 y los estndares IS,222
Como indica la 'abla *G!, por eBemplo, para realiDar $na presentaci%n de ade$dos
directos Je de se&$ir las normas establecidas por el S#P2 en s$ esA$ema DSI)3 (A$e se
describe en el anteriormente citado doc$mento #PC!6G6), y Je de constr$ir el mensaBe
se&In la norma IS, 222 @5L Cu/to,3rD5r32tD3>5tI05t5-t5o0V)2 J1-50.))$.))1.))2K,


P&ina 2* de !)*
si&$iendo las especificaciones partic$lares para implementaci%n de env>os S#P2 ClienteG
-anco A$e aparecen el doc$mento #PC!"G?+
#s importante recalcar A$e no todos los elementos de los mensaBes 9pain: son $sados por
el S#P2+ Siempre manteniendo la inte&ridad del esA$ema @5L, las diferentes
especificaciones DS del S#P2 imponen restricciones y re&las de $so sobre elementos y
atrib$tos+ #s por ello A$e, adems de est$diar c%mo se constr$ye $n mensaBe 9Payment
Initiation:, se debe tambiEn tener en c$enta las &$>as de implementaci%n S#P2 p$blicadas
por el #PC+
Las especificaciones completas para la creaci%n de los mensaBes @5L, son, por tanto,
bastante compleBas+ #s por ello A$e, a contin$aci%n, incl$yo $na referencia res$mida de
toda la doc$mentaci%n cons$ltada+
Referencias
ISO 2))22 M3//-:3 D3<505t5o0 R31ort I P-?,30t/ M-50t30-023 2))9 I E45t5o0
S31t3,>3r 2))9
1"
. #s el doc$mento principal, A$e incl$ye la definici%n de todos
los esA$emas @5L Payment Initiation (pain), as> como otros tipos de mensaBes
relacionados con pa&os (-anZ 'o C$stomer CasJ 5ana&ement GcamtG, Payments
Clearin& and Settlement GpacsG)+
ISO 2))22 Cu/to,3rItoIB-0L M3//-:3 U/-:3 Gu543 I Cu/to,3r Cr345t Tr-0/<3r
I05t5-t5o0M Cu/to,3r D5r32t D3>5t I05t5-t5o0 -04 P-?,30t St-tu/ R31ort I V3r/5o0
3.)
!)
H <n doc$mento de ay$da para la constr$cci%n de los mensaBes @5L m$y
completo en c$ya redacci%n Jan participado por $na serie de corporaciones y
partic$lares, y A$e esta almacenado por la sociedad S[I;'
!?

S31- Cor3 D5r32t D3>5t S2B3,3 Cu/to,3rItoIB-0L I,193,30t-t5o0 Gu5439503/
JEPC13)I)$K
:C
H G$>a p$blicada por el propio #PC para la implementaci%n de los
mensaBes C$stomerG'oG-anZ+ #n ella especifica como transportar los esA$emas
DSG", DSG( y DSG) a los mensaBes IS, 222 @5L, tal y como antes
comentamos+
#l IS,222 &$arda $n arcJivo
2
de todas las definiciones de mensaBes+ #n
partic$lar, en s$ secci%n 9'Jird version of tJe Payment Initiation messa&es:
2!
,
adems del doc$mento 9H*, >II>> 8essa"e 3e&inition 6eport), incl$yeH
o (52B3ro *ML S2B3,- D3<505t5o0 J.N/4K para cada $no de los mensaBes pain,
A$e res$lta 2-S,L<'25#4'# I5P0#SCI4DI-L# a la Jora de realiDar $n
desarrollo 'DD, p$es permite ir validando cada $no de los elementos y
atrib$tos @5L a medida A$e se van desarrollando+
o (52B3ro/ 43 ,30/-73/ *ML 43 373,19o
(52B- 43 A43u4o/ SEPA
22
. PeA$eCa ficJa A$e reco&e las caracter>sticas bsicas de
la implementaci%n espaCola del Sepa, as> como las pa$tas para la mi&raci%n desde
el anterior formato de teLto plano CS-GC$aderno !6
2"


P&ina 2( de !)*
M5:r-25A0 - SEPA 43 9o/ A43u4o/ Do,52595-4o/ 3/1-Oo93/
2*
H Por Iltimo, eListe
re&lamentaci%n espaCola, reco&ido en $n doc$mento p$blicado por la 2#-
2(
,
C#C2
26
y <42C
2)
, donde aparecen las especificaciones sobre c%mo realiDar la
mi&raci%n del anterior sistema de env>o de ade$dos, el C$aderno CS-G!6 en teLto
plano a los n$evos ade$dos S#P2+ #n el se indican las correspondencias entre las
fi&$ras de ambos esA$emas+
r4303/ 30 (or,-to ISO 2))22 1-r- 9- 3,5/5A0 43 A43u4o/ D5r32to/ SEPA P
E/Qu3,- B8/52o P Gu;- 43 I,19-0t-25A0 P No@53,>r3 2)12
2$
. La Confederaci%n
#spaCola de CaBas de 2Jorros Ja confeccionado $n doc$mento A$e reIne en $n
solo folleto en espaCol la prctica totalidad de las especificaciones anteriores+ De
especial interEs, en esta Iltima versi%n de 4oviembre 2!2, es A$e reco&e $na
variaci%n del esA$ema bsico 9core: (C,0), llamado C,0!, A$e apareci% por
primera veD en el Core 0$lebooZ 6 (#PC!6G6), el c$al permite $n ciclo de
presentaci%n ms corto+
Dado A$e los mensaBes S#P2 son $na implementaci%n de $n s$besA$ema de 9pain:, Jay
A$e vi&ilar ciertos factoresH
<n mensaBe A$e es conforme a S#P2 es siempre conforme a 9pain:+
<n mensaBe A$e es conforme a 9pain: p$ede no ser conforme a S#P2, ya A$e
p$ede $sar elementos o valores no reconocidos en el s$besA$ema S#P2+
#sto implica A$e el $so del ficJero @5L ScJema ;efinition (+Lsd) A$e facilita
IS,222 Ja de $sarse con s$ma ca$tela, o adaptarlo previamente a los esA$emas
DS, especialmente en las restricciones de valores para elementos y atrib$tos+
Por Iltimo, eListe re&lamentaci%n espaCola, donde aparecen las especificaciones para la
mi&raci%n del env>o de ade$dos c$aderno !6 clsico en teLto plano (C$aderno CS-G!6)


P&ina 26 de !)*


P&ina 2) de !)*
5. ESTADO ACTUAL
5.1. Los problemas de las metodologas clsicas
5.1.1. De los requisitos al producto final
NC$ntos de nosotros, desarrolladores y analistas, no Jemos visto mil y $na veces esta
viCetaO
(5:ur- 5I1. #l problema de la interpretaci%n de los reA$isitos

<no de los mayores problemas en el desarrollo de softFare es la enorme dific$ltad A$e
s$pone el lle&ar a entender la mente del cliente, lo A$e realmente necesita, y terminar
entre&ndole eLactamente lo A$e demanda+ 'odos conocemos al&In caso de $na
aplicaci%n 9A$e no se adec$a: a lo A$e el $s$ario Jab>a pedido+ 'ras meses y meses de
espera, al recibir s$ prod$cto, el cliente nos mira con desaprobaci%n y, de manera ms o
menos ed$cada, ms o menos indirecta, nos s$elta al&$na variaci%n de 9esto no es lo A$e
Jab>a pedido:
NC%mo podemos evitar estas sit$acionesO
Desde Jace dEcadas se Ja abordado el problema desde la In&enier>a de SoftFare, A$e se
centra en el ciclo de 2nlisisGDiseCoGImplementaci%n, con dos aproLimaciones distintasH


P&ina 2? de !)*
#n las metodolo&>as 9en cascada: el softFare se desarrolla en $n silo ciclo, en el
A$e se planifica con ca$tela y se establecen de manera firme los pasos A$e se dan
desde el inicio Jasta el final
5Etodos Iterativos A$e permiten $n feedbacZ con el cliente, realiDndose tantos
ciclos como sea necesario+
La se&$nda aproLimaci%n res$lta menos sensible al problema de la conformidad con los
reA$isitos, por lo A$e, a este nivel, el c%di&o deber>a ser meBor+ Sin embar&o, ambos se
basan en $n elemento base, la aproLimaci%n de in&enier>a anlisisGdiseCoG
implementaci%n, donde, entre otros elementosH
4o se desarrolla softFare sin $na r>&ida fase de diseCo previa
#n proyectos de cierto nivel Jay $na estr$ct$ra claramente BerarA$iDada de
participantes, separando totalmente las tareas realiDan los analistas, los
diseCadores y los pro&ramadores finales A$e implementan el prod$cto+
Por tanto eListe $na f$erte dependencia del desarrollo a la correcta elaboraci%n e
interpretaci%n de la doc$mentaci%n, a lo lar&o de $n lar&o viaBe, A$e, en la metodolo&>a
en cascada, p$ede llevar meses, e incl$so aCos, antes de poder comprobar A$e 9todo Ja
ido bien:+ Podemos decir A$e las metodolo&>as clsicas son sensibles al problema del
(tel&ono roto)+
5.1.2. El telfono roto
Como perfectamente il$stra la viCeta de la si&$iente p&ina, creada por el &enial artista
del J$mor &rfico A$e es R$ino, todo mensaBe A$e es intercambiado y repetido a travEs
de $na cadena de interloc$tores es proclive a re&istrar $na enorme distorsi%n+
2l&o tan simple, y A$e m$cJos de nosotros conoceremos a travEs del clsico B$e&o del
9telEfono roto:
26
, s$pone $no de los mayores problemas A$e re&istra el enfoA$e clsico de
la In&enier>a de SoftFare+ 2 la Jora de transmitir los reA$erimientos desde el cliente
Jasta el pro&ramador final de la aplicaci%n, el mensaBe p$ede lle&ar a encontrar por s$
camino a $n comercial, a $n analista, a $n diseCador y a $n Befe de eA$ipo de
desarrolladores+ La in&enier>a de SoftFare Ja ideado m$ltit$d de Jerramientas y
protocolos para intentar A$e dicJa informaci%n no se pervierta, pero a veces, esto solo
aCade $n elemento ms al problema, A$e es la trad$cci%n e interpretaci%n de dicJos
doc$mentos+
#s simplemente $n JecJo f>sico re&istrable en c$alA$ier mbito, m$y bien est$diado en la
'eor>a de la Informaci%n
"
H al intentar pasar informaci%n de $n dominio a otro SI#5P0#
se prod$ce $na cierta pErdida de informaci%n debido a los canales y medios de
transmisi%n, a los transd$ctores, a los sistemas de almacenamiento intermedios y
finalesK Por m$y bien A$e se intenten definir los protocolos, por m$y eLJa$stivamente
A$e se intente doc$mentar, siempre nos podemos encontrar con $na toma de
especificaciones incorrecta debido a Jaber sabido esc$cJar al cliente, $nos casos de $so
incompletas al trad$cir estas especificaciones, $n anlisis err%neos, $nos esA$emas <5L


P&ina 26 de !)*
mal diseCadosK+ C$antas ms Jerramientas y dia&ramas $semos, c$anto ms completos
intentemos ser, ms ries&o de distorsi%n de la informaci%n se corre+ =a&an $na pr$ebaH
en s$ pr%Lima re$ni%n social con ami&os EcJense $na partida a $n 9party &ame: llamado
M#at Poop, 1o$ CatU
"!
, $n B$e&o clsico conocido con otros nombres no tan malsonantes
como MPaper 'elepJoneU, en el A$e tan solo Jay dos tipos de transd$ccionesH de len&$aBe
formal a $n dib$Bo, y viceversa+ 'ras $nas pocas iteraciones el res$ltado es
sorprendentemente c%mico

(5:ur- 5I2. Cada interloc$tor intermedio en $na cadena de mensaBes
a$menta la probabilidad de distorsi%n
;$enteH R$ino

5.1.3. El modelo en cascada
#l 5odelo en Cascada
"2
es, de todos los modelos, el ms simple, y, a$nA$e eListen
m$cJas otras metodolo&>as ms fleLibles, es el bloA$e sobre el A$e se constr$yen la
mayor>a de ellas, por lo A$e nos servir para il$strar los problemas de A$e adolecen la
mayor>a de los enfoA$es clsicos


P&ina " de !)*
Se basa en A$e el desarrollo de $n softFare Ja de se&$ir $na sec$encia definida de fases+
Cada fase consta de $na serie de etapas y metas claramente definidas, y $na serie de
Jerramientas y procedimientos a se&$ir+ Si se detecta $na falla en $na de las fases, tan
solo es necesario volver $n paso atrs, a la fase anterior, y corre&ir+

(5:ur- 5I3. #sA$ema del 5odelo Lineal o en Cascada

Las fases de la 5etodolo&>a en Cascada sonH
Adquisicin de Requisitos de UsuarioH Se adA$ieren a travEs de los clientes los
reA$isitos del sistema, y se deciden c$ales de ellos debern ser c$biertos por el
softFare
Especificacin de Requisitos de SoftwareH Se describe el comportamiento
esperado en el softFare $na veD desarrollado+ #l in&eniero Ja de comprender el
mbito de la informaci%n del softFare as> como la f$nci%n, el rendimiento y las
interfaces reA$eridas+
DiseoH Definimos completamente la estr$ct$ra de los datos, la arA$itect$ra del
softFare, la l%&ica de pro&rama y el interfaD+
ImplementacinH #s en este p$nto, y no antes, c$ando empeDamos a desarrollar
c%di&o si&$iendo las especificaciones del diseCo+ #l desarrollador no necesita tener
conocimientos sobre reA$isitos+ Si el diseCo est bien realiDado, la trad$cci%n a
c%di&o ser casi mecnica+
Pru3>-H 'ras finaliDar completamente la implementaci%n, empieDa la fase de
pr$eba, en la A$e se &eneran entradas y se deber>an re&istrar salidas de ac$erdo a
los reA$isitos+
M-0t305,530toH #l softFare p$ede s$frir cambios, debido a errores detectados
A$e Jay A$e c$brir, o a meBoras A$e se solicitan+
RU
RS
OM
TR
D
RU
RS
OM
TR
D


P&ina "! de !)*
Como vemos, en la (5:ur- 5I, el modelo es bastante sencillo, y parece ser rob$sto+
Si&$iendo los preceptos de la Calidad en los Procesos, confiamos A$e, si c$mplimos
escr$p$losamente con los procesos definidos en cada $na de las etapas, el res$ltado final
se aB$ste a los reA$isitos iniciales+

(5:ur- 5I. Grfica ideal de desarrollo del modelo en cascada

Sin embar&o, este modelo adolece, A$iD, de demasiados inconvenientes en la mayor>a de
las sit$aciones, precisamente por s$ ri&ideDH
#s m$y dif>cil establecer completamente los reA$isitos desde $n principio, por lo
A$e, para evitar tener A$e volver atrs en fases posteriores, la fase de anlisis
p$ede alar&arse prod$ciendo estancamiento en el desarrollo+
0ara veD se c$mple eLactamente con la sec$encia y aparecen ciclos inesperados,
como p$eden ser A$e se presentes n$evos reA$isitos, o detectar A$e, por errores
en el diseCo, estos no Jan sido contemplados, siendo Estos ms catastr%ficos
c$anto ms adelante en desarrollo se localicen+ 1, precisamente, en este modelo,
la fase de pr$ebas est al finalK
#l cliente p$ede terminar perdiendo la paciencia, especialmente si se s$peran los
plaDos+ Solo va a ver s$ prod$cto al final del desarrollo+ #s ms, si A$isiera ecJar
$n vistaDo de 9por donde va s$ pro&rama: en $n momento dado, se p$ede
encontrar con A$e, pasado ms de la mitad del plaDo de entre&a, no se Ja
desarrollado $na sola l>nea, p$es aIn se est en la fase de anlisis y diseCo+
#l res$ltado final viene pareciEndose ms a la (5:ur- 5I5
Pruebas Anlisis y Diseo
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
MODELO EN CASCADA
GRFICA IDEAL DE DESARROLLO
Implementacin
Plazo
Entrega
Pruebas Anlisis y Diseo
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
MODELO EN CASCADA
GRFICA IDEAL DE DESARROLLO
Implementacin
Plazo
Entrega


P&ina "2 de !)*

(5:ur- 5I5H Grfica real de desarrollo en el modelo en cascada
5.1.4. Los modelos evolutivos
La eLcesiva ri&ideD del modelo en cascada en la act$alidad solo lo Jacen en cierto modo
vlido para sit$aciones m$y partic$lares en los A$e se dispon&a de tiempo ms A$e
s$ficiente para efect$ar el desarrollo, sin la presi%n del cliente+ Proyectos m$y compleBos
y eLtensos se p$eden abarcar si&$iendo por eBemplo las especificaciones de la 5Etrica "
""

Como alternativa, se Jan planteado modelos evol$tivos A$e permiten ir presentando
versiones parciales del softFare al cliente, tales como le modelo incremental o el modelo
espiral+
(5:ur- 5I". #l 5odelo Incremental
#l modelo incremental ((5:ur- 5I") tiene como filosof>a aplicar sec$encias lineales de
forma escalonada mientras pro&resa en el tiempo del calendario+ Cada sec$encia prod$ce
$n 9incremento: en el softFare, A$e se entre&a al cliente, A$e recibe softFare Itil y
meBorado cada cierto tiempo+ #s importante ver A$e los desarrollos se solapan en el
Pruebas A + D
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
MODELO EN CASCADA
GRFICA REAL DE DESARROLLO
Plazo
Entrega
Errores detectados
Nuevos requisitos
Entrega
Final
A
+
D
D
Implementacin
Anlisis extendido
Pruebas A + D
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
MODELO EN CASCADA
GRFICA REAL DE DESARROLLO
Plazo
Entrega
Errores detectados
Nuevos requisitos
Entrega
Final
A
+
D
D
Implementacin
Anlisis extendido

Anlisis Diseo Prueba Cdigo
Ingeniera de Sistemas
Tiempo de Calendario
incremento 1
incremento 2
incremento 3
incremento 4
Entrega del
1er. incremento
Entrega del
2 incremento
Entrega del
3er. incremento
Entrega del
4 incremento
Tiempo de Calendario
incremento 1
incremento 2
incremento 3
incremento 4
Entrega del
1er. incremento
Entrega del
2 incremento
Entrega del
3er. incremento
Entrega del
4 incremento


P&ina "" de !)*
tiempo, por lo A$e la adquisicin de requisitos se realiza al principio, y se espera A$e no
sea necesario A$e el cliente vaya a presentar n$evas especificaciones, a$nA$e, si lle&aran
a prod$cirse, podr>an inte&rarse en al&$no de los incrementos s$bsi&$ientes+

(5:ur- 5I7. 5odelo espiral

#l modelo espiral ((5:ur- 5I7 )es tambiEn iterativo por nat$raleDa, pero en el mismo los
desarrollos no se solapan, sino A$e cada v$elta de la espiral comienDa esc$cJando al
cliente y termina entre&ndole $n prod$cto, A$e el cliente evalIa y para darnos s$
opini%n y A$iD proponer meBoras o cambios+ #n las primeras iteraciones se p$eden
presentar modelos en papel o prototipos para adA$irir reA$isitos del cliente, mientras
A$e en las Iltimas se van entre&ando versiones ms completas del sistema diseCado+
Los mEtodos incrementales A$e Jemos visto s$p$sieron $n avance en la manera de
&estionar los proyectos de softFare, y sol$cionan, en cierto modo, el problema de tener
satisfecJo al clienteH
4$estro cliente no tiene A$e esperar Jasta el final para ver s$ softFare+ P$ede
verlo, tocarlo, $sarlo+ ,bserva con satisfacci%n como el prod$cto A$e Ja pedido va
tomando forma+
2l mismo tiempo, p$ede ir proponiendo meBoras, o advertirnos de los errores A$e
Jayamos podido cometer al adA$irir y plasmar los reA$isitos+
Pero este Iltimo p$nto, los reA$isitos cambiantes, se&$>a ca$sando problemas, por $na
raD%nH cada $no de los ciclos se&$>a basndose en $n ladrillo f$ndamentalmente r>&ido, el
modelo lineal sec$encial 2nalisisGDiseCoGC%di&oGPr$eba ((5:ur- 5I$)
Eje de punto de
entrada
del proyecto
Anlisis de Riesgos
Planificacin
Ingeniera
Construccin
y Adaptacin
Evaluacin
del cliente
Comunicacin
con el cliente
Eje de punto de
entrada
del proyecto
Anlisis de Riesgos
Planificacin
Ingeniera
Construccin
y Adaptacin
Evaluacin
del cliente
Comunicacin
con el cliente


P&ina "* de !)*
(5:ur- 5I$. #l modelo lineal sec$encia de la In&enier>a

#n el modelo sec$encial $na peA$eCa prop$esta del cliente p$ede s$poner A$e debamos
reJacer por completo todo $n diseCo y tener A$e volver a implementar $na enorme
cantidad de c%di&o+ 2dems, el c%di&o res$ltante de $sar este modelo s$ele ser costoso
de modificar, ya A$e est concebido para c$mplir de manera aB$stada a $n diseCo
espec>fico+
5.2. La Alternativa gil
'enemos entonces metodolo&>as iterativas o evol$tivas A$e nos permiten interact$ar con
el cliente, pero la aproLimaci%n a travEs de la in&enier>a clsica Jace A$e implementar los
n$evos reA$isitos A$e p$eda aportar res$lte casi proJibitivo+ NR$E JacerO
2A$> donde viene a ay$darnos el 9a&ilismo:+ <na de s$s premisas centrales es la
fleLibilidad+ Como dice Carlos -lE en s$ libroH 4;os requisitos cambiantes son bienenidos,
incluso en las etapas &inales del desarrollo5AGl, Carlos et al, >I:IBO9P
#l a&ilismo es el 9ladrillo perfecto: para los modelos evol$tivos o iterativos+ #l SC0<5
"*
,
por eBemplo, es $na metodolo&>a iterativa, A$e, en veD de $sar el modelo sec$encial de la
in&enier>a de softFare, Ja JecJo $so del a&ilismo+


P&ina "( de !)*
6. El Agislismo
#l !) de ;ebrero de 2!, $n &r$po de pro&ramadores y analistas, m$y cr>ticos con los
r>&idos modelos de desarrollo imperantes Jasta el momento, se re$nieron para tratar
sobre tEcnicas y procesos para desarrollar softFare+ #n la re$ni%n se ac$C% el tErmino
M5Etodos 8&ilesU para definir a los mEtodos A$e estaban s$r&iendo como alternativa a
las metodolo&>as formales (como, por eBemplo, la anteriormente comentada 5Etrica"
""
)
a las A$e consideraban eLcesivamente MpesadasU y r>&idas por s$ carcter normativo y
f$erte dependencia de planificaciones detalladas previas al desarrollo+ #ntre ellos estaban
\en -ecZ, el escritor del libro @7treme <ro"rammin" @7plainedAGec+, Q/, :CCCBOEP y A$e,
mas tarde, B$nto con David 2stels imp$lsar>an el s$r&imiento del 'DD AGec+, Q/, >IIEBO9P
AAstels, 3/, >IIEBO:P , o .eff 5c\enna, se&In la mayor>a , reconocido como creador de la
metodolo&>a SC0<5
"*
+
.$ntos, res$mieron los principios sobre los A$e se basan los mEtodos alternativos en
c$atro post$lados, lo A$e Ja A$edado denominado como el M-05<53/to #:59
35
+
6.1. El Manifiesto gil
#l 5anifiesto 8&il plantea A$e Jay A$e cambiar la escala de valores de ciertos elementos
del desarrollo del softFare+

(5:ur- "I1. #l 5anifiesto 8&il

V-9or-r ,8/ - 9o/ 5045@54uo/ ? /u 50t3r-225A0 Qu3 - 9o/ 1ro23/o/ ? B3rr-,530t-/.
#ste es posiblemente el principio ms importante del manifiesto, p$es reivindica
la labor final de pro&ramador y Ja dado pie al mas reciente movimiento del
(*o&t-are Cra&tmans.ip
EF
)Aartesan'a de so&t-areB, A$e ve al desarrollador ms
como $n 9maestro artesano: A$e a $n simple obrero de $na cadena ind$strial de
montaBe+ Por s$p$esto A$e los procesos ay$dan al trabaBo+ Son $na &$>a de
MANI(IESTO #GIL
#stamos desc$briendo formas meBores de desarrollar
softFare tanto por n$estra propia eLperiencia como
ay$dando a terceros+ 2 travEs de este trabaBo Jemos
aprendido a valorarH
I045@54uo/ 3 50t3r-225o03/ sobre procesos y Jerramientas
So<t=-r3 <u025o0-04o sobre doc$mentaci%n eLtensiva
Co9->or-25A0 2o0 39 29530t3 sobre ne&ociaci%n contract$al
R3/1u3/t- -0t3 39 2-,>5o sobre se&$ir $n plan
#sto es, a$nA$e valoramos los elementos de la derecJa,
valoramos ms los de la iDA$ierda+


P&ina "6 de !)*
operaci%n+ Las Jerramientas meBoran la eficiencia, pero sin personas con
conocimiento tEcnico y actit$d adec$ada, no prod$cen res$ltados
V-9or-r ,8/ 39 /o<t=-r3 Qu3 <u025o0- Qu3 9- 4o2u,30t-25A0 3NB-u/t5@-.
Poder ver anticipadamente c%mo se comportan las f$ncionalidades esperadas
sobre prototipos o sobre las partes ya elaboradas del sistema final ofrece $na
retroalimentaci%n m$y estim$lante y enriA$ecedor A$e &enera ideas imposibles
de concebir en $n primer momento] dif>cilmente se podr conse&$ir $n
doc$mento A$e conten&a reA$isitos detallados antes de comenDar el proyecto+
Los doc$mentos son soporte de la doc$mentaci%n, permiten la transferencia del
conocimiento, re&istran informaci%n Jist%rica, y en m$cJas c$estiones le&ales o
normativas son obli&atorios, pero se resalta A$e son menos importantes A$e los
prod$ctos A$e f$ncionan+ 5enos trascendentales para aportar valor al prod$cto+
V-9or-r ,8/ 9- 2o9->or-25A0 2o0 39 29530t3 Qu3 9- 03:o25-25A0 2o0tr-2tu-9.
Las prcticas &iles estn especialmente indicadas para prod$ctos dif>ciles de
definir con detalle en el principio, o A$e si se definieran as> tendr>an al final menos
valor A$e si se van enriA$eciendo con retroGinformaci%n contin$a d$rante el
desarrollo+ 'ambiEn para los casos en los A$e los reA$isitos van a ser m$y
inestables por la velocidad del entorno de ne&ocio+
#n estos casos el valor del res$ltado no es consec$encia de Jaber controlado $na
eBec$ci%n conforme a procesos, sino de Jaber sido implementado directamente
sobre el prod$cto+ <n contrato no aporta valor al prod$cto, sino la interacci%n con
el cliente+
V-9or-r ,8/ 9- r3/1u3/t- -9 2-,>5o Qu3 39 /3:u5,530to 43 u0 19-0.
Para $n modelo de desarrollo A$e s$r&e de entornos inestables, A$e tienen como
factor inJerente el cambio y la evol$ci%n rpida y contin$a, res$lta m$cJo ms
valiosa la capacidad de resp$esta A$e la de se&$imiento y ase&$ramiento de
planes preGestablecidos+ Los principales valores de la &esti%n &il son la
anticipaci%n y la adaptaci%n] diferentes a los de la &esti%n de proyectos ortodoLaH
planificaci%n y control para evitar desviaciones sobre el plan+
De todo ello dimanan los !2 principios del a&ilismo
")
, A$e no reprod$ciremos aA$> para
no eLtendernos eLcesivamente, pero de los A$e destacaremos estas ideasH
Dil$ir las f$ertes fronteras BerrA$icas entre analistasGdiseCadoresGpro&ramadores,
de manera A$e todos los inte&rantes del proyecto participan en cada $na de las
fases+
Contin$a colaboraci%n con el clienteH se adA$ieren $nos pocos reA$isitos, se
desarrolla la parte del softFare A$e las c$mple, se le m$estra, y se toman n$evos
reA$isitos, ya sea modificaciones a lo eListente o ampliaciones de la f$ncionalidad+


P&ina ") de !)*
2 primera vista esta forma de enfocar la sol$ci%n de $n proyecto cJoca frontalmente con
la de la in&enier>a, ya A$eH
Se trabaBa con adA$isiciones parciales de reA$isitos, A$e, adems p$eden ser
cambiantes+
4o eListe $n diseCo arA$itect%nico o de datos previo a la implementaci%n, ya A$e
ser>a abs$rdo, dados los reA$isitos cambiantes+
Sin $nas especificaciones completas de diseCo, la persona A$e implementa
trabaBa sobre los reA$isitos+
#n $n primer vistaDo el a&ilismo se nos antoBa, a las personas A$e, como yo, Jemos
realiDado desarrollos 9en cascada: (mi Proyecto de ;in de Carrera para la Diplomat$ra f$e,
precisamente, $n trabaBo de 2nlisis y DiseCo $sando 1o$rdonA0ourdon, @/ A:C?>BO:DPB,
al&o absol$tamente ca%tico+ Se&$idor convencido Jasta aJora de ladrillos como la
95Etrica":, siempre Jab>a prom$l&ado A$e lanDarse a pro&ramar sin $na completa
planificaci%n previa, era $n abs$rdo+ NC%mo p$ede f$ncionar bien al&o as>O
#ste es, precisamente, el ar&$mento principal de s$s detractores, A$e las metodolo&>as
&iles adolecen de control y planificaci%n, mientras A$e los 9a&ilistas: eLponen A$e, si a lo
lar&o del proyecto aparecen desviaciones sobre el plan, Estas no se deben controlar para
eliminarlas, sino adaptarse a ellas, o el prod$cto final no ser lo A$e en verdad necesita el
cliente+ Se&In estos Iltimos, $na planificaci%n inicial eLcesivamente r>&ida lo Inico A$e
consi&$e red$cir la calidad final del prod$cto+

(5:ur- "I2H 2&ilismo +vs+ 5etodolo&>as Clsicas+ 2daptaci%n +vs+ Planificaci%n y Control
6.2. El Agilismo y sus herramientas
NC%mo p$ede el a&ilismo sobreponerse al caosONPor A$E no s$c$mbe $n proyecto 9&il:
ante las incertid$mbres de la falta de planificaci%n eLJa$stiva, ante los reA$isitos
inesperadosO PorA$e Jace $so de Jerramientas A$e le permiten 9adaptarse al cambio:
con ELitoH
5etodolo&>as como SC0<5 para coordinar el proyecto
=erramientas como -DD para interact$ar con el cliente a la Jora de adA$irir los
reA$isitos y Jacer se&$imiento de s$ c$mplimiento+
A4-1t-r/3 -9 2-,>5o
(2&ilismo)
.V/.
P9-05<52-25A0 ? Co0tro9 1-r- 3@5t-r 43/@5-25o03/ 439 19-0
(5etodolo&>as clsicas)


P&ina "? de !)*
#l 'DD como metodolo&>a para el desarrollo del softFare, A$e se basa en estos
pilares para tener ELitoH
o SofFare CraftmansJip
o Contin$a 0efactoriDaci%n
o Clean Code
o Code R$ality
Intentemos mostrar $na visi%n conB$nta de c%mo todas estos elementos actIan en
perfecta siner&ia, y l$e&o entraremos en prof$ndidad sobre cada $na de ellas, viendo
como se Jan $sado en el desarrollo de este ';G+
Partimos de $na idea baseH $sar mEtodos iterativosGevol$tivos+ #l cliente Ja de recibir
n$evas versiones meBoradas de s$ softFare cada cierto tiempo, probarlas, y plantear las
meBoras pertinentes, si son necesarias+ <n marco de trabaBo o &rame-or+ diseCado
espec>ficamente para esta 9resp$esta rpida al cambio: es el SC0<5, en la A$e en cada
ciclo, de " o * semanas, se presenta al cliente $na n$eva versi%n meBorada del prod$cto+
Cada ciclo empieDa seleccionando la serie de reA$isitos A$e se van a implementar, y
planificando s$ distrib$ci%n entre el eA$ipo, y finaliDa comprobando A$e dicJos reA$isitos
f$ncionan+ Cada d>a Jay $na sesi%n de 9sincroniDaci%n: en la A$e se revisa el estado de
cada eA$ipo de trabaBo y se actIa en consec$encia+
NC%mo se &estionan los reA$isitosO NC%mo los adA$irimos, se los pasamos al eA$ipo de
desarrollo, y comprobamos A$e Jan sido aCadidos a la n$eva versi%n del softFareO 2A$>
viene en n$estra ay$da otra n$eva Jerramienta, el -DD, o -eJavior Driven
Developement+ #l -DD
"?
f$e $na evol$ci%n del 2'DD
"6
(2ceptance 'est Driven
Deveolpement) A$e permit>a servir como neLo entre las peticiones de los clientes y los
ciclos 'DD+ Con cada ciclo 'DD, con cada pr$eba, comprobamos si $n elemento del
sotFare ($n m%d$lo en $n test $nitario o la interacci%n entre varios sistemas en $n test
de inte&raci%n) responde a conforme a lo esperado+ Pero a veces res$lta dif>cil ver cosas
tales como ND%nde empieDo a trabaBar con el 'DD para c$mplir con el reA$isito de mi
clienteO NR$E debo testear y A$e noO NC$ndo parar, c$ndo mis test Jan c$bierto
completamente lo A$e mi cliente me pideO #l -DD, como l$e&o veremos, permite obtener
los reA$isitos del cliente en $n len&$aBe nat$ral, A$e El mismo entiende, y, al mismo
tiempo, especificarlos de manera A$e sean fciles de se&$ir e implementar a travEs de
'DD+
1a tenemos las Jerramientas A$e permiten adA$irir los reA$isitos, Jacer $n se&$imiento,
y comprobar A$e se estn c$mpliendo+ 2Jora necesitamos la Jerramienta A$e nos
permita ir a&re&ando, paso a paso, por acreci%n, dicJos reA$erimientos al softFare+ 1
dicJa Jerramienta es el 'DD+
#l 'DD nace de $na necesidad+ #n sistemas de trabaBo como el #Ltreme Pro&rammin& o
SC0<5 Jablamos de la constante modificaci%n en el softFare, A$e crece a medida se le
aCaden las f$ncionalidades A$e los reA$isitos de $s$ario eLi&en+ 'odos los pro&ramadores


P&ina "6 de !)*
sabemos lo peli&roso A$e es ir retocando l>neas de c%di&o, en como 9$n cambio aA$>:
termina 9Jaciendo A$e al&o falle all:+
Para mantener el control sobre $n c%di&o f$ente en permanente cambio, se JiDo casi
imprescindible el $so de $na Jerramienta por entonces no demasiado pop$lar, los 9test
$nits:, peA$eCos fra&mentos de c%di&o escrib>amos para comprobar A$e las f$nciones ya
desarrolladas se&$>an f$ncionando correctamente tras cada inevitable refactoriDaci%n+
Por fin ten>amos n$estro c%di&o baBo control+ NSe&$roO
#n realidad era m$y dif>cil &arantiDar A$e los test c$brieran todos y cada $na de las
diferentes f$nciones del softFare+ <sar como &$>a los 9casos de $so: res$ltaba
absol$tamente ins$ficiente+ =ab>a A$e, a posteriori, analiDar cada mEtodo, cada clase, e
ima&inar como podr>a responder ante c$alA$ier entrada+ Siempre A$edaba la d$da de si
Jab>a al&o A$e no Jab>as tenido en c$enta+ 2 veces A$edaban f$nciones sin testear,
intencionadamente o no+
;inalmente, todo ello desemboc% en $na ideaH en veD de desarrollar y l$e&o crear los test
A$e &arantiDaran A$e lo ya desarrollado se&$ir>a f$ncionando tras los f$t$ros aCadidos,
Npor A$E no Jacerlo al revEsOH
La idea es A$e cada reA$isito de softFare se definiera en base a eBemplos (casos)
A$e el c%di&o deb>a c$mplir+ #n cada incremento implementamos el c%di&o A$e
satisface $n eBemplo, en ciclos de tres pasosH
o <na veD ele&ido el reA$isito (caso, aceptaci%n del cliente, eBemplo), se
plantea el test A$e compr$eba A$e el softFare implementa el reA$isito+
,bviamente, el test ;2LL2+
o L<#G, se aCade al c%di&o ya eListente las l>neas A$e Ja&an A$e dicJo
reA$isito, solamente dicJo reA$isito, se c$mpla+ 'enemos 9l$D verde: en el
test+
o #s el momento de refactoriDar el c%di&o, tanto como sea necesario, Jasta
A$eH
#stemos satisfecJos con la calidad del c%di&o res$ltante
',D,S los test den l$D verde+
#l softFare va creciendo, por tanto, en base a peA$eCos microincrementos+ <n caso cada
veD, $na aceptaci%n cada veD, $n test cada veD+ Pasamos a 9Desarrollo Diri&ido por 'estsU,
=ab>a nacido el 'DD+
#sta n$eva manera de entender el desarrollo del softFare, necesita, sin embar&o, para
f$ncionar estar bien apoyada en s%lidos principiosH
0ealiDar $na correcta, completa y eLJa$stiva refactoriDaci%nAFo-ler, 8artin/,
:CCCBO=P a cada paso+ 4o se debe d$dar en tener A$e desecJar c%di&o


P&ina * de !)*
implementado+ #n cada iteraci%n, n$estro c%di&o va a meBorar, y podemos confiar
en A$e n$estros test nos avisarn c$ando toA$emos al&o A$e no debamos+
#n este entorno en el A$e debemos reestr$ct$rar el diseCo de las clases
contin$amente, la 9Calidad del C%di&o: (Code R$ality) es imperativa+ 5antener los
principios S,LID
*
en las clases es a la veD $na necesidad y $n res$ltado final de la
contin$a refactoriDaci%n en 'DD+ Para ello nos podemos ay$dar de Jerramientas
A$e, d$rante el desarrollo, nos permitan comprobar la calidad de n$estro c%di&o a
travEs de ciertas mEtricas
*!
+
#l c%di&o desarrollado, al tener A$e ser contin$amente retocado, a veces por
distintos eA$ipos de desarrollo, eLi&e CL20ID2D+ 4o Jablamos de A$e este
comentado y doc$mentado, sino A$e si&a los preceptos del (Clean Code)A8artin,
6obert C/ >II?BO::P+
'odos estos principios reA$ieren de $n eA$ipo de desarrolladores motivados y
c$alificados A$e &aranticen la prod$ctividad del procedimiento+ Se impone
absol$tamente la visi%n de MSoftFare CraftmansJipU A$e comentamos como
f$ndamental en el primero de los valores del a&ilismo+
Con todo ello, el 2&ilismo proclama s$ ventaBa frente a los mEtodos clsicos en la mayor>a
de los proyectos+ #Liste $na &ran controversia sobre las ventaBas de $no sobre otro
La ri&ideD en la planificaci%n de los proyectos en cascada normalmente lo JacenH
o 5as predecible en plaDos de entre&a y costes, p$es se definen claramente
desde el principio, lo c$al es precisamente lo A$e desean ciertos tipos de
&randes clientes, como los or&anismos pIblicos+
o 'ambiEn es, en cierto modo, menos sensible a los cambios en los
inte&rantes del eA$ipo, por la misma raD%n+
o Por el contrario, introd$cir $n cambio inesperado en el diseCo p$ede ser
catastr%fico, lo A$e s$pone desde enormes costes y cambios en plaDos de
entre&a, Jasta abandonos del proyecto+ #stos cambios s$r&en con
frec$encia como res$ltado de errores detectados en las pr$ebas, A$e en
esta metodolo&>a se realiDan al final, c$ando las modificaciones son ms
compleBas y costosas+
Los proyectos &iles son eLactamente lo contrarioH
o S$ fleLibilidad los Jace menos predecibles en plaDos de entre&a y costes,
pero ms adaptables a cambios+ Por tanto, si no son proyectos de &ran
enver&ad$ra (es decir, para la mayor>a de los proyectos) res$lta $na
alternativa ms vlida+
o 2l no Jaber doc$mentaci%n formal eLJa$stiva, son ms sensibles a los
cambios en los inte&rantes del &r$po+


P&ina *! de !)*
o La intensa colaboraci%n del cliente p$ede lle&ar a ser conflictiva en al&$nas
ocasiones, por lo A$e se necesita $na firma implicaci%n del mismo+
#s por ello A$e, se&In al&$nas f$entes f$entes, la tasa de ELitos res$lta m$cJo mayor en
los proyectos &iles, como m$estra la ;i&$ra 6G"H
(5:ur- "I3. Comparativa de ELito entre mEtodos 8&iles y 5odelo en Cascada
2Jora bienH NR$E pasa con la calidad del c%di&oO Se&In al&$nos est$dios, como el
realiDado por SJine 'ecJnolo&ies
*2
o Scott 2mbler
*"
parece ser A$e tambiEn s$pera a las
metodolo&>as ms clsicas+ #l inte&rar en s$s eA$ipos a pro&ramadores altamente
c$alificados o 9senior pro&rammers: (primer valor del manifiesto &il) y $tiliDar la contin$a
refactoriDaci%n prestando m$cJa atenci%n al Clean Code y a las clases S,LID, prod$ce
meBores res$ltados A$e las implementaciones JecJas por pro&ramadores normalmente
menos c$alificados de las arA$itect$ra de softFare A$e presentan los in&enieros en s$
doc$mentaci%n, aIn con la eListencia de $n sistema de SR5 (SoftFare R$ality
5ana&ement)
**
+
Pasemos aJora a ver en mayor prof$ndidad c$les son estas Jerramientas A$e parecen
&arantiDar s$ ELito+
6.2.1. SCRUM
#l SC0<5 es $n frameForZ de trabaBo, esboDado con ese mismo nombre por primera veD
en !6?6 por =irota 'aZe$cJi
*(
e IZ$Biro 4onaZa
*6
en s$ art>c$lo 4$.e 2e- <ro%ect
3eelopement Game5 A$a+euc.i, H/ R 2ona+a, H :C?FBO:9P, a$nA$e no f$e Jasta el aCo
!66" c$ando se JiDo $n primer desarrollo si&$iendo esta metodolo&>a (.eff S$tJerland,
.oJn Sc$mniotales y .eff 5c\enna)+ #n !66( \en ScJFaber
*)
normaliD% s$ metodolo&>a+
#s $no de los mEtodos A$e sirvi% de inspiraci%n en el 5anifiesto 8&il, en c$ya creaci%n
particip% .eff 5c\enna+
4o vamos a eLtendernos m$cJo en s$ definici%n, ya al tratarse de $n proyecto parcial con
$n eA$ipo de $na sola persona, no se Ja $tiliDado+ Pero es importante eLplicar s$
f$ncionamiento para entender c%mo se inte&ran el resto de Jerramientas del a&ilismo+


P&ina *2 de !)*
E9 Pro23/o
#l SC0<5 es $n mEtodo iterativo en A$e cada ciclo o iteraci%n es de corta d$raci%n ($n
mes nat$ral o Jasta dos semanas)+ #n cada iteraci%n se obtiene $n res$ltado completo,
$n incremento sobre el prod$cto final A$e p$ede entre&arse al cliente+
(5:ur- "I. #l proceso SC0<5
;$enteH Proyectos2&iles+or&
Como observamos en la ;i&$ra 6G*, en el SC0<5 se parte de $na lista prioriDada de
obBetivos, A$e actIa como plan del proyecto+ #n esta lista, el cliente prioriDa los mismos
balanceando el valor A$e le aportan respecto a s$ coste, y A$edan repartidos en las
correspondientes iteraciones y entre&as+ De esta manera, el cliente p$ede maLimiDar la
$tilidad de lo A$e se desarrolla y el retorno de inversi%n+ 2l mismo, tiempo, el sistema
A$eda abierto a adA$isici%n de n$evos reA$isitos+
Las actividades del SC0<5 sonH
P9-05<52-25A0 43 9- 5t3r-25A0. #l primer d>a de cada iteraci%n, se realiDa la
planificaci%n, en dos partesH
o Selecci%n de reA$isitos (* Joras mLimo)H #ntre el cliente y el eA$ipo se
revisa la lista prioriDada de reA$isitos, resolviendo las d$das A$e p$dieran
s$r&ir por ambas partes+ Se eli&e la si&$iente lista de reA$isitos a c$mplir
o Planificaci%n de la iteraci%n (* Joras mLimo)H #l eA$ipo elabora la lista de
tareas de la iteraci%n necesarias para c$mplir los reA$isitos+ Los miembros
del eA$ipo estiman conB$ntamente el esf$erDo y se a$toasi&nan las tareas+


P&ina *" de !)*
E732u25A0 43 9- 5t3r-25A0. #n cada iteraci%n, tambiEn llamados 9sprint:, cada
miembro del eA$ipo realiDa las tareas asi&nadas en la planificaci%n, teniendo en
c$enta A$e dispone de dos elementos importantes de ay$daH
o 0e$ni%n de sincroniDaci%nH Cada d>a de prod$ce $na re$ni%n de
sincroniDaci%n de !( min$tos en la A$e cada miembro inspecciona el
trabaBo del resto del eA$ipo (dependencias de tareas, pro&reso y
obstc$los) para Jacer las adaptaciones necesarias+ #ste p$nto es cr>tico,
principalmente por las dependencias+ #n cada re$ni%n cada miembro del
eA$ipo plantea
NR$E Je JecJo desde la Iltima re$ni%nO
NR$E ten&o A$e JacerO
NC$les son mis impedimentosO
N#Listen dependencias con las tareas de otros eA$iposO
o #Liste la fi&$ra del 9facilitador:, l>der del eA$ipo, A$e se encar&a de resolver
las d$das y c$alA$ier problema A$e p$diera red$cir la prod$ctividad, as>
como velar por el c$mplimiento de los procesos del SC0<5H coordina las
re$niones con el cliente y &$>a las re$niones con el mismo e intraeA$ipos,
prepara las listas de reA$isitos, ay$da al eA$ipo en s$ a$to&esti%n lo
separa de las interr$pciones eLternas, siendo el neLo con c$alA$ier
necesidad eLterior+
I0/13225A0 ? A4-1t-25A0. #l Iltimo d>a de la iteraci%n Jay $na re$ni%n de revisi%n,
en dos partesH
o Demostraci%n(* Joras mLimo)H #l eA$ipo presenta al cliente los reA$isitos
completados, en forma de prod$cto completado+ #l cliente plantea las
adaptaciones A$e considere, replantendose el proyecto si es necesario+
o 0etrospectiva (* Joras mLimo)H #l eA$ipo analiDa c%mo Ja sido s$ manera
de trabaBar, y los problemas A$e le Jan impedido pro&resar
adec$adamente, si los J$biera+ #l facilitador se encar&ar de ir eliminando
los obstc$los identificados
Lo/ <u04-,30to/
Como Jemos visto, el proceso del SC0<5 es bastante simple, y se f$ndamente en estas
premisasH
Desarrollo incremental en bloA$es temporales cortos y fiBos
PrioriDar los reA$isitos por valor del cliente y coste del desarrollo


P&ina ** de !)*
Control emp>rico del proyecto, no basado en doc$mentaci%n+ #l eA$ipo se
sincroniDa diariamente y al final de cada iteraci%n se esc$cJa al cliente
Se potencia a los individ$os del eA$ipo, A$e se comprometen a Jacer $nas
entre&as y se les otor&a la a$toridad para or&aniDar s$ trabaBo
Para evitar problemas con el p$nto anterior, se sistematiDa la colaboraci%n y la
com$nicaci%n
=ay $na f$erte 9timeboLin&: en las actividadesH se fiBa el tiempo mLimo para
realiDar $na tarea, conse&$ir $nos obBetivos o tomar las decisiones+
Lo/ r3Qu5/5to/
Como se p$ede apreciar, el f$ncionamiento del SC0<5 es radicalmente diferente a otras
metodolo&>as, y para A$e f$ncione correctamente, se deben re$nir ciertos reA$isitosH
C$lt$ra de empresa basada en eA$ipo, dele&aci%n, creatividad y meBora contin$a+
Compromiso del cliente en la direcci%n de los res$ltados del proyecto
Compromiso de la direcci%n de la or&aniDaci%n para resolver los problemas
endEmicos, realiDar cambios or&aniDativos si es necesario, formar eA$ipos
a$to&estionados y m$ltidisciplinares y fomentar la c$lt$ra de la empresa citada al
principio+
Compromiso conB$nto y de colaboraci%n de todo el eA$ipo
;$erte relaci%n de colaboraci%n y transparencia entre proveedor y cliente
;acilidad para realiDar cambios en el proyecto
'amaCo del eA$ipo entre ( y 6 personas
#A$ipo trabaBando en $n espacio comIn para facilitar la com$nicaci%n
Dedicaci%n del eA$ipo a tiempo completo
#stabilidad en los miembros del eA$ipo+
6.2.2. Behaviod-Driven Developement (BDD)
=emos visto en el SC0<5 A$e cada iteraci%n parte de $na Mlista de reA$isitos prioriDadaU+
#Listen m$cJas maneras de establecer dicJa lista de reA$isitos+ #n la in&enier>a de
softFare se definen $na &ran cantidad de mEtodos formales+ Por eBemploH


P&ina *( de !)*
#n 2nlisis #str$ct$rado partimos de $n entorno y de $na lista de eventos del
sistema, cada $no de los c$ales se convertir en $na b$rb$Ba A$e la procesar+
#n el diseCo orientado a obBetos tenemos actores y casos de $so+
Sin embar&o, para las metodolo&>as &iles, como el SC0<5, si bien p$dieran ser $sadas,
presentan el inconveniente A$e eLp$simos al principio de este doc$mentoH el 9telEfono
roto:+ #Listen tres transd$cciones bsicas entre en cliente y el desarrollador final H
#l cliente eLpone s$s reA$isitos en len&$aBe formal, A$e $n analista deber
trad$cir en al&$no de los esA$emas anteriormente mencionados, en la confianDa
de sean claros, concisos y completos+
#l pro&ramador interpretar dicJos dia&ramas, eLtraer el reA$isito, e intentar
dil$cidar c%mo atacar s$ inte&raci%n en el desarrollo a base de iteraciones 'DD+
;inalmente, en la re$ni%n de demostraci%n, deberemos convencer al cliente de
A$e dicJa 9b$rb$Ba: o dicJo 9caso de $so: se Ja inte&rado en s$ softFare, c$ando
el pobre $s$ario no tiene por A$E tener los conocimientos tEcnicos A$e le
permitan interpretarlo+
Si finalmente, en la demostraci%n, el softFare no c$mple con lo A$e el cliente A$er>a, no
sabremos si es porA$e se tomaron mal los reA$isitos, si porA$e el analista no JiDo bien s$
trad$cci%n a dia&ramas, si es A$e el desarrollador no JiDo bien s$ trad$cci%n de
dia&ramas a c%di&o, o si, simplemente, el desarrollador no c$mpli% con s$s obBetivos+
Las metodolo&>as &iles, como el SC0<5, donde los desarrolladores participan en las
re$niones con el cliente, A$e disponen de re$niones de sincroniDaci%n y la labor del
facilitador, son m$cJo menos sensibles a estos 9errores de trad$cci%n:, pero, aIn as>,
f$ncionan meBor con $n sistema de reco&ida y re&istro de reA$isitos ms adec$ado a s$
idiosincrasia+
1 es aA$> donde viene en s$ ay$da el -DD, A$e naci% como $na evol$ci%n del 'DD y el
2'DD+
TDD ? ATDD
#n el 'DD, como l$e&o veremos, vamos desarrollando el softFare paso a paso+ 2 base de
tests comprobamos si cada caso posible, cada eBemplo A$e entre en n$estro sistema, es
tratado adec$adamente y se recibe el res$ltado correcto+ Con esta metodolo&>a, poco a
poco, paso a paso, nos ase&$ramos A$e cada f$ncionalidad, cada reA$isito A$e aCadimos
est correctamente inte&rado en el sistema+ Pero, como reDa $n vieBo A$iasmo MSon todos
los A$e estn, peroK Nestn todos los A$e sonOU
#l 'DD nos ay$da a caminar con paso firme, pero no nos &$>a en c$l debe ser n$estro
pr%Limo paso+


P&ina *6 de !)*
#l problema radica en A$e, a travEs de $na sola Jerramienta, los tests, estamos
intentando sol$cionar dos problemas diferentesH
Comprobar si estamos c$mpliendo con $n reA$isito
Comprobar si n$estro softFare f$nciona de la manera adec$ada
#n realidad, lo A$e oc$rre es A$e debemos ser conscientes de A$e n$estra Jerramienta
f$nciona 2 D,S 4I/#L#S+ =ay dos tipos y $sos del 'DDH
ATDD. #n 2'DD (2ceptance 'estGDriven Desi&n) para cada reA$isito escribimos $n
test de aceptaci%n (aceptante test), en el A$e especificamos $n comportamiento
(o reA$isito) A$e n$estro softFare debe c$mplir+ L$e&o escribimos el c%di&o
necesario para A$e dicJo test pase+
TDD 43 D3/-rro99o. 5ediante $n test de desarrollo A$e comprobamos es si
f$ncionan correctamente los elementos de n$estro diseCo, es decir, si, dada $na
entrada en el sistema, se prod$ce la salida esperada+ ;$nciona de la misma
manera A$e el anteriorH primero creamos el test y l$e&o aCadimos el c%di&o A$e
Jace A$e dicJo test pase+
#l 2'DD es, por tanto, A$ien &arantiDa A$e se c$mplen todos los reA$isitos+ #l 'DD de
desarrollo, o, simplemente, 'DD, es el A$e se encar&a de A$e los reA$isitos A$e se
inte&ren en el sistema lo Ja&an correctamente+
D-0 NortB ? BDD
#l tndem 2'DDW'DD es el A$e nos Jace, por tanto, pro&resar en el desarrollo del
softFare+ #n el desarrollo 2'DD partimos de aceptaciones basadas en reA$isitos, y cada
aceptaci%n la eLpresamos en $n test 2'DD, y desarrollamos toda la l%&ica necesaria para
c$mplirla con 'DD+
Sin embar&o, si&$e eListiendo $n vac>oH
NC%mo obtenemos los reA$isitos A$e sirven para n$estra lista de aceptaciones
2'DDO
NC%mo ase&$ramos A$e est completaO
Podr>amos, como antes diBimos, $tiliDar listas de eventos o casos de $so, pero A$ed% claro
A$e res$ltan demasiado cr>pticas para el cliente+ 2l mismo tiempo, y si no se tiene
demasiada eLperiencia en 'DD, es frec$ente encontrarse en calleBones sin salidaH
NR$E testear y A$E no testear en cada aceptaci%nO NPor d%nde empieDo el los 'DD
de desarrolloO NC$ndo acaboO
NC$l debe ser mi si&$iente pasoO


P&ina *) de !)*
#ra necesario dar $n cierto enfoA$e formal, sin inc$rrir n$evamente en compleBas
doc$mentaciones+
#n el aCo 2*, Dan 4ortJ
*?
y otros colaboradores, tras varios aCos de desarrollar
2'DDW'DD, prop$sieron $na sol$ci%n a este problema+ Ide% $na manera de estr$ct$rar el
proceso de 2'DD, los test de 9alto nivel:, centrndose en los 9comportamientos:
esperados del softFare, no en como debe ser implementada la l%&ica del mismo+ Lo llam%
-eJavio$rGDriven Developement o -DD
*6
+
#n el interesante art>c$lo (Hntroducin" G33) A2ort., 3/ >II9BO:EP, Dan eLplica como f$e
mad$rando la idea del -DD, basada en los conceptos de 9=istoria de $s$ario:
(
y en c%mo
trad$cirlas de manera formal para A$e f$eran fcilmente interpretables tanto por $n
desarrollador 'DD como por el cliente final+
Lo A$e necesitamos, por tanto, es tomar cada reA$isito y eLpresarlo con $na f%rm$la A$eH
Sea lo s$ficientemente simple para A$e el cliente p$eda entenderla y se&$ir s$
c$mplimiento+
Sea lo s$ficientemente estr$ct$rada como para indicar al desarrollador los pasos
A$e debe ir dando para, a travEs de 'DD, inte&rar dicJo reA$isito en el softFare+
La idea es brillantemente simpleH tomar cada reA$erimiento del $s$ario y eLpresarla
formalmente mediante $na 9plantilla:, tal como la de la ;i&$ra 6G(H

(5:ur- "I5H Plantilla para $na 9Jistoria de $s$ario: en -DD
;$enteH dannortJ+net
Como podemos apreciar, se compone de tres partesH
<n t>t$lo, donde se eLpresa de manera absol$tamente narrativa, en len&$aBe
nat$ral, c$l es el reA$isito A$e se desea implementar+ 4ormalmente, eLpresada
directamente por el cliente
Title (one line describing the story)

Narrative:
As a [role]
I want [feature]
So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...

Scenario 2: ...


P&ina *? de !)*
<na narrativa, donde se especifica A$ien necesita la f$nci%n (rol), A$e es lo A$e se
necesita (feat$re) y c$l es el beneficio esperado (-enedit)+ #n este p$nto,
normalmente trabaBando conB$ntamente el cliente y el eA$ipo de desarrollo, se
define de de manera formal el reA$isito A$e A$eremos satisfacer+
;inalmente, los criterios de aceptaci%n, eLpresados en forma de escenarios+ #n
cada $no de ellos se especifica el conteLto ^conteLt_, el evento A$e activa n$estro
sistema ^event_ y los res$ltados esperados ^o$tcome_+ 'odo ello con $na f%rm$la
fcil de recordar y repetirH 9Gien-S.en-$.en) #n esta parte es donde el
desarrollador 'DD interviene en mayor medida, p$es, prcticamente detalla c%mo
Ja de dar forma a s$ test de aceptaci%nH la car&a de precondiciones, el elemento
de c%di&o A$e Ja de invocar, y de A$E elemento Ja de comprobar el res$ltado+
Como vemos, esta simple plantilla nos res$elve todos los problemas A$e planteamos al
inicioH
NC%mo obtenemos los reA$isitosO 'omamos $na Jistoria de $s$ario y nos
centramos en la narrativaH (H -antT)
NC%mo ase&$ramos A$e esta completaO C$ando el cliente no ten&a ms Jistorias
de $s$ario A$e contarnos
NR$E testear y A$e no testear en cada aceptaci%nO NPor donde empieDoO NDonde
acaboO NC$l debe ser mi si&$iente pasoO Implementa cada escenario, paso a
paso, de $no en $no, siempre teniendo en mente c$l es el si&$iente+
`ste es $n proceso iterativo A$e se inte&ra perfectamente en la forma 9&il: de trabaBar, y
en el modelo SC0<5 en partic$lar+ Podemos claramente identificar esas primeras * Joras
de selecci%n de reA$isitos, en las A$e se establecen las Jistorias de $s$ario a c$brir en la
iteraci%n y c%mo cada miembro eli&e los escenarios a c$mplir, y como en la re$ni%n final
de la iteraci%n, en la demostraci%n de reA$isitos, Jistorias de $s$ario en mano, el cliente
p$ede comprobar fcilmente A$e s$s reA$erimientos Jan sido c$mplidos+
#s importante se&$ir al&$nas re&las a la Jora de crear las Jistorias de $s$ario, tanto para
A$e el cliente no se pierda con especificaciones demasiado compleBas, como para A$e el
desarrollador obten&a los s$ficientes detalles A$e le &$>en en el trabaBo+ /emos, en la
;i&$ra 6G6, $n eBemplo de 9$na b$ena Jistoria:, A$e Ja de c$mplirH
E9 t;tu9o 43>3 43/2r5>5r u0- -2t5@54-4, A$e ser la A$e n$estro softFare facilite, si
J$biera sido 92cco$nt mana&ement: o 92'5 2ctivity: nos res$ltar>a ms dif>cil de
determinar c$ando Jemos c$mplido con la Jistoria de $s$ario+ Los l>mites
A$edar>an conf$sos, dif$minados+
L- 0-rr-t5@- 43>3 5029u5r ro9M r3Qu3r5,530to ? >303<525o+ 4o basta solo con el
reA$erimiento, a$nA$e se trate del obBetivo final+ #l rol nos ay$da a identificar con
A$iEn debemos Jablar sobre el reA$erimiento a c$mplir+ #l beneficio nos aclara
por A$E debemos c$mplir el reA$isito, lo A$e nos ay$da a enfocarnos meBor+ Por
otra parte, si encontramos A$e el reA$erimiento a c$mplir, en realidad, no nos da
el beneficio indicado, esto es $n indicativo de A$e la Jistoria est mal planteada+


P&ina *6 de !)*
E9 t;tu9o 2-4- 3/230-r5o 43>3 /3r 43/2r51t5@o 439 373,19oM ? /3r 29-r-,30t3
45<3r30t3/ u0o/ 43 otro/. 4ombres va&os como 9caso !:, 9caso 2: son
absol$tamente inapropiados+ Solo con mirar el t>t$lo ya deber>amos entender
claramente A$E estamos comprobando en el escenario, y con $n vistaDo &eneral
tener claro si se Jan contemplado todas las posibles sit$aciones+
E9 t;tu9o 439 3/230-r5o 43>3r;- 50452-r /o9o 9o Qu3 3/ 45<3r30t3. Si $n conteLto
similar se repite en todos los escenarios, no es necesario especificarlo en el t>t$lo+
#n el eBemplo, no necesitamos empeDar cada t>t$lo del escenario con 4Cuando el
cliente a al ca%ero a sacar dineroT5
E9 3/230-r5o 43>3 3/1325<52-r/3 30 tGr,50o/ G5@30I'B30ITB30. #s lo A$e da s$
potencia al -DD+ #l $tiliDar esta terminolo&>a elimina por completo las
ambi&aedades, y ay$da a los desarrolladores a trad$cirlos en test de aceptaci%n,
ya A$e identifica claramente los reA$isitos (y ay$da a determinar si se nos escapa
al&$no), A$E debemos testear y, eLactamente, A$E debemos comprobar+
Lo/ RG5@30S 43>30 23O5r/3 -9 2o0t3Nto 3N29u/5@-,30t3 0323/-r5o 1-r- 39
3/230-r5o. 2 la Jora de realiDar $n test, ya sea de aceptaci%n o $nitario, debemos
de intentar aislar s$ comportamiento de elementos eLternos A$e p$dieran falsear
s$ res$ltado+ Por tanto, si $n preGreA$isito no es necesario para el escenario,
debemos descartarlo+
E9 3@30to J=B30K 43>3 3/1325<52-r 29-r-,30t3 2u89 3/ 9- <u025A0 - t3/t3-r. Si est
bien realiDado, normalmente se trad$cir en $na llamada simple a $n mEtodo o
f$nci%n de n$estro c%di&o+
E9 0T,3ro 43 3/230-r5o/ 43>3r;- 1o43r 2u>r5r/3 30 u0- /o9- 5t3r-25A0. #l obBetivo
es A$e, cada veD A$e n$estro cliente ven&a a comprobar los reA$isitos, vea la
Jistoria, el reA$isito, completado+ 4o es ele&ante presentarle 9medio reA$isito
c$mplido:+ Si la Jistoria res$lta demasiado compleBa, Jabr de fraccionarse en
Jistorias ms simples, cada $na representando $n 9s$breA$isito: completo A$e
podamos presentar al $s$ario+ #n el caso anterior, podr>amos dividirlos en 9#l
cliente retira dinero del caBero:, 9#l cliente intenta retirar dinero del caBero con $na
tarBeta invlida: y 9#l cliente intenta retirar dinero de $n caBero averiado:
E9 0T,3ro 43 3/230-r5o/ 1-r- 2-4- B5/tor5- 0o 43>3r;- /3r ,u? :r-043.
4ormalmente deber>a caber en $na JoBa, o en $n folio a dos caras+ Le res$lta ms
fcil de se&$ir al cliente+
E0 u0 3/230-r5o 43>3,o/ B->9-r 43 2o,1ort-,530to/M 0o /o>r3 43t-993/ 43
5,193,30t-25A0. 4o es vlido $n escenario A$e di&aH 9Si se introd$ce $n valor
inesperado, el pro&rama lanDa $na eLcepci%n:+ #sos son detalles del
implementador, A$e deber c$brir con s$s 'DD de desarrollo+ <n escenario
correcto ser>a 94o se aceptan ciertas entradas:


P&ina ( de !)*

(5:ur- "I". <n eBemplo de 9$na b$ena Jistoria de $s$ario:
;$enteH dannortJ+net
Con el -DD tenemos, por tanto, la Jerramienta perfecta para inte&rar en SC0<5H
Sirve de intermediario entre los reA$isitos de $s$ario y la implementaci%n con
'DD de desarrollo, eliminando los problemas de 9telEfono roto: A$e presentan,
por eBemplo, los casos de $so clsicos del desarrollo orientado a obBetos+
Sirve de intermediario entre los desarrolladores y el cliente, creando $n
doc$mento intermedio, A$e contiene tanto len&$aBe nat$ral como $na estr$ct$ra
formal, y ay$da a ambos a Jacer $n se&$imiento del c$mplimiento de las
especificaciones del $s$ario, eliminando los problemas de 9telEfono roto: entre
cliente y eA$ipo, y ase&$rando A$e lo A$e se entre&ar al final es eLactamente lo
A$e pidi% y necesita+
Story: Account Holder withdraws cash

As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
And the card should be returned

Scenario 2: Account has insufficient funds
Given the account balance is \$10
And the card is valid
And the machine contains enough money
Then the ATM should not dispense any money
And the ATM should say there are insufficient funds
And the account balance should be \$20
And the card should be returned

Scenario 3: Card has been disabled
Given the card is disabled
Then the ATM should retain the card
And the ATM should say the card has been retained

Scenario 4: The ATM has insufficient funds
...


P&ina (! de !)*
6.2.3. TDD
2Jora A$e en n$estra re$ni%n de SC0<5 nos Jan dado los reA$isitos en -DD, podemos
empeDar a inte&rarlos en el softFare mediante desarrollo 'DD+
#n el 'DD vamos desarrollando el softFare paso a pasoH ele&imos $na f$nci%n A$e
A$eramos aCadir al sistema (si tenemos la ay$da del -DD, Jabremos ele&ido $n
escenario), y comprobamos si est inte&rada en n$estro softFare diseCando $n primer
test+ #n El alimentamos n$estro sistema con $n eBemplo, $n caso partic$lar del A$e
sabemos eLactamente c$al debe ser el res$ltado, y comprobamos si n$estro softFare
dev$elve lo esperado+ Si no lo Jace, aCadimos a n$estro pro&rama las l>neas
eLcl$sivamente necesarias para A$e &enere la salida prevista+ C$ando finalmente
f$nciona, arre&lamos n$estro c%di&o para A$e res$lte lo ms fcil posible el aCadir n$evas
f$nciones en el f$t$ro+
=emos completado $n ciclo+
1 vamos repitiendo ciclos, vamos probando eBemplo tras eBemplo, todos los A$e se nos
oc$rran, Jasta estar se&$ros de A$e n$estra f$nci%n responde adec$adamente en toda la
posible cas$>stica+ C$ando todos los test pasen, Jabremos inte&rado en n$estro softFare
$na n$eva f$nci%n $sando 'DD+
Sencillo, NnoO
#n realidad el 'DD es de $na enorme simpleDa concept$al+ Como vemos se trata de
repetir tres simples pasosH
Cr3-r u0 t3/t. <n test es $n peA$eCo fra&mento de c%di&o A$e, al eBec$tarlo,
alimenta n$estro sistema con $n eBemplo, $n caso, del A$e sabemos eLactamente
el res$ltado, y reco&e la salida prod$cida, coteBndola con lo esperado+ #l test se
crea 24'#S de pro&ramar la f$nci%n A$e lo satisface, por lo A$e inicialmente, el
test no 9pasa:+
E/2r5>5r 2A45:o. Lo si&$iente A$e Jacemos es aCadir a n$estro pro&rama
estrictamente las l>neas necesarias para A$e la eBec$ci%n del test de la salida
esperada, sin reoc$parnos en eLceso de la calidad de las mismas+ Pro&ramamos
para R1-/-r 39 t3/tS+
<na veD el test ya pasa, si&nifica A$e n$estro pro&rama esta preparado para
responder adec$adamente el caso o eBemplo prop$esto en el test+ Lo A$e nos
A$eda RE(ACTORIDAR el c%di&o, arre&larlo para inte&rar las n$evas l>neas
aCadidas+


P&ina (2 de !)*
(5:ur- "I7H #l ciclo 'DD

#n al$si%n al esA$ema de colores comInmente $tiliDado en los diferentes marcos de
trabaBo para indicar si $n test Ja pasado o no, al ciclo 'DD se le s$ele conocer como R34I
Gr330IR3<-2tor.
T3/t u05t-r5o/ ? t3/t 43 50t3:r-25A0
Dentro del 'DD de desarrollo (deBamos f$era los test de aceptaci%n), podemos distin&$ir
dos tipos de test principalesH
E9 t3/t u05t-r5o JU05t T3/tK. Son la base sobre la A$e se f$ndamenta el 'DD+
4ormalmente constr$imos en base a sec$encias de test $nitarios+ <n test $nitario
Ja de serH
o 2t%micoH Compr$eba la m>nima f$ncionalidad posible, normalmente $n
mEtodo de $na clase+ Si dicJo mEtodo tiene diferentes entradas o
conteLtos, cada <nit 'est comprobara $no de ellos, $n caso, $n eBemplo+ Si
el mEtodo A$e probamos llama a s$ veD a otros mEtodos, Jablamos de A$e
el test $nitario tiene menor &ran$laridad+
o IndependienteH <n test no p$ede depender del res$ltado de otros test+ 4o
p$ede Jaber llamadas entre los test, ni el res$ltado final de $no intervenir
como preGreA$isito del si&$iente, ni ser sensible al orden en A$e se
eBec$ten los tests+
CREAR
TEST
REFACTORIZAR
PASAR
TEST
CICLO
TDD
CREAR
TEST
REFACTORIZAR
PASAR
TEST
CICLO
TDD


P&ina (" de !)*
o Inoc$oH 4o debe alterar el estado del sistema+ Se deben de eBec$tar en $n
entorno aislado+ 4o deben modificar ficJeros, ni bases de datosK Da lo
mismo si se eBec$ta $na o mil veces (normalmente lo Iltimo es lo
frec$ente)
o 0pidoH #n $n entorno normal de trabaBo podemos acabar con cientos o
miles de tests, A$e deberemos eBec$tar con frec$encia+ 1 no podemos
estar esperando varios se&$ndos cada veD+
E9 t3/t 43 50t3:r-25A0. C$ando necesitamos ver c%mo interactIan varios
elementos de n$estro sistema, estamos realiDando test de inte&raci%n+ Si&$en
siendo importantes la independencia, inoc$idad y velocidad, pero ya no b$scamos
la comicidad ni la &ran$laridad m>nima+ #Listen varios tipos de test de inte&raci%n,
desde los A$e compr$eban como interactIan $n par de elementos previamente
comprobados mediante test $nitarios, Jasta los A$e lanDan $na entrada al
sistema, recorre todo el mismo, y reco&e la salida en el otro eLtremo+
Mo2L/ ? 4o>93/ 43 1ru3>-
=emos dicJo A$e dos de los principios bsicos A$e Jan de c$mplir del los 9$nit test: son el
aislamiento y la inoc$idad+ Pero, Nc%mo podemos conse&$ir c$ando prcticamente, todo
elemento de $n softFare (mEtodos, clasesK) tienen dependenciasO
La sol$ci%n es sencillaH cada veD A$e n$estro c%di&o f$ncional vaya a Jacer $na llamada a
otro elemento del sistema, s$stit$imos el mEtodo a llamar por $n 9doble:+ Como los de las
pel>c$las de acci%n Las operaciones 9peli&rosas: (interacciones con el sistema real tales
como modificar $na base de datos), las SI5<L2 el doble, sin interact$ar realmente con
n$estro sistema, y dev$elve $na resp$esta, normalmente predefinida+
=ay varios tipos de doblesH
3umm#J #l ms simple, normalmente $n obBeto A$e creamos para rellenar $na
llamada, y A$e no Jace nada+
Fa+eJ 'iene $na implementaci%n A$e dev$elve $n res$ltado, pero $sando $n
ataBo, sin llamar a los mEtodos del c%di&o al A$e s$planta+
*tubJ Proporciona resp$estas predefinidas a llamadas JecJas desde los test, y
p$ede almacenar estados+
8oc+J 5s compleBo A$e $n st$b, al mocZ podemos pro&ramarle 9eLpectativas:, es
decir, acepta parmetros de entrada, por lo A$e no dev$elve res$ltados fiBos,
como el st$b+
<n art>c$lo m$y interesante sobre los diferentes tipos de 9dobles: y s$ $so es 95ocZs
aren:t St$bs:
(!
, de 5artin ;oFler


P&ina (* de !)*
2 la Jora de $sar este tipo de dobles tenemos dos opcionesH crear los n$estros propios o
aJorrarnos trabaBo y $tiliDar diferentes frameForZs A$e permiten crear clases a medida
en tiempo de eBec$ci%n A$e respondan a $n interfaD predefinido+
D3/-rro99-04o TDD. D5/251950- ? r3Qu3r5,530to/
Desarrollar en 'DD es $n proceso bastante repetitivo, A$e por s$s caracter>sticas a veces
p$ede res$ltar tedioso+ Sin embar&o, la calidad final del c%di&o depende de ser met%dico
y mantener la concentraci%n+ 0eA$iere DISCIPLI42H
No 3/2r5>5r 2A45:o /50 B->3r -O-454o 39 t3/t. Debemos evitar el s$c$mbir a la
impaciencia+ #scribir el test antes de escribir c%di&o nos ay$da a centrarnos
eLcl$sivamente en lo necesario+ Introd$cir c%di&o no testado es $n ries&o, ya A$e
podemos cometer el error de no eval$ar correctamente, y podemos terminar a
posteriori, con c%di&o no c$bierto por test+ 1 c%di&o no c$bierto es f$ente se&$ra
de problemas en el f$t$ro+ Por tanto, al&o A$e no debe faltar en el toolboL de $n
desarrollador 'DD es al&$na Jerramienta inte&rada el entorno de desarrollo A$e
te informe contin$amente del 9Code Covera&e:
(2
, es decir, el porcentaBe de c%di&o
c$bierto por los tests+ =a de mantenerse en el !S+
E,1536- 2-4- 2529o 2o0 u0 t3/t Qu3 <-993. #s $na norma A$e c$esta m$cJo se&$ir
c$ando empieDas en el 'DD+ NPor A$E no podemos directamente aCadir c%di&o
f$ncional A$e de 9verde:O
o PorA$e Jas de empeDar separando los errores de compilaci%n A$e se
prod$cen al Jacer llamadas a f$nciones no implementadas+ 2l crear $n
n$evo test, posiblemente introd$cirs errores de compilaci%n por llamadas
a elementos aIn no implementados+ Limpia esos errores+ PCompilaQ
o <na veD ya tenemos 9red:, ya A$e disponemos del p$nto de entrada, el
mEtodo sobre el A$e tendremos A$e trabaBar para Jacer A$e el test pase+
#s m$y importante disponer de $n p$nto de referencia sobre el A$e
constr$ir el res$ltado del test+ Si intentamos empeDar en verde podemos
encontrarnos escribiendo c%di&o distrib$ido por todo el pro&rama, a veces
sin Jaber siA$iera limpiado los errores de compilaci%n, y corremos el ries&o
de perdernos+
No r3<-2tor56-r B-/t- o>t303r @3r43. ,tro error comIn es intentar conse&$ir
9verde: a travEs de la refactoriDaci%n en veD de aCadir c%di&o+ Se termina
meDclando el obBetivo principal (aCadir $na f$nci%n) con el del paso si&$iente, A$e
ser>a inte&rarla+ 2dems, p$ede oc$rrir A$e, como consec$encia de la
refactoriDaci%n, otros test comiencen a dar 9roBo: aCadiendo mayor complicaci%n+
E@5t-r 50tro4u25r 0u3@-/ <u025o0-954-43/ -9 r3<-2tor56-r. 2 veces, por error,
aCadimos c%di&o no testado al refactoriDar+ #s por ello A$e es importante realiDar
esta labor de manera sistemtica, y ceCirse lo ms posible a $na serie de re&las, y
patrones, como los A$e reIne Sean CJambers en s$ p$blicaci%n eGbooZ M"! Days


P&ina (( de !)*
0efactorin&U AC.ambers, *ean/ >IICBOFP/ 4$evamente, $na Jerramienta A$e
controle el 9Code Covera&e: res$lta de lo ms Itil+
No 2o45<52-r @-r5o/ t3/t - 9- @36. Idealmente, el ciclo 'DD Ja de ser at%mico+ #sto
es, $n test cada veD+ Si te s$r&en ideas sobre n$evos test, consec$encia del A$e
ests implementando, $na b$ena prctica es disponer de $n bloc de notas abierto
en el eA$ipo para ir tomando nota+ 2l&$nas 9s$ites: de test permiten codificar el
test como 9Inconcl$sive:, marcndolo en amarillo, y, a veces res$lta prctico como
manera de mantener $na lista de test 9toGdo:, pero es preferible mantener esa
lista f$era del c%di&o+
No 437-r 43 2o,1ro>-r 2-/o/ 1orQu3 9o/ r3/u9t-4o/ 1-r362-0 tr5@5-93/H P$eden
res$ltar triviales, o invariantes, con la lista act$al de tareas, pero ms adelante con
los reA$isitos cambiantes, p$diera ca$sar problemas en no mantenerlos baBo
control+
Por Iltimo, es necesario disponer de u0 3Qu51o 43 43/-rro99o 2o0 50t3:r-0t3/ ,u?
2u-95<52-4o/ para realiDar 'DD+ 2l no partir de doc$mentaci%n eLJa$stiva, al no eListir
diseCo arA$itect%nico de clases previo, este Iltimo va emer&iendo d$rante el desarrollo+
Por tanto, el pro&ramador debe tener cierta eLperiencia, saber Jacia donde ir, A$E
orientaci%n debe dar al c%di&o con cada refactoriDaci%n, c%mo diseCar cada n$evo test+
Sin esas destreDas, la prod$ctividad se red$ce radicalmente, y, en Iltima instancia, la
misma calidad del softFare desarrollado+ Por tanto, si no todos, al menos parte del &r$po
Jan de ser pro&ramadores 9senior:, y adoptar la filosof>a del 9SoftFare CraftmansJip:,
para A$e los eLpertos orienten en las re$niones de sincroniDaci%n a los menos aveDados
Jasta A$e meBoren s$s Jabilidades+
L-/ @30t-7-/ 439 43/-rro99o TDD
Como vemos, el 'DD revol$ciona por completo la forma de trabaBar+ Si&$iendo
inalterablemente esta disciplina conse&$iremosH
CA45:o -9t-,30t3 <5->93H Por dos raDones principalesH
o Cdi"o (a prueba de tontos)J C$antas veces, tras desarrollar $n softFare y
entre&arlo al cliente, nos encontramos A$e, al entrar en prod$cci%n, $n
$s$ario tarde o temprano realiDa al&o inesperado y n$estro flamante
pro&rama finaliDa lanDando $n error, m$cJas veces no controlado+ Si
se&$imos la metodolo&>a 'DD esto es m$cJo ms dif>cil A$e oc$rra, ya A$e
todos los escenarios previstos (&racias a -DD) se Jan implementado
partiendo de test, y, si Jemos sido dili&entes, solo Jabremos aCadido cada
veD el c%di&o estrictamente necesario para Jacer f$ncionar cada ciclo+
o (*i &unciona, no lo toques)J #sta es $na mLima A$e llevo toda mi vida
oyendo+ Los pro&ramadores solemos sentir ape&o por el c%di&o operativo
A$e f$nciona, por $na parte por el trabaBo A$e nos Ja llevado el
implementarlo, y por otra por el miedo a A$e, al intentar arre&lar al&o,


P&ina (6 de !)*
termines fastidiando otra cosa+ #n 'DD esto no tiene sentido, ya A$e $na
de las fases de cada ciclo es, precisamente, 9arre&lar c%di&o A$e f$nciona:+
#n esta metodolo&>a podemos Jacerlo con se&$ridad, p$es d$rante cada
reor&aniDaci%n se v$elven a lanDar ',D,S los test, no solo el Iltimo, con lo
A$e &arantiDas A$e c$alA$ier elemento A$e Jayas modificado si&$e
f$ncionando+
CA45:o 43 -9t- 2-954-4M ,u? r3u/->93M ? <8259 43 r3<-2tor56-r. #l c%di&o de calidad
es tanto $n res$ltado del 'DD como $na necesidad del mismo+ C$ando
contin$amente Jas de rediseCar las clases, partirlas, derivarlas, reor&aniDarlas, a
menos A$e se acerA$en lo mLimo al paradi&ma S,LID, te encontrars con $n
trabaBo in&ente+ 2 veces, simplemente, imposible de afrontar, lle&ando a $n
calleB%n sin salida+ #l 'DD es la Jerramienta perfecta para desarrollar con
reA$isitos cambiantes+
Lo/ 1ro15o/ /o0 u0- ,-:0;<52- 4o2u,30t-25A0 tG2052-. 5irando los test podemos
ver fcilmente c%mo f$nciona y encaBan cada $na de las partes de n$estro
softFare+
2dems, conse&$iremos a $nos trabaBadores motivados, p$es la incertid$mbre y
fr$straciones de $n softFare A$e falla son s$stit$idas por $na sensaci%n diaria de $n
trabaBo bien JecJo+
TDD ? 1ro4u2t5@54-4
5$cJos detractores del 'DD plantean como cr>tica la posible pErdida de prod$ctividad
N4o cons$me m$cJo tiempo Jacer los testsON1 tener A$e reescribir contin$amente el
c%di&oO
Carlos -lE, en el pr%lo&o de s$ libro 43iseo U"il con $335AGle, C/ >I:IBODP, eLpone $na
parbola, $n claro y entretenido eBemplo de por A$E no es as>+ Si comparamos $na
metodolo&>a formal en cascada, $na metodolo&>a informal, y $n desarrollo 'DD ((5:ur-
"I$)H
La metodolo&>a en cascada tarda m$cJ>simo tiempo en arrancar, y no prod$ce
res$ltados Jasta el final+ #l cliente p$ede impacientarse por la falta de
informaci%n+
La metodolo&>a informal prod$ce res$ltados espectac$lares en los prototipos
iniciales, pero s$ele 9atascarse: a medida A$e el proyecto crece, por no tener
planificaci%n ni Jerramientas A$e le ay$den en s$ avance+ #l cliente s$ele terminar
desil$sionndose ante las eLpectativas iniciales perdidas o ante $n softFare final
repleto de fallos+
Las metodolo&>as &iles avanDa lentamente, con paso firme+ #l cliente pronto
dispondr de res$ltados, m$y bsicos, pero, p$nt$almente recibir meBoras, ve
como el softFare crece, va meBorando, siempre si&$iendo los reA$erimientos A$e


P&ina () de !)*
plantea tras cada n$eva entre&a+ 2l final recibir $n softFare rob$sto A$e se
aB$star a lo A$e necesita+
(5:ur- "I$H Comparativa de metodolo&>as de desarrollo de softFare

'estear y refactoriDar, no es, por tanto, $n elemento ne&ativo, sino A$e es la Jerramienta
A$e mantiene al cliente satisfecJo y le &arantiDa $n softFare A$e c$bra s$s necesidades+
#n el caso, por eBemplo, del SC0<5, si s$ planificaci%n es correcta y se dispone del eA$ipo
de desarrolladores adec$ados, el softFare se entre&ar no solo en tiempo, sino,
posiblemente, antes A$e con las otras dos metodolo&>as+
6.2.4. Refactorizacin, code quality y clases SOLID
2tendiendo a la definici%n A$e 5artin ;oFler nos da al principio de s$ libroH
46e&actorizar es el proceso de cambiar un sistema de so&t-are de tal manera que no se altere su
comportamiento .acia el e7terior, pero se me%ore su estructura interna5
;oFler, 5artin (!666)+ 6e&actorin"J Hmproin" t.e 3esi"n o& @7istin" Code+ 2ddisonG[esley Professional (p+?)
Por tanto, c$ando refactoriDamos lo A$e intentamos es meBorar el c%di&o eListente+
#n $n desarrollo clsico nos planteamos esta tarea c$ando la implementaci%n
inicial de $n diseCo entre&ado por el analista Ja sido totalmente desvirt$ado
debido a modificaciones $lteriores realiDadas en el c%di&o+
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
PROGRESO DEL DESARROLLO DE SOFTWARE
Comparativa de metodologas
Fin del desarrollo
Desarrollo informal
Metodologa en cascada
Metodologas giles
Visitas
del cliente
%

C
d
i
g
o

c
o
m
p
l
e
t
a
d
o
Tiempo
100%
PROGRESO DEL DESARROLLO DE SOFTWARE
Comparativa de metodologas
Fin del desarrollo
Desarrollo informal
Metodologa en cascada
Metodologas giles
Visitas
del cliente


P&ina (? de !)*
#n 'DD estamos contin$amente modificando el diseCo, l$e&o, la Inica manera de
9meBorar la estr$ct$ra eLterna sin modificar el comportamiento eLterno: es,
precisamente, la permanente refactoriDaci%n+
La refactoriDaci%n, como todo en 'DD, se realiDa en peA$eCos pasos, simples, $no a $noH
eLtraer c%di&o de $n mEtodo para convertirlo en $n mEtodo independiente, mover
c%di&o arriba o abaBo en $na BerarA$>a, re$nir c%di&o d$plicado en $n mismo l$&ar, K Para
cada $na de las sit$aciones A$e reA$ieran meBora de la estr$ct$ra interna, 5artin ;oFler
define en s$ libro $na serie de pasos sistemticos+ Las tEcnicas estn claramente
definidas, cada $na con s$ nombre, del mismo modo A$e, por eBemplo, los Patrones de
DiseCo
("
, A$e tan claramente especificaron s$s a$tores en el libro del mismo nombre
AGamma, @/, Helm, 6/, Jo.nson, 6/, Vlissides, J/ :CC9BO?P/ Para mantener la fl$ideD de este
procedimiento repetitivo, las modificaciones Jan de ser leves+ #s importante, por tanto,
localiDar rpidamente los p$ntos donde se necesita meBorar el c%di&o, antes de A$e sea
necesaria $na intervenci%n s$bstancial+ ;oFler Jabla de 9bad smells:, c%di&o A$e 9J$ele
mal:, y nos da pistas sobre como localiDarloH c%di&o d$plicado, mEtodos o clases
demasiado eLtensas, listas de parmetros m$y &randes, son pistas de A$e es necesaria
$na intervenci%n importante
#l obBetivo final de la refactoriDaci%n en 'DD es, por tanto, 524'#04#0 el c%di&o dentro
de $nos estndares de calidad, permitiendo A$e la adici%n de n$evas f$ncionalidades se
realice siempre de la manera ms sencilla posible, con el &asto m>nimo de rec$rsos+ #s
esto, precisamente, lo A$e permite al 'DD reaccionar de forma tan eficaD a los n$evos
reA$isitos+ NC%mo definimos esos estandares dentro de c$yos parmetros debemos
movernosO Son lo principios S,LID+

L-/ 29-/3/ SOLID
Para ase&$rar la portabilidad y re$sabilidad del c%di&o en el diseCo orientado a obBetos,
las clases deben de constr$irse si&$iendo ciertos patrones+ 5$cJos est$dios se Jan
elaborado al respecto, entre ellos el A$e realiD% a principios del aCo 2 0obert C+
5artin para el Febsite de ,b%ect 8entor, con el nombre de 3esi"n <rinciples and 3esi"n
<atterns A8artin, 6, >II?BO:IP
D9

#n El, 0obert (conocido con el cariCoso sobrenombre de !ncle Gob), identificaba ciertas
normas A$e ms tarde res$mir>a en s$ ensayo 'Je Principles of ,DD
((
+ #n este art>c$lo de
obli&ada lect$ra, se eLponen, entre otros, los ( principios A$e deben se&$ir las clases en
,,D, y A$e ms tarde, como s$ele ser en el m$ndo an&losaB%n, se re$nir>an baBo el
acr%nimo S,LID+ Con este nombre, las clases S,LID se Jan convertido en 9Los (
5andamientos: dentro del ,,D+
#stos son los preceptos A$e toda clase debe se&$irH


P&ina (6 de !)*
JSK SRP I S50:93 R3/1o0/->595t? Pr5025193
5"
. <na clase debe tener $na Y4IC2
responsabilidad+
JOK OCP P O130 C9o/34 Pr5025193
57
. <na clase deber>a estar abierta a s$ eLtensi%n,
pero cerrada a s$ modificaci%n
JLK LSP P L5/Lo@ Su>/t5tut5o0 Pr5025193
5$
. <na clase derivada deber>a poder
s$stit$ir a $n s$ clase base+
JIK ISP P I0t3r<-23 S3:r3:-t5o0 Pr5025193
59
. 0ealiDar $n interfaD espec>fico para cada
cliente es meBor A$e no solo &enErico+
JDK DIP P D31304302? I0@3r/5o0 Pr5025193
")
. Las clases deber>an depender de
abstracciones, no de implementaciones+
#l principio de responsabilidad 1nica nos indica A$e cada clase deber>a tener $na finalidad
sencilla y concreta+ Si detectamos A$e est eBerciendo varias tareas, s$ele ser s>ntoma de
A$e deber>amos partirla y crear $na clase para cada $na de ellas+ De esta manera, por
eBemplo, si necesitamos eLtender $na f$ncionalidad de $na clase (por eBemplo,
derivndola), no tenemos por A$E 9arrastrar: con nosotros los otros cometidos+ #ste
mismo principio podr>amos aplicarlo a los mEtodos+
#l principio AbiertoMCerrado, (atrib$ido a -ertrand 5eyer A8e#er, G/ :C??BO:>PB, indica
A$e $na clase deber>a estar abierta a s$ eLtensi%n, pero no deber>amos tener A$e
modificar s$ implementaci%n+ Dado A$e d$rante el desarrollo, especialmente en 'DD,
Jabremos de Jacer contin$os cambios, y A$e las entidades dependen $nas de otras, las
modificaciones en el c%di&o de $na de ellas p$eden &enerar indeseables efectos en
cascada+ 2$nA$e con los test tenemos $na cierta salva&$arda, es importante se&$ir este
principio+ Debemos tener previsi%n y aB$starnos a S0P+ 2 veces podremos salvarlo
mediante Jerencia o inyecci%n de dependencias (por ello la clase debe estar 9abierta:),
pero, en otras ocasiones nos veremos obli&ados a romper este principio+
#l principio de *ustitucin de ;is+o (post$lado por -arbara LisZov
6!
en !6?)) Jabla de la
importancia de crear todas las clases derivadas para A$e tambiEn p$edan ser tratadas
como la propia clase base+ C$ando creamos clases derivadas debemos ase&$rarnos de no
reimplementar mEtodos A$e Ja&an A$e los mEtodos de la clase base no f$ncionases si las
instancias derivadas se tratasen como $n obBeto de esa clase base+ #ste principio esta
tambiEn m$y relacionado con el principio ,CP+
#l principio de se"re"acin de los inter&aces podemos verlo como $na ampliaci%n del
primer principio, pero aplicado a los interfaces+ Prop$esto por el mismo 0obert C+ 5artin,
nos dice A$e c$ando se definen interfaces estos deben ser espec>ficos a $na finalidad
concreta+ 2 veces, para simplificar trabaBo, podemos estar tentados de obli&ar a los
clientes a depender de clases o interfaces A$e no necesitan $sar, por eBemplo, c$ando
$na clase o interfaD tiene ms mEtodos de los A$e $n cliente (otra clase o entidad)
necesita para s> mismo+ #n estos casos, es meBor crear n$evos interfaces ms adaptados+
#l principio de la inersin de las dependencias f$e definido tambiEn por 0obert C+ 5artin
para red$cir el acoplamiento entre las clases+ #n todo diseCo siempre debe eListir $n


P&ina 6 de !)*
acoplamiento pero Jay A$e evitarlo en la medida de lo posible+ <n sistema no acoplado
no Jace nada pero $n sistema altamente acoplado es m$y dif>cil de mantener+ Para ello
debemos Jacer $so de abstracciones siempre A$e sea posible, para conse&$ir A$e $na
clase interactIe con otras clases sin A$e las conoDca directamente+ #s decir, las clases de
nivel s$perior no deben los detalles de la clase inferior de la A$e depende+ #n 'DD el $so
de este principio es f$ndamental en m$cJos casos para poder mantener la atomicidad e
independencia de los test $nitarios+ #Listen diferentes patrones como la inyeccin de
dependencias
62
o service locator
6
A$e nos permiten invertir el control+
Los conceptos de clases S,LID estn m$y relacionados con los de -9t- 2oB3/5A0 y >-7o
-2o19-,530to, A$e disc$tiremos c$ando Jablemos de las mEtricas de c%di&o+
Si est$diamos estos principios, veremos A$e el c$mplimiento de los mismos es de m$cJa
mayor importancia en el desarrollo 'DD A$e en metodolo&>as sec$enciales, por dos
raDonesH
#n 'DD estamos refactoriDando contin$amente, y si las clases no son S,LID,
s$pondrn $n problema &rave en cons$mo de rec$rsos y pErdida de
prod$ctividad+ #n otros mEtodos de desarrollo, donde el diseCo de clases es
esttico (el A$e te entre&a el in&eniero analistaWdiseCador), mientras c$mplan con
s$ f$nci%n, como no va a Jaber A$e modificarlas ni re$sarlas para otra cosa, a
veces se desc$ida este aspecto+
#n 'DD necesitamos Jacer test $nitarios, A$e deben ser at%micos y aislados+ Por
lo A$e es imprescindible red$cir al mLimo el acoplamiento de las clases+
Como consec$encia de ello, la labor A$e era responsabilidad de departamentos de R2
(R$ality 2s$rance), Ja pasado cada veD a ser de mayor importancia para c$alA$ier
desarrollador+ #l concepto de las 9mEtricas de c%di&o:, A$e veremos a contin$aci%n, y
disponer de al&$na Jerramienta A$e controle las mismas d$rante el desarrollo, es otro
elemento cr$cial en 'DD+
6.2.5. Mtricas de Cdigo
Como Jemos visto, en 'DD Jemos de intentar mantener las clases dentro de los
parmetros S,LID+ De manera s$bBetiva podemos detectar, mediante los 9bad smells:,
c$ando nos estamos aleBando de estos patrones, peroK NeListe al&$na manera obBetiva,
reprod$cible y c$antificable de medir tales desviacionesO
Para ello disponemos de las llamadas 9mEtricas de c%di&o:+ 5ediante la medida de valores
discretos de diferentes elementos de c%di&o y la aplicaci%n de $na serie de f$nciones, la
ciencia de la comp$taci%n Ja definido $n catlo&o de valores A$e ay$dan a los
desarrolladores a tener $na meBor visi%n de la calidad del c%di&o A$e estn creando+
De todas ellas, las ms relevantes para los principios de ,,D son la coJesi%n y el
acoplamiento


P&ina 6! de !)*
CoB3/5A0
La coJesi%n es $na medida de c%mo las distintos componentes de $n elemento de
softFare estn relacionados entre s>+
#sta mEtrica est vinc$lada con el primer principio de ,,D, el de la Inica responsabilidad+
#n $na clase con $na sola misi%n, todos s$s elementos (mEtodos y atrib$tos) colaboran
entre s> para lle&ar a este Inico obBetivo+ #Liste $na alta coJesi%n+ Si la clase t$viera varias
f$nciones, nos encontrar>amos A$e dicJos elementos se a&r$par>an en torno a los
diferentes cometidos, sin A$e eListiera relaci%n entre $no y otro &r$po+
Para entenderlo meBor, veamos $na mEtrica de la coJesi%n, conocida como L-2L o<
CoB3/5o0 o< M3tBo4/ JLCOMK+ /eamos $nos eBemplosH
(5:ur- "I9. CoJesi%n en los mEtodos de $na clase

#n la ;i&$ra 6G6 vemos tres posibles confi&$raciones de $na clase+ DicJa clase tiene cinco
mEtodos, 2,-,C,D,y #, y dos atrib$tos, propiedades privadas del mismo, L e y+
!remisaH Decimos A$e dos mEtodos 2 y - estn relacionados si se c$mple al&$na de estas
condiciones
Dentro de 2 eListe $na llamada a - o dentro de - eListe $na llamada a 2+
'anto 2 como - $tiliDan $n mismo atrib$to de la clase
#n la primera confi&$raci%n de la clase, todos los mEtodos estn relacionados entre s>H 2
depende de -, y b $tiliDa el atrib$to L, A$e tambiEn $sa C+ C y D comparten el $so del
A
B
D C
E
x y
A
B
D C
E
x y
A
B
D C E
x y
LCOM =1 LCOM =2
LCOM =3
A
B
D C
E
x y
A
B
D C
E
x y
A
B
D C
E
x y
A
B
D C E
x y
LCOM =1 LCOM =2
LCOM =3


P&ina 62 de !)*
atrib$yo 1, y D depende de #+ DicJa clase tiene la mLima coJesi%n, p$es todos s$s
elementos forman $n solo &r$po+
#n la se&$nda confi&$raci%n los elementos se separan formando dos &r$pos distintos, sin
relaci%n entre ellos+ Posiblemente lo A$e Jemos detectado es A$e dicJa clase est
realiDando dos f$nciones distintas e independientes+ Se&In el principio S0P deber>amos
partirla en dos+
#n la tercera, detectamos incl$so $n mEtodo A$e 9va a s$ aire:+ #n este caso,
posiblemente podr>amos sacar tres clases de Esta+
La mEtrica LC,5 nos ay$da por tanto a identificar posibles violaciones del *in"le
6esponsabilit# <rinciple/
LC,5 b ! c 5Lima coJesi%n
LC,5 d ! c C$anto mayor sea LC,5, menor coJesi%n eListe
LC,5 b c 4o eListen mEtodos en la clase+ 2 menos A$e se trate de $na
estr$ct$ra de datos, podemos considerarla $na 9mala clase:
A2o19-,530to
#l acoplamiento Jace referencia a los enlaces eListente entre $nidades separadas de $n
pro&rama+ Si eListe &ran dependencia a nivel de detalles de implementaci%n entre dos
clases, se dice A$e estn f$ertemente acopladas+ Si todos los obBetos inte&rantes de $na
clase Jacen referencia directa a los obBetos inte&rantes de la clase de la A$e se tiene
dependencia, eListe $n alto acoplamiento
Idealmente las clases no deber>an tener informaci%n sobre la implementaci%n A$e
realiDan las clases de las A$e dependen+ Si no accedemos a las dependencias a travEs de
$n interfaD, al menos deber>amos intentar al menos tener contacto con ellas a travEs de
s$s mEtodos pIblicos, nada ms+ Si no, se corre el ries&o de s$frir $n 9efecto onda:, ya
A$e, en el caso de realiDar $na modificaci%n en $na clase, todas las A$e dependan de ella,
si estn demasiado acopladas, corren el ries&o de necesitar tambiEn ser modificadas+
Ima&inemos, por eBemplo, el caso de $na fact$ra y s$ detalle+ 'enemos la clase fact$ra,
entre c$yos atrib$tos est $na colecci%n de instancias de la clase 9Linea de Detalle:+
Podemos crear $n mEtodo en la clase fact$ra A$e vaya leyendo $na a $na las lineas de
detalle, tomando de cada $na de ellas el nImero de $nidades y el precio por $nidad, y
calc$lar as> el total de la fact$ra+ Sin embar&o, esta implementaci%n presenta alto
acoplamiento+ Si cambiramos el obBeto 9l>nea de detalle:, para incl$ir n$evos elementos
tales como desc$ento o imp$estos para cada operaci%n, esto nos eLi&ir>a a cambiar el
mEtodo de clc$lo en el obBeto 9;act$ra:+ NPor A$EO PorA$e estamos obli&ando a la
fact$ra a $sar detalles de implementaci%n de 9Linea de Detalle:+ NSol$ci%nO R$e sea la
l>nea de detalle la A$e calc$le s$ propio total, y presente al eLterior $n interfaD ($n simple
mEtodo pIblico) llamado 9'otal de L>nea:, A$e es, en realidad, lo Inico A$e la ;act$ra
necesita conocer del detalle para calc$lar el total de la misma+


P&ina 6" de !)*
(5:ur- "I1). #liminando el acoplamiento entre clases
#n la ;i&$ra 6G! esA$ematiDamos lo anteriormente eLp$esto, donde eliminamos la
referencia directa de $n mEtodo a atrib$tos de otra clase+ 4o A$iere esto decir A$e $n se
deba n$nca acceder a los atrib$tos desde las clases de las A$e se depende, sino A$e as
clases deber>an presentar solamente atrib$tos A$e enmascaren detalles de
implementaci%n+
<n eBemplo
6*
en CT m$y simple, a la veD A$e il$strativo, de acoplamiento y como
solventarlo, lo podemos encontrar en la Feb de StacZ#LcJan&e por cortes>a de [ed&e
Las mEtricas principales A$e nos ay$dan a discernir el nivel de acoplamiento sonH
A<<3r30t Cou1950: JC-K. #l acoplamiento aferente mide el nImero de elementos
de c%di&o A$e dependen directamente de Este+ #s decirH Nc$ntas veces me $sanO
E<<3r30t Cou1950: JC3K. #l acoplamiento eferente mide el nImero de elementos de
c%di&o del A$e dependo directamente+ #s decirH Na c$ntos $so yoO
(5:ur- "I11. 2coplamientos aferente y eferente
#stas dos mEtricas se p$eden definir a varios nivelesH
A B
x y z
C D
W
Clase A
Clase B
A B
x y z
C D
W
Clase A
Clase B
Public
Acoplamiento
Eliminando
acoplamiento
A B
x y z
C D
W
Clase A
Clase B
A B
x y z
C D
W
Clase A
Clase B
Public
Acoplamiento
Eliminando
acoplamiento

Code
Element
Efferent
Coupling
Afferent
Coupling
Code
Element
Efferent
Coupling
Afferent
Coupling


P&ina 6* de !)*
A niel de ensambladoH NC$ntos tipos (clases, estr$ct$ras, en$meraciones) de
otros ensamblados dependen de miO NDe c$ntos tipos de otros ensamblados
Ja&o $soO
A niel de espacios de nombresH #Lactamente i&$al A$e el anterior
A niel de clasesH NC$ntas clases dependen de m>O NDe c$ntas clases dependoO
A niel de mtodosH NC$ntos mEtodos dependen de m>, independientemente de
la clase o ensamblado de procedenciaO NDe c$antos mEtodos dependoO
Las mEtricas sobre acoplamiento nos permiten ver n$estro &rado de c$mplimiento del
A$into principio de ,,D, el 3ependenc# Hnersion <rinciple/
Otr-/ ,Gtr52-/ 43 2A45:o 5,1ort-0t3/
#Listen &ran cantidad de mEtricas A$e nos permiten vi&ilar el &rado de coJesi%n y el
acoplamiento, aparte de otros indicadores sobre la calidad de c%di&oH
NT,3ro 43 9;03-/ 43 2A45:o. 2parte de ay$darnos a medir la prod$ctividad de
n$estro eA$ipo al ver como evol$ciona temporalmente, el nImero de l>neas de
c%di&o en cada mEtodo es $n indicativo de s$ >ndice de responsabilidad y
le&ibilidad+ Los mEtodos m$y eLtensos son dif>ciles de mantener+
Por230t-73 43 9;03-/ 43 2o,30t-r5o. Como l$e&o veremos al Jablar del Clean
code, dentro del a&ilismo se considera A$e comentar c%di&o es $na mala practica,
por varias raDones
o Si necesitas comentar c%di&o es s>ntoma de A$e Este es 9poco claro:, ya sea
por s$ eLtensi%n o compleBidad+ #l 9Clean code: de 'DD no necesita ser
comentado, ya A$e s$s mEtodos no se s$elen eLtender ms all de ( % 6
l>neas+
o #l c%di&o necesita ser contin$amente refactioriDado, y aA$ello A$e se
coment% p$ede termina no estando aJ>, o ser solo $na implementaci%n
parcial, con lo A$e los comentarios p$eden terminar llevando a conf$si%n+
Por230t-73 43 2A45:o 2u>53rto. 2bsol$tamente imprescindible en 'DD es
ase&$rarnos A$e todo el c%di&o A$e escribimos est c$bierto por test+ Si se&$imos
las directrices A$e eLp$simos al Jablar de la disciplina en 'DD, no deber>amos de
tener problemas con ello+
Co,193754-4 C529o,8t52- JC?29o,-t52 Co,193N5t?K. #sta mEtrica es $na clara
medida de la le&ibilidad el c%di&o, as> como la dific$ltad A$e implicar>a s$
refactoriDaci%n+ Indica el n$mero de caminos A$e toma el c%di&o a lo lar&o de $n
mEtodo, y viene definida por la cantidad de decisiones (bloA$es if, sentencias
sFitcJK) A$e lo inte&ran+ #st li&ada en cierto modo al se&$ndo principio de la
,,D, el (,penMClose <rinciple), A$e nos insta a, en veD de Jacer $so de las


P&ina 6( de !)*
sentencias condicionales c$ando entre $n n$evo caso, optar por Jacer clases
derivadas o $sar patrones decoradores+
6.2.6. Clean Code
NR$E es el Clean CodeO NC%mo medirloO

=asta aJora nos Jemos preoc$pado de la calidad del c%di&o desde el p$nto de vista de la
eficiencia y re$sabilidad+ Los b$enos pro&ramadores son especialistas en crear este tipo
de c%di&o+ 1, adems, s$elen sol$cionar los problemas de manera in&eniosa+ Pero ello no
implica 9Clean Code:+ 2 veces el res$ltado es eLactamente el op$esto+ <n pro&ramador
p$ede sentirse tentado de s$stit$ir $na eLpresi%n relativamente eLtensa, por otra A$e
Jace todo en $na sola l>nea, en $n alarde de intelecto, re&odendose en s$
a$tocomplacencia, acompaCndolo todo con $n comentarioH 9WWeste fra&mento de
c%di&o sirve paraK:
#n la act$alidad Ja lle&ado $na corriente A$e abo&a por aCadir a la ec$aci%n del 9A$ality
code: los conceptos de 93:5>5954-4 ? 3N1r3/5@54-4+
<n c%di&o limpio eLpresa claramente s$ intenci%n, de forma simple y ele&ante+ =a de
facilitar s$ entendimiento tanto para el propio pro&ramador como para los f$t$ros
mantenedores del c%di&o+ =a de acercarse lo mLimo posible al len&$aBe nat$ral+


P&ina 66 de !)*
Podemos considerar al libro Clean Code A8artin, 6/ >II?BO::P como lect$ra de absol$ta
referencia dentro de este paradi&ma+ #n El 9$ncle -ob: nos presenta al&$nos patrones
para lle&ar a obtener 9c%di&o limpio:+ #Lpon&amos, por eBemplo, $n par de ideas sobre la
constr$cci%n de mEtodos y el $so de variablesH
U/-r R,3-050:<u99 0-,3/SM 0o,>r3/ 2o0 /5:05<52-4o. #n los entornos de desarrollo
act$ales no s$ele Jaber limitaciones con la lon&it$d de los nombres de variables,
clases o mEtodos+ #n veD de simples y cr>pticas iniciales, las propiedades deber>an
nombrar la entidad a la A$e representan, los mEtodos la f$nci%n A$e realiDan+
'omemos el eBemplo las variablesH

N4o res$lta m$cJo meBor la se&$nda opci%nO Podremos se&$ir la variable con
m$cJa mayor facilidad en el c%di&o+
Los mEtodos tambiEn deber>an tener nombres descriptivos+ Por, por eBemplo, en
este 9snippet: de BavaH

U&-69o 2ortoV. Los mEtodos eLtensos son dif>ciles de se&$ir y mantener+ Se
deber>an eLtraer bloA$es de c%di&o (patro%n de refactoriDacion 9#Ltract mEtJod:)
a s$bmEtodos con 9meanin&f$ll names:+ Los mEtodos, de tamaCo medio, deber>an
ser " o * l>neas, incl$so menos+
C-4- ,Gto4oM u0- t-r3-. Del mismo modo A$e oc$rre con el Sin&le 0esponsability
Principle para las clases, cada mEtodo deber>a Jacer <42 sola cosa+ 4$evamente,
se deba Jacer $so del 9#Ltract metJod:+
Lo/ ,Gto4o/ 43>30 t303r 1o2o/ Jo 050:T0K 1-r,3tro
U/-r 3N23125o03/ -0t3/ 43 r3tor0o 43 2A45:o/ 43 3rror.
1, si&$iendo esta idea, nos ofrece decenas de principios a se&$ir a la Jora de trabaBar con
atrib$tos y mEtodos, dar formato al c%di&o, normas sobre c$ando comentar (en realidad,
casi n$nca), obBetos y estr$ct$ras de datos, clases, maneBo de errores+++ 2simismo, como
JiDo en s$ libro de refactoriDaci%n, nos da pistas sobre c%mo localiDar los 9bad smells:+
4o eListen mEtricas A$e directamente nos ay$den a detectar el Clean Code+ 2l&$nas,
como el n1mero de l'neas de cdi"o A;,CB o la comple%idad ciclomtica nos p$eden
int d; //da del mes
int diaDelMes;
public static String RenderPageWithSetupsAndTeardowns(
PageData pageData, boolean isSuite) throws Exception {
if (isTestPage(pageData))
includeSetupAndTeardownPages(pageData, isSuite);
return pageData.getHtml();
}


P&ina 6) de !)*
alertar sobre 9bad smells: en c%di&o+ Pero solo con ecJarle $n vistaDo, se nota la falta de
9[';QQQ:
F&-? Qu3 2o,30t-r 39 2A45:oH
Como re&la &eneral, en 'DD no se comenta el c%di&o, por dos raDones principalesH
4o se debe comentar el c%di&o porA$e en las contin$as refactoriDaciones los
comentarios a $na f$nci%n o fra&mento de c%di&o p$eden deBar de tener sentido,
y llevar a conf$si%n+ 0es$lta normalmente $n en&orro el tener A$e 9refactoriDar los
comentarios:
4o es necesario comentar el c%di&o si se&$imos las normas del Clean Code
Sin embar&o, Esta es $na mLima no absol$ta+ #n ocasiones, c$ando lo A$e se
implementa es $na biblioteca prcticamente esttica, con $nos obBetos claramente
definidos A$e debern ser $sados por otros, los comentarios son bienvenidos, no para
aclarar el c%di&o, sino para doc$mentar las clases y s$s atrib$tos+
#ste caso A$eda claramente refleBado en las clases A$e implementan el estndar
IS,222 para el env>o de recibos domiciliados, donde, dada s$ compleBidad, res$lta
prcticamente imprescindible aCadir estos comentarios A$e nos &$>en en la constr$cci%n
del esA$ema+
Pro4u2t5@54-4 ? RC93-0 Co43S
N#s necesario dividir y dividir, $tiliDar nombre lar&os ms lentos de escribir, convertir
eLpresiones osc$ras pero concisas en $na serie de mEtodos y llamadasKO N4o ser>a
s$ficiente con comentar adec$adamenteO P$esK no+
(5:ur- "I12H #l problema de la prod$ctividad en el 9bad code:

P
r
o
d
u
c
t
i
v
i
d
a
d
Tiempo
100%
Productividad
El problema del bad code
P
r
o
d
u
c
t
i
v
i
d
a
d
Tiempo
100%
Productividad
El problema del bad code


P&ina 6? de !)*
Comentar no es la sol$ci%n+ #s ms, es totalmente desaconseBable, especialmente en
'DD, donde, como diBimos, al tener A$e modificar c%di&o ya escrito en cada ciclo, los
comentarios p$eden deBar de tener sentido+ Los entornos de desarrollo act$ales nos
apoyan enormemente con el 9c%di&o limpio:+ Incl$yen ay$das a la refactoriDaci%n y
a$tocompletar+
La verdad es A$e la prod$ctividad en 'DD a$menta enormemente $sando Clean Code+ 2
medida A$e crece, $n c%di&o dif>cilmente le&ible se convierte en $n enorme caos dif>cil de
mantener y ampliar, y, teniendo en c$anta A$e debemos refactoriDarlo contin$amente, la
prod$ctividad decae como podemos ver en la ;i&$ra 6G!2+
E<5253025- .V/. C93-0 Co43
4<ro"rams must be -ritten &or people to read, and onl# incidentall# &or mac.ines to e7ecute/5
OAbelson, H/, *ussman G/ :C?9PO:P
FD

#sta frase, escrita en el aCo !6?* por dos profesores del 5I', res$me en ella misma la
resp$esta a esta c$esti%n+
=a pasado m$cJo tiempo desde la Epoca en la A$e pro&rambamos en ensamblador,
donde lo primordial era la eficiencia y la econom>a+ #n la act$alidad podemos permitirnos
escribir c%di&o claro, y confiar en la calidad de los compiladores para A$e la posible
peA$eCa dismin$ci%n de rendimiento sea llevada al m>nimo+ 4o A$iere decir esto A$e
debamos olvidar factores importantes de implementaci%n+ <na bIsA$eda en rbol es
m$cJo ms rpida A$e $na sec$encial+ 4o debemos ele&ir la bIsA$eda sec$encial porA$e
sea ms clara+ Debemos centrarnos en c$l es la manera ms 9limpia: de implementar $n
al&oritmo, no A$e al&oritmo es ms claro+
La red est pla&ada sobre eficiencia de c%di&o, por eBemploH KVu es me%or, usar ;H2V o
un bucle &oreac.L P$esK depende+ <na sentencia LI4R tiene $n li&ero menor
rendimiento A$e $n b$cle iterativo+ Por el contrario, para eLpresiones simples, es m$cJo
mas clara, le&ible y portable A$e todo $n bloA$e de c%di&o+ Por el contrario, a medida
A$e las eLpresiones lambda se anidan y complican en $na sentencia LI4R, empieDa a ser
preferible la ms eLtensa, pero ms clara, sol$ci%n de b$cle iterativo+ Para casos como
este, donde la diferencia de rendimiento es poco apreciable, no Jay d$daH tomar siempre
la opcion 9limpia:+ 1 as> ser en la &ran mayor>a de los casos+ #s por ello A$e casi todos los
eLpertos coinciden en la importancia del Clean Code sobre la eficiencia del c%di&o+
#n otras sit$aciones, en sistemas clave, donde la eficiencia es cr>tica, debemos est$diar
bien las posibilidades de $sar 9$nclean: code+ NDeberemos sacrificar el la prod$ctividad de
n$estro eA$ipo de desarrollo obli&ndoles a crear c%di&o 9s$cio: pero eficiente, en pro de
la eficiencia del c%di&o $na veD en prod$cci%nO =a&an nImerosK


P&ina 66 de !)*
6.2.7. Software Craftmanship
#l primer concepto de modelo en cascada
66
f$e $na adaptaci%n de los mEtodos $tiliDados
en otras in&enier>as como la constr$cci%n o la man$fact$raci%n+ #s por ello A$e, en esta
metodolo&>a es posible establecer $na m$y fcil analo&>a entre los obreros de $na cadena
de montaBe y los pro&ramadores+ Cada $no es, simplemente, $n elemento de $na
maA$inaria A$e realiDa $n trabaBo m$y espec>fico y p$nt$al, atendiendo a $nas normas
r>&idas (el doc$mento de diseCo), sin tener necesidad de tener conocimiento al&$no de
c$al es la f$nci%n de s$ trabaBo+ Como partes de $na mA$ina, s$ perfil est
perfectamente definido y especificado, por lo A$e en m$cJos casos se les considera
prescindibles o intercambiables por otra pieDa similar+
;rente a esta ima&en, el a&ilismo reivindic% el papel del pro&ramador, no como $na pieDa
de $na maA$inaria bien en&rasada, sino cono $n artesano, enfatiDando las Jabilidades
como pro&ramadores A$e cada desarrollador debe tener, y en como debe preoc$parse
por $n softFare bien JecJo, del A$e forman parte >nte&ra+ #stamos Jablando de la
9artesan>a de softFare:, o 9SoftFare CraftmansJip:+
#n esta analo&>a con las cofrad>as de ori&en medieval, se presta &ran atenci%n al
pro&ramador no como $n ente aislado, sino como inte&rante de $na com$nidad, donde
los pro&ramadores 9senior:, maestros de la cofrad>a, se preoc$pan por ay$dar a los
9B$nior:, los aprendices+ ;orma parte de s$ r$tina diaria aprender y enseCar, meBorar, e
imprimir a s$ oficio ese sello de calidad A$e conlleva el or&$llo del trabaBo bien JecJo+
#n cada eA$ipo de trabaBo 9a&il: se si&$en los preceptos del softFare craftmansJip, por lo
A$e se trata de &r$pos de personas motivadas y de &ran capacidad, realmente eLpertos+
Cada $no de los inte&rantes conoce bien el trabaBo de los dems, y participa del mismo en
las re$niones diarias de sincroniDai%n+ #n $n eA$ipo 9a&il: los desarrolladores menos
eLpertos reciben en cada sincroniDaci%n el apoyo de los ms eLpertos+ #n el SC0<5, por
eBemplo, tienen la ay$da de $n 9facilitador:+ 2 veces se $tiliDa la pro&ramaci%n por pareBas,
el 9pair pro&rammin&:
6)
+
#s por ello A$e la calidad del softFare en los proyectos &iles es meBor A$e la res$ltante
en la metodolo&>a en cascada, precisamente por la primera premisa del manifiesto &ilH
4Valorar ms a los indiiduos # su interaccin que a los procesos # .erramientas5


P&ina ) de !)*


P&ina )! de !)*
7. ANLISIS
7.1. RCNGC Members Management
Para el presente est$dio se Ja realiDado $n anlisis parcial de los reA$erimientos,
centrndose en elementos de la fact$raci%n de recibos de $na sociedad deportiva+ Se Jan
implementado $nas bibliotecas de clases sin interfaD de $s$ario, s$ficientes para eval$ar
el 'DD+ Se Ja prestado especial atenci%n a los elementos necesarios para la
implementaci%n del sistema de ade$dos domiciliados S#P2+
7.1.1. Requisitos
De manera m$y res$mida, los reA$isitos reco&idos en la librer>aH
Creacin Gestin de 8iembrosJ 2 nivel m$y simple, tan solo el miembro
propietario, y centrndonos en lo estrictamente necesario para &esti%n de las
fact$ras
*ericios # <roductosJ Los miembros del cl$b p$eden $tiliDar servicios y prod$ctos,
y como res$ltado se &eneran ventas o car&os por servicios+
Gestin de FacturasJ Las ventas y car&os por servicios se anotan en fact$ras A$e se
re&istran al socio+
o Cada fact$ra p$ede reco&er varios car&os o servicios+
o #Liste la posibilidad de crear fact$ras proGforma+
o Las fact$ras p$eden ser an$ladas crendose $na fact$ra de an$laci%n+
Gestin de 6ecibosJ Las fact$ras se cobran mediante recibos+
o <na fact$ra p$ede ser pa&ada en varios recibos
o Los recibos p$eden ser cobrados por caBa o mediante ade$do en c$enta+
#n c$alA$ier momento p$ede cambiar c$al es s$ modo preferido de pa&o+
Si se vence s$ fecJa de cobro pasan a estar impa&ados+ Los recibos p$eden
ser an$lados, o ser considerados como 9fallidos: si es imposible s$ cobro
(por eBemplo, en el caso de baBa del socio)
o Los recibos p$eden ser rene&ociados en plaDos, crendose $n ac$erdo de
pa&o+ Se Jace $n se&$imiento de los ac$erdos de pa&o de cada recibo+
Gestin de domiciliaciones bancariasJ #l socio p$ede a$toriDar el env>o de los
recibos sobre s$ c$enta a travEs de domiciliaciones bancarias


P&ina )2 de !)*
o #l socio p$ede disponer de varias domiciliaciones bancarias, y ele&ir c$l
desea $sar para los diferentes pa&os
o #l socio p$ede cambiar el nImero de c$enta bancaria asociada a $na
domiciliaci%n, manteniEndose $n Jistorial de c$entas
Gestin de 6emesas de 6ecibosJ Los recibos domiciliados se env>an al banco
mediante remesas A$e si&$en el formato S#P2 para el env>o de 2de$dos Directos
o #l cl$b p$ede establecer diferentes contratos de env>o con distintas
entidades bancarias, incl$so varios con $na misma entidad+
o C$ando desee iniciar $na remesa de ade$dos, eli&e el contrato a $tiliDar, y
va aCadiendo los recibos A$e desee cobrar+ C$ando estE completa, lanDa el
proceso de &eneraci%n del mensaBe (ficJero) Customer3irect3ebitHnitiation
conforme al estndar IS,222 @5L pain+?+!+2

#n $n anlisis normal orientado a obBetos, el si&$iente paso ser>a confeccionar los Casos
de <so+ Sin embar&o, a$nA$e son perfectamente compatibles, como estamos trabaBando
en 'DD, y Jemos confeccionado las =istorias de <s$ario de -DD, A$e detallaremos
mediante esta Jerramienta+
7.1.2. Historias de usuario
La #specificaci%n de reA$isitos la modelamos mediante =istorias de <s$ario -DD+ 2l ser
de cierta eLtensi%n, reco&emos los mismos en el 24#@, !
7.1.3. Restricciones impuestas por el proyecto
#n el desarrollo de las librer>as se Jan establecido al&$nas restricciones A$e pasamos a
referirH
7.1.3.1. Por las caractersticas del estudio
La necesidad de llevar $n Jist%rico de la evol$ci%n de las mEtricas, en ciertas ocasiones Ja
limitado las posibilidades de la refactoriDaci%n, p$esto A$e al cambiar los nombres de los
tipos se pierde el enlace con s$ Jist%rico de medidas+ =emos intentado limitar al m>mino
este tipo de sit$aciones, sin romper n$estro compromiso con la calidad del c%di&o+ #n
casos como los espacios de nombres Ja sido especialmente compleBo, ya A$e c$alA$ier
cambio en s$ nombre implica la r$pt$ra con el Jistorial de todos s$s tipos, y mover $n
tipo a $na n$evo namespace prod$ce el mismo res$ltado en el mismo+


P&ina )" de !)*
7.1.3.2. Desarrollo sin persistencia de datos
<na de las cosas mas dif>ciles Ja sido trabaBar evitando el concepto de la 9persistencia de
datos:+ Se me imp$so como reA$isito de softFare el no pensar en bases de datos, para no
contaminar los reA$isitos de $s$ario con reA$erimientos de softFare, ya A$e llevo
m$cJos aCos trabaBando con sistemas de informaci%n+
N'rabaBar sin acceso a persistencia de datosO NSin almacenar al&o en discoO #n $n
principio parece al&o dif>cil de asimilar+ Por eBemplo, c$ando pensamos en $na fact$ra,
a$tomticamente nos viene a la cabeDa el c$erpo de la fact$ra, A$e contiene $n mont%n
de l>neas de conceptos+ La primera idea A$e le viene a $no a la Jora de Jacer el diseCo de
clases (al menos, a mi), esH cada fact$ra tiene $n ID (cierto), y l$e&o, para cada l>nea de la
fact$ra tendr s$ propio ID, el ID de la fact$ra de la A$e dependeK P;2LS,Q P#sos dos
atrib$tos son reA$erimientos de la persistencia de datos, nada msQ Si no Jay
persistencia, si solo Jay obBetos A$e tiene s$ vida en memoria, cada instancia de obBeto
9;act$ra: contiene $na colecci%n de instancias de obBetos tipo 9Concepto:+ 4o Jay
necesidad de atrib$tos eLternos A$e la relacionen+
R$iD podamos entenderlo meBor con $n s>mil+ Pensemos en $na entidad, A$e
llamaremos 9=abitaci%n:, A$e contiene $na serie, $na colecci%n de obBetos A$e
abstraeremos como 95$ebles: (p$eden ser sillas, mesas, lmparasK)+ La Jabitaci%n
contiene esos elementos, pero nosotros no tenemos nin&$na necesidad de marcar cada
m$eble como 9est dentro de esta Jabitaci%n:+ DicJa relaci%n A$eda refleBada en el
dia&rama de la ;i&$ra )G!
(5:ur- 7I1. 0elaci%n simple de a&re&aci%n entre $na Jabitaci%n y s$s m$ebles
Pero, $n d>a, nos toca Jacer reformas en la Jabitaci%n, por lo A$e tenemos A$e vaciarla y
contratar los servicios de $n &$ardam$eble+ `ste ser n$estro 9proveedor de
persistencia:+ Pero, $na veD se los entre&$emos, ya no eListe vinc$laci%n entre cada
Jabitaci%n y s$s m$ebles+ NC%mo los podremos rec$perar l$e&o, entre todos los m$ebles
A$e n$estro proveedor almacena en s$ empresaO Sencillo+ 520C25,S n$estros
m$ebles+ 'enemos dos opcionesH
5arcamos cada m$eble con $na identificaci%n, Jacemos $na relaci%n, y la
&$ardamos en casa
,, simplemente, marcamos cada m$eble con n$estro nombre
Con $na de estas dos opciones, representadas en la ;i&$ra )G2, podremos rec$perarlos
l$e&o+

Habitacin Mueble
1
*
Habitacin Mueble
1
*


P&ina )* de !)*

(5:ur- 7I2. Dos opciones para aCadir persistencia, y los atrib$tos A$e serian necesarios aCadir

#ste eBemplo es fcilmente trasladable al caso de las fact$ras y s$s conceptos+
#ntonces, podemos trabaBar sin persistencia, pero Nno A$edar el diseCo incompletoO
P4oQ #n realidad el diseCo ser de m$cJa mayor calidad, p$es la persistencia no forma
parte de los reA$erimientos del $s$ario+ #n 'DD la persistencia de datos es $n problema
A$e p$ede (y s$ele) abordarse 9a posteriori:, para no meDclar lo A$e nos pide el cliente
con lo A$e demanda la arA$itect$ra final de datos+
NC%mo lo JacemosO 5ediante $na sabia meDcla de clases derivadas y ase&$rarnos de
se&$ir a pie B$ntillas el A$into principio S,LID en todas las clases A$e reA$ieran
persistencia+
Para cada clase A$e reA$iera ser almacenada creamos $na clase derivada A$e
incl$ya los atrib$tos de persistencia (los ID y dems campos necesarios para
almacenar)
Incl$imos tambiEn los mEtodos A$e servirn para almacenar y rec$perar los datos,
pero 4, L,S I5PL#5#4'25,S+
Creamos $na clase A$e es la A$e realmente accede a los datos, $na clase
9repositorio:, A$e ofreDca como interfaD p$blica $nos mEtodos &enEricos para leer
y escribir datos y A$e dentro de s$s mEtodos privados incl$ya toda la l%&ica
necesaria para intercambiar los mismos con el sistema de almacenamiento
ele&ido+
Preparamos los constr$ctores de las anteriormente comentadas clases derivadas
con persistencia para I41#C'20 instancias de los obBetos repositorios+ #s lo A$e se
Habitacin Mueble
idMueble[] id
1
*
Habitacin Mueble
id idHabitacin
1
*
Opcin 1:
Opcin 2:
Habitacin Mueble
idMueble[] id
Habitacin Mueble
idMueble[] id
1
*
Habitacin Mueble
id idHabitacin
Habitacin Mueble
id idHabitacin
1
*
Opcin 1:
Opcin 2:


P&ina )( de !)*
llama 9Inyecci%n de Colaboradores:+ #sa inyecci%n, como antes comentamos, Ja de
se&$ir el (e principio S,LIDH Ja de depender de $na abstracci%n+ #s decir, el
constr$ctor Ja de declarar $na I4'#0;2X, para A$e el colaborador p$eda ser de
c$alA$ier clase A$e lo implemente+
2Jora s>, implementamos los mEtodos de acceso a datos de las clases derivadas
para A$e llamen a los mEtodos de acceso a datos del colaborador inyectado, A$e
como si&$e $na interfaD, sern estndares+
Con todo ello Jemos separado por completo el diseCo del dominio del problema del
dominio la arA$itect$ra de base de datos, por lo A$eH
Podemos trabaBar en $no y en otro por separado, sin interferencias
Podemos $sar varios dominios de arA$itect$ra de base de datos con el mismo
dominio del problema+ 'an solo, a la Jora de inyectar el colaborador, ele&imos
el A$e necesitemos
1 como consec$encia de lo anterior, el 'DD nos est infinitamente a&radecido,
p$es mientras A$e en el c%di&o A$e se esta implementando para prod$cci%n
las clases instancias se inicialiDan con colaboradores reales, instancias reales
del repositorio, en n$estros test las inicialiDamos con S'<-S+
#n la ;i&$ra )G" tenemos $n esA$ema de todo lo anteriormente eLp$esto+
(5:ur- 7I3H Implementando persistencia de datos mediante patr%n repositorio, con inyecci%n de
colaboradores y $so de S'<-S para sim$lar acceso a datos
#n el blo& de 0emondo+4et p$edes encontrar $na m$y sencilla y clara implementaci%n
6?

del patr%n repositorio en CT+
Clase base
(sin persistencia)
Colaborador
Inyectado
Persistencia
de datos
Instancia de clase derivada con
acceso a persistencia de datos
Clase base
(sin persistencia
Colaborador
Inyectado
acceso a persistencia de datos ficticia
FAKE
Clase derivada
(con persistencia)
Llamada a la interfaz de persistencia
Llamada a la persistencia
Colaborador de acceso a datos
(repositorio)
STUB
Interfaz de persistencia
Clase derivada
(con persistencia)
Clase base
(sin persistencia)
Colaborador
Inyectado
Persistencia
de datos
acceso a persistencia de datos
Clase base
(sin persistencia
Colaborador
Inyectado
acceso a persistencia de datos ficticia
FAKE
Clase derivada
(con persistencia)
(repositorio)
STUB
(repositorio)
STUB
Clase derivada
(con persistencia)


P&ina )6 de !)*
7.1.4. Diagramas de Clases y Dependencias
Como res$ltado del desarrollo 'DD Ja A$edado conformada $na arA$itect$ra de
softFare A$e representaremos mediante dia&ramas de clases y de dependencias+ 2l i&$al
A$e en el caso anterior, dada s$ eLtensi%n, la reco&emos en el 24#@, !
7.2. NDepend Metrics Reporter
Para obtener las mEtricas de c%di&o disponemos de la Jerramienta 4Dpend+ Sin embar&o
eList>an al&$nas necesidades A$e no estaban c$biertas con la versi%n *+(H
Grficos Jist%ricos de evol$ci%n+
=isto&ramas de frec$encias para anlisis estad>stico de las mEtricas
2l&$nos valores estad>sticos (medias y medidas de dispersi%n)+
Inicialmente para satisfacer estas necesidades, se iba a $tiliDar $n proceso de capt$ra y
volcado en base de datos, para interro&ar posteriormente+ ;inalmente decidimos crear
4Depend 5etrics 0eporter, A$e f$e creciendo Jasta incl$ir otras f$nciones+ Los reA$isitos
c$biertos con 4Depend 5etrics 0eporter sonH
Cons$ltar mEtricas individ$ales sobre elementos de c%di&o
o #nsamblados
o #spacios de 4ombres
o 'ipos
o 5Etodos
/is$aliDar las mEtricas en formato tab$lar para s$ comparaci%n, permitiendo s$
ordenaci%n+
Distin&$ir entre mEtricas sobre el c%di&o de la aplicaci%n, c%di&o asociado a los
test de aceptaci%n de las Jistorias de $s$ario, y c%di&o de los test de desarrollo
'DD+
Permitir incl$si%n de mEtricas personaliDadas
/is$aliDaci%n de valores estad>sticos (medias, mLimos, m>nimos, desviaciones)
sobre los valores de $na mEtrica para todo $n conB$nto de elementos+ Por
eBemplo, media de la mEtrica (n1mero de l'neas de cdi"o) para todos los mEtodos
de $n ensamblado+
/is$aliDaci%n de =isto&ramas de ;rec$encias sobre los valores de $na mEtrica para
todo $n conB$nto de elementos
/is$aliDaci%n de evol$ci%n temporal de $na mEtrica


P&ina )) de !)*
Dado A$e no era el obBetivo del presente ';G realiDar esta Jerramienta, para no eLtender
la presente memoria ms all de lo necesario y ceCirnos a 0C4GC 5embers
5ana&ement, no incl$iremos en ella dia&ramas referentes a este desarrollo+


P&ina )? de !)*


P&ina )6 de !)*
8. REQUISITOS DE HARDWARE Y SOFTWARE
Dado A$e el presente ';G no tiene como res$ltado $n prod$cto final para prod$cci%n,
este apartado ser>a en $n principio innecesario+ Sin embar&o, la Jerramienta 4Depend
5etrics 0eporter Jace $so de $na librer>a propietaria, por lo A$e tanto para la correcta
compilaci%n del c%di&o como para la instalaci%n del eBec$table final, eListen $na serie de
reA$erimientos de softFare+
8.1. NDepend Metrics Reporter
4Depend 5etrics 0eporter (4D50) Jace $so de $na 2PI propietaria de 4Depend+ Para
evitar problemas de copyri&Jt, no est permitido incl$ir el +dll de dicJa 2PI con la
instalaci%n de 4D50, sino A$e el sistema de destino debe disponer de s$ propia licencia
de 4Depend instalada y activa+ #sto si&nifica A$e, si bien deberemos incl$ir $na copia de
la librer>a en n$estro proyecto, para poder referenciarla d$rante n$estro desarrollo, no
debemos copiarla B$nto con los eBec$tables finales+ La referencia a dicJa librer>a de 2PI en
el eBec$table final deber resolverse en tiempo de eBec$ci%n, localiDando el directorio de
instalaci%n del paA$ete 4Depend+
Por tanto, se reA$ieren ciertos pasos previos y confi&$rar al&$nos elementos del proyecto
antes de poder comenDarH
Disponer de $na licencia activa del prod$cto 4Depend, A$e deber estar
correctamente instalada+
#n las propiedades de la referencia a 4Depend+2PI Jemos de indicar A$e no se
copie la librer>a al directorio de destino de los eBec$tables, estableciendo Copy
Local a 9false:+
#l eBec$table debe tener como directorio de destino la carpeta de instalaci%n de
4DependH $NDependInstallPath$\
La librer>a debe ser car&ada en tiempo de eBec$ci%n para elloH
o 2nadiremos a n$estro proyecto 4D50 la clase A$e podemos encontrar enH
$NDependInstallPath$\NDepend.PowerTools.SourceCode\AssemblyRe
solverHelper.cs


P&ina ? de !)*
o Car&aremos la librer>a Jaciendo $na llamada al evento al inicio del
pro&rama
AppDomain.CurrentDomain.AssemblyResolve +=
AssemblyResolverHelper.AssemblyResolveHandler;
(5:ur- $I1. C%di&o A$e debemos incl$ir en n$estro proyecto para resolver y car&ar en tiempo de eBec$ci%n
la librer>a del a 2PI de 4Depend
Los ensamblados de 4Depend contienen el c%di&o tras los interfaces definidos en
la 2PI, por lo A$e todos los ensamblados de 4Depend deben tambien estar
presentes en $NDependInstallPath$\ y $NDependInstallPath$\Lib
Los eA$ipos de destino para la instalaci%n o reGdeploy de 4D50 deben disponer
de s$ licencia, o copiar la licencia del sistema de desarrollo, respetando las
condiciones establecidas para p$estos 9Developer: y 9-$ild 5acJine:+

namespace NDepend.PowerTools {
internal static class AssemblyResolverHelper {
internal static Assembly AssemblyResolveHandler(object sender,
ResolveEventArs ars! {
var assemblyName " new AssemblyName(ars.Name!#
Deb$.Assert(assemblyName %" n$ll!#
var assemblyName&trin " assemblyName.Name#
Deb$.Assert(assemblyName&trin %" n$ll!#

'' &pecial treatment (or NDepend.AP) and NDepend.*ore beca$se t+ey
are de(ined in ,NDepend)nstallDir,-.ib
i( (assemblyName&trin %" /NDepend.AP)/ 00
assemblyName&trin %" /NDepend.*ore/! {
ret$rn n$ll#
1
strin binPat+ "

&ystem.)2.Pat+.3etDirectoryName(Assembly.3etE4ec$tinAssembly(!..ocation! 5
&ystem.)2.Pat+.Directory&eparator*+ar 5
/.ib/ 5
&ystem.)2.Pat+.Directory&eparator*+ar#

const strin e4tension " /.dll/#

var assembly " Assembly..oad6rom(binPat+ 5 assemblyName&trin 5
e4tension!#
ret$rn assembly#
1
1
1


P&ina ?! de !)*
9. DESARROLLO Y HERRAMIENTAS
#l presente ';G es $n proyecto de est$dio y anlisis de n$evas metodolo&>as+ Por tanto,
en la parte del desarrollo Jaremos $na eLposici%n de las Jerramientas empleadas para
realiDar el mismo+ La presentaci%n de las Jerramientas $tiliDadas s$ponen adems $na
&$>a para c$alA$ier eA$ipo de desarrolladores A$e deseen introd$cirse en al 2&ilismo+
9.1. El sistema de desarrollo
9.1.1. Hardware
#l eA$ipo de desarrollo Ja sido $n sistema PC compatible de las si&$ientes caracter>sticas
principalesH
Procesador Intel Core i( "()\ "+*GJD
?Gb 5emoria DD0(
Disco d$ro !'b S2'2 " )2
0ed cableada velocidad !Gbit, con coneLi%n a Internet !5b
5onitor 2)U !6H6 trabaBando a $na resol$ci%n de !62H!?
Para facilitar el aislamiento y las copias de se&$ridad, se cre% $na mA$ina virt$al con el
si&$iente JardFare sim$ladoH
",( Gb de memoria
Disco d$ro de ? Gb
#l dispositivo de red virt$al mant$vo la velocidad de !Gbit
#l monitor mant$vo la resol$ci%n nativa de !62H!?
9.1.2. Software
#l Sistema ,perativo del eA$ipo de desarrollo es $n [indoFs ? 6* bits, en el A$e se Ja
instalado ,racle /5 /irt$al -oL v+*+2+!2 para crear $na mA$ina virt$al A$e corre el
sistema final+ #n dicJa mA$ina virt$al, c$yas caracter>sticas antes eLp$simos, se Ja
montado $n [indoFs ) #mbedded de "2 bits, y se Ja desarrollado baBo /is$al St$dio
2!2+
Las licencias del softFare de desarrollo sonH


P&ina ?2 de !)*
[indoFs ? 6* bitH Licencia personal
,racle /5 /irt$al -oLH Licencia G4<
[indoFs ) #mbeddedH Licencia de la <LPGC para s$s al$mnos, descar&ada a
travEs de DreamSparZ
66

/is$al St$dio 2!2H Licencia de la <LPGC para s$s al$mnos, descar&ada a travEs
de DreamSparZ
5e &$star>a destacar el perfecto comportamiento de la mA$ina virt$al, A$e, con las
especificaciones asi&nadas, Ja respondido como si est$viEramos trabaBando directamente
con la mA$ina f>sica+
Dentro del /is$al St$dio 2!2 se Jan montado $na serie de Jerramientas A$e pasamos a
presentar+
9.2. Herramientas de desarrollo
9.2.1. Git
Dado A$e era necesario Jacer $n est$dio temporal de la evol$ci%n de la calidad del
c%di&o, desde $n principio se plante% la necesidad de Jacer $so de al&In sistema
repositorio donde almacenar el Jistorial de cambios+
;inalmente se opt% por el $so de $n Sistema de Control de /ersiones (S/C
)
), en
partic$lar la Jerramienta SC5 (So$rce Control 5ana&ement) conocida como Git
)!
,
principalmente por la facilidad A$e permit>a para almacenar $na copia del c%di&o en la
n$be a travEs del Git=$b
)2
, lo A$e proporcionaba como valor aCadido $n sistema de copia
de se&$ridad, as> como poder realiDar el desarrollo distrib$ido desde varios eA$ipos,
c$ando f$era necesario+
(5:ur- 9I1. La consola del Git

Git es $na Jerramienta A$e f$nciona en modo consola+ Para mayor comodidad es comIn
instalar al&In interfaD
)"
avanDado A$e facilite la interacci%n con el repositorio+ La decisi%n
A$e se tom% en este proyecto f$e instalar el SmartGit, ya A$e es m$y completa y &rat$ita
para $so no comercial+


P&ina ?" de !)*
9.2.1.1. GIT
Git es $n sistema de repositorio A$e presenta al&$nas caracter>sticas A$e lo Jacer m$y
interesanteH
S5/t3,- 43 RBr-02B50: -04 M3r:50:S. #n c$alA$ier momento, si en necesario, se
p$ede crear $na n$eva rama sobre el desarrollo principal, probar en ella las
modificaciones de c%di&o oport$nas, y si no te interesa, volver al desarrollo base
en el p$nto A$e se cre% la rama, o, si est todo correcto, f$sionar la misma+
(5:ur- 9I2. Sistema de 9-rancJin& f 5er&in&: del Git
;$enteH Git

L5:3ro ? r8154o. #l 9core: de &it es $na aplicaci%n li&era pro&ramada en C A$e
&estiona $n repositorio local en disco, $n solo ficJero llamado +&it A$e almacena
de forma comprimida el estado ori&inal del directorio y las copias diferenciales
con todos los cambios A$e se van prod$ciendo en el mismo+ #l ficJero se $bica en
el mismo directorio ori&en del repositorio, lo A$e facilita la event$al copia de
se&$ridad o borrado del mismo+ Los cambios son almacenados localmente y no se
env>an Jacia el repositorio central Jasta A$e no se eBec$te la orden de 9p$sJ:+


P&ina ?* de !)*
(5:ur- 9I3. La carpeta comprimida +&it conteniendo el repositorio del directorio

Tr->-7o 45/tr5>u54o. /arias personas p$eden participar de $n mismo proyecto
manteniendo $na copia local del mismo y volcando s$s modificaciones sobre el
repositorio central c$ando lo estimen necesario+ Permite n$merosas variantes a la
Jora de fl$Bos de trabaBo, con repositorios principales y sec$ndarios, &estores de
inte&raci%nK pero, en n$estro caso, $samos el sistema ms sencillo+
(5:ur- 9I. Sistema de repositorio compartido en Git
;$enteH Git

S3:ur54-4 43 4-to/. Cada aportaci%n al repositorio est firmada
cripto&rficamente con la ID del desarrollador A$e la realiDa, por lo A$e, es fcil
crear $n sistema de a$toriDaciones de lect$raWmodificaciones, y Jacer se&$imiento
de cada modificaci%n+
E9 RSt-:50: Ar3-S. C$ando defines $n repositorio, estableces, mediante $n ficJero
.gitignore
74
, de A$E ficJeros deseas Jacer se&$imiento y de c$ales no+ Pero,
adems, antes de efect$ar el 9commit: definitivo sobre el repositorio, siempre
p$edes revisar, en el 9Sta&in& 2rea:, los ficJeros modificados A$e van a ser
almacenados+ Por tanto, cada aportaci%n al repositorio se Jace en dos pasosH


P&ina ?( de !)*
primero, 9add: al 9sta&e:, y desp$Es, 9commit: al repositorio+ Para cada 9commit:
realiDado podrs incl$ir $n comentario descriptivo de los cambios aCadidos+
(5:ur- 9I5. #l 9sta&in& area: en el Git
;$enteH Git

L5>r3 >-7o 9523025- GNU. ,bviamente, no se p$ede $sar softFare ile&al en $n
proyecto ])
5ediante el $so de $n sistema repositorio de estas caracter>sticas, y a travEs de los
mensaBes del 9commit:, se p$ede llevar $n control de las iteraciones, Jistorias de $s$ario y
escenarios, test aCadido y p$ntos del ciclo donde nos encontramos+
<na b$ena prctica a se&$ir es realiDar $n 9commit: desp$Es de cada 9&reen: y al final de
cada refactoriDaci%n+
I0/t-9-04o 39 G5t
La instalaci%n en [indoFs del Git (msys&it
)(
), es m$y simple, como en casi todas las
aplicaciones [indoFs+ 'an solo nos pedir A$e tomemos al&$nas decisiones sobre
modificaciones de la variable 9P2'=: o la forma de maneBar C0WL; para mayor
compatibilidad son sistemas <niL+
<na veD instalado, dispondremos de $na consola estilo 9basJ:, llamada Git -asJ y de $n
sencillo interfaD, el Git G<I, A$e permitir realiDar las tareas bsicas de crear, clonar y
abrir repositorios, o tener acceso a las claves SS= para la coneLi%n con escritorios
remotos+
Co0<5:ur-04o 39 G5t
<na veD instalado, deberemos confi&$rar el $s$ario por defecto en Git, para A$e se
identifiA$en correctamente los 9commit: realiDado a los repositorios+ Para ello, abrimos el
Git -asJ e introd$cimos estos dos comandosH


P&ina ?6 de !)*
(5:ur- 9I". Confi&$raci%n del $s$ario del Git
Cr3-04o 9-/ 29-@3/ SS& 1-r- 9o/ r31o/5tor5o/ r3,oto/
Git $tiliDa coneLi%n se&$ra SS= para conectarse con los servidores remotos+ #n n$estro
caso, A$e no trabaBaremos solamente en local, sino A$e Jaremos $so de Git=$b,
necesitamos crear n$estro par de claves privada y pIblica+ Para ello, en [indoFs,
podemos Jacer $so de la consola de Git -asJ o $sar el c%modo Git G<I
"eneracin del par de claves en "it #as$
#Bec$tamos la consola de Git -asJ e introd$cimos los si&$ientes comandosH
(5:ur- 9I7. Creaci%n de las claves SS= para la com$nicaci%n se&$ra con repositorios remotos
9.2.1.2. GitHUB
La raD%n principal por la A$e nos decidimos a $sar el Git f$e por le eListencia del proyecto
Git=<-, $n sistema de repositorio en la n$be A$e es libre para c%di&o abierto+ Dado A$e
el proyecto A$e ibamos a realiDar no iba a dar como res$ltado nin&In softFare comercial,
sino A$e tan solo se trataba de al&$nas librer>as sobre las A$e realiDar est$dios de
mEtricas, esta sol$ci%n era perfecta+ 5s tarde empeDamos con el desarrollo de la
aplicaci%n 4Depend 5etrics 0eporter, pero no t$vimos nin&In problema en deBar libre s$
acceso de lect$ra+

$ ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/you/.ssh/id_rsa): [Press
enter]

$ ssh-add id_rsa

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

Your identification has been saved in /c/Users/you/.ssh/id_rsa.
Your public key has been saved in /c/Users/you/.ssh/id_rsa.pub.
The key fingerprint is:
01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com

$ git config --global user.name "Your Name Here"
# Sets the default name for git to use when you commit

$ git config --global user.email "your_email@example.com"
# Sets the default email for git to use when you commit


P&ina ?) de !)*
(5:ur- 9I$. InterfaD [eb del Git=$b

5ediante $n simple re&istro en la p&ina del Git=$b y la creaci%n de $na c$enta,
podemos crear repositorios de forma &rat$ita siempre y c$ando se manten&an pIblicos+
La idea de Git=$b pIblico es la de compartir informaci%n de manera A$e c$alA$ier
$s$ario se p$ede s$scribir a repositorios de otras personas para se&$irlos, solicitar
permiso para $nirse a ellos, o clonarlos para iniciar $n desarrollo propio basado en el
anterior+ #s $n concepto A$e trata de com$nidad de desarrolladores A$e comparte
eLperiencias de pro&ramaci%n, convirtiendose en $na red social con 9se&$idores: como
p$deran tenerlos los 9tFeets:
)6
+ 5$cJos proyectos de c%di&o abierto se est iniciando
aA$> en veD de en 9So$rce;or&e:
))
+
#n n$estro caso apenas se Ja JecJo $so de las capacidades de la red social, sino A$e se le
Ja dado tres $sos m$y definidosH
Como sistema de copia de se&$ridad en la n$be
Para compartir el proyecto entre varios eA$ipos donde Je realiDado el desarrollo
Para mantener informado al t$tor sobre la evol$ci%n del proyecto+
#l Git=$b dispone de $na Jerramienta instalable en [indoFs para maneBar todos los
repositorios de forma remota y mantenerse informado de los cambios en el proyecto A$e
realiDan otros miembros del eA$ipo, pero el interfaD Feb Ja sido ms A$e s$ficiente para
n$estras necesidades+


P&ina ?? de !)*
(5:ur- 9I9. 2plicaci%n de acceso a Git=$b para [ndoFs

Co0<5:ur-04o 9- 2o03N5A0 r3,ot- - G5t&u>
Lo primero es localiDar las claves pIblica y privada del Git+ Por defecto se encontrarn en
el directorio MC:/Users/<username>/.ssh/id_rsa.pubU+ Si es as>, Git Gamos $na+
<na veD la ten&amos en el portapapeles, pasamos entramos en n$estra c$enta de Git=$b
y se&$imos estos pasosH
!+ #ntramos en 92cco$nt Settin&s:
2+ P$lsamos en MSS= \eysU, en la barra de la iDA$ierda
"+ =acemos clicZ en 92dd SS= \ey:


P&ina ?6 de !)*
*+ Pe&amos la clave A$e ten>amos en el portapapeles dentro del c$adro 9\ey:
(+ P$lsamos 92dd \ey:
6+ Confirmamos introd$ciendo n$estra clave de $s$ario
'odo el procedimiento de creaci%n de claves, introd$cci%n de las mismas y pr$eba de
coneLi%n la podemos encontrar en este enlaceH
JttpsHWWJelp+&itJ$b+comWarticlesW&eneratin&GssJGZeys
9.2.1.3. SmartGit
SmartGit es $na Jerramienta realmente potente A$e permite realiDar todas las
operaciones sobre t$ repositorio 9Git: de $na manera vis$al y m$y sencilla+ Incl$ye $n
completo vis$aliDador de las modificaciones realiDadas sobre el c%di&o, $n formidable
&estor de 9brancJes:, y $n sistema de coneLi%n con repositorios en la n$be A$e Jace m$y
fcil la sincroniDaci%n+ 2dems, aCade $n editor del 9indeL:, la memoria A$e re&istra los
cambios A$e se van prod$ciendo en los ficJero antes de ser aCadidos al 9sta&e:,
permitiendo s$ modificaci%n+
I0/t-9-04o S,-rtG5t
La instalaci%n del SmartGit es inmediata, a travEs de $n sencillo 9FiDard:, en el A$e no
deberemos tomar prcticamente nin&$na decisi%n+
V30t-0- 1r50251-9
Desde la interfaD del SmartGit tenemos rpido acceso a las operaciones ms com$nes del
GitH
Sta&e, <nsta&e, IndeL editorH Gestiona los elementos de 9sta&e:
CommitW5er&eH #nv>a del sta&e al repositorio, y f$siona la rama act$al del
proyecto con la rama principal si se lo indicamos
P$llWP$sJWSyncH 0ealiDa las operaciones entre el repositorio local y la red
#n la pantalla principal del SmartGit tenemos, en $n solo vistaDo, las carpetas A$e
componen el repositorio y los ficJeros A$e Jan sido modificados, as> como s$ estado (si
se enc$ntran pendientes de aCadir al 9sta&e: o ya Jan sido aCadidos para el pr%Limo
9commit:)+ 2 travEs de diferentes filtros p$edes pedir al pro&rama A$e te presente todos
los ficJeros+


P&ina 6 de !)*
(5:ur- 9I11. La ventana principal del SmartGit

'ambiEn dispone de $n visor en el A$e se presentan c$les son las modificaciones
prod$cidas en los ficJeros de teLto, en n$estro caso, ficJeros f$ente, para $n meBor
se&$imiento de la eval$aci%n de c%di&o
;inalmente, presenta $n res$men del las ramas del proyecto, operaciones ms recientes
realiDadas sobre el proyecto, y Iltimos 9commits:+
S3:u5,530to 43 9- 3@o9u25A0 439 r31o/5tor5o
Desde esta ventana podemos acceder de manera m$y vis$al al estado del repositorio en
c$alA$ier p$nto temporal, con $na representaci%n &rfica m$y clara de la evol$ci%n de las
diferentes ramas+
Permite llevar el control de cada rama, y revisar los cambios introd$cidos en cada
9commit:+ Si el sistema de repositorio sobre el A$e corre la Jerramienta permite la
creaci%n y edici%n de perfiles completos de $s$ario, estos aparecen en los detalles+


P&ina 6! de !)*
(5:ur- 9I12. Se&$imiento de la evol$ci%n del repositorio en SmartGit

E45tor 43 2-,>5o/ 30 ;04523
(5:ur- 9I13. #l 9IndeL #ditor: del SmartGit


P&ina 62 de !)*
Desde el 9indeL editor: p$edes ver claramente, para cada ficJero, s$ estado en el
repositorio, el ficJero tal y como se enc$entra act$almente en el directorio de trabaBo, y
los cambios (adiciones y elementos eliminados) A$e se van a prod$cir en el sta&e,
permitiendo $na edici%n de los mismos+
R3:5/tro 43 ,o45<52-25o03/ 30 u0 <52B3ro. B9-,3
<na de las Jerramientas ms potentes del Git es el 9-lame:+ #n El podemos ver cada
cambio prod$cido en el cada l>nea de c%di&o de $n ficJero, la fecJa del mismo y A$iEn f$e
el desarrollador A$e la JiDo, de aJ> el simptico nombre de 9-lame: (Pya sabemos a A$ien
ecJarle la c$lpa si al&o fallaQ)+ SmartGit dispone de $n vis$aliDador para esta f$nci%n+
(5:ur- 9I1. -lame para SmarttGit

G3/t5A0 43 r31o/5tor5o/ 30 9- r34
#l SmartGit permite vinc$lar c$alA$ier repositorio local con otro remoto de manera
sencilla+ Para conectarse con $n repositorio Git=$b tan solo es necesario iniciar $n
proceso de clonado en local+ La coneLi%n con Git=$b se realiDa a travEs de SS=, debiendo
car&arse en tanto en SmartGit como en Git=$b la clave de la ID de $s$ario Git+ Como
medida adicional, en las operaciones 9p$sJ: se pedir tambiEn confirmaci%n de la clave de
la c$enta Git=$b+


P&ina 6" de !)*
(5:ur- 9I15. ConeLi%n de SmartGit con repositorios remotos

Las claves SS= para la coneLi%n son encontradas y aCadidas a$tomticamente al
SmartGit d$rante la instalaci%n del mismo+ Si necesitamos cambiarlas, podemos Jacerlo a
travEs de @dit-W <re&erences
(5:ur- 9I1". Gesti%n del claves SS= en SmartGit

9.2.2. SpecFlow
Para Jacer ms sencilla la &esti%n y el se&$imiento de las Jistorias de $s$ario -DD eListe
$na serie de frameForZs A$e facilitan la inte&raci%n del -DD y la a$tomatiDaci%n de s$s
test de aceptaci%n dentro del entorno del desarrollo+
<no de los ms conocidos es el C$c$mber
)?
para len&$aBe de pro&ramaci%n 0$by
)6


P&ina 6* de !)*
Para el entorno de desarrollo de /is$al St$dio podemos encontrar el Spec;loF
?
, de
c%di&o abierto baBo licencia -SD, basado en la misma idea A$e C$c$mber y A$e tambiEn
$tiliDa como len&$aBe GJerZin
?!
, y A$e presenta $na ma&n>fica inte&raci%n con la mayor>a
de frameForZs de test para /is$al, incl$yendo el nativo 5S'ests, A$e es el A$e Jemos
$sado en n$estro desarrollo+
Para completar el SpecfloF eListen dos Jerramientas A$e, si bien no Jemos $sado por no
se libres, merecen especial menci%nH
Spec0$n
?2
meBora la interfaD para la eBec$ci%n y el se&$imniento de los test de
aceptaci%n de Spec;loF+
SpecLo&
?"
es la Jerramienta perfecta para or&aniDar y &estionar todas las Jistorias
de $s$ario entre los distintos miembros de $n eA$ipo de desarrollo &il, Jacer $n
se&$imiento de las mismas, y doc$mentarlas+
Con Spec;loF, la conversi%n de las Jistorias de $s$ario a test de aceptaci%n es $n proceso
m$y simple en dos pasosH
1.I E/1325<52-r 9- B5/tor5- 43 u/u-r5o 30 930:u-73 GB3rL50
Para cada Jistoria de $s$ario creamos $na 9;eat$re: en SpecfloF
(5:ur- 9I17. 2Cadiendo $na n$eva 9;eat$re: (=istoria de <s$ario)

<na 9feat$re: no es ms A$e $n doc$mento de teLto con $na Jistoria de $s$ario como la
A$e ya Jemos mostrado al Jablar de -DD, con $n formato espec>ficoH
La Jistoria de $s$ario se llama 9;eat$re:
2 la Jora de especificar 9roleGfeat$reGbenefit: se $sa prcticamente la misma
notaci%n A$e la A$e present% Dan 4ortJ, solo A$e cambiando $n poco el orden+
#n este caso es 9In order to g 2s an g I Fant to:, es decir, 9benefitGroleGfeat$re:


P&ina 6( de !)*
Se&$idamente, vienen los diferentes escenarios, con s$ serie de precondiciones
(Given), acciones ([Jen) y res$ltados ('Jen)
(5:ur- 9I1$. <na 9feat$re: o Jistoria de $s$ario en Spec;loF

2.I Auto,-t56-r 9o/ 3/230-r5o/
Podemos pedir a Spec;loF A$e nos cree y asocie $n mEtodo a cada $no de los pasos
GivenG[JenG'Jen de la 9feat$re:+ Cada $no de estos mEtodos es llamado por Spe;loF $n
9Step Definition:+ #n veD de tener $n solo test de aceptaci%n, nosotros lo veremos
dividido en fra&mentos GivenG[JenG'Jen, A$e iremos completando con el c%di&o de
n$estro test de aceptaci%n+ #n el momento de la compilaci%n, Spec;loF re$nir todos los
9step definitions: asociados a los GivenG'Jenh[Jen de $n escenario en solo test con s$
nombre, c$yo res$ltado veremos posteriormente al eBec$tarlo desde n$estro frameForZ
de test+
(5:ur- 9I19H Specs bindin& en SpecfloF


P&ina 66 de !)*
I0/t-9-04o 39 S132(9o=
#l ;rameForZ de Spec;loF est comp$esto de tres paA$etes principalesH
#l 50t3:r-4or 439 IDE, A$e c$stomiDa el editor y las f$nciones de &eneraci%n de
test en el entorno de desarrollo ele&ido
#l :303r-4or, A$e convierte las especificaciones GJerZin en clases de test
eBec$tables
#l ru0t5,3, A$e es necesario para eBec$tar los test &enerados+ =ay diferentes
ensamblados se&In la plataforma de destino (+4et, Silverli&Jt, [indoFs PJone)
#n el caso de n$estro entorno de desarrollo, todo ello se a$tomatiDa a travEs de $na sola
descar&a e instalaci%n , a travEs de la Jerramienta de 9#Ltensiones y 2ct$aliDaciones: del
/is$al St$dio+
(5:ur- 9I2). Instalaci%n de Spec;loF en /is$al St$dio 2!2

<na veD ya dispon&amos de la Jerramienta inte&rada en n$estro entorno de desarrollo,
podemos aCadir Spec;loF a n$estra sol$ci%n activa+
(5:ur- 9I21. 2Cadiendo $n proyecto Spec;loF a la sol$ci%n a travEs del administrador de paA$etes 4$Get

2$nA$e no es imprescindible, $na b$ena praLis profesional reA$iere A$e todo el sistema
de -DD se monte en $n proyecto de biblioteca de clases separado de la l%&ica de


P&ina 6) de !)*
aplicaci%n+ <na veD creado, aCadimos Spec;loF travEs de la Jerramienta de
administraci%n de paA$etes llamada 94$Get:
?*
, incl$ida en /is$al St$dio 2!2+
Co0<5:ur-04o 39 1ro?32to S132(9o=
La confi&$raci%n del proyecto Spec;loF se realiDa por completo a travEs de la edici%n de
$n ficJero +@5L, llamado (App/con&i")
(5:ur- 9I22. ;icJero de confi&$raci%n de Spec;loF

De las mIltiples opciones de confi&$raci%n
?(
la A$e realmente nos interesa es especificar
c$al ser el proveedor de tests+ #n n$estro caso indicaremos A$e ser 5s'est, A$e esta
inte&rado en /is$al St$dio+ Si f$Eramos a $sar otro proveedor diferente, deber>amos,
primeramente, instalar dicJo ;rameForZ de test, y, posteriormente, indicar a Spec;loF
A$e vamos a Jacer $so del mismo+
;inalmente, no se nos debe olvidar aCadir en n$estro reciEn creado proyecto, $na
referencia al ensamblado sobre el A$e eBec$taremos los test de aceptaci%n+
GB3rL50. 39 930:u-73 1-r- 3N1r3/-r B5/tor5-/ 43 u/u-r5o
(5:ur- 9I23. <na Jistoria de $s$ario eLpresada en GJerZin

1: Feature: Some terse yet descriptive text of what is desired
2: In order to realize a named business value
3: As an explicit system actor
4: I want to gain some beneficial outcome which furthers the goal
5:
6: Scenario: Some determinable business situation
7: Given some precondition
8: And some other precondition
9: When some action by the actor
10: And some other action
11: And yet another action
12: Then some testable outcome is achieved
13: And something else we can check happens too
14:
15: Scenario: A different situation
16: ...


P&ina 6? de !)*
GJerZin es el len&$aBe A$e $tiliDa Spec;loF+ #st diseCado para ser similar al len&$aBe
nat$ral y ay$da a describir el comportamiento de $n softFare sin detallar c%mo se
implementa dicJo comportamiento+ #stablecer $n neLo entre lo A$e el cliente necesita y
$na especificaci%n ms o menos detallada de los elementos de $n test de aceptaci%n+
C$mple, por tanto finesH doc$mentaci%n y a$tomatiDaci%n de tests
#n GJerZin cada declaraci%n es $na l>nea, y la conversi%n desde las Jistorias de $s$ario de
Dan 4oJ es trivialH $n nombre para la Jistoria, la especificaci%n de roleGfeat$reGbenefit, y
$na serie de escenarios, cada $no de los c$ales se convertir en $n test de aceptaci%n+
2l ser $n len&$aBe nat$ral, con pocas palabras reservadas (en realidad, !2H name, native,
feat$re, bacZ&ro$nd, scenario, scenarioho$tline, eLamples, &iven, FJen, tJen, and, b$t),
GJerZin se p$ede obtener en m$ltit$d de idiomas, para facilitar la interpretaci%n al
cliente+
Las especificaciones completas del len&$aBe
?6
, incl$yendo como aCadir elementos de
conteLto y tablas de eBemplos, las podemos encontrar dentro de proyecto C$c$mber A$e
mantiene Git=$b
R(3-tur3SIRS230-r5oSIRSt31S. 9- -uto,-t56-25A0 43 9o/ t3/t S132(9o=
Las 9feat$res: son la base del SpecfloF+ Cada $na de ellas se especifica en len&$aBe
GJerZin en $n ficJero de teLto .feature diferente+ Cada ficJero .feature incl$ye $na
serie es escenarios, cada $no de los c$ales se detalla en $na serie de pasos (steps) GivenG
[JenG'Jen (precondicionesGaccionesGres$ltados)+ =asta aA$> la parte A$e ver el cliente+
Para el desarollador, cada $na de estos pasos deber ser c$bierto por $n 9step definition:,
$n mEtodo A$e se asocia al :step:, y A$e implementa, en el len&$aBe del entorno de
pro&ramaci%n, el comportamiento del mismo+ Los declaraciones de los 9step definitions:
p$eden ser creadas y asociadas por el desarrollador o deBar A$e sea el Spec;loF A$ien se
encar&$e de la labor, deBando al pro&ramador la tarea de implementarlos+ La $ni%n de
todos los 9step definitions: asociados a los pasos GivenG'JenG[Jen de $n escenario
conformar>an lo A$e ser>a el test de aceptaci%n de dicJo escenario+
FP3roM 2A,o <u025o0-H
'ras la compilaci%n, Spec;loF &enerar de forma a$tomtica $na clase (.feature.cs)
por cada .feature del proyecto+ #n ella se crear $n test por cada escenario, con el
nombre del mismo+ #l contenido de esta clase no debe ser en nin&In momento editado
por el desarrollador, ya A$e es a$to&enererado por el frameForZ+ Si la vis$aliDamos,
podremos observar A$e incl$ye varias inicialiDaciones y los tests A$e l$e&o veremos
eBec$tarse (en formato 4<nit, @<nit, 5s'estK, se&In la confi&$raci%n del proyecto)+ Sin
embar&o, el contenido de estos test no es el c%di&o re$nificado de los diferentes 9specs:,
sino A$e todo el trabaBo se realiDa a travEs de s$ propio m%d$lo 9r$ntime:, mediante
llamadas a $n obBeto test6unner A$e va invocando por s$ nombre los diferentes 9specs: y
eBec$tndolos a travEs de refleLi%n+


P&ina 66 de !)*
#sto, A$e en $n principio es $n comportamiento perfecto para evitar d$plicidades en el
c%di&o, s$p$so $n problema a la Jora de realiDar mEtricas sobre tests de aceptaci%n,
como l$e&o eLplicaremos, obli&ndonos a tomar medidas 9antipatr%n:+
St31/ B50450:
Spec;loF facilita la creaci%n y asociaci%n de los mEtodos 9step definition:, con $n patr%n
m$y simpleH
(5:ur- 9I2. ;orma en A$e Spec;loF asocia cada 9paso: con el c%di&o A$e lo implementa

Los 9step definitions: se a&r$pan en clases A$e Jan de estar decoradas con el atrib$to
[Binding]. #l nombre del mEtodo es irrelevante, a$nA$e res$lta meBor si Jace
referencia al 9step:+
Lo ms importante a recordar es A$e en Spec;loF los 9step definition: son, por defecto,
GL,-2L#S al proyecto+ Por tanto $n mEtodo decorado con 9[Given(@"I have an
invoice")] se asociar a c$alA$ier 9Given I have an invoice,
independientemente de en A$E ficJero .feature se enc$entre dicJo step, o si se repite
en varios escenarios diferentes+ 'ampoco importa en A$e [Binding] Jayamos incl$ido el
9step definition:+ #sto, A$e en $n principio es $na enorme ventaBa a la Jora de aJorrar
c%di&o ($n solo 9step definition: nos sirve para m$cJas repeticiones de $n step), p$ede
lle&ar a ser $n verdadero rompecabeDas, p$esH
#n dos escenarios diferentes dos pasos con el mismo nombre p$eden referirse a
sit$aciones distintas y reA$erir cada $na s$ propia implementaci%n+
I&$almente, no podemos d$plicar steps definitions+
Para evitar este tipo de problemas, Spec;loF nos da $na serie de conseBos y nos facilita
al&$nas JerramientasH
2 la Jora de crear los mEtodos 9step definitions: no debemos a&r$parlos en torno
a $na 9feat$re:, sino a $n dominio+ #s decir, A$e no debemos intentar crear $na
clase con todos los 9step definitions: asociados a $na 9feat$re 9en partic$lar, ya A$e
posiblemente terminaremos asociando esos mismos mEtodos a otros pasos con el
mismo nombre y f$nci%n en diferentes 9feat$res:+ Lo meBor es $tiliDar el dominio
de ne&ocio al A$e se aplican como norma para a&r$par los 9step definitions:
D-4o 39 R/t31S

Given I have an invoice

E9 ,Gto4o R/t31 43<505t5o0S Qu3 /3 -/o25-r8 -9 ,5/,o t304r8 3/t- <or,-

[Given(@"I have an invoice")]
public void GivenIHaveAnInvoice(){}


P&ina ! de !)*
#sto nos lleva a A$e, a veces, $n escenario se desarrolla a travEs de mEtodos A$e
residen en clases ([Binding]) distintas+ Spec;loF facilita al&$nos mEtodos para
intercambiar
?)
la informaci%n, entre las A$e se incl$yen inyecci%n de clases
P,C,
??
, campos de instancia de clases, incl$so a veces recomiendo el $so de
clases estticas para el intercambio+ 'ambiEn facilita $na clase llamada
ScenarioConteLt, A$e se inicialiDa al principio de cada escenario, a travEs de la
c$al, $tiliDando $n diccionario llamado ScenarioConteLt+C$rrent
?6
, podemos pasar
obBetos de todo tipo a lo lar&o de la eBec$ci%n+
Si nos vemos en la necesidad de d$plicar 9step definitions: restrin&ir el mbito de
los mismos mediante el $so de los 9Scooped -indin&s:
6
+ Siempre podemos
decorar $na 9feat$re:, 9scenario: o 9step: mediante el $so de 9ta&s:
6!
, lo A$e
normalmente Jacemos para filtrar $ or&aniDar escenarios y feat$res+ #s posible
establecer el alcance de $n 9Step Definition: si especificamos s$ 9scope:+ Sin
embar&o Spec;loF es m$y claro al respecto, indicando A$e se debe evitar el $so
de estas prcticas por considerarlas 9antipatr%n:
[Scope(Tag = "mytag", Feature = "feature title", Scenario = "scenario title")]

Sin embar&o, en este desarrollo en partic$lar, para poder adA$irir mEtricas sobre
las Jistorias de $s$ario, a la Jora de crear los 9Step Definition: para Spec;loF
Jemos se&$ido $n comportamiento 9antipatron:+ 2 veces Jemos debido
d$plicarlos para re$nir en $na sola clase todos los todos los mEtodos asociados a
los 9Steps: de los escenarios de $n mismo 9;eat$re:+ #l problema reside en la
manera A$e tiene Spec;loF de implementar los test de aceptaci%n para cada
escenario, ya A$e, en veD de llamar directamente a los mEtodos de los 9Step
Definition:, lo Jace a travEs de s$ propio r$ntime, $sando refleLi%n+ Por tanto, las
mEtricas efect$adas sobre dicJos test de aceptaci%n no arroBan nin&In tipo de
informaci%n sobre el modelo de la aplicaci%n+ Solo a travEs de esa 9clase
antipatron:, A$e reIne todos los mEtodos A$e procesan $n 9;eat$re:, podemos
tomar al&$na medida con respecto a la compleBidad del mismo+
#stas son las caracter>sticas ms bsicas de Spec;loF y C$c$mber+ Para prof$ndiDar en
mayor medida sobre s$s f$nciones, podemos acceder a $na doc$mentaci%n
62
m$y
completa en la p&ina del desarrollador+
9.2.3. MSTests
Para n$estro desarrollo 'DD Jemos ele&ido el 5S'est, el frameForZ propio A$e trae
inte&rado el /is$al St$dio
S$ f$ncionamiento es similar al de otras infraestr$ct$ras de test ms conocidas en
sistemas abiertos como p$dieran ser 4<nit o @<nit+ Sin embar&o, dado A$e estamos
desarrollando en /is$al, Jemos A$erido $tiliDar la Jerramienta nativa y comprobar s$
inte&raci%n con las otros elementos como son Spec;loF, 'estDriven o 4Cover+
Desfort$nadamente, al&$nas caracter>sticas importantes, como p$eden ser el Code
Covera&e, no est disponibles en la versi%n Profesional de /is$al St$dio, A$e es la A$e la


P&ina !! de !)*
esc$ela pone a disposici%n de los al$mnos para s$ descar&a travEs de DreamSparZ, por la
A$e, para poder Jacer se&$imiento del mismo, instalamos la Jerramienta 'estDriven, A$e
incl$ye $na versi%n limitada de 4Cover, s$ficiente para este prop%sito+
A:r3:-04o u0 1ro?32to MST3/t
2l ser el ;rameForZ nativo de /is$al St$dio, a&re&ar $n proyecto de test es de lo ms
sencillo+ Simplemente, como vemos en la ;i&$ra 6G2( abrimos en interfaD para aCadir $n
proyecto ms a la sol$ci%n, y ele&imos MProyecto de pr$eba $nitariaU
(5:ur- 9I25. 2&re&ando $n proyecto 5S'est a la sol$ci%n act$al

2l i&$al A$e con el Spec;loF, tan solo nos falta aCadir la referencia al ensamblado A$e
contiene el c%di&o sobre el A$e eBec$taremos los test $nitarios+
L- 29-/3 43 t3/t 30 MST3/t ? /u 50/t-025-25A0
<na clase de test es, bsicamente, $na clase normal de CT en la A$e Ja sido decorada con
atrib$tos A$e la identifican como tal+ Dentro de la misma, cada $no de los mEtodos A$e la
componen p$ede ser decorado con $n atrib$to para realiDar $na f$nci%n espec>fica,
siendo la ms normal la de [TestMethod] A$e identifica al mismo como test+
2 diferencia de otras s$ites de test, como p$ede ser 4<nit, en 5Stest cada $no de los
[TestMethod] se eBec$ta en $na instancia separada de la clase, cada $no de ellos en $n
Jilo diferente+ #ste diseCo implica * comportamientos A$e Jan de tenerse en c$entaH
!+ C9-//I05t5-9563 ? C9-//C93-0u1. 5icrosoft Ja diseCado estos mEtodos como
estticos para ser eBec$tados $na sola veD+ ClassInitialiDe antes de la primera
instancia del primer [TestMethod], y [ClassCleanup] lo Jace al final de la
Iltima instancia+ S$ f$nci%n es inicialiDar var$iables A$e debern ser compartidas
por los test+ 2l ser $na clase esttica, solo p$ede modificar variables estticas+
2+ Or430 43 3732u25A0. #l orden en A$e se eBec$tan los tests es absol$tamente
aleatorio, por lo A$e el res$ltado de $n test no deber afectar a los dems+ #s por


P&ina !2 de !)*
ello A$e las variables estticas inicialiDadas en [ClassInitialize] no deber>an
ser tocadas+ Si necesitamos inicialiDar $n &r$po de variables, $n conteLto, A$e
$saremos $n modificaremos en cada test, la manera correcta de Jacerlo es a
travEs de los mEtodos [TestInitialize], A$e se eBec$tarn $na veD por cada
[TestMethod]+ Del mismo modo eListen los [TestCleanup], A$e se eBec$tarn
desp$Es de cada [TestMethod] +
(5:ur- 9I2". <na clase de test en 5S'est y s$s atrib$tos

"+ E9 Co0/tru2tor 43 9- 29-/3. Como vemos, cada [TestMethod] se eBec$ta en $na
instancia separada de la clase, por lo A$e el constr$ctor de la clase, si lo
implementamos, se eBec$tar $na veD por mEtodo, asemeBndose s$
comportamiento a [TestInitialize] en veD de a [ClassInitialize]
[TestClass]
public class VSTSClass1
{
private TestContext testContextInstance;

public VSTSClass1()
{}

public TestContext TestContext
{
get
{
return testContextInstance;
}
set
{
testContextInstance = value;
}
}

[ClassInitialize]
public static void ClassSetup(TestContext a){}

[TestInitialize]
public void TestInit(){}

[TestMethod]
public void Test1(){}

[TestMethod]

[TestMethod]

[TestCleanup]
public void TestCleanUp(){}

[ClassCleanup]
public static void ClassCleanUp(){}
}


P&ina !" de !)*
*+ T3/tCo0t3Nt. 5S'est facilita $na clase especial 9$estConte7t)
CE
, c$ya forma de ser
inicialiDada vemos en el eBemplo de la ;i&$ra 6G26, A$e podremos $sar para
obtener informaci%n sobre el conteLto de los tests+ Las variables de este tipo se
inicialiDan en cada test, no p$diendo $tiliDarse para compartir informaci%n entre
cada [TestMethod]
E/tru2tur- 43 u0 t3/t 30 MST3/t
La estr$ct$ra de $n mEtodo de test es, bsicamente, siempre la mismaH
!+ IncialiDaci%n de las variables locales del test (precondiciones), donde se car&a el
sistema con los valores a probar
2+ #Bec$ci%n del mEtodo o llamada al elemento del sistema sobre el A$e A$eremos
efect$ar la pr$eba
"+ Comprobaci%n del res$ltado mediante el $so de la clase (Assert)
C9

(5:ur- 9I27. #Bemplo de test $nitario en 5S'est
M-037o 43 3N23125o03/ 30 MST3/t/
5S'est &estiona los res$ltados de los test a base de eLcepciones
6(
+ Cada veD A$e $n test
falla, se lanDa la eLcepci%n (Assert@7ceptionFailed)+ De esta manera, si $n test presenta
varias sentencias (Assert) (lo A$e deber>a evitarse en la medida de lo posible), desde A$e
falle $na el frameForZ 5S'est se aJorra el tener A$e se&$ir con la eBec$ci%n del resto+
Por tanto, el res$ltado de $n test p$ede serH
T3/t 30 ro7o. Se Ja prod$cido $na (AssertFailed@7ception)+ #sto p$ede oc$rrir
porA$eH
o #l test Ja tardado demasiado tiempo en eBec$tarse
o #l test Ja ca$sado $na eLcepci%n no controlada
o #l test falla
T3/t 30 -,-r599o. Se Ja prod$cido $na 92sserInconcl$sive#Lception:+ #sto oc$rre
c$ando el res$ltado del test es 9inconcl$sivo:+ 4ormalmente se Jace $so de esta
7Test8et+od9
p$blic void NetAmmo$ntis:ell*alc$lated2nTa46ree)nvoices(!
{
)nvoice invoice " new )nvoice(/;;;;;/, new DateTime(<=;>, ?, ;>!!#
invoice.AddTransaction(/*$ota/, /*$ota &ocial @$lio/, ;, AB,=!#
Assert.AreEC$al(AB, invoice.NetAmmo$nt!#
1


P&ina !* de !)*
f$nci%n para marcar los test de aceptaci%n incompletos, forDando esta eLcepci%n
mediante la invocaci%n del mEtodo 9Assert.Inconclusive():
T3/t 30 @3r43. 4o se Ja prod$cido nin&$na eLcepci%n+ #l test Ja pasado
Por tanto, Jemos de tener m$y en c$enta dos cosasH
Si $n test finaliDa en roBo no siempre si&nifica A$e el test Ja fallado+
*i lo que esperamos como resultado de nuestro test es que se produzca una
e7cepcin, no podemos comprobarlo a tras de una sentencia (Assert), #a que
solo .a# erde si no se producen e7cepciones/
La manera A$e tiene 5S'est de maneBar las eLcepciones es decorando el mEtodo de test
con $n atrib$to A$e refleBe el tipo de eLcepci%n decorado+ #ntonces, el propio 5S'est
interceptar la interr$pci%n, ver si es del tipo esperado, y el test aparecer en verde+
#sta manera de maneBar las eLcepciones obli&a a realiDar $n trabaBo 9eLtra: a la Jora de
comprobar A$e n$estra aplicaci%n las lanDa correctamenteH
!+ Decorar el mEtodo de test para A$e se A$ede a la espera del tipo de eLcepci%n
A$e prod$cir>a $n test con 9ELito:
2+ Interceptar nosotros la interr$pci%n dentro de $n bloA$e tryGcatcJ+
"+ Dentro del bloA$e catcJ, comprobar mediante 92ssert: A$e la eLcepci%n
interceptada es la A$e esperbamos, por eBemplo, comparando el mensaBe de la
eLcepci%n con el valor esperado+
*+ LanDar Jacia f$era la eLcepci%n, para A$e si&a s$ c$rso y el frameForZ de test la
detecte+ Si no la lanDramos, el test dar>a 9failed:+
#n la ;i&$ra 6G2? podemos ver $n eBemplo
(5:ur- 9I2$H Como comprobar las eLcepciones en 5S'est
7Test8et+od9
7E4pectedE4ception(typeo((&ystem.Ar$mentE4ception!!9
p$blic void Acco$nN$mber8a4.en+t)s;=(!
{
try
{
DanEAcco$nt testAcco$nt " new DanEAcco$nt(//, //, //, /;<>?FG;<>?FAHB=B/!#
1

catc+ (&ystem.Ar$mentE4ception e!
{
Assert.AreEC$al(/nImero de c$enta/, e.ParamName!#
t+row e#
1
1


P&ina !( de !)*
9.2.4. NCover
Dado A$e la versi%n Professional de /is$al St$dio 2!2 no incl$ye la f$nci%n de Code
Coera"e, para poder se&$ir en porcentaBe de c%di&o c$bierto por n$estros test, Jemos
tenido A$e rec$rrir a aplicaciones de terceros+
<na de las ms completas A$e podemos encontrar para esta f$nci%n es 4Cover, A$e,
adems, es compatible con 4Depend, A$e l$e&o comentaremos+ Sin embar&o, 4Cover es
en la act$alidad $na aplicaci%n comercial A$e tan solo incl$ye $na versi%n de pr$eba de
" d>as, absol$tamente ins$ficiente para n$estro proyecto+
Como alternativa, p$dimos localiDar la Jerramienta 'estDriven+4et
66
, $na Jerramienta
para &estionar los proyectos 'DD, facilitando $n c%modo interfaD para la eBec$ci%n y
se&$imiento de los test, A$e inte&ra $na versi%n anti&$a de 4Cover+ 'ras varios d>as de
pr$eba, p$dimos constatar A$e esta versi%n limitada no es compatible con 4Depend, por
lo A$e no p$dimos inte&rarla con el resto de mEtricas de est$dio+ Sin embar&o, dispone
de $n interfaD en /is$al St$dio A$e permite Jacer $n completo se&$imiento de la
cobert$ra del c%di&o por los tests+
I0/t-9-04o T3/tDr5@30
La versi%n Personal de 'estDriven+4et es &rat$ita para entornos de est$diantes+ #l
instalador es fcilmente descar&ado desde s$ p&ina Feb, tras la eBec$ci%n de Este,
A$eda instalado como $n addGin inte&rado dentro de /is$al St$dio
(5:ur- 9I29. 'estDriven y 4Cover inte&rados den /is$al St$dio 2!"
U/-04o NCo@3r
'ras lanDar 4Cover se realiDa la comprobaci%n de cobert$ra de c%di&o, y mediante s$
4Cover#Lplorer podemos localiDar c$alA$ier c%di&o no c$bierto por los test+


P&ina !6 de !)*
(5:ur- 9I3). La Jerramienta 4Cover#Lplorer en f$ncionamiento

4Cover#Lplorer contiene $n c%modo nave&ador a travEs del c$al, y &$iado por c%di&os de
color, podemos acceder a c$alA$ier p$nto de n$estro c%di&o y comprobar si est c$bierto
por $n test+
#n la ;i&$ra 6G" podemos encontrar $n error m$y comIn al iniciar el desarrollo en 'DD,
p$es al crear $na clase A$e necesitamos $sar, podemos cometer el error de completarla
con propiedades (para acceder a s$s campos privados) A$e aIn no Jan sido testeados+ 2l
lanDar con re&$laridad esta Jerramienta nos ase&$ramos de mantener $n CodeCovera&e
del !S+
9.2.5. NDepend
4Depend
6)
es $na potent>sima Jerramienta profesional A$e podr>amos definir en dos
frases A$e $tiliDan en s$ p&ina FebH
48a+e #our /2et Code Geauti&ul5
4Ac.iee .i".er /2et code qualit#5
4Depend se inte&ra en /is$al St$dio y permiteH
5onitoriDar la evol$ci%n del c%di&o a travEs de ms de ?2 mEtricas
6?

/is$aliDar la arA$itect$ra del softFare eLplorando las dependencias entre
ensamblados y tipos a travEs de &rafos y matrices de dependencias
66


P&ina !) de !)*
Interro&ar al c%di&o mediante sentencias LI4R
!
+ DicJas sentencias se p$eden
convertir en re&las de comprobaci%n A$e lanDan avisos c$ando no son c$mplidas+
Desde la versi%n (, salida en oct$bre de este aCo 2!", y posterior al inicio de este
proyecto (A$e $tiliDa 4Depend *+(), incl$ye se&$imiento a travEs de &rficas de
tendencias
!!
+
0epresentaci%n de varios dia&ramas A$e refleBan la compleBidad del c%di&o, as>
como s$ nivel de abstracci%n y posible inestabilidad
!2
+
2 lo lar&o del desarrollo de este proyecto Je aprendido a apreciar en todo s$ valor la
tremenda $tilidad de esta Jerramienta en s$ enorme variedad y compleBidad+ Sin
embar&o, desde $n principio se defini% s$ $so en este ';G tan solo para Jacer el
se&$imiento y eval$aci%n del c%di&o a travEs de mEtricas+ ;$e esta la raD%n por la A$e se
desarrollo, Jaciendo $so de la 2PI de 4edepend, la Jerramienta sencilla llamada
4Depend 5etrics 0eporter, para poder presentar &rficas de evol$ci%n de las mismas,
f$ncionalidad A$e la versi%n *+(, la Inica disponible al inicio de proyecto, no ten>a+
I0/t-9-25A0 43 ND31304
Simplemente facilitando $n eGmail se p$ede descar&ar $na versi%n de pr$eba de !* d>as
completamente f$ncional+ #n n$estro caso, tras $sarlo $n tiempo, p$dimos comprobar
A$e se aB$staba perfectamente a las necesidades del proyecto y nos p$simos en contacto
con s$ departamento de atenci%n al cliente, A$e nos amablemente nos Ja facilitado $na
licencia Academic *ponsor por el tiempo de d$raci%n del proyecto, Jabiendo accedido
incl$so en $na ocasi%n a la eLtensi%n de s$ fecJa de cad$cidad c$ando se prod$Bo $n
retraso A$e impidi% presentar el presente ';G en septiembre+
(5:ur- 9I31. Instalador de 4Depend


P&ina !? de !)*
La instalaci%n es a travEs de $n c%modo interfaD+ Las librer>as y licencia A$edan montadas
en $n directorio a n$estra elecci%n, A$e deberemos recordar p$es los eBec$tables de todo
desarrollo basado en la 2PI de 4Depend deben de $bicarse en dicJa carpeta
(u025o0-,530to 43 ND31304
<na veD instalado, si se eli&e la inte&raci%n completa, se accedern a s$s f$nciones a
travEs del menI principal de /is$al St$dio
(5:ur- 9I32. #l 4Depend inte&rado en /is$al St$dio

<na veD instalado, podemos crear $n proyecto 4Depend y asociarlo a la sol$ci%n activa,
definiendo los parmetros del mismo teles como ensamblados A$e se A$ieren
monitoriDar, caracter>sticas del anlisis A$e se desea realiDar (por eBemplo, si deseamos
&$ardar Jist%rico de los mismos o efect$ar 9code diff:
!"
) y la manera en A$e se desea A$e
se presenten los res$ltados en los informes ='5L+
Cada veD A$e abramos la sol$ci%n, 4Depend presentar dentro de /is$al St$dio los
res$ltados de las re&las A$e Jayamos definido mediante CRLI4R, y abrir $na ventana en
el nave&ador con el informe ='5L A$e Jayamos definido en la confi&$raci%n del proyecto
4Depend+ 'ambiEn podemos ordenar el anlisis y ver $n res$men del Iltimo desde $n
icono inte&rado en la parte inferior derecJa de /is$al St$dio+


P&ina !6 de !)*
(5:ur- 9I33. #Bec$tando $n anlisis de c%di&o desde 4Depend
4Depend incl$ye adems $na completa Jerramienta llamada /is$al 4Depend A$e inte&ra
todas s$s f$ncionesH
(5:ur- 9I3. /is$al 4Depend


P&ina !! de !)*
MGtr52-/ 30 ND31304
4Depend dispone de todas las mEtricas de las A$e Jablamos d$rante la eLposici%n sobre
la Calidad del C%di&o (coJesi%n, acoplamiento, compleBidad ciclomtica, l>neas de
c%di&oK), pero, adems nos da acceso, entre s$s ?2 mEtricas, a otras realmente
interesantesH
MGtr52-/ 43 A2o19-,530to
A//o25-t5o0 B3t=330 C9-//3/ JABTK. La 2sociaci%n entre clases de $na clase o
estr$ct$ra partic$lar es el nImero de otros tipos directamente $sados en el
c$erpo de s$s mEtodos+
T?13 R-0L. #l valor de esta mEtrica se calc$la aplicando el a&oritmo Pa&e0anZ
!*

de Goo&le sobre el &rafo de dependencias entre clases+ =a sido ponderado para
A$e el valor medio de esta mEtrica sea !+ Los tipos con $n alto 'ype0anZ deben
ser especialmente vi&ilados debido s$ relevancia+
Nu,>3r o< O@3r9o-4/. #l nImero de sobrecar&as de $n mEtodo+ Si $n mEtodo no
est sobrecar&ado, este valor es !+ 'ambiEn se aplica a constr$ctores+ <n mEtodo
sobre el A$e se Jan JecJo ms demasiadas sobrecar&as (por eBemplo, 6), res$lta
dif>cil de mantener y refactoriDar, y es $n posible s>ntoma de $na acoplamiento
eLcesivo+
I0/t->595t?JIK. La inestabilidad es el ratio entre el acoplamiento eferente y el
acoplamiento total
I b CeW(CaiCe)
#s indicador de la resiliencia del ensamblado ante el cambio+ #l valor de esta
mEtrica va de (totalmente estable, p$es no depende de nadie) a ! (totalmente
inestable, p$es depende completamente del eLterior)+ <na alta 9inestabilidad: no
es mala, si la clase no es abstracta, como vemos en la ;i&$ra 6G"(+
MGtr52-/ 43 A>/tr-225A0
A>/tr-2t03//JAK. La abstracci%n de $n ensamblado es el ratio entre el nImero de
tipos abstractos (clases e interfaces) sobre el nImero de tipos internos de la clase+
S$ ran&o va ($n ensamblado absol$tamente concreto) a ! (formado tan solo por
abstracciones)
D5/t-023 <ro, M-50 S3Qu3023. Los valores individ$ales de abstracci%n o
inestabilidad no son indicativos de problemas, pero s$ combinaci%n s> nos avisa de
ellos+ Definimos la Distancia sobre la Sec$encia principal como la distancia
perpendic$lar normaliDada sobre la l>nea 2iIb!, A$e llamamos secuencia principal+
#sta mEtrica nos ay$da a desc$brir si eListe $n eA$ilibrio entre la abstracci%n y la
inestabilidad, como podemos observar en la ;i&$ra 6G"(+ <n valor por encima de
,) s$ele ser indicativo de problemas+


P&ina !!! de !)*
(5:ur- 9I35. 2bstraccion e Inestabilidad+ Distancia sobre la sec$encia principal

<n interesante art>c$lo sobre como aplicar las mEtricas de 4Depend a $n est$dio de
acoplamiento lo podemos ver en el art>c$lo 9Code metrics on co$plin&, dead code, desi&n
flaFs and reGin&eneerin&
!(
de PatricZ SmacJia

MGtr52-/ 43 CoB3/5A0
R39-t5o0-9 CoB3/5o0J&K. La coJesi%n relacional es el nImero de relaciones
internas por tipo+ Sea 0 el nImero de relaciones entre tipos A$e son internas al
ensamblado (no conectadas a tipos eLternos al ensamblado)+ Sea 4 el nImero de
tipos del ensamblado+ #ntonces
= b (0i!)W4
Ael X: e7tra eita que HY cuando 2Y:B
La coJesi%n relacional representa la relaci%n A$e tiene en ensamblado entre todos
s$s tipos+ Dato de las clases dentro de $n ensamblado deber>an estar
normalmente f$ertemente relacionadas, la coJesi%n deber>a ser alta+ Por otra
parte, si es demasiado alta podr>a Jaber eLcesivo acoplamiento+ <n ran&o
aceptable ser>a de !+( a *++ /alores f$era del mismo podr>an res$ltar
problemticos+


P&ina !!2 de !)*
MGtr52-/ r3<3r30t3/ - C93-0 Co43
IL N3/t50: D31tB. La prof$ndidad de anidamiento es el nImero mLimo de
mbitos encaps$lados A$e podemos encontrar en $n mEtodo+ Prof$ndidades
mayores a * son dif>ciles de mantener y refactoriDar+ Si lle&a a ?, nos encontramos
con $n problema &rave de claridad de c%di&o
Otr-/ ,Gtr52-/ 50t3r3/-0t3/
Nu,>3r o< CB594r30JNOC)H #l nImero de JiBos es el nImero de s$bclases derivada
de $na clase dada, indpendientemente de s$ nivel dentro del rbol de Jerencia+
#n el caso de interfaces, es el nImero de clases A$e lo implementan+
D31tB o< I0B3r5t-023 Tr33 JDITK. La prof$ndidad en el rbol de Jerencia es c$enta
el n$mero de clases base desde la clase act$al Jasta System+,bBect, por lo A$e
DI'db! siempre+ <n DI' demasiado alto s$elen ser dif>ciles de mantener+
L3@39. #sta mEtrica est definida para ensamblados, espacios de nombres, tipos y
mEtdodos, y se define, por eBemplo, para ensamblados, como si&$eH
o Level H #l namespace no $sa nin&In otro namespace
o Level !H #l namespace solo $sa directamente espacios de nombres
definidos en ensamblados de terceras partes+
o Level !i (5aL Level de los ensamblados A$e $sa directamente)
o Level 4W2H #l espacio de nombres se ve env$elto en $n ciclo de
dependencia
#sta mEtrica ay$da a clasificar los elementos de c%di&o en alto, medio y baBo nivel,
y, al mismo tiempo, perimite detectar dependencias c>clicas+
(5:ur- 9I3". La mEtrica Level
;$enteH PatricZ SmaccJia (Code-eter+com)


P&ina !!" de !)*
4$evamente $n art>c$lo m$y interesante, llamado 9Layerin&, tJe Level 5etric and
tJe Disco$rse of 5etJod:
!6
, de PatricZ SmaccJia, nos ay$da a sacar partido de
esta mEtrica+
Como ya comentamos, m$cJas de estas mEtricas se p$eden obtener a varios nivelesH por
ensamblado, espacio de nombres, tipos o mEtodos, lo A$e permite prof$ndiDar el est$dio
Pero la &ran potencia de 4Depen estriba en poder inte&rar dicJas mEtricas con sentencias
de cons$lta LI4R sobre el c%di&o, lo A$e le da $na plena libertad al $s$ario para crear las
s$yas propias+ =emos JecJo $so de esta capacidad para crear mEtricas definidas por el
$s$ario en 4Depend 5etrics 0eporter+
A4Qu5/52;o0 43 9-/ ,Gtr52-/ ND31304
R$iD la f$ncionalidad A$e ms interesante nos res$lt% de 4Depend es la posibilidad de
almacenar el Jist%rico de todos los anlisis realiDados+
4Depend crea $na carpeta, $bicada en el directorio la ra>D de la sol$ci%n, donde, en cada
anlisis, v$elca todo lo necesario para presentar $n informe en ='5LH snippets en
Bavascript, JoBas de estilo y plantillas personaliDables, ficJeros @5L con los res$ltados de
las mEtricas y otros valoresK Cada veD A$e realiDamos $n n$evo anlisis, si se Ja realiDado
transc$rrido desde el anterior $n tiempo m>nimo confi&$rable, los Iltimos res$ltados
eListentes son almacenados $n carpetas de Jist%ricos antes de act$aliDar los datos+
(5:ur- 9I37. 4Depend 5etrics 0eporter


P&ina !!* de !)*
#n $n principio el proyecto iba a Jacer $so de dicJos ficJeros @5L para alimentar $na
base de datos, A$e desp$Es podr>amos cons$ltar para obtener mEtricas y representar
&rficas, pero finalmente, tras al&$nos eGmail intercambiados con los desarrolladores, se
nos recomend% Jacer $so de la 2PI de 4Depend para acceder directamente a dicJa
informaci%n, A$e se &$arda en $n ficJero llamado 9/is$al4Depend+bin: A$e se crea en
cada anlisis+
Como res$ltado de ello se cre% la aplicaci%n 4Depend /is$al 0eporter (;i&$ra 6G")), a
travEs de la c$al podemos ver directamente las mEtricas de c%di&o y representar
res$ltados+
Desde esta aplicaci%n tenemos acceso a todo el Jist%rico de mEtricas reco&idas d$rante el
desarrollo del proyecto, p$diendo rec$perar mEtricas A$e representamos t$b$larmente,
as> como &rficos Jist%ricos de l>neas e Jisto&ramas de frec$encias+


P&ina !!( de !)*
10. RESULTADOS DE LA EVALUACION DEL CDIGO
10.1. Sobre la metodologa de evaluacin
Para eLponer los res$ltados del est$dio tomaremos como &$>a la c$esti%n A$e
planteamos al principio de n$estra memoriaH NR$e es el R$ality CodeO
4os centraremos, por tanto, en eval$ar, $no a $no, los elementos A$e consideramos son
el indicativo de la calidad del c%di&o+
Conformidad con los reA$isitos
;iabilidad
Le&ibilidad
;leLibilidad y re$sabilidad
Siempre A$e nos sea posible, $tiliDaremos las mEtricas obtenidas a travEs de 23epend
8etrics 6eporter como base y soporte de la ar&$mentaci%n+ #n ocasiones $tiliDaremos
otros datos como apoyo+
Lo/ :r8<52o/ 43 ND31304 M3tr52/ R31ort3r
La Jerramienta diseCada para reco&er y eLponer las mEtricas Ja res$ltado de inestimable
ay$da para el est$dio, especialmente &racias a la posibilidad de crear mEtricas
personaliDadas, A$e Jemos $sado ampliamente para obtener evol$ciones Jist%ricas sobre
valores estad>sticos de mEtricas base+ Los dos tipos de &rfico A$e se Ja definido sonH
&5/to:r-,-/ 43 <r32u3025-/
#l valor p$nt$al de $na mEtrica para $n solo elemento de c%di&o no es demasiado
representativo+ Por eBemplo, Nde A$E nos sirve saber eLactamente c$al es el LC,5 de la
clase (Hnoice)O+ N#s s$ficiente $na media de la mEtrica de todas las clasesO #s Itil, s>,
especialmente si disponemos de mLimos, m>nimos y desviaciones+ Pero, lo
verdaderamente interesante es ver los LC,5 de todos los tipos del ensamblado+ <na
tabla de valores nos presenta toda la informaci%n, pero ser>a demasiado eLtensa y
farra&osa de maneBar+
Para poder analiDar comparativamente todos los res$ltados de $na mEtrica partic$lar
Jemos decidido $sar $n Jisto&rama de frec$encias para cada mEtrica, en los A$eH
E%e &' @l alor de la mtrica


P&ina !!6 de !)*
E%e (' La frec$encia con A$e dicJo valor se repite+ #n n$estro caso dicJa
frec$encia nos indica c$antos elementos de c%di&o, para la mEtrica en est$dio,
tienen ese valor+
2s>, con $n solo vistaDo, podemos eval$ar &lobalmente $na mEtrica de c%di&oH c$al es el
valor ms repetido (moda), mLimos y m>nimos, en A$E ran&o se a&r$pan, si Jay
dispersi%n+
/eamos, por eBemplo, al&o tan simple como el nImero de l>neas de todos los mEtodos del
ensamblado+
(5:ur- 1)I1. =isto&rama de frec$encias de l>neas de c%di&o de todos los mEtodos en el ensamblado

Como podemos observar, con diferencia el valor A$e ms aparece es !+ #s decir, A$e los
mEtodos tienen, en s$ &ran mayor>a (ms de 2* de ellos), $na sola instr$cci%n+ 5as
tarde disc$tiremos el por A$E de la enorme prevalencia de este valor+ Pero, lo A$e si
podemos apreciar, de $n solo vistaDo, es A$e el res$ltado Ja sido A$e los mEtodos son
principalmente m$y peA$eCos+
E@o9u25A0 B5/tAr52-
Con la anterior &rfica podemos analiDar $n momento p$nt$al en el estado del c%di&o, en
partic$lar lo $saremos para ver el res$ltado final+ Pero dicJo valor p$ede ser prod$cto de
$na serie de refactoriDaciones finales+


P&ina !!) de !)*
#sto es lo A$e normalmente oc$rre en desarrollos A$e no son 'DDH el c%di&o va
de&radndose Jasta A$e se Jace tan imposible de mantener A$e reA$iere $na &ran
refactoriDaci%n+ <na &rfica de 9calidad de c%di&o: mostrar>a $na serie de picos a lo lar&o
de s$ desarrollo+
(5:ur- 1)I2. 0efactoriDaciones en $n desarrollo clsico

Sin embar&o, el 'DD, al estar el c%di&o en permanente refactoriDaci%n, n$nca debern
lle&ar a formarse dicJos picos+ Pasados los inicios del desarrollo, en los A$e la escasa
cantidad de c%di&o prod$ce &randes variaciones en la calidad con cada ciclo de test, se
deber>a prod$cir $na estabiliDaci%n con peA$eCos dientes de sierra y li&eras tendencias+
#sto Iltimo es lo A$e b$scaremos en los &rficos de tendencias
Sin embar&o, Jemos de Jacer $na consideraci%n final+ #n el act$al desarrollo las Iltimas
aportaciones f$eron las tipos A$e conforman la definici%n del esA$ema para los env>os
@5L del S#P2, m$y compleBos y con $n diseCo m$y espec>fico (sin mEtodos, con m$cJos
parmetros y m$y eLtensos) A$e desvirt$aban los res$ltados de las mEtricas+ ;inalmente
se tom% la decisi%n de separar dicJas clases a $n ensamblado eLterno, $na biblioteca a la
A$e Jacer referencia+ Las medidas as> obtenidas son ms reales, pero en la evol$ci%n
Jist%rica de ciertas mEtricas se p$ede $na variaci%n final importante+
10.2. Resultados
10.2.1. Conformidad con los requisitos
D$rante la fase de anlisis, establecimos los reA$isitos en forma de Jistorias de $s$arios+
Con la ay$da del -DD y a Jerramienta SPec;loF convertimos dicJas Jistorias de $s$ario
en escenarios, y para cada $no de ellos se defini% $n test de aceptaci%n+
#l JecJo de A$e todos estos test de aceptaci%n, al final del proyecto, se enc$entren en
verde, implica A$e todos los reA$isitos de $s$ario reco&idos en el mismo Jan sido
perfectamente c$biertos+

Tiempo
d
e
g
r
a
d
a
c
i
n

d
e
l

c
d
i
g
o
refactorizaciones
Lmite de
inoperancia
Tiempo
d
e
g
r
a
d
a
c
i
n

d
e
l

c
d
i
g
o
refactorizaciones
Lmite de
inoperancia


P&ina !!? de !)*
(5:ur- 1)I3. 'odos los test de aceptaci%n de los escenarios -DD 9en verde:

Ynicamente en el caso en A$e dicJas Jistorias de $s$ario y escenarios no J$bieran sido
correctamente reco&idos, podr>amos ar&$mentar no conformidad con los reA$isitos,
peroH
DicJas Jistorias de $s$ario y escenarios f$eron JecJos en colaboraci%n con el
cliente, y ser El mismo, con cada entre&a de $na iteraci%n, A$ien podr
comprobar A$e se JiDo eLactamente lo A$e con El se acord%+
Si, a posteriori, el cliente considera A$e faltaba al&o en la Jistoria de $s$ario, es
fcil de aCadir+
#n c$alA$ier caso lo A$e estamos est$diando es si 'DD prod$ce meBor
conformidad con los reA$isitos+ 1, ciertamente, 'DD &arantiDa el c$mplimento de
lo A$e aparece en los test de aceptaci%n, independientemente de si, en el
anlisis, las Jistorias Jan sido incompletas
10.3. Fiabilidad (Tested Code)
#l c%di&o en 'DD est !S testado, simple y llanamente+
#n otras metodolo&>as res$lta tremendamente compleBo lle&ar a este porcentaBe de
cobert$ra+ Debemos, en c$alA$ier caso tener en c$enta A$e !S de cobert$ra no
implica ! falta de fallos+ P$ede A$e eListan escenarios no previstos+ Pero el desarrollo
&$iado por test es tambiEn llamado 9desarrollo &$iado por eBemplos:+ #s decir,


P&ina !!6 de !)*
codificamos en base a eBemplos, solo lo A$e los eBemplos nos eLi&e+ Si Jemos sido
s$ficientemente
(5:ur- 1)I. C%di&o de la aplicaci%n !S c$bierto por tests

#n otras metodolo&>as res$lta tremendamente compleBo lle&ar a este porcentaBe de
cobert$ra+ Debemos, en c$alA$ier caso tener en c$enta A$e !S de cobert$ra no
implica !S falta de fallos+ P$ede A$e eListan escenarios no previstos+ Pero el desarrollo
&$iado por test es tambiEn llamado 9desarrollo &$iado por eBemplos:+ #s decir,
codificamos en base a eBemplos, solo lo A$e los eBemplos nos eLi&en+
Por tanto, si el pro&ramador Ja sido met%dico, si&$iendo las pa$tas A$e comentamos en
la disciplina y reA$erimientos a la Jora de desarrollar 'DD, podemos afirmar A$e nos
encontramos ante c%di&o casi !S rob$sto+
10.4. Legibilidad (Clean Code)
La le&ibilidad es Jasta cierto p$nto $n elemento s$bBetivo, dif>cilmente medible+ 2l&$nas
cosas son simplemente observables como el $so de nombres con si&nificado, o mEtodos
concisos y clarosH
#n el eBemplo de la ;i&$ra !G( marcamos $na fact$ra como pendiente de pa&o
9'o-ePaid: si le A$edan recibos al cobro y no le A$eda nin&$no impa&ado+ #s m$y sencillo
de se&$ir, p$es $samos nombres con si&nificado, y los detalles de implementaci%n de
cada $na de las tareas de la inicialiDaci%n las realiDa $n mEtodo diferente (*in"le
6esponsabilit# <rinciple)+


P&ina !2 de !)*
(5:ur- 1)I5. #Bemplo de 9Clean Code: en la aplicaci%n desarrollada

#n al&$nos casos Jay A$e lle&ar al compromiso de decidir si res$lta ms claro $na
instr$cci%n no demasiado compleBa o eLtraerla a $n mEtodo eLterno, p$esto A$e
contin$as llamadas Jacen el c%di&o a veces demasiado disperso+ 2 veces mirar desde
otras %pticas ms all del Clean Code ay$da+ P+#+H Nme conviene eLtraer el mEtodo por
c$estiones de refactoriDaci%n (principios S0P, eLceso de acoplamientoK)
DicJo todo esto, NA$E mEtricas p$eden ay$darnos a comprobar la claridad el c%di&oO
/amos al&$nas+
T-,-Oo 43 9o/ ,Gto4o/
5irando este Jisto&rama de la ;i&$ra !G6 podemos observar A$e como media, vemos
A$e los mEtodos tienen m$y pocas l>neas de c%di&o, se&In las estad>sticas, $na media de
2,2 lineas, con $na desviaci%n de 2,*+ #n c$alA$ier caso Jemos de prestar atenci%n a
al&$nos datos A$e nos m$estra el Jisto&ramaH
=ay $na enorme prevalencia de mEtodos con $na sola l>nea de c%di&o+ Si bien Jay
m$cJos mEtodos con estas caracter>sticas, Jay A$e tener en c$enta A$e, entre
ellos estan los 9&etters: y 9setters: de las propiedades+
=ay dos mEtodos, de !6 y 22 l>neas, A$e desvirtIan el &rfico+ Son dos mEtodos
relacionados con la creaci%n del ficJero S#P2+
p$blic class )nvoiceJ Dase)nvoice
{
KK

p$blic void &et)nvoiceToDePaid)(HasNoLnpaidDills(!
{
i( ()nvoiceHasDillsTo*ollect(! 00 )nvoiceHasNoLnpaidDills(!!
t+is.invoice&tate " )nvoicePayment&tate.ToDePaid#
1

private bool )nvoiceHasNoLnpaidDills(!
{
DictionaryMstrin, DillN bills*ollection " t+is.invoiceDills#
var $npaidDills " bills*ollection
.:+ere(bill "N bill.Oal$e.PaymentRes$lt "" Dill.DillPaymentRes$lt.Lnpaid!#
ret$rn ($npaidDills.*o$nt(! "" =!#
1

private bool )nvoiceHasDillsTo*ollect(!
{
DictionaryMstrin, DillN bills*ollection " t+is.invoiceDills#
var to*ollectDills " bills*ollection
.:+ere(bill "N bill.Oal$e.PaymentRes$lt "" Dill.DillPaymentRes$lt.To*ollect!#
ret$rn (to*ollectDills.*o$nt(! %" =!#
1
KK
1


P&ina !2! de !)*
(5:ur- 1)I". =isto&rama de frec$encias del nImero de l>neas de c%di&o
para todos los mEtodos del ensamblado
Por otra parte, en la evol$ci%n Jist%rica de la media de nImero de l>neas por mEtodo,
(;i&$ra !G)) Esta se Ja mantenido relativamente estable, con $na tendencia de baBada
final debida a la anteriormente nombrada implementaci%n del S#P2, c$yas clases no
incl$>an mEtodos, sino tan solo campos y propiedades (L,Cb!)+ Desp$Es de traspasar
dicJas clases a otro ensamblado, vemos A$e el res$ltado final v$elve al estabiliDado 2,2+
(5:ur- 1)I7. #vol$ci%n Jist%rica de la media de la mEtrica L,C


P&ina !22 de !)*
Co,193754-4 C529o,8t52-
NC$ntas decisiones anidadas deben de tomarse en los mEtodosO #n el Clean Code se
intenta evitar al mLimo el $so de sentencias condicionales (ifWelse g sFitcJWcase),
factoriDndose siempre A$e sea posible en base a polimorfismo+ #n el Jisto&rama de la
podemos observar A$e, el c%di&o lineal, sin $na sola decisi%n, sin $n solo 9if:, es decir de
compleBidad b !, es lo comIn+ #n al&$nos mEtodos rec$rrimos al condicional para al&$na
comprobaci%n bsica como la del c%di&o del eBemplo, y solo en contad>simas ocasiones
debemos Jacer $so de sentencias sFitJWcase A$e disparan esta mEtrica+
(5:ur- 1)I$. =isto&rama de frec$encias de la CompleBidad Ciclomtica
4$evamente, en el Jistorico, observamos $n comportamiento similar al anterior
(5:ur- 1)I9. #vol$ci%n Jist%rica de la media de la mEtrica CompleBidad Ciclomtica


P&ina !2" de !)*
Pro<u0454-4 43 -054-,530to
N'iene n$estro c%di&o demasiados mbitos anidados, por eBemplo, como res$ltado de
b$cles o sentencias de decisi%nO+ 0ealmente no+ #n la inmensa mayor>a de los mEtodos ni
siA$iera eListen+
(5:ur- 1)I1). =isto&rama de frec$encias de la Prof$ndidad de 2nidamiento

<no de los factores A$e Ja ay$dado Ja obtener esto res$ltado es la incl$si%n de las
sentencias LI4R en /is$al St$dio 2? y +4et ;rameForZ "+(+ Gracias a LI4R las
colecciones implementan, entre otras f$nciones ms compleBas, $n mEtodo +Select A$e
permite recorrerlas sin necesidad de $n b$cle 9foreacJ:+
(5:ur- 1)I11. #vol$ci%n Jist%rica de la media de la mEtrica Prof$ndidad de 2nidamiento


P&ina !2* de !)*
#n el Jist%rico de la ;i&$ra !G!! volvemos a observar el mismo comportamientoH $n
inicio irre&$lar, $na estabiliDaci%n y l$e&o $na tendencia (en este caso de f$erte baBada) al
implementar las clases de S#P2, A$e, como solo incl$yenmEtodos 9&etter: y 9setters:,
baBan el valor de la media+ 'ras s$ escisi%n, volvemos al valor estable A$e finalmente
vemos des&losado en el Jisto&rama+
10.5. Flexibilidad y Reusabilidad (Principios OOD)
La fleLibilida y la re$sabilidad se cons$&$en si&$iendo los principios S,LID del ,,D, A$e
recordemos, sonH
JSK SRP I S50:93 R3/1o0/->595t? Pr5025193
1)7
. <na clase debe tener $na <4IC2
responsabilidad+
JOK OCP P O130 C9o/34 Pr5025193
1)$
. <na clase deber>a estar abierta a s$
eLtensi%n, pero cerrada a s$ modificaci%n
JLK LSP P L5/Lo@ Su>/t5tut5o0 Pr5025193
1)9
. <na clase derivada deber>a poder
s$stit$ir a $n s$ clase base+
JIK ISP P I0t3r<-23 S3:r3:-t5o0 Pr5025193
11)
. 0ealiDar $n interfaD espec>fico para
cada cliente es meBor A$e no solo &enErico+
JDK DIP P D31304302? I0@3r/5o0 Pr5025193
111
. Las clases deber>an depender de
abstracciones, no de implementaciones+
#s m$y dif>cil est$diar cada principio en base a mEtricas, pero Jay conceptos A$e las
relacionan, de los A$e ya Jemos Jablado eLtensamente c$ando eLp$simos las mEtricas+
CoJesi%n
2coplamiento
2bstraci%n
10.5.1. Cohesin
'remendamente relacionados con el principio de responsabilidad Inica, vemos A$e los
mEtodos deben ser f$ertemente coJesionados dentro de $na clase+ 1a vimos A$e el
tamaCo de los mEtodos es normalmente peA$eCo, lo A$e res$lta $n indicio de coJesi%n+
Pero tenemos mEtricas espec>ficas, como la de (;ac+ ,& Co.esion ,& 8et.ods) A)*+,B/ Sin
embar&o, $na eLcesiva coJesi%n no es siempre b$ena, p$es p$ede indicar sobreG
acoplamiento en las clases+ Para ello podemos est$diar la mEtrica 90elational
CoJesion:-./0


P&ina !2( de !)*
L-2L o< CoB3/5o0 O< M3tBo4/ JLCOMK
#n n$estro caso est$diaremos $na mEtrica derivada, LC,5G=S (de =endersonGSellers),
A$e fl$ctIa entre los valores ^G2_+ <n valor de indica perfecta coJesi%n, y $n valor
s$perior a ! indica A$e podemos tener problemas con el mEtodo+
#l al&oritmo $tiliDado para el clc$lo de la mEtrica esH
LC,5 b ! g (s$m(5;)W5j;)
LC,5 =S b (5 g s$m(5;)W;)(5G!)
DondeH
5 es el nImero de mEtodos en la clase (estticos o de instancia, incl$idos
constr$ctores, 9&etters: y 9setters:, eventos, y mEtodos 9dispose:)
; es el nImero de campos de instancia en la clase
5; es el nImero de mEtodos de clase A$e acceden a $n campo de instancia en
partic$lar
S$m(5;) es la s$ma de todos los 5; de todos los campos de instancia
La idea es A$e $na clase es completamente coJesiva si todos los mEtodos $san todos los
campos de instancia, con lo A$e s$m(5;)b5j; y, por tanto, LC,5b y LC,5=S b
#ste al&oritmo tiene al&$nos problemas con las transitividades+ #n c$alA$ier caso
veremos los res$ltados de LC,5G=S AHenderson-*ellers, :CCDBOCP, A$e fl$ctIa entre los
valores ^G2_+ <n valor de indica perfecta coJesi%n, y $n valor s$perior a ! indica A$e
podemos tener problemas con el mEtodo+
(5:ur- 1)I12H =isto&rama de frec$encia de LC,5G=S


P&ina !26 de !)*
Como podemos observar en la ;i&$ra !G!2, la inmensa mayor>a de los mEtodos tienen
$na perfecta coJesi%n, y nin&$no s$pera el $mbral de peli&ro A$e es el valor !+
(5:ur- 1)I13. #vol$ci%n Jist%rica de la media de la mEtrica LC,5=S
para todas las clases del ensamblado
Se repite en la ;i&$ra !G!" el esA$ema de Jist%ricos anterioresH inestabilidad inicial,
estabiliDaci%n alrededor del valor +*, y de&radaci%n A$e se corri&e al eLtraer los tipos del
S#P2+
R39-t5o0-9 CoB3/5o0 J&K
La coJesi%n relacional mide el nImero medio de relaciones internas en $n tipo
Sea 0 el nImero de relaciones entre tipos A$e son internas al ensamblado (es
decir, A$e no conectan con tipos f$era del ensamblado)+
Sea 4 el nImero de tipos en el ensamblado
=b (0i!)W4
Ael X: eita que HYI cuando 2Y:B
(5:ur- 1)I1. /alor de la CoJesi%n 0elacional para el ensamblado principal


P&ina !2) de !)*
#sta mEtrica es $n indicativo de la relaci%n A$e tiene el ensamblado con s$s tipos, y nos
ay$da, como antes comentamos, a detectar acoplamientos eLcesivos, se considera A$e
$n valor correcto es el A$e oscila entre^!+(, *_, por lo A$e n$estro ensamblado &oDa de $n
sal$dable 2+!" a este nivel+
(5:ur- 1)I15. #vol$ci%n Jist%rica de la mEtrica CoJesi%n 0elacional

Como era de esperar, i&$al evol$ci%n A$e en las anteriores
10.5.2. Acoplamiento
Las mEtricas bsicas de acoplamiento son el 2coplamiento 2ferente y el 2coplamiento
#ferente
(5:ur- 1)I1". 2coplamiento 2ferente y #ferente
#n n$estro est$dio revisaremos las mEtricas de acoplamiento a nivel de clases y de
mEtodos+
Las medidas de acoplamiento nos permiten localiDar al&$nos mEtodos o clases A$e
ten&an demasiadas responsabilidades, ya sea porA$e Jacen demasiadas llamadas al
eLterior o porA$e son invocadas por $n nImero eLcesivo de otros mEtodos o clases+
'ambiEn nos ay$dan a desc$brir si eListe &ran dependencia a nivel de detalles de
implementaci%n entre dos clases+ C$ando eListe acoplamiento a este nivel termina por
inc$mplirse el ,penWClose Principle (,CP)+

Code
Element
Efferent
Coupling
Afferent
Coupling
Code
Element
Efferent
Coupling
Afferent
Coupling


P&ina !2? de !)*
Por Iltimo, valores de 2ferent Co$plin&b indican la eListencia del llamado 9Dead Code:, o
c%di&o inaccesible, A$e p$ede s$r&ir tras realiDar las refactoriDaciones+
A2o19-,530to A<3r30t3 JA<<3r30t Cou1950:K
A nivel de m1todos
Lle&ados a este p$nto, Jemos de decir A$e las mEtricas A$e c$entan el nImero de veces
en A$e $n mEtodo es llamado (2coplamiento 2ferente y 'ype 0anZ) presentan $n &rave
problema para n$estro est$dioH
Las mEtricas A$e se Jan ido adA$iriendo a lo lar&o del desarrollo Jan incl$ido
siempre a los ensamblados de test y de -DD+ #sto implica A$e las veces en A$e $n
mEtodo es llamado incl$yen el nImero de mEtodos de test A$e lo $san,
desvirt$ando completamente el res$ltado, ya A$e no da informaci%n sobre el
acoplamiento real+ Por tanto los &rficos Jist%ricos son irrelevantes+
Por tanto se Ja realiDado al final $n anlisis descartando dicJos ensamblados de test+ Sin
embar&o el res$ltado arroBa $n valor desconcertanteH casi !( mEtodos A$e 9no son
n$nca llamados:+
(5:ur- 1)I17. 2coplamiento 2ferente en los mEtodos del ensamblado

NSi&nifica esto A$e nos encontramos ante $na &ran cantidad de c%di&o inaccesible, de
9Dead Code:O
P4oQ Debemos recordar A$e estamos desarrollando $na librer>a de clases, y adems,
parcial, por lo A$e m$cJos mEtodos no son llamados en nin&In momento, sino A$e Jan


P&ina !26 de !)*
sido implementados para ser llamados desde otras librer>as o desde $n pro&rama
principal A$e Ja&a $so de Esta+
<na veD aclarado este p$nto, podemos observar A$e salvo al&$nos mEtodos de cierta
importancia, en la mayor>a de los casos el 2coplamiento 2ferente es m>nimo, $na b$ena
seCal de independencia y S0P+
A nivel de clases
Con las clases tenemos el mismo problema A$e con los mEtodos a la Jora de est$diar
Jist%ricos, p$es las llamadas desde las clases del test desvirtIan los res$ltados+
4$evamente nos centramos en el anlisis p$nt$al A$e las descarta+
(5:ur- 1)I1$. 2coplamiento 2ferente en los tipos del ensamblado

4os encontramos n$evamente con $na nada despreciable cantidad de clases 9no
llamadas:, y la raD%n es la misma de antes+ ,c$rre en las 9Clases Controladoras:, tales
como (Gills8ana"er), (Hnoices8ana"er), 9DirectDebit0emmitances5ana&er: o (*@<A
8ana"er), A$e estn en lo alto del &rafo de dependencias, o como el (Z8;Validator),
clase de ay$da para la validaci%n de los esA$emas @SD, A$e finalmente solo Jemos $sado
desde los test+
#n el otro eLtremo tenemos $n par de clases, como (Gan+Account) o (Gill), A$e
obviamente son m$y referenciadas en $na biblioteca sobre fact$raci%n y ade$dos
bancarios+
Por lo dems, podemos concl$ir A$e el acoplamiento aferente est bastante controlado, y
n$estras clases no estn demasiado acopladas a este nivel+


P&ina !" de !)*
A2o19-,530to E<3r30t3 JE<<3r30t Cou195:K
A nivel de m1todos
(5:ur- 1)I19. 2coplamiento #ferente en los 5Etodos+ =isto&rama y evol$ci%n de la media

Con respecto al acoplamiento aferente, podemos ver A$e se mantiene controlado+
Podemos observar la misma desviaci%n anteriormente comentada en el Jist%rico,
corre&ida al final+ Casi todos los mEtodos c$mplen el Principio de 0esponsabilidad Inica,
al llamar a m$y pocos otros mEtodos+ Solo en al&$nos casos p$nt$ales se al acoplamiento
aferente se eleva, y $na veD revisados, no res$ltan alarmantes+


P&ina !"! de !)*
A nivel de clases
(5:ur- 1)I2). 2coplamiento eferente en los tipos+ =isto&rama y evol$ci%n de la media

/emos A$e esta mEtrica crece de forma nat$ral, con $na tendencia fiBa, a medida A$e el
c%di&o evol$ciona, p$es van creciendo el nImero de clases implementadas y la relaci%n
entre ellas, especialmente teniendo en c$anta A$e todas ellas forman parte de $n mismo
dominioH la fact$raci%n+ La media se mantiene en niveles relativamente baBos, con $na
moda de *, por lo A$e podemos concl$ir A$e la calidad del c%di&o es correcto se&In esta
mEtrica+
Cabe destacar la eListencia de c$atro valores altos, A$e se corresponden con las clases
9controladoras: A$e fi&$ran en lo alto del dia&rama de dependencias, las mismas A$e


P&ina !"2 de !)*
ten>an $n valor de en la mEtrica aferente+ ,bservamos, por tanto, $na caracter>stica de
las clases 9controladoras:H baBo acoplamiento aferente y alto acoplamiento eferente+ <n
comportamiento esperado y deseable
A/o25-25A0 30tr3 C9-/3/
(5:ur- 1)I21. 2sociaci%n entre Clases+ =isto&rama y evol$ci%n de la media
La asociaci%n entre clases, para $n tipo dado, mide el nImero de miembros de otras
clases A$e $sa directamente en el c$erpo de s$s mEtodos+ #s similar al acoplamiento
aferente, pero, con $na diferencia, c$enta los miembros $sados+


P&ina !"" de !)*
Pon&amos $n eBemploH Los mEtodos de la clase 2 $san a ( mEtodos de la clase -+ Por
tanto, 2 $sa - (acoplamiento aferente b!), y $sa ( mEtodos (2-Cb()+ Por tanto, la mEtrica
2-C prod$ce valores ms altos+ Si esta diferencia es m$y &rande, podr>a ser $n indicativo
de A$e Jay $n alto acoplamiento debido a A$e la clase 2 est entrando en demasiados
detalles de implementaci%n de la clase -+
#n n$estro caso no se aprecia tal eLcesivo acoplamiento, a$nA$e d$rante la
implementaci%n de las clases S#P2 se prod$Bo $na meBora importante (a$nA$e no real) en
la mEtrica+
10.5.3. Abstraccin e Inestabilidad
=ay dos mEtricas A$e se relacionan en el c%di&oH
2bstracci%nH NC$an abstracto es mi ensambladoO DicJa mEtrica se comp$ta como
el ratio entre clases abstractas sobre el total de clases
Abstraccin Y $otal clases abstractas M $otal de clases
InestabilidadH NC$nta resistencia opone mi clase al cambioO DicJa mEtrica se
comp$ta como el ratio del acoplamiento eferente con respecto al acoplamiento
total+ <na clase A$e solo ten&a acoplamiento eferente depende totalmente del
eLterior, es inestable, y no opondr>a demasiada 9resistencia:, p$es, al nadie
depender de ella, podemos modificarla con libertad+
H Y CeMACaXCeB
Por si solas estas dos mEtricas no son demasiado relevantes, pero al combinarlas,
podemos observar estados interesantes en los ensambladosH
<n ensamblado m$y inestable (A$e depende demasiado del eLterior) no tiene
problemas si es poco abstracto
<n ensamblado m$y abstracto debe ser todo lo estable e independiente posible,
se&In el principio ,CP+
<niendo ambos eLtremos tenemos la llamada kL>nea de Sec$encia Principal:
;'nea de *ecuencia <rincipalJ A X H Y:
Podemos $bicar cada ensamblado como $n p$nto en este dia&rama, $sando s$
inestabilidad como coordenada @ y s$ abstracci%n como coordenada 1+ La distancia de
este p$nto, calc$lada sobre dicJa l>nea, ser s$ indicativo de calidad+
#n n$estro caso, estos los valores de abstracci%n, inestabilidad y distancia de la sec$encia
principal de n$estros ensambladosH


P&ina !"* de !)*
E0/-,>9-4o A I D5/t.
0C4GC5embers5ana&emment2pLo&ic +6? +) +*
0C4GCIS,222C$stomerDebitInitiation +6 +)
0C4GC5embers5ana&ement5ocZs !
#Ltension5etJods +62 +6

Si los representamos en $n &rfico, se $bicarn en la esA$ina inferior derecJa, e 9Dona
verde:
(5:ur- 1)I22. 2bstracci%n e Inestabilidad


P&ina !"( de !)*
11. CONCLUSIONES
Lle&ado a este p$nto, cabe recapit$lar, y, A$iD la meBor manera es refleLionar sobre si,
en El, se Jan c$mplido los obBetivos prop$estos+
O>73t5@o 1r50251-9
Con respecto al obBetivo principal del proyecto, A$e era eval$ar la calidad del c%di&o en
proyectos A$e $sen 'DD, la resp$esta, en mi opini%n, m$y clara, es SI+
=emos ar&$mentado A$e el c%di&o &enerado mediante 'DD es de mayor calidad
por p$ra y simple necesidad+ <nas clases A$e se aleBan del paradi&ma S,LID y A$e
no si&$en a pies B$ntillas el Clean Code se convierten en $n verdadero tormento
para el desarrollador A$e contin$amente refactoriDar $n c%di&o en constante
crecimiento+
=emos podido comprobar emp>ricamente en este proyecto la verdad de la
anterior afirmaci%n+ Los res$ltados de todas las mEtricas Jan sido positivos, y se
Jan mantenido as> de principio a fin, d$rante todo el desarrollo+
#n los desarrollos con metodolo&>as no &iles, donde la arA$itect$ra viene
predefinida y el implementador recibe $na 9caBa ne&ra: de la A$e solo le eLi&en
A$e c$mpla con cierta interfaD pIblica, esttica e inm$table, Este se p$ede
permitir c$alA$ier licencia, siempre A$e s$ c%di&o estE debidamente comentado,
claro est+ 5ientras c$mpla con $nos m>nimos de eficiencia, s$ c%di&o p$ede
permitirse ser de c$estionable calidad+ =asta A$e ten&a A$e Jacer cambiosK
'an solo $na p$nt$aliDaci%n+ 5e Ja A$edado tambiEn claro el primer valor del manifiesto
&il, A$e insiste en la necesitad de disponer de pro&ramadores altamente c$alificados en
el a&ilismo+ Sin ellos, o, al menos, $n par de ellos en el eA$ipo A$e ecJen $na mano al
resto (la fi&$ra del 9facilitador: en SC0<5), el pro&reso se Jace terriblemente lento, al
enfrentarse a cada paso, en cada ciclo 'DD, a decisiones importantes dif>ciles de tomar
para $na persona de baBa o mediana competencia+ #s necesario $n &ran dominio del
len&$aBe de pro&ramaci%n en c$esti%n, as> como de refactoriDaci%n y diseCo orientado a
obBetos+ Para $n servidor, bastante oLidado en el desarrollo, el desarrollo Ja res$ltado
tremendamente laborioso, a$nA$e Je de confesar A$e Ja res$ltado m$y &rato
comprobar a travEs de las mEtricas A$e la calidad final del mismo era bastante aceptable+
O>73t5@o/ E/1325<52o/
=ablbamos al comienDo del proyecto, en s$ enfoA$e, de los obBetivos espec>ficos, y
A$iero recordarlos, porA$e, para m>, son la verdadera esencia del proyecto+ #n partic$lar
el primero de ellos


P&ina !"6 de !)*
(or,-r.
o E/ u0 1ro23/o 43 -1r30456-73. Definitivamente, s>+ #n el pr%lo&o comentE
c%mo mi t$tor me embarc% en este viaBe, como me convenci%n de A$e iba
a aprender $n mont%n de cosas+ R$e iba a desc$brir $na forma n$eva,
radicalmente diferente de pro&ramar, y A$e al final se lo a&radecer>a+ 1 Je
aprendido+ 5$cJo+ 1 se lo a&radeDco infinitamente+
o E/ u0 3/tu45o 45482t52o. 2 lo lar&o del proyecto Je desc$bierto cosas A$e
me Jan asombrado y me Jan il$sionado tanto como a mi t$tor+ 2s> A$e
aA$> me tienen Jaciendo proselitismo &il + Con este proyecto, en esta
memoria, intento transmitir a todos las cosas A$e Je aprendido, A$e como
antes diBe, son m$cJas+ #spero A$e sirva de ay$da, de &$>a en los primeros
pasos a aA$ellos A$e A$ieran empeDar a adentrarse en las a&$as del
a&ilismo+ 1, para los A$e estEn mirando desde la orilla, indecisos, les
entren &anas de ecJarse $n b$en cJap$D%n+
I,193,30t-r. R$iD la parte ms desc$idada, p$es se centra m$cJo ms en los
dos anteriores obBetivos+ Pero Je de decir A$e me siento m$y or&$lloso de mi
peA$eCo 4Depend 5etrics 0eporter, de lo Itil y potente A$e Ja res$ltado ser+
Por otra parte, a mi me Ja venido de perlas el desarrollar $n m%d$lo en CT para
enviar los ficJeros de ade$dos directos se&In las especificaciones del S#P2, A$e
en mi empresa ten&o A$e deBar lista toda la mi&raci%n para el ! de ;ebrero del
aCo A$e viene+ N2l&$ien ms con el mismo problemaO
'ienen libre acceso al c%di&o en JttpHWW&itJ$b+comWZiZo&omeD

Anexo 1
=istorias de <s$ario
Dia&ramas de Clases
Dia&ramas de Dependencias


P&ina !"6 de !)*

RCNGC MEMBERS MANAGER
=istorias de <s$ario
Para la adA$isici%n de reA$isitos, y como intermediario entre el :pod$ct oFner: y los
desarrolladores finales, se Jan $sado las Jistorias de $s$ario de -DD, con la Jerramienta
de Spec;loF
Aadir miem2ros de *lu2
Como diBimos, es m$y simple+ 'an solo vamos a aCadir miembros bsicos+ La informaci%n
de fact$raci%n se incl$ye posteriormente+
A03No (5:ur- 1. =istoria de $s$arioH 2Cadir miembros del cl$b

6eat$reJ Add members
In order to manage the club members
As a administrative assistant
I want to add new members to the system

&cenario 2$tlineJ &econd s$rname is optional b$t iven name and (irst
s$rname are mandatory
3iven T+ese names M3ivenNameN, M6irst&$rnameN, M&econd&$rnameN
:+en ) process t+e names
T+en T+e name is considered MvalidN

&cenariosJ
P GivenName P FirstSurname P SecondSurname P valid P
P /6rancisco/ P /3omeQR*aldito/ P /Oiseas/ P /valid/ P
P /6rancisco/ P /3omeQR*aldito/ P // P /valid/ P
P /6rancisco/ P // P /Oiseas/ P /invalid/ P
P // P /3omeQR*aldito/ P /Oiseas/ P /invalid/ P
P /6rancisco/ P // P // P /invalid/ P
P // P /3omeQR*aldito/ P // P /invalid/ P
P // P // P /Oiseas/ P /invalid/ P
P // P // P // P /invalid/ P

&cenarioJ T+e members )D are consec$tive
3iven T+e c$rrent member)D seC$ence n$mber is 2
:+en ) add a new member
T+en T+e c$rrent member)D seC$ence n$mber is 3

&cenarioJ Lp to BBBBB members
3iven T+e c$rrent member)D seC$ence n$mber is 100000
:+en ) add a new member
T+en T+e new member is not created


P&ina !* de !)*
"enerar 3acturas
Se fact$ran a los socios los prod$ctos comprados y los servicios $sados+ Cada fact$ra
p$ede referirse a $no o ms conceptos, y se contempla los imp$estos (A$e p$eden ser
diferentes para cada concepto) y posibles desc$entos+
A03No (5:ur- 2. =istoria de $s$arioH 2Cadir ;act$ras (Parte !)

6eat$reJ 3eneratin invoices
In order to bill the club members
As an administrtative assistant
I want to generate invoices

DacEro$ndJ
3iven .ast enerated )nvoice)D is /INV2013000023/

3iven A *l$b 8ember
P emberI! P Name P FirstSurname P SecondSurname P
P ====; P 6rancisco P 3omeQR*aldito P Oiseas P

3iven T+is set o( ta4es
P "a# "y$e P "a# Value P
P No )3)* P = P
P )3)* Red$cido ; P <.AF P
P )3)* Red$cido .== P
P )3)* 3eneral P A.== P
P )3)* )ncrementado ; P B.F= P
P )3)* )ncrementado .F= P
P )3)* Especial P <=.== P

3iven T+ese services
P Service Name P !e%ault &ost P !e%ault "a# P
P Rent a EajaE P F=.== P )3)* 3eneral P
P Rent a Eatamaran P ;==.FF P )3)* 3eneral P
P Rent a mo$rin P ;F=.== P )3)* 3eneral P
P 6$ll 8embers+ip 8ont+ly 6ee P AB.== P No )3)* P

3iven T+ese prod$cts
P 'roduct Name P !e%ault &ost P !e%ault "a# P
P Pennant P ;=.== P )3)* 3eneral P
P *$p P ;F.== P )3)* 3eneral P
P 8ember )D *ard P ;.F= P No )3)* P

&cenarioJ 3enerate an invoice (or a service c+are
3iven T+e member $ses t+e cl$b service /(ent a )a*a)/
:+en ) enerate an invoice (or t+e service
T+en An invoice is created (or t+e cost o( t+e serviceJ +3,+0
And T+e invoice state is /"o be $aid/
And T+e invoice is assined to t+e *l$b 8ember

&cenarioJ 3enerate an invoice (or a sale
3iven T+e member b$ys a /'ennant/
:+en ) enerate an invoice (or t+e sale
T+en An invoice is created (or t+e cost o( t+e saleJ 10,-0
And T+e invoice is assined to t+e *l$b 8ember


P&ina !*! de !)*

A03No (5:ur- 3. =istoria de $s$arioH 2Cadir ;act$ras (Parte 2)

&cenarioJ T+e invoices )D m$st allways be consec$tive
T+en T+e enerated )nvoice )D s+o$ld be /INV2013000023/
T+en T+e ne4t invoice seC$ence n$mber s+o$ld be 2.

&cenarioJ Lp to BBBBBB invoices in a year
3iven .ast enerated )nvoice)D is /INV2013///////
3iven T+e member $ses t+e cl$b service /(ent a mouring/
:+en ) try to enerate an invoice (or t+e service
T+en T+e application doesnSt accept more t+an ////// invoices in t+e
year

&cenarioJ 3enerate an invoice (or m$ltiple transactions wit+ one ta4 type
3iven T+is set o( service c+are transactions
P 0nits P Service Name P !escri$tion P 0nit &ost P "a# P !iscount P
P ; P Rent a EajaE P Rent a EajaE (or one day P F=.== P )3)* 3eneral P = P
P < P Rent a mo$rin P 8o$rin 8ayR@$ne P ;F=.== P )3)* 3eneral P = P
:+en ) enerate an invoice (or t+is't+ese transaction's
T+en An invoice is created (or t+e cost o( t+e serviceJ 3-.,+0

&cenarioJ 3enerate an invoice (or m$ltiple transactions wit+ di((erent ta4
type
P ; P 8embers+ip 8ont+ly 6ee P 8ont+ly 6ee @$ne P AB.== P No )3)* P = P
T+en An invoice is created (or t+e cost o( t+e serviceJ .00,00

&cenarioJ Disco$nts on transactions m$st be applied be(ore ta4es
P ; P Rent a mo$rin P 8o$rin 8ayR@$ne P ;F=.== P )3)* 3eneral P <= P
T+en An invoice is created (or t+e cost o( t+e serviceJ 121,.0

&cenarioJ Ro$ndinJ Ro$nd to two decimals Away 6rom Tero
P ; P Rent a mo$rin P 8o$rin 8ayR@$ne P ;F=.== P )3)* 3eneral P ;F P
T+en An invoice is created (or t+e cost o( t+e serviceJ 132,.3

&cenarioJ Ro$ndinJ 6irst calc$late disco$nt on $nit, t+en ro$nd, t+en ta4
$nit, t+en ro$nd, t+en s$m $nits
P < P Rent a Eatamaran P Rent a Eatamaran < days P ;==.FF P )3)* 3eneral P ;F P
T+en An invoice is created (or t+e cost o( t+e serviceJ 112,/0


P&ina !*2 de !)*

A03No (5:ur- . =istoria de $s$arioH 2Cadir ;act$ras (Parte ")

&cenarioJ Transactions can +ave di((ernt cost and ta4 t+an de(a$lt service
ones
P ; P Rent a Eatamaran P Renta a Eatamaran < days P B= P No )3)* P = P
T+en An invoice is created (or t+e cost o( t+e serviceJ /0,00

&cenarioJ :e can mi4 services c+ares and sales in a sinle invoice
P < P Rent a Eatamaran P Renta a Eatamaran < days P F= P )3)* 3eneral P = P
P < P Rent a mo$rin P 8o$rin 8ayR@$ne P ;F=.== P )3)* 3eneral P <= P
3iven T+is set o( sale transactions
P 0nits P 'roduct Name P !escri$tion P 0nit &ost P "a# P !iscount P
P ; P *$p P Dl$e *$p P ;= P )3)* 3eneral P = P
P ; P 8ember )D *ard P )D *ard Reprinted P ;.F= P No )3)* P F= P
T+en An invoice is created (or t+e cost o( t+e serviceJ 3-+,2+


P&ina !*" de !)*
"enerar facturas proforma
Se &eneran a veces fact$ras proGforma (pres$p$estos) para al&$nos servicios
A03No (5:ur- 5. Generar ;act$ras Proforma

6eat$reJ 3eneratin pro (orma invoices
In order to give estimates to the club members
As an administrtative assistant
I want to generate $ro %orma invoices

DacEro$ndJ
3iven .ast enerated pro (orma invoice )D is /'(F2013000023/

3iven A *l$b 8ember

P No )3)* P = P
P )3)* Red$cido .== P



&cenarioJ 3eneratin a pro (orma invoice (or a set o( service c+ares and
sales
3iven T+is set o( sale transactions
P 0nits P 'roduct Name P !escri$tion P 0nit &ost P "a# P !iscount P
P ; P *$p P Dl$e *$p P ;= P )3)* 3eneral P = P
P ; P 8ember )D *ard P )D *ard Reprinted P ;.F= P No )3)* P F= P
:+en ) enerate a pro (orma invoice (or t+is't+ese transaction's
T+en A pro (orma invoice is created (or t+e cost o( t+e serviceJ
3-+,2+


P&ina !** de !)*

A03No (5:ur- ". =istoria de $s$arioH Generar fact$ra proforma (Parte 2)

&cenarioJ A pro(orma invoice +as no bill associated
:+en ) enerate a pro (orma invoice (or t+is't+ese transaction's
T+en No bills are created (or a pro (orma invoice

&cenarioJ T+e invoice detail o( a pro (orma invoice can be edited
3iven ) enerate a pro (orma invoice (or t+is't+ese transaction's
:+en ) c+ane t+e invoice detail to t+ese val$es
T+en T+e pro (orma invoice is modi(ied re(lectin t+e new val$eJ
2+2,10


P&ina !*( de !)*
,odificar 3acturas
<na fact$ra creada p$ede an$larse mediante $na fact$ra rectificativa+
A03No (5:ur- 7. =istoria de $s$arioH 5odificar fact$ras

6eat$reJ 8anae )nvoices
In order to control the debt
As a an administrtative assistant
I want to manage the created invoices

DacEro$ndJ

3iven A *l$b 8ember

P No )3)* P = P
P )3)* Red$cido .== P



&cenarioJ )n some special cases, an invoice can be cancelled
3iven ) +ave an invoice (or t+e service /(ent a )a*a)/
:+en ) cancel t+e invoice
T+en T+e invoice state is /&ancelled/
And All t+e pendin bills are marEed as *ancelled
And T+e bill total amo$nt to be paid is 0
And An amendin invoice is created (or t+e neative val$e o( t+e
oriinal invoiceJ 3+3,+0
And T+e ta4es devol$tion (33,+0! is separated (rom t+e base cost
devol$tion (3+0!
And T+e amendin invoice )D is t+e same t+an t+e oriinal invoice
wit+ di((erent pre(i4J /AN2013000023/ T+en T+e new member is not created


P&ina !*6 de !)*
"estionar reci2os
Se &eneran recibos para cada fact$ra+ #stos p$eden pa&arse, A$edar impa&ados al
c$mplir s$ vencimiento, cancelarse, o rene&ociarse a $n n$evo vencimiento o en pa&os
aplaDados+
A03No (5:ur- $. =istoria de $s$arioH Gestionar recibos (Parte !)

6eat$reJ 8anae bills
In order charge my invoices
As an administrative assistant
I want reate and manage bills %or my invoices

DacEro$ndJ

3iven A *l$b 8ember wit+ a de(a$lt Payment met+od
P emberI! P Name P FirstSurname P SecondSurname P !e%ault 'ayment method P
S$anish I4AN 4an) Account P !irect !ebit (e%erence Number P
P ====; P 6rancisco P 3omeQR*aldito P Oiseas P Direct Debit P
)DAN E&GH ;<>? FGAH =G;< >?FG AHB= P ;<>?F P

P No )3)* P = P
P )3)* Red$cido .== P



&cenarioJ A sinle bill is a$tomatically created (or a new invoice
T+en An invoice is created (or t+e cost o( t+e serviceJ +3,+0
And A sinle bill To *ollect is enerated (or t+e total amo$nt o( t+e
invoiceJ +3,+0
And T+e bill )D is /INV20130000235001/
And Dy de(a$lt no payment met+od is associated to bill


P&ina !*) de !)*
A03No (5:ur- 9. =istoria de $s$arioH Gestionar recibos (Parte 2)

&cenarioJ No bills are created (or a pro (orma invoice
:+en ) enerate an proR(orma invoice (or t+e service
T+en A proR(orma invoice is created (or t+e cost o( t+e serviceJ
+3,+0
And No bills are created (or a proR(orma invoice

&cenarioJ A bill can be reneotiated into instalments
3iven ) +ave an invoice wit+ cost 2+0 wit+ a sinle bill wit+ )D
/INV20130000235001/
:+en ) reneotiate t+e bill /INV20130000235001/ into t+ree
instalmentsJ 200, 200, 2+0 to pay in 30, 20 and /0 days wit+ areement terms
/'ayment Agtreement/
T+en T+e bill /INV20130000235001/ is marEed as reneotiated
And T+e reneotiated bill /INV20130000235001/ +as associated t+e
areement terms /'ayment Agtreement/ to it
And A bill wit+ )D /INV20130000235002/ and cost o( 200 to be paid in
30 days is created
And T+e new bill /INV20130000235002/ +as associated t+e areement
terms /'ayment Agtreement/ to it
And A bill wit+ )D /INV20130000235003/ and cost o( 200 to be paid in
20 days is created
And T+e new bill /INV20130000235003/ +as associated t+e areement
And A bill wit+ )D /INV2013000023500./ and cost o( 2+0 to be paid in
/0 days is created
And T+e new bill /INV2013000023500./ +as associated t+e areement

&cenarioJ ) can assin an speci(ic e4pected payment met+od (or a sinle bill
3iven ) +ave an invoice wit+ cost 2+0 wit+ a sinle bill wit+ )D
/INV20130000235001/
:+en ) assin to be paid wit+ a direct debit
T+en T+e new payment met+od is correctly assined

&cenarioJ A bill to collect is paid in cas+
3iven ) +ave an invoice wit+ some bills
And ) +ave a bill to collect in t+e invoice
:+en T+e bill is paid in cas+
T+en T+e bill state is set to /'aid/
And T+e bill payment met+od is set to /&ash/
And T+e bill payment date is stored
And T+e bill amo$nt is ded$ced (orm t+e invoice total amo$nt

&cenarioJ A bill to collect is paid by banE trans(er
:+en T+e bill is paid by banE trans(er
And T+e bill payment met+od is set to /4an) "rans%er/
And T+e trans(eror acco$nt is stored
And T+e trans(eree acco$nt is stored


P&ina !*? de !)*
A03No (5:ur- 1). =istoria de $s$arioH Gestionar recibos (Parte ")

&cenarioJ A bill to collect is paid by direct debit
:+en T+e bill is paid by direct debit
And T+e bill payment met+od is set to /!irect !ebit/
And T+e direct debit initiation )D is stored

&cenarioJ All t+e bills o( an invoice are paid
:+en All t+e bills are paid
T+en T+e invoice state is set as /'aid/

&cenarioJ A bill is past d$e date
:+en T+e bill is past d$e date
T+en T+e bill is marEed as /0n$aid/
And T+e invoice containin t+e bill is marEed as /0n$aid/

&cenarioJ A bill wit+ an associated areement is past d$e date
3iven ) +ave an invoice wit+ some bills wit+ areements
And ) +ave a bill to collect in t+e invoice wit+ a payment areement
:+en T+e bill is past d$e date
T+en T+e bill is marEed as /0n$aid/
And T+e invoice containin t+e bill is marEed as /0n$aid/
And T+e associated payment areement is set to /NotAcom$lished/ (or
all bills involved on t+e areement
And T+e associated payment areement is set to /NotAcom$lished/ (or
t+e invoice

&cenarioJ A bill d$e date can be e4tended
:+en ) renew t+e d$e date
T+en T+e new d$e date is assined to t+e bill

&cenarioJ A past d$e bill d$e date can be renewed
And T+e bill is past d$e date
:+en ) renew t+e d$e date
T+en T+e new d$e date is assined to t+e bill
And T+e bill is marEed as /"o&ollect/
And )( t+ere are no ot+er bills marEed as /0n$aid/ t+e invoice is
marEed /"o4e'aid/


P&ina !*6 de !)*
"estionar la informacin de pa4o de los socios
Los socios p$eden pa&ar en efectivo o mediante emisi%n de ade$do domiciliado+ Para
poder mandar $n recibo Jan de firmar $na orden de domiciliaci%n+ <n socio p$ede tener
varias %rdenes de domiciliaci%n
A03No (5:ur- 11. =istoria de $s$arioH Gestionar la informaci%n de pa&o de los socios

6eat$reJ 8anae 8embers Dillin )n(ormation
In order be able to bill my club members
As a administrative assistant
I want to manage my members billing registered data

DacEro$ndJ

3iven A *l$b 8ember

3iven T+ese Direct Debit 8andates
P !irect!ebitInternal(e%erenceNumber P (egister!ate P I4AN P
P <>?F P <=;>';;'<= P E&GH;<>?FGAH=G;<>?FGAHB= P
P <>?G P <=;>';;'>= P E&>=;;;;<<<<==>>>>>>>>>> P

3iven T+ese Acco$nt N$mbers
P I4AN P
P E&GH;<>?FGAH=G;<>?FGAHB= P
P E&>=;;;;<<<<==>>>>>>>>>> P

&cenarioJ ) can c+ane t+e member de(a$lt payment met+od
3iven ) +ave a member
And T+e member +as associated cas+ as payment met+od
:+en ) set direct debit as new payment met+od
T+en T+e new payment met+od is correctly $pdated

&cenarioJ ) can assin a new direct debit mandate to a member
And T+e direct debit re(erence seC$ence n$mber is +000
:+en ) add a new direct debit mandate to t+e member
T+en T+e new direct debit mandate is correctly assined
And T+e new direct debit re(erence seC$ence n$mber is +001

&cenarioJ ) can c+ane t+e acco$nt n$mber associated to a direct debit
And ) +ave a direct debit associated to t+e member
:+en ) c+ane t+e acco$nt n$mber o( t+e direct debit
T+en T+e acco$nt n$mber is correctly c+aned
And T+e old acco$nt n$mber is stored in t+e acco$nt n$mbers +istory


P&ina !( de !)*
"estionar la informacin del *lu2 como emisor de reci2os
Como emisor de recibos el Cl$b establece contratos de cedente de recibos con las
entidades bancarias
A03No (5:ur- 12. =istoria de $s$arioH Gestionar la informaci%n del cl$b como emisor de recibos

6eat$reJ 8anae *reditor )n(o
In order to charge the bills to my club members
As a &lub anager
I want to manage all my in%o as a direct debit creditor

DacEro$ndJ

3iven 8y creditor in(o is
P NIF P Name P
P 3>F==HAA= P Real *l$b NU$tico de 3ran *anaria P

&cenarioJ *reate a creditor aent
3iven ) +ave a banE
:+en ) reister t+e banE as a creditor aent
T+en T+e creditor aent is correctly created

&cenarioJ Reister a direct debit initiation contract
3iven ) +ave a creditor aent
:+en ) reister a contract data
T+en T+e contract is correctly reistered

&cenarioJ Reister more t+an one direct debit initiation contract
3iven ) +ave a direct debit initiation contract reistered
:+en ) reister a second contract data
T+en T+e contract is correctly reistered

&cenarioJ ) c+ane t+e banE acco$nt (or my contract
3iven ) +ave a direct debit initiation contract
:+en ) c+ane t+e creditor acco$nt to /6S1-21002222002222222222/
T+en T+e contract acco$nt is correctly $pdated to
/6S1-21002222002222222222/

&cenarioJ ) c+ane remove a direct debit initiation contract
3iven ) +ave a direct debit initiation contract reistered wit+
b$ssines code /333/
:+en ) remove t+e contract /333/
T+en T+e contract /333/ is correctly removed


P&ina !(! de !)*
"enerar remesas de reci2os domiciliados
<na veD ele&ido $n contrat, se &enera $na remesa, a la A$e se van aCadiendo los reibos,
para, finalmente crear el mensaBe S#P2 IS,222 pain+?+!+2
A03No (5:ur- 13. =istoria de $s$arioH &enerar remesas de recibos domiciliados

6eat$reJ 3eneratin Direct Debit Remmitances
In order to charge the bills to my club members
I want to generate direct debit remitances to ban)

DacEro$ndJ

3iven 8y Direct Debit )nitiation *ontract is
P NIF P Name P 4I& P &reditorAgentName
P 7ocal4an)&ode P &reditor4ussines&ode P &reditorAccount P
P 3>F==HAA= P Real *l$b NU$tico de 3ran *anaria P *A)VE&DDVVV P *A)VADANW
P <;== P AAA P E&FG<;==;;;;>=;;;;;;;;;; P

3iven T+ese *l$b 8embers
P emberI! P Name P FirstSurname P SecondSurname P (e%erence P Account P
4I& P
P ====; P 6rancisco P 3omeQR*aldito P Oiseas P ;<>? P =;H<;;;;G=;;;;;;;;;; P
DDOAE&88VVV P
P ====F P <;==;;;;>=;;;;;;;;;; P
*A)VE&DDVVV P

3iven T+ese bills
P emberI! P "ransaction&once$t P Amount P
P ====; P *$ota 8ens$al 2ct$bre <=;> P AB P
P ==== P AB P
P ==== P AB P

&cenarioJ *reate a new direct debit remmitance
3iven ) +ave a ) +ave a direct debit initiation contract
:+en ) enerate a new direct debit remmitance
T+en An empty direct debit remmitance is created

&cenarioJ *reate an empty ro$p o( direct debit payments
3iven ) +ave a will send t+e payments $sin /&8(1/ local instr$ment
:+en ) enerate an empty ro$p o( direct debit payments
T+en An empty ro$p o( direct debit payments $sin /&8(1/ is
enerated

&cenarioJ *reate a Direct Debit Transaction (rom a bill as speci(ied by a
member direct debit mandate
And T+e member +as a bill
And T+e member +as a Direct Debit 8andate
:+en ) enerate Direct Debit Transaction
T+en T+e direct debit transaction is correctly created

&cenarioJ Add a second bill to a direct debit transaction
3iven ) +ave a direct debit wit+ 1 bill and amo$nt o( -/
:+en ) add a new bill wit+ amo$nt o( -/
T+en T+e direct debit transaction is $pdated wit+ 2 bills and amo$nt
o( 1+1


P&ina !(2 de !)*

A03No (5:ur- 1. =istoria de $s$arioH Generar remesas de recibos domiciliados (Parte 2)

&cenarioJ Add a direct debit transaction to an empty ro$p o( payments
3iven ) +ave a direct debit wit+ 1 bill and amo$nt o( -/
And ) +ave an empty ro$p o( payments
:+en ) add t+e direct debit transaction to t+e ro$p o( payments
T+en T+e ro$p o( payments is $pdated wit+ 1 direct debit and total
amo$nt o( -/

&cenarioJ Add a second direct debit transaction to a ro$p o( payments
3iven ) +ave a ro$p o( payments wit+ 1 direct debit transaction and
amo$nt o( -/
:+en ) add a new direct debit transaction wit+ amo$nt o( -/
T+en T+e ro$p o( payments is $pdated wit+ 2 direct debit and total
amo$nt o( 1+1

&cenarioJ Add a ro$p payments to a direct debit remmitance
3iven ) +ave an empty direct debit remmitance
And ) +ave a ro$p o( payments wit+ 1 direct debit transaction and
amo$nt o( -/
:+en ) add t+e ro$p to t+e direct debit remittance
T+en T+e direct debit remittance is $pdated wit+ 1 direct debit and
total amo$nt o( -/

&cenarioJ 3eneratin &EPA )&2<==<< V8. *$stomerDirectDebit)nitiation 8essae
(orm a Direct Debit Remmitance
3iven ) +ave a prepared Direct Debit Remmitance
:+en ) enerate de &EPA )&2200022 V8. *$stomerDirectDebit)nitiation
messae
T+en T+e messae is correctly created


P&ina !(" de !)*
"estionar los n5meros de cuenta
#s m$y importante la correcta adA$isici%n de nImeros de c$enta de la anteriores bases
de datos+ Se Ja de permitir importar nImeros incompletos, pero se Jan de validar todas
las n$evas entradas+ Los nImeros anti&$os p$eden ser c%di&os de bancoWs$c$rsalWc$enta
o CCC completos+ Los n$evos p$eden ser, adems, I-24+
A03No (5:ur- 15. =istoria de $s$arioH Gestionar los nImeros de c$enta
6eat$reJ 8anae acco$nt n$mbers
In order to create direct debits
I want to $rocess account numbers
I want to store old incom$lete ban) account %ields %rom $reviuos
database
I want to acce$t only valid accounts i% &&& or I4AN are $rovided

&cenarioJ :+en ) provide a valid banE acco$nt it is stored and *** and )DAN
is created
3iven T+is banE acco$nt /123./, /+2-1/, /02/, /123.+2-1/0/
:+en ) process t+e banE acco$nt
T+en t+e banE acco$nt is considered /valid/
And t+e banE acco$nt is /stored/
And T+e *** /123.+2-102123.+2-1/0/ is created
And T+e spanis+ )DAN code /6S21123.+2-102123.+2-1/0/ is created

&cenarioJ :+en ) provide an invalid banE acco$nt it is stored b$t no *** nor
)DAN are created
3iven T+is banE acco$nt /123./, /+2-1/, /0+/, /123.+2-1/0/
T+en t+e banE acco$nt is considered /invalid/
D$t t+e banE acco$nt is /stored/
And T+e *** // is created
And T+e spanis+ )DAN code // is created

&cenarioJ :+en ) provide an incomplete banE acco$nt it is stored b$t no ***
nor )DAN are created
3iven T+is banE acco$nt //, /+2-1/, /0+/, /123.+2-1/0/
D$t t+e banE acco$nt is /stored/
And T+e *** // is created
And T+e spanis+ )DAN code // is created

&cenarioJ :+en ) provide a too lon banE acco$nt it is not stored
3iven T+is banE acco$nt /123./, /+2-1/, /02/, /123.+2-1/01111/
And t+e banE acco$nt is /not stored/

&cenarioJ :+en ) provide a valid *** it is stored, banE acco$nt (ields are
created, and )DAN is created
3iven T+is *** /123.+2-102123.+2-1/0/
:+en ) process t+e ***
T+en t+e *** is considered /valid/
And t+e *** is /stored/
And t+e banE acco$nt /123./, /+2-1/, /02/, /123.+2-1/0/ is created
And T+e spanis+ )DAN code /6S21123.+2-102123.+2-1/0/ is created


P&ina !(* de !)*

A03No (5:ur- 1". =istoria de $s$arioH Gestionar los nImeros de c$enta (Parte 2)

&cenarioJ :+en ) provide a valid spanis+ )DAN it is stored, banE acco$nt
(ields are created, and *** is created
3iven T+is )DAN /6S21123.+2-102123.+2-1/0/
:+en ) process t+e )DAN
T+en t+e )DAN is considered /valid/
And t+e )DAN is /stored/
And t+e banE acco$nt /123./, /+2-1/, /02/, /123.+2-1/0/ is created
And T+e *** /123.+2-102123.+2-1/0/ is created

&cenarioJ :+en ) provide an ivalid *** no in(o is stored nor created
3iven T+is *** /123.+2-10+123.+2-1/0/
:+en ) process t+e ***
T+en t+e *** is considered /invalid/
And t+e *** is /not stored/

&cenarioJ :+en ) provide a invalid spanis+ )DAN no in(o is stored nor
created
3iven T+is )DAN /6S21123.+2-10+123.+2-1/0/
:+en ) process t+e )DAN
T+en t+e )DAN is considered /invalid/
And t+e )DAN is /not stored/

&cenario 2$tlineJ T+eese are t+e res$lts w+en processin t+eese banE
acco$nts
3iven T+is banE acco$nt MDanEN, M2((iceN, M*ontrolDiitN,
MAcco$ntN$mberN
T+en t+e banE acco$nt is considered MvalidN
And t+e banE acco$nt is MstoredN
And T+e *** M***N is created
And T+e spanis+ )DAN code M)DANN is created

&cenariosJ
P 4an) P 8%%ice P &ontrol!igit P AccountNumber P valid P stored
P &&& P I4AN P
P /;<>?/ P /FGAH/ P /=G/ P /;<>?FGAHB=/ P /valid/ P /stored/
P /;<>?FGAH=G;<>?FGAHB=/ P /E&GH;<>?FGAH=G;<>?FGAHB=/ P
P /;<>?/ P /FGAH/ P /=F/ P /;<>?FGAHB=/ P /invalid/ P /stored/
P // P // P
P // P // P /=F/ P /;<>?FGAHB=/ P /invalid/ P /stored/
P // P // P
P /;<>?/ P /FGAH/ P /=G/ P /;<>?'FGR=/ P /invalid/ P /stored/
P // P // P
P /;<>?/ P /FGAH/ P /=G/ P /;<>?FGAHB=;;/ P /invalid/ P /no stored/
P // P // P


P&ina !(( de !)*


P&ina !(6 de !)*
Dia&ramas de Clases
Socios y facturacin 26sica
Cada socio incl$ye $na lista de fact$ras A$e se les Jan emitido (normales, pro
forma o rectificativas), derivadas de $na clase base+
Las fact$ras tienen $n detalle de conceptos A($ransactions)), A$e p$eden ser
ventas o car&os por servicios+
2l mismo tiempo, cada fact$ra p$ede pa&arse de $na veD o en recibos aplaDados+
Las fact$ras se &estionan desde $na clase controladora (Hnoices8ana"er)
A03No (5:ur- 17. Dia&ramas de clasesH Las fact$ras


P&ina !() de !)*
!a4o de reci2os
#n los recibosH
Se le p$ede asociar $na forma de pa&o por defecto
P$ede tener ac$erdos de rene&ociaci%n
C$ando se pa&a, se le asocia $n 9pa&o:+
Se &estionan desde la clase controladora (Gills8ana"er)+
A03No (5:ur- 1$. Dia&ramas de clasesH Las fact$ras


P&ina !(? de !)*
7rdenes de Domiciliacin
Cada miembro p$ede tener $na serie de %rdenes de domiciliaci%n, cada $na con $na
c$enta asociada, A$e se p$ede eLpresar en varios formatos+ DicJa c$enta p$ede
cambiarse, pero se mantiene $n Jist%rico

A03No (5:ur- 19. 3rdenes de Domiciliaci%n


P&ina !(6 de !)*
"eneracin de Remesas al #anco
Se p$eden &enerar remesas de recibos para enviar al banco+
Como emisor podemos firmar c$antos contratos A$eramos con n$estro banco
Cada remesa A$e &eneremos estar asociada a $no de estos contratos
Cada remesa esta formada por $no o ms &r$pos de pa&os, cada $no de los c$ales
p$ede tener $no o ms ade$dos directos, cada $no de los c$ales p$ede ser el
pa&o de $no o ms recibos
La &eneraci%n de la remesa se realiDa desde la clase controladora
(3irect3ebit6emittances8ana"er)+
A03No (5:ur- 2). Generaci%n de remesas de recibos


P&ina !6 de !)*
Env8o de remesas al 2anco
<na veD &enerada, la remesa se p$ede enviar al banco $sando el formato establecido por
el S#P2 IS,222 pain+?+!+2 mediante la clase (*@<A8essa"es8ana"er)+ La
especificaci%n IS, es m$y eLtensa ($nas 6 clases)+ 5ostramos el esA$ema ms eLterno+
A03No (5:ur- 21. #nv>o de remesas al banco $sando S#P2 IS,222 pain+?+!+2


P&ina !6! de !)*
,oc9in4
Para el presente proyecto se Jan implementado $n par de clases para ay$dar en el
9mocZin&: de los tests+
A03No (5:ur- 22. DiseCo de 95ocZin&:


P&ina !62 de !)*
Dia&ramas de dependencias
Como podemos observar en los si&$ientes dia&ramas, las clases estn correctamente
estr$ct$radas y no se observan dependencias circ$lares en los &rafos de dependencias+
Adeudos directos

A03No (5:ur- 23. Dependencias en las clases de ade$do directo


P&ina !6" de !)*
3acturacion
A03No (5:ur- 2. Dependencias en las clases de fact$raci%n


P&ina !6* de !)*
Dia4rama 4eneral de dependencias
A03No (5:ur- 25. Dia&rama &eneral de dependencias


P&ina !6( de !)*


P&ina !66 de !)*
BIBLIOGRAFA
W1X A>39/o0M &-ro94. Su//,-0M G3r-94 J. J19$K Structure and Interpretation of *omputer !ro4rams0
(5r/t E45t5o0 P M5t Pr3//
W2X A/t39/M D-@54 R. J2))3K. :est;Driven Development' A !ractical "uide0 Pr30t523 &-99
W3X B32LM Y30t J2)))K E<treme !ro4rammin4 E<plained' Em2race *$an4e. A445/o0I'3/93? Pro<3//5o0-9
WX B32LM Y30t J2))3K. T3/tIDr5@30 D3@39o1,30t. B? EN-,193. A445/o0I'3/93? Pro<3//5o0-9
W5X B9GM C-r9o/. J2)1)K. Diseo =4il con :DD
W"X CB-,>3r/M S3-0 J2))9K > Days Refactorin4
W7X (o=93rM M-rt50 J1999K. Refactorin4' Improvin4 t$e Desi4n of E<istin4 *ode. A445/o0I'3/93?
Pro<3//5o0-9
W$X G-,,-M Er52BM &39,M R52B-r4M JoB0/o0M R-91BM V95//543/M JoB0 J199K Desi4n !atterns' Elements of
reusa2le +2%ect;+riented Software0 A445/o0I'3/93? Pro<3//5o0-9
W9X &3043r/o0IS3993r/ J1995K A #++? of +2%ect;+riented ?nowled4e -2
nd
0 Edition/. Pr30t523 &-99.
W1)X M-rt50M Ro>3rt C. J2))$K Desi4n !rinciples and Desi4n !atterns. ===.o>732t,30tor.2o,
W11X M-rt50M Ro>3rt C. J2))$K. *lean *ode' A .and2oo9 of A4ile Software *raftmans$ip. Pr30t523 &-99
W12X M3?3rM B3rtr-04 J19$$K +2%ect;+riented Software *onstruction0 Pr30t523 B-99
W13X NortBM D-0 J2))"K I0tro4u250: BDD . D-0 NortB Z A//o25-t34
W1X T-L3u2B5M &5roL-t- P No0-L-M ILu75ro J19$"K. :$e @ew !roduct Development "ame
W15X !our4o0M E. J19$2K. An6lisis Estructurado ,oderno. Pr30t523 &-99 I>3ro-,3r52-0-


P&ina !6) de !)*


P&ina !6? de !)*
REFERENCIAS

!
L,PD
JttpHWWFFF+a&pd+esWportalFeb2GPDWcanaldoc$mentacionWle&islacionWestatalWcommonWpdfsWL,PDhconsoli
dada+pdf
2
2rt>c$lo ! del Convenio de -erna para la Protecci%n de las ,bras Literarias y 2rt>sticas
JttpHWWFFF+Fipo+intWtreatiesWesWipWberneWtrtdocshFo!+JtmlTP!("h2?62)
"
Directiva 2!W26WC# relativa a la armoniDaci%n de ciertos derecJos de a$tor
JttpHWWe$rGleL+e$ropa+e$WLeL<riServWLeL<riServ+doO$ribC#L#@H"2!L26H#SH='5L
*
S#P2 g Sin&le #$ro Payments 2rea
(
#$ropean Co$ncil pa&e on S#P2
JttpHWWec+e$ropa+e$WinternalhmarZetWpaymentsWsepaW
6
PSD g Directive on Payment Services
JttpHWWec+e$ropa+e$WinternalhmarZetWpaymentsWframeForZW
)
Ley de Servicios de Pa&o G Ley !6W26, de !" de noviembre
JttpHWWFFF+boe+esWboeWdiasW26W!!W!*WpdfsW-,#G2G26G!?!!?+pdf
?
#PC g #$ropean Payments Co$ncil
JttpHWWFFF+e$ropeanpaymentsco$ncil+e$W
6
#$ropean Central -anZ pa&e on S#P2
JttpHWWFFF+ecb+e$ropa+e$WpaymWsepaW
!
Portal sobre la S#P2 en espaCol
JttpHWWFFF+sepaesp+es
!!
IS,222 G <niversal financial ind$stry messa&e scJeme
JttpHWWFFF+iso222+or&W
!2
IS, 'ecJnical Commitee 'C6? ;inancial Services
JttpHWWFFF+iso+or&WisoWisohtecJnicalhcommitteeOcommidb*66(
!"
P&ina del #PC sobre 2de$dos Directos S#P2
JttpHWWFFF+e$ropeanpaymentsco$ncil+e$Wcontent+cfmOpa&ebsepahdirecthdebithS2?sddS26
!*
P&ina del -anco de #spaCa sobre 2de$dos Directos S#P2
JttpHWWFFF+sepaesp+esWsepaWesWseccionesWinstr$mentosWade$dosdirectosW2de$doshdirectoshbasicos+Jtml
!(
S#P2 Core Direct Debit ScJeme 0$lebooZ (#PC!6G6)
JttpHWWFFF+e$ropeanpaymentsco$ncil+e$WZnoFled&ehbanZhdetail+cfmOdoc$mentshidb(("
!6
IS, 222 5essa&e Definition 0eport G Payments 5aintenance 26 G #dition September 26
JttpHWWFFF+iso222+or&Wdoc$mentsW&eneralWPaymentsh5aintenanceh26+Dip
!)
IS, 222 C$stomerGtoG-anZ 5essa&e <sa&e G$ide G C$stomer Credit 'ransfer Initiation, C$stomer Direct
Debit Initiation and Payment Stat$s 0eport G /ersion "+


P&ina !66 de !)*

JttpHWWFFF+sFift+comWassetsWcorporatesWdoc$mentsWo$rhsol$tionWimplementin&hyo$rhproBecth26hiso2
22h$sa&eh&$ide+pdf
!?
S[I;' G Society for [orldFide InterbanZ ;inancial 'elecomm$nication
JttpHWWFFF+sFift+com
!6
Sepa Core Direct Debit ScJeme C$stomerGtoG-anZ Implementation G$idelines (#PC!"G?)
JttpHWWFFF+e$ropeanpaymentsco$ncil+e$WZnoFled&ehbanZhdetail+cfmOdoc$mentshidb(**
2
IS,222 5essa&e 2rcJive Pa&e
JttpHWWFFF+iso222+or&Wmessa&eharcJive+pa&e
2!
IS, 222 (pain) G 'Jird version of tJe Payment Initiation messa&es
JttpHWWFFF+iso222+or&Wmessa&eharcJive+pa&eTPaymentsInitiation"
22
;icJa de 2de$dos Sepa
JttpHWWFFF+sepaesp+esWfWFebsepaWseccionesWInstr$mentosW;IC=2hD#h2D#<D,ShDI0#C',ShS#P2+pdf
2"
CS-GC$aderno !6 g 5arDo 2?
JttpHWWempresas+banZia+esW;icJerosWC52WficJerosW4orma!65arDo2?+PD;
2otaJ @ste documento no aparece publicado en nin"una de las p"inas de los or"anismos anteriores, sino
que est disponible a tras de las p"inas para empresa de las di&erentes entidades bancarias/ @l enlace
proisto en esta memoria est sacado directamente a tras de una b1squeda en Hnternet, perteneciendo en
este caso a ;a Cai7a+
2*
5i&raci%n a S#P2 de los 2de$dos Domiciliados #spaColes
JttpHWWFFF+aebanca+esWcsW&ro$psWp$blicWdoc$mentsWp$blicacionesWG2!"*2)+pdf
2(
2#- g 2sociaci%n #spaCola de -anca
JttpHWWFFF+aebanca+es
26
C#C2 g Confederaci%n #spaCola de CaBas de 2Jorros
JttpHWWFFF+ceca+es
2)
<42CC g <ni%n 4acional de Cooperativas de CrEdito
JttpHWWFFF+$nacc+comW
2?
3rdenes en ;ormato IS, 222 para la emisi%n de 2de$dos Directos S#P2 g #sA$ema -sico g G$>a de
Implantaci%n g 4oviembre 2!2
JttpHWWempresa+lacaiLa+esWdeployedfilesWempresasW#staticosWpdfW'ransferenciasyficJerosWC$adernoh@5Lh
#misionh2de$doshSDDhCoreh4oviembreh2!2+pdf
2otaJ @ste documento no aparece publicado en nin"una de las p"inas de los or"anismos anteriores, sino
que est disponible a tras de las p"inas para empresa de las di&erentes entidades bancarias/ @l enlace
proisto en esta memoria est sacado directamente a tras de una b1squeda en Hnternet, perteneciendo en
este caso a ;a Cai7a+
26
.$e&o del 'elEfono 0oto
JttpHWWes+FiZipedia+or&WFiZiW'elSC"S26fonohdescomp$esto
"
'eor>a de la Informaci%n
JttpHWWes+FiZipedia+or&WFiZiW'eorSC"S2DahdehlahinformaciSC"S-"n
"!
M#at Poop 1o$ CatU g -oard Game GeeZ
JttpHWWboard&ame&eeZ+comWboard&ameW"6!?WeatGpoopGyo$Gcat


P&ina !) de !)*

"2
[aterfall 5odel
JttpHWWen+FiZipedia+or&WFiZiW[aterfallhmodel
""
5Etrica " g 5inisterio de =acienda y 2dministraciones PIblicas de #spaCa
JttpHWWadministracionelectronica+&ob+esWpaeh=omeWpaehDoc$mentacionWpaeh5etodolo&Wpaeh5etricahv"
+Jtml
"*
NR$E es el SC0<5O
JttpHWWFFF+proyectosa&iles+or&WA$eGesGscr$m
"(
5anifiesto 8&il
JttpHWWa&ilemanifesto+or&WisoWesW
"6
SoftFare CraftmansJip g [I\IP#DI2
JttpHWWen+FiZipedia+or&WFiZiWSoftFarehcraftsmansJip
")
Los !2 principios del a&ilismo
JttpHWWa&ilemanifesto+or&WisoWesWprinciples+Jtml
"?
-DD g -eJavio$r Driven Development
JttpHWWen+FiZipedia+or&WFiZiW-eJaviorGdrivenhdevelopment
"6
2n Introd$ction to 2ceptance 'ests
JttpHWWa&ile+tecJFell+comWarticlesWFeeZlyWintrod$ctoryGacceptanceGtest
*
S,LID g ,,P Principles+ 0obert C+ 5artin M<ncle -obU
JttpHWWb$t$nclebob+comW2rticleS+<ncle-ob+Principles,f,od
*!
Code 5etrics g 4depend
JttpHWWFFF+ndepend+comWmetrics+aspL
*2
2&ile 5etJodolo&ies S$rvey 0es$lt (PD;) g SJine 'JecJnolo&ies
JttpHWWFFF+sJinetecJ+comWattacJmentsW!*hSJine'ecJ2&ileS$rvey2"G!G!)+pdf
*"
2mbler, Scott (" 2$&$st 26) G S$rvey SaysH 2&ile [orZs in Practice
JttpHWWFFF+drdobbs+comWarcJitect$reGandGdesi&nWs$rveyGsaysGa&ileGForZsGinGpracticeW!6!?!66
**
SoftFare R$ality 5ana&ement g [I\IP#DI2
JttpHWWen+FiZipedia+or&WFiZiWSoftFarehA$alityhmana&ement
*(
=irota 'aZe$cJi g [iZipedia
JttpHWWen+FiZipedia+or&WFiZiW=irotaZah'aZe$cJi
*6
IZ$Biro 4onaZa g [iZipedia
JttpHWWen+FiZipedia+or&WFiZiWIZ$Biroh4onaZa
*)
\en ScJ[aber g [iZipedia
JttpHWWen+FiZipedia+or&WFiZiW\enhScJFaber
*?
Dan 4ortJ f 2ssociates
JttpHWWdannortJ+netW
*6
-eJavio$rGDriven Development G [iZipedia
JttpHWWen+FiZipedia+or&WFiZiW-eJaviorGdrivenhdevelopment


P&ina !)! de !)*

(
[Jat:s in a storyO Dan 4ortJ f 2ssociated
JttpHWWdannortJ+netWFJatsGinGaGstoryW
(!
5ocZs aren:t st$bs g 5artin ;oFler
JttpHWWmartinfoFler+comWarticlesWmocZs2rentSt$bs+Jtml
(2
Code Covera&e g [I\IP#DI2
JttpHWWen+FiZipedia+or&WFiZiWCodehcovera&e
("
Desi&n Patterns g oodesi&n+com
JttpHWWFFF+oodesi&n+comW
(*
Desi&n Principles and Desi&n Patterns g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWPrincipleshandhPatterns+pdf
((
'Je Principles of ,,D g 0obert C+ 5artin
JttpHWWb$t$nclebob+comW2rticleS+<ncle-ob+Principles,f,od
(6
Sin&le 0esponsability Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWsrp+pdf
()
'Je ,penWClosed Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWocp+pdf
(?
'Je LisZov S$stit$tion Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWlsp+pdf
(6
'Je Interface Se&re&ation Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWisp+pdf
6
'Je Dependency Inversion Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWdip+pdf
6!
-arbara LisZov g [iZipedia
JttpHWWen+FiZipedia+or&WFiZiW-arbarahLisZov
62
Inversion of Control Containers and tJe Dependency InBection Pattern g 5artin ;oFler
JttpHWWmartinfoFler+comWarticlesWinBection+Jtml
6"
2 t$torial on Service Locator patter FitJ implementation g 1+ S$Ban G 'Je Code ProBect
JttpHWWFFF+codeproBect+comW2rticlesW(6))?)W2Gt$torialGonGServiceGlocatorGpatternGFitJGimpleme
6*
Deco$plin& eLample in CT G StacZ #LcJan&e
JttpHWWstacZoverfloF+comWA$estionsW2266))WFJatGisGlooseGco$plin&GpleaseGprovideGeLamples
6(
Str$ct$re and Interpretation of Comp$ter Pro&rams g 2belson f S$ssman
JttpHWWmitpress+mit+ed$WsicpWf$llGteLtWbooZWbooZ+Jtml
66
Prod$ction of Lar&e Comp$ter Pro&rams G =erbert D+ -ennin&ton
JttpHWWs$nset+$sc+ed$WcsseW'#C=0P'SW!6?"W$sccse?"G(!W$sccse?"G(!+pdf
6)
Pair pro&rammin& g [I\IP#DI2
JttpHWWen+FiZipedia+or&WFiZiWPairhpro&rammin&
6?
'Je 0epository Pattern #Lample in CT G 0emondo -lo&
JttpHWWFFF+remondo+netWrepositoryGpatternGeLampleGcsJarpW


P&ina !)2 de !)*

66
5icrosoft DreamSparZ
JttpsHWWFFF+dreamsparZ+comW
)
Sistema de Control de /ersiones G [I\IP#DI2
JttpHWWes+FiZipedia+or&WFiZiWControlhdehversiones
)!
GitGSC5
JttpHWW&itGscm+comW
)2
Git=$b
JttpsHWW&itJ$b+comW
)"
Git GrapJic $ser Interfaces
JttpHWW&itGscm+comWdoFnloadsW&$is
)*
I&norar ficJeros en $n repositorio G +&itI&nore
JttpsHWWJelp+&itJ$b+comWarticlesWi&norin&Gfiles
)(
5sys&it
JttpHWWcode+&oo&le+comWpWmsys&itW
)6
'Fitter
JttpsHWWtFitter+comW
))
So$rce;or&e+4et
JttpHWWso$rcefor&e+netW
)?
C$c$mber
JttpHWWc$Zes+infoW
)6
Len&$aBe de pro&ramaci%n 0$by
JttpsHWWFFF+r$byGlan&+or&WesW
?
Spec;loF
JttpHWWFFF+specfloF+or&W
?!
GJerZin
JttpsHWW&itJ$b+comWc$c$mberWc$c$mberWFiZiWGJerZin
?2
Spec0$n
JttpHWWspecr$n+comW
?"
SpecLo&
JttpHWWFFF+speclo&+netW
?*
4$Get
JttpHWWFFF+n$&et+or&W
?(
Spec;loF Confi&$ration
JttpHWWFFF+specfloF+or&Wdoc$mentationWConfi&$rationW
?6
GJerZin lan&$aBe g C$c$mber g Git=$b
JttpsHWW&itJ$b+comWc$c$mberWc$c$mberWFiZiWGJerZin
?)
Spec;loF g SJarin& data betFeen -indin&s
JttpHWWFFF+specfloF+or&Wdoc$mentationWSJarin&GDataGbetFeenG-indin&sW


P&ina !)" de !)*

??
Spec;loF g P,C, classes inBection
JttpHWWFFF+specfloF+or&Wdoc$mentationWConteLtGInBectionW
?6
Spec;loF g ScenarioConteLt+C$rrent
JttpHWWFFF+specfloF+or&Wdoc$mentationWScenarioConteLt+C$rrentW
6
Spec;loF g Scoped -indin&s
JttpHWWFFF+specfloF+or&Wdoc$mentationWScopedG-indin&sW
6!
C$c$mber g 'a&s
JttpsHWW&itJ$b+comWc$c$mberWc$c$mberWFiZiW'a&s
62
Spec;loF Doc$mentation
JttpHWWFFF+specfloF+or&Wdoc$mentationW
6"
'eLtConteLt Class g 5S'est
JttpHWWmsdn+microsoft+comWenG$sWlibraryWmicrosoft+vis$alst$dio+testtools+$nittestin&+testconteLt+aspL
6*
2ssert Class g 5S'est
JttpHWWmsdn+microsoft+comWenG$sWlibraryWmicrosoft+vis$alst$dio+testtools+$nittestin&+assert+aspL
6(
<sin& tJe 2ssert classes in 5S'est
JttpHWWmsdn+microsoft+comWenG$sWlibraryWms!?2("+aspL
66
'estDriven+4et
JttpHWWFFF+testdriven+netW
6)
4Depend
JttpHWWFFF+ndepend+comW
6?
4Depend Code 5etrics
JttpHWWFFF+ndepend+comW;eat$res+aspLT5etrics
66
4Depend arA$itect$re and dependences #Lplorer
JttpHWWFFF+ndepend+comW;eat$res+aspLTDependencies/ieF
!
4Depend Code R$ery LinA
JttpHWWFFF+ndepend+comW;eat$res+aspLTCRL
!!
4Depend 'rend monitorin&
JttpHWWFFF+ndepend+comW;eat$res+aspLT'rend
!2
4Depend Dia&rams
JttpHWWFFF+ndepend+comW;eat$res+aspLTDia&rams
!"
4Depend Code Diff
JttpHWWFFF+ndepend+comWdochvshdiff+aspL
!*
Goo&le Pa&e 0anZ 2l&oritJm
JttpHWWFFF+sir&roane+netW&oo&leGpa&eGranZW
!(
Code metrics on co$plin&, dead code, desi&n flaFs and reGin&eneerin& g PatricZ SmaccJia g
Code-etter+com
JttpHWWcodebetter+comWpatricZsmaccJiaW2?W2W!(WcodeGmetricsGonGco$plin&GdeadGcodeGdesi&nGflaFsG
andGreGen&ineerin&W


P&ina !)* de !)*

!6
Layerin&, tJe Level metric and tJe Disco$rse of 5etJod g PatricZ SmaccJia g Code-etter+Com
JttpHWWcodebetter+comWpatricZsmaccJiaW2?W2W!Wlayerin&GtJeGlevelGmetricGandGtJeGdisco$rseGofG
metJodW
!)
Sin&le 0esponsability Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWsrp+pdf
!?
'Je ,penWClosed Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWocp+pdf
!6
'Je LisZov S$stit$tion Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWlsp+pdf
!!
'Je Interface Se&re&ation Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWisp+pdf
!!!
'Je Dependency Inversion Principle g 0obert C+ 5artin
JttpHWWFFF+obBectmentor+comWreso$rcesWarticlesWdip+pdf

Calidad de Software

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Calidad de Software

Caricato da

Copyright:

Formati disponibili

Evaluacin de la calidad de cdigo usando TDD

en el desarrollo de la lgica de negocio

Potrebbero piacerti anche