CAPTULO I

GENERALIDADES
1. GENERALIDADES
Este primer captulo sita en el contexto de la situacin actual de la Gestin de
Proyectos de software con enfoque gil, identifica los problemas encontrados y
plantea los objetios a lograr que sern delimitados por los alcances y aportes
del Proyecto de Grado!
1.1. Introduccin
El constante aance tecnolgico, los nueos conocimientos y la generacin de
tecnologas cada e" ms noedosas #acen que las diferentes reas de
ingeniera se encuentren en continua eolucin! $n rea de la ingeniera, que
adopta de forma rpida todos estos moimientos es la %ngeniera de &istemas'
esta ingeniera, para lograr sus objetios, #ace uso de metodologas,
#erramientas y t(cnicas que son elegidas y utili"adas segn sea el propsito
que se persigue!
)oy en da los sistemas de informacin se #an conertido en un producto de
consumo cada e" mayor! Esta situacin repercute en el mbito empresarial
#aciendo que las empresas sean cada e" ms exigentes en cuanto a las
especificaciones de caractersticas del software que precisan!
$n sistema de informacin, software, es obtenido a partir de un proyecto de
software' estos proyectos no siempre tienen una finali"acin exitosa, #ay casos
en los que concluyen sin cubrir todas las expectatias iniciales y otros inclusie
en los que no se concluyen!
*a Gestin de Proyectos es una t(cnica que permite controlar o monitori"ar el
aance de un proyecto, lo cual posibilita proeer los recursos necesarios para
su ptima finali"acin! &egn el tipo de metodologa que se utilice para reali"ar
el desarrollo de un proyecto, se tiene la Gestin de Proyectos con enfoque
+radicional y la Gestin de Proyectos con enfoque ,gil!
-
En el presente documento se desarrolla una #erramienta, que se #a bauti"ado
con el nombre de .gile&ucces&+ool, esta #erramienta se concibi bajo las
directrices y lineamientos de &crum, una metodologa gil, que en su categora
se encuentra entre las ms difundidas y utili"adas' tiene como principal
propsito la gestin de proyectos, de esta forma se pretende coadyuar la labor
de gestionar Proyectos &oftware con enfoque gil!
1.2. Antecedentes
En este apartado se reali"a una diferenciacin entre antecedentes del tema y
antecedentes de trabajos afines' el primero expone informacin, datos
#istricos y estadsticas, acerca de la reali"acin de Proyectos de &oftware as
tambi(n como de la Gestin de los mismos' el segundo muestra un resmen y
comparacin de trabajos que #an sido elaborados persiguiendo un objetio
similar al del presente Proyecto de Grado!
1.2.1. Antecedentes del Te!
*a gestin de proyectos tiene su origen y necesidad de profesionali"acin en el
mbito militar! .lrededor de los a/os 012s, 3ernard &c#rieer, considerado padre
de la gestin de proyectos y arquitecto de desarrollo de misiles balsticos
Polaris' desarroll el concepto de 4concurrencia5
-
, integrando los elementos del
plan de desarrollo en un solo programa y presupuesto ejecutndolos en paralelo
y no secuencialmente! .s consigui de manera considerable reducir los
tiempos de la ejecucin de proyectos!
En -678, en un congreso organi"ado por la 9+.:, se trat el tema de los
problemas en los proyectos de software, ya que estos siempre presentaban
retrasos de entrega, desiacin de la planificacin inicial, desbordamiento en
costo y algunos ni siquiera llegaban a su finali"acin! Este fenmeno fue
etiquetado como 4;risis del &oftware5
<
, y por primera e" se #abl acerca de la
creacin de un conocimiento para darle solucin, una 4%ngeniera del &oftware5!
1 Segn Bernard Schiever, concurrencia es la manera de integrar todos los componentes y elementos de una
planificacin en un solo presupuesto y programa de tal forma que su ejecucin sea en paralelo.
2 El trmino !crisis del soft"are# se acu$ en 1%&', en la primera conferencia organi(ada por la )*+,,
)rgani(acin del *ratado +tl-ntico del ,orte, so.re desarrollo de soft"are.
<
El nacimiento de la %ngeniera del &oftware #a sido el inicio del conocimiento
para el desarrollo de sistemas de informacin' este nueo conocimiento se
ciment sobre las prcticas coetneas utili"adas en otras ingenieras y en otros
mbitos como el desarrollo basado en procesos, a fin de que se garantice su
calidad de manera repetible y escalable' a su e" se ciment tambi(n sobre los
principios de calidad =la calidad resultante depende de la calidad en los
procesos empleados> y las pautas de gestin de proyectos predictias para
garanti"ar la eficiencia y el cumplimiento de pla"os y presupuestos!
Entre los a/os -681 y -661, la %ngeniera de &istemas se comien"a a edificar en
base a modelos de procesos especficos para software =%&9 6111?@, ;AA2s,
&P%;E, %&9 -001B> y aplicacin a los sistemas de informacin del patrn de
gestin de proyectos predictio aplicado en otras ingenieras =PA%, %PA.>!
En la d(cada de los 612s comien"a la difusin y aplicacin de los modelos y
metodologas para la %ngeniera de &istemas! *a respuesta en algunos mbitos
da buenos resultados y es faorable, pero en cambio, en otros genera una
r(plica dial(ctica que cuestiona la alide" de los modelos basados en procesos
y la gestin predictia para el desarrollo de sistemas de informacin, es as que
en el a/o <11- diecisiete crticos
@
de los modelos de desarrollo de software
=basados en procesos> conocados por Cent 3ecD, quien #aba publicado un
par de a/os antes el libro 4Extreme Programming Explained5
B
, se reunieron en
Salt Lake City =$ta# ? Estados $nidos> para tratar sobre t(cnicas y procesos
para desarrollar software! En la reunin se adopt el t(rmino de 4A(todos
,giles5 para definir a los m(todos que estaban surgiendo como alternatia a las
metodologas formales!
*os integrantes de la reunin resumieron los principios sobre los que se basan
los m(todos o metodologas alternatios en cuatro postulados, lo que #a
quedado denominado como el Aanifiesto ,gil EF.G%*EA.:%G1-H!
/ 0anifiesto 1gil, firmado por2 3ent Bec4, 0i4e Beedle, +rie van Benne4um, +listair 5oc4.urn, 6ard
5unningham, 0artin 7o"ler, 8ames 9renning, 8im :ighsmith, +ndre" :unt, ;on 8effries, 8on 3ern, Brian
0aric4, ;o.ert 5. 0artin, Steve 0ellor, 3en Sch"a.er, 8eff Sutherland y <ave *homas.
= 3ent Bec4, !Extreme Programming Explained, 1%%%. En este li.ro se e>pone una nueva metodolog?a
denominada Extreme Programming, @rogramacin E>trema.
@
En el Aanifiesto ,gil se expone lo siguiente ..Estamos poniendo al descubierto
nuevos mtodos para desarrollar software, hacindolo y ayudando a otros a
que los haan. ! aunque hay valor en los elementos de la derecha, valoramos
m"s los de la i#quierda..$EF.G%*EA.:%G1-H! En la Gigura -!-, se muestran los
postulados definidos en esta reunin' se puede obserar su inclinacin
#umanista
0
, para ellos los modelos y metodologas deben dar mayor alor a las
personas antes que a los procesos y #erramientas!
Gigura -!-I ;onclusiones Aanifiesto ,gil
GuenteI Extrado de EP.*.;%91JH
. partir de estas conclusiones, las tareas y actiidades que se reali"aban con
esta orientacin se empe"aron a constituir como las Aetodologas ,giles' entre
las principales y ms conocidas se puede mencionar las siguientesI .K =.gile
Katabase +ec#niques>, .A =.gile Aodeling>, .&K =.daptatie &oftware
Keelopment>, .$P =.gile $nifed Process ;ristal>, GKK =Geature Krien
Keelopment>, K&KA =Kynamic &ystems Keelopment Aet#od>, *ean &oftware
Keelopment, &;L$A, +KK =+est Krien Kesign>, M3reed, MP =eMtreme
Programming>!
;ada uno de ellos expone formas concretas de aplicacin de principios giles
en el desarrollo de software' algunos determinan cmo reali"ar las pruebas o la
duracin que emplean para desarrollar cada iteracin o el protocolo para
A El trmino !humanista# se refiere a que el >ito de un @royecto de Software depende m-s de la capacidad,
e>periencia y el entorno de las personas involucradas que de la documentacin y los procesos que se puedan
esta.lecer.
B
reali"ar las reuniones de trabajo, unos m(todos cubren reas concretas de la
ingeniera del software como ser el dise/o =p!ej! .K, .A>, otros se centran en la
gestin del proyecto =p!ej! .&K, .$P, ;ristal, K&KA, &;L$A y M3reed>, y otras
se orientan #acia la parte de desarrollo y pruebas =p!ej! MP, +KK>!
1.2.1.1. El "ro#le! de l! "roducti$id!d de l! industri! de so%t&!re
Kesde -66B la consultora norteamericana %he Standish &roup$ reali"a un
estudio llamado %he Chaos 'eport$ cuyo objetio es medir la efectiidad
lograda por los proyectos de software, en base a criterios tales comoI
;umplimiento y desiacin con respecto a metas de tiempo y costo
Porcentaje de funcionalidad til realmente lograda
. continuacin se muestra en la Gigura -!<, los resultados de los estudios
reali"ados sobre los proyectos de software comparados entre los a/os -66B y
<116!
Gigura -!<I Lesultados de Proyectos de &oftware comparados entre -66B y <116
Guente Aodificado de EF&+.:K%&)H
;omo es posible obserar en la Gigura -!<, #a existido un aumento constante
en el porcentaje de proyectos concluidos exitosamente, es decir que son
terminados dentro de los pla"os, costos y con la funcionalidad esperada' no
obstante el porcentaje de proyectos que tienen problemas, proyectos que no
cumplen con todas las expectatias y necesidades del cliente y son
cuestionados, o fracasan, es decir no son terminados, an persisten en
cantidades que no pueden pasar desapercibidas!
0
En promedio el aumento por a/o de la cantidad de proyectos que concluyen
exitosamente es peque/o, apenas superior al -N, lo que proyectando en el
tiempo se deduce que para llegar al 01N de proyectos terminados con (xito se
debera esperar un aproximado de -< a/os, a/o <1<1! &in embargo existen
adems otros antecedentes que ponen en duda incluso esta proyeccin!
. continuacin en la +abla -!- se reali"a una comparacin entre el porcentaje
de sobre?tiempo, tiempo adicional del estimado en la planificacin inicial de un
proyecto que se requiere para su conclusin, y la efectiidad, que se refiere a
las funcionalidades requeridas por el cliente que son logradas en el proyecto'
esta comparacin es reali"ada entre los a/os <111 y <11@!
+abla -!-I &obre?tiempo y efectiidad comparada entre <111 y <11@
2''' 2''(
So#re)tie"o "roedio 7@,11N 8<,11N
* de %uncion!lid!des re+uerid!s lo,r!d!s 7J,11N 0<,11N
GuenteI Extrado de EF&+.:K%&)H
&e puede obserar en la +abla -!-, que los proyectos de software sufren un
aumento en el porcentaje de sobre?tiempo as como tambi(n se obsera que
cada e" se logra menos de las funcionalidades esperadas! Esta situacin se
e reflejada en la Gigura -!@, donde se muestra la proporcin de
funcionalidades que los clientes declaran realmente usar en los productos de
software que reciben!
Gigura -!@I Guncionalidades desarrolladas en un proyecto de software y porcentaje de uso
GuenteI Aodificado de EF&+.:K%&)H
Esta situacin fue la que moti a Cent 3ecD a acu/ar la siguiente fraseI El
software falla en ser entreado...y falla en entrear valor$ E3E;C11H!
7
1.2.1.2. Des"l!-!ientos e incu"liientos en los "ro.ectos de so%t&!re
Kentro de los estudios reali"ados por %he Standish &roup$ se #an detectado
tambi(n otras cifras, que #acen referencia a despla"amientos e incumplimientos
en proyectos de software, estudios reali"ados sobre aproximadamente @1,111
proyectos' en estos estudios se toman en cuenta @ aspectos importantes que
sonI
Excedencia de ;ostos
Excedencia en calendario
Guncionalidad incluida en el proyecto
. continuacin en la +abla -!< se muestra el despla"amiento e incumplimiento
de los proyectos de software respecto a los @ aspectos mencionados!
+abla -!<I Kespla"amientos e %ncumplimientos de proyectos de software
As"ecto R!n,o de /edid! *Cu!nti%ic!cin
E0cedenci! en Costos
<1,11N 01,11N BJ,11N
0-,11N <11,11N @6,81N
<1-,11N OB11,11N -@,<1N
E0cedenci! en C!lend!rio
<1,11N 01,11N @<,<1N
0-,11N <11,11N 00,01N
<1-,11N OB11,11N -<,@1N
1uncion!lid!d incluid! en
el "roducto
1,11N <0,11N B,71N
<7,11N J0,11N B6,11N
J7,11N 66,11N @6,-1N
-11,11N -11,11N J,@1N
GuenteI Extrado de EF&+.:K%&)H
+al como se muestra en la +abla -!<, segn 4%he Standish &roup$ se obsera
queI
El BJN de los proyectos excede entre el <1N y 01N del costo estimado!
El @6,8N de los proyectos excede entre el 0-N y <11N del costo
estimado!
El -@,<N de los proyectos excede entre el <1-N y mas del B11N del
costo estimado!
J
El @<,<N de los proyectos excede entre el <1N y 01N de la duracin
estimada!
El 00,0N de los proyectos excede entre el 0-N y <11N de la duracin
estimada!
El -<,@N de los proyectos excede entre el <1-N y ms del B11N de la
duracin estimada!
El B,7N de los proyectos incluyen en el producto menos del <0N de la
funcionalidad esperada!
El B6N de los proyectos incluyen en el producto entre el <7N y J0N de
la funcionalidad esperada!
El @6,-N de los proyectos incluyen en el producto entre el J7N y 66N de
la funcionalidad esperada!
El J,@N de los proyectos incluyen en el producto el -11N de la
funcionalidad esperada!
1.2.1.(. 1!ctores detect!dos en los "ro.ectos de so%t&!re
El estudio reali"ado por %he Standish &roup$ tambi(n #a detectado una lista
de factores comunes y su porcentaje de incidencia entre los proyectos de
software exitosos y los proyectos de software con problemas, cuestionados!
+abla -!@I Gactores detectados en los proyectos de software exitosos
No. 1!ctor *
- $suario inolucrado -0,61N
< &oporte del niel superior -@,61N
@ ;lara definicin de requerimientos -@,11N
B .decuada planificacin 6,71N
0 Expectatias realistas 8,<1N
7 Plan del proyecto con #itos cercanos J,J1N
J &taff =equipo de desarrollo> competente J,<1N
8 &entido de propiedad de los temas 0,@1N
6 Pisin y objetios claros <,61N
-1 Equipo enfocado y trabajo fuerte <,B1N
-- 9tros factores -@,61N
GuenteI Extrado de EF&+.:K%&)H
8
;omo se io con anterioridad en la +abla -!@, se muestran los factores
detectados en los proyectos de software exitosos!
En la +abla -!B, se muestran los factores detectados en los proyectos de
software con problemas!
+abla -!BI Gactores detectados en los proyectos de software con problemas
No. 1!ctor *
- Galta de informacin por parte del $suario -<,81N
< Lequerimientos y especificaciones incompletas -<,@1N
@ ;ambios constantes de requerimientos y especificaciones --,81N
B Galta de apoyo a niel superior J,01N
0 %ncompetencia tecnolgica J,11N
7 Galta de recursos 7,B1N
J Expectatias no realistas 0,61N
8 9bjetios poco claros 0,@1N
6 +iempos irreales B,@1N
-1 :uea tecnologa @,J1N
-- 9tros factores <@,11N
GuenteI Extrado de EF&+.:K%&)H
&egn las +ablas -!@ y -!B, se puede obserar que cada uno de los factores
detectados tienen un porcentaje de incidencia positio y negatio
respectiamente en el desarrollo y eolucin de un proyecto de software, tener
la capacidad de detectar la ausencia o no de estos factores resulta una aliosa
#abilidad para potenciar el (xito de un proyecto e incrementar las posibilidades
en faor del mismo, no obstante no existe una frmula mgica que pueda
garanti"ar el (xito ya que cada proyecto presenta cualidades y caractersticas
que en conjunto lo #ace nico e irrepetible!
1.2.2. Antecedentes de Tr!#!2os A%ines
Kado que el presente trabajo trata del desarrollo de un &istema de %nformacin
para la Gestin de Proyectos de &oftware con Enfoque ,gil, se #a inestigado,
adems de trabajos de fin de carrera que comparten afinidad, acerca de las
#erramientas que se encuentran en el mercado y que comparten este cometido!
. continuacin se presenta un resumen y diferencias con el presente trabajo de
6
los trabajos afines y una descripcin y comparacin de las principales
caractersticas de las #erramientas inestigadas!
Entre los trabajos de fin de carrera se puede mencionar el siguienteI
Titulo3 4$sabilidad en una )erramienta de Gestin de Kesarrollo de
Proyectos &oftware5
A4o3 <118
Autor3 Aatas +oro %pin"a
Institucin3 $niersidad de ;#ile
Resuen3 &u finalidad es dise/ar e implementar la interfa" de usuario
de Painless +racDing ersin Feb, una #erramienta para gestin de
desarrollo de proyectos software' construida a partir de una plantilla
Excel! Para la obtencin del producto final utili"a una metodologa gil
orientada a la usabilidad, $?;K!
. continuacin en la +abla -!0, se muestra una comparacin de las diferencias
entre el presente Proyecto de Grado y el trabajo de fin de carrera antes
mencionado!
+abla -!0I Kiferencias entre el presente proyecto y el trabajo de fin de carrera inestigado
T5tulo
6Sistema de Informacin para
Gestin de Proyectos con
Enfoque gil7
6Usabilidad en una
Herramienta de Gestin de
Desarrollo de Proyectos
Software7
/etodolo,5!
!"lic!d!
Aetodologa gil para gestin de
proyectos software &crum!
Aetodologa gil orientada a la
usabilidad $?;K
O#2eti$o
Kesarrollar una #erramienta
orientada a los gerentes y
lderes de proyectos de software
que permita reali"arI gestin de
reuniones as como de los
integrantes del proyecto,
planificacin y seguimiento de
tareas!
Kesarrollar una #erramienta
orientada a equipos de desarrollo de
software que permita reali"ar la
planificacin y seguimiento de
tareas!
GuenteI Elaboracin Propia
Entre las #erramientas inestigadas disponibles en el mercado, libres de pago
-1
de licencias, se encontraron la siguientesI
1.2.2.1. S"rintoeter
&printometer es una aplicacin de escritorio desarrollada para gestin, y
seguimiento de proyectos giles! &printometer es una aplicacin Findows!
Legistra las #istorias de usuario =funcionalidades>, las tareas, estimaciones y su
asignacin a las personas del equipo! &e puede llear el seguimiento diario,
generar grficos (urn )own
7
, exportar los datos a Aicrosoft Excel! *os datos de
cada proyecto se pueden guardar en un fic#ero local, o en un seridor de base
de datos que los autores del programa #an puesto en su sitio web!
Kesarrollada por un equipo de programadores rusos, para emplearla en sus
proyectos, la #an liberado como freeware
*
! EF&PL%:+9AH
1.2.2.2. 8"l!nner
Mplanner, #erramienta dise/ada para planificacin y seguimiento de proyectos
que usan e+treme ,rorammin =MP>! &e basa en la definicin de
caractersticas que son descompuestos posteriormente en tareas con
estimaciones de t(rmino correspondiente! Esto de manera de er cules de las
caractersticas necesitarn renegociaciones con el cliente! Esta #erramienta fue
creada para soportar esta ltima funcin!
Qa que esta #erramienta se basa en e+treme ,rorammin est orientada
especialmente para los programadores! EFMP*.::ELH
1.2.2.(. 9ersionOne
Persion9ne es una #erramienta web que permite la utili"acin de diferentes
metodologas gilesI &crum, MP, K&KA y .gile $P! *as organi"aciones tienen
la posibilidad de adquirir una copia para instalarla en sus instalaciones o tener
la misma funcionalidad en el sitio web de Persion9ne! Ke fcil utili"acin, posee
capacidades de seguimiento y generacin de informes, planificacin,
seguimiento y reisin de sprints y de tareas EFPEL&%9:9:EH!
& Bos gr-ficos Burn Down, son gr-ficos que muestran el avance, de forma que lo que se o.tiene es la
visi.ilidad no lo que se ha avan(ado sino de lo que falta por terminar.
C Freeware2 tipo de soft"are de computadora que se distri.uye sin costo, disponi.le para su uso y por
tiempo ilimitado http2DDes."i4ipedia.orgD"i4iD7ree"are
--
1.2.2.:. Scru;
&crumR es una #erramienta clienteSseridor, que puede ser utili"ada por
peque/os y grandes equipos para gestionar proyectos! $tili"a una base de
datos &T* &erer y se puede utili"ar para administrar arios proyectos
utili"ando una metodologa gil! *e permite definir los elementos del 3acDlog del
Producto =#istorias de usuario>, crear y gestionar &prints, gestin de tareas y
seguimiento del progreso del proyecto EF&;L$ARH!
1.2.2.<. ScruDes=
&crumKesD, #erramienta rica en elementos isuales, creada por una empresa
de la Lepblica Esloaca, ayuda en la gestin de proyectos con &crum! Posee
capacidades de gestin de #istorias de usuario, planificacin y seguimiento de
sprints, registro seguimiento y asignacin de tareas, generacin de reportes y la
posibilidad de exportar datos a formato A& Excel EF&;LKE&CH!
1.(. Pl!nte!iento del Pro#le!
El tema en cuestin representa una preocupacin continua para los
profesionales dedicados al desarrollo de programas de computadora, por lo que
a continuacin se reali"a una descripcin de la situacin actual detectado por la
autora!
1.(.1. Situ!cin Actu!l
&egn una encuesta reali"ada, mostrada en el .nexo ;, sobre un grupo de 7
personas, profesionales del rea de +ecnologa de la %nformacin dedicados al
desarrollo de sistemas computacionales, con una media de aproximadamente
-- a/os de experiencia en desarrollo de software, se #a podido identificar que
en general se utili"a A& Project o una plantilla A& Excel para reali"ar la gestin
de un proyecto de software!
*a utili"acin de una plantilla Excel para gestin gil de un proyecto de software
es oportuno cuando el proyecto gestionado tiene un tama/o peque/o
8
, pero
' Se determina el tama$o de un proyecto de soft"are pequeo cuando su estimacin de duracin no supera los =
meses de desarrollo y la cantidad de integrantes del equipo no supera en nmero a /EDF1.
-<
resulta conflictio cuando se trata de proyectos de tama/o mediano
6
ya que se
debe aumentar el control sobre el crecimiento de la plantilla para eitar generar
informacin errnea!
*a #erramienta A& Project, #a sido dise/ada orientada a planificacin
anticipada de proyectos, este proceso es propio de la gestin predictia de
proyectos, metodologas tradicionales! *a gestin gil de proyectos reali"a la
planificacin de forma iterada, en cada uno de los ciclos en los que es
desarrollado un proyecto! .dems A& Project no cubre actiidades de gestin y
seguimiento para un proyecto!
&egn el conocimiento y utili"acin de #erramientas que apoyan la gestin de
proyectos de software se #a podido detectar, segn la encuesta reali"ada, que
en general estas #erramientas no son de fcil utili"acin o no cuentan con todos
los componentes que requieren los profesionales que las usan para reali"ar su
labor!
.dems se #a podido detectar tambi(n que existe una amplia inclinacin #acia
el uso de una #erramienta dedicada para gestin de proyectos, que incluya
cualidades colaboratias, accesible desde una red pblica, posibilite el eno de
correos electrnicos!
$n aspecto importante que se #a podido identificar es la necesidad de inclusin
de ciertas caractersticas en una #erramienta para gestin de proyectos de
software!
.#ora bien las personas, empresas y departamentos de empresas ms grandes
dedicadas al desarrollo de sistemas de informacin que no utili"an #erramientas
para la gestin de proyectos de software, reali"an las tareas de gestin de
proyectos de forma manual, en apuntes fortuitos e incluso de forma mental!
Esta situacin afecta el desenolimiento de los proyectos de software de forma
que se pueden obiar u olidar requerimientos o aspectos importantes del
proyecto, no reali"ar un seguimiento adecuado sobre los puntos expuestos a lo
% Se determina el tama$o de un proyecto de soft"are mediano cuando su estimacin de duracin no supera los 1G
meses de desarrollo y la cantidad de integrantes del equipo no supera en nmero a &EDF2.
-@
largo de las reuniones reali"adas, obiar u olidar tareas e incluso reali"arlas
ms de una e", no es posible reali"ar el seguimiento preciso de cada iteracin
del proyecto y el seguimiento sobre la eolucin de mismo' este panorama se
da especialmente cuando los proyectos no son lleados a cabo por personas,
que adems de tener el conocimiento, cuenten con un recorrido y experiencia
en gestin de proyectos' en consecuencia afecta tambi(n a la toma de
decisiones acerca del proyecto y no se puede determinar con antelacin el
aance real de un proyecto!
*a no utili"acin de #erramientas para gestin de proyectos de software se da
por arios motios internos y externos de un equipo de desarrollo, pero
principalmente porque estas #erramientas no pueden ser adoptadas debido a
que las mismas son elaboradas si bien siguiendo la teora que dictan las
metodologas giles tambi(n segn las necesidades del lugar donde son
reali"adas!
;uando las tareas de gestin son reali"adas de forma manual implica que se
debe dedicar una cantidad de tiempo para ello!
*a aplicacin de una Aetodologa ,gil para un Proyecto de &oftware tiene uno
de sus intereses en el desarrollo rpido de aplicaciones software, esta condicin
da lugar a la informalidad en la ejecucin de las tareas que dicta la gestin de
proyectos con enfoque gil ya que 4por falta de tiempo5 y desorgani"acin, las
tareas de gestin no son reali"adas con pertinencia e incluso en otros casos no
son reali"adas y esto da lugar a la generacin de informacin errnea acerca
del estado de un proyecto!
1.(.2. Pro#le! Princi"!l
$na e" presentados los antecedentes y expuesta la situacin actual, se
describe el problema central como sigue a continuacinI
-B
L! desor,!ni-!cin
-1
en l! e2ecucin de t!re!s . !cti$id!des de
,estin de "ro.ectos de so%t&!re +ue utili-!n l! etodolo,5! Scru>
di%icult! l! o#tencin de un "!nor!! %i!#le . o"ortuno !cerc! del
est!do de los "ro.ectos ,estion!dos.
Konde se entiende que el t(rmino 4dificultad5 #ace referencia al siguiente
conceptoI conjunto de circunstancias por las que no se puede #acer, entender o
conseguir una cosa sin emplear muc#a #abilidad, inteligencia o esfuer"o!
1.(.(. Pro#le!s Secund!rios
%dentificado el problema principal y en base a los antecedentes y situacin
actual preiamente descritos, y para completar el planteamiento del problema
del presente trabajo, se detalla a continuacin los problemas secundarios!
El crecimiento y eolucin, no controlados, de los requerimientos y los
cambios reali"ados en el transcurso del desarrollo de un proyecto de
software propician la p(rdida de la isin inicial propuesta para el
producto de software esperado!
*a informalidad en la ejecucin de las actiidades repetitias de gestin
de los ciclos iteratios en los que se construye un sistema de informacin
causa desorgani"acin en la ejecucin de estas actiidades de gestin y
dificulta el seguimiento y control sobre el equipo que desarrolla el
proyecto de software!
*a desorgani"acin en la reali"acin y coordinacin de reuniones dentro
de un proyecto de software, as como de los puntos o aspectos
acordados en las mismas, dificulta la cuantificacin y formali"acin de las
tareas que deben ser reali"adas a partir de una reunin, lo cual aporta
inconeniencia a que no se tenga bien en claro qu( es lo que se debe
#acer!
1G Ba desorgani(acin presente en situaciones cuando !por falta de tiempo# no se ejecutan con pertinencia las
actividades de gestin de proyectos de soft"are yDo tam.in cuando no se conoce con amplitud los procesos de
aplicacin de la metodolog?a Scrum.
-0
*a falta de organi"acin e informalidad en la asignacin, seguimiento y
cumplimiento de las tareas en el desarrollo de un proyecto de software
por parte del equipo que lo desarrolla, conduce a la ausencia de
coordinacin y trabajo colaboratio!
*a poca informacin #acia los nieles superiores del equipo de
desarrollo' ejecutios, gerentes, jefes y lderes de los proyectos de
software' acerca del trabajo asignado, reali"ado y pendiente, y la
disponibilidad de tiempo para planificar y asignar nueo trabajo produce
la saturacin #acia algunos integrantes del equipo de desarrollo!
1.:. De%inicin de O#2eti$os
. partir de los problemas presentados en la anterior seccin, se formulan los
objetios a los que responde la reali"acin del presente trabajo!
1.:.1. O#2eti$o Gener!l
Des!rroll!r un Siste! de In%or!cin "!r! Adinistr!cin .
Se,uiiento de !cti$id!des de Gestin de Pro.ectos de So%t&!re +ue
utilicen l! etodolo,5! Scru> +ue "osi#ilite l! o#tencin o"ortun!
de re"ortes so#re el est!do . e$olucin de los "ro.ectos
,estion!dos.
1.:.2. O#2eti$os Es"ec5%icos
.utomati"ar las actiidades de planificacin, seguimiento y reisin de
los ciclos iteratios en los que se desarrolla un proyecto de software con
enfoque gil con el propsito de coadyuar en la formali"acin de
ejecucin de actiidades de gestin de los ciclos iteratios y por
consiguiente al seguimiento y control sobre el equipo que desarrolla el
proyecto de software!
-7
.utomati"ar las actiidades de registro y administracin de
requerimientos de un proyecto de software con enfoque gil con objeto
de eitar la p(rdida de la isin con la que fue concebido el proyecto!
Permitir la administracin de reuniones y puntos acordados que se
reali"an en un proyecto de software de forma automati"ada con el fin de
coadyuar a la organi"acin en la reali"acin y coordinacin de
reuniones!
.utomati"ar las actiidades de registro, asignacin y seguimiento de
tareas de un proyecto de software para propiciar organi"acin y
formali"acin en la reali"acin y cumplimiento de tareas!
Proeer un mecanismo para la consulta automati"ada acerca del trabajo
asignado, pendiente y reali"ado sobre cada uno de los integrantes del
equipo de un proyecto de software para los nieles superiores de un
equipo de desarrollo!
1.<. ?usti%ic!cin
Kentro de lo que contempla la justificacin para la elaboracin de presente
Proyecto a continuacin se exponen tres aspectos importantes, los cuales
permiten comprender la energadura del mismo, estos sonI justificacin t(cnica,
social y prctica!
1.<.1. ?usti%ic!cin T@cnic!
El desarrollo del sistema .gile&ucces&+ool incorpora procesos automati"ados
para coadyuar la labor de gestionar Proyectos de &oftware con enfoque gil!
*a utili"acin de &crum, una metodologa gil para gestin de proyectos
software, como una #erramienta que permite el desarrollo de software
flexibili"ando los requerimientos del usuario para la obtencin de un sistema
acorde a las necesidades, que ayuda a conocer en todo momento el estado de
un proyecto y permite reali"ar un seguimiento oportuno acerca del mismo!
.plicar una arquitectura orientada a aplicaciones web y #erramientas
-J
tecnolgicas, complementarias con la arquitectura' tecnologa de ltima
generacin con bastantes funcionalidades para la construccin del sistema de
informacin, que son acordes a la metodologa utili"ada!
1.<.2. ?usti%ic!cin Soci!l
En el aspecto social el presente trabajo contribuye a facilitar la labor de los
lderes, jefes de proyectos software con enfoque gil, que son quienes deben
llear las riendas as como la responsabilidad sobre el mismo!
Por lo general los jefes de proyectos son las personas que #acen de puente de
comunicacin entre los clientes, los gerentes y los desarrolladores'
consecuentemente el presente Proyecto de Grado en su conjunto proee una
#erramienta para apoyar el trabajo reali"ado por los jefes de proyectos!
1.<.(. ?usti%ic!cin PrActic!
En nuestro contexto existen muc#os profesionales dedicados al desarrollo de
&istemas de %nformacin pero es una realidad que muy pocos cuentan con la
experiencia necesaria para la ejecucin de las tareas de Gestin de Proyectos
&oftware, es por ello que el presente proyecto pretende proporcionar un
producto de software que sira como instrumento para apoyar el cumplimiento
de las tareas de gestin de proyectos de sistemas de informacin que apliquen
la metodologa &crum!
1.B. Alc!nces . A"ortes
En esta seccin se detallan los alcances del presente Proyecto de Grado y el
alor de aporte que su desarrollo proee!
1.B.1. Alc!nces
El presente proyecto est orientado a la gestin de proyectos software de forma
que se reali"a administracin y seguimiento sobre las actiidades de gestin
reali"adas en los mismos!
&ern tomados en cuenta para la elaboracin del presente trabajo los aspectos
que est(n directamente relacionados al desarrollo y gestin de proyectos de
-8
software con enfoque gil, y ms an precisamente para proyectos de software
que apliquen &crum como metodologa de gestin gil!
Por aspectos de comunicacin entre los inolucrados de un proyecto de
software y accesibilidad oportuna a la informacin acerca del mismo' este
proyecto se orienta #acia la obtencin de un &istema de %nformacin construido
sobre una arquitectura Feb!
1.B.2. A"ortes
*a utili"acin de la metodologa &crum con una adaptacin de la Aetodologa
Programacin Extrema para la gestin y desarrollo del proyecto
respectiamente, arquitectura y tecnologa de ltima generacin es sin lugar a
duda un aporte importante tanto en t(rminos de dise/o, rendimiento y calidad,
adems de proeer una documentacin era" sobre el uso de las mismas!
-6
CAPTULO II
/ARCO TECRICO
2. /ARCO TECRICO
En este captulo se explica los conceptos utili"ados durante el desarrollo del
proyecto, las metodologas aplicadas para gestin y desarrollo del mismo, y la
tecnologa y #erramientas utili"adas para la construccin del sistema de
informacin obtenido!
2.1. In,enier5! de Siste!s
*a ingeniera de &istemas o tambi(n llamada %ngeniera de &oftware es una
disciplina del rea de la %nformtica o ;iencias de la ;omputacin, que ofrece
m(todos y t(cnicas para desarrollar y mantener software de calidad
--
que
resuele problemas de todo tipo EPLE&&A.:10H!
. continuacin se muestran dos definiciones sobre %ngeniera del &oftware que
se #an tomado como directrices en el desarrollo del presente Proyecto de
Grado!
)efinici.n -
%ngeniera de &oftware es el estudio de los principios y metodologas para
desarrollo y mantenimiento de sistemas de software ERE*C9P%+RJ8H!
)efinici.n /
%ngeniera de software es la aplicacin prctica del conocimiento cientfico en el
dise/o y construccin de programas de computadora y la documentacin
asociada requerida para desarrollar, operar =funcionar> y mantenerlos! &e
conoce tambi(n como desarrollo de software o produccin de software
E39)EAJ7H!
. partir de la primera definicin de %ngeniera de &oftware se reali"a un estudio
de principios y metodologas para el anlisis, dise/o, desarrollo e
11 Soft"are de calidad2 *rmino referido a Sistemas de Hnformacin que principalmente satisfacen las necesidades
del usuario final. Ba calidad de un sistema se puede evaluar segn los siguientes aspectos2 funcionalidad,
confia.ilidad, usa.ilidad, eficiencia, manteni.ilidad y porta.ilidad
<1
implementacin de sistemas de informacin, preia seleccin de aquellos que
soportan terica y fundamentalmente la reali"acin del presente trabajo'
posteriormente en base a la segunda definicin descrita con anterioridad, se
reali"a la aplicacin prctica del conocimiento adquirido para el dise/o y
construccin del sistema de informacin esperado como resultado del estudio
reali"ado!
.#ora bien se puede diferenciar entre sistemas de informacin que concluyen
exitosamente y sistemas de informacin que presentan problemas o fracasan
de la siguiente formaI
2.1.1. Siste!s de In%or!cin +ue conclu.en e0itos!ente
$n sistema de informacin se desarrolla con (xitoI
;uando satisface las necesidades de las personas que lo utili"an!
;uando funciona impecablemente durante muc#o tiempo!
;uando es fcil de modificar o incluso es ms fcil de utili"ar!
Puede cambiar todas las cosas y de #ec#o las cambia para mejorar' para tener
(xito al dise/ar y construir un software se necesita un enfoque de ingeniera
EPLE&&A.:10H!
2.1.2. Siste!s de In%or!cin +ue "resent!n "ro#le!s o %r!c!s!n
$n sistema de informacin presenta problemas, fracasaI
;uando los usuarios no se quedan satisfec#os!
;uando es propenso a errores!
;uando es difcil de cambiar e incluso mas difcil de utili"ar!
Pueden ocurrir y de #ec#o ocurren erdaderos desastres EPLE&&A.:10H!
2.1.(. I"ort!nci! de los Siste!s de In%or!cin
*os sistemas de informacin en la actualidad son importantes porque afectan
muy de cerca a cualquier aspecto de nuestra ida y est muy extendido en
nuestro comercio, cultura y en nuestras actiidades cotidianas EPLE&&A.:10H!
<-
2.1.:. Cl!si%ic!cin Are!s del so%t&!re
*os sistemas de informacin pueden aplicarse en cualquier situacin en la que
se #aya definido preiamente un conjunto especfico de pasos procedimentales,
es decir un algoritmo! . continuacin se nombran las categoras, reas
gen(ricas significatias para las aplicaciones de software que indican la
amplitud de las aplicaciones potenciales EPLE&&A.:10HI
&oftware de sistemas!
&oftware de tiempo real!
&oftware de gestin!
&oftware de ingeniera y cientfico!
&oftware de computadoras personales!
&oftware empotrado!
&oftware basado en web!
&oftware de inteligencia artificial!
&egn la clasificacin mostrada el presente trabajo concluye con la obtencin
de un producto de software de computadoras personales y basado en web!
2.1.<. Proceso ) @todos ) Derr!ient!s
*a ingeniera de sistemas es una tecnologa multicapa, basada en un enfoque
de calidad, proceso, m(todos y #erramientas' como se muestra ms adelante
en la Gigura <!-, se puede obserar las capas de la %ngeniera de &istemas!
;ualquier enfoque de ingeniera =incluida la ingeniera de sistemas> debe
apoyarse sobre un compromiso de organi"acin de calidad!
El fundamento de la ingeniera de sistemas es la capa de proceso! El proceso
de la ingeniera de sistemas es la unin que mantiene juntas las capas de
tecnologa y que permite un desarrollo racional y oportuno de la ingeniera de
sistemas! El proceso define un marco de trabajo para un conjunto de reas
clae de proceso que se deben establecer para la entrega efectia de la
tecnologa de la ingeniera de sistemas! *as reas clae del proceso forman la
base de control de gestin de proyectos de software y establecen el contexto en
<<
el que se aplican los m(todos t(cnicos, se obtienen productos del trabajo
=modelos, documentos, datos, informes, formularios, etc!>, se establecen #itos,
se asegura la calidad y el cambio se gestiona adecuadamente!
Gigura <!-I ;apas de la %ngeniera de &istemas
GuenteI Extrado de EPLE&&A.:10H
*os m(todos de la ingeniera de sistemas indican cmo construir t(cnicamente
el producto de software! *os m(todos abarcan una gran gama de tareas que
incluyen anlisis de requisitos, dise/o, construccin de programas, pruebas y
mantenimiento! *os m(todos de la ingeniera de sistemas dependen de un
conjunto de principios bsicos que gobiernan cada rea de la tecnologa e
incluyen actiidades de modelado y otras t(cnicas descriptias!
*as #erramientas de la %ngeniera de &istemas proporcionan un enfoque
automtico o semiautomtico para el proceso y para los m(todos! ;uando se
integran #erramientas para que la informacin creada por una #erramienta la
pueda utili"ar otra, se establece un sistema de soporte para el desarrollo del
software llamado ingeniera del software asistida por computadoras =;.&E>
EPLE&&A.:10H!
2.1.B. /odelo
*a definicin de modelo tiene diferentes significados que aran segn el mbito
en el que se est trabajando, para este caso en el mbito de ingeniera de
sistemas se define de la siguiente forma! En primera instancia, un modelo es la
representacin de un objeto, concepto o sistema real de tal forma que an
siendo distinto de la entidad que representa, puede imitar su funcionamiento ySo
<@
arios atributos de (ste' un modelo puede ser descriptio, para explicar ySo
comprender, o un modelo puede ser prescriptio, para predecir ySo duplicar el
comportamiento caracterstico de un sistema E.G$%*.LU;.V.&6-H! En
segunda instancia un modelo para que sea de alor en el aporte al
conocimiento tiene que proeer tres atributos importantesI Primero, debe ser
realista, es decir, debe mostrar una aproximacin ra"onable, el cual debe
contener las propiedades y los elementos ms importantes del sistema!
&egundo, el modelo debe ser sencillo en su comprensin! Q tercero, la precisin
y la exactitud no siempre an juntos, ya que un niel de precisin mayor a la
debida puede causar inexactitudes en los resultados, por ello es importante
tomar en cuenta la identificacin de los elementos y definirlos estableciendo las
principales relaciones entre ellos, lo cual es de suma importancia ya que el
mejor modelo es el ms til!
Para resoler los problemas reales de una industria, un ingeniero de software o
un equipo de ingenieros debe incorporar una estrategia de desarrollo que
acompa/e al proceso, m(todos y capas de #erramientas descritos en el
apartado <!-!0! Esta estrategia a menudo se llama Aodelo de Proceso o
paradigma de ingeniera de sistemas! &e selecciona un modelo de proceso
para la ingeniera del software segn la naturale"a del proyecto y de la
aplicacin, los m(todos y las #erramientas a utili"arse, y los controles y
entregas que se requieren EPLE&&A.:10H!
&egn la naturale"a y la aplicacin del presente proyecto se #a optado por la
seleccin de una metodologa gil, que ms adelante ser explicada con mayor
detalle, que por el conjunto de cualidades que la conforman se posiciona en la
segunda y tercera capas de la %ngeniera de &istemas, ilustracin mostrada en
la Gigura <!-, seccin <!-!0!
2.2. Gestin de Pro.ectos So%t&!re
&e considera Proyecto a la ejecucin de un trabajo que adems de requerir
personas, recursos y ejecucin controlada' es un desarrollo nico, desde la
perspectia de gestin predictia, y se desarrolla en un marco temporal
<B
preestablecido! +ambi(n se define proyecto como un conjunto nico de
actiidades necesarias para producir un resultado definido en un rango de
fec#as determinado y con una asignacin especfica de recursos! $n proyecto
tiene objetios y caractersticas nicas!
*a gestin de proyectos software implica la planificacin, superisin y control
del personal, del proceso y de los eentos que ocurren mientras eoluciona el
software desde la fase preliminar a la implementacin operacional
EPLE&&A.:10H!
*as personas que reali"an la gestin de proyectos software de algn modo son
todos los inolucrados en el mismo, pero el mbito de las actiidades de gestin
ara en funcin de la persona que las reali"a! $n ingeniero de software
gestiona sus actiidades del da a da, planificando superisando, y controlando
las tareas t(cnicas! *os gestores del proyecto planifican, superisan y controlan
el trabajo de un equipo de ingenieros de software! *os gestores expertos
coordinan la relacin entre el negocio y los profesionales del software
EPLE&&A.:10H!
Ke forma general la gestin de proyectos abarca principalmente cuatro
elementosI el personal, el producto, el proceso y el proyecto! El personal debe
estar organi"ado para desarrollar el trabajo del software con efectiidad! *a
comunicacin con el cliente debe ocurrir para que se comprendan el alcance del
producto y los requisitos! Kebe seleccionarse el proceso adecuado para el
personal, y el producto! El proyecto debe planificarse estimando el esfuer"o y el
tiempo para cumplir las tareas' definiendo los productos del trabajo,
estableciendo puntos de control de calidad y estableciendo mecanismos para
controlar y superisar el trabajo definido en la planificacin EPLE&&A.:10H!
$n plan de proyecto, desde la perspectia tradicional, se reali"a al comien"o de
las actiidades de gestin! El plan define el proceso y las tareas a reali"ar, el
personal que reali"ar el trabajo y los mecanismos para ealuar los riesgos,
controlar el cambio y ealuar la calidad!
<0
2.2.1. I"ort!nci! de l! Gestin de Pro.ectos de So%t&!re
*a construccin de software de computadoras es una labor compleja,
particularmente si participa muc#a gente trabajando durante un periodo de
tiempo relatiamente largo! Esta es la ra"n por la cual los proyectos de
software necesitan ser gestionados EPLE&&A.:10H!
:unca se tiene la completa seguridad de que el plan de proyecto es correcto
#asta que no se entrega un producto de alta calidad dentro del presupuesto y
del tiempo! &in embargo un gestor de proyectos #ace lo correcto cuando
estimula al personal para trabajar centrando su atencin en las necesidades de
cliente y en la calidad del producto, como un equipo efectio EPLE&&A.:10H!
2.2.2. Gestin Tr!dicion!l de Pro.ectos So%t&!re
*a gestin de proyectos predictia o clsica es una disciplina formal de gestin,
basada en la planificacin, ejecucin y seguimiento a tra(s de procesos
sistemticos y repetibles! Establece como criterios de (xitoI obtener el producto
definido, en el tiempo preisto y con el coste estimado! .sume que el proyecto
se desarrolla en un entorno estable y predecible! Kiide el desarrollo en fases a
las que considera ;iclo de Pida, con una secuencia de tipoI iniciali"acin,
planificacin, ejecucin, seguimiento y control, y cierre! . continuacin se
muestra en la Gigura <!<, el ;iclo de Pida de los procesos que interienen en un
Gestin de Proyectos +radicional!
Gigura <!<I Grupo de procesos de la gestin de proyectos tradicional
GuenteI Extrado y +raducido de EPA39C1BH
*os grupos de procesos no son fases, son un conjunto integrado de procesos
<7
aplicados de forma iteratia en todo el proyecto y reisados segn sea
necesario!
El resultado esperado en una gestin tradicional es desarrollar un plan, y
mantener el cronograma y los recursos planificados!
2.2.(. Gestin E,il de Pro.ectos de So%t&!re
En los proyectos de software giles en los cuales adems de un conjunto de
alores que #an apoyado la transicin rpida y robusta de las ideas en
innoaciones, el t(rmino gil puede expresarse tambi(n como un enfoque
general sobre entregar software de forma incremental e iteratia! Ke esta
manera la definicin de gil, no slo describe lo que los equipos tratan de ser,
sino tambi(n la forma en que tratan de llegar a ese objetio! ,gil se refiere con
frecuencia como un enfoque basado en el alor, en comparacin con el enfoque
tradicional!
El ciclo de ida de un proyecto gil de manera general se muestra a
continuacin en la Gigura <!@, donde de forma ilustratia se llega #asta el niel
de ejecucin mas simple, tareas, dentro de un proyecto desde el niel ms alto
que es la ejecucin del proyecto en s!
Gigura <!@I ;iclo de Pida Proyecto ,gil
GuenteI Extrado y +raducido de E&*%:GELU3L9KEL%;C18H
<J
+omando posicin en el niel ms alto se comien"a con la planificacin del
proyecto que da inicio a la reali"acin de las diferentes ersiones que
eolucionan #asta lograr el objetio y isin del producto' a su e" cada una de
las ersiones comien"an con una planificacin que dan inicio a diferentes
iteraciones que eolucionan #asta lograr el objetio de la ersin' de la misma
forma cada iteracin comien"a con su respectia planificacin que da inicio a la
ejecucin del trabajo reali"ado diariamente que eoluciona #asta cumplir el
objetio de la iteracin y da lugar a la presentacin del incremento obtenido'
finalmente el trabajo reali"ado en un da comien"a con una reunin corta en la
cual se planifica lo que se reali"ar en el da acto que da inicio a la reali"acin y
finali"acin de cada una de las tareas que se reali"arn esto eoluciona en el
transcurso del da de manera que a la finali"acin del mismo se reali"a la
actuali"acin del incremento para la iteracin!
$na e" explicado el ciclo de ida de una proyecto gil se procede a la
definicin de gestin gil de proyectos de software, describiendo sus principales
conceptos que la diferencian de la gestin tradicional!
*a gestin gil, de proyectos software tiene como objetio dar garantas a las
demandas principales de la actualidadI alor, reduccin del tiempo de
desarrollo, agilidad, flexibilidad y fiabilidad!
2.2.(.1 9!lor
En los mercados donde se debe dar el mayor alor posible al producto cuando
(ste debe su ra"n a la %nnoacin y Glexibilidad!
a> %nnoacinI ;apacidad de innoacin continua, lan"amiento continuo de
noedades que compiten con los productos de otras empresas que tambi(n
estn en continua innoacin!
b> GlexibilidadI El producto no slo es alioso por su alor en el momento del
lan"amiento, sino tambi(n por su capacidad de adaptacin y eolucin a tra(s
de actuali"aciones y ampliaciones!
<8
2.2.(.2 Reduccin del Tie"o de Des!rrollo
*as estrategias de la gestin gil para producir resultados en menos tiempo que
la gestin tradicional se basan principalmente en el solapamiento de las fases
de desarrollo y la entrega temprana de las primeras partes del producto, que
corresponden con las de mayor urgencia para el cliente, de forma que puede
lan"ar la primera ersin en el menor tiempo posible!
2.2.(.( A,ilid!d
*a gestin de proyectos gil denomina agilidad a la capacidad y #abilidad para
producir partes completas del producto en periodos brees de tiempo, esto
quiere decir reali"ar peque/as entregas de partes completamente funcionales
en rangos de tiempo que no exceden a las 8 semanas!
2.2.(.: 1le0i#ilid!d
Glexibilidad en gestin de proyectos gil es la capacidad para adaptar la forma y
el curso del proyecto a las caractersticas del mismo y a la eolucin de los
requisitos segn lo demande el usuario!
2.2.(.< 1i!#ilid!d
*a gestin gil no tiene un carcter predictio o de anticipacin! :o conoce de
antemano el detalle del producto que se a a desarrollar, y por eso su objetio
no es la fiabilidad en el cumplimiento de los planes, sino en el alor del
resultado!
*os procesos de la gestin tradicional son buenos cuando consiguen desarrollar
de forma repetible los productos especificados en el tiempo y con los costes
preistos! *os procesos de la gestin gil son buenos, cuando consiguen
entregar de forma temprana y continua alor innoador!
*a gestin gil a diferencia de la tradicional muestra las preferencias resumidas
en el manifiesto gilI
. las personas y su interaccin por encima de los procesos y las
#erramientas!
<6
*a colaboracin con el cliente frente a la negociacin contractual!
&oftware que funciona frente a especificaciones y documentaciones
detalladas!
;apacidad de respuesta al cambio sobre el seguimiento a un plan!
2.(. /etodolo,5!s E,iles
*os m(todos giles son estrategias de desarrollo de software que promueen
prcticas que son adaptatias en e" de predictias, centradas en las personas,
iteratias, orientadas #acia las prestaciones y #acia las entrega, de
comunicacin intensia, y que requieren que el cliente se inolucre en forma
directa!
*as metodologas giles tienen en comn el modelo de desarrollo incremental
=entregas funcionales en tiempos cortos>, cooperatio =desarrolladores y
usuarios trabajan juntos en estrec#a comunicacin>, directo =el m(todo es
simple y fcil de aprender> y adaptatio =capa" de incorporar los cambios>! *as
claes de las metodologas giles son la elocidad y la simplicidad, de acuerdo
a ello, los equipos de trabajo se concentran en obtener lo antes posible una
pie"a til que implemente slo lo que sea ms urgente' de inmediato requieren
retroalimentacin de lo que se #a #ec#o, este acto es muy importante para el
proyecto! &e prosigue con ciclos igualmente brees, desarrollando de manera
incremental! Estructuralmente las metodologas giles de asemejan a las
L.Ks
-<
y a otros modelos iteratios, no obstante el (nfasis es distintio y la
resultante de su combinacin de ideas es nica!
;ada metodologa gil tiene su enfoque particular! Entre las ms difundidas se
puede mencionarI &crum, es un marco de gestin de proyectos' MP,
programacin extrema, por otro lado se cimenta en las buenas prcticas del
desarrollo t(cnico!
2.:. /etodolo,5! E,il de ,estin de "ro.ectos Scru
.ntes de comen"ar con el detalle y descripcin de esta metodologa, se
reali"ar una bree mencin acerca de los orgenes de la misma! En -687,
12 ;+<s2 Rapid Application Development I<esarrollo r-pido de aplicacionesJ.
@1
%he 0ew 0ew ,roduct )evelopment &ame$ un documento t(cnico publicado
por :onaDa y +aDeuc#i, sugiere que 4las reglas de juego en el desarrollo de
productos estn cambiando! Auc#as compa/as #an descubierto que se
necesita ms que los fundamentos aceptados de alta calidad, bajo costo, y la
diferenciacin de sobresalir en el competitio mercado de #oy! Q toman adems
los conceptos de elocidad y flexibilidad5 E:9:.C.U+.CE$;)%87H! En este
artculo se reali"a una metfora entre los equipos que desarrollan los productos
de las -1 compa/as japonesas que mencionan, englobando las buenas
prcticas
-@
en comn, y los equipos del juego deportio Lugby
-B
, resaltando la
auto organi"acin de los mismos, auto control, solapamiento de las fases de
desarrollo, transferencia organi"ada del conocimiento, la multidisciplinariedad, y
la construccin sobre inestabilidad' esta metfora enfati"a cierta formacin que
toman los equipos del deporte Lugby para lograr el baln y aan"ar con (l por
el campo, denominada &crum
-0
!
En el a/o -660 Weff &ut#erland y Cen &c#waber dirigen y formali"an &crum
como una t(cnica general para gestin, en la empresa en la que trabajaban
4Easel Corporation5! Posteriormente en el a/o <11- Cen &c#waber y AiDe
3eedle afinan y extienden &crum para su uso en Proyectos de desarrollo de
software E&;)F.3ELU3EEK*E1-H! *os proponentes de esta metodologa
indican que su utili"acin #ace posible el desarrollo rpido y aumenta el grado
de flexibilidad en los procesos de desarrollo de software!
&crum forma parte del conjunto de metodologas denominadas giles, que son
una alternatia a las metodologas tradicionales para la obtencin de sistemas
de informacin' de desarrollo simple, la gestin no se basa en el seguimiento de
un plan, sino en la adaptacin continua a las circunstancias de la eolucin del
proyecto! &u desarrollo posee un carcter adaptable, est orientada a las
1/ Buenas pr-cticas2 del trmino en ingls .est practices.
1= ;ug.y2 deporte que evolucion a partir del ft.ol IsoccerJ jugado en Hnglaterra, es un deporte de contacto en
equipo. http2DDes."i4ipedia.orgD"i4iD;ug.y.
1A Scrum2 es la .ase del juego I;ug.yJ de los delanteros, es el punto de partida para la construccin de un equipo y
formacin solida. Es un medio y no un fin, donde todos los delanteros aprenden a actuar en conjunto al servicio
del equipo. Es importante o.tener la pelota en esta formacin pero lo m-s importante es ganar la .atalla
psicolgica que se plantea cada ve( que dos equipos entran en contacto para disputar el .aln
http2DD""".diasderug.y.com.arDcoaching1%.html
@-
personas antes que a los procesos empleando un desarrollo gil, lo cual quiere
decir que es iteratio e incremental!
Esta metodologa de gestin de proyectos de software est estructurada
alrededor de tres principios fundamentalesI iteracin, incremento y
comunicacin, dada su importancia se describe estos principios de la siguiente
manera de acuerdo al trabajo reali"ado por Cen &c#waber en E&;)F.3EL1BHI
%teracionesI *as iteraciones en &crum se denominan &prints, los &prints
son ciclos de desarrollo rpidos y cortos, son similares a las iteraciones
en MP
-7
, en las cuales las funcionalidades listas para implementacin son
desarrolladas! El concepto t(cnico de funcionalidad lista para
implementacin se define como el objetio que cada &print tiene de
producir cdigo que est( listo para implementar!
%ncrementoI ;ada &print produce un incremento, requerimientos
desarrollados que se conierten en partes del sistema completamente
funcionales, que es liberado para aumentar la capacidad funcional del
producto o sistema!
;omunicacinI *os equipos de cliente y desarrollador deben estar en
cercana continua para facilitar la alta frecuencia de comunicacin
requerida por el proyecto durante la planificacin, seguimiento, y reisin
del producto o funcionalidad del sistema! ;on el objeto de satisfacer las
necesidades y requerimientos del cliente y propiciar la capacidad de
respuesta inmediata por parte del equipo a los cambios sobre el
proyecto!
&crum fue dise/ada para gestionar proyectos software que presentan o
requieren las siguientes caractersticas y cualidadesI entregables flexibles,
cronogramas flexibles, equipos reducidos, reisiones frecuentes, soluciones de
codificacin orientadas a objetos! &egn el trabajo reali"ado por Cen &c#waber
en E&;)F.3EL1<H, a continuacin se explica cada una de las caractersticas y
cualidades antes mencionadas!
1& K@ E>treme @rogramming2 0etodolog?a -gil de desarrollo propuesta por 3ent Bec4 LBE53GGM.
@<
Entregables flexiblesI el contenido de los entregables, ersin funcional o
producto de software terminado, es regulado segn el entorno donde
sern implementados y los cambios que pueda sufrir este entorno desde
la concepcin inicial del producto en el transcurso del tiempo!
;ronogramas flexiblesI el entregable qui"s pueda ser requerido con
mayor prontitud o ms despu(s del tiempo estimado, cronograma inicial
planificado!
Equipos reducidosI un equipo de un proyecto &crum no debe superar en
nmero a los 7 miembros! :o obstante pueden existir arios equipos en
un mismo proyecto!
Leisiones frecuentesI el aance desarrollado por el equipo es reisado
con frecuencia, como en ambientes complejos donde el proyecto
demanda posible riesgo para su finali"acin' la frecuencia de reisiones
usualmente en ciclos de una a cuatro semanas siendo cuatro y tres
semanas los ciclos que mas se usan!
&oluciones de codificacin orientadas a objetosI cada equipo se
direccionar a un conjunto especfico de objetos a la e", produciendo
interfaces claras y un comportamiento esperado en el entregable!
En esta metodologa se definen tres roles especficos bsicosI el propietario del
producto
-J
, el &crumAaster
-8
, y el equipo de &crum! El propietario del producto
es el responsable de representar los intereses de los staDe#olders
-6
, representa
la o" del cliente! &e asegura de que el equipo &crum trabaja de forma
adecuada desde la perspectia del negocio, usualmente proienen del negocio
y de la isin administratia' su labor principal es crear la lista de requerimientos
y priori"ar cada uno de los elementos de esta lista, los elementos de esta lista
se traducen en #istorias de usuario
<1
que describen la funcionalidad que se
desea en el sistema! El &crumAaster es el responsable de facilitar y propiciar el
1C @ropietario del producto2 del trmino en ingls Product Owner. Representa la vo( del cliente.
1' Scrum0aster2 El Scrum0aster se asegura de que el proceso Scrum se utili(a como es de.ido, cuyo tra.ajo
primario es eliminar los o.st-culos que impiden que el equipo alcance el o.jetivo del sprint.
1% Sta4eholders2 son los 5lientes y @roveedores.
2G :istorias de Nsuario2 Nna historia de usuario es una representacin de un requerimiento de soft"are escrito en una
o dos frases utili(ando el lenguaje comn del usuario.
@@
ambiente &crum, manteniendo diariamente las reuniones de reisin,
protegiendo de las distracciones e impedimentos externos al equipo y
asegurando que este equipo siga las prcticas de &crum! El equipo de &crum
es el responsable de planificar lo elementos que sern desarrollados en cada
iteracin por este equipo E*.++.:RE16H!
2.:.1. Estructur! . eleento "rinci"!l de Scru
&crum pone todas sus prcticas en una estructura de procesos iteratia e
incremental, esta estructura se muestra a continuacin en la Gigura <!B,
estructura bsica de &crum!
Gigura <!BI Estructura bsica de &crum
GuenteI Extrado y traducido de E&;)F.3EL1BH
El crculo inferior representa una iteracin, sprint, de las actiidades de
desarrollo, que son reali"adas una tras otra, la salida de cada iteracin es el
incremento sobre el producto! El crculo superior representa la reisin diaria
reali"ada durante una iteracin en la cual se tiene una reunin con todos los
integrantes del equipo para reisar las actiidades y reali"ar las adaptaciones
correspondientes! ;onduciendo la iteracin en la direccin de la lista de
requerimientos! Este ciclo se repite mientras el proyecto no se consolida
completamente!
Esta estructura funciona de la siguiente formaI al inicio de una iteracin el
equipo examina qu( es lo que se reali"ar, cada uno de los elementos
seleccionados se conertir en un potencial entregable funcional en la
@B
finali"acin de la iteracin! ;uando una iteracin termina el equipo presenta el
incremento a los stakeholders que reali"an la respectia reisin para
posteriormente exponer en el siguiente inicio de iteracin las modificaciones
que ean necesarias!
El cora"n, elemento principal, de &crum radica en la iteracin! El equipo da un
ista"o a los requerimientos, pone a consideracin la disponibilidad tecnolgica,
y reali"a una ealuacin segn su propias #abilidades y capacidades! En
conjunto se determina cmo se construirn las funcionalidades, modificando
segn se presenten diariamente nueas complicaciones y dificultades! El
equipo isuali"a qu( es lo que requiere ser #ec#o y selecciona la mejor forma
para #acerlo! Este creatio proceso es el cora"n de la productiidad en &crum!
*a metodologa &crum se diide en tres fases principales que son la fase
preliminar, fase de desarrollo y fase de finali"acin
<-
! En la primera fase,
preliminar, se definen los lineamientos iniciales y requerimientos del sistema,
definicin de los responsables y equipo con los que dar inicio el proyecto! En
la segunda fase, la fase de desarrollo, se reali"a la planificacin, desarrollo,
seguimiento y reisin de las tareas y actiidades para el proyecto, estas
actiidades tienen lugar dentro de las iteraciones o sprints que se repiten el
numero de eces necesario en funcin de la magnitud y requerimiento del
sistema esperado!
2.:.2. 1!se Preliin!r
Gase por la cual empie"a un proyecto con &crum, se diide a su e" en
planificacin y dise/o de alto niel de la arquitectura del sistema!
El propsito de la planificacin es establecer la isin del producto y delimitar a
manera general las expectatias por parte del cliente sobre el sistema
esperado, se debe conceptuali"ar y anali"ar el las necesidades y
requerimientos, para tal efecto se deben reali"ar las siguientes actiidadesI
Kesarrollar una comprensible lista de trabajo por reali"ar, esta lista #ace
referencia al 3acDlog del producto donde cada uno de sus elementos
21 Scrum se divide en tres fases2 Pregame, ame y Postgame. Segn LS5:6+BE;G2M.
@0
reflejan una #istoria de usuario!
&e debe definir tentatiamente las fec#as de entrega y la funcionalidad
que deban presentar las ersiones del producto!
&eleccionar la ersin del producto mas apropiada para ser desarrollada
inmediatamente!
Kefinir los responsables del proyectoI propietario del producto y
&crumAaster!
Kefinir el equipo del proyecto para construir la nuea ersin!
Ealuacin del riesgo del proyecto, y de los elementos de control de
riesgo ms apropiados!
Leisin y posible ajuste de los elementos del bacDlog del producto!
Paloracin y seleccin de la infraestructura y las #erramientas de
desarrollo!
Estimacin de los costos del proyecto!
$n proyecto en &crum comien"a con la isin del sistema que se ser
desarrollado! Esta isin probablemente no sea muy clara en inicio,
posiblemente porque se encuentre enfocada ms en t(rminos de mercadeo y
comerciali"acin que en t(rminos del real requerimiento del sistema, pero podr
ser clarificada en la medida que el proyecto aance! El propietario del producto
reali"a la formulacin del plan que se reali"ar en el proyecto, este plan es el
3acDlog del Producto! El bacDlog del producto es una lista de requerimientos
funcionales y no funcionales, que se conertirn en funcionalidades que
respondern a la isin del proyecto! &e reali"a la priori"acin del bacDlog del
producto de manera que los elementos que presuman generar mayor alor
tendrn la prioridad ms alta y sern diididos en ersiones tentatias! *a
priori"acin del bacDlog del producto es el punto de partida, y sus elementos
priori"ados y agrupados en posibles ersiones usualmente cambian cuando
comien"a el proyecto! *os cambios en el bacDlog de producto reflejan los
cambios requeridos por el negocio y cun rpido o lento el equipo puede
transformar el bacDlog del producto en funcionalidad!
@7
En la subfase de dise/o de alto niel de la arquitectura del sistema, se define
cmo sern implementados los elementos del bacDlog del producto! %ncluye las
modificaciones a la arquitectura del sistema y el dise/o de alto niel! *as tareas
que se deben reali"ar sonI
Leisin de los elementos del bacDlog del producto asignados!
%dentificacin de los cambios necesarios para implementar los elementos
del bacDlog del producto!
Lepresentacin del dominio de anlisis para el alcance requerido para
construir, incrementar o actuali"ar el dominio de modelos que reflejan el
nueo contexto del sistema y los requerimientos!
.decuar la arquitectura del sistema para dar soporte al nueo contexto y
requerimientos!
%dentificar cualquier problema o situacin que cambie en el transcurso del
desarrollo o implementacin!
Kise/ar la reunin de reisin, donde el equipo presenta las
aproximaciones y cambios para la implementacin de cada uno de los
elementos del bacDlog del producto! Es preciso reasignar los cambios!
2.:.(. 1!se de des!rrollo
En esta fase tiene lugar el desarrollo de los &prints! Kesarrollo de nueas
ersiones de funcionalidad, con constante estimacin para las ariables en el
tiempo, los requerimientos, la calidad y la competencia para el negocio! *a
interaccin con estas ariables define la finali"acin de esta fase! En esta fase
se reali"an arios e iteratios desarrollos de sprints, o ciclos, que son utili"ados
para eolucionar el sistema!
+odo el trabajo es reali"ado dentro de los &prints! ;ada sprint es una iteracin
de, usualmente aunque no de manera determinante, @1 das calendario! ;ada
sprint iniciali"a con una reunin de planificacin, donde el propietario del
producto y el equipo de forma conjunta y colaboratia deciden qu( es lo que
sera reali"ado en el sprint! &eleccionando del bacDlog del producto los
elementos con mayor prioridad, el objetio es definir el trabajo a reali"ar!
@J
;ada da el equipo tiene una reunin denominada &crum diario, en este &crum
diario cada integrante del equipo expone las tareas que reali"o desde el ltimo
&crum diario, qu( es lo que planea #acer #asta la siguiente reunin de &crum
diario, y qu( impedimentos #a detectado para reali"ar su trabajo! El propsito
de esta reunin es sincroni"ar el trabajo de todo el equipo de forma cotidiana y
de forma estructurada determinar las necesidades o problemas que pueda
presentar el equipo dentro la eolucin del proyecto!
;uando finali"a el &print, se reali"a una reunin de reisin del &print en la que
el equipo presenta al propietario del producto el desarrollo que se #a reali"ado
durante el sprint! Esta reunin pretende, mediante la demostracin del
incremento reali"ado, obtener una realimentacin acerca de lo desarrollado
para aplicar oportunamente, usualmente reali"ado en el siguiente sprint, los
cambios necesarios para potenciar el incremento de alor en el producto final!
. continuacin se muestra en la Gigura <!0, el proceso bsico de las fases de
&crum descritas!
Gigura <!0I Gases de &crum
GuenteI Extrado y traducido de E&;)F.3EL1BH
*a fase de desarrollo es un ciclo iteratio del trabajo de desarrollo! *a gestin
determina el tiempo, competencia, caractersticas o funcionalidad que se deben
encontrar! &e termina con las iteraciones cuando ocurre la fase de finali"acin!
@8
Esta forma de trabajo es conocida como Concurrent Enineerin
<<
! El desarrollo
consiste en los siguientes grandes procesosI
Leuniones con el equipo para reisar los planes de ersin!
Kistribucin, reisin y ajuste de los estndares con los cuales el
producto ser conformado!
&prints iteratios, #asta que el producto se encuentre listo para
distribucin!
$n sprint es un conjunto de actiidades conducidas sobre un periodo
predefinido! El interalo es basado segn la complejidad del producto y el
riesgo estimado! *a elocidad e intensidad del &print son conducidas por la
duracin del &print seleccionada! Ke manera continua el riesgo es ealuado as
como son adecuados continuamente los controles de riesgo!
2.:.:. 1!se de 1in!li-!cin
En esta fase, fase de finali"acin, se reali"a la preparacin de la ersin,
despliegue operacional, incluyendo documentacin final, y pruebas reali"adas!
;uando el equipo gestionado considera que los requerimientos, las ariables y
mejoras que se presentan son candidatas para reali"ar una nuea ersin, se
declara la ersin como cerrada y se ingresa en esta fase! En esta fase se
prepara el producto desarrollado para una ersin general, integracin, pruebas
del sistema, documentacin del usuario y elaboracin del material de
entrenamiento entre las tareas de clausura!
2.:.<. Control de l! e$olucin de un "ro.ecto
*a metodologa gil &crum controla de forma emprica y adaptable la eolucin
de un proyecto, con las siguientes prcticas de la gestin gilI
a> Leisin de las %teracionesI .l final de cada &print o iteracin, se reali"a
una reisin con todas las personas implicadas en el proyecto! Este es el
periodo mximo que se puede tardar en reconducir una desiacin del proyecto
22 5oncurrent Engineering2 Hngenier?a concurrente, es un enfoque sistem-tico para la integracin, dise$o concurrente
de productos y sus procesos relacionados, incluyendo fa.ricacinDconstruccin y soporte. Este enfoque est-
destinado a considerar todos los elementos del ciclo de vida del producto, desde su concepcin hasta su
eliminacin, donde las fases del desarrollo se ejecutan en paralelo y no en serie, para reducir los tiempos de
entrega y los costes I@ennell y 6inner, 1%'%J.
@6
o de las circunstancias del producto
b> Kesarrollo %ncrementalI En el proyecto, no se trabaja con dise/os o
abstracciones! El desarrollo incremental implica que al final de cada iteracin se
dispone de una parte del producto operatia que se puede inspeccionar y
ealuar!
cJ Kesarrollo EolutioI ;omo modelo gil, es til en entornos con
incertidumbre e inestabilidad de requisitos! %ntentar predecir en las fases
iniciales cmo ser el resultado final, y sobre dic#a prediccin desarrollar el
dise/o y la estructura del producto no es realista, porque las circunstancias
obligarn a remodelarlo muc#as eces! Este modelo toma a la inestabilidad
como premisa' por eso el protocolo de las prcticas de trabajo que se dise/en
tiene que permitir la eolucin continua sin degradar la calidad de la
arquitectura, que se ir generando durante el desarrollo!
;on esta metodologa, el dise/o y la estructura del resultado se construyen de
forma eolutia! :o se considera que la descripcin detallada del producto, del
sericio, de la estrategia o de la arquitectura del software, segn sea el caso,
deban reali"arse en las primeras instancias de un proyecto!
En la aplicacin de la metodologa &crum para software, con el objeto de eitar
los problemas de degradacin del sistema o de la arquitectura por la eolucin
continua del producto se deben incluir prcticas de refactori"acin en las tareas
de dise/o y codificacin!
a> .uto 9rgani"acinI Kurante el desarrollo de un proyecto surgen
circunstancias impredecibles en todas las reas y nieles! *a gestin predictia
confa la responsabilidad de su resolucin al gestor de proyectos! En cambio
#aciendo referencia al marco de trabajo de &crum los equipos son auto?
organi"ados, con margen de decisin suficiente para tomar las decisiones que
consideren oportunas!
b> ;olaboracinI *as prcticas y el entorno de trabajo giles facilitan la
colaboracin del equipo, que se conforma de todas las personas que participan
en un proyecto de software, que es necesaria y debe basarse en la
B1
colaboracin abierta entre todos los miembros segn los conocimientos y
capacidades de cada uno de ellos y no as segn su rol o puesto!
2.:.B. Arte%!ctos de Scru
&crum propone unos pocos artefactos! Estos artefactos se mencionan a lo largo
de todo el proceso de &crum descrito' y sern detallados y desglosados en las
siguientes secciones!
2.:.B.1 F!c=lo, del Producto
*a Pila del Producto o llamada tambi(n 3acDlog del Producto es una lista de
funcionalidades
<@
que necesita el cliente! Es un documento, que eoluciona
durante el desarrollo del &istema de %nformacin, no es un documentos de
requisitos, sino una #erramienta de referencia para el equipo que desarrollo el
producto!
&e sita en el rea de necesidades de negocio desde el punto de ista del
cliente! Es el rea que en la ingeniera del software tradicional, cubren los
requisitos del sistema!
*as funcionalidades que incluye dan forma a una isin del producto definida y
conocida por todo el equipo! *as funcionalidades estn indiidualmente
definidas, priori"adas y pre?estimadas, reali"adas y gestionadas por el cliente!
. diferencia de un documento de requisitos del sistema, la pila del producto
nunca se da por completada' esta en continuo crecimiento y eolucin!
)abitualmente se comien"a a elaborar con el resultado de una reunin de
fertili"acin cru"ada o brainstormin
/1
' o un proceso de Exploracin,
denominada fase inicial en la metodologa gil de desarrollo Programacin
Extrema donde colabora todo el equipo a partir de la isin del propietario del
producto!
. continuacin en la Gigura <!7, se muestra el modelo del formato recomendado
para reali"ar un Pila de Producto o ,roduct (acklo.
2/ Ba lista de funcionalidades del Product !ac"log es reali(ada a partir de los requerimientos, :istorias de Nsuario,
del propietario del productoO el Product !ac"log es una lista de :istorias de Nsuario.
2= 7ertili(acin cru(ada o #rainstorming tam.in denominada lluvia de ideas o tormenta de ideas, es una herramienta
de tra.ajo grupal que facilita el surgimiento de nuevas ideas so.re un tema o pro.lema determinado. Ba lluvia de
ideas es una tcnica de grupo para generar ideas originales en un am.iente relajado L6H3HM.
B-
Gigura <!7I Aodelo de una Pila del Producto o ,roduct (acklo
ID Descri"cin Priorid!d Esti!cin G S"rint Res"ons!#le O#ser$!ciones /dulo
Siste!
a> b> c> d> e> f> g> #>
KescripcinI a> %dentificador nico de la funcionalidad o del trabajo, numero de
)istoria de $suario!
b> Kescripcin de la funcionalidad!
c> ;ampo o sistema de priori"acin!
d> Estimacin de tiempo para la funcionalidad!
e> :mero del Sprint en el que se reali"a!
f> Persona asignada!
g> 9bseraciones!
#> Aodulo del sistema al que pertenece!
GuenteI Aodificado de E&;WP1JH
2.:.B.2 Histori!s de Usu!rio IHUJ
*a descripcin del sistema es responsabilidad del cliente, es quien debe decidir
que se incluye en la pila del producto, y el orden de prioridad ! *a isin del
cliente es conocida por todo el equipo, el cliente forma parte del equipo, y la pila
del producto o lista de )istorias de $suario se reali"a y eoluciona de forma
continua con las aportaciones de todo el equipo EP.*.;%918H!
*as )istorias de $suario constan de @ a 0 lneas escritas por el propietario del
producto en lenguaje no t(cnico, sin #acer (nfasis en los detalles, no se debe
#ablar de posibles algoritmos, dise/os de base de datos adecuados, ni de otras
caractersticas t(cnicas! *as #istorias de usuario son similares al empleo de
escenarios, con la excepcin de que no se limitan a la descripcin de la interfa"
de usuario, conducen al proceso de creacin de test de aceptacin
<0
! El formato
de las #istorias de usuario se compone de J diisiones, donde la descripcin y
el nombre son fundamentales para permitir lograr un buen desarrollo en el
producto esperado, antes de obtener una #istoria de usuario funcional para los
miembros del equipo de desarrollo es aconsejable que el cliente o propietario
del producto deba ensayar el reali"ar #istorias de usuario preferentemente
guiado por un miembro del equipo de desarrollo con el objeto de obtener
#istorias de usuario que plasmen de forma correcta las funcionalidades que se
2A *est de aceptacin2 prue.a que es ela.orada por los desarrolladores y propietarios del producto denominados
tam.in clientes, donde los clientes dan el visto .ueno acerca del correcto funcionamiento so.re los
requerimientos reali(ados.
B<
esperan del sistema!
*as #istorias de usuario son utili"adas para estimar tiempos de desarrollo para
el sistema de informacin que describen, tambi(n se utili"an en la etapa de
reali"acin de pruebas, para erificar si la funcionalidad desarrollada cumple
con lo especificado por el propietario del producto EMP3E;C11H!
&olamente se proporciona los detalles sobre la estimacin del riesgo y del
tiempo de duracin para la implementacin de dic#a #istoria de usuario! El niel
de detalle debe ser el mnimo posible, para que permita plasmar una ligera idea
de cunto costar
<7
implementar la misma! ;uando inicie el &print que contiene
una #istoria de usuario los desarrolladores tienen la posibilidad de acudir al
cliente para ampliar detalles! &i una #istoria de usuario tiene una estimacin de
tiempo superior a la duracin de un &print, se debe proceder a replantear la
inicial o diidirla en ms de una! . continuacin en la Gigura <!J, se muestra el
formato de una #istoria de usuario!
Gigura <!JI Aodelo de )istoria de $suario
Histori! de Usu!rio NK 3 a> g>
:ombreI b> PrioridadI c>
Kescripcin I

d>
EstimacinI e> KependenciaI f>
KescripcinI a> :umero de #istoria de usuario
b> :ombre de la #istoria de usuario
c> Prioridad en planificacin de entregas
d> Kescripcin de la #istoria de usuario
e> Estimacin del tiempo de desarrollo
f> Kependencia del programador
g> :ombre del sistema
GuenteI Aodificado de E3E;C11H!
2.:.B.( F!c=lo, del S"rint
*a Pila del &print o &print 3acDlog es una lista de tareas que se reali"an en un
sprint! ;ubre la especificacin de los requisitos, #istorias de usuario, de
software necesarios para dar respuesta a las funcionalidades esperadas por el
2& El costo se refiere al tiempo que la historia de usuario requerir- para su desarrollo.
B@
cliente! %ncluyen todas las tareas necesarias para construir el incremento de un
sprint EP.*.;%918H!
*a pila del sprint, es la lista que descompone las funcionalidades de la pila del
producto en las tareas necesarias para construir un incremento! ;ada tarea de
la pila del sprint tiene asignada una persona, y la indicacin del tiempo que aun
falta para terminarla! Es til porque descompone el proyecto en unidades de
tama/o adecuado para determinar el aance a diario, e identificar riesgos y
problemas sin necesidad de procesos complejos de gestin! Es tambi(n una
#erramienta de soporte para la comunicacin directa del equipo EP.*.;%918H!
Gigura <!8I Aodelo de Pila de &print
KescripcinI a> :mero de &print, fec#a de inicio y duracin en das del &print
b> :mero de elemento del Product 3acDlog o Pila del Producto al
que pertenece la tarea, tambi(n se refiere a la )istoria de
$suario a la que pertenece
c> Kescripcin de la tarea
d> +ipo de tarea
e> Estado de la tarea
f> Persona asignada, responsable de la tarea
g> ;antidad de #oras restantes para concluir la tarea, registro por da
#> :mero de tareas pendientes, por concluir, resultado por da
i> :mero de #oras pendientes, por concluir, resultado por da
j> Encabe"ado de la columna de cada da con la fec#a y nmero de da
dentro del sprint!
GuenteI Aodificado de E&;WP1JH
El Sprint (acklo o Pila del &print es reali"ada de forma conjunta por todos lo
miembros del equipo de un proyecto de software, cubre todas las tareas
identificadas por el equipo para conseguir el objetio del sprint y slo el equipo
BB
lo puede modificar durante el sprint! *a duracin de tiempo de cada tarea debe
estar en un rango de < a -7 #oras de trabajo y es de gran importancia dentro de
la gestin de proyectos con &crum que sea isible en todo momento para el
equipo EP.*.;%918H!
*a Pila del &print puede ser elaborada ya sea en una #oja de clculo o en una
#erramienta colaboratia o de gestin de proyectos, para su elaboracin se
debe tener en cuanta queI
%ncluye la informacinI lista de tareas, persona responsable de cada una,
estado en el que se encuentra y tiempo de trabajo que queda para
completarla!
El medio y opcin elegido es la opcin posible que mas facilita la
consulta y comunicacin diaria y directa del equipo!
&ire de soporte para registrar en cada reunin diaria del sprint, el tiempo
que le queda a cada tarea!
Kurante el sprint, el equipo actuali"a sobre la pila del sprint, a diario, los tiempos
pendientes de cada tarea! .l mismo tiempo con la alimentacin diaria de estos
datos se puede reali"ar el grfico de aance del proyecto EP.*.;%918H! En la
Gigura <!8, se mostr un modelo de la Pila del &print o (acklo Sprint.
2.:.B.: Increento
El %ncremento es el alor que se entrega al cliente al final de cada &print, es una
parte del sistema desarrollado en un &print completamente terminada y
operatia EP.*.;%918H! &e constituye en la parte del producto producida en un
&print, y tiene como caractersticas que esta completamente terminada y
operatia, en condiciones de ser entregada al cliente final! :o se trata por tanto
de mdulos o partes del producto a las que aun les falta reali"ar pruebas, o
adjuntar documentacinI
;ada funcionalidad de la pila del producto se refiere a funcionalidades
entregables, no a trabajos internos =p!ej! Kise/o de la base de datos5>!
$n incremento es producido tras la finali"acin de cada &print o
%teracin!
B0
&in embargo suele ser una excepcin #abitual el primer &print! En el que los
objetios del tipo 4contrastar la plataforma y el dise/o5
<J
pueden ser normales, e
implican trabajos de dise/o o desarrollo de prototipos para probar la solencia
de la plataforma que se a a emplear!
+eniendo en cuenta esta excepcin #abitual, %ncremento de manera general es
una parte de producto reali"ada en un sprint, y potencialmente entregable,
terminada y probada!
&i el proyecto o sistema requiere documentacin, o procesos de alidacin y
erificacin documentados, o con nieles de independencia que implican
procesos con terceros, (stos tambi(n tienen que estar reali"ados para
considerar que un incremento est terminado EP.*.;%918H!
2.:.B.< Reuniones
*a metodologa &crum reali"a la gestin de un proyecto de software a partir de
reuniones que forman parte del modelo, estas reuniones tienen la siguiente
clasificacinI
Leunin de Planificacin del &print!
Leunin de &eguimiento del &print!
Leunin de Leisin del &print
2.:.B.<.1 Reunin de Pl!ni%ic!cin del S"rint
*a reunin de Planificacin del sprint toma como base las prioridades y
necesidades de negocio del cliente, y determina cules y cmo an a ser las
funcionalidades que incorporar el producto tras el siguiente &print!
Para reali"ar esta reunin el propietario del producto
<8
debe tener preparada la
pila del producto, lista de #istorias de usuario, con su criterio de prioridad para
el negocio y una idea de elementos para desarrollar en el &print' el equipo debe
tener conocimiento de las tecnologas empleadas, y del negocio del producto
2C Bos requerimientos y o.jetivos inicialmente definidos en un proyecto se traducen en tareas como seleccin de la
tecnolog?a, dise$o de la arquitectura de la solucin, y otras de este tipoO por lo que la reali(acin de estas tareas no
constituye en s? una parte funcional para un producto de soft"are, pero s? constituyen una parte importante en el
proyecto y su generacin requiere la asignacin de personas responsa.les y un periodo de tiempo.
2' @ropietario del producto2 delegado del cliente, responsa.le so.re las decisiones de los requerimientos.
B7
suficiente para reali"ar estimaciones basadas en 4juicio de expertos5
<6
, y para
comprender los conceptos del negocio que expone el propietario del producto!
*os elementos de entrada de esta reunin sonI la Pila del Producto o ,roduct
(acklo, el producto desarrollado #asta la fec#a a tra(s de los sucesios
incrementos con la excepcin de que trate del primer sprint, las circunstancias
de las condiciones del negocio del cliente y del escenario tecnolgico empleado
o a emplear! *os elementos esperados de esta reunin sonI el objetio del
&print, la Pila del &print o Sprint (acklo, la duracin del &print y la fec#a de la
reunin de reisin!
2.:.B.<.2 Reunin de Se,uiiento del S"rint
*a reunin de &eguimiento del &print es una reunin diaria bree, de no mas de
-0 minutos, en la que cada miembro del equipo dice las tareas en las que est
trabajando, si se #a encontrado o pre( encontrarse con algn impedimento, y
actuali"a sobre la pila del sprint las tareas ya terminadas, o los tiempos de
trabajo que les an falta!
Para reali"ar esta reunin se debe contar con la Pila del &print y el grfico de
aance con la informacin de la reunin anterior, y la informacin de las tareas
reali"adas por cada integrante del equipo! *o resultados esperados de esta
reunin es la Pila de Producto y el grfico de aance actuali"ados y la
identificacin de necesidades e impedimentos de los miembros del equipo!
2.:.B.<.( Reunin de Re$isin del S"rint
Esta reunin se reali"ada al finali"acin del &print, el equipo presenta el trabajo
reali"ado durante el &print al propietario del producto, clientes, usuarios, y
dems personas que interacten con el sistema o est(n a cargo de sus gestin
el incremento construido en el &print!
El propietario del producto obtiene informacin objetia del progreso del
sistema! Esta reunin marca a interalos regulares, el ritmo de construccin del
sistema y la trayectoria que a tomando la isin del producto! .l er y probar el
2% Estimaciones .asadas en !juicio de e>pertos#2 dado que una de las caracter?sticas del modelo Scrum es, que las
personas que conforman el equipo de desarrollo en un proyecto de soft"are, de.an ser personas que tengan un
nivel de e>periencia en ese -m.ito.
BJ
incremento, el propietario del producto, y el equipo en general obtienen una
realimentacin importante para eolucionar y dar mas alor a la pila del
producto!
Para reali"ar esta reunin se debe tener el &print concluido, y el incremento
terminado! *os resultados esperados de esta reunin son la fec#a de la reunin
de Planificacin del siguiente &print, feedback
23
para el propietario del producto
del seguimiento de la construccin del sistema e informacin para mejorar el
alor de la isin del producto, feedback para el responsable de la gestin del
proyecto sobre buenas practicas y resolucin de problemas durante el sprint!
2.<. /etodolo,5! de Des!rrollo Pro,r!!cin E0tre!
*a Programacin Extrema o MP
@-
forma parte del conjunto de metodologas
denominadas giles, que son una alternatia a las metodologas tradicionales
para el desarrollo de software, y adems es apropiada como proceso para el
aseguramiento de la calidad!
&egn Cent 3ecD todo en el software cambia, los requisitos cambian, el dise/o
cambia, el negocio cambia, la tecnologa cambia, el equipo cambia, los
miembros del equipo cambian, el problema no es el cambio en s mismo, puesto
que se sabe que a a suceder' el problema es la incapacidad de adaptarse al
cambio cuando (ste tiene lugar!
*a Programacin Extrema surge como respuesta principalmente a la necesidad
de una alternatia de organi"acin, planificacin y desarrollo de software ante
proyectos donde existen cambios frecuentes en los requerimientos, y donde el
usuario no posee una isin clara y exacta de lo que necesita! Es un m(todo
ideal en proyectos donde el usuario tiene una perspectia confusa del problema
a resoler, siendo muy adaptable en ese aspecto, esta es un propiedad muy
significatia!
*a metodologa de desarrollo Programacin Extrema es una t(cnica que
permite al equipo de desarrollo organi"ar, planificar y elaborar un software de
/G 7eed.ac42 trmino en ingls que hace referencia a retroalimentacin o realimentacin
/1 K@2 eKtreme @rograming 2 programacin e>trema desarrollada por 3ent Bec4, 0artin 7o"ler y 6ard 5uningham
B8
manera incremental teniendo en cuenta siempre la calidad ante todo aplicando
pruebas, y desarrollar el proyecto permitiendo cambios de manera constante sin
elear el costo excesiamente en t(rminos de tiempo y de dinero!
*a Programacin Extrema plantea dos objetios bsicos y principales segn
Cent 3ecD y sus colaboradores que sonI
aJ &atisfaccin del clienteI objetio principal, debido a que esta metodologa
fue concebida y dise/ada para proporcionar el software que el cliente necesita
cuando lo necesita, se debe responder de manera rpida a los cambios en las
necesidades del cliente, incluso aun cuando estos cambios se produ"can al
final del ciclo de ida de dic#o software #aciendo uso de la simplicidad y
retroalimentacin! Kebido a que la filosofa de la Programacin Extrema es
satisfacer al completo las necesidades del cliente se lo integra como una parte
del equipo de desarrollo!
b> Potenciar el trabajo en equipoI segundo objetio de la Programacin
Extrema, se plantea asignando la responsabilidad de la implementacin al
cliente y al desarrollador, esto implica que las planificaciones son elaboradas
por ambas partes, tambi(n se debe contar con dise/os simples, y los clientes
deben disponer constantemente de ersiones operatias para aportar con
sugerencias!
Esta metodologa est dise/ada para el desarrollo de aplicaciones que
requieren un grupo de programadores peque/o, dnde la comunicacin tiene
mayor grado de factibilidad que en grupos de desarrollo grandes, la
comunicacin es un punto importante que debe reali"arse entre los
programadores, los jefes de proyecto y los clientes!
*os alores principales aplicados en esta metodologa son cuatroI
comunicacin, simplicidad, retroalimentacin y coraje, siendo base fundamental
para su desarrollo, se los describe de la siguiente manera de acuerdo al trabajo
reali"ado por Cent 3ecD y Aartin Gowler I
;omunicacinI programadores en constante comunicacin con los
clientes para satisfacer los requisitos propuestos por ellos y responder
B6
rpidamente a los cambios de los mismos! Este alor requiere de una
interaccin total por parte de todo el equipo, es muy importante ya que
apoya y acelera el proceso de retroalimentacin en el proyecto!
&implicidadI aplicacin de dise/os simples y claros en cuanto al cdigo
del programa, permiten un mantenimiento estable, y desarrollo de futuras
implementaciones sin muc#o esfuer"o!
LetroalimentacinI mediante la retroalimentacin se ofrece al cliente la
posibilidad de conseguir un sistema apto a las necesidades que
presenta, ya que se muestra el proyecto a tiempo para ser cambiado y
retroceder a una fase anterior para redise/arlo segn se ea
coneniente! Este proceso esta muy ligado a la comunicacin donde el
cliente proee las ariables de entrada en forma de requerimientos y
necesidades a una siguiente fase donde es mejorado el software!
;orajeI alor esencial, ya que la metodologa Programacin Extrema
requiere de alenta o coraje para cumplir con los tres puntos anteriores
en beneficio del proyecto! &e debe tener alor para comunicarse con el
cliente y enfati"ar algunos puntos, y se debe tener coraje para mantener
un dise/o!
+abla <!-I Practicas de la Programacin Extrema
Nro. PrActic!
- Wuego de planificacin
< Kise/o simple!
@ Prueba continua
B Estndares de codificacin!
0 Entregas peque/as y frecuentes
7 Aetfora del sistema
J Lefactori"acin continua!
8 Programacin en pares
6 Propiedad colectia del cdigo
-1 %ntegracin continua
-- Litmo sostenible, trabajando un mximo de 8 #oras por da
-< +odo el equipo en el mismo lugar
GuenteI Extrado y traducido de E3E;C11H
01
*as practicas mencionadas en la tabla se refuer"an e interactan entre si de
acuerdo a las funcionalidades y los objetios! Kic#as prcticas son expresadas
y mostradas en la figura siguiente donde se agrupan en tres distintos nieles, el
niel mas bsico muestra las practicas diarias y constantes, el segundo niel
con practicas mas generales, y el tercer niel con practicas para todo el equipo
y aplicables a lo largo del proyecto de manera general!
Gigura <!6I Practicas que se refuer"an entre si
GuenteI Extrado y traducido de E3E;C11H!
*a Programacin Extrema define un proceso de dise/o eolutio que se basa
en refabricar un sistema simple por cada iteracin, todo el dise/o se centra en
la iteracin actual y no se #ace nada en anticipacin a las necesidades futuras!
%mpone una disciplina en el proceso en combinacin con la adaptabilidad que
#ace de la Programacin Extrema una metodologa muy slida! . continuacin
se detallan las prcticas y el proceso bsico propuesto en la Gigura <!-1, donde
0-
se en los alores y los principios de una forma conjunta, brindndose soporte
mutuoI
Gigura <!-1I Palores y principios primordiales de la programacin extrema
Pruebas
;odificacin
Planificacin
Kise/o
;
o
m
u
n
i
c
a
c
i

n
&
i
m
p
l
i
c
i
d
a
d
L
e
t
r
o
a
l
i
m
e
n
t
a
c
i
o
n
;
o
r
a
j
e
Palores de la Programacin Extrema
P
r
a
c
t
i
c
a
s

d
e

l
a

P
r
o
g
r
a
m
a
c
i

n

E
x
t
r
e
m
a
GuenteI Extrado y traducido de E3E;C11H!
+odas las practicas mencionadas y explicadas en los grficos <!6 y <!-1 se
aplican a diferentes integrantes del grupo de desarrollo, estas son refor"adas
entre si y se interrelacionan mutuamente como se io en la figura <!6, es
importante #acer uso de las practicas de programacin y los alores de la
Programacin Extrema para obtener buenos resultados en cuanto al desarrollo
del software' a continuacin se muestra en la tabla <!< un detalle de los
participantes de cada prctica donde son diferenciadas en practicas conjuntas,
practicas de programador, practicas gerenciales y practicas del cliente!
*a metodologa Programacin Extrema se diide en B fases principales en el
desarrollo que son la exploracin, planificacin, iteraciones y la produccin,
donde en la primera que es la fase de exploracin se definen los requerimientos
iniciales con los que comen"ara el proyecto, luego en la fase de planificacin se
priori"an las tareas mas importantes a ser ejecutadas, se planifica el desarrollo
0<
del proyecto, y se estiman los tiempos iniciales de desarrollo, luego en la fase
de iteracin se desarrolla el software en si, teniendo siempre al cliente
disponible, esta fase junto con la de planificacin y de produccin siguen un
ciclo incremental repetitio, que se repite n?eces de acuerdo a la magnitud del
sistema, se alcan"a la conclusin del proyecto cuando el cliente ya no tiene
ningn requerimiento y esta conforme con el software desarrollado!
+abla <!<I Prcticas de desarrollo
PrActic!s con2unt!s
%teraciones =una fase del desarrollo>
Aetforas
PrActic!s del
"ro,r!!dor
Kesarrollo orientado a pruebas
Programacin en pares
Lefactori"acin
Propiedad colectia
%ntegracin continua
Kise/o &imple
Estndares de codificacin
PrActic!s
,erenci!les
+odo el equipo en el mismo lugar 4;liente in situ5
Litmo sostenible
PrActic!s del cliente
:arracin de #istorias =una tarea continua del cliente>
Planeamiento de entrega
Entregas frecuentes
GuenteI Extrado de E)$L+1BH
*as fases de Planificacin, %teracin, y Produccin son iteratias entre si, ya que
la salida de una es la entrada de otra y siguen un ciclo eolutio #asta que no
existen necesidades por parte del usuario respecto al software, su ciclo de ida
se lo detalla en la Gigura <!--!
En la fase de Exploracin es donde se reali"a el anlisis de requerimientos
preio al inicio para el desarrollo del sistema, es muy importante que el cliente
se acople a la dinmica de trabajo a reali"arse en el proyecto, proeyendo de
#istorias de usuario aptas para la codificacin de los programadores, es la
nica que no participara en el ciclo iteratio de planificacin iteracin y
produccin del proyecto citadas anteriormente!
$na e" que se llega a la fase de Produccin se inicia una nuea %teracin
empe"ando nueamente con la fase de Planificacin, para seguir un nueo
ciclo!
0@
Gigura <!--I ;iclo de ida de un proyecto desarrollado con programacin extrema
Gase de
Exploracin
Plan de
entregas
%teracin
Ar+uitecto
)istorias de
$suarios
Gase de
Planeamiento
Gase de
%teracin
Gase de
Produccin
Prueba de
aceptacion
/etA%or!
del siste!
Lequerimientos
Gase de
manteniento
Nue$! Distori! de us!rio
9elocid!d del "ro.ecto
$ltima
ersin
.ceptacin del
cliente
Lequerimientos
GuenteI Aodificado de E3E;C11H
2.B. Ad!"t!cin /etodolo,5!s Scru . Pro,r!!cin E0tre!
*a metodologa gil &crum cubre todas las actiidades de gestin de proyectos
de software, sin embargo no cubre con la misma amplitud las actiidades de
desarrollo de un proyecto de software, es por ello que es comn encontrar este
tipo de #ibridacin &crum X MP en los equipos de profesionales dedicados al
desarrollo de software con orientacin gil, as como tambi(n en publicaciones
de arios autores de libros y artculos cientficosSacad(micos sobre
metodologas giles, aplicacin de un enfoque gil!
Este tipo de conjuncin armnica de metodologas es posible ya que tanto
&crum como Programacin Extrema comparten y aplican de manera similar
algunos conceptos y se complementan en otros aspectos!
El presente proyecto de grado #a tomado una #ibridacin de dos metodologasI
para gestin de proyectos y para desarrollo de proyectos de software, &crum y
Programacin Extrema respectiamente!
Esta adaptacin plantea como metodologa principal a Scrum! para las
acti"idades de gestin del proyecto y toma pr#cticas y acti"idades
prestadas de Programacin E$trema! para las acti"idades de desarrollo
del proyecto que no se encuentren definidas en Scrum%
0B
Para el presente proyecto se reali" una adaptacin de &crum con MP de la
siguiente formaI
a> &e mantiene el ciclo de ida normal de &crum, en sus @ fasesI preliminar,
desarrollo y finali"acin!
b> En la fase de desarrollo se aplican las siguientes prcticas de
Programacin Extrema por parte del Equipo &crumI
Kise/o simple!
Prueba continua!
Estndares de codificacin!
%ntegracin continua!
Lefactoreo
*as prcticas definidas en el inciso b> se aplican implcitamente en la fase de
Kesarrollo de &crum por los integrantes del equipo de desarrollo!
2.L. Ar+uitectur! de Siste!s de In%or!cin
*a arquitectura del software alude a la 4estructura global del software y a las
formas en que la estructura proporciona la integridad conceptual de un
sistema5! En su forma ms simple, la arquitectura es la estructura jerrquica de
los componentes del programa =mdulos>, la manera en que los componentes
interactan y la estructura de datos que an a utili"ar los componentes! &in
embargo, en un sentido ms amplio, los 4componentes5 se pueden generali"ar
para representar los elementos principales del sistema y sus interacciones =Por
ejemplo, los componentes arquitectnicos de un sistema clienteSseridor se
representan en un niel de abstraccin diferente>!
$na arquitectura de software es el producto de trabajo de desarrollo que ofrece
la mayor inclinacin a inertir en lo que se refiere a calidad, planificacin y coste
EPLE&&A.:10H!
*a arquitectura de software de un sistema de programa o computacin es la
estructura de las estructuras del sistema, la cual comprende los componentes
del software, las propiedades de esos componentes isibles externamente, y las
00
relaciones entre ellos! *a arquitectura del software no es operacional! As bien
es la representacin que capacita al ingeniero del software paraI =-> anali"ar la
efectiidad del dise/o para consecucin de los requisitos fijados, =<> considerar
las alternatias arquitectnicas en la cual #acer cambios en el dise/o es
relatiamente fcil, y =@> reducir los riesgos asociados a la construccin del
software! *a arquitectura de un sistema constituye un amplio marco que
describe su forma y estructura, sus componentes y cmo (stos encajan juntos
EPLE&&A.:10H!
2.L.1. Ar+uitectur!s Centr!d!s ! D!tos
En el centro de (sta arquitectura se encuentra un almac(n de datos =por
ejemplo, un documento o una base de datos> al que otros componentes
acceden con frecuencia para actuali"ar, a/adir, borrar o bien modificar los datos
del almac(n! El software de cliente accede a un almac(n central! En algunos
casos, el almac(n de datos es pasivo! Esto significa que el software de cliente
accede a los datos independientemente de cualquier cambio en los datos o de
las acciones de otro software de cliente EPLE&&A.:10H! *a Gigura <!-<,
representa un estilo tpico basado en datos!
Gigura <!-<I .rquitectura ;entrada a Katos
GuenteI Extrado de EPLE&&A.:10H
2.M. Tecnolo,5! . Herr!ient!s
En el presente trabajo se #a definido la utili"acin de #erramientas tecnolgicas
para las actiidades de anlisis, dise/o y desarrollo del sistema de informacin
planteado!
07
Kentro de las #erramientas utili"adas para la reali"acin del proyecto se
describen las siguientesI
2.M.1. Tecnolo,5! ?!$! Edicin E"res!ri!l
*as aplicaciones Waa Edicin Empresarial, WEE, estn compuestas de
diferentes componentes! $n componente WEE es una unidad de software
funcional auto?contenida que se ensambla dentro de una aplicacin WEE con
sus clases de ayuda y fic#eros, adems estos componentes se comunican con
otros componentes de la aplicacin! *a especificacin WEE define los siguientes
componentes WEEI
.plicaciones ;lientes, se consideran aplicacin cliente a aquel software
que corre en el equipo del cliente, pudiendo ser este un naegador Feb
que accede a recursos del seridor o aplicaciones stand alone
2/
!
;omponentes Feb de seridor, son componentes que permiten
desarrollar aplicaciones basadas en Feb!
;omponentes de *gica de :egocio, son componentes desarrollados
exclusiamente para brindar recursos de lgica de negocio!
. excepcin de las aplicaciones clientes, los otros tipos de componentes, deben
ejecutarse en un &eridor de .plicaciones
@@
!
2.M.2. /odelo de A"lic!cin ?!$! EE
El modelo de aplicacin Waa EE define una arquitectura para la
implementacin de sericios como las aplicaciones de arios nieles que
proporcionan la escalabilidad, accesibilidad y capacidad de gestin necesaria
para aplicaciones de niel empresarial! Este modelo de particiones de los
trabajos necesarios para implementar un sericio de arios nieles en dos
partesI la empresarial y la lgica de presentacin que ser ejecutada por el
seridor de aplicaciones y los sericios del sistema estndar proporcionado por
la plataforma Waa EE!
/2 Stand alone hace referencia a sistemas de informacin autnomos e independientes.
// Servidor de +plicaciones2 *ipo de servidor que permite el procesamiento de datos de una aplicacin de cliente. Nn
servidor de aplicaciones generalmente gestiona la mayor parte Io la totalidadJ de las funciones de lgica de
negocio y de acceso a los datos de la aplicacin. http2DDes."i4ipedia.orgD"i4iDServidorPdePaplicaciones.
0J
2.M.(. A"lic!ciones /ultic!"!
*a plataforma Waa EE utili"a un modelo de aplicacin distribuida multicapa
para aplicaciones empresariales! *a lgica de la aplicacin se diide en
componentes segn la funcin, y los componentes de distintas aplicaciones que
componen una aplicacin Waa EE se instalan en mquinas diferentes
dependiendo del niel en el entorno de mltiples nieles Waa EE al que
pertenece el componente de aplicacin! *a Gigura <!-@ muestra los nieles
mltiples de las aplicaciones Waa EE, estos nieles se describen de la formaI
:iel de componentes de ;liente, ejecucin en la mquina cliente!
:iel de componentes Feb, ejecucin en el seridor de Waa EE!
:iel de componentes Empresariales, ejecucin en el seridor de WEE!
:iel del &istema de informacin empresarial =E%&>, software que se
ejecuta en el seridor E%&!
.unque una aplicacin Waa EE puede constar de los tres o cuatro nieles que
se muestra en la Gigura <!-@, las aplicaciones Waa EE multicapa se consideran
en general .plicaciones que se diiden en tres nieles, ya que estn distribuidas
en tres localidadesI las mquinas clientes, el seridor Waa EE, y la base de
datos o el legado de las mquinas en la parte final!
Gigura <!-@I .plicaciones Aulticapa
GuenteI Extrado de E&$:18H
08
2.M.:. Se,urid!d
Aientras que otros modelos de aplicacin de una plataforma empresarial
requieren medidas de seguridad especficas en cada aplicacin, el entorno de
seguridad de Waa EE permite las restricciones de seguridad que debern
definirse en el tiempo de despliegue! *a plataforma Waa EE proporciona a las
aplicaciones porttiles para una amplia ariedad de implementaciones de
seguridad, colaborando a los desarrolladores de aplicaciones en la reali"acin
de complejos elementos de seguridad de la aplicacin!
*a plataforma Waa EE proporciona las reglas estndar de control de acceso
declaratio que se definen por el seridor de aplicaciones e interpretado cuando
la aplicacin se implementa en el seridor! Waa EE tambi(n ofrece mecanismos
de inicio de sesin estndar para los desarrolladores de aplicaciones y no
tienen que aplicar estos mecanismos en sus aplicaciones E&$:18H!
06
CAPTULO III
INGENIERA DEL PRONECTO
(. INGENIERA DEL PRONECTO
En este captulo se reali"ar el desglose y descripcin del proceso de %ngeniera
aplicado al presente Proyecto de Grado bajo el rtulo de 44ileSuccesS%ool5, un
sistema de informacin web para reali"ar la administracin y seguimiento de las
actiidades de gestin de proyectos de software que apliquen la metodologa
&crum, que es el resultado del trabajo reali"ado!
(.1 Introduccin
*a ingeniera del proyecto, una e" determinado qu( es lo que se quiere
obtener, comien"a con la definicin de la metodologa que ayudar a lograr el
objetio y determinar cmo ser logrado!
&e #a seleccionado la metodologa gil para gestin de proyectos de software
&crum que #a sido alorada como la ms apropiada por arias ra"ones entre
las cuales se detallan las principalesI
El producto esperado inicialmente no contaba con todas las
especificaciones de requerimientos bien definidos, ya que este Proyecto
de Grado no #a sido concebido con una orientacin #acia una empresa o
institucin en especfico sino a profesionales del rea de +ecnologa de la
%nformacin que se dedican a gestionar proyectos de software!
Para conocer la eolucin del proyecto y tambi(n obtener realimentacin
sobre las necesidades reales a las que deba responder el sistema, se
precisaba de ersiones funcionales preias a la ersin final! ;on el
objeto de satisfacer en mayor medida los objetios planteados!
Kada la sensibilidad, importancia y complejidad que tiene la reali"acin
de un +rabajo de Gin de ;arrera exista la necesidad de reisar
frecuentemente el trabajo reali"ado' poseer el m(todo ms adecuado
para poder llegar a reali"ar una correcta gestin del proyecto' aplicar
71
t(cnicas, que no demanden muc#a dedicacin, para controlar el aance
del proyecto!
.#ora bien, en los siguientes apartados se reali"ar la descripcin de la forma
en la que se aplic, utili" y adapt segn las necesidades la metodologa
seleccionada!
(.2 A"lic!cin de Scru
*a forma en que fue aplicada la metodologa seleccionada, &crum, ser
mostrada en los apartados que siguen a continuacin' el presente proyecto fue
desarrollado a lo largo de 0 ciclos iteratios, denominados &prints!
*a documentacin del presente proyecto fue eolucionando e incrementndose
a lo largo del desarrollo de los &prints, segn era el aance de la construccin
del sistema!
En la Gase de Kesarrollo, segunda fase de &crum, se aplic la adaptacin de
una metodologa gil orientada al desarrollo de softwareI Programacin
Extrema! Qa que &crum, como metodologa de gestin de proyectos de
software, no cubre aspectos de desarrollo de sistemas de informacin y por su
parte la Programacin Extrema, como metodologa de desarrollo de software,
comparte y aplica de forma similar a &crum sus actiidades y prcticasI es
posible y adem"s resulta una con5unci.n arm.nica estionar un proyecto de
software con la metodolo6a Scrum y desarrollarlo con la metodolo6a
,roramaci.n E7trema!
(.( 1!se Preliin!r
*a planificacin y el dise/o de alto niel de la arquitectura del sistema
corresponden a la primera fase del desarrollo &crum, Gase Preliminar! Esta fase
se diide en dos
En esta fase se identifican dos sub fases' en la primera, la Planificacin, se
reali"a la definicin de la isin del producto para elaborar un dise/o general de
forma simple y gil, se definen los roles del proyecto, el 3acDlog del Producto
que corresponde a la lista de #istorias de usuario o requerimientos, se definen
7-
de forma general las ersiones del proyecto, se alora y selecciona la
infraestructura y las #erramientas de desarrollo y por ltimo se reali"a una
estimacin de costos para el proyecto' en la &egunda sub fase, dise/o de alto
niel de la arquitectura del sistema, se reali"a en base al 3acDlog del Producto
la representacin del modelo de dominio, se define el dise/o arquitectnico y
finalmente se reali"a el dise/o de la reisin del trabajo desarrollado en cada
uno de &prints!
. continuacin se describe las acciones reali"adas en cada sub?fase!
(.(.1 Pl!ni%ic!cin
En la sub?fase de planificacin se reali"aron las siguientes actiidadesI
a> Kefinicin de la isin del producto
*a isin del producto responde al logro del objetio general planteado en el
;aptulo % del presente documento as como tambi(n la delimitacin general de
las expectatias del sistema detallada en el mismo captulo como lmites y
alcances!
b> Kefinicin de los roles del proyecto
El equipo de trabajo definido para la construccin del sistema de informacin,
4ileSuccesS%ool, se muestra en la +abla @!-, roles en el proyecto!
+abla @!-I Loles en el proyecto
Rol Descri"cin
&crumAaster - persona encargada de reali"ar las prcticas de &crum en el
proyecto
Propietario del producto - persona responsable de las decisiones sobre los requerimientos en
el proyecto
Equipo &crum - persona constituye el equipo de desarrollo
GuenteI Elaboracin propia
c> Kesarrollo del 3acDlog del producto
$na e" definidos los roles en el proyecto se procede con el desarrollo del
3acDlog del Producto, que es la lista de requerimientos que deben ser
desarrollados para la obtencin del producto final denominado
7<
4ileSuccesS%ool, cada uno de los elementos de esta lista de trabajo reflejan
una #istoria de usuario!
En la tabla +abla @!<, se muestra el 3acDlog del Producto 4ileSuccesS%ool, se
debe mencionar que esta lista de requerimientos, es el fruto de arios ensayos y
modificaciones por parte del Propietario del Producto quien con colaboracin del
Equipo &crum lograron obtener un listado de #istorias de usuario que satisfaga
las necesidades del Propietario del Producto pero a la e" tambi(n sean reales
en cuanto a las posibilidades t(cnicas y tecnolgicas del Equipo &crum,
permitiendo una comprensin total de las mismas!
+abla @!<I 3acDlog del Producto .gile&ucces&+ool
/CDULO3 PRE9IO DESARROLLO SISTE/A
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
- PLE?11- Kise/o de interfaces no funcionales para
administracin de Proyectos!
:o
Guncional
.lta
< PLE?11< Kise/o de interfaces no funcionales para
administracin de Leuniones!
:o
Guncional
.lta
@ PLE?11@ Kise/o de interfaces no funcionales para
administracin de &prints!
:o
Guncional
.lta
/CDULO3 AD/INISTRACICN DE USUARIOS
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
B $&$?11- El sistema debe permitir .lta, Aodificacin y
3aja de usuarios!
Guncional Aedia $&$?11-
0 $&$?11< Leali"ar el cambio de contrase/a en usuarios! Guncional Aedia $&$?11-'
$&$?11B
7 $&$?11@ Permitir la asignacin de roles! Guncional Aedia $&$?110'
$&$?117
J $&$?11B Permitir la asignacin de priilegios a los roles! Guncional Aedia
8 $&$?110 Leali"acin de .lta, Aodificacin y 3aja de roles Guncional Aedia
6 $&$?117 Leali"ar la .lta, Aodificacin y 3aja de
priilegios!
Guncional Aedia
/CDULO3 CON1IGURACICN DEL SISTE/A
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
-1 ;9:?11- Kefinicin de unidades de tiempo =equialencias
de da, mes y #oras>!
Guncional 3aja
7@
/CDULO3 AD/INISTRACICN DE PRONECTOS
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
-- PL9?11- El sistema debe permitir .lta, Aodificacin y
3aja de proyectos!
Guncional .lta
-< PL9?11< Para cada proyecto se debe administrar la
siguiente informacinI :ombre, objetio,
descripcin, cronograma tentatio =fec#a inicio y
finali"acin> y prioridad!
Guncional .lta PL9?11-
-@ PL9?11@ El sistema debe permitir la definicin de
integrantes del equipo de un proyecto, lder de
proyecto =obligatorio>!
Guncional .lta PL9?11<
-B PL9?11B El sistema debe permitir la definicin de cliente
y propietario del producto de un proyecto
=informacin de contacto, referente a su cargo
en la empresa cliente y disponibilidad de
tiempo>!
Guncional .lta PL9?11<
-0 PL9?110 &e debe registrar la documentacin de
referencia como serI marco conceptual,
requerimientos gen(ricos =solicitud formal, no
confundir con #istorias de usuario>!
Guncional 3aja PL9?11<
-7 PL9?117 .dministracin de requerimientos, 3acDlog del
Producto! Es el inentario de caractersticas que
el propietario del producto desea obtener en el
producto final!
Guncional .lta PL9?11J
-J PL9?11J &e debe registrar nombre, descripcin, estado,
solicitante y prioridad de cada requerimiento!
Guncional .lta PL9?11<
-8 PL9?118 Kefinir la duracin de los &prints en un
proyecto!
Guncional Aedia PL9?11-
/CDULO3 AD/INISTRACICN DE REUNIONES
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
-6 LE$?11- El sistema debe permitir .lta, Aodificacin y
3aja de reuniones con el cliente y dentro del
equipo de desarrollo en un proyecto!
Guncional .lta PL9?11-'
PL9?11@'
PL9?11B
<1 LE$?11< Leali"ar la planificacin de reuniones despu(s
de definir responsables e integrantes del
equipo!
Guncional .lta LE$?11-
<- LE$?11@ Leali"ar registro de puntos acordados en una
reunin!
Guncional .lta LE$?11<
<< LE$?11B Leali"ar el registro de asistentes a una reunin! Guncional .lta LE$?11<
<@ LE$?110 Leali"ar el registro de #ora, fec#a y lugar de las
reuniones!
Guncional .lta LE$?11-
7B
/CDULO3 AD/INISTRACICN DE SPRINTS
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
<B &PL?11- El sistema debe permitir .lta, Aodificacin y
3aja de ms de un sprint de un proyecto a la
e"!
Guncional .lta PL9?11-
<0 &PL?11< Leali"ar la planificacin de un sprint! Legistrar
fec#a de inicio y finali"acin, objetio, trabajo
definido =tareas a ser reali"adas>!
Guncional .lta &PL?11-
<7 &PL?11@ Leali"ar .lta, Aodificacin y 3aja de ms de
una tarea a la e"!
Guncional .lta &PL?11-
<J &PL?11B Legistrar nombre, descripcin, duracin, estado
y responsable de cada tarea!
Guncional .lta &PL?11@
<8 &PL?110 Leali"ar la asignacin de tareas a los
integrantes del equipo!
Guncional .lta &PL?11@
<6 &PL?117 Leali"ar el seguimiento de un sprint!
actuali"acin de estimacin de tiempos del
trabajo restante =proceso para cada tarea>!
Guncional .lta &PL?11@'
&PL?110
@1 &PL?11J Leali"ar la reisin de un sprint! .dministrar los
resultados de cada &print, refleja la cantidad de
requerimientos o funcionalidad cumplidas
efectiamente en cada sprint!
Guncional Aedia &PL?117
@- &PL?118 Leali"ar la actuali"acin del incremento
reali"ado en el sprint para el producto
desarrollado!
Guncional Aedia &PL?11J
/CDULO3 GENERAL
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
@< &%&?11- El sistema debe posibilitar el acceso de los
usuarios a tra(s de una red de acceso pblico
=basado en Feb>!
:o
Guncional
.lta
@@ &%&?11< Permitir las :otificaciones por email =arias
acciones' recordatorios reuniones planificadas,
tareas pendientes, !!!>!
Guncional 3aja
@B &%&?11@ Leali"ar el registro de #abilidades t(cnicas de
los integrantes de un equipo de desarrollo!
Guncional Aedia
/dulo3 REPORTES
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
@0 LEP?11- Grfico 3urn$pI )erramienta de gestin y
seguimiento para el propietario del producto!
Presenta de un ista"o las ersiones de
producto preistas, las funcionalidades de cada
una, elocidad estimada, fec#as probables para
cada ersin, margen de error preisto en las
estimaciones, y aance real!
Guncional Aedia &PL?118
70
@7 LEP?11< Grfico 3urn KownI )erramienta del equipo
para reali"ar el seguimiento del trabajo de cada
&print! Lepresentacin bsica del aance del
&print!
Guncional Aedia &PL?117
@J LEP?11@ Leporte del estado de las tareas asignadas a un
integrante del equipo de desarrollo del proyecto!
Guncional Aedia &PL?110'
&PL?117
@8 LEP?11B ;onsulta de las reuniones planificadas y
reali"adas en un proyecto!
Guncional Aedia LE$?11@'
LE$?11B'
LE$?110
GuenteI Elaboracin Propia
En el 3acDlog del Producto se asign un nmero correlatio a cada #istoria de
usuario y un cdigo segn el mdulo al que corresponden, el equipo &crum se
encarg de clasificar las #istorias de usuario segn el tipo funcional o no
funcional en el sistema, el propietario del producto segn su importancia asigna
la prioridad a cada elemento del 3acDlog del producto!
d> Kefinicin de las ersiones del proyecto
&e #a planificado que el desarrollo del proyecto ser reali"ado a lo largo de tres
ersiones' la primera responde a una ersin no funcional por eso se la
denomin como Persin 1, la segunda y tercera son ersiones funcionales
denominadas Persin 1!- y Persin 1!<!
;ada una de las ersiones esta compuesta por uno o ms &prints, se #a
definido que un &print tendr una duracin de < semanas o su equialente -1
das calendario! . continuacin se describe la planificacin tentatia reali"ada
para las ersiones mencionadas!
Persin 1I *a elaboracin del mdulo 4Preio Kesarrollo &istema5 no
aporta ningn tipo de funcionalidad al producto final, no obstante las
tareas definidas para las #istorias de usuario que componen este mdulo
se reali"aron dentro de un &print y adems el resultado obtenido aport
gran alor para el equipo de desarrollo en lo referente a la construccin
del sistema! El resultado esperado para esta ersin se #a definido
comoI
*a obtencin del dise/o de interfaces de usuario para las
funcionalidades principales de .gile&ucces&+ool como lo es
77
.dministracin de Proyectos, Leuniones y &prints!
. partir del dise/o de interfaces de usuario, se espera la obtencin del
modelo de datos!
Kise/o de diagramas generales, reisin y ajuste de los
requerimientos =#istorias de usuario> y ealuacin de los
componentes tecnolgicos a ser utili"ados en el desarrollo del
sistema!
Persin 1!-I Ke forma general en esta ersin se plante el desarrollo de
los siguientes mdulosI .dministracin de Proyectos, .dministracin de
&prints!
Persin 1!<I Para esta ersin se defini el desarrollo de los siguientes
mdulosI .dministracin de Leuniones, Leportes, General y
;onfiguracin del &istema y .dministracin de $suarios!
. continuacin en la Gigura @!-, se muestra la planificacin de las ersiones
para el proyecto!
Gigura @!-I Persiones planificadas del proyecto
GuenteI Elaboracin Propia
&e debe mencionar que las #istorias de usuario del tipo :o Guncional,
exceptuando las que se describen en el Adulo 4Preio al Kesarrollo del
7J
&istema5, se tomaron en cuenta a lo largo de todo el proceso de eolucin del
proyecto ya que este tipo de #istorias de usuario no aporta funcionalidad al
sistema pero si delimitan la forma en la que el usuario espera que funcione!
e> Paloracin y seleccin de infraestructura y #erramientas de desarrollo
*a infraestructura seleccionada para 4ileSuccesS%ool se #a definido de la
siguiente formaI
Sun &lass8ish Enterprise Server
21
9 &eridor de .plicaciones Feb que no
requiere un pago de licencia para su utili"acin en su ersin libre, desarrollado
por &un Aicrosystems, considerado en su categora como un seridor de
aplicaciones estable!
,ostreS:L
2;
9 &istema de Gestin de base de datos relacional orientada a
objetos de software libre publicado bajo la licencia 3&K
@7
, desarrollado en la
actualidad por PGKG
@J
!
Conectividad9 los seridores de aplicaciones web y de base de datos deben
tener un conectiidad deseable de 0-< Ab si an a funcionar en una red pblica
y tener una direccin %P esttica o fija!
0aveador <eb9 para el acceso de los usuarios al sistema web es
recomendable el uso de Girefox, aunque no excluyente el uso de ;#rome o
%nternet Explorer!
*as #erramientas que se #an definido para la obtencin del sistema de
informacin web 4ileSuccesS%ool son las siguientesI
,ower)esiner
2=
9 )erramienta para modelado empresarial, utili"ada para
reali"ar el modelado de datos, desarrollada por &ybase!
0et(eans
2>
9 Entorno de desarrollo integrado, utili"ado para reali"ar la
codificacin del sistema, #erramienta patrocinada por &un Aicrosystems!
?ava Enterprise Edition9 Plataforma tecnolgica que se basa en el lenguaje de
/= https2DDglassfish.dev.java.netD
/A http2DD""".postgresql.orgD
/& Bicencia BS<2 es una licencia de soft"are otorgada que permite el uso del cdigo fuente en soft"are no li.re
http2DDes."i4ipedia.orgD"i4iDBicenciaPBS<
/C @9<92 @ostgreSQB 9lo.al <evelopment 9roup, comunidad de desarrolladores y organi(aciones comerciales que
tra.ajan en el desarrollo de @ostgreSQB http2DDes."i4ipedia.orgD"i4iD@ostgreSQB
/' http2DD""".sy.ase.comDproductsDmodelingdevelopmentDpo"erdesigner
/% http2DD""".net.eans.orgD
78
programacin Waa y utili"a un modelo de aplicacin multicapa distribuida!
AagicKraw
B1
I )erramienta ;.&E para el modelado isual de diagramas $A*,
desarrollado por :o Aagic, %nc!
f> Estimacin de costos
*a estimacin de costos para el presente proyecto se determin por medio de
m(tricas orientadas a la funcin, para tal suceso se aplic el m(todo
denominado ;lculo de Puntos de Guncin complementado con el m(todo
;ocomo 3sico!
En el .nexo E se detalla el anlisis reali"ado para la estimacin de costos con
;ocomo 3sico mediante el ;lculo de Puntos de Guncin, as como tambi(n el
detalle de costos fijos!
(.(.2 Dise4o de !lto ni$el Ar+uitectur! del siste!
*a sub?fase de dise/o de alto niel de la arquitectura del sistema describe las
siguientes actiidades reali"adasI
a> Lepresentacin del modelo de dominio
Gigura @!<I Aodelo de Kominio
GuenteI Elaboracin Propia
=G http2DD""".magicdra".comD
76
Leali"ado el anlisis para el alcance requerido en el desarrollo del presente
proyecto, el modelo de dominio identificado se muestra en la Gigura @!<, modelo
de dominio!
b> Kefinicin del dise/o arquitectnico
*a arquitectura de un sistema tiene como finalidad facilitar la construccin,
escalabilidad y mantenimiento del mismo, la arquitectura bsica definida para el
presente proyecto es la arquitectura ;entrada a Katos!
En la figura @!@, se muestra la distribucin tecnolgica reali"ada en base a la
arquitectura centrada a datos!
Gigura @!@I .rquitectura tecnolgica del &istema
GuenteI Elaboracin Propia
El seridor de aplicaciones es un componente principal para la arquitectura
tecnolgica del sistema, en este sentido se utili" Waa Enterprise Edition 0
=WEE 0> como tecnologa de desarrollo!
El seridor de aplicaciones y el seridor de base de datos no necesariamente
tienen que encontrarse en equipos fsicos diferentes, ambos pueden estar
configurados en un solo equipo computacional!
+ambi(n se define la arquitectura lgica o el modelo multicapa orientado a la
J1
plataforma Waa Edicin Empresarial 0! En la Gigura @!B se muestra el modelo
multicapa general para 4ileSuccesS%ool!
Gigura @!BI Aodelo multicapa general para 4ileSuccesS%ool
GuenteI Aodificado de E&$:18H
c> Kise/o de la reisin a reali"arse para el trabajo #ec#o dentro los sprints
*a reisin y presentacin del aance desarrollado sern reali"ados en una
reunin a la finali"acin de cada uno de los &prints!
Para el primer &print se #a dise/ado la reisin de la siguiente formaI
Presentacin de las interfaces de usuario dise/adas, el modelo de datos
general y dems documentacin y diagramas desarrollados!
.nlisis de la informacin presentada!
.ceptacin y aprobacin para iniciar el desarrollo del sistema!
Para los siguientes &prints la reisin ser reali"ada de la siguiente formaI
.pertura de reunin de reisin con la lectura del objetio del &print!
Presentacin del incremento reali"ado por el equipo de desarrollo'
Ealuacin en base a la planificacin y objetio del sprint de la
funcionalidad desarrollada, esta ealuacin la reali"a el propietario del
producto en un formulario dise/ado para cada &print!
J-
*a ealuacin reali"ada a la finali"acin de un &print ser anali"ada en la
reunin de planificacin del siguiente &print!
El formato para el formulario de ealuacin para los &prints se muestra en el
.nexo K, Kesarrollo &prints!
(.: 1!se de Des!rrollo
En la Gase de Kesarrollo se reali"an los ciclos iteratios, denominados &prints,
en los cuales es desarrollado el trabajo y por consiguiente en esta fase es
construido el sistema de forma incremental y eolutia!
(.:.1 Ad!"t!cin Scru . Pro,r!!cin E0tre!
Qa que la segunda fase de &crum est orientada al desarrollo del sistema, se #a
reali"ado una adaptacin con la metodologa de desarrollo MP, debido a que las
prcticas reali"adas en esta metodologa resultan un ptimo complemento al
proceso de gestin reali"ado en el proyecto!
Gigura @!0I .daptacin &crum?MP
GuenteI Elaboracin Propia
En la Gigura @!0, se expone la adaptacin &crum?MP aplicada en el presente
proyecto!
J<
*as prcticas tomadas de MP se #an aplicado dentro el desarrollo de los &prints
en el trabajo diario, de modo que el desarrollo de un &print contemplaba
ademsI
*a utili"acin de estndares de cdigo, para la escritura de lneas de
cdigo siguiendo reglas de codificacin establecidas al lenguaje de
programacin!
El desarrollo dirigido por pruebas! &e escriben las pruebas funcionales
antes de que se escriban las lneas de cdigo! &e reali"aron dos tipos de
pruebasI las pruebas unitarias, que erifican los m(todos de una sola
clase, y las pruebas de aceptacin, que erifican funcionalidades
completas o mdulos del sistema!
Kise/o &imple! El (nfasis se deposita en dise/ar la solucin ms simple
susceptible de implementarse en el momento! &e eliminan complejidades
innecesarias y cdigo extra, no se implementa nada que no se necesite
a#ora!
Lefactoreo! &e refactori"a el sistema eliminando la duplicacin sin
cambiar la funcionalidad!
%ntegracin continua! ;ada pie"a se integra a la base de cdigo apenas
est lista y se reali"an pruebas antes y despues de la integracin!
*a fase de desarrollo esta compuesta por ciclos iteratios, denominados &prints,
en los cuales es desarrollado el trabajo! ;ada uno de estos &prints consta de @
partesI Planificacin, &eguimiento y Leisin del &print!
(.:.2 Pl!ni%ic!cin S"rint
*a planificacin de un &print es reali"ada en una reunin denominada Leunin
de Planificacin, los asistentes a esta reunin sonI el &crum Aaster, el
Propietario del Producto y el Equipo &crum!
En la reunin de planificacin se debe exponer el 3acDlog del Producto,
se/alando qu( elementos tienen mayor prioridad!
Esta accin se ira repitiendo a lo largo del proyecto, de manera que tras cada
J@
que se finalice un &print se obtendr realimentacin del mismo, tal como se
mostr en la Gigura <!0! &e mostrar el proceso del primer &print!
a> &eleccin 3acDlog del Producto
$na e" expuesto y anali"ado el 3acDlog del Producto se procede a la seleccin
segn prioridad e importancia de los elementos del 3acDlog, #istorias de
usuario, que sern desarrollados en el &print! . continuacin en la +abla @!@, se
muestra los elementos del 3acDlog seleccionados!
+abla @!@I Elementos del 3acDlog del Producto para el &print -
/dulo3 PRE9IO DESARROLLO SISTE/A
No. Cdi,o Descri"cin Ti"o Priori)
d!d
De"en)
denci!
- PLE?11- Kise/o de interfaces no funcionales para
administracin de Proyectos
:o
Guncional
.lta
< PLE?11< Kise/o de interfaces no funcionales para
administracin de Leuniones
:o
Guncional
.lta
@ PLE?11@ Kise/o de interfaces no funcionales para
administracin de &prints
:o
Guncional
.lta
GuenteI Elaboracin Propia
b> Kefinicin del &print
. partir de las #istorias de usuario, elementos del 3acDlog del Producto,
seleccionadas se define el objetio para el &print - como sigue a continuacinI
)ise@o de las las interfaces de usuario no funcionales para los m.dulos de
4dministraci.n de ,royectos, 4dministraci.n de 'euniones y 4dministraci.n de
SprintsA dise@o del modelo de datos eneralA dise@o de diaramas enerales
para la construcci.n del sistema.
*a capacidad del sprint se calcula en base a la duracin definida para el sprint y
la cantidad de tiempo dedicado de los integrantes del Equipo &crum' la
capacidad del &print - es de 81, lo que quiere decir que la sumatoria de las
estimaciones de los elementos del 3acDlog del &print no debe superar a 81!
c> Kefinicin del 3acDlog del &print
$na e" definido el objetio del sprint, y a partir de los elementos del 3acDlog
del Producto seleccionados se reali"a el 3acDlog del &print, que consiste en un
JB
listado de tareas que se reali"arn durante el &print!
;ada una de estas tareas definidas tiene un nmero secuencial, un cdigo, una
descripcin de la tarea, #istoria de usuario a la que pertenece, prioridad dentro
el sprint y estimacin!
*a prioridad es asignada por el equipo segn la importancia de la tarea o el
grado de dependencia de otras tareas, el tiempo para la reali"acin de la tarea
es estimado por el equipo en base a su experiencia en desarrollo! En la +abla
@!B, se muestra el 3acDlog del &print -!
+abla @!BI 3acDlog del &print -
No. Cdi,o Descri"cin Priorid!d Est.Hrs HU
- +?11- Kise/o interfa" de usuario =%$> del panel de
control de proyectos de software
.lta 7 PLE?11-
< +?11< Kise/ar %$ para registro nueo proyecto .lta B PLE?11-
@ +?11@ Kise/ar %$ para asignar responsables a un
proyecto
.lta @ PLE?11-
B +?11B Kise/ar %$ para determinar los roles que existirn
en un proyecto
.lta < PLE?11-
0 +?110 Kise/ar %$ para asignar roles a un proyecto Aedia < PLE?11-
7 +?117 Kise/ar %$ para er el perfil de un integrante de
un proyecto
Aedia @ PLE?11-
J +?11J Kise/ar %$ para buscar integrantes de un
proyecto
Aedia < PLE?11-
8 +?118 Kise/ar %$ para registrar una nuea reunin .lta < PLE?11<
6 +?116 Kise/ar %$ para administrar reuniones .lta B PLE?11<
-1 +?1-1 Kise/ar %$ para registrar un nueo &print .lta < PLE?11@
-- +?1-- Kise/ar %$ para reali"ar la planificacin de un
&print
.lta B PLE?11@
-< +?1-< Kise/ar %$ para registrar una nuea tarea .lta @ PLE?11@
-@ +?1-@ Kise/ar %$ para registrar una nuea )istoria de
$suario
Aedia < PLE?11@
-B +?1-B Kise/ar %$ para buscar una #istoria usuario Aedia @ PLE?11@
-0 +?1-0 Kise/ar %$ para buscar una tarea Aedia < PLE?11@
-7 +?1-7 Kise/ar el modelado de datos a partir de las %$
dise/adas
.lta <1
-J +?1-J Kise/o de diagramas para la construccin del
sistema
.lta -7
Tot!l Dor!s esti!d!s3 M'
GuenteI Elaboracin Propia
J0
(.:.( Se,uiiento S"rint
$na e" reali"ada la planificacin, el seguimiento de un &print es un proceso de
reali"acin diario!
;omo se explic en el ;aptulo %%, el 3acDlog del &print es actuali"ado todos los
das por los miembros del Equipo &crum acerca de la estimacin de tiempo del
trabajo por reali"ar!
.#ora bien, una e" terminado el &print se puede mostrar el 3acDlog del &print!
En la +abla @!0, se muestra el 3acDlog final del &print -!
+abla @!0I 3acDlog Ginal &print -
S"rint3 &print - Dur!cin3 -1
+areas PendientesI -7 -< -< -1 J B < < < 1
)oras de +rabajo PendientesI 76 71 07 01 B@ @7 @- -8 -1 1
No. Cdi,o Priori
d!d
Est!do Est.
Hrs
1 2 ( : < B L M O 1'
- +?11- .lta +erminado 7 @ 1 1 1 1 1 1 1 1 1
< +?11< .lta +erminado B - 1 1 1 1 1 1 1 1 1
@ +?11@ .lta +erminado @ 1 1 1 1 1 1 1 1 1 1
B +?11B .lta +erminado < < 1 1 1 1 1 1 1 1 1
0 +?110 Aedia +erminado < < 1 1 1 1 1 1 1 1 1
7 +?117 Aedia +erminado @ @ @ @ @ 1 1 1 1 1 1
J +?11J Aedia +erminado < < < @ @ 1 1 1 1 1 1
8 +?118 .lta +erminado < < < < 1 1 1 1 1 1 1
6 +?116 .lta +erminado B B B B 1 1 1 1 1 1 1
-1 +?1-1 .lta +erminado < < < < < 1 1 1 1 1 1
-- +?1-- .lta +erminado B B B < < @ 1 1 1 1 1
-< +?1-< .lta +erminado @ @ @ < < < 1 1 1 1 1
-@ +?1-@ Aedia +erminado < < < < < < 1 1 1 1 1
-B +?1-B Aedia +erminado @ @ @ @ @ @ @ 1 1 1 1
-0 +?1-0 Aedia +erminado < < < < < < < 1 1 1 1
-7 +?1-7 .lta +erminado <1 -8 -J -0 -0 -0 -0 -0 8 B 1
-J +?1-J .lta +erminado -7 -7 -7 -7 -7 -7 -7 -7 -1 7 1
GuenteI Elaboracin Propia
Ke la misma forma, la #erramienta que est destinada al control del trabajo
pendiente para el equipo de desarrollo en la metodologa &crum, denominada
J7
Grfico de trabajo pendiente o Grfico 3urn?Kown, es actuali"ada diariamente,
mostrando la estimacin del trabajo que an queda pendiente!
;abe recordar que la metodologa &crum no se basa en el control sobre el
trabajo que ya #a sido reali"ado por el contrario (sta metodologa centra su
orientacin en el control sobre el trabajo que an queda pendiente!
En la Gigura @!7, se muestra el grfico 3urn?Kown final del &print -!
Gigura @!7I 3urn?Kown Ginal &print -
GuenteI Elaboracin Propia
(.:.: Re$isin S"rint
;omo se mencion con anterioridad la reisin del primer &print se reali" en
una reunin denominada Leunin de Leisin de la siguiente formaI
Presentacin de las interfaces de usuario dise/adas, el modelo de datos
general y dems documentacin y diagramas desarrollados!
.nlisis de la informacin presentada!
.ceptacin y aprobacin para iniciar el desarrollo del sistema!
. continuacin se muestra el trabajo reali"ado durante el desarrollo del &print -!
a> Kise/o de %nterfaces de $suario
*as interfaces de usuario dise/adas en el &print - suman un total de -7, que
representan las acciones que se tomaron como de mayor importancia para el
JJ
- < @ B 0 7 J 8 6 -1
1
<1
B1
71
81
Grfico 3urn?Kown
+rabajoSEsfuer"o Pendiente
.ance Leal &pri nt
.ance Ypti mo
Kas
)
o
r
a
s

+
r
a
b
a
j
o

P
e
n
d
i
e
n
t
e
sistema! En la figuras siguientes se muestra las interfaces de usuario ms
representatias!
Gigura @!JI %nterfa" de $suario?Panel de ;ontrol Proyectos
GuenteI Elaboracin Propia
El Panel de ;ontrol de Proyectos, que se muestra en la Gigura @!J, es la interfa"
de usuario que ser una de las pantallas principales del sistema, ya que
proporciona un resumen del estado de los proyectos, un resumen del estado de
las tareas de cada uno de los proyectos y una ista sobre las reuniones
planificadas y reali"adas para el usuario del sistema!
El Panel de ;ontrol de +areas, mostrado en la Gigura @!8, es la interfa" de
usuario que proporciona informacin dirigida a los integrantes del=los>
proyecto=s>, persona a la que se asigna tareas asociadas al rol que tiene dentro
de cada uno de los proyectos gestionados! Presentando informacin sobre el
estado de cada una de las tareas de cada proyecto que #an sido asignadas al
usuario que ingresa al sistema! Ke la misma forma que en Panel de ;ontrol de
Proyectos, una ista sobre las reuniones planificadas y reali"adas para el
usuario que ingresa al sistema!
J8
Gigura @!8I %nterfa" de $suario?Panel ;ontrol +areas
GuenteI Elaboracin Propia
Gigura @!6I %nterfa" de $suario?Legistrar :ueo Proyecto
GuenteI Elaboracin Propia
*a interfa" de usuario :ueo Proyecto de la Gigura @!6, representa un
formulario en el que se registra la informacin de un nueo proyecto para ser
gestionado por el sistema!
J6
Gigura @!-1I %nterfa" de $suario?Legistrar :ueo &print
GuenteI Elaboracin Propia
*a Gigura @!-1, interfa" de usuario :ueo &print, representa un formulario en el
que se registra la informacin de un nueo &print que pertenecer a un
proyecto!
Gigura @!--I %nterfa" de $suario?Planificacin &print
GuenteI Elaboracin Propia
81
*a Gigura @!-<, muestra la interfa" de usuario dise/ada para reali"ar la
planificacin de un &print! Lepresenta la seleccin de #istorias de usuario para
un &print y el registro de tareas a partir de las #istorias de usuario
seleccionadas!
Gigura @!-<I %nterfa" $suario?Perfil %ntegrante
GuenteI Elaboracin Propia
En la Gigura @!-<, Perfil %ntegrante, muestra la informacin que puede ser
obtenida mediante el sistema sobre las #abilidades de un integrante del equipo
de desarrollo de un proyecto, as como tambi(n del tiempo de trabajo que an
tiene pendiente!
*as interfaces de usuario mostradas en las Giguras @!J, @!8, @!6, @!-1, @!-- y
@!-< son las que #an sido consideradas, del conjunto, como las ms
representatias!
Kebido a que debe existir un amplio canal de comunicacin entre todos los
integrantes del proyecto, el dise/o de las %nterfaces de $suario #a sido
reali"ada conjuntamente con el responsable del producto, lo cual facilit la
construccin del sistema en los siguientes &prints!
b> Aodelo de datos %nicial
El Aodelo de Katos dise/ado para el sistema web 4ileSuccesS%ool, por
aspectos de mejor isibilidad, ser mostrado por partes, segn la relacin de
sus elementos!
8-
Gigura @!-@I Aodelo Katos =parte->
GuenteI Elaboracin Propia
Gigura @!-BI Aodelo Katos =parte<>
GuenteI Elaboracin Propia
8<
Gigura @!-0I Aodelo Katos =parte@>
GuenteI Elaboracin Propia
Gigura @!-7I Aodelo Katos =parteB>
GuenteI Elaboracin Propia
8@
Gigura @!-JI Aodelo Katos =parte0>
GuenteI Elaboracin Propia
*a Giguras @!-@, @!-B, @!-0, @!-7 y @!-J corresponden al Aodelo de Katos
reali"ado a partir de las interfaces de usuario dise/adas para el sistema
4ileSuccesS%ool!
c> Kiagrama de Estados
&iguiendo la notacin $A*, se #a reali"ado el dise/o de diagramas de estados
para representar el cambio de estado de los siguientes elementos del sistemaI
Proyecto
&print
)istoria de $suario
+area
Leunin
Qa que son considerados como los elementos ms importantes dentro el
desarrollo!
. continuacin se muestran los diagramas de estados reali"ados para el
proyecto!
8B
Gigura @!-8I Kiagrama de Estados
Proyecto
Gigura @!-6I Kiagrama de Estados
&print
GuenteI Elaboracin Propia GuenteI Elaboracin Propia
Gigura @!<1I Kiagrama de Estados
)istoria de $suario
Gigura @!<-I Kiagrama de Estados
+area
GuenteI Elaboracin Propia
GuenteI Elaboracin Propia
80
Gigura @!<<I Kiagrama de Estados X Leunin
GuenteI Elaboracin Propia
*os diagramas de estados mostrados #an sido dise/ados para cada uno de los
de los elementos ms importantes de los mdulos definidos en los
requerimientos! Ke forma que el diagrama de estados de proyecto corresponde
al modulo .dministracin de Proyectos y de la misma forma los dems
diagramas!
$na e" presentado el trabajo desarrollado en el &print - con su posterior
anlisis y aprobacin por parte de los interesados =&crumAaster, Equipo &crum
y Propietario Producto> se da la conclusin del mismo! Q se define la fec#a para
la reunin de planificacin del siguiente &print!
El desarrollo de los dems &prints reali"ados =&prints <, @, B y 0> se muestra en
el .nexo K, Kesarrollo &prints! Para ello se #a dise/ado formularios que
faciliten su isibilidad =formularios de planificacin y de reisin de &print>!
Kurante la eolucin de los &prints se #a definido una arquitectura de cuatro
capas para llear a cabo el proceso de desarrollo del sistemaI
;apa de Presentacin
;apa de *gica de :egocio
;apa de Persistencia de Katos
;apa de Lecursos Empresariales
En la Gigura @!<@, se muestra la arquitectura para el desarrollo del sistema!
87
Gigura @!<@I .rquitectura base para el desarrollo de sistemas web
GuenteI 3asado en E&$:18H
8J
W&PZs u otras istas
que generan )+A*
W&PZs u otras istas
que generan )+A*
.cciones de la ;apa Feb
Procesamiento de los datos de entrada
del $suario, llamadas a sericio de la
capa de negocio y administracin del
Glujo de :aegacin!
.cciones de la ;apa Feb
Procesamiento de los datos de entrada
del $suario, llamadas a sericio de la
capa de negocio y administracin del
Glujo de :aegacin!
Expone las caractersticas principales, administra lo referente a transaccionalidad,
incluye *gica de :egocio! :o conoce los detalles respecto a la persistencia
de informacin, &ericios declaratios son utili"ados en esta capa comnmente!
Expone las caractersticas principales, administra lo referente a transaccionalidad,
incluye *gica de :egocio! :o conoce los detalles respecto a la persistencia
de informacin, &ericios declaratios son utili"ados en esta capa comnmente!
%nterfase de .cceso a Katos
=K.9 interfase>
Kefine las operaciones de persistencia,
independientemente de la tecnologa
con la que se implementar!
%nterfase de .cceso a Katos
=K.9 interfase>
Kefine las operaciones de persistencia,
independientemente de la tecnologa
con la que se implementar!
%mplementacin de .cceso a Katos
=K.9 %mplementacin>
Lecibe y guarda entidades utili"ando
#erramientas 9LA o WK3;
%mplementacin de .cceso a Katos
=K.9 %mplementacin>
Lecibe y guarda entidades utili"ando
#erramientas 9LA o WK3;
/!"eo OPR
/!"eo OPR
Kominio de
9bjetos
Persistentes
Aodelo 99
Kominio de
9bjetos
Persistentes
Aodelo 99
F!se de D!tos
F!se de D!tos
C!"! de Present!cin
C!"! de L,ic! de Ne,ocio
C!"! de Persistenci! de
D!tos
C!"! de Recursos
E"res!ri!les
aJ ;apa de PresentacinI Esta capa es la encargada de interactuar con el
usuario, es en esta capa donde se desarrollan los componentes para la interfa"
de usuario, en esta capa existen tres elementosI
Pginas W&P y otros elementos que generen contenido )+A*, estos
elementos se encargan de brindar una interfa" a Feb, para ser
accedidas por :aegadores Feb!
.dministrar las acciones reali"adas por los clientes, esta capa adems
tiene elementos que 4controlan5 la acciones que reali"an los usuarios,
procesa los datos reali"ando alidaciones y conersiones apropiadas a la
informacin introducida por el usuario, en base a esta informacin reali"a
llamadas a los sericios de la capa de lgica de negocio, en aplicaciones
Feb tambi(n administra la lgica de naegacin del usuario, es decir
dependiendo de los eentos que genera el usuario determina a donde
eniarlo dentro la aplicacin!
b> ;apa de *gica de :egocioI En esta capa se reali"a el procesado de la
lgica de negocio, se expone las caractersticas principales del negocio a las
capa de presentacin y se administra todo lo referente a las transacciones de la
aplicacin' es importante destacar que esta capa no conoce de los mecanismos
de persistencia de la informacin, es decir en esta capa los componentes
desconocen en que 3ase de Katos se esta persistiendo la informacin,
inclusie s es una 3ase de Katos donde se esta persistiendo la informacin!
c> ;apa de Persistencia de KatosI Esta es la capa encargada de persistir y
proeer la informacin que utili"a la capa de *gica de :egocio, esta
compuesta por tres elementos principalesI
%nterfa" de .cceso de Katos =Kata .ccess 9bject>, este elemento define,
por medio de interfaces, las operaciones de persistencia que sern
utili"adas por la capa de *gica de :egocio, esta capa desconoce las
#erramientas tecnolgicas que se utili"aran para este propsito!
%mplementacin de .cceso a Katos, este elemento es el que recibe,
88
proporciona y guarda entidades utili"ando #erramientas 9LA =)ibernate,
EW3@>, #erramientas que extienden a WK3; o directamente puede
reali"arlo a WK3;!
Aapeo 9bjeto Lelacional, en caso de utili"arse un 9LA es necesario un
elemento que permita traducir el modelo relacional de una 3ase de Katos
a un modelo de objetos!
Kominio de 9bjetos Persistentes, este elemento sire para coadyuar al
mapeo 9bjeto Lelacional, y a la %mplementacin de .cceso a Katos!
(.< 1!se 1in!li-!cin
;uando todos los elementos del 3acDlog del Producto ya #an sido
desarrollados en un &print y no quedan ms elementos, #istorias de usuario o
requerimientos reali"ados por el propietario del producto, se procede con la fase
de finali"acin!
En esta fase se debe reali"ar una ealuacin general del sistema por parte del
propietario del producto, principalmente para erificar que el sistema cumple
con las funcionalidades generales ya que las funcionalidades especficas y ms
peque/as #an sido desarrolladas, ealuadas y corregidas durante la fase de
desarrollo!
El formulario de ealuacin general del sistema de informacin web
4ileSuccesS%ool se encuentra en el .nexo G, Gormulario de ealuacin global!
$na e" que se #a determinado que los requerimientos del sistema #an sido
desarrollados con (xito se reali"a la preparacin del entregable final del sistema
desarrollado, para luego reali"ar pruebas funcionales por parte del equipo de
desarrollo en todo el sistema erificando que las funcionalidades no #ayan
sufrido cambios!
+ambi(n, en esta fase se reali"a la documentacin pertinente del producto
desarrollado como ser el manual de usuario, manual de instalacin y
configuracin y un documento con la descripcin de las caractersticas y
funcionalidad del sistema!
86
CAPTULO I9
PRUEFAS
:. PRUEFAS
*a elaboracin del presente Proyecto de Grado, una e" reali"ado su
desarrollo, contina con un proceso de pruebas reali"adas tanto a niel de
desarrollo del mismo Proyecto de Grado como a niel del sistema de
informacin obtenido!
:.1. /!tri- del /!rco L,ico
El Aarco *gico es una #erramienta de trabajo con la cual un ealuador puede
examinar el desempe/o de un proyecto en todas sus etapas! Permite presentar
de forma sistemtica y lgica los objetios de un proyecto y sus relaciones de
causalidad!
.simismo, sire para ealuar si se #an alcan"ado los objetios y para definir los
factores externos al proyecto que pueden influir en su consecucin!
*a Aatri" de Aarco *gico que se elabora para efectos de la ealuacin debe
reflejar lo que el proyecto es en la actualidad!
. continuacin en la +abla B!-, se muestra la Aatri" de Aarco *gico reali"ada
para el presente Proyecto de Grado!
+abla B!-I Aatri" de Aarco *gico
Enunci!do del
o#2eti$o
Indic!dores /edios de
9eri%ic!cin
Su"uestos
1in3
Elaboracin de un
proyecto innoador
#aciendo uso de la
metodologa gil
&crum y tecnologa y
#erramientas de
ltima generacin
%nformacin clara y
precisa contenida en
el documento del
presente Proyecto de
Grado!
&istema de
%nformacin obtenido
en el proyecto con su
respectio instalador!
Kocumentacin que
aala y respalda el
cumplimiento y
conclusin
satisfactoria del
presente Proyecto de
Grado!
61
Pro"sito3
Kesarrollar un
&istema de
%nformacin para la
administraci[n y el
seguimiento de las
actiidades de
Gestin de
Proyectos de
&oftware que usen la
metodologa gil
&crum, posibilitando
la obtencin
oportuna de reportes
sobre el estado y
eolucin de los
proyectos
gestionados!
%nformacin y
proceso del
Kesarrollo mostrado
en el ;aptulo %%%,
%ngeniera del
Proyecto!
Lespuesta oportuna
del sistemaI
Eer mdulo de
reportes del sistemaH
&e aplique en mayor
medida las
recomendaciones
para el uso del
sistema de gestin
de proyectos de
software y (ste
presente un
adecuado
funcionamiento!
*a informacin
generada por los
usuarios del sistema
debe responder a
eracidad y
responsabilidad en
su ejecucin!
Co"onentes3
.utomati"acin de la
administracin de
ciclos iteratios!
.utomati"acin de la
administracin de
requerimientos!
.dministracin de
reuniones y puntos
acordados!
.utomati"acin de
registro, asignacin y
seguimiento de
tareas!
Proisin de
informacin acerca
del estado del
trabajo asignado,
reali"ado y pendiente
Ejecucin organi"ada
de la administracin
de iteraciones!
Legistro y
administracin
organi"ada de
requerimientos y
cambios reali"ados!
Legistro y
administracin
organi"ada de
reuniones y puntos
acordados!
9portuno
seguimiento y control
sobre el trabajo
reali"ado por el
equipo de desarrollo!
Aodulo de
administracin de
&prints Eer sistemaH!
&ub?Adulo
administracin de
requerimientos Eer
sistemaH!
Adulo
administracin de
reuniones Eer
sistemaH!
Procesos de registro,
asignacin y
seguimiento de
tareas Eer sistemaH!
%nformacin oportuna
sobre el estado del
trabajo de los
integrantes de un
equipo de desarrollo
Eer sistema, perfil
integranteH!
Kefinir - responsable
del proyecto =&crum
Aaster>, - propietario
del producto, equipo
&crum=integrantes
equipo de
desarrollo>!
*a administracin de
&prints es reali"ada
por el &crum Aaster!
Legistro adecuado
de los requerimientos
y actuali"acin
inmediata sobre los
cambios reali"ados!
Legistro adecuado
de reuniones y
puntos acordados!
.ctuali"acin diaria
sobre el trabajo
pendiente reali"ado
por cada uno de los
integrantes del
equipo!
Efica" aplicacin de
la metodologa gil
de gestin de
proyectos &crum!
GuenteI Elaboracin Propia
6-
:.2. Co"!r!cin de C!r,!s de Tr!#!2o
+omando el concepto inicial de 4comparacin de cargas de trabajo entre
sistemas existentes y sistemas propuestos5 descrito en ECE:K.**UCE:K.**H
se puede utili"ar esta #erramienta para mostrar los resultados de la
comparacin entre la utili"acin y la no utili"acin del sistema de gestin de
proyectos 4ileSuccesS%ool, exponiendo la eficiencia en ejecucin de tareas o
actiidades de gestin de proyectos de software que aplican la metodologa gil
&crum tras la utili"acin del sistema!
Para reali"ar la comparacin entre la utili"acin y la no utili"acin del sistema
desarrollado en el presente proyecto se tomaron en cuenta los siguientes
aspectosI
+areaI Kescribe las tareas o actiidades que se reali"an en una gestin
de proyectos de software con la metodologa &crum!
A(todoI Es la forma como es reali"ada o ejecutada la tarea!
;undo y ;moI El momento en el que es reali"ada la tarea y el proceso
de su ejecucin!
+iempo requeridoI El tiempo que es requerido para reali"ar la tarea!
:o obstante se puede mencionar que la ejecucin de actiidades o tareas de
forma mental no proee un grado deseable de confiabilidad sobre la informacin
que se obtiene a partir de ellos!
Para la elaboracin de este captulo, se #a reali"ado la prueba del sistema
sobre la gestin de dos proyectos de software diferentes, ambos reali"ados en
dos iteraciones cortas, cada iteracin con una duracin de dos semanas! Ke
manera que el primero no utili" el sistema 4ileSuccesS%ool para las
actiidades de gestin y el segundo si lo utili"!
*os resultados obtenidos de las pruebas reali"adas se muestran a continuacin
en la tablas B!< a la B!-8!
6<
+abla B!<I ;omparacin X Kefinicin responsables
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin de los responsables de un proyecto =Propietario Producto,
&crumAaster>
/@todo Aanual, mental .utomati"ado
CuAndo . Co .l inicio de un proyectoI
+omar nota ySo recordar informacin del
Propietario del Producto, datos
personales e informacin de contacto!
.l inicio de un proyectoI
Legistro del Propietario del
Producto, datos personales e
informacin de contacto!
Tie"o re+uerido - minuto o ninguno < minutos
GuenteI Elaboracin Propia
+abla B!@I ;omparacin X Kefinicin equipo desarrollo
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefincin del Equipo &crum =equipo de desarrollo>
/@todo Aanual, mental .utomati"ado
CuAndo . Co .l inicio de un proyectoI
+omar nota ySo recordar las personas que
integrarn el equipo de desarrollo y sus
roles dentro del equipo!
.l inicio de un proyectoI
Legistrar los integrantes del
equipo de desarrollo de un
proyecto con sus respectios
roles en el equipo!
Tie"o re+uerido :inguno - minuto
GuenteI Elaboracin Propia
+abla B!BI ;omparacin X Kefinicin 3acDlog Producto
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin del 3acDlog del Producto de un proyecto
/@todo Aanual .utomati"ado
CuAndo . Co .l inicio de un proyectoI
+omar nota, arc#iar el listado de
elementos del 3acDlog del Producto
=listado de requerimientos o #istorias de
usuario>!
.l inicio de un proyectoI
Legistrar los elementos del
3acDlog del Producto
=#istorias de usuario>!
Tie"o re+uerido &egn la cantidad de #istorias de usuario!
@ X B minutos por #istoria de usuario!
&egn la cantidad de #istorias
de usuario!
- minuto por #istoria de
usuario!
GuenteI Elaboracin Propia
6@
+abla B!0I ;omparacin X Kefinicin reunin
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin de una Leunin en un proyecto
/@todo Aanual, mental .utomati"ado
CuAndo . Co ;ada que se planifica una reuninI
+omar nota, recordarI fec#a, #ora,
objetio, lugar y asistentes de una
reunin!
;ada que se planifica una
reuninI
Legistrar fec#a, #ora, objetio,
lugar y asistentes de una
reunin!
Tie"o re+uerido < minutos o ninguno < minutos
GuenteI Elaboracin Propia
+abla B!7I ;omparacin X Kefinicin puntos acordados
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin de los Puntos .cordados en una reunin
/@todo Aanual, mental .utomati"ado
CuAndo . Co ;ada que se reali"a una reuninI
+omar nota, recordar los puntos
acordados en una reunin!
;ada que se reali"a una
reuninI
Tie"o re+uerido ? Aientras se reali"a la reunin ? Aientras se reali"a la reunin
? o al finali"ar la reunin,
segn la cantidad de puntos
acordados!
- minuto por punto acordado!
GuenteI Elaboracin Propia
+abla B!JI ;omparacin X Lesmen reunin
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Lesmen de reunin
/@todo Aanual .utomati"ado
CuAndo . Co *uego de la reali"acin de una reuninI
Preparar resmen, recabando o
recordando informacin acerca de la
reunin, objetio, asistentes y puntos
acordados en la misma!
*uego de la reali"acin de una
reuninI
Ejecutar consulta en el
sistema que obtenga el
resmen de una reunin
Tie"o re+uerido -0 minutos - minuto
GuenteI Elaboracin Propia
6B
+abla B!8I ;omparacin X Kefinicin 3acDlog Producto escogido para &print
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin de los elementos del 3acDlog del Producto escogidos para un
sprint
/@todo Aanual .utomati"ado
CuAndo . Co ;ada que se planifica un sprintI
+omar nota o anotar en pi"arra qu(
elementos del 3acDlog del Producto sern
desarrollados durante el &print!
;ada que se planifica un
sprintI
&eleccionar en el sistema qu(
elementos del 3acDlog del
Producto sern desarrollados
en el &print!
Tie"o re+uerido &egn la cantidad de elementos!
@ minutos
- minuto
GuenteI Elaboracin Propia
+abla B!6I ;omparacin X Kefinicin 3aDlog del &print
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin del 3acDlog del &print, las tareas que sern desarroladas
durante el &print
/@todo Aanual .utomati"ado
CuAndo . Co .ntes de que inicie un sprintI
+omar nota o anotar en pi"arra los
elementos del 3acDlog del &print, listado
de las tareas que sern reali"adas y su
estimacin de tiempo de resolucin!
.ntes de que inicie un sprintI
Legistrar mediante el sistema
los elementos del 3acDlog del
&print, tareas que sern
reali"adas y su tiempo de
resolucin!
Tie"o re+uerido &egn la cantidad de tareas definidas!
@ minutos por tarea
&egn la cantidad de tareas!
- minuto por tarea
GuenteI Elaboracin Propia
+abla B!-1I ;omparacin X .signacin de tareas
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! .signacin de tareas a los integrantes del equipo de desarrollo
/@todo Aanual, mental .utomati"ado
CuAndo . Co ;ada que se define una tareaI
+omar nota, recordarI qu( tarea se asigna
a qui(n!
;ada que se define una tareaI
.signacin, en el sistema, de
una tarea a un responsable
=integrante del equipo>!
Tie"o re+uerido - minuto o ninguno Aientras se reali"a el registro
de una tarea!
\ X - minuto por tarea
GuenteI Elaboracin Propia
60
+abla B!--I ;omparacin X .ctuali"acin tiempo restante
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! .ctuali"acin del tiempo estimado restante para la finali"acin de una
tarea
/@todo Aanual .utomati"ado
CuAndo . Co Kiario durante un &printI
+omar nota o anotar en pi"arra la
estimacin, segn el responsable, del
tiempo que an falta para la conclusin de
una tarea!
Kiario durante un &printI
Legistrar en el sistema la
estimacin de tiempo que an
falta para la conclusin de una
tarea, reali"ado por el
responsable de la tarea!
Tie"o re+uerido \ minuto \ minuto
GuenteI Elaboracin Propia
+abla B!-<I ;omparacin X %ncremento &print
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! Kefinicin del incremento del &print
/@todo Aanual .utomati"ado
CuAndo . Co . la finali"acin de un &print, luego de la
demostracin del sistemaI
+omar nota y reali"ar la ealuacin del
incremento reali"ado en un &print de la
funcionalidad sobre el producto final!
. la finali"acin de un &print,
luego de la demostracin del
sistemaI
Legistro en el sistema del
incremento reali"ado en un
&print y su correspondiente
ealuacin!
Tie"o re+uerido -1 minutos -1 minutos
GuenteI Elaboracin Propia
+abla B!-@I ;omparacin X Leporte estado de tareas
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btencin del reporte sobre el estado de +areas asignadas a los
integranates del equipo de desarrollo
/@todo Aanual, mental .utomati"ado
CuAndo . Co ;ada que sea requeridoI
Lecabar o recordar informacin acerca
del estado de las tareas asignadas y
preparar reporte!
;ada que sea requeridoI
Ejecutar consulta en el
sistema que obtenga el
reporte del estado de las
tareas en el proyecto!
Tie"o re+uerido ? -0 minutos si el m(todo es manual!
? ninguno si el m(todo es mental!
\ minuto
GuenteI Elaboracin Propia
67
+abla B!-BI ;omparacin X Leporte reuniones en un proyecto
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btencin del reporte de las reuniones reali"adas y planificadas en un
proyecto!
/@todo X .utomati"ado
CuAndo . Co :o se reali"a ;ada que sea requeridoI
Ejecutar consulta en el sistema
que obtenga el reporte de las
reuniones planificadas y
reali"adas en un proyecto!
Tie"o re+uerido X \ minuto
GuenteI Elaboracin Propia
+abla B!-0I ;omparacin X Leporte reuniones por persona
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btencin del reporte de las reuniones reali"adas y planificadas por
persona =integrante de un proyecto gestionado>
/@todo X .utomati"ado
CuAndo . Co :o se reali"a ;ada que sea requeridoI
Ejecutar consulta en el
sistema que obtenga el
reporte de las reuniones
planificada y reali"adas por
integrante de un proyecto!
Tie"o re+uerido X \ minuto
GuenteI Elaboracin Propia
+abla B!-7I ;omparacin X Leporte aance de proyecto
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btencin del reporte del aance de un proyecto
/@todo Aanual .utomati"ado
CuAndo . Co . la finali"acin de un sprint y cada que
sea requeridoI
Lecabar datos, consultar apuntes y
resumir la informacin sobre el
incremento y su ealuacin de cada &print
y preparar reporte y grfico de aance!
. la finali"acin de un sprint y
cada que sea requeridoI
Ejecutar consulta en el
sistema que obtenga el
reporte sobre el aance de un
proyecto =incluye grfico de
aance>
Tie"o re+uerido <1 minutos \ minuto
GuenteI Elaboracin Propia
6J
+abla B!-JI ;omparacin X Leporte esfuer"o pendiente
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btencin del reporte sobre la estimacin del esfuer"o pendiente =tiempo
restante> para la conclusin de un &print!
/@todo Aanual .utomati"ado
CuAndo . Co Kiario durante un &print y cada que sea
requeridoI
Lecabar datos, consultar apuntes y
preparar reporte de esfuer"o pendiente y
grfico 3urnKown =estimacin de tiempo
restante>!
Kiario durante un &print y
cada que sea requeridoI
Ejecutar consulta en el
sistema que obtenga el
reporte de esfuer"o pendiente
=icluye grfico 3urnKown>
Tie"o re+uerido 0 minutos \ minuto
GuenteI Elaboracin Propia
+abla B!-8I ;omparacin X Lesmen de los &prints de un proyecto
SIN A,ileSuccesSTool CON A,ileSuccesSTool
T!re! 9btener resmen de los &prints reali"ados en un proyecto
/@todo Aanual .utomati"ado
CuAndo . Co ;ada que sea requeridoI
Lecabar datos, consultar apuntes y
preparar resmen de los &prints
reali"ados en un proyecto!
;ada que sea requeridoI
Ejecutar consulta en el
sistema que obtenga el
resmen de los &prints
reali"ados en un proyecto!
Tie"o re+uerido <1 minutos \ minuto
GuenteI Elaboracin Propia
&e puede obserar en base a los resultados mostrados en las anteriores tablas,
principalmente, la oportunidad de obtencin de reportes para una gestin de
proyectos de software cuando se #ace uso del sistema .gile&ucces&+ool!
*a pruebas para el primer y segundo caso, sin .gile&ucces&+ool y con
.gile&ucces&+ool, se reali"aron sobre dos proyectos similares, ambos para el
desarrollo de dos portales web diferentes! Esto para poder tener un ambiente
de pruebas similar en ambos casos!
68
Gigura B!-I ;omparacin de resultados X pruebas reali"adas
Kescripcin +areasI
. Kefinicin de los responsables de un proyecto =Propietario Producto, &crumAaster>
3 Kefincin del Equipo &crum =equipo de desarrollo>
; Kefinicin del 3acDlog del Producto de un proyecto
K Kefinicin de una Leunin en un proyecto
E Kefinicin de los Puntos .cordados en una reunin
G Lesmen de una reunin
G Kefinicin de los elementos del 3acDlog del Producto escogidos para un sprint
) Kefinicin del 3acDlog del &print, las tareas que sern desarroladas durante el &print
% .signacin de tareas a los integrantes del equipo de desarrollo
W .ctuali"acin del tiempo estimado restante para la finali"acin de una tarea
C Kefinicin del incremento del &print
* 9btencin del reporte sobre el estado de +areas asignadas a los integranates del equipo de
desarrollo
A 9btencin del reporte de las reuniones reali"adas y planificadas en un proyecto
: 9btencin del reporte de las reuniones reali"adas y planificadas por persona =integrante de un
proyecto gestionado>
9 9btencin del reporte del aance de un proyecto
P 9btencin del reporte sobre la estimacin del esfuer"o pendiente =tiempo restante> para la
conclusin de un &print
T 9btener resmen de los &prints reali"ados en un proyecto
GuenteI Elaboracin Propia
&e puede obserar en la Gigura anterior que las tareas 3, E, %, A y :, no
requieren un tiempo para su ejecucin para el caso de no utili"ar el sistema
.gile&ucces&+ool, debido a que en esta situacin esas tareas son reali"adas
de forma mental o inclusie no son reali"adas!
66
. 3 ; K E G G ) % W C * A : 9 P T
1
0
-1
-0
<1
<0
;uadro estadstico
;omparacin Lesultados
;9: .gile&ucces&+ool
&%: .gile&ucces&+ool
+areas
+
i
e
m
p
o

=
A
i
n
u
t
o
s
>
:.(. C!lid!d del So%t&!re
*a calidad del software se define comoI 4;oncordancia de los requisitos
funcionales y de rendimiento explcitamente establecidos, con los estndares de
desarrollo explcitamente documentados y con las caractersticas implcitas que
se espera de todo software desarrollado profesionalmente5 EPLE&&A.:10H!
*a ealuacin de calidad para el sistema de informacin web 4ileSuccesS%ool
se reali" tomando en cuenta los siguientes aspectosI
a> GuncionalidadI capacidad del producto software para proporcionar
funciones que satisfagan las necesidades especficas e implcitas!
b> GiabilidadI capacidad del producto software para mantener un niel
especificado de rendimiento!
c> AantenibilidadI capacidad del producto software para ser modificado! *as
modificaciones incluyen correcciones, mejoras o adaptacin del software
a cambios en el entorno, en los requisitos o en las especificaciones
funcionales!
d> PortabilidadI capacidad del producto software de ser transferido de un
entorno a otro!
. continuacin se describe los resultados obtenidos de la ealuacin de calidad
reali"ada al sistema desarrollado en el presente proyecto!
:.(.1. 1uncion!lid!d
Kebido a que la funcionalidad de un sistema no se mide directamente,
corresponde deriar a otras medidas directas como Puntos de Guncin =PG>!
En la ingeniera del proyecto, la primera fase de &crum, Gase Preliminar, en el
inciso @!<!-!- f> estimacin de costos, se reali" el preiamente el clculo de
Puntos de Guncin para aplicar el m(todo ;ocomo 3sico! Para medir la
funcionalidad del sistema se utili"arn estos resultados obtenidos del cculo de
PG, que se detallan en el .nexo E, Estimacin de ;ostos!
El alor obtenido de PG es de <8-, este alor representa una funcionalidad con
-11
un grado de confian"a del 70N!
PG real ] <8B ^ E 1,70 _ 1,1- ^ @B

H
PG real ] <8-
la funcionalidad esperada con un grado de confian"a del -11N esI
PG esperado ] <8B ^ E - _ 1,1- ^ @B

H
PG esperado ] @81
;alculando el porcentaje de funcionalidad al que se lleg, se tieneI
N PG ] = PG realSPG esperado > ] = <8-S@81 > ] 1,J@
*o cual significa que el &istema de %nformacin para Gestin de proyectos de
software con enfoque gil tiene una funcionalidad del J@N!
:.(.2. 1i!#ilid!d
Para calcular la fiabilidad, se emplea la m(trica de eficacia de eliminacin de
defectos =EEK>, dada por la siguiente frmulaI
EEK ] E S = E _ K > =->
Kado que el desarrollo del sistema de informacin fue reali"ado de forma
iteratia a lo largo de 0 &prints, se calcular la eficacia de eliminacin de errores
de manera detallada y obteniendo resultados fiables y obserables como sigue
a continuacin!
*a frmula EEK =-> para ser aplicada ser modificada de la siguiente formaI
EKK
i
] E
i
S = E
i
_ K
2
> =<>
EKK
tot!l
] = EKK
i
> S : =@>
KondeI
N es el nmero de total de iteraciones, &prints, disminudo en uno ya que en el
primer &print del presente proyecto no se reali"a funcionalidades del sistema!
i toma los alores de - X :!
EDD
i
es la eficacia de eliminacin de errores en el el ciclo i!
-1-
E
i
es nmero de test para caso de error reali"ados a la conclusin del ciclo i!
D
2
es el nmero de test para casos de error fallidos preparados en el ciclo i _ -!
EDD
tot!l
es el porcentaje total de eficacia de eliminacin de errores!
. continuacin en la +abla B!-6 se muestra los resultados de cada iteracin
para la eficacia de eliminacin de errores!
+abla B!-6I Eficacia de eliminacin de errores por iteraciones
NQero de
S"rint
C!ntid!d
Histori!s
de Usu!rio
C!ntid!d
de T!re!s
C!ntid!d
de TestIE iJ
Tests
A"ro#!dos
Tests
1!llidosID 2J
EDD i
< J -8 6 7 @ 1,J0
@ 6 <1 -@ 6 B 1,J7
B -- -J -< -1 < 1,87
0 8 -J 8 8 1 -
= EKK i > R
@,@J
GuenteI Elaboracin Propia
.plicando la frmula =@> EKK
tot!l
se tieneI
EKK
tot!l
] @,@J S B
EKK
tot!l
] 1,8B
*o que quiere decir que la eficacia de eliminacin de errores asciende a 8BN!
:.(.(. /!nteni#ilid!d
Kebido a que el sistema de informacin web .gile&ucces&+ool fue desarrollado
en base a una #ibridacin de metodologas &crum?Programacin Extrema =MP>,
aplicando prcticas de MP dentro la fase de desarrollo de &crum' se obtuo un
software con un dise/o sencillo y de fcil comprensin, teniendo como resultado
una aplicacin en la cual la forma de reali"ar mantenimiento a la misma no
presenta gran dificultad!
:.(.:. Port!#ilid!d
Kado que el sistema fue desarrollado con tecnologa Waa y Postgre&T*,
utili"ando cdigo estndar G:$, los cuales funcionan bajo todo tipo de
plataforma, la portabilidad del sistema #acia cualquier sistema operatio
-1<
conocido es total! Por lo que se tiene una portabilidad del -11N!
:.:. Se,urid!d
*a importancia de la seguridad de la informacin radica en la fiabilidad de los
datos, impidiendo que sean ulnerables por personas no autori"adas, con el
objetio de obtener resultados fiables de la aplicacin! Es en este sentido se
tiene identificada la seguridad de dos manerasI
a> Polticas de seguridad aplicadas al sistemaI son los lineamientos que son
tomados en cuenta como requisitos para el correcto funcionamiento del sistema
que se definieron como los siguientes puntos respecto a este temaI
*a seguridad utili"ada en el funcionamiento del mismo tomando en
cuenta la configuracin correcta del seridor de aplicaciones!
;onfiguracin correcta del seridor de base de datos!
)abilitacion de puertos necesarios!
.cceso restringido de usuarios a los seridores!
b> &eguridad utili"ada en el funcionamiento del sistemaI en este punto se
detalla las medidas de seguridad aplicadas en el desarrollo del sistema que son
las siguientesI
$so de buenas prcticas en la transferencia de datos clienteSseridor a
web!
*a aplicacin cuenta con *9G de posibles errores!
El dise/o de la base de datos cuenta con campos de auditoria en caso
de ser necesarias reisiones!
&e trabaja con un esquema de seguridad en el sistema orientada a roles?
usuarios que est embebida por la capa del seridor de aplicaciones la
cual est basada en estndares definidos por &un!
-1@
CAPTULO 9
CONCLUSIONES N RECO/ENACIONES
<. CONCLUSIONES N RECO/ENACIONES
.l t(rmino del presente Proyecto de Grado es necesario determinar las
conclusiones a las que se lleg con su elaboracin y plantear recomendaciones
que complementen al trabajo y estudio reali"ados!
<.1. Conclusiones
El objetio principal de este trabajo fue el desarrollo de un sistema de
informacin para la gestin de proyectos de software que apliquen la
metodologa &crum, posibilitando el acceso de los usuarios desde una red
pblica! Para ello se reali"aron los pasos y actiidades propuestos en las
captulos % y %%, mostradas de forma aplicatia en el captulo %%% y ealuadas en el
captulo %P!
En la +abla 0!-, se muestra una comparacin reali"ada entre las #erramientas,
que apoyan la gestin de proyectos de software con enfoque gil, inestigadas
en el captulo %, seccin -!<!<! .ntecedentes de trabajos afines y el sistema
resultante del presente trabajo!
+abla 0!-I ;omparacin entre las #erramientas inestigadas y .gile&ucce&+ool
C!r!cter5stic!s A F C D E &
Gestin de ms de un proyecto a la e"
.plicacin de escritorio
.plicacin clienteSseridor
.plicacin web
Legistro de funcionalidades =)istorias de $suario>
&eguimiento de funcionalidades
Legistro de tareas
Estimacin de tareas
.signacin de tareas
&eguimiento diario de tareas
Legistro integrantes del proyecto
-1B
Legistro responsables del proyecto
Leportes de estado del proyecto
Exportar datos a formato Excel
Exportar datos a formato MA*
Exportar proyecto a formato A& Project
Exportar datos a formato Pdf
Planificacin sprint
&eguimiento sprint
Leisin sprint
Legistro de reuniones
Planificacin de reuniones
&eguimiento de reuniones
Legistro de puntos acordados en una reunin
Legistro de asistentes a una reunin
Legistro de las #abilidades de los integrantes de un equipo
%nformacin sobre el estado de ltareas asignadas a una persona
:otificacin por email
KescripcinI .! &printometer
3! Mplanner
;! Persion9ne
K! &crumR
E! &crumKesD
1. 'gileSuccesS(ool =desarrollado en el presente proyecto>
GuenteI Elaboracin propia
En la tabla mostrada se obsera que las #erramientas disponibles en el
mercado no cubren de forma integral todos los aspectos que interienen en una
gestin de proyectos de software con enfoque gil! Q segn la encuesta
reali"ada, er .nexo ;, se puede resaltar la necesidad de inclusin de ciertas
funcionalidades, que no se #an encontrado entre las #erramientas conocidas,
en un sistema de informacin para gestionar proyectos de software por parte de
las personas encuestadas!
. partir de lo expuesto anteriormente se formulan las siguientes conclusionesI
&e comprob mediante el desarrollo del proyecto que la utili"acin de
&crum con una adaptacin de Programacin Extrema plantea enfoques
faorables y buenas prcticas para el desarrollo de un proyecto de
software!
-10
El uso de tecnologas de ltima generacin implica en primera medida
amplios esfuer"os en estudio e inestigacin para llegar a un
conocimiento de las mismas, pero una e" logrado el aprendi"aje reporta
rapide" y robuste" en la construccin de sistemas de informacin
facilitando la labor de los desarrolladores que las utili"an!
*a utili"acin de la #erramienta colaboratia para reali"ar la
administracin y seguimiento de actiidades de gestin de proyectos de
software permite obtener informacin acerca de un proyecto sobre el
estado en el que se encuentra para llear a cabo decisiones sobre la
administracin del proyecto de forma gerencial!
<.2. Recoend!ciones
*as recomendaciones #ec#as a continuacin son de manera personal acorde a
la experiencia obtenida en el desarrollo del proyecto!
&egn lo isto en el desarrollo del proyecto se recomienda la aplicacin
de la metologa &crum para equipos de desarrollo que reali"an ms de
un proyecto a la e" donde el cliente necesite er los aances de su
proyecto antes de la fec#a de entrega!
&e recomienda la aplicacin de la metodologa &crum cuando se cuenta
con la isin definida del proyecto y una persona responsable en la
decisin de los requerimientos que est( comprometida con el equipo y
que cono"ca los principios del desarrollo gil!
&e e por coneniente que el equipo de desarrollo cono"ca el modelo y
la doctrina de &crum, tenga experiencia en la estimacin de tareas y
cualidades para ser un equipo cooperatio y co#esionado!
-17