UniversidadORTUruguayFacultaddeIngeniería

Amadeus:plataformaparamúsicosemergentes

EntregadocomorequisitoparalaobtencióndeltítulodeIngenieroenSistemas

AlexisZucco-163608JuanMéndez-155076NicolásMañay-163779

Tutor:HelenaGarbarino

2016

2

DeclaracióndeautoríaNosotros,AlexisZucco,JuanDiegoMéndezyNicolásMañay,declaramosqueeltrabajoquesepresentaenestaobraesdenuestrapropiamano.Podemosasegurarque:

• LaobrafueproducidaensutotalidadmientrasrealizábamoselproyectodegradoparalaobtencióndeltítulodeIngenieroenSistemas;

• Cuandohemos consultadoel trabajopublicadoporotros, lo hemos atribuido conclaridad;

• Cuandohemoscitadoobrasdeotros,hemosindicadolasfuentes.Conexcepcióndeestascitas,laobraesenteramentenuestra;

• Enlaobra,hemosacusadorecibodelasayudasrecibidas;• Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos

explicado claramente qué fue contribuido por otros, y qué fue contribuido pornosotros;

• Ningunapartedeestetrabajohasidopublicadapreviamenteasuentrega,exceptodondesehanrealizadolasaclaracionescorrespondientes.

3

AgradecimientosEn primer lugar, queremos agradecer a nuestras familias y novias, quienes no solo nosapoyaronduranteel transcursodeesteproyecto sino tambiéna lo largode todanuestracarrera.Agradecemosespecialmenteanuestra tutoraDra.HelenaGarbarinoporguiarnosdurantetodo este proceso, demostrando siempre la mejor voluntad y disposición ante cualquierinconvenientequesurgiese,apostandosiemprepornuestramejoracontinua.Extendemosnuestrosagradecimientosatodosaquellosqueestuvieroninvolucradosconelproyectoayudándonosdealgunamanerauotra,especialmentea:

• Lic.RossanaFernández,CoordinadoradelCIE,porayudarnosalograrencaminarestapropuestadeproyectopormediodeltalleremprendedor.

• Dr. Pedro Salvetto, Coordinador del LISI, por solucionar demanera rápida y eficaznuestros problemas de asignación de tutores y facilitarnos toda la informaciónnecesariaalcomienzodeesteproyecto.

• AlejandroZorrilladeSanMartín,nuestrousuarioexpertoyproductownerqueconsugranconocimientodeláreadelamúsicaylamejordelasganasynosayudódesdeelprimermomento,aportandonuevasideasyayudandoenlaconstrucciónyevolucióndeAmadeusentodomomento.

• También a todos los músicos que aportaron su granito de arena al ayudarnoscontestando todas las inquietudes que fueron surgiendo en las distintas etapas ygraciasalocualdimosformaaunaidea.

Por últimoqueremos agradecer al personal de laboratorio de laUniversidadORTquienessiempretuvieronlabuenadisposicióndefacilitarnos las instalacionesnecesariasyatendercualquierinquietudparamejornuestroambientedetrabajo.Muchasgracias.

4

AbstractLatecnologíaestácambiandoelmundodeformavertiginosa,transformandolosmodelosdenegociotradicionalesycreandovalorennuevasáreasdeconsumo.Elrubrodelamúsicanohasidolaexcepciónaestefenómeno.ElusodeInternetylacompresióndigitalhanpermitidoteneruncatálogodetemasaunparde clics de distancia, permitiendo a los consumidores escuchar lo que quieran escuchar ycomprarsoloaquelloporloqueestándispuestosapagar.Estohaproducidounaavalanchadecontenidomultimediaquetransformalosmilesderesultadosdebúsquedasdecontenidoenunproblemaparaaquellosmúsicosemergentesquepretendendestacarsumaterial.Amadeus plantea el desarrollo de una plataformaweb que incentive la comunicación yrelacionamiento entre músicos emergentes y su público potencial, logrando impulsar sudesarrolloartísticoygenerandounespaciodereferenciaparalamúsica.Suprincipalobjetivocomoproyectoesobtenerconocimientosyhabilidadesdetecnologíasnovistasenlacarreraasícomotambiénponerenprácticalosconocimientosadquiridossobregestiónalolargodelamisma.El proceso se dividió en cuatro fase, utilizando en la etapa de implementación unametodologíaágilyunmarcodetrabajoScrum.SebuscóutilizarScrum lomáspuroposibleperodebidoa lascaracterísticasdelproyectoseaplicóunaadaptaciónqueseadecuaraalmismo.Alfinalizarelproyectoselogrócumplirconlosobjetivosdescritosyademásseobtuvocomoresultadounprototipofuncionaldelasolución.

5

PalabrasclaveAmadeus,UniversidadORTUruguay,Android,RubyonRails,Scrum,proyecto,tesis,redsocial,streaming, músico emergente, música, AngularJS, API, Amazon, Cloud computing, Git,MaterialDesign,Heroku,clienteservidor,Sentimentanalysis,JSON,REST.

6

Índice1. Introducción.............................................................................................................10

1.1. Seleccióndelproyecto..................................................................................................101.2. Objetivosdelproyecto..................................................................................................131.3. Elequipoyroles............................................................................................................14

2. Producto...................................................................................................................162.1. Descripcióndelproblema..............................................................................................162.2. Oportunidad.................................................................................................................162.3. Soluciónpropuesta.......................................................................................................172.4. Actoresprincipales........................................................................................................17

3. Ingenieríaderequerimientos....................................................................................193.1. Introducción.................................................................................................................193.2. Técnicas........................................................................................................................20

3.2.1. Tormentadeideas......................................................................................................203.2.2. Benchmarking.............................................................................................................203.2.3. Prototipación...............................................................................................................223.2.4. Reuniones....................................................................................................................233.2.5. Encuesta......................................................................................................................23

3.3. Justificacióndelastécnicasderelevamiento................................................................243.4. Especificacióndelosrequerimientos.............................................................................24

3.4.1. Introducción................................................................................................................243.4.2. Técnica........................................................................................................................253.4.3. Requerimientos...........................................................................................................253.4.4. Requerimientosfuncionales........................................................................................263.4.5. Requerimientosnofuncionales...................................................................................31

4. Arquitectura.............................................................................................................334.1. Introducción.................................................................................................................334.2. Arquitecturapropuesta.................................................................................................334.3. Análisisdeatributosdecalidad.....................................................................................344.4. Descripcióndelaarquitectura.......................................................................................41

4.4.1. VistadeDespliegue.....................................................................................................414.4.2. Vistademódulos.........................................................................................................454.4.3. Vistalógica..................................................................................................................47

4.5. Criteriodeseleccióndelastecnologías.........................................................................484.5.1. Herramientasdedesarrollo........................................................................................49

5. Gestióndelproyecto.................................................................................................505.1. Ciclodevidaymodelodeciclodevida..........................................................................505.2. Metodologíadetrabajo................................................................................................515.3. AdaptacióndeScrumalproyecto..................................................................................515.4. EtapasdelprocesoScrum..............................................................................................545.5. Conclusionesdelagestióndeproyecto.........................................................................55

6. Gestióndelalcance...................................................................................................576.1. Introducción.................................................................................................................576.2. Gestión.........................................................................................................................57

6.3. Recopilaciónderequisitos...............................................................................................576.4. Definicióndelalcance......................................................................................................586.5. CreacióndelEDT..............................................................................................................58

7

6.6. Validacióndelalcance.....................................................................................................606.7. Controldelalcance..........................................................................................................606.8. Conclusionesyleccionesaprendidas...............................................................................60

7. Gestióndeltiempo...................................................................................................617.1. Introducción.................................................................................................................617.2. Cronograma..................................................................................................................61

7.2.1. FaseI,planificación.....................................................................................................617.2.2. FaseII,diseño..............................................................................................................627.2.3. FaseIII,ejecución........................................................................................................637.2.4. FaseIV,cierre..............................................................................................................637.2.5. Actividadesdecontrol.................................................................................................64

7.3. Aplicaciónyherramientas.............................................................................................647.4. Conclusionesyleccionesaprendidas.............................................................................64

8. Gestióndelacomunicación......................................................................................668.1. Comunicacióninternadelequipo..................................................................................668.2. Comunicaciónconexternosalequipo...........................................................................668.3. Conclusionesyleccionesaprendidas.............................................................................67

9. Gestiónderiesgos.....................................................................................................689.1. Introducción.................................................................................................................689.2. Planificación.................................................................................................................689.3. Identificaciónderiesgos................................................................................................699.4. Conclusionesyleccionesaprendidas.............................................................................71

10. Gestióndelaconfiguración...................................................................................7210.1. Herramientasparalagestióndelcódigo.......................................................................72

10.1.1. Ramasprincipales........................................................................................................7310.1.2. Ramasdeapoyo..........................................................................................................74

10.2. Herramientasparalagestióndeproductosdedocumentación.....................................75

11. Gestióndelacalidad.............................................................................................7711.1. Gestión.........................................................................................................................7711.2. Burndownchartsyproyecciones...................................................................................8211.3. Horasplanificadasvshorasreales.................................................................................8311.4. Testing..........................................................................................................................8511.5. Conclusionesyleccionesaprendidas.............................................................................86

12. Conclusionesdelproyectoyleccionesaprendidas.................................................87

13. Proyecciónafuturo...............................................................................................88

14. Bibliografía...........................................................................................................89

15. Anexos..................................................................................................................9315.1. Anexo1:Cuestionarioparaartistasybandas................................................................9315.2. Anexo2:Resultadosdeencuesta..................................................................................9715.3. Anexo3:Benchmarking................................................................................................9815.4. Anexo4:Sprintplannigmeeting.................................................................................103

8

Glosario• Amazon EC2: Amazon Elastic Compute Cloud es un servicio web que proporciona

capacidadinformáticacontamañomodificableenlanube[1].• AmazonS3:AmazonSimpleStorageServiceofreceunalmacenamientodeobjetosseguro,

duraderoyaltamenteescalable[2].• AmazonES:AmazonElasticSearchesunserviciowebquepermitemanejarinstanciasde

ElasticSearch(motorpopulardebúsquedayanálisisdecódigoabierto)enlanubedeAWS[3].

• Android: Esun sistemaoperativobasadoenelnúcleoLinux ypresenteendispositivosmóvilesqueabarcandesdecelularesaautomóviles.

• API:ApplicationProgrammingInterfaceeselconjuntodefuncionesymétodos,queofrececierta biblioteca o servicio para ser utilizado por otro software como una capa deabstracción[4].

• Backend:Módulo del sistema encargado de procesar lo relacionado a las entradas deusuario.

• BurdownChart:Representacióngráficadeltrabajoporhacerenunproyectoeneltiempoquelleveelmismo.

• Cloudcomputing:ParadigmaqueofreceserviciosdecomputoatravésdeInternet,talescómodeservicioodeinfraestructura.

• Framework:Marcodetrabajoquedefineunconjuntodeconceptosestandarizadospararesolver un tipo de problema en particular. Generalmente sirve como referencia pararesolver problemas similares ofreciendo un conjunto de herramientas para facilitar suimplementación.

• Frontend:Eslapartedelsoftwarequeinteractúaconelolosusuarios.• Git:Softwaredecontroldeversionesdecódigofuente.• JQuery:BibliotecadeJavaScriptquepermitesimplificarlamaneradeinteractuarconlos

documentosHTML.• MVC:PatróndearquitecturadesoftwareModelViewController.Separalosdatosdela

lógicaylainterfazdeusuario.• ProductBacklog:Documentodealtonivelparatodoelproyecto.Contienedescripciones

genéricasdetodoslosrequisitosyfuncionalidadesdeseables[5].• ProductOwner:Representalavozdelcliente.SeaseguradequeelequipoScrumtrabaje

deformaadecuadadesdelaperspectivadelnegocio[5].• SCM:SiglaparaSoftwareConfigurationManagementoGestiónde laconfiguracióndel

software.• Scrum:Marcodetrabajoparalagestiónydesarrollodesoftwarebasadaenunproceso

iterativoeincrementalutilizadocomúnmenteenentornosbasadoseneldesarrolloágildesoftware[5].

9

• ScrumMaster: Facilitador del Scrum, se asegura de que el proceso se utiliza como esdebido,hacequelasreglassecumplan[5].

• SQA:SiglaparaSoftwareQualityAssuranceoAseguramientodelacalidaddelsoftware.• Streaming:Distribucióndigitaldemultimediaatravésdeunaredentiemporeal[6].• UI:UserInterfaceeslapartedelsoftwarevisibleparaelusuario.• UX:UserExperiencehacereferenciaalainteracciónentreelusuarioyunsistema

informático.

10

1. IntroducciónEl presentedocumento tiene comoobjetivodescribir eldesarrollodelproyectoAmadeus,comprendidoentreabrilde2015ymarzode2016,paralaobtencióndetítulodeIngenieroen Sistemas de la UniversidadORT Uruguay. El contenido delmismo abarca los aspectosprincipales del problema, concepción e implementación de la solución planteada, fasesprincipales del proyecto y su gestión. El objetivo será presentarle al lector un informedetalladodel trabajorealizado,procurandorespetarelordencronológicode loseventosydescribiendolosaspectosmásrelevantesdecadauno.Para el desarrollo de este trabajo se siguieron las reglamentaciones estipuladas por losdocumentos302,303,304,306y307paralapresentacióndetrabajosfinalesdelascarrerasdelaFacultaddeIngeniería,ypublicadosenjuliode2013yaccesiblesatravésdelapáginadeAulasdelaUniversidad[7].

1.1. SeleccióndelproyectoLa intención del equipo fue desarrollar un proyecto de carácter emprendedor, definiendoobjetivos propios para el mismo y buscando aportar una solución innovadora. Como prerequisito para presentar un proyecto a la facultad fue necesaria la realización del talleremprendedor,comprendidoentremarzoyabrilde2015.Duranteeltranscursodedichotallerse puso en práctica la metodología Design Thinking [8] cuyo objetivo es “generar ideasinnovadorasquecentrasueficaciaenentenderydarsoluciónalasnecesidadesrealesdelosusuarios”.Duranteelmesdemarzoelequipomantuvoreunionesperiódicasconelobjetivodedescubrirunanecesidaddelmercadoquecombinaraundominiointeresanteparatodoslosintegrantes,un potencial desafío tecnológico y por último que fuera viable para un posibleemprendimientoafuturo.Deestasreunionessurgieronvariasideasinteresantes,entreellasAmadeus, unaplataforma social deartistas y fansque impulseel desarrollo cultural de lamúsica emergente y brinde nuevas oportunidades de crecimiento profesional. Comoresultadodeanalizaresta ideadentrodel tallersurgen loscanvas,diagramasvisualesquepermiten comunicar de forma rápida y efectiva un modelo de negocios a todos losstakeholdersdeunproyectodiagramandolascaracterísticasprincipalesdesuscomponentes.

11

Ilustración1-TheLeanCanvasparaproyectoAmadeus.

InicialmentecomosepuedeobservarenlaIlustración1laideadelproyectoAmadeusgiraentornoalconceptoartista-local,dondesehaceespecialénfasisenlacontratacióndeartistasqueiniciansucarreraenelámbitodelamúsica.Lahipótesisgeneradaporelequiposostienequeunodelosprincipalesproblemasqueenfrentanlosmúsicosensucarreraeslanecesidaddeexhibirsumaterialparalograrllegarasupúblico.Estosedebeprincipalmenteaquelocalesdemúsicaenvivonoestándispuestosapresentarartistasobandasquenoconocen,yaquenopuedengarantizarunmínimodeconcurrencianiunespectáculodecalidad.EsasíqueAmadeusplanteaunasoluciónsimpleaestaproblemática,generarunespaciovirtualdondemúsicospuedanexhibirsumaterialygenerarmayorexposición, localesdemúsicaenvivorecurranparacontratacióndeartistasyporúltimounespaciodereferenciadondecualquieramantedelamúsicapuedainteractuarcongentedelmedio.

12

Ilustración2-BusinessModelCanvasparaproyectoAmadeus.

Como se puede apreciar de la Ilustración 2 el modelo de negocios se basa en ofrecer 2versionesdelservicio,unadeusobásicoconlimitacionesdeespacioofuncionalidadesyotraversióndeusopremiumsinrestricciones.Laestructurade ingresos(revenuestreamsen laIlustración 2) detalla algunas de las estrategias básicas que se plantean para obtenergananciasacortoplazo:

• Interconexión con otras plataformas: Ofrecer la posibilidad de publicar eventos onuevas presentaciones en múltiples plataformas simultáneamente, cobrando pordichainfraestructuraalosmúsicosquelautilicen(pagoporuso).

• Suscripciones:Paraaquellosartistasquequieranobtenermayoraprovechamientodelainfraestructuraofrecidasediseñaunplandebeneficiosporsuscripción,talescomobroadcastdenoticasaseguidores,quelesseránútilesparalogrardiferenciaciónconotrosmúsicosdelaplataforma.

• Serviciospremium:Juntoconlassuscripcionessonlos“extras”queseofrecenparalosusuarios abonados, estas pueden incluir conjuntos de funcionalidades tales comoaumentodetamañodealojamientodearchivoseinterconexiónconredessociales.

• Publicidad:Venderpublicidadesunadelasformasmásrápidaysencilladeingresos.Altenerunpúblicocongustosdefinidosyconocersuperfilenlaplataformasepuedeofrecerpropagandaobjetiva.

13

• Mejoradeposicionamientodentrodelaplataforma:Permitehacerescalaralmúsicoen el ranking de resultados en búsquedas que ofrece el sistema, favoreciendo supublicidadyreconocimiento.

Amedidaqueelproyectoavanzalosobjetivosdelmismofueronvariando,manteniendocomoconstanteelfocosobrelosartistasysunecesidaddeexposición.Encapítulosposterioressehacereferenciaalosnuevosobjetivosdelproductoasícomolossegmentosdeclientesqueataca.

1.2. ObjetivosdelproyectoA continuación se describen los principales objetivos que el equipo persigue durante eldesarrollodelproyecto,categorizandolosmismosdentrodedosperspectivas:académicaydelproducto:Perspectivaacadémica

• Obtener conocimientos solidos sobre el desarrollo y puesta en producción de unsistemaenlanube.

• Desarrollarhabilidadestecnológicasnovistasdurantelacarreraqueayudenaobtenerunamejorpreparaciónprofesional.

• Puestaenprácticadeconocimientosadquiridosdegestión,desarrolloyhabilidadesinterpersonalesadquiridasdurantelacarrera.

Perspectivadeproducto

• Promover el desarrollo de la música brindando una plataforma interactiva dondenuevosmúsicoslogrenexponersumaterial.

• Crearunsistemaquecontribuyaconeldesarrollocultural.• Desarrollarunproductodecarácterinnovadorquebrindeunasoluciónrealypermita

unemprendimientoafuturo.

14

1.3. ElequipoyrolesIntegradoporAlexisZucco (AZ), JuanDiegoMéndez (JM)yNicolásMañay (NM)elequipocuentaconexperienciapreviaeneldesarrollodeobligatorios,talleresytareasenconjuntorealizadosduranteeltranscursodelacarrera.Sibienningunoposeeexperienciapreviaeneldesarrollodeunproyectodemagnitudessimilareslosintegrantessicuentanconexperienciaprofesionaleneldesarrollodesoftware,enparticularcontecnologíasMicrosoftcomo.NETySQL Server. También se tiene experiencia básica en el desarrollo de aplicacionesweb contecnologíasPHPyJQueryasícomoenelmanejodesistemasoperativosLinuxyservidoresApache.Enlasprimerasetapasdelproyectoseacordóentrelosintegrantesdelequipoqueactividadesdesarrollaríacadaunoalolargodelproyecto,asumiendoelcompromisodedesempeñarlasmismashastasufinalización.DedichasreunionessurgelaTabla1.

Actividad AZ JM NM

Arquitectura x x x

Desarrollo x x x

Ingenieríaderequerimientos x x x

SCM x

SQA x

Testing x x x

UI/UX x x

Investigación x x x

Gestión x

Tabla1-Actividadesdesarrolladasduranteelproyecto

Alexis Zucco (AZ): Arquitectura y Gestión del proyecto. Encargado de diseñar, evaluar yseleccionardiferentesalternativasdearquitecturaqueseadaptenalosrequerimientostantofuncionalescomonofuncionalesdelaplataformaysuscomponentes.Ademásseencargaráde analizar y estudiar diferentes tecnologías, seleccionar aquellas quemás se adecuen alproyectoyponerlasadisposicióndelequipo.Encuantoalagestióndeberáasegurarquesellevenacabolasactividadesplanificadas,garantizandoquetodoslosmiembrosdelequipotenganclaroqué tareas realizary cuales son losobjetivosqueelequipopersigue.Deberáadministrarelalcanceadecuadamenteygarantizarelcumplimientodelosobjetivosdefinidos.También asume el rol del área de SCM (del inglés Software ConfigurationManagement)procurandounacorrectaconfiguraciónderepositoriosasícomodelosambientesnecesarios

15

paraeldesarrollodelproyecto(equipos,servidores,cuentas,etc.)asegurándosequetodoslosintegrantestenganclaraslaspolíticasdetrabajosobrelosmismos.Juan Méndez (JM): Ingeniería de requerimientos y UI/UX. Encargado de evaluar ycomprenderlasnecesidadesdelcliente,eldominiodelproblema,lanecesidaddelsoftwareylasexpectativasdetodos losusuarios.Deberátransferirestavisiónalrestodelequipodelproyecto.Ademásseráresponsabledeasegurarquelaexperienciadeusuarioseaamigableyvisualmenteatractiva.NicolásMañay(NM):Encargadodelacalidad.Encargadodedefinirlosestándaresdecalidadymétricasquepermitanmedir losmismos.Deberárealizarunaplanificación,seguimiento,aseguramientodelacalidadycontroldelamismaduranteeltranscursodelproyecto.Si bien estos fueron los roles principales que cada integrante asumió las actividadesdesarrolladasnoselimitanaestosúnicamente;actividadescomoporejemplodesarrolloypruebadesoftwareseránllevadasacabodeformaconjuntaportodoslosintegrantes.TodaslasdecisionesdearquitecturaseránpropuestasporAZperoserán tomadas finalmenteenconjuntoportodoelequipo.Todoslosparticipantesasumenlaresponsabilidaddemantenerelrepositorioordenadoycorrectoasícomolosambientesdedesarrolloenforma.Paraestosedefinieronunconjuntodeestándaresyreglasparalacodificaciónygeneracióndeversioneslasmismassedescribenencapítulosposteriores.Debidoa las característicasemprendedorasdeesteproyectono se cuenta conuna figuraformaldeclientequeestipule funcionalidadesyrestriccionesalsistema.Sinembargoestafigura se sustituye por un experto del dominio, Alejandro Zorrilla de SanMartín,músico,bajistaycompositorgraduadodeBerkleeCollegeofMusic,Boston,Massachusettsenel2012,aquiensedescribiráenestedocumentocomoelproductowneraplicandounadenominacióndelametodologíaScrum[5].

16

2. Producto

2.1. DescripcióndelproblemaConelobjetivoderealizarunproyectodecarácterinnovadorsepropusoinvestigarcómosedesarrollaactualmenteennuestropaíslacarreradeunmúsico,partiendodesdesusinicios,primeraspresentaciones,relacionamientoconelpúblico,managers,etc.hastaconvertirseenartistasprofesionales.TeniendoencuentalahipótesisplanteadaenelcapítuloSeleccióndelproyecto,serealizaronentrevistas presenciales conmúsicos y bandas además de un cuestionario a más de 120artistasuruguayos(véaseAnexo1).Elobjetivodedichainvestigaciónfuecomprobarsidichahipótesissecumplíayasusvezdeterminarcualeseranlosfactoresdeterminantesparalogrardesarrollarseenelmediodelamúsica.Comoresultadoselogróvalidarlateoríaysedeterminóqueexistendosgrandesfactoresquedificultanabandasyartistasemergentesaconcretarpresentaciones:carecerdecontactosarticuladoresenelmedioylafaltadeunpúblicosignificativoqueimpulsesutrabajo.Asuvezcomoderivadodeestavalidaciónsedetectólabajadisponibilidaddeherramientasespecíficasexistentesquetomenenconsideraciónaestegrupodepersonasparaproyectarsuscarrerasartísticas.Esasíquesurgelaideadeunaplataformacolaborativa,dondeaquellosquebuscanunlugarenelmundodelamúsicatenganunecosistemadiseñadoparapresentarsumaterial,contactarconsusconsumidoresylograrunamayorexposición.

2.2. OportunidadElmercadodelamúsicaestácambiandonosóloparaquienescomponenmúsica,sinotambiénparasusconsumidores.LaexpansióndelatecnologíaeinfraestructurahanllevadoaquelosserviciosdestreamingporsuscripcióntalescomoSpotify,SoundCloudoBeatsMusic[9]esténlogrando captar cada vez mayor número de usuarios, logrando incluso atraer a quienesutilizabanserviciospiratascomoprincipalformadeconsumo.SegúnelreportedeIFPI(delinglésInternationalFederationofthePhonographicIndustry)[10]en2014(véaseAnexo2)losserviciosdemúsicaporsuscripciónlograronllegara41millonesde abonados, experimentando un 39% de crecimiento con respecto a años anteriores yrepresentandoel23%deltotaldeventasdigitalesanivelmundialen2014.Aestedatoselesumaelhechodeque2014representaunañodetransiciónparalaindustriadiscográficayaque por primera vez en la historia, impulsado por la demanda de los consumidores, losingresosmundialesprovenientesdelaventaenformatosdigitalesequipararonalosingresosprovenientesdeventasenformatosfísicos, lograndounaumentodel6.9%conrespectoaañosanteriores(comoseapreciaenlaIlustración3)yrepresentandountotaldeU$S6850millones.

17

Ilustración3-Ingresosporventasdemúsicadigital2014

Laindustriamusicalrepresentaunsectormuyatractivoqueactualmenteseencuentraenungranmomentopara la innovación.Lautilizaciónderedessocialeshaconvertidoamúsicoscompletamentedesconocidosenestrellasinstantáneas,impulsandocadavezamáspersonasaimitarlatendenciadesubirsumaterialaInternet.Delcuestionariorealizadoamásde120músicosuruguayos(véaseAnexo3)sedesprendióquecercadel92%delosartistasamateururuguayos utilizaron redes sociales para promocionar su trabajo, siendo las principalesherramientasutilizadaconestefinYouTube[11],Facebook[12]ySoundCloud[13].

2.3. SoluciónpropuestaAmadeussurgecomounasolucióndigitalquepretendeacercaramúsicosemergentesysupúblico potencial, logrando favorecer su desarrollo artístico y generando entre todos losusuariosunespaciodereferenciaparalamúsica.Porunapartelosmúsicosinteractuaránconun sistema que permita subir audios de su trabajo, programar eventos para difundirpresentaciones,adjuntarmaterialaudiovisualdeconciertosydesarrollaruncontactodirectoconsupúblicoatravésdemensajería.Porelladodelpúblicosepercibecomounsistemaquepermiteescucharyvisualizareltrabajodeartistas,contactarcon losmismodeformamáspersonal,compartiropinionesysobretodogenerarunambientedediálogoentornoaunacomunidadcongustosafines.Atodoestolousuariospodráninteractuaralestilodeunaredsocialconfuncionalidadescomoseguirasusartistasfavoritos,destacarmaterial(acción“megusta”o“compartir“)ovisualizarperfilesycontenidoenelsistema.DesdeunaperspectivatecnológicalaplataformaAmadeusseofreceatravésdeunaaplicaciónweb y una aplicaciónAndroid como prototipos funcionales del concepto desarrollado, asícomounaAPI(delInglésApplicationProgrammingInterface)abiertaquepuedeserutilizadaporotrosdesarrolladoresparaimplementarsuspropiosclientes.

2.4. ActoresprincipalesSeconsideradeespecialimportancialadescripcióndelosprincipalesactoresqueinteractúanconelsistema.Paraesosediseñanunaseriederolesquetienendistintosprivilegiossobrelasfuncionalidadesdelasaplicaciones.Debidoalascaracterísticasdeunaplataformaquebuscallegaralamayoraudienciaposibleylograrpromoverelconsumodecontenidocreadoporartistasexistelaposibilidaddeinteractuarconelsistemadeformaanónima.

0

5

10

2009 2010 2011 2012 2013 2014

Ingresosanivelmundial2009–2014

MilesdemillonesU$S

18

• Usuarios anónimos: Son aquellos usuarios que no proveen credenciales de

autenticaciónalservicio(bienseaporquenosedecidióiniciarsesiónopornohaberpasadoporelprocesoderegistro).SuinteracciónconelservicioestálimitadaalaAPIdemúsicayvisualizacióndeinformaciónbásicadeperfiles.

• Usuariosautenticados:Aquellosusuariosqueproveenal sistemaconalgún tipodecredencialyaseaelconjuntodeemailypasswordountokendeacceso.Dentrodeesta categoría sedefinen los siguientes roles, los cuales cuentanconuna jerarquíafuncionalenlascapacidadesquepuedendesarrollarenelsistema:

o Admin:Esterolesdesarrolladoparausoexclusivodelosintegrantesdelequipodurantelaetapadeprogramación,yaqueelmismocuentaconlahabilidaddemanipulartodoslosobjetosdelsistemasinlanecesidaddesereldueñodelmismo.

o Fan: Usuario básico del sistema que cuenta con las funcionalidades decomentar, seguir y dar “me gusta”. También tiene la posibilidad de subircomentarios,fotosyvideosensuperfil.

o Artista: Los usuarios que proporcionan material a la plataforma, pudiendoaccederalasfuncionalidadesbásicasdefanyagregandolaposibilidaddecrearálbumes,subirtemas,creareventos,etc.

o Banda: Usuarios similares a los artistas a nivel funcional pero que secaracterizanconceptualmentecomoalgodiferente.

o Locales:Sonaquellosusuariosquerepresentanaloslocalesdemúsicaenvivo.

19

3. Ingenieríaderequerimientos

3.1. IntroducciónDentro del desarrollo de software una de las etapasmás importantes es la Ingeniería derequerimientos, durante la cual se definen las funcionalidades y las restricciones para elsistemaasícomotambiénlosprocesosutilizadosparalograrsudefinición,especificaciónyvalidación.Dentrodeesteprocesosedefineunaseriedeactividadesnecesariasadesarrollarquedanformaasuciclodevida[14](verIlustración4):

Ilustración4-EtapasdentrodelaIngenieríaderequerimientos[14]

• Estudiodeviabilidad [15]: Elobjetivodeestaactividad seráverificar si elproyecto

merece la pena ser desarrollado a través de un estudio de viabilidad, por ejemploanálisisdelasfuerzasdePorter1[15].

• Obtenciónyanálisisderequerimientos:Elobjetivodeestaactividadesdeterminareldominiodelaaplicaciónasícomosusfuncionalidadesyrestricciones.

• Especificaciónderequerimientos:Unavezdeterminadoslosrequerimientossedebenredactarydocumentarlosmismosdeunaformacompleta,precisayverificableparaserinterpretadosportodoslosstakeholdersdelsistema.

• Validaciónderequerimientos:Duranteestaactividadseestablecenlosrequerimientosfinalesycompletosquedefiniránalsistemafiltrandolosmismosdelaespecificaciónpreviamenterealizadaconlaayudadelcliente(productownerparaesteproyecto).

1ParaesteproyectonoseaplicaestaetapayaqueexisteunanálisisprevioutilizandoDesignThinkingcomosedetallaenelcapítuloSeleccióndelproyecto.

20

3.2. TécnicasParaelrelevamientoderequerimientoselequiposebasóprincipalmenteenelusocombinadodetécnicasdetormentadeideasybenchmarking,lascualessonaltamenteefectivasparaeldesarrollodesoftware.Enetapasposterioresdelproyectotambiénfueronmuyefectivaslautilizacióndemockups[16]oprototiposqueayudaronalequipoaentendermejorcomolosusuarios interactuarían con el sistema, permitiendo descubrir nuevos requerimientos queotrasmetodologíasnorevelaron.Otrotécnicaquesirviódeinsumoparaelrelevamientofuela opinión del experto en el dominio (elproduct owner para este proyecto) que ayudó aclarificarlaperspectivadelartistaenciertostópicos.Cómo resultado se logró desarrollar un listado de requerimientos priorizado los cuales seagregaronalproductbacklog[17],siendoesteelprincipalinsumoalahoradecomenzareldesarrollo.

3.2.1. TormentadeideasEste tipodeherramientaesutilizadoporpequeñosy/omedianosequipospara facilitarelsurgimientodenuevasideasenunambienterelajadoendondeseaprovechalacapacidadcreativadecada integrante.Se realizanvarias sesionesendondesolamenteparticipan losintegrantesdelequipo,definiendounaideaoproblemacentralentornoalcualsegenerarannuevasideas.Acontinuaciónserealizanpropuestasportodoslospresentes,lascualessonanotadasdebidamente;comonormageneralningunaideaserechazayaquepuedeservirdeinspiración a otra idea. Esta técnica permite obtener un listado base de requerimientosrápidamenteyayudaaextenderlavisióndelproblemaaldesarrollarlaperspectivadetodoslosintegrantesdelequipo.Lametodologíaseaplicómediantelarealizacióndereunionesperiódicasenlafacultaddondese procedía a anotar las ideas que iban surgiendo en un documento. Posteriormente serealizaron reuniones donde el foco era el análisis sistemático de dicho documento,manteniendounavisiónampliadelproblemaquenodejaraescaparningunaideapotencial.

3.2.2. BenchmarkingEsta técnica permite considerar productos, servicios y/o procesos para lograr unacomparaciónqueevidencielasmejoresprácticasocaracterísticassobreunáreadeinterés,lograndoasíunatransferenciadeconocimientos[18].AplicandoBenchmarkingsecomparandiferentesempresasqueofrecensolucionessimilaresy se analizan las funcionalidades que sus productos ofrecen, buscando aquello que másimpacto y valor generan para los potenciales usuarios, así como también las posiblesdebilidadesquetienenyquesepuedenmejorar.Comoproductosprincipalesseconsideraronaquellosquedealgunaformamantuvieranundominio similar al que propone Amadeus, como por ejemplo streaming de contenido ofuncionalidadesderedsocial:

21

• Spotify: Es la aplicación clave para entender como se manejan las entidades

relacionadasalartistayalamúsica.• SoundCloud:Al igualqueSpotifysemanejasuusoalrededordelamúsicahaciendo

especial énfasis en la funcionalidad de subida de material por usuarios y loscomentarios.

• Reverbnation [19]:Es laaplicaciónmássimilaralproductoquesequiereconstruir,sirve como principal competidor aunque no opera en América Latina. Plantea unsistemaorientadoaartistaspararealizacióndeeventosmusicalesyalojamientodematerialdeaudio.

• Google+ [20]: Modelo de red social enfocada a compartir archivos gracias a suintegraciónconGoogleDrive.

• Facebook:Unadelasredessocialesmásgrandesanivelmundialyporlotantomodeloindiscutibledelarquetipo“redsocial”.

Enbaseestossistemasqueactualmenteofrecensusservicios(véaseAnexos4)serealizaunanálisisquepermitedescubrirlascaracterísticasquetienenmayorimpactoygeneranmayorvalorparalospotencialesusuarios.Algunascaracterísticasquesedestacanson:

• Reproductor siempre visible situado en la parte inferior (Spotify, Reverbnation,SoundCloud).

• Menúdenavegabilidadverticalysituadoalaizquierda(Spotify).• Navegabilidadmediantetabsparaelcontenido(Spotify,SoundCloud).• Títulodelacanciónenreproducciónsituadoenlaparteinferiordelmenúconimagen

delálbum(Spotify).• Tagsdeusuariosconcomentariosenlossegundosdelacanción(SoundCloud).• Sugerenciasdelbuscadoragrupadasportipodecontenido(Reverbnation,Spotify).• Barrasuperiorquemuestreinformacióndelusuarioautenticado(SoundCloud,Spotify,

Reverbnation).• Lista vertical situada a la derecha con las actividades recientes de otros usuarios

(Spotify).• Buscadorsituadoenlabarrasuperior(SoundCloud,Spotify,Reverbnation).

Del análisis se concluye que tanto Spotify, SoundCloud como Reverbnation cumplensatisfactoriamenteconlosrequisitosdeunaplataformadedistribucióndemúsica.AsuvezReverbnationySoundCloudcumplenademásconlosrequisitosfuncionalesdeunaredsocialofreciendounaexcelentecombinacióndeambosservicios,mientrasqueSpotifyfallaenesteaspectoporsufaltadeunchatolahabilidaddecomentarelementosenlaplataforma.SedescubrióqueunadelasfortalezasdeSpotifyessuusabilidad,ofreciendounproductodedistribucióndemúsicamásatractivoporsuinterfazsimpleycomprensible.EncuantoaredessocialestantoFacebookcomoGoogle+tienenunaexcelenteusabilidadconaltasatisfacción

22

delosusuarios,entreellasnosinclinamosporGoogle+yaquecumpleconlasnormativasdeMaterialDesign[21],perofallancomoplataformadestreamingdemúsica.

3.2.3. PrototipaciónEsunatécnicaquepermitedeformarápidayefectivalautilizacióndemaquetasodibujosparaesbozarunainterfazdeusuariodandounaperspectivamásclaradecómointeractúanlosusuariosconelsistema.Elequipocreodiversosprototipos(verejemploenIlustración5)loscualesseibapresentandoal product owner con el objetivo de validar tanto los requerimientos así como laUI/UX,obteniendomejorasenlaexperienciadelusuario.Elusodeestatécnicallevoaqueelequipose situara en la piel del usuario, facilitando entender su punto de vista, como sería lainteracciónhumano-máquinaybajoquecontextoseríautilizadalaaplicación.

Ilustración5-MockupdeaplicaciónAndroid

23

3.2.4. ReunionesSemantuvieronreunionesperiódicastantoconelproductownercomoconlatutoraconelobjetivo de obtener nuevos requerimientos y validar los existentes. Todas las reunionesestablecidaseranpreviamentecoordinadasentre losparticipantescomosedescribeenelcapítuloGestióndelacomunicaciónyenellasseplanteabanlasfuncionalidadesdetectadasoimplementadas.De las reuniones con la tutora surgió la idea de utilizar sentiment analysis, actividad querefiere al uso de procesamiento del lenguaje natural para interpretar connotacionesemocionales implícitas en el texto [22]. Se discutió mucho sobre la aplicación de estacaracterísticaenelproyectoconcluyendoquepermitiríabrindarunafuncionalidadúnicadelrestodelasplataformasexistentes,sumadoaqueesunexcelentecomplementoamuchosdelos requerimiento definidos. Amodo de ejemplo se planteó la posibilidad de utilizar esterecursojuntoalafuncionalidaddeconciertosenvivodemaneradeobtenerentiemporealunanálisisdeloscomentariosdelosfansqueayudealosartistasaentendercomorepercutesumaterial.Encuantoalasreunionesconelproductownerelmismohizoénfasisenlanecesidaddequeelsistemahagasufocoprincipalenlainteracciónentreartistasyfans,siendoesteelpuntoquemásvaloraranlosartistasdelproducto.

3.2.5. EncuestaDurantelasetapasprimariasdelproyectosellevóacabounaencuestaatravésdelusodeformularios de Google, los cuales permiten crear una plantilla electrónica fácilmentedistribuibleatravésdeunlink(verAnexo1).Elpropósitodedichaencuestafuecomprobarlateoría que el equipo sostenía al iniciar el proyecto de que los artistas emergentes teníandificultadesalahoradecomenzarsucarreradebidoalpocopúblicoalquesepuedellegarpor los canales existentes. Un derivado obtenido del análisis posterior de los resultadospermitió conocer cuales eran las características principales del público objetivo para elproducto(verIlustración6)ademásdedescubrircualessonlasherramientasqueseutilizanactualmente para satisfacer la demanda, las cuales se analizaron como se describe enanteriormenteenestecapítulo.

24

Ilustración6-EmpathyMapcanvasdeperfildemúsicoemergente

3.3. Justificacióndelastécnicasderelevamiento

Lastécnicasanteriormentemencionadaspararelevarlosrequerimientosseeligieronporquela ideadelproductonaceenelpropioequipodeproyecto,ycomoseexplicóencapítulosanterioresnoexistelaimagendeclienteaquienentrevistarenbuscaderequerimientos.Sinembargoduranteelproyectosecontóconlaayudadelusuarioexperto,aquiensedefiniócomo el product owner (ver capítulo El equipo y roles), brindando su experiencia cómomúsico/usuario y junto a quien se especificaron la mayoría de las funcionalidades delproducto.

3.4. Especificacióndelosrequerimientos

3.4.1. IntroducciónLosrequerimientosdeunsistemasonaquellascapacidadesocondicionesrequeridasporelusuariopara resolverunproblemaoalcanzarunobjetivo,odesdeunpuntodevistamásenfocadoalosusuariosloqueelsistemahacesinespecificarcómosehace[23].

25

3.4.2. TécnicaLas user stories (US) son descripciones cortas de funcionalidades descritas desde laperspectivadelusuarioquelassolicita[24].EstaspuedenserescritasporcualquierpersonadelequipoencualquiermomentoperoesresponsabilidaddelproductownerqueelproductbacklogesteformadoporunconjuntodeUSquereflejelosdeseosdetodoslosusuarios.Unproblemageneralquepresentanmuchosproyectosesasumir indebidamentequesoloexisteunúnicotipodeusuario,locualgeneracomoresultadoespecificacionesincompletas.ParaelloenScrum sedefinen losusers roles almomentodedescribir las funcionalidades.Estospermitenobtenerdiferentesvisionessegúnlaperspectivadelosdistintosusuarioslocualeliminalageneralidad,volviéndolosmástangibles.Unposibletemplateparadefinirlosseria:“Como<userrole>quiero<objetivo>deformatalque<beneficio>”.Las3Csdelasuserstories

• Carta:Porlogeneralseescribenentarjetasonotasadhesivasyselepuedenagregarestimacionesyotrasnotas.

• Conversación: Los detalles de unaUS se desprenden de las conversaciones con elproductowner.

• Confirmación:Existentestsdeaceptaciónqueconfirmaquelahistoriafuecodificadademaneracorrecta.

CaracterísticasdebuenacalidaddelasUS

• Independiente:CadaUSdebeserindependientedeotraUS.• Negociable:Puedenserreescritashastaqueentrenaundeterminadosprint• Valuable:laimplementacióndebedeteneralgúntipodevalorparaalgúnelclienteo

interesadodelproducto• Estimable:Debepoderdefinirseelgradodegranularidad.• Escalable:Manejablealahoradeplanificar/estimar/priorizar.• Testable:Elprogramadortienequepoderversisecompletócorrectamente.

DuranteeldesarrollodelproyectoelequipoutilizólasUSparadefinirlosrequerimientosdelosdistintosusuariosdelaplataformaconelobjetivodecomprenderlasnecesidadesdetodoslosusuarios.Sinembargocomosedetallaencapítulosposterioreselequipooptóporutilizaruna adaptación de la metodología Scrum, así como de la especificación de las US queconformanelproductbacklog.ParaelmanejodelproductbacklogasícomodelScrumboard,sprintsyuserstoriesseutilizóTrillo[25]comoprincipalherramienta.

3.4.3. RequerimientosAcontinuaciónsepresentalaespecificaciónformaldelosrequerimientosfuncionalesynofuncionales desarrollados durante la etapa de ingeniería de requerimientos. Los

26

requerimientos funcionales se encuentran debidamente catalogados con prioridad alta,mediaobajasegúnelgradoderelevanciaquerepresentenparalaplataforma.

• Alta:Requerimientodecarácteresencialparaelsistema,lafaltauomisióndelmismodeterioraelniveldeserviciobrindado.

• Media:Requerimientoaltamentedeseadoqueaporta a la funcionalidadpero cuyaomisiónofaltaocasionapocoobajodeterioroalserviciobrindado.

• Baja:Requerimientodeseadocuyafaltanoocasionadeteriorosalserviciobrindado.

3.4.4. RequerimientosfuncionalesUnrequerimientofuncionaldefineunafuncióndesoftwareosuscomponentesyelconjuntodeestospermiteestablecerelcomportamientosdelsistema[26].

RF1 Registrodeusuarios

Creacióndenuevosusuariosdentrodelsistema,loscualespuedenposeerdistintosroles:Admin,Artist,FanoVenue.

Prioridad:Alta.

RF2 Logindeusuarios

Dadaslascredencialesdeautenticaciónunusuariopodráaccederasucuentadentrodelaplataforma.

Prioridad:Alta.

RF3 Edicióndeperfilydatos

Todousuarioregistradotendrálaposibilidaddeeditarsuinformaciónpersonal(fotodeperfil,email,etc.).

Prioridad:Media.

RF4 Logoutdeusuarios

Todousuarioquehayaingresadoalaplataformapodrácerrarsusesiónenlamismaunavezhayafinalizado.

Prioridad:Baja.

27

RF5 Resetdecredencialesdeautenticación

Todo usuario que haya ingresado a la plataforma podrá solicitar un reset de suscredencialesdeautenticación(ejemplopassword)encasodeolvidoosospechadevulneracióndeseguridad.

Prioridad:Baja.

RF6 Cierredecuentadeusuarios

Todoslosusuariosquehayaningresadoalaplataformapodránsolicitaruncierretotaldesucuenta,borrandotodosucontenidodelamisma.

Prioridad:Baja.

RF7 Manejodeálbumparaartistas

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodráncrear,modificary/oeliminarsusálbumesdemúsica.

Prioridad:Alta.

RF8 Manejodetemasparaartistas

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsubiry/oeliminarsustemasdesusálbumes.

Prioridad:Alta.

RF9 Escucharmúsica

Todoslosusuariosdelsistema(autenticadosono)podránhacerusodelamismaparaescucharlostemassubidosporartistas.

Prioridad:Alta.

RF10 Manejodearchivosmultimedia

Todoslosusuariosquehayaningresadoalaplataformapodránsubir,modificary/oeliminarsusarchivostalescomofotografíasovideos.

Prioridad:Media.

RF11 Seguirartistasobandas

28

Todos los usuarios que hayan ingresado a la plataforma podrán seguir o dejar deseguiraotrousuarioconrolartistaobanda.

Prioridad:Alta.

RF12 Crearbanda

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodráncrearunabandaconotrosartistasdelaplataforma.

Prioridad:Media.

RF13 Escribircomentarios

Todoslosusuariosquehayaningresadoalaplataformapodrándejarcomentariosaotrosusuarios,bandas,álbumes,temas,archivos(fotosyvideos)ypresentacionesenvivo.

Prioridad:Alta.

RF3 Daraplauso

Todos los usuarios que hayan ingresado a la plataforma podrán dejar aplausos o“likes”aotrosusuariosconroldeartista,bandas,álbumes,temasoarchivos(fotosyvideos).

Prioridad:Alta.

RF14 Manejodeeventos

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodráncreareventos(presentaciones,convocatorios,festivales,etc.)enlaplataforma.

Prioridad:Media.

RF15 Presentacionesenvivo

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránprogramarytransmitirunvideoenvivodentrodelaplataforma.

Prioridad:Baja.

RF16 Ventadecontenido

29

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsolicitarunbotónde“Invitarmeuncafé”parasolicitardonativosasusfans.

Prioridad:Baja.

RF17 Manejodeplaylists

Todoslosusuariosquehayaningresadoalaplataformapodráncrear,modificary/oeliminarsusplaylists.

Prioridad:Media.

RF18 Rankingdeálbumes

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsolicitarelrankingdeálbumesduranteeltiemposeleccionandolaunidaddetiempo,losálbumesacompararyelperiodoaconsultar.

Prioridad:Baja.

RF19 Rankingdecanciones

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsolicitarelrankingdecancionesduranteeltiemposeleccionandolaunidaddetiempo,lascancionesacompararyelperiodoaconsultar.

Prioridad:Baja.

RF20 Sentimentanalysisdecanciones

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsolicitar un sentiment analysis de sus canciones en base a los comentarios de lamismas.

Prioridad:Baja.

RF21 Sentimentanalysisdealbums

Todoslosusuariosquehayaningresadoalaplataformaconelroldeartistapodránsolicitarunsentimentanalysisdesusálbumesenbasealoscomentariosdelamismas.

Prioridad:Baja.

30

RF22 Sentimentanalysisdepresentacionesenvivo

Todoslosusuariosquehayaningresadoa laplataformaconelroldeartistayesterealizandounapresentaciónenvivopodránsolicitarunsentimentanalysisentiemporealenbasealoscomentariosdelapresentación

Prioridad:Baja.

RF23 LoginmedianteFacebook

Dada las credenciales de Facebook se creara un usuario según los datosproporcionadossinotieneypodráaccederasucuenta.

Prioridad:Alta.

RF24 LoginmedianteTwitter

DadalascredencialesdeTwittersecrearaunusuariosegúnlosdatosproporcionadossinotieneypodráaccederasucuenta.

Prioridad:Baja.

RF25 Visualizacióndeactividades

Todos los usuarios podrán ver las actividades como nuevo álbum, comentario,canción,seguimiento,etc.delosusuariosquesiga.

Prioridad:Media.

RF26 Buscadordecontenido

Todoslosusuariospodránbuscarartistas,álbumesocancionesingresandountexto

Prioridad:Alta.

RF27 Reproductordevideo

Todoslosusuariospodránreproducirlosvideossubidosalaplataforma

Prioridad:Media.

RF28 Visualizacióndel“muro”deunusuario

31

Todoslosusuariospodránverun“muro”dondesepodrádejarcomentariosaotrousuario.

Prioridad:Media.

RF29 Chat

Todoslosusuariospodráncomunicarseentiemporealconotrosusuariosaloscualessiganyseencuentrenautenticadosenelsistema

Prioridad:Baja.

RF30 Manejodeoportunidadeslaborales

Losusuariosconelroldelocalpodráncrear,editaryeliminaroportunidadeslaboraleslascualespodránseraplicadasporlosartistas

Prioridad:Baja.

RF31 Aplicaciónaoportunidadeslaborales

Losusuariosconelroldeartistaspodránaplicaralasoportunidadeslaboralescreadasporloslocales.

Prioridad:Baja.

3.4.5. RequerimientosnofuncionalesUnrequerimientono funcionaloatributodecalidadesaquelqueespecificacriteriosparajuzgarlaoperacióndeunsistemaenlugardesuscomportamientosespecíficos.Serefierenatodos losrequisitosquereflejancaracterísticasdefuncionamientoynofuncionalidad[26].Todos los requerimientos no funcionales que se especifican a continuación serándebidamentejustificadosenelcapítuloAnálisisdeatributosdecalidad.RNF1-DisponibilidadElsistemadeberápermanecesdisponibleparasuacceso24horasdiariaslos365díasdelaño,garantizandounmínimodedisponibilidaddel99%deltiempo(uptime).Encasodefallaseltiempopromedioderestauracióndelservicio(downtime)nodeberásuperarlahora.RNF2-PerformanceLaperformancesedivideen2criteriosatenerencuenta:

32

• Tiemposderespuesta:Lostiemposderespuestadependerándelazonayelanchode

bandadisponible.Paraunaconexiónconlatenciaentre100y250msy15Mbitsdevelocidad de bajada, los tiempos de respuesta serán inferiores al segundo. Latransferencia de datos hacia los servidores tales como imágenes y/o video podrárequerirtiempoadicionalenresponderdebidoasuprocesamiento.

• Capacidaddeconcurrencia:Elsistemadebepermitirunmínimode100conexionesconcurrentesalservidorentodomomento.

RNF3-PortabilidadLalógicadelservidordebeestarimplementadaenunlenguajedeprogramaciónportableconel objetivo de ser desplegada tanto en servidores Linux comoWindows en caso de serrequerido.Asuvezdebetenerunniveldedesacoplesuficientecomoparaconstruirnuevasinterfacesdeusuarioquehaganusodesusfuncionalidadessinsernecesariolamodificacióndelcódigofuente.RNF4-EscalabilidadElsistemadeberáescalarhorizontalmentesinsufrirpérdidasdeperformanceentiemporealsin tiempo fuera de servicio. También es deseable que exista soporte para escalabilidadverticalsiserequiere.RNF5-SeguridadElsistemadebeautenticaralosusuariosantesdedarlesaccesoaciertasfuncionalidadesdelservicio.Laplataformadeberáutilizarunsistemadetokensquepermitanevitarenelmayorgradoposiblelanecesidaddeutilizarcredencialesdeautenticacióntradicionales(porejemplousodeemailypasswordcadavezqueserequiereacceso)juntoconunesquemaderolesquefiltren las funcionalidades.A su vezdichas credencialesdeberánestar almacenadas enunformato seguro impidiendo su utilización en caso de ser vulneradas (almacenamientoencriptado).PorúltimoesdeseablelautilizacióndeunprotocoloSSL(delInglésSecureSocketsLayer)quegaranticeunacomunicaciónsegura.RNF6-UsabilidadDebeexistircoherenciaentrelasinterfacesgraficasdelosdistintosdispositivosenlosquelaaplicaciónestésoportada.ParaellosesiguelasguíasdeimplementacióndeMaterialDesign[21].

33

4. ArquitecturaAcontinuaciónsedetallanlasprincipalescaracterísticasydecisionesarquitectónicasquesetomaron en cuenta para la implementación de este proyecto, junto con sus atributos decalidadycriteriosdeseleccióndetecnologías.Elcapítulopartedeunenfoquearquitectónicodealtonivel,adentrándosecadavezmásenlosdistintosnivelesmedianteelusodeunsubconjuntodelmodelodevistaspropuestoporPhilippeCrichton[27].

4.1. IntroducciónLaarquitecturadesoftwareeslaorganizaciónfundamentaldeunsistemaformadaporsuscomponentes, lasrelacionesentreellos,elcontextodondese implantarán,y losprincipiosqueorientansudiseñoyevolución[28].Lamismaseseleccionaydiseñaenbaseaobjetivospreestablecidos,buscandoquesuscomponentesfortalezcanlaestructurageneral,tomandodecisiones en base a un amplio rango de factores, los cuales pueden impactarconsiderablementeenaspectostalescomolacalidadomantenibilidadysobretodoafectareléxitodelproducto.Comocualquierestructuracomplejaelsoftwaredebeestarconstruidosobreunpilarsólido,ya que de no tener en consideración posibles escenarios o situaciones a las que se verásometido el mismo, puede llevar a serios problemas de performance o disponibilidadconvirtiendoaunsistemaenalgofrágileinútil.

4.2. ArquitecturapropuestaDelaespecificaciónderequerimientosdetalladaenelcapítuloanteriorelequipooptópordesarrollartresproductosindependientes,paraloscualesseutilizaronsuspropiasdecisionesarquitectónicasyloscualestrabajaranenconjuntocomounaúnicasolución.EnelnúcleodelsistemasedecidiódesarrollarunaAPIquebrindasetodaslasfuncionalidadesrequeridasalosclientesatravésdesuinterfazyqueactuasecomoúnicaentradaparalosdatos.Comofrontendsedecidieronimplementardossoluciones:primerodesarrollarunclientewebcapazdeejecutarencualquiernavegadorcompatibleconHTML5ysegundounaaplicaciónnativaparaAndroidquepermitabrindarunaexperienciamásespecíficaalosusuariosdeestaplataforma.Desde una perspectiva general el proyecto se desarrolla sobre una arquitectura clienteservidor, en el que las tareas se reparten entre los proveedores de recursos o servicios,llamadosservidores,ylosdemandantesoclientes[29].Estetipodearquitecturafavoreceeldesacoplamientodelprocesamientoymanejodedatosentre losnodosclientey servidor,incrementando laperformanceal alivianar la cargadel ladodel servicio (cada cliente seráresponsabledemostrarlainformaciónasuconveniencia)yfavoreciendolainteroperabilidad(elservidorsecomunicaenunsoloidioma,losclientessonresponsablesdeinterpretarlo).Esto permite al servidor mantener una estructura consistente mientras que los clientes

34

puedenutilizarsusfuncionalidadesdesdeunsinnúmerodeimplementacionesposibles,comosepuedeapreciarenlaIlustración7acontinuación.

Ilustración7-Arquitecturadistribuidacliente-servidor

4.3. AnálisisdeatributosdecalidadPara el desarrollo de la arquitectura uno de las principales entradas del proceso fue laespecificaciónderequerimientos,conparticularénfasislaespecificacióndelosatributosdecalidad.Paracadaatributodecalidaddetectadoexistenunaseriedeconcernsloscualessepuedendefinircomopuntosclavesobreelatributoatenerencuenta,asícomounconjuntodetácticasaplicablesquepermitegarantizarsucumplimiento.Acontinuaciónsedetallaenanálisisdedichosrequerimientosjuntoconsustácticasaplicadasparasatisfacerlosmismo.DisponibilidadLadisponibilidaddesepuededefinircomolahabilidaddeunsistemadeestarcompletaoparcialmente operacional cuando se lo requiera (gestionando efectivamente fallas quepuedanafectarsudisponibilidad)[30].Parahacer frentea los requerimientosdedisponibilidadesnecesario tenerencuentadospuntosclave:calidaddeservicioservido(uptime)ytiempofueranoplaneado(downtime).Lacalidad de servicio, como se describe en el requerimiento no funcional hace referencia altiempomínimo durante el cual debe permanecer activo el servicio y el tiempo fuera noplaneadoesellapsotemporalmáximoquepuedeexistircuandoocurreunabajadelsistemahastaelmomentoenelqueelmismovuelveaestaroperativo.TácticasdedisponibilidadPara lograr satisfacer los requerimientos de disponibilidad fue necesario utilizar unmecanismo que garantizase redundancia de servidores, permitiendo así que en todomomentoexistaalmenosunnodoquerespondaalaspeticionesdelosclientes.Elequipo

35

estudiódurante lasetapasprimariasdelproyectovariasopcionesdecloudcomputingquepermitiesenofrecerelserviciodeunaformamasivaalosusuariosyasuvezgarantizaseladisponibilidadespecificada,entreellaselserviciodeInfraestructuracomoserviciooIaaS(delInglésInfrastructureasaservice)provistoporAmazonECS(delInglésElasticComputeCloud)yporotroladoHeroku,serviciodeplataformacomoserviciooPaaS(delInglésPlatformasaService)[31].FinalmenteelequipodecidióutilizarHeroku.Herokunaceenjuniodel2007yseconvierteenunadelasprimerasPaaSdelmercado,dandosoporteenaquelentoncesúnicamenteasistemasRuby.Posteriormenteseextiendeaotroslenguaje de programación dando actualmente soporte a sistemas Java, PHP,NodeJS,Go,entre otros. Una de sus características más destacables es la utilización de dynos,(contenedores Linux virtualizados) los cuáles permiten manejar múltiples peticiones declientesenambientesaisladosdentrodeunmismohostoequipo (ver Ilustración8). Estoquieredecirqueunequipopuedealbergarmúltiplesdynosquecompartensuhardwareperoquetrabajancomounidades independientesentresí, favoreciendoelaprovechamientoderecursosylaseguridadenlacomunicaciónentrelosdistintosclientesyelservidor.Tambiéngarantizan que dentro de un ambiente con múltiples dynos el servicio no sufrirá unadegradacióntotalalconstatarseunafallaenunadelasinstancias.

Ilustración8-Virtualizacióndedynosdentrodeunservidorfísico

Heroku ofrece una variedad de planes de uso para las distintas necesidades de losdesarrolladores,peroesdestacablesuopciónparadesarrolladoresdeusogratuita,lacualesperfecta para comenzar a experimentar con sistemas en la nube. Por último, otro factordecisivoparaelegirestaplataformafueelusodeadd-onsoextensiones,quepermitenutilizarañadidosdefuncionalidadesextraanuestroservicioquevadesdeunmanejadordebasededatos hasta un completo sistema de prueba de estrés al servidor. A pesar de no contarformalmenteconunacuerdodeniveldeservicio[32]enlaprácticaestaplataformacuentaconunuptime99.7%,locualesmayoraltiemporequeridoasícomoundowntimedenomásdeunahora[33].

36

PerformanceEselgradoenelcualelsistemaocomponentellevaacabounafuncionalidadespecificadadaunarestriccióndevelocidad,precisión,etc.yelusoeficientedelosrecursos[30].Para hacer frente a los requerimientos deperformance es necesario tener en cuenta dospuntosclave:tiemposderespuestaypicosdecarga.Lostiemposderespuestadebenestardefinidos para el promedio de las llamadas al servidor bajo determinadas circunstanciasmientras que los picos de carga se definen como la cantidadmínima de usuarios que elservidordebedarrespuestadeformasimultaneasindegradacióndelservicio.TácticasdeperformanceUnaformadeofrecerunserviciomásligeroesmediantelaimplementacióndeunservidorREST (del Inglés Representational State Transfer). REST define un conjunto de principiosarquitectónicos por los cuales se diseñan serviciosweb haciendo foco en los recursos delsistema,incluyendocómoseaccedealestadodedichosrecursosycómosetransfierenporsimplescomandosHTTP [34].UnaimplementaciónconcretadeunserviciowebRESTsiguecuatroprincipiosdediseñofundamentales:

• UtilizacióndemétodosHTTP.• Stateless,nosemantieneestadoalgunodelladodelservidor.• ExposicióndeURIsorecursosenformadedirectorios.• TrasferenciadecontenidoenXMLy/oJSON.

REST hace que los desarrolladores usen losmétodosHTTP explícitamente demanera queresulteconsistenteconladefinicióndelprotocolo.Esteprincipiodediseñobásicoestableceuna asociación “uno a uno” entre las operaciones de crear, leer, actualizar y borrar y losmétodosHTTP.Deacuerdoaestaasociación:

• POSTparacrearunrecursoenelservidor.• GETparaobtenerunrecurso.• PUTparacambiarelestadodeunrecursooactualizarlo.• DELETEparaeliminarunrecurso.

Al utilizar JSON como lenguaje de comunicación entre clientes y servidor, se evita utilizarmecanismoscomplejosdeprocesamientodeXMLypermitetenermayorinteroperabilidadentredistintasaplicacionesdebidoaqueactualmenteesunformatoestándar.JSONasuvezes amigable desde un punto de vista lingüístico para el ser humano así como fácilmenteinterpretableporlasmáquinas.Otra tácticaaplicadaparamejorar laperformancees ladistribuciónde responsabilidades.ParamejorarlarespuestadelservidorseoptóporimplementarunasoluciónSPA(delInglésSinglePageApplication)enlosclientesweb,demaneratalqueunavezqueseestableceunacomunicaciónconelservidoresteúltimosolodeberáenviarlainformaciónrelevante,dejando

37

queseaelclienteelquedecidacomodeberápresentarla.EstopermitediseñarunasoluciónúnicadelladodelservidorquefuncionebienconcualquiertipodeclienteEnmuchasllamadasaunaAPIesnecesariocargarrecursosrelacionadosentresí,locualderivaenungrupodepeticionesbatchalservidorquepuedentomarmuchotiempoencompletarse.Paraelloen lugardequeelclientedebaemitirsolicitudesadicionales,sepuede lograrunmejor aprovechamiento de los recursos si los datos son retornados junto con la solicitudoriginal. Por ello durante el diseño de laAPI se tomó́ en cuenta su contexto de uso paraagrupartodoslosdatosquelosclientesnecesitanparacompletarunrequerimientodentrodeunamismarespuesta.PortabilidadSedefinecomolacapacidaddeunsistemadeejecutarsusfuncionessobrediversossistemasoperativos[35].TácticasdeportabilidadPara satisfacer este requerimientos se decidió utilizar lenguajes de programación quepudiesenserejecutadosencualquierservidor,manteniendoasílasposibilidadesabiertasencuanto alhosting que se elegiría. Se tuvieron en consideraciónPHP y Java comoposiblescandidatosperofinalmenteelequiposedecidióporRubyonRailsparaeldesarrollodelaAPIyAngularJSparadesarrollofrontend.ParalaaplicaciónnativaAndroidlaelecciónfueJavaporser la forma más rápida y eficiente de desarrollo en dicha plataforma, existiendo otrasposibilidadescomoRubymotion,XamarinoPhoneGap.EscalabilidadEs la capacidad de un sistema, red o proceso de manejar un crecimiento excesivo en lademandaoelpotencialparaaumentarsusrecursosparahacerfrenteadichademanda[36].La escalabilidad de una aplicación puede sermejorada asignando recursos adicionales dehardware (escalabilidad vertical) omediante la asignación de nuevos nodos que atiendanpeticiones (escalabilidad horizontal). En el caso de Heroku ambas posibilidades estánpresentes,yaseapasandoaunplandondeseasignemayoresrecursosdehardwareobienmediantelautilizacióndenuevosdynosenelservidor,locualaumentaráconsiderablementelacapacidadderespuestadelmismo.Paralograrunaescalabilidadhorizontalesnecesarioproveerunasoluciónstateless.Estoesimprescindibleyaquealescalarhorizontalmenteseañadennodos,porlotantolassolitudesdelclientepuedenserresueltaspordynosdiferentes,causandoquedeexistirunasesiónseanecesario una sincronización en los mismo lo cual afectaría considerablemente laperformance,disponibilidad,entreotras.GraciasaunaimplementaciónRESTestonoseríaproblemaparalaAPI.

38

SeguridadLa habilidaddeun sistemapara controlar,monitorear y auditar en forma confiablequiénpuederealizarquéaccionessobreel sistemaysus recursos,y lahabilidadparadetectaryrecobrardefallasenlossistemasdeseguridad[30].TácticasdeseguridadPara lidiar con el tema de la seguridad se optó por utilizar Devise como motor deautenticación. Devise es una gema de Rails diseñada para hacer un manejo flexible deregistros de usuario e inicio de sesión que puede ser fácilmente adaptable a cualquierproyectomediante el uso independiente de cualquiera de sus diezmódulos que brindanfuncionalidadesúnicasalsistema:

• Database Authenticatable: Permite manejo de tokens en la base de datos paraautenticación.

• Omniauthable:Manejodeiniciodesesiónconredessociales.• Confirmable:Envíodemailquepermitaconfirmarunacuenta.• Recoverable:Envíodeemailconinstruccionesdereset.• Registerable:Manejodecuentasdeusuario.• Rememberable: Manejo de tokens dentro de cookies que permitan mantener el

estado.• Trackable:ManejodeIP,cantidaddeiniciosdesesión,etc.• Timeoutable:Expiracióndesesiónquenohasidoutilizadoenciertoperiodo.• Validatable:Proveevalidaciónatravésdeemailypassword.• Lockable:Bloqueodecuentaaldetectarseunnúmerodadodeiniciosfallidos.

Paraesteproyectoenparticularseutilizóunderivadodeestagema,llamadodevise-token-auth[37],lacualfuncionadeigualformaquelaanteriorexceptuandoqueelmanejodetokensesresponsabilidaddelclienteynodelframework.Larazónprincipalparautilizarestederivadoes la utilización de la plataforma deAndroid, con la cual se puede hacer unmanejomásadecuadodelostokens,permitiendomayorcontrolyseguridad(verIlustración9).

39

Ilustración9-Intercambiodetokenenunallamadaalservidor

Otra táctica aplicada para lograr satisfacer el requerimiento de seguridad es el uso delprotocoloSSLenlacomunicaciónentreclienteyservidor.UsabilidadLafacilidadconlacuallaspersonasinteractúanconlaaplicaciónenformaefectiva,ysobrecomoelsistemaproveesoportealusuarioenestesentido[30].TácticasdeusabilidadLa usabilidad es uno de los atributos de calidad en lo que se hizomás énfasis durante eldesarrollodelproducto,buscandounaUI/UXuniforme,coherentey sobre todosimpleentodaslasinterfacesdeusuario.ParaellosesiguieronlasguíasdediseñodeGoogleMaterialDesign[21].LafilosofíadeMaterialDesignsurgecomounaguíadepautasespecíficaseneldiseñodeinterfacesAndroidperoquenoseaplicaúnicamenteenestaplataforma,sinoqueseextiendeatodaslasinterfacestalescomopáginaswebyotrasUI.Estarecibesunombrepor estar basada en objetos materiales, con profundidad, superficie, bordes, sombras ycoloresquejueganunpapelprincipalensudiseño,dondelafísicaseaplicaenlainteracciónentredistintosobjetosbuscandorecrearunasensaciónderealidad.MaterialDesign(ejemplo

40

deUIenIlustración10)esundiseñoconunatipografíaclara,casillasbienordenadas,coloreseimágenesllamativosquenodejanperderelfocodelaacciónrequerida,apoyándoseenunintuitivosistemademovimientoenlosobjetosquerequieranespecialatención.

Ilustración10-MockupdeinterfazMaterialDesign[21]

Para lograrunacorrecta implementacióndeMaterialDesignenelclientewebseoptóporadquiriruntemplatequeincorporaselasespecificacionesrequeridas,ademásdeacelerarlaimplementacióndelmismo.Estoaseguracontarundiseñoquecumplelasespecificaciones,asu vez que garantiza una correcta adaptación amúltiples resoluciones (responsiveness) ypermitelaimplementaciónSPA.Esasíqueseadquiereeltemplatetriangular[38].OtratácticaaplicadafueelpatróndearquitecturaMVC[39](delInglésModelViewController)elcualproponelaconstruccióndetrescomponentesindependientesquesonelmodelo,lavistayelcontrolador,conelfindeseparardatosylógicadenegociodeunaaplicación,interfazdeusuarioymóduloencargadodegestionarloseventosylascomunicaciones(verIlustración11). Este patrónde arquitectura de software buscamaximizar la reutilización de código yaumentareldesacoplamientoentreloscomponentesdelsistema,facilitandoeldesarrolloyelmantenimiento.Unavistanoconoceacercade losorígenesdedatos,yaque recibe losdatosdelcontrolador.Uncontroladornoconocenadaacercadeladistribucióngráficadeloselementosporqueeslaresponsabilidaddelavista.

41

Ilustración11-ArquitecturaMVC[40]

4.4. Descripcióndelaarquitectura

Acontinuaciónsedescriben lasestructurasprincipalesquedanformaa laarquitecturadeAmadeus. La misma se hace en función de un conjunto de vistas, las cualesindependientemente representa un aspecto particular del sistema. Se decidió utilizar lassiguientesvistas:

• VistadeDespliegue:Muestracomoserelacionanloselementosconsuambientedeejecución.

• VistadeMódulos:Serepresentalaestructuradelsistemaentérminosdeunidadesdeimplementación.

• VistaLógica:Serepresentalaestructurainternadelsistemadesdeunaperspectivadeclasesyrelacionesentresí.

4.4.1. VistadeDespliegue

Estavista seutilizaparaproveeruna imagenestáticade la configuracióndelambientedeejecución de los nodos de procesamiento y de los componentes que ejecutan sobre losmismos.Enotraspalabraseldiagramadedesplieguemuestraelhardwareparaelsistema,elsoftware que se instalaenesehardware y las conexionesquecomunicandichohardwareentresí.

42

Ilustración12-Diagramadedesplieguedelservicio

Acontinuaciónsehaceundesglosedetallado(Tabla2)deloscomponentesdescritosenlaIlustración12:

Componente Descripción

AmadeusRESTAPI Backend del sistema, desarrollado sobre Ruby on Rails con arquitecturaRESTyformatoderespuestaJSON.

PostgreSQL Sistemadegestióndebasesdedatosrelacionalorientadoaobjetos.

Herokuadd-ons Servidordebasededatos generadoporHeroku implementado sobreunsistemadeAmazonEC2.

ApachePuma ServidorwebligeroparaRubyonRails.

Herokudyno Implementación virtual de Linux capaz de albergar una instancia delsistema.

Herokuserver ServidorfísicodeHerokuimplementadosobreAmazonEC2concapacidadde512MBdeRAM.

Androidsmartphone Cualquier dispositivo Android que corra la versión API 16 (Jelly Bean) osuperior.

Amadeusapp AplicacióndeAmadeusdesarrolladaparasistemasAndroid.

Browser NavegadorwebcompatibleconHTML5yCSS3.

Pc Equipo con sistema operativo capaz de ejecutar un navegador webcompatible.(Pc,laptop,Mac,etc.)

Amadeus

ImplementacióndelfrontedquetendrálacapacidaddecomunicarseconlaAPI. Dicha implementación deberá contar con una referencia directa alarchivodeangular.jsparaagilizarsu funcionamientoygarantizarque loscomponentesesténsiempredisponibles.

43

AmazonEC2 AmazonEasyComputeCloud. Equipo virtual con sistemaoperativoLinuxdondesealojaráelfrontend.

AmazonES AmazonElasticSearch,indexadordelabasededatosdelaaplicaciónpararealizarbúsquedas.

AmazonS3 AmazonSimpleStorageService.Permitealmacenarlosarchivosdeusuariostalescomofotosyvideos.

Amazonserver Servidor de Amazon que actúa de hosting para todas las instancias deAmazonutilizadasparaesteproyecto.

Tabla2-Componentesdeldiagramadedespliegue

Paratodalacomunicación“puntoapunto”entredistintosnodosfísicosdelserviciosedestacalautilizacióndelprotocoloHTTPS(delInglésHypertextTransferProtocolSecure)basadoenelprotocoloHTTP,destinadoalatransferenciaseguradedatos.ElmismoutilizauncifradoparacrearuncanalseguromásapropiadoparaeltráficodeinformaciónsensiblequeelprotocoloHTTP[41].Decisionesdediseño

• AmazonSimpleStorageServicePara el manejo de archivos multimedia fue necesario desarrollar una solución dealmacenamiento que permitiese agilizar las respuestas del servidor, evitando tener querecurriracostososaccesosabasededatosysincontarconelcostoasociadodealmacenardichosarchivos.ParaelloseutilizaAmazonSimpleStorageService(AmazonS3),serviciodeAmazonquepermiteelalmacenamientodearchivosmultimediaalestilodeDropboxoGoogleDriveperoauncostomuchomásaccesible.Medianteunasimpleconfiguraciónenelservidoryutilizandolagemadecarrierwave [42]sefacilitauncampoconelcualsepuedeaccederfácilmentealdocumentoencuestión,permitiendoretornarcadaarchivocomootrorecursodelaAPI,esdeciratravésdeunaURL,comosepuedeapreciarenlaIlustración13.

Ilustración13-RespuestaJSONdelservidor

44

AmazonElasticsearchServiceAmazon Elasticsearch Service (Amazon ES) es un servicio gestionado que facilita laimplementación, el funcionamiento y el escaladodeElasticsearch en la nubedeAWS [3].Mediante el usodeElasticsearch se provee al sistema la capacidadde realizar búsquedassobreartistas,álbumesytemasenelsistema.AmazonEasyComputeCloudAmazonElasticComputeCloud(AmazonEC2)esunserviciowebqueproporcionacapacidadinformáticacontamañomodificableenlanube.Básicamentepermitecrearymantenerunservidorconcapacidadmodificableenfuncióndelasnecesidades,porejemploaumentarlaRAMdisponibleuoptarporunprocesadormásrápido.ConAmazonEC2secrearunservidordondesealojaráel frontenddeAmadeus,el cual será llamadoporunnavegadorparaserdesplegadoenlosdispositivosdelosclientes.PostgreSQLSistemadegestióndebasededatosrelacionalopensourceorientadoaobjetos,provistopordefectoenHerokuysimpledeadicionaraunsistemaRubyonRailsenproducción.Algunasdesusprincipalescaracterísticasson[43]:

• AltaconcurrenciaMedianteunsistemadenominadoMVCC(accesoconcurrentemultiversión,porsussiglaseninglés)PostgreSQLpermitequemientrasunprocesoescribeenunatabla,otrosaccedanalamismatablasinnecesidaddebloqueos.Cadausuarioobtieneunavisiónconsistentede loúltimoaloqueselehizocommit.Estaestrategiaessuperioralusodebloqueosportablaoporfilascomúnenotrasbases,eliminandolanecesidaddelusodebloqueosexplícitos.

• AmpliocatálogodetiposnativosPostgreSQLproveenativamentesoportepara:

• Númerosdeprecisiónarbitraria.• Textodelargoilimitado.• Figurasgeométricas.• DireccionesIP(IPv4eIPv6).• BloquesdedireccionesestiloCIDR.• DireccionesMAC.• Arrays.

45

4.4.2. VistademódulosAlutilizarestavistasepretendemostrarcómoserepartieronlasresponsabilidadesdentrodelosmódulosopaquetesdelsistema.Existeuncriteriodeagrupaciónquesetuvoencuentaduranteeldesarrollo:clasesquecompartenresponsabilidadesyquecambianpormotivossimilaresseagrupanjuntasbajoelmismopaquete(principiodeclausulacomún)[44].MódulosdelaaplicaciónAndroid

Ilustración14-DiagramademódulosdeAndroid

Acontinuaciónserealizaundesglosedetallado(verTabla3)deloscomponentesdescritosenlaIlustración14:

Componente Descripción

uy.com.amadeus.activitiesEste módulo agrupa las activities en Android. Cada activity Seencargan de desplegar todos los elementos de UI al usuario einteractuaryrecibiracciones.

uy.com.amadeus.fragmentsPaquetedeagrupacióndefragments.Unfragmentesunaseccióndeinterfazdeusuarioembebidadentrodeunaactividadanfitriona,lascualespermiteversatilidadyoptimizacióndediseño.

uy.com.amadeus.player Agrupa las clases encargadas del manejo del servicio dereproducciónasícomoelservicioensí.

uy.com.amadeus.persistance EstemóduloconcentralasclasesnecesariasparaproveeraAndroidconunsistemadebasededatos.

uy.com.amadeus.rest ClaseseinterfacesparahacerusoasincrónicodellamadasalservicioprovistoporlaAPI.

46

uy.com.amadeus.utils Agrupación de clases de uso común por todos los paquetes quepermitenreutilizarfuncionesyconstantesgenéricas.

uy.com.amadeus.entities Este paquete contiene las entidades que son utilizadas por lasactivitiesyserviciosdentrodelaaplicación.

uy.com.amadeus.adaptersSuprincipalresponsabilidadesfacilitarlalógicadepresentacióndelistasdedatosenlasactivitiesylareutilizacióndecomponentesenlaUI.

uy.com.amadeus.views Conjunto de clases visuales modificadas para adaptarse a esteproyectoygenerarunaUIdeterminada.

Tabla3-MódulosdeAndroid

MódulosdelaAPI

Ilustración15-DiagramademódulosAPI

Acontinuaciónserealizaundesglosedetallado(verTabla4)deloscomponentesdescritosenlaIlustración15:Componente Descripción

models Estemódulo agrupa todas las entidadesquedan formaal sistemaasí como susrelaciones.DentrodelpatrónMVCestemódulorepresentacomponentedeModel.

uploaders AgrupacióndeclasesresponsablesdemanejarlosarchivosdisponiblesenAmazonS3.

controllers Agrupalasclasesencargadasdelmanejodeentradadeusuarioyrespuesta.

session Dentrodeloscontroladoresestemódulocontienelosresponsablesdelmanejodesesiónparausuarios,asícomoregistroyvalidacióndecredenciales.

serializers ClasesresponsablesporlaconversióndelosdatosprovistosporelcontroladorenformatoJSON.

Tabla4-MódulosdeAndroid

47

4.4.3. VistalógicaEsta vista está enfocada en describir la estructura y funcionalidad del sistema desde laperspectiva de sus principales entidades y como se relacionan. Para ello se recurre a lautilizacióndeundiagramadeclases.

Ilustración16-Diagramadeclasesprincipales

EnlaIlustración16seaprecialaarquitecturainternadelservidordesdeunaperspectivadelasentidadesinvolucradasenlalógicadelsistema.

48

4.5. CriteriodeseleccióndelastecnologíasParaeldesarrollodelproyectoelequiposeplanteócomodesafíolautilizacióndetecnologíasquenohubiesensidoprovistasporlauniversidadenelcursodelacarrera.Comopuntodepartida lasmismas debían cumplir dos criterios: primero ser tecnologías gratuitas yopensource donde se pudiera conocer su implementación y posiblemente extender sufuncionalidad,ysegundocontarconunampliosoportedelacomunidadasegurandosiempredisponibilidad de información y recursos prácticos. Otros aspectos tenidos en cuenta alseleccionarherramientasdedesarrollofueronlacurvadeaprendizajeylaperformance.Como se pretenden implementar tres soluciones independientes que se comuniquenmedianteunlenguajeencomúnparacadaplataformasedeberátenerencuentasuspropiasnecesidades:CriteriosparaseleccióndedesarrollowebSebuscadesarrollarunaaplicaciónSPA[45]quepermitaunaexperienciafluidayseasemejemás a una aplicación nativa que las páginas web tradicionales. También se desea quemantengaunformatoresponsivoantedistintasresolucionesdepantallapermitiendoquesuutilizaciónnoselimiteaPCsylaptopssinoquepuedaaccederseporejemplodesdetablets.Para este producto de software se decidió utilizar AngularJS [46], framework MVC deJavaScriptparaeldesarrollowebfrontendycuyaprincipalcaracterísticaessuutilizaciónparacrearSPA.AngularJSestáconstruidoentornoalacreenciadequelaprogramacióndeclarativaeslaquedebe utilizarse para generar interfaces de usuario y enlazar componentes de software,mientrasquelaprogramaciónimperativaesexcelenteparaexpresarlalógicadenegocio[46].EsteframeworkadaptayamplíaelHTMLtradicionalparaservirmejorcontenidodinámicoatravés de un data binding o enlace de datos bidireccional que permite la sincronizaciónautomática de modelos y vistas. Como resultado, AngularJS pone menos énfasis en lamanipulacióndelDOM(delInglésDocumentObjectModel)ymásenmejoralatesteabilidadyelrendimiento.CriteriosparaseleccióndedesarrollodelbackendDebidoaqueesel centro lógicodel sistemasebuscaqueseade fácildesarrollo,permitaextender su funcionalidadmediante el uso de librerías o similares y su interconexión consistemasdebasededatosseasencillo.Paramantener lasopcionesdehostingabiertassedecidióademásquefueseunlenguajemultiplataformacapazdeserdesplegadoencualquiersistemaoperativodeformafácilyrápidacomoseexplicóanteriormenteenestecapítulo.ParabrindarestasoluciónsedecidiódesarrollarlaAPIconlaayudadeRubyonRails.RubyonRails[47]esunframeworkdeaplicacioneswebdecódigoabiertoescritoporDavidHeinemeier Hansson en el lenguaje de programación Ruby, siguiendo el paradigma de laarquitecturaMVC,elcualsedetallarámásadelanteenestecapítulo.RailsadmiteextensionesasusfuncionalidadesbásicasatravésdelusodegemasyademáscuentaconActiveSupport,

49

colecciónútildeclasesyextensionesquefacilitaneltrabajoconbasesdedatos(ActiveRecord,ORMtradicionaldeRails)yenvíosdemail,porejemplo.CriteriodeselecciónparadesarrolloAndroidPara desarrollar la aplicación nativa de Android se busca brindar una experiencia nativautilizandolosprincipiosdeMaterialDesign [21].SibienexistenmuchasopcionesgratuitasparadesarrollaraplicacionesAndroidnativasJavaeslaopciónpordefecto.

4.5.1. HerramientasdedesarrolloBuscandooptimizareltiempoylasimplicidaddeltrabajoserecurrealautilizacióndetresambientesdedesarrollointegrado(IDEporsussiglasenInglés):

• RubyMine:desarrollodelaAPIconRubyonRails.• WebStorm:desarrollodelfrontendwebconAngularJS.• AndroidStudio:desarrollodelfrontendAndroid.

EstostresentornosdedesarrolloestánbasadosenelsoftwareIntelliJIDEAdeJetBrains,porlo cual todos cuentan con interfaces y funcionalidades similares, facilitando al equipo elintercambiodeexperiencias.

50

5. GestióndelproyectoEnestecapítulosedescribeelciclodevida,elmodelodeciclodevida,losprocesosempleadosparalagestióndelproyectoylasherramientasutilizadasparalaimplementacióndedichosprocesos.ElPMI(delInglésProjectManagementInstitute)exponenueveáreasdelconocimientodentrodelagestióndeproyectos,portratarsedeunproyectoacadémicoseoptóporaplicarseis:gestión del alcance, gestión del tiempo, gestión de la comunicación, gestión de riesgos,gestióndelacalidadygestióndelaconfiguración[48].

5.1. CiclodevidaymodelodeciclodevidaEl modelo de ciclo de vida utilizado en el proyecto es el iterativo evolutivo ya que es elparadigmaquemejorseadaptaalproyectodebidoaquesetratadeunproyectodecarácterinnovador.Losrequerimientosdelproyectosoncambiantesporloqueseoptóaplicarunciclodevidaqueseadaptefácilmenteaestoscambios,aprovechandoasíunadelascaracterísticasdelosciclosevolutivos(losrequerimientosseconocenamedidaqueavanzaelproyecto).Otrofactordecisivoenlaelecciónfuequelosriesgostecnológicossonaltos,demaneraqueseoptóporestemodeloquetienecomoventajadisminuirdichosriesgos, lograndoqueelequipo adquiera mayor conocimiento de las tecnologías utilizadas en cada iteración delespiral.Porúltimopermiteobtenerresultadosvisiblesyfeedbackdelclienteentiempodedesarrollolocualevitacostososcambiosalfinaldelproducto,ademásdepermitirconocerelprogresodesde las primeras iteraciones para sí poder lograr unamejor alineación a los tiempos yobjetivosplanificados(verIlustración17).

Ilustración17-Modelodeciclodevida

51

5.2. MetodologíadetrabajoLuego de analizar las características del proyecto el equipo decidió aplicar metodologíaságiles,perodebidoaquelascondicionesdelequipo(disponibilidad,experiencia,espacio,etc.)noeranexactamentelasidealesparaScrumpuroseoptóporutilizarunaadaptacióndequese acomodaramejor al proyecto [5]. Otra técnica que resultó muy efectiva a la hora dedesarrollarfue laprogramacióndeapares,provenientedeotrametodologíaágilconocidacomoXP (del InglésExtremeProgramming) [49].Dicha técnica sostieneque las tareas dedesarrollollevadasacabopordospersonasenunmismopuestoproducencódigodemayorcalidad,yaqueesteesrevisadoydiscutidodurantesuescritura.Laprimercaracterísticadeesteproyectoespoderintroducircambiosenlosrequerimientossin generar un gran impacto, siendo las metodologías ágiles ideales para cumplir esterequisito.Encadaiteraciónsepuedeirgenerandofeedbackqueretroalimentealproductoygenerenuevosrequerimientos.Dadoqueelequipoestáformadoportrespersonasytantoelclientecomolatutoratienenaltadisponibilidadseconsideralacomunicación“caraacara”comoelprincipalcanal,siendoestasmetodologíaslasquemejorseadaptanyaquesostienequeeselmétodomásefectivoyeficientedecomunicación.Teniendoencuentalacantidadderiesgosencontradosenelproyectoysobretodoporlosaltos riesgos tecnológicos que se decidió asumir, la utilización de Scrum es ideal ya quepermitemitigarlosdesdelasprimerasiteraciones.Estosedebeaqueelequipoencadasprintdecidequérequisitosdesarrollar,estadecisiónsetomasegún lacomplejidadyriesgoqueimplicaimplementarlopudiendoasípriorizarlosquecuentenconmayorcomplejidadyriesgo,afrontandolosmismosenetapastempranas.Porúltimosebuscóobtenerunentregablequecumplieraconlosrequerimientosprincipalesdentrodelplazo.EstollevóalautilizacióndemetodologíaságilesquepermitiesencomenzareldesarrolloloantesposibleydentrodeestasseoptóporScrum,yaqueelequipocontabaconlosconocimientosteóricosyteníaexperienciaacadémicaenelusodeesta.

5.3. AdaptacióndeScrumalproyectoComo se mencionó con anterioridad en este capítulo las características cambiantes delproyectojuntoaladisponibilidaddehorariosyespacioencomúnllevaronaquelaaplicaciónde Scrum tuviese que ser adaptada a las necesidades particulares de este, utilizando unsubconjuntode sus artefactos, yno sepudieseaplicar en su formapura. Porotro lado lanecesidaddedesarrollardocumentaciónentregableycondeterminadoformatoestablecidaporlaUniversidadllevaaunacontradiccióndelmanifiestoágildondesefavoreceeldesarrollosobreladocumentaciónextensiva[50].Acontinuaciónsedescribenloselementossugeridosporlametodologíaysifueronutilizadosduranteelproyecto.

52

• RolesProductOwner.EsterolseasignóaAlejandroZorrillamúsicoycompositoruruguayohoydíaerradicadoenlosEstadosUnidos(vercapítuloElequipoyroles).Sibienexistenunadiferenciahorariadeaproximadamente2horasyunadistanciaconsiderable,elproductownertieneunaalta disponibilidad para trabajar en el proyecto. Sumado a su amplio conocimiento yexperienciaenelnegociodelamúsicatantoanivellocalcomointernacionalademásdeunsincero interésesdesarrollarAmadeusesqueAlejandroZorrillaes idealparaasumirelrolcomoproductowner.ScrumMaster.EsterolfueasignadoaAlexisZucco.Eselencargadodecoordinarlasreunionesdelequipo,dirigirlasmismasyvelarquelosparticipantessiganlasreglasyvaloresdeScrum.Sumisiónesguiarlacolaboraciónentreparesdelequipo,yconelproductownerdemaneraquelassinergiasseanmáximas.Equipo.EstáformadoporNicolásMañay,JuanDiegoMéndez,AlexisZucco.Apesardequelosmiembrostienenlasimilarformaciónacadémicayexperienciaendesarrollo,cadaunoseespecializoenunaovariasáreasconelfindelograrunequipomultidisciplinario.Mediantelaautoasignacióndetareasyrolesesquetodoslosintegrantestrabajandeformamáscómodayproductiva.

• CeremoniasAcontinuaciónsedetallanlasceremoniasdeScrumutilizadasduranteelproyecto.Sprintplanningmeeting.Participantodoslosmiembrosdelequipoysuobjetivoesplanificareltrabajoqueserárealizadoenelsprint.Unavezcompletadalareuniónsetienequepodercontestarlassiguientespreguntas:• ¿Quésecompletaraduranteelsprint?• ¿Cómosecompletaraeltrabajoseleccionado?Dailymeetings. Participan todos losmiembros del equipo, su duración es de 15minutosaproximadamente,suobjetivoescrearunplandeloqueserealizaraesedíaysincronizareltrabajo. Para lograr esto cada uno de los participantes debe responder las siguientespreguntas:• ¿Quésehizodesdelaúltimareunión?• ¿Quéseharáantesdelapróximareunión?• ¿Existealgúnobstáculoqueesteentucamino?Sprintreview.Serealizaunavezacabadoelsprintyparticipanelequipoyelproductowner.Sebuscamostrar loalcanzadoenelsprint yobtener feedbackdel clientesobreel trabajorealizado.

53

Sprintretrospective.Participatodoelequipoysuobjetivoesanalizarloquesehizobienyloquenoduranteelsprintparapodermejorarenpróximasiteraciones.

• ArtefactosAcontinuaciónsedetallanlosartefactosdeScrumutilizadosduranteelproyecto.Product backlog. Es la lista priorizada de requerimientos que representa la visión yexpectativasdelproductownerrespectoalosobjetivosyentregardelproducto.Elproductbacklogserepriorizaalcomienzodecadasprintenbasealosrequerimientoscambiantesdelproducto que se construye. Para este artefacto se utilizó la herramienta onlineTrillo [25]dondesesimulaunscrumboard (ver Ilustración18)alquetodoslosmiembrosdelequipotienenacceso.

Ilustración18-ScrumboardparaproyectoAmadeusenTrello.com

Sprintbacklog.Listadetareasarealizarduranteelsprintseleccionadasdelproductbacklog.EnlaIlustración18seaprecianlossprintbacklogsparalossprint1y2deizquierdaaderecharespectivamente.Burndownchart.Herramientaeficazparadeterminar siel trabajoseráculminadopara lafechaprevista.Paraelproyectoseutilizaron2tiposdeburndowncharts,unoporsprint(sprintburndown chart [cantidad de story points por sprint]) y otro por el producto (releaseburndownchart[storypointsdesarrolladosdeltotal]).

54

5.4. EtapasdelprocesoScrumScrumesunametodologíaquesebasaenunciclodevida iterativo,cuyas iteracionessonllamadassprints.Laduracióndeestospuedellevarde2a4semanas(verIlustración19);paraeste proyecto se decidió realizar sprints de 4 semanas de duración con el objetivo dedesarrollarfuncionalidadescompletasparamostraralproductowneryalinearlafinalizacióndeunsprintmensualmente,buscandofacilitarelseguimientodelproyecto.

Ilustración19-MetodologíaScrum:etapas,ceremoniasyartefactos[51]

PlanificacióndelsprintComosemencionaalcomienzodelcapítulosedecidiórealizarsprintsde4semanas,estosdebencomenzarconunareuniónpresencialdeplanificaciónllamadasprintplanningmeetingenlacualparticipantodoslosmiembrosdelequipo.A lo largo del proyecto fueron apareciendo nuevos requerimientos, elproduct owner fuecambiandolasprioridadesyelequipofueadquiriendomayorconocimientodelproblemaydelastecnologíasutilizadasteniendoquevolveraestimarypriorizarelproductbacklog.Estasactividadessonrealizadasalcomienzodelareunióndeplanificación,dondeseanalizajuntoal product owner el product backlog en busca de las funcionalidades pendientes porimplementaryseestudiasuprioridadencontraposiciónalasdemásuserstories.Unavezfinalizadalaevolucióndelproductbacklogsedecidequefuncionalidadessevanadesarrollarduranteelpróximosprint,eligiendolasquesesitúanmásarribasegúnsuprioridadyduraciónestimada,ysehaceunanálisisdelosposiblesriesgosparaelsprint.VerAnexo6amododeejemplodocumentosdelsprintplanningmeeting1y2.SeguimientodelsprintParael controldeseguimientoScrumpropone la realizaciónde laceremoniadenominadaDailymeeting.Comosedescribióanteriormentedentrodeestecapítulo,ladailymeetinges

55

unareuniónpresencialdeaproximadamente15minutosdeduraciónenlacualcadaunodelosintegrantesdelequipodeberesponder3preguntas.El objetivo de estas reuniones es conocer el estado actual del proyecto a través de lasrespuestasde los integrantes, facilitandoasuvezqueel restoconozca lasituacióndesusparesyestableciendoposiblesinstanciasdeayudamutua,permitiendocrearunplandeloquesevarealizaresedíayllevarunseguimientodelasactividadesquerealizacadamiembrodelequipoduranteeltranscursodelsprint.Debidoadiferentesdisponibilidadeshorariasdelosintegrantesdelequipoestasreunionesno se realizaron diariamente como se había planificado inicialmente. Las mismas fueronrealizadas unmínimo 2 veces por semana priorizando siempre la facultad como lugar deencuentro,apesardeestoenocasionessetuvoquerecurriralencuentrovirtualporSkype.CierredelsprintAl finalizarcadasprint se realizauna reunión llamadasprint reviewen lacualelequipo leenseñaalproductownerlosavancesobtenidos,seinformadelastareasnoculminadasysusmotivos.Analizandoloanteriorsedeterminasisecumplióconlosobjetivosplanificadosparaelsprint.Enlasprimerasiteracionesnofueposiblemostrarunavanceperceptiblealproductowneryaqueeldesarrollonoeravisibleparaeste,sinoqueeranprogresosaniveldeinfraestructuraydelmanejodecomunicaciónydatos.Alcerrarelsprinttambiénserealizalaceremoniasprintretrospectivedondelosintegrantesdelequipoanalizanlorealizadoenlaiteraciónanterior,tantolosaspectospositivoscomolosnegativosdemaneradeidentificaroportunidadesdemejoraparalospróximosSprint.

5.5. ConclusionesdelagestióndeproyectoLametodologíaScrumbrindóalequipolasherramientasnecesariasparaalinearsusobjetivosconenelprocesodedesarrollodelproyecto,permitiendoobteneryanalizarlosdesvíosquesurgíanmediantelosresultadosdesusceremonias.Las iteraciones de Scrum así como las ceremonias de sprint retrospective fueronretroalimentandoalequipoconexperienciayaprendizajedelasactividadesrealizadasenelprocesodedesarrolloasícomotambiénenlastecnologíasutilizadas.Estogenerómejorasenlastareasqueserealizabaniteraciónaiteraciónyenlostiemposdedesarrollo.Elmayordesafíoconqueelequiposeencontrófuelaestimacióndelastareasplanificadasparacadasprint,lascualesllevaronmástrabajodeloquesehabíatenidoencuentaenunprincipio.Estosedebealassiguientesrazones:

56

• El equipo no contaba con experiencia en proyectos de similar magnitud ycaracterísticas. La experiencia conque contabaeraprincipalmenteacadémica ydeproyectosdecortaduración.

• Elusodetecnologíasnuevasparaelequipo.Apesardequeserealizóunainvestigaciónyunestudiodecadaunaantesdecomenzareldesarrollo,enmuchasocasionesnofuesuficiente haciendo que en algunas tareas se necesitara más tiempo dedicado ainvestigación.

Amedidaqueavanzabanlossprintslaestimaciónfuemejorandoresultandosermásprecisa.Sibienseoptóporelusodesprintsdelargaduración(4semanasenlugardelas2semanastradiciones) de forma de obtener unamayor cantidad de requerimientos paramostrar alproduct owner en algunos casos fue contraproducente ya que se sobrecargó a este defuncionalidades a evaluar. Además el equipo comprendió la importancia del feedbackproporcionadoporelproductownerycomopierdeniveldedetalleestaalagruparsedentrodeungrupodeotrosfeedbacksdefuncionalidadesevaluadas.Sumadotodoestoelequipoconcluyequeiteracionesmáscortasparaproyectosdeestascaracterísticashubiesensidomásenriquecedoras.A lo largodelproyectoel equipo realizó las ceremoniasdeScrum que sedetallananteriormenteenestecapítulo,tantodeformapresencialcomodeformavirtual,concluyendoque laspresencialesen sumayoría fueronmásproductivasdebidoaque losparticipantesfueronmáspropensosinteractuarycompartirmaterialvisual.Duranteeldesarrollodelproductosebuscópriorizarelusodelatécnicadeprogramacióndea pares, con la convicción de que esto generaría código más claro y reusable. Debido adificultades para organizar reuniones presenciales esta técnica quedó rezagada pero secomprobósueficienciaanteunestilodeprogramaciónmástradicional.EnsíntesislametodologíaScrumfavoreciólacomunicacióndentrodelequipo,eldesarrollodeunproductoqueseajustamejoralasrecomendacionesdelproductownerylagestióndeunproyectodondesedesconocíacompletamenteelalcancefinal.ComodesventajaelequipoconcuerdaenqueScrumnofavorecelasinstanciasparaeldesarrollodedocumentacióncomoclaramenteloespecificaelmanifiestoágil[50],loqueocasionadificultadparaadaptaresteartefactodentrodeunagestiónconScrum.

57

6. Gestióndelalcance

6.1. IntroducciónCuando se hace referencia al alcance es necesario distinguir si se trata del alcance delproductoodelproyecto,yaqueusualmentesondosconceptosquesuelenserconfundidos.Porunladoelalcancedelproductoserefierealascaracterísticasyfuncionesdelproductooservicioquedesarrolla.Porotro ladoel alcancedelproyecto consisteendefinir todos losprocesosyeltrabajonecesarioparaqueelproductoseaprovistocontodaslascaracterísticasyfuncionesrequeridas[26].Enestecapítulosedetallarálagestióndelproyecto.

6.2. GestiónMediantelagestióndelalcanceelequipodefinióycontrolótodoeltrabajorequeridoparacompletar el proyecto con éxito. Se establecieron los siguientes cinco procesos: recopilarrequisitos,definiralcance,crearlaEstructuradelDesglosedeTrabajo(EDTporsussiglasenInglés) y validar/controlar el alcance. Estos procesos son definidos como básicos segúnPMBOK (del Inglés ProjectManagement Body of Knowledge) [48] si se quiere lograr unagestiónexitosadelalcance.A continuación se detallan los procesos ejecutados para la gestión del alcance de esteproyecto:

6.3. RecopilaciónderequisitosRecopilarrequisitosconsisteendefinirydocumentarlasnecesidadesdelosstakeholdersparapoder cumplir con los objetivos del proyecto [48]. Los requisitos incluyen desde lasnecesidades hasta los deseos y expectativas cuantificadas y documentadas de todos losinteresados.Enbase a los requisitos se construirán laEDT, el cronogramay la calidad se efectuara enfuncióndeellos.Paraelanálisisdelosrequerimientossedistinguióentrerequerimientosdelproyectoyrequerimientosdelproducto.Seutilizaronlassiguientesherramientasconelfinderecopilarinformaciónparapoderdefinirydocumentartodoslosrequerimientos.

• Encuestademercado.Serealizóunaencuestaorientadaaposiblesclientesconelfindeconocerlaexistenciadeproblemasquetienelosartistaparaalcanzarciertogradodeéxitoyhallarnecesidades.VerAnexo3

• Entrevistas. Se mantuvieron entrevistas con los distintos interesados donde sedescubrieronnecesidadesypuntosnegativosdelproyecto.

• Internet. Se obtuvo documentación de interés sobre el negocio de la música y latecnologíaquenosayudóalaconstruccióndelproyecto.

Paraespecificarlosrequerimientosseutilizólatécnicadeuserstories(vercapítuloIngenieríaderequerimientos)provenientedelametodologíaScrum.

58

6.4. DefinicióndelalcanceElalcancedefinidoconsisteenlaimplementacióndeunprototipofuncionaldondelosartistaspuedanexponersumaterialytantoestoscomolosseguidorespuedancompartirideas,gustosyopiniones.ElprototipoestáformadoporunaaplicaciónmóvilparacelularesconsistemaoperativoAndroidyunaaplicaciónweb,ambosconsumiránunaAPIdesplegadaenlanube.Quedaexcluidodelalcancecomoestrategiadenegociolafuncionalidadesdeloslocaleshastanotenerelvolumendecontenidonecesarioparaqueestosobtenganutilidaddelaaplicación.Tambiénquedafueradealcanceelchat,sentimentanalysisdecomentariosyelstreamingenvivo de video por falta de tiempo, ya que al analizar dichas funcionalidades se llegó laconclusióndequeunacorrectaimplementaciónhabríaimplicadoeldesarrollodeservidoresdedicadosparacadaservicio.Unavezqueserecopilanlosrequerimientoslosmismossedefinenenentregablesclarosqueseutilizancomoentradaenelsiguienteprocesodelagestióndelalcance.

6.5. CreacióndelEDTEsteprocesoconsisteensubdividirentregablesdelproyectoencomponentesmáspequeñosyfácilesdemanejar[48](verIlustración20).LaEDTresultanteesunaestructurasimilaraunorganigramajerárquicocuyaestructuranoreflejanecesariamenteunordencronológicoenlasecuenciadedesarrolloydonde losniveles inferioresuhojassedenominan“paquetesdetrabajo”,loscualesconceptualmentedeberíanpoderestimarseconprecisión[26].

59

Ilustración20-EDTdelproyecto

60

6.6. ValidacióndelalcanceLa validación del alcance consiste en asegurar sistemáticamente que cada entregablepropuestoenlaEDTseestácompletandodeformaadecuada[26].Elprocesodevalidaciónsefuerealizandomediantereunionesconlatutorayelproductownerdemaneradeasegurarque losentregableselproyecto lograrasatisfacer losestándaresestablecidos(porejemplocumpliesenlasnormasdeldocumento302[7]).

6.7. ControldelalcanceEl control del alcance es unproceso cuyoobjetivo es responder a la pregunta “¿Se estánrealizando todos los entregables definidos en elEDT?” [26]. Este se realizó a lo largo delproyecto ya que debido a diferentes acontecimientos se vio la necesidad de realizarmodificaciones a lo largo del tiempo. A modo de ejemplo se destacan algunos de losacontecimientosmásimportantescomolainexperienciaenestimacióndetareasgenerandoatrasos según lo planificado, dificultad en el aprendizaje de las tecnologías utilizadas ydisminucióndeladisponibilidadhorariadeunodelosintegrantes.Todos los cambios fueron introducidos en la línea base del alcance del proyecto y delproducto. Los cambios se validaron previamente con la tutora según correspondiera y segestionaronsiguiendoelplandecontroldecambiosestablecidoenelcapítulodeGestióndelaconfiguración.

6.8. ConclusionesyleccionesaprendidasDebidoalagrancantidadrequerimientosquefueronsurgiendoalolargodelproyecto,tantode entrevistas con los stakeholders como generados internamente por el equipo, fuenecesario aplicar una gestión del alcance rigurosa que permitiese asegurar una metamanejableyrealistadelproyecto,evitandofrustracionesalfinalizarelperiodoestipuladodeunaño.Debidoalamaterializacióndealgunosriesgosplanificadosduranteeltranscursodelproyecto,se tuvo que introducir cambios en la definición del alcance inicial, siendo necesario laeliminacióndeunconjuntodefuncionalidadesdelproducto.Alahoradeseleccionarcualesseríanimplementadasseoptópordesarrollaraquellasqueaportasenunvalorcomprobablealaplataforma,comoporejemploaquellasfuncionalidadesqueseencuentranpresentesenotrossistemascontempladosenelbenchmarking(vercapítuloIngenieríaderequerimientos),así como una priorización de los aspectos arquitectónicos y los atributos de calidad. Sinembargotodoslasfuncionalidadesdefinidasfueroninvestigadasytenidasencuenta.Todolomencionadoanteriormentegeneróconcienciaenelequipodelaimportanciadelagestióndelalcance,yaquedenohabersidorealizadacorrectamentehubieseaumentadoelriesgodenoterminarunproductofuncionalatiempo.

61

7. Gestióndeltiempo

7.1. IntroducciónParaunacorrectagestióndeltiempoelPMBOK[48]definelossiguientesproceso:

• Planificacióndelcronograma:Desarrollarydefinirlasetapasdelproyecto.• Definicióndeactividades: Identificar cadaunade lasactividadesnecesariasparael

desarrolloéxitosdelproyecto.• Secuenciarlasactividadesdefinidas:Definirlasdependenciastemporalesasícomola

relacióndetiempodelasactividadesdescritas.• Estimaciónderecursosparacadaactividad:Asignaciónderecursosdisponiblesacada

actividaddefinida(“¿Quiéndebehacerquécosa?”).• Desarrollo del cronograma: Analizar la integración existente entre recursos,

actividades,dependenciastemporales,etc.• Controldelcronograma:Administrarlalíneabasedelcronograma.

Alaplicarunametodologíaágilseaceptalaideabásicadefavorecerdesarrolloyrespuestasantecambiossobredocumentaciónyseguimientodeplanes,porloqueuncontrolestrictodelcronogramainvalidaríaparcialmentelametodologíaelegidaporelequipo.Esasíqueparaesteproyectosedefineuncronogramadealtoniveljuntoconsusactividadesmásdestacablessin llegaraunniveldedetalledondesepueda lograrunestimaciónprecisaderecursosotareas.

7.2. CronogramaUn proyecto es una planificación que consiste en un conjunto de actividades que seencuentraninterrelacionadasycoordinadas.Elobjetivodeunproyectoesalcanzarlasmetasespecificadasdentrodeloslímitesqueimponenunpresupuesto,calidadesestablecidasyunlapso de tiempo predefinido [26]. Para la realización de este proyecto se cuenta con unaduraciónaproximadade10meses,comenzandoa finalesdeabrilde2015yterminandoaprincipiosdemarzode2016,parael cual se impusouncronogramaquedefineagrandesrasgos lasprincipalesetapasquedebenserseguidascomoseespecificaanteriormenteenestecapítulo.

7.2.1. FaseI,planificaciónEl proyecto comienza el día 20de abril de 2015 con la aceptación formal por parte de laUniversidaddelproyectoAmadeus,propuestoporelequipoduranteeltranscursodeltalleremprendedor. Durante esta etapa el equipo comenzó a analizar las características delproyectoasícomocuálesseránlosmayoresriesgosinvolucradoseneltranscursodelmismoysusactividadesprincipales,iniciandoasílaplanificacióndeuncronogramatentativo.

62

Estaprimerafase(verIlustración21)cuentainicialmenteconunaduraciónprestablecidade45díasenloscualessedefiniránlosprincipalesplanesquepermitiránasegurarelcorrectodesarrollodelproyecto.Comoresultadoseesperauncronogramadealtonivelquedefinaagrandesrasgoslasetapasdelproyectoasícomoplanesdecomunicación,SCMySQAentreotros.

Ilustración21-FaseIjuntoasusprincipalesactividades

7.2.2. FaseII,diseño

Lafasedediseño(verIlustración22)cuentainicialmenteconunaduraciónpreestablecidade60díasyconsisteeneliniciodeldesarrollodeunasolución,comenzandoporelanálisisdelproblemaylosrequerimientosdelsistema,finalizandoconunaarquitecturaclara,habiendomitigadoposiblesproblemasdeimplementaciónquefuesensurgiendo.Estafaseoetapaesde vital importancia ya que se da comienzo formal a la capacitación del equipo en lastecnologías seleccionadas, actividad que se prolongará durante toda la extensión delproyecto.Duranteeltranscursodeestafaselaprototipaciónasícomoeldiseñodelainterfazgráficasonherramientasfundamentalesquepermitirándesarrollarunprimeracercamientoconlasoluciónfinal.Enparticular implementarminisolucionesaproblemasdetectados facilitaráunamitigaciónderiesgostecnológicosenlaetapadedesarrolloposterior.

63

Ilustración22-FaseIIjuntoasusprincipalesactividades

7.2.3. FaseIII,ejecución

Enlafasedeejecución(verIlustración23)sedacomienzoaldesarrollodelproductoaplicandoelconceptodesprintprovenientedeScrum,dondeseestableceunaduraciónde4semanaspor cadasprint. Sibienelénfasisduranteesta fasees la implementacióndelproducto, ladocumentaciónyseguimientodelosplanesdesarrolladosen las fase anteriores siguensiendoderelevancia.Inicialmenteestafasecuentaconunaduraciónpreestablecidade180díasaproximadamente.

Ilustración23-FaseIIjuntoasusprincipalesactividades

7.2.4. FaseIV,cierre

Elobjetivoprincipaldeestaetapadecierre(verIlustración24)esdarleunterminaciónformalalproyecto,realizandocambiosenladocumentacióncomotambiéncorregirposiblesfallosyaplicarrefactoringalcódigogenerado.Otraactividaddestacableeselanálisisdelasleccionesaprendidasduranteelproyectoasícomodelosdatosobtenidosdemétricasygráficosconelfindeplasmarloseneldocumentofinalydiscutirloscomoequipoparasaberquesepudohacermejorycomo.Inicialmenteestafasecuentaconunaduraciónestimadade30días.

Ilustración24-FaseIVjuntoasusprincipalesactividades

64

7.2.5. ActividadesdecontrolLasactividadesdecontrolcomienzanenlaprimerafaseyseextiendenalolargodetodoelciclo de vida del proyecto, buscando siempre garantizar la correcta gestión del proyecto.Comoseexplicaalcomienzodeestacapítulolasactividadesdecontrolsebasanúnicamenteenunseguimientotemporaldelasdistintasfasesestablecidasparaelproyecto,deformadedetectarposiblesdesvíosoretrasos.

7.3. AplicaciónyherramientasLas horas trabajadas por cada integrante durante el transcurso del proyecto fueronregistradasdesdeelinicio,conelobjetivodellevaruncontroldelesfuerzorealizadoasícomotambiénparautilizarseenlamejorardelasestimacionesdecadasprint.ComoherramientaprincipalderegistroseutilizóExcel,dondesedefinióunaplanillacontodaslas fechas programadas de trabajo. Las horas eran ingresadas manualmente por cadaintegrante calculando lasmismas restando simplemente lahora inicio yde finde la tarearealizada.Paralograrregistrosmásexactosseacordóentrelosmiembrosdelequipoutilizarun cronómetro para medir el tiempo insumido aplicando un híbrido de la metodologíaPomodoro[52].Endichaprácticacadaintegrantedelequipoutilizauncronometroestándarpreconfiguradoconuntiemponomayora60minutos,loscualesutilizaráparadesarrollarsus actividades. Pasados los 60 minutos se concluye un “tiempo” o “Pomodoro” en sudefinición y tomará un descanso de 5minutos, a los que posteriormente le seguirá otro“tiempo”.Previamenteseacordódedicarunpromediode3horasdiariasaldesarrollodelproyecto,por loque concluidos3 “tiempos” se finalizaráel trabajodiario.Al aumentar lacantidadde“tiempos”seagregaunpausaextendidade20minutoscada3períodos.

7.4. ConclusionesyleccionesaprendidasUnode losprincipalesproblemassurgeporelusodeExcelcomoherramientaprimariadegestióndeltiempo,debidoaquelacargadeberealizarsedeformamanualgenerandoolvidosy registros inexactos. Si bien la metodología Pomodoro resulta altamente efectiva, esnecesario recordar las pausas y reanudacionesdel cronómetro constantemente loquenoevita faltas en la precisión de los registros. Para fututos proyectos se estudiaría algunatecnologíaquepermitaelregistrodehorasdeformaautomática.Tambiénseríadeutilidadimplementar alguna táctica que permitiese medir la eficiencia en el insumo de horas,permitiendoconocerconexactitudcuántashorasnetassededicaaldesarrolloensí.Lautilizacióndeuncronogramaapesardeutilizarunametodologíaágilpermitióalequipoconocersusituaciónentodomomentodelproyecto,detectandocuandosurgíaundesvióenlarutaprogramadayfacilitandolatomadedecisionesenbasealosmismos.Debidoalafaltade detalle en las estimaciones de horas insumidas por actividad dentro de cada fase fueimposibledeterminarconexactitudcualesfueronlasculpablesdeocasionarretrasosen lalínea base del proyecto, por lo que se llega a la conclusión de que a pesar de seguir unametodologíaágil invertirmayortiempoenlaelaboracióndeuncronogramamásdetallado

65

hubiesesidounfactorfavorableparalagestióngeneralycomoherramientadefeedbackparafuturosproyectos.Lasfasesdefinidasparaesteproyectosondecaráctergeneral(aplicableacualquierproyecto)y su asignación horaria se basa en la relación esfuerzo-tiempo que un proyecto estándardebiesecumplir[26],comosepuedeapreciarenlaIlustración25.

Ilustración25-Curvadeesfuerzoaplicadoenfuncióndeltiempo

ParaesteproyectolafaseinicialdelaIlustración25hacereferenciaalafaseIdeplanificacióndondeeltiempoplanificadoesde45días,óseaaproximadamenteun14%deltotal.LafaseintermediaesdondeseacomodanlasfasesIIyIIIdelcronogramadesarrolladoparaAmadeus,lascualestienenunacargahorariade60y180horasrespectivamente,representadoasíun19%deltiempoenlafasedediseñoycercadeun57%deltiempoenlafasedeejecución.Estadivisión temporalpermitióunesfuerzoacordepara cadaetapadelproyecto facilitando latareabásicasdelcontroldelcronograma.

66

8. GestióndelacomunicaciónEn esta sección se describe los diferentes mecanismos utilizados para lograr facilitar lacomunicaciónentrelosdiferentesmiembrosdelequipoylasdiferentesstakeholdersexternosalproyecto.Identificacióndelosinteresados

• HelenaGarbarino–Tutor• AlexisZucco–Equipodedesarrollo• JuanMéndez–Equipodedesarrollo• NicolásMañay–Equipodedesarrollo• AlejandroZorrilla–Expertodeláreayproductowner

8.1. Comunicacióninternadelequipo

Para la comunicaciónentre losmiembrosdelequipo seutilizarondiferentesherramientasparaelintercambiodecomunicacióncomoGmail,IMessage,WhatsappySkypepermitiendouna comunicación fluida y continua en todo momento. Para el desarrollo de todas lasreuniones no presenciales se utilizó Skype, herramienta que permite compartir archivos,realizar conversaciones de chat y videoconferencia con múltiples integrantes de formasimultánea.Encuantoalasreunionespresenciales,enetapastempranasdelproyectosedecidiócoordinarpararealizarlasconunafrecuenciaaproximadadeunasemanaymediaydeunaadoshorasde duración, dependiendo de las actividades a realizar. Amedida que el proyecto pasó aetapasmásavanzadasseaumentaronlafrecuenciadelasreunionesconelequipoyconlatutora.Serealizarondedosatresvecesporsemanaperomanteniendoeltiempoaproximadodelasmismas.Paraelfindelproyectolasreunionesdelequiposerealizarondesdetreshastacincovecesporsemanaydeentretresacincohorasdeduración.

8.2. ComunicaciónconexternosalequipoElcontactoconstakeholdersexternosalequiposerealizótantoconreunionespresencialescomonopresenciales.Conlatutorasehizoénfasisenlaimportanciademantenerenmayormedidareunionespresenciales.Ademáselemailfuelaherramientaprincipalparacomunicarposibles detalles que se pasaran por alto durante las reuniones o simplemente paracoordinación.ConelclienteexpertoserealizaronreunionesnopresencialesmedianteSkype,debidoaqueactualmentesuresidenciaseencuentrafueradelpaís.Enetapastempranasdelproyectolacomunicaciónfuemásintensayaquefueclaveenlaextracciónderequerimientosytomadedecisionesparaeldiseñofinal.

67

8.3. ConclusionesyleccionesaprendidasEl equipo concluye que la comunicación conforma un punto vital para lograr una exitosagestióndeproyecto.Graciasaunabuenacomunicación interna se reducen losproblemasasociadosatodoemprendimientodegranporte,talescomodefinicióndemetasyobjetivos,distribucióndetrabajo,diferenciasdeopiniones,etc.Tambiénpermiteatodoslosintegrantesconocerlaperspectivadesuscompañerosenrelaciónalproyectoyalproductoyfacilitaunambientecreativoydeinnovaciónconstante.Porotroladounabuenacomunicaciónhaciaelexteriorfacilitaladireccióndelproyectoenbasealasnecesidadesrealesdelosstakeholdersasí comouna alineación enbase a las restricciones generales que comprende a todos losproyectosdecarrerasuniversitariasrealizadosdentrodeORT(porejemploseguimientodeestándaresIEEE).Encuantoa las leccionesaprendidaselequipoconcuerdaenquesetuvoquemantener lamismaintensidaddecomunicacióndurantetodoelciclodevidadelproyectoconelproductowneryaqueduranteestasinstanciasesdondeelusuariofinal(representadosporelusuarioexperto)tienecontactoconlaformacióndelproducto.

68

9. Gestiónderiesgos

9.1. IntroducciónLosriesgossonfactoresinternosoexternosquenormalmentesonconsideradosamenazasparaelproyecto,ycomotalesdebenserminimizados[48].Dematerializarsealgunopodríaafectarelalcance,lacalidad,losplazosocualquierotroaspectorelacionadoalprocesooalproducto.Paramitigarohacerfrenteaestasamenazasesnecesariorealizarunagestióndelosriesgosque conste de cuatro procesos: planificación de la gestión, identificación de los riesgos,análisiscualitativoycuantitativo,planderespuestaycontrolyporúltimoseguimientodelosmismos.Esporestoqueelequipotomóladecisióndellevarunaexhaustivagestióndelosriesgosconelfindedisminuirlaprobabilidaddeocurrenciaydelimpactoencasoquealgunoseconviertaenproblema.Acontinuaciónsedetallalaestrategiaparalagestiónderiesgos.

9.2. PlanificaciónEnlaplanificaciónsebuscarespuestaalassiguientespreguntas:

• ¿Quiénesseránlosresponsablesdeidentificarlosriesgos?Sedecidióqueelequipoesresponsable de la identificación de los riesgos, a su vez JM se encargará delseguimientoycontrol.

• ¿Enquémomentoycómosellevaráacabolaidentificaciónderiesgos?Setomóladecisióndeidentificarlosriesgosalprincipiodecadasprint.

• ¿Quéescalautilizaremosparaelanálisiscualitativoderiesgos?Seoptóporutilizarlasescalasdeprobabilidaddeocurrenciaeimpacto(verIlustración26).

Ilustración26-Alaizquierdaprobabilidaddeocurrenciaeneltiempo.Aladerechaimpacto

• ¿Cómo priorizaremos los riesgos? Se decidió priorizarlos según su magnitud

ponderándolosutilizandolatabladelaIlustración27.

69

Ilustración27-Prioridadsobreimpacto

• ¿Es necesario realizar análisis cuantitativo de riesgos? ¿Qué herramientas

utilizaremos?Noesnecesarioyaqueesunproyectoconfinesacadémicos.• ¿Qué estrategia adoptaremos para cada riesgo? Las posibles estrategias que

adoptamossonevitar,mitigaryaceptar.Transferirnofuetomadaencuentaporlascaracterísticas del proyecto, principalmente que no es posible delegar tareas aterceros.

• ¿Cadacuántotiemporealizaremoselcontrolyseguimientoderiesgos?Elcontrolyseguimientosedecidiórealizaralprincipiodecadasprintjuntoalaidentificaciónderiesgos.

9.3. IdentificaciónderiesgosLa identificación de los riesgos se realiza una vez por semana donde el equipo evalúa laexistenciadenuevasamenazas.Sebuscanriesgostantodelosprocesoscomodelproducto.Unavezidentificadosselesasignaunnúmeroúnicoparapoderrealizarsuseguimiento.Comoseexplicaconanterioridadduranteestaetapatambiénsehaceuncontroldelosriesgosyaidentificados para lograr un seguimiento sistemático y garantizar que los mismos no sematerialicenenproblemas.A continuación se detalla en laTabla 5 algunos de los riesgos encontrados a lo largo delproyectojuntoasucorrespondienteid.

1 Queelaprendizajedelastecnologíasseleccionadasllevemástiempodelplanificado.

2 Quelacapacitaciónenalgunadelastecnologíasnofuerasuficiente.

3 Queconalgunadelastecnologíasseleccionadasnosepuedaimplementarciertafuncionalidad.

4 Quealgunodelosintegrantesseausenteporuntiempoodebadedicarhorasaotrasactividades.

70

5 Erroresenlaestimacióndetareasllevandoaquesenecesiteuntiempoconsiderableadicionalparacompletarlas.

6 Queseintroduzcancambiosenlosrequerimientosenlafasededesarrollo.

7 Queloslocalesnotenganinterésenelproducto.

8 Quealgunodelosrequerimientosseapococlaro.

9 Quenosecumplaconlosrequisitosmínimosdeunadocumentacióndeproyectodefindecarrera.

10 Abandonodealgúnintegrantedelequipo.

11 Queelproductonocumplaconlasexpectativasdelusuarioexperto.

12 Quelafaltadeexperienciaeneldesarrollowebymóvilgenereretrasosenlastareas.

13 FaltadeconocimientoyexperienciaconelusodeJitparaelcontroldeversiones.

14 Queeltiempoderespuestadelhostingseaconsiderablementelento.

Tabla5–Riesgosidentificados

AnálisiscualitativoSe realiza una análisis cualitativopara cadaunode los riesgos identificados, con el fin depriorizarlosmismos,medirsumagnitudymonitorearlos.Paraestoseponderalaprobabilidaddeocurrencia,elimpactoysecalculalamagnitudsiendoestaelproductodelosanteriores.Unavezpormessevuelveareponderarlosriesgos.PlanderespuestaEl plan de respuesta se realiza luego de identificados y ponderados los riesgos. El fin esminimizarlaocurrenciadelriesgoyreducirelimpactoencasodeconvertirseenproblema.Amododeejemplosedetallalasaccionespreventivasydecontinenciaplanificadasparaalgunodelosriesgosencasodeocurrencia.SeguimientoycontrolSerealizaevaluacionesdelosriesgosaliniciodecadasprintparaobservarsuevoluciónalolargo del proyecto. A continuación semuestra la gráfica de evolución de los riesgos (verIlustración28yTabla6)eneltiempo,sedetallanúnicamentelosriesgosmássignificativos.

71

Ilustración28-Evolucióntemporaldelosriesgosidentificados

Id M J J A S O N D E F1 1.2 1.2 1.8 3.0 3.0 0.0 0.0 0.0 0.0 0.02 0.0 0.0 0.0 0.0 0.0 1.8 1.8 1.2 0.6 0.63 0.0 0.0 0.0 0.0 0.0 1.6 1.6 0.8 0.8 0.84 1.2 1.2 2.4 2.4 2.4 2.4 1.2 1.2 2.4 2.45 1.6 1.6 1.6 2.0 2.0 1.8 1.8 1.2 0.6 0.66 0.0 0.0 0.0 0.0 0.0 1.8 1.8 1.2 0.8 0.87 3.0 2.0 1.6 1.6 1.6 1.6 1.6 1.6 1.6 1.68 2.4 2.4 2.4 1.8 1.8 1.6 1.6 1.6 0.8 0.89 0.6 0.6 0.6 0.6 0.6 0.8 0.8 0.8 0.6 0.410 2.4 2.4 2.4 2.4 1.8 2.4 2.4 1.6 1.0 1.011 0.0 0.0 0.0 0.0 0.0 2.4 1.8 1.2 0.6 0.612 0.0 0.0 0.0 0.0 0.0 2.4 1.8 0.6 0.6 0.613 1.2 1.2 1.2 1.2 1.2 1.2 1.2 1.2 2.0 1.014 0.0 0.0 0.0 0.0 0.0 0.0 0.0 3.0 0.0 0.0

Tabla6-Evolucióndelosriesgosponderadosmesames

9.4. Conclusionesyleccionesaprendidas

En cuanto a la gestión de riesgos se comprendió la importancia de llevar un control yseguimiento a lo largo del proyecto como también la de crear planes de mitigación ycontingencia.Elcontrolyseguimientopermitióalequipotomaraccionesanticipadasconelobjetivodisminuirlaprobabilidaddeocurrenciayelimpactodecadariesgoidentificadoalserconscientes de estas características a lo largo del tiempo. Los planes anteriormentemencionadossirvieronalequipoparaafrontarlosriesgosquesematerializaronenproblemasdeformarápidayeficaz.

0,00,51,01,52,02,53,03,5

Evolucióndelosriesgos

11

1

13

5

8

7

72

10. GestióndelaconfiguraciónA continuación se describe el proceso utilizado para la gestión de la configuración delsoftware,locualincluyeseleccióndelasherramientasutilizadasasícomolasmetodologíasaplicadasparaelmanejodeversionados.ElPlandeconfiguraciónestábasadoenalgunossupuestosquesedetallanacontinuación:

• El tiempo de duración del proyecto está limitado a una extensión de un añoaproximadamenteapartirdel20deabrildel2015,porlotantosebuscaunarápidarespuestaaloscambiosyunaltogradodeorganizaciónquefaciliteneltrabajodiario.

• ElModelodeProceso sebasaenundesarrollo incremental, dadopor lasdistintasiteraciones.Resultaimportantetenercontrolsobrecadaunadelasiteracionesyfases,delosproductosgeneradosenestasydeloscambiossurgidos,evaluadosyaprobados.

• Sedebenincluirencontroldeconfiguraciónlamayorcantidaddeproductosposibles,tomandoencuentasiemprelasrestriccionesdadasporladuracióndelproyectoyporlacapacidadorganizativadelgrupo.

AlcomienzodelproyectofuenecesarioestablecercualesseríanlosprincipalesECS(Elementosdeconfiguracióndelsoftware)paraasípoderdefinirqueherramientasutilizarycualseríalapolíticaparaelmanejodelasmismas.LosprincipalesECSdetectadosfueron:productosdesoftware(códigoyejecutables)yproductosdedocumentación.

10.1. HerramientasparalagestióndelcódigoGit es actualmente el software de control de versionado más utilizado mundialmentepensando para ofrecer eficiencia, facilidad de uso, confiabilidad del mantenimiento deversionesytrabajodistribuido[53].Susimplicidadfrentealasramificacionesloconvierteenun sistema rápido e intuitivo, con baja curva de aprendizaje y alto desempeño en su usoprolongado.Gitsebasaenunaarquitecturaderepositoriosdistribuidos(verIlustración29),endondeexisteunnodocentralizadoqueactúadehostingdeversionesmientrasquecadacolaboradormantienesupropiorepositorioensumáquina.

73

Ilustración29-ArquitecturadistribuidaGit[54]

Estaarquitecturaloproveeconunadesuscaracterísticasmásdestacables,enlaquetodoelcódigoseencuentracentralizadoperoasuvezdescentralizadofavoreciendoasílaseguridad,accesibilidadydisponibilidaddelcódigosinperderdevistalacolaboraciónentrepares.Deesta forma quienes participan del proyecto pueden obtener una copia del nodo origen,manejarsuestructuraderamificacionespersonalensuequipo,obtenerunacopiadeotrocolaboradoryunavezseestéconformecon lasmodificacionescompartirlasal repositoriocentral.Elesquemaderamificaciónpropuestoparaesteproyectosebasaenelusodeprincipaldedos grandes tipos de ramas: ramas centrales y ramas de apoyo. Las ramas centrales sonutilizadasparamantenerelcódigoprincipaldel sistema,mientrasque las ramasdeapoyosirven para diversificar y proveer mecanismos de cambios minimizando el impacto y lapropagacióndeerrores.

10.1.1. RamasprincipalesTodoelmodeloderamificaciónpropuestogiraalrededordedosramascentralesqueexistenentodomodeloGitdedesarrollodesoftwareycuyociclodevidaseextiendealolargodelciclodevidadelmismoproducto:masterydevelop.MasterLa ramamaster será donde se alojará el código fuente listo para producción, y donde elapuntadorHEADsiemprereflejarálaúltimaversiónestabledelmismo.Sobreestaramanosedesarrollarancommits(nosemodificaráelcódigo),sinoqueelcódigoprovendrádefusionaruna ramadeapoyo,ya sea releaseohotfix segúnseael caso,permitiendocrearaccionesautomáticassobreestaramaquefaciliteneldesplieguedenuevasversiones.

74

DevelopLaramadevelopserádondeocurralaintegracióncontinuaentreelcódigoprovenientedelosintegrantesdelequipo.Enestaramaseirádesarrollandohastaqueelcódigofuentealcanceunaversiónestable,paraluegopasaralaramadeapoyorelease,dondeseacondicionaráparapasaraunambientedeproducción[55].

10.1.2. RamasdeapoyoJuntoalasramasmasterydevelop,elmodelodedesarrolloelegidoutilizaunavariedadderamasdeapoyoparamejorareltrabajoparaleloentrelosmiembrosdelequipo,facilitarelseguimientodenuevascaracterísticas,prepararseparalasliberacionesdeproducciónyparaayudarenlacorrecciónrápidadeproblemasprovenientesdeunambientedeproducción.Adiferenciadelasramasprincipales,estasramassiempretienenuntiempodevidalimitado,yaqueseráneliminadaseventualmente.Estasramassonrelease,featureyhotfix.ReleaseLaramareleasesurgeapartirdelaramadevelopydebefusionarseconlasramasdevelopymasterunavezfinalizadosuciclodevida.Sufunciónesactuarcomoramadepreparaciónparaliberación,esdecirserádondesealojaráelcódigoquesequiereponerelproducciónenbreveyporlotantodeberáserinspeccionadomásendetalle,permitiendocorregirpequeñosbugsquenosehubiesendetectadoendevelop.Enelmomentoenquesecrealaramificacióndeunnuevoreleaseelequipoenteroenfocasutrabajosobreestaramaparalograrenpocotiempoponerenproducciónelcódigo.Todos loscambiosqueserealicensobreestaramadeberánserimpactadoscontralaramadevelopparaquealvolveralambientededesarrollolosbugsnopersistan.Unavezquesecorrigen las incidenciasdetectadaselcódigodeberáfusionarseenmasterydeberárealizarseuntagconelcorrespondientenúmerodeversiónestablecidoporelSCMR(gestordeláreadeconfiguración).FeatureLa rama feature surgeapartirde la ramadevelop ydebevolvera fusionarse con la ramadevelopunavezfinalizadosuciclodevida.Seutilizanparadesarrollarnuevasfuncionesparapróximas versiones del producto. Al iniciar el desarrollo de una nueva característica nosiempresetieneclaroelmomentoenqueseintegraráalproducto,porloquedesarrollarlaendevelop llevaráa códigodesprolijo yno finalizado,produciendopotencialeserroresdecompilación.Laesenciadeunaramafeatureesqueexiste,siempreycuandolafunciónseencuentraendesarrollo,peroconel tiempose integrarádenuevoendevelop (seañadirádefinitivamentelanuevafunciónparalapróximaliberación)obienserádesechada(encasode un experimento decepcionante), por lo que una rama feature normalmente existeúnicamenteenrepositoriosdedesarrolladoresynoenelorigen.HotfixLaramahotfixsurgeapartirde laramamasterydebefusionarsecon lasramasdevelopymaster una vez finalizados su ciclo de vida. Las ramashotfix son similares a las ramas de

75

releaseyaqueenambasseestápreparandounanuevaversióndeproducción,aunqueenelcasodehotfixnohubiesesidoplanificado.Surgendelanecesidaddeactuarinmediatamentedespuésdeunestadonodeseadodeunaversiónenproducción.Cuandoocurreunerrorcríticoenunaversióndeproducciónsedeberesolverdeinmediato,unaramahotfixpuedeserramificadofueradelaetiquetacorrespondienteenlaramaprincipalquemarcalaversióndeproducción.Laesenciaesqueeltrabajode losmiembrosdelequipoendeveloppuedecontinuar,mientrasqueotrapersonaseencargadeproveerunasoluciónrápidaalambientedeproducción.

10.2. HerramientasparalagestióndeproductosdedocumentaciónConelfindeorganizarymantenerlosproductosdedocumentaciónseutilizaelsistemadealmacenamientoenlanubedeDropbox,elcualbrindaasususuariosdecuentasgratuitascon3GBdealmacenamientos,espaciomásquesuficientesparalosrequerimientosdelproyecto.También provee un modelo de versionado automático de archivos permitiendo larecuperacióndeversionesanterioresencasonecesariojuntoconunsistemadeintegraciónconMicrosoftOffice,permitiendoelmanejosimultaneodearchivostradicionalesdeWord,ExceloPowerPointpormúltiplesusuarios,registrandoloscambiosasociadosalosmismos.ControldecambiosSedefineunprocesodecontroldecambios(verIlustración30)conelobjetivoprincipaldeque los cambios detectados se implementen adecuadamente durante el transcurso delproyecto,garantizandoresponderenformaágilalosmismos.

Ilustración30-Circuitodecontroldecambios

76

Porlascaracterísticasdelproyectoelequipoasumeunentornocambianteencuantoalosrequerimientosporloqueseanticipauncircuitodecontroldecambios.Loscambiossurgenportresrutasposibles:

• Elusuarioexpertosugiereuncambioenlafuncionalidaddelsistema.• Elequiposugiereuncambioparaelsistema.• Elequipoounusuariodetectanunafallaenlaaplicación.

77

11. Gestióndelacalidad

11.1. GestiónEl Aseguramiento de la Calidad es el conjunto de actividades planificadas y sistemáticasnecesariasparaaportarlaconfianzaqueelsoftwaresatisfarálosrequisitosdadosdecalidad[56].Estasactividadessebasanenlaselecciónyverificacióndelosestándares,definiciónyrecolección de lasmétricas que deben tenerse en cuenta durante todo el transcurso delproyecto.Eneste capítulo sedescribeelprocesodecalidadque seutilizóen todoel transcursodelproyectodefiniendo lasdiferentesáreasdeactividad, tareas, encargados, y los resultadosfinales.ObjetivosUnode los objetivos principales de la gestiónde calidad es la de lograr cumplir todas lasexpectativas de los usuarios. Esto se logra a partir del cumplimiento de tanto losrequerimientosfuncionalescomolosnofuncionales.Además,esnecesariolograrobtenerunproducto con un bajo porcentaje de defectos, cumplir con todos los estándares dedocumentación y codificación, y cumplir con todas las métricas establecidas ya sean deprocesoodelproducto.ProcesodecalidadAl comienzo del proyecto se definieron los diferentes estándares de codificación ydocumentación a utilizar. Luego se definieron diferentes actividades con el propósito deverificaryevaluarelprocesoylaevolucióndelproductoalolargodelciclodevida.Enunambientedetrabajoágil,sedefinierondiferentescriteriosdevalidaciónyaceptaciónqueentranenjuegoalahoradefinalizarcadaunodelosstorypointsdelsprint,acompañadoconpruebasyrevisionesconpartedelequipoyposiblesusuarios.Unavezfinalizadounsprint,serealizarontareasdedetección,prevenciónycorreccióndeerrores,ademásdeanálisisdeevaluacióndecumplimientodeestándares.Luegodefinalizadauna iteración, además de las tareas de detección, prevención y corrección de errores, seevaluó el cumplimiento de cada uno de los estándares establecidos para luego realizarcorreccionespertinentes.ActividadesdeCalidadSon las actividades responsables de garantizar que se hayan cumplido todos los objetivosestablecidosparalograrlacalidad.Estasactividadessebasanenlaselecciónyverificacióndelosestándares,definiciónyrecoleccióndelasmétricasquedebentenerseencuentadurantetodoeltranscursodelproyecto.

78

DefinicióndeestándaresLosestándaresdecodificaciónsonaquellosestilosoprácticasdeunlenguajepensadosparaproveerlodecaracterísticasquefavorezcansulecturaeinterpretaciónhumana,asícomoquefacilitenunamayormantenibilidadalcódigogenerado.ElequipodecidióseguirconlosestándaresestablecidosparaeldesarrolloenellenguajeJavayRuby.Java[57]

• Clases: Para todonombrede clase, la primera letradebede serMayúscula, si sonvariaspalabrassedebedeintercalarentremayúsculasyminúsculas,estemecanismodenombreesllamadocamelCase(Porejemplo:NombreDeClase,Animal,Factura).

• Métodos:Paralosmétodosdeclases,laprimeraletradebeserminúscula,sisonvariaspalabras se debe de intercalar entreminúsculas ymayúsculas, para el caso de losmétodos de clases aplica el mecanismo delcamelCase (Por ejemplo, getNombre,setEdad,buscarPorIdPersona).

• Variables:Paralasvariables,seaplicaelcasodelosmétodos,dondelaprimeraletraesminúscula,ylasdemássedebendeguiarporelmecanismodecamelCase,loqueesimportantededestacar,esquelosnombresdelasvariables,ademásdecumplirloanterior,debensercortosydescriptivosensímismo. (Porejemplo:nombre,edad,idPersona).

• Constantes: Para las constantes, su nombre debe ser escrito completamente enMayúsculas,yparalaseparacióndepalabrassedebeusarelunderscore/guiónbajo(_).(Porejemplo,MAX_SUMA,VALOR_MULTIPLO).

Ruby[58]

• Modelos“gordos”concontroladoresdelgados: La ideabásicaes lademantenerelcódigolimpioyconciso,conlógicaconalgúntipoderesponsabilidadenelcontroladory la que no tiene en el modelo para lograr tener un buen modelo con métodostesteables.

• Principio de responsabilidad única: Hacer que las clases tengan una únicaresponsabilidadporcualcambiar.

• Evitarcódigorepetido:Tratardeevitartenermuchocódigorepetidoenelsistema.Laideaprincipaldeestoesladefacilitarlamantenibilidaddelsistema.

• Regladelboysocut:Dejarelcódigomejordeloqueloencontraste.• Reusable y Chainable Scopes y Relaciones: Rails 3 introdujo nuevos scopes que

cumplenlafuncióndemantenermáslimpioyfacilitaelusodelasrelacionesdebasededatosymodelosActiveRecord.

79

• Tenerelcódigoenpaquetes:Sielcódigogeneralmenteesreusableintentarcolocarloenpaquetesyaseanpluginsogemas,asíhacerqueelsistemasealimpioyfaciliteelmantenimiento.

EstándaresenladocumentaciónParaestablecerlosestándaresparaladocumentación,seutilizaroncomoformadeguíalosdocumentosproporcionadospor la facultadqueestablecen lasnormaspara laentregadedocumentos y proyectos finales de las carreras de ingeniería de sistemas. Estos son losdocumentos:302,303y306.ValidacionesUnaformadevalidacióndelosrequerimientosfuelautilizacióndeprototiposparavisualizarlasfuncionalidadesdelsistemaycómosecomportanenunflujodetrabajoestablecido.Éstatarea se intentó realizar en el correr de todo el proyecto y teniendo especial hincapié alcomienzoparapoderrealizarajustesenlosrequerimientos.Además,serealizanreunionesconusuariosyentrevistasconelexperto,conelobjetivodeobtenercomentariosyaseadeposiblesmejoras,correccionesovalidacionesdelasfuncionalidadesdelproducto.

Productoaevaluar Criterios/técnica Responsable Registrode

resultados Duración

InterfazGrafica Usabilidad Equipo

Resultadodeentrevistasyreuniones

Durantetodoelproyecto

ProductBacklog Requerimientos Equipo

Resultadodeentrevistasyreuniones

Durantetodoelproyecto

ArquitecturadelSistema

Reuniónconexperto Equipo

Aceptaciónformalmedianteentrevistasconel

experto

Durantetodoelproyecto

Tabla7-Validacionesdelosrequerimientos

80

PruebasdeconceptoAntesdeoptarporlaseleccióndealgunatecnologíaenparticular,elequiporealizópruebasdeconceptodurantelafasedediseñodescritaenelcapítuloGestióndeltiempo,conelfindeconocerlasventajasydesventajasquepresentancadaunadeellas.Apartirdedichaspruebasyjuntoaunaespecificaciónprimariadelosrequerimientos,selogródefinircualestecnologíasseríanutilizadasparaeldesarrollodelsistema.CriteriosdeaceptaciónEnelcomienzodecadaiteración,sedefinenunconjuntodecriteriosdeaceptaciónparacadauserstory.Éstaestomadacomoválidasicumplecontodosloscriteriosdeaceptación.TestingParalograrunsistemaquepresentealtosnivelesdecalidadesnecesariorealizarunaetapadetesting,queasegurequeelsistemafuncionaenlaformaesperada.Noexistesistemasinerrores,perosepuedelograrreducirlosmismosdeformaconsiderableatravésdelanálisisydepuracióndepruebassobreelcódigo.Duranteeltranscursodelproyectoserealizaronunconjuntodepruebasalfa[59]juntoaposiblesusuariosdelsistemaquefacilitaronunfeedbackdesuuso,elcualresultódegranayudaparaeldesarrollo.PruebasdeaceptaciónLaspruebasdeaceptacióncumplenconelobjetivodeverificaryvalidarqueelsistemacumpleconelfuncionamientodeseado,ademáspermitenvalidarquelosdiferentesusuariosquedensatisfechosconelproductodesarrollado.Sonejecutadasmediantelosintegrantesdelequipoyademásungrupodeusuariosfinales,conelobjetivodeasegurarsequeelsistemacumplaconlosrequisitosylasexpectativasparaelcualfuecreado.PruebasdeusabilidadLas pruebas de usabilidad son aquellas pruebas donde el usuario se encuentra frente alsistemaenunambientededesarrollocontroladoparaevaluarelfuncionamientodelmismo.Esto puede ser una práctica de usabilidad directa de como los usuarios reales utilizan elsistemaenelambientedeproducción.Elobjetivoprincipaldelaspruebasdeusabilidadesidentificar losproblemasdeinteracciónhombre-máquina,recolectarfeedbackymejorar lasatisfaccióndesususuarios.PruebadeseguridadEste tipo de pruebas sirven para verificar que el sistema cumpla con los elementos deseguridadespecificados,verificandoquelosdatosdecadausuarioesténdisponiblesyseanaccesiblesúnicamenteporélynadiemás.Acontinuaciónsedetallanlastécnicasqueseutilizanparalavalidaciónfuncionaldelsistema:

81

PruebasderendimientoEstaspruebascumplenelcometidodeanalizarelrendimientodelaaplicación,sometiendoaesta a situaciones atípicas que no enfrentaría en condiciones normales de uso. Paradesarrollar las pruebas de rendimiento se utilizan add-ons deHeroku, los cuales permitegenerar diferentes situacionesde trabajo, quepermitan analizar el comportamientode laaplicaciónylostiemposdetrabajobajoestrés.MétricasLasmétricassonunconjuntodeindicadoresqueseempleanparaconoceroestimaralgunacaracterísticadel sistemaquepermitaayudara laplanificacióny generarun feedback deltrabajodelequipo[60].Conellassepuedemedir,controlarymejorarlosprocesodondeseapliquen.Acontinuaciónsedescriben(verTabla8)lasmétricasaplicadasparaesteproyecto:

Tipo Métrica Objetivo Valor

Proceso HorasplanificadasConocerelesfuerzoenhorasparaundeterminadosprint

Cantidaddehorasqueelequiposecomprometeacumplir

Proceso HorasrealesConocerelesfuerzorealdedicadoparaundeterminadosprint

Cantidaddehorasqueelequipoefectivamenterealizó

Proceso Storypointsplanificados

Conocerelesfuerzoenstorypointparaundeterminadosprint

Cantidaddestorypointqueelequiposecomprometeadesarrollarparaunsprint

Proceso Storypointsdesarrollados

Conocerelesfuerzorealdedicadoenunsprint

Cantidaddestorypointsqueelequiporealmentedesarrollaenunsprint

Proceso Horasrealesvshorasplanificadas Mejorarlaproductividad +-15%variaciónentrelo

planificadoyloreal

Proceso Disponibilidad Conocerelporcentajedehorasextrasinsumidas

>=0horasextrasqueelequipodebededicarencadasprint

Proceso Porcentajeesperadocompletado

Conocerelporcentajedeavancesegúnlacantidaddesprintstotales#SprintsCompletados/#sprintsTotales

Proceso Porcentajerealcompletado

Conocerelporcentajedestorypointsdesarrollados#storypointsCompletados/#storypointsestimados

Proceso Cantidaddetareasrealizadas

Conocerlacantidaddetareasarealizarenundeterminadosprint

Realizartodaslastareasdefinidas

82

Proceso Cantidaddetareaspendientes

Evitarlaacumulacióndetareaspendientes

Nomásdeunatareapendiente

Producto Cantidaddeerroresdetectadosentesting

Conocerlacantidaddeerroresdetectados 20%deltotaldetareas

ProductoCantidaddeerroresdetectadospor

usuarios

Conocerlacantidaddeerroresdetectadosporusuarios

NomásdecincoerroresdeseveridadcriticoalfinalizarelSprint

Producto Porcentajedecoberturadepruebas

Testeartodaslasfuncionalidades Cumplirconel90%

Tabla8-Métricasaplicadasalproyecto

11.2. Burndownchartsyproyecciones

LaIlustración31muestraeltrabajopendienteyeltrabajoagregadoduranteeltranscursodelproyecto.LoqueseobservaporencimadelejeX(colornaranjaenlaIlustración31)representaelaumentodetrabajoenstorypoints reflejandocomoafectannuevas incorporacionesderequerimientosalproductbacklog.Elproyectocomienzacon210SP(storypoints)aserimplementados.Comosepuedeapreciar,a partir del segundo sprint se agregan nueva funcionalidad para implementar sobre laspreviamentedefinidaenunaprimerainstancia.Estorepercutióalfinaldelaetapadeejecución,ysibienelequipoincrementólashorasdetrabajo diarias para lograr cumplir con lo establecido no se logró ejecutar el sprint 6planificado inicialmente, tal como se explicará más adelante en este capítulo, dejandopendientes44SPparasufuturaimplementación.

Ilustración31-Burndownchartporrelease

210185

159121

7444

2318

3

0

50

100

150

200

250

Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6

BurndownChart

Trabajopendientealiniciodelsprint Trabajoagregado

83

Comosepuedeapreciarenla Ilustración32 lacantidaddeuserstories implementadasporsprint, de lo cual sedesprendeel cálculodevelocidadpromedio (tambiénconocida comovelocityenScrum).Estecálculojuntoalproductbacklogfinaldelsprint6quesemuestraenla Ilustración 31, permiten generar una aproximación del trabajo necesario (cantidad desprints)parafinalizarcompletamenteelproducto.ElresultadodeestecálculoseplanteaenlaTabla9acontinuación.

Velocidadpromediodedesarrolloporsprint(SP/S) 40SP/SPorcentajetotalcompletadodelproducto 83%

Tabla9-Velocidadpromedioyporcentajedeavance

Ilustración32-Storypointsimplementadosporsprint

Analizando la velocidad promedio y la cantidad de funcionalidad pendiente en elproductbacklogsepuedeestimarquelarealizacióndelsprint6programadoinicialmentepermitiríafinalizarcompletamenteeldesarrollodetodaslasfuncionalidadesdelproducto.Sinembargola dificultad de estimación llevó a que las user stories implementadas por sprints no semantuviesenconstantescomoseapreciaenlaIlustración32,razónporlacualseríanecesarioun análisismás profundo y una reevaluación del product backlog para definir conmayorprecisiónlafinalizacióntotaldelproducto.

11.3. HorasplanificadasvshorasrealesEnlaIlustración33semuestrealarelaciónentrelashorasinicialmenteestimadasylashorasque realmente llevó la realización de cada sprint. Originalmente debido a la planificaciónprimariadehorasaemplear,seestimóqueparacompletarlatotalidaddelasfuncionalidadesdebíandeejecutarse6sprints.

16

4956

50

30

0

10

20

30

40

50

60

Sprint1 Sprint2 Sprint3 Sprint4 Sprint5

Storypointdesarrolladoporsprint

84

Ilustración33-Horasplanificadasvshorasreales

ComosepuedeapreciarenlaIlustración33durantelosprimerosdossprintssetrabajópordebajodelashorasplanificadas,yluegosecomenzóadedicarmayorcargahorariabuscandocompensareldéficitylograrcumplirconlopropuestoenelalcanceinicialdelproyecto.DeigualformalosdesvíossiguieronexistiendoporlamaterializaronderiesgosqueseexplicanenelcapítuloGestiónderiesgos,retrasandoelproyectoyhaciendoqueelúltimosprintnosepudiesellevaracabo.

Ilustración34-Horasplanificadasparacadafaseenlaizquierdayhorasplanificadasvshorasrealesaladerecha

Lasdiferenteshorasestimadasque semuestranen la Ilustración34 hacen referenciaa laestimacióntotaldelproyecto.Sinembargo,lashorasrealesrepresentaneltrabajorealizadohastaelquintoyúltimosprintqueserealizó.

Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 Sprint6Horasplanificadas 195 195 195 300 300 300

Horasreales 165 163 253 337 352 0

195 195 195300 300 300

165 163253

337 352

0050

100150200250300350400

HorasplanificadasVSHorasreales

Horasplanificadas Horasreales

85

11.4. Testing

LaIlustración35muestralacantidaddeerroresencontradosporelequipoparacadasprintdurantetodoelproyecto.Comosepuedeapreciarloserroressedividenendiferentestiposdependiendodequéformaafectan al sistema. Se registraronmayor cantidad de errores amedida de que se fueronimplementando funcionalidades con mayor índice de complejidad. Al finalizar la fase deejecución loserroresdisminuyerondebidoaqueelsistemalogrounestadodeestabilidaddeseada.Debidoalagrancomplejidaddealgunasfuncionalidadesresultamuydifícilprobartodaslasalternativasposiblesdeuso.Portalmotivo,apartirdeltercersprint,apartirdelcualsepuedeconsiderar implementadas una cantidad considerable de funcionalidades, se recurrió adiferentesusuariosdelsistemaparaincrementarlastareasdetesting.Estoresultódemuchautilidaddebidoaqueellosreportanunacantidadimportantedeltotaldeerroresdetectados,comosepuedeverenlaIlustración36.

Ilustración35-Erroresportipodeseveridad

2

54

7

32

3

5

322 1

4

23

1 1 13

20

2

4

6

8

Sprint1 Sprint2 Sprint3 Sprint4 Sprint5

Erroresporseveridad

Critico Alto Medio Bajo

86

Ilustración36-Tiposdeerroresdetectadosporusuarios

11.5. Conclusionesyleccionesaprendidas

Una vez finalizado con los puntos de calidad se puede concluir que efectivamente secumplieroncontodosloselementosycaracterísticasesencialesquerepresentanaláreadecalidaddesoftware.Se definió el proceso, las actividades, los diferentes estándares a utilizar, los criterios deaceptaciónodiferentesformasdevalidarlosrequerimientos.Paraelapartadodeltestingsedefinióelproceso,sehablarondelosdiferentestiposdepruebasnecesariasparauncorrectoprocesoyseestablecierondiferentesestrategias.Finalmenteseestablecieronlasdiferentesmétricastantodeprocesocomodelproductoyseanalizaronlasmismas.Gracias a la gestión de calidad que se realizó, se logró encontrar y analizar los diferenteselementos que lograron desvíos a lo largo del proyecto, permitiendo tomar diferentesmedidasparamitigarycorregir.

0 0 1 0 00 0 0 1 10 0 1

2

10 0

3

2 2

00,51

1,52

2,53

3,5

Sprint1 Sprint2 Sprint3 Sprint4 Sprint5

Erroresencontradosporusuarios

Critico Alto Medio Bajo

87

12. ConclusionesdelproyectoyleccionesaprendidasDesdeunaperspectivahumanaelgrupodemostrócompañerismoybuenadisposiciónparatrabajoenequipo,tomandounaposturaproactivaduranteelproyectoyprocurandosiempreresolverlosproblemasquefueronsurgiendo.Lacomunicaciónconstanteentreparesayudóamantenersiempreundiálogofluido, indispensablepara lametaderesolverproblemasyfacilitando un ámbito de creatividad. En todomomento se asumió la responsabilidad decumplirconlastareasautoasignadasyladedicaciónhorariaestablecidadecomúnacuerdo,asícomodedesempeñarentodomomentoelmayoresfuerzoposibleparalograrunproyectoexitoso.Tomandoenconsideraciónlaperspectivadelproyectosepuedeconcluirqueselogródiseñare implementarmuchasde lasfuncionalidadesesperadas,permitiendoofrecerunproductoque aporte valor a la comunidad de artistas y con el cual los integrantes quedaronmuysatisfechos. Sin embargo todo el equipo está de acuerdo en que existen un grupo defuncionalidades altamente desaseadas que hubiesen permitido ofrecer un productorealmenteúnico,talescomopresentacionesenvivoo“sentimentanalysis”deloscomentariosentiemporeal.La gestión del proyecto fue sin duda uno de los desafíos más grandes que se tuvo queenfrentarelequipodebidoalafaltadeexperienciaprácticaenelárea.Lasestimacionesenprocesosyactividadesfueronunadelasprincipalescausasdedesvíosduranteelproyectoyrepresentaronunadelasdificultadesmásgrandes.Apesardeestoelequipoquedóconformecon el trabajo realizado, obteniendo importantes lecciones y experiencias que podrán seraplicadasafuturosproyectos.En general el proyecto fueuna instanciade aprendizajequepermitió generar experienciatanto a nivel técnico como a nivel profesional y humano, facilitando auto descubrir lascapacidadesdecadaintegranteytambiénlascapacidadescomoequipo.Sintenerencuentalosresultadosacadémicosobtenidosdeesteproyectoseconcluyequelasmetasesperadasfueroncumplidasyqueelresultadogeneralhasidoexitoso.

88

13. ProyecciónafuturoEnlasetapasiniciales,durantelarealizacióndeltalleremprendedor,estudiamoslaviabilidadde la idea del equipo. Para ello analizamos los entornos a los cuales podría pertenecerAmadeus y pudimos ver que, si bien existían aplicaciones con funcionalidades similitudes,estas no apuntaban almismo cliente final, sumando que el foco principal de usuarios esreducidoaméricalatina.Comoresultadodeeseanálisisensumomentonosplantemoscomoobjetivoeldecontinuarconelemprendimientounavezfinalizadalaetapaacadémica.Durante el transcurso del proyecto fuimos viendo como las distintas aplicaciones querepresentan una competencia directa fueron evolucionando agregando nuevasfuncionalidadesqueresultansersimilaresalasnuestras.Estollevoarealizarnuevamenteunanálisisparaestudiarlaposibilidaddecontinuarconelobjetivodecontinuarconelemprendimientoluegodelaetapaacadémica.SellegóalaconclusióndequetodavíaesviableseguirconelemprendimientodebidoaqueelclienteobjetivodeAmadeuscontinúasiendodiferentealdelacompetencia,ademásdequelosotrossistemassiguenteniendobajoimpactoenaméricalatina.

89

14. Bibliografía[1] Amazon AWS, «Amazon EC2,» [En línea]. Available:

https://aws.amazon.com/es/ec2/?nc2=h_l3_c.[Últimoacceso:1722016].[2] Amazon, «Amazon S3,» [En línea]. Available:

https://aws.amazon.com/es/s3/?nc2=h_l3_sc.[Últimoacceso:1722016].[3] Amazon AWS, «Amazon Elasticsearch Service,» [En línea]. Available:

https://aws.amazon.com/es/elasticsearch-service/.[Últimoacceso:1722016].[4] money.howstuffworks, «API,» [En línea]. Available:

http://money.howstuffworks.com/business-communications/how-to-leverage-an-api-for-conferencing1.htm.[Últimoacceso:1722016].

[5] proyectosagiles,«QuéesSCRUM,»[Enlínea].Available:http://proyectosagiles.org/que-es-scrum/.[Últimoacceso:132016].

[6] Wikipedia, [En línea]. Available: https://es.wikipedia.org/wiki/Streaming. [Últimoacceso:1722016].

[7] Universidad ORT, «Aulas,» [En línea]. Available:https://aulas.ort.edu.uy/mod/url/view.php?id=50644.[Últimoacceso:132016].

[8] «Design thinking en Español,» [En línea]. Available:http://www.designthinking.es/inicio/index.php.[Últimoacceso:17022016].

[9] «Beatsmusic,»[Enlínea].Available:http://www.apple.com/music/.[Últimoacceso:1282015].

[10]

«IFPI,»[Enlínea].Available:http://ifpi.org.[Últimoacceso:132016].

[11]

«Youtube,»[Enlínea].Available:https://www.youtube.com/yt/about/.

[12]

«Facebook,»[Enlínea].Available:https://www.facebook.com/facebook/info/.

[13]

«SoundCloud,»[Enlínea].Available:https://soundcloud.com/pages/contact.

[14]

danielvn7, «Procesode la Ingeniería deRequisitos,» 273 2008. [En línea].Available:https://danielvn7.wordpress.com/category/ingenieria-de-requisitos/.[Últimoacceso:132016].

[15]

Adessor, «Las 5 fuerzas de porter,» 5 2 2013. [En línea]. Available:http://www.adesor.com/2013/02/cinco-fuerzas-de-porter.html. [Último acceso: 1 32016].

[16]

interaction Design Foundation, «Mock-ups,» [En línea]. Available:https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/mock-ups.[Últimoacceso:132016].

[17]

D. Radigan, «The product backlog: your ultimate to-do list,» [En línea]. Available:https://es.atlassian.com/agile/backlogs.[Últimoacceso:132016].

[18]

cge, «Benchmarking,» [En línea]. Available:http://www.cge.es/portalcge/tecnologia/innovacion/4111benchmarking.aspx. [Últimoacceso:132016].

90

[19]

«Reverbnation,» [En línea]. Available: http://corporate.reverbnation.com/. [Últimoacceso:2132016].

[20]

«Google+,» [En línea]. Available: https://plus.google.com/+googleplus/about. [Últimoacceso:2132015].

[21]

Google, «Material Design,» [En línea]. Available:https://www.google.com/design/spec/material-design/introduction.html#introduction-goals.

[22]

B. P. a. L. Lee, «Thumbs up? Sentiment Classification using Machine LearningTechniques,» [En línea]. Available:http://www.cs.cornell.edu/home/llee/papers/sentiment.pdf.[Últimoacceso:132016].

[23]

«Ingeniería de requerimientos,» [En línea]. Available:http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4.[Últimoacceso:1722016].

[24]

M. Cohn, «User Stories,» [En línea]. Available:https://www.mountaingoatsoftware.com/agile/user-stories.[Últimoacceso:132016].

[25]

Trello,«Trellodashboard,»[Enlínea].Available:https://trello.com/.[Últimoacceso:132016].

[26]

P.Lledó,DirectorProfesionaldeProyectos.

[27]

H. C. E. Valencia, «Modelo de Vistas de Arquitectura 4+1,» [En línea]. Available:http://sg.com.mx/revista/30/documentacion-arquitectura#.Vti76pPhCqA. [Últimoacceso:17022016].

[28]

J. Casanovas, «Desarrollo web,» 9 9 2004. [En línea]. Available:http://www.desarrolloweb.com/articulos/1622.php.

[29]

ccm,«Client/ServerEnvironment,»[Enlínea].Available:http://ccm.net/contents/152-client-server-environment.[Últimoacceso:1722016].

[30]

A.d.C.y.A.d.C.y.Tácticas,«AtributosdeCalidadyAtributosdeCalidadyTácticas,»[En línea]. Available: http://www-2.dc.uba.ar/materias/isoft2/2007_02/clases/Clase5-EscenariosYTacticas.pdf.[Últimoacceso:1722016].

[31]

P.C.C.R.K.LenBass,SoftwareArchitectureinPractice,ThirdEdition,A.Professional,Ed.

[32]

SLA Information zone, «The Service Level Agreement,» [En línea]. Available:http://www.sla-zone.co.uk/index.htm.[Últimoacceso:132016].

[33]

Heroku, «Heroku status,» [En línea]. Available: https://status.heroku.com/uptime.[Últimoacceso:1722016].

[34]

A. Rodriguez, «IBM,» 9 2 2015. [En línea]. Available:http://www.ibm.com/developerworks/webservices/library/ws-restful/index.html?ca=dgr-jw22RESTfulBasics&S_Tact=105AGX59&S_CMP=GRsitejw22.[Últimoacceso:1722016].

[35]

J. D. Mooney, «Bringing Portability to the Software Process,» [En línea]. Available:http://www.cs.wvu.edu/~jdm/research/portability/reports/TR_97-1.pdf. [Últimoacceso:1722016].

[36]

C. B. W. J. B. Goodenough, «On System Scalability,» 3 2006. [En línea]. Available:http://www.sei.cmu.edu/reports/06tn012.pdf.[Últimoacceso:1722016].

91

[37]

L. D. Hurley, «devise_token_auth,» [En línea]. Available:https://github.com/lynndylanhurley/devise_token_auth.[Últimoacceso:1722016].

[38]

«Triangular - Material Design Admin Template AngularJS,» [En línea]. Available:http://themeforest.net/item/triangular-material-design-admin-template-angularjs/11711437.[Últimoacceso:132013].

[39]

c2, «Modelo–vista–controlador,» 20 11 2014. [En línea]. Available:http://c2.com/cgi/wiki?ModelViewController.[Últimoacceso:1722016].

[40]

S.Carbonell,«DesarrollodeaplicacionesconelframeworkMVC,»1672012.[Enlínea].Available:https://miblogtecnico.wordpress.com/tag/asp-net-mvc-2/.[Últimoacceso:132016].

[41]

F. K. Kocher, «The SSL Protocol Version 3.0,» 18 11 1996. [En línea]. Available:https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00.[Últimoacceso:132016].

[42]

T. Drake-Brockman, «carrierwave,» [En línea]. Available:https://github.com/carrierwaveuploader/carrierwave.[Últimoacceso:132016].

[43]

2ndquadrant, «PostgreSQL,» [En línea]. Available:http://2ndquadrant.com/es/postgresql/.[Últimoacceso:1722016].

[44]

R. Chavarria, «R. Chavarria's Blog,» 4 3 2010. [En línea]. Available:http://rchavarria.github.io/blog/2010/03/04/principios-y-patrones-de-diseno/.

[45]

singlepageappbook, «Single page apps in depth,» [En línea]. Available:http://singlepageappbook.com/goal.html.[Últimoacceso:1722016].

[46]

Google,«AngularJS,»[Enlínea].Available:https://www.angularjs.org/.[Últimoacceso:1722016].

[47]

«RubyOnRails,»[Enlínea].Available:http://rubyonrails.org/.[Últimoacceso:2132016].

[48]

W.R.Duncan,«Aguide to theprojectmanagementbodyof knowledge,» [En línea].Available:http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf.

[49]

extremeprogramming, «Programación Extrema,» [En línea]. Available:http://www.extremeprogramming.org/.[Últimoacceso:132016].

[50]

K.Beck,«Manifiestoágil,»[Enlínea].Available:http://www.agilemanifesto.org/iso/es/.[Últimoacceso:132016].

[51]

«ToolsHero,» 2015. [En línea]. Available:http://www.toolshero.nl/projectmanagement/scrum-agile/.[Últimoacceso:2032016].

[52]

pomodorotechnique, «DO MORE AND HAVE FUN WITH TIME MANAGEMENT,» [Enlínea].Available:http://pomodorotechnique.com/.[Últimoacceso:1722016].

[53]

Git,«Git,»[Enlínea].Available:https://git-scm.com/.[Últimoacceso:1722016].

[54]

V. Driessen, «A successful Git branching model,» 05 1 2010. [En línea]. Available:http://nvie.com/posts/a-successful-git-branching-model/.[Últimoacceso:1722016].

[55]

P. C. Clements, «Software Architecture in Practice,» [En línea]. Available:https://profesores.ing.unab.cl/~gbadillo/archivos/cursos/software-arch/The%20Software%20Engineering%20Institute%20(SEI)%20/SA%20in%20practice.pdf.[Últimoacceso:1722016].

92

[56]

Techopedia, «Software Quality Assurance (SQA),» [En línea]. Available:https://www.techopedia.com/definition/4363/software-quality-assurance-sqa.[Últimoacceso:2222016].

[57]

O.García,«NomenclaturaEstándardelCódigoJava,»2282011.[En línea].Available:http://www.elclubdelprogramador.com/2011/08/22/java-nomenclatura-estandar-del-codigo-java/.[Últimoacceso:2222016].

[58]

L. Spindance, «GitHub,» [En línea]. Available: https://gist.github.com/lauram-spindance/a37c83ec9ed7721a34e4.[Últimoacceso:2222016].

[59]

ISTQB EXAM CERTIFICATION, «What is Alpha testing?,» [En línea]. Available:http://istqbexamcertification.com/what-is-alpha-testing/.[Últimoacceso:132016].

[60]

D.M.Basso,«PropuestadeMétricasparaProyectosdeExplotacióndeInformación,»[En línea].Available:http://sistemas.unla.edu.ar/sistemas/redisla/ReLAIS/relais-v2-n4-157-218.pdf.[Últimoacceso:132016].

93

15. Anexos

15.1. Anexo1:Cuestionarioparaartistasybandas

Cuestionario para músicos (bandas, solistas o compositores) El siguiente formulario fue desarrollado con el propósito de entender el proceso que debe atravesar un solista o banda de músicos que se inicia en el espectáculo para lograr sus primeras presentaciones.

*Obligatorio

1. Edad *

2. Nombre

3. 1) ¿Alguna vez participaste en una banda musical? * Tocando un instrumento o cantando ya sea profesional o por diversión Marca solo un óvalo.

Si No

Otro:

4. 2) ¿Lo seguís haciendo? * Ensayos al menos una vez al mes Marca solo un óvalo.

SiNo

Otro:

5. 3) En el caso de que ya no toques...porqué dejaron de tocar?

94

6. 4) ¿Alguna vez buscaste una banda para formar parte? * La banda buscó un nuevo integrante o tú buscaste formar parte de una banda armada (a través de páginas, periódicos, anuncios, etc.) Marca solo un óvalo.

Si No

Otro:

7. 5) ¿Llegaron a tocar en vivo? * Presentación en cumpleaños, eventos, boliches, pubs, etc. Marca solo un óvalo.

Si No

Otro:

8. 6) ¿Qué tan difícil es conseguir un toque o lugar para presentarse? * Marca solo un óvalo.

Fácil Muy

fácil Difícil

Muy difícil

Otro:

9. 7) ¿Por qué? *

10. 8) ¿Todos los integrantes de la banda utilizan smartphones, tablets e Internet? *

Marca solo un óvalo.

Si No

Otro:

11. 9) ¿Utilizan/utilizaron redes sociales para publicitar su banda? *

Marca solo un óvalo.

Si No

95

12. 10) ¿Alguna vez recibieron propuestas de tocar en vivo por este medio? * Marca solo un óvalo.

Si No

Otro:

13. 11) ¿Crees que para los músicos amateur es un problema difícil conseguir donde

presentarse? * Marca solo un óvalo.

Si No

Otro:

14. 12) ¿Crees que hay suficientes lugares para tocar en vivo? *

15. 13) ¿Cuál crees que es el obstáculo más grande para las bandas uruguayas

amateur? *

16. 14) Qué medio de difusión utilizan para promocionar la banda? *

Como logran hacerse conocer, presentar su música, mostrarse...

17. 15) Realizan otras actividades relacionadas con la música? Trabajo, estudio, otros

18. 16) Estudian o trabajan la mayoría de los integrantes? *

Selecciona todos los que correspondan.

Estudia

Trabaja

Otro:

19. 17) Invierten o invirtieron en alguna campaña publicitaria para la banda? *

Anuncios, propaganda en Facebook, MercadoLibre (u otros), etc. Marca solo un óvalo.

Si No

Otro

20. 18) Subieron alguna canción a youtube o servicios similares? *

Marca solo un óvalo.

Si No

Otro:

21. 19) Cuales usaron?

Ejemplo youtube...

97

15.2. Anexo2:Resultadosdeencuesta

Concepto Datos PorcentajeEdad promedio de encuestados 26Desviación estandar 7Rango mínimo de edad 19Rango máximo de edad 32

Cantidad de personas entre 19 y 32 años 91 78%Cantidad de personas total 117

Cantidad de personas que siguen tocando 91 78%Cantidad de personas que ya no tocan 26 22%

Cantidad personas que buscaron una banda 89 76%Cantidad personas que no buscaron una banda 28 24%

Cantidad personas que llegaron a tocar en vivo 111 95%

Cantidad personas que no llegaron a tocar en vivo 6 5%

Conseguir donde tocar…Muy fácil 3 3%Fácil 33 28%Difícil 57 49%Muy difícil 13 11%Otros 11 9%

Todos los integrantes usan smartphone, tablet y/o internet?Si 78 67%No 30 26%Otros 9 8%

Utilizaron redes sociales para promocionarse?Si 109 93%No 2 2%Otro 6 5%

Recibieron propuestar de tocar en vivo por este medio?Si 79 68%No 31 26%Otro 7 6%

Crees que para los músicos amateur es un problema difícil conseguir donde presentarse?Si 85 73%No 26 22%Otro 6 5%

Medios utilizados para promocionarseFacebookYoutubeSoundcloudRadiosPegatinas, volantes, afichesBoca a bocaPáginas webRedes sociales

Invierten o invirtieron en alguna campaña publicitaria para la banda?Si 16 30%No 37 70%Otro 0

Subieron algun tema a Youtube o servicios similares?Si 50 96%No 2 4%Otro 0

Personas que hayan entrado a ver algún video?Más de 100 22Más de 1.000 15Más de 10.000 7Más de 100.000 0Otros 2

98

15.3. Anexo3:Benchmarking

Benchmarking

Spotify

Esunaaplicacióndereproduccióndemúsicaquecuentaconmásde75millonesdeusuariosactivos.

Quienespuedensubirmúsica:Permitesubirmúsicaúnicamentealosartistasquepertenezcanaunsellodiscográficooaesténasociadosaundistribuidordemúsicadigitalconelcualspotifytengaconvenio.

Quienespuedenescucharmúsica:Cualquierusuarioregistrado,elregistroserealizadeformagratuitacompletandounformulariowebosincronizandounacuentadefacebook.

Interoperabilidad:Ademásdecontarconunaaplicaciónwebtambiéncuentaconaplicacionesespecíficasparadistintossistemasoperativos.LaaplicaciónsepuededescargarparaWindows.OSX,Android,iOS,Symbian,WindowsPhone,Linux,BlackberryOS,ChromeOS,FireOS,SonyPlaystation3ySonyPlaystation4.

Disponibilidaddelcontenido:Laversióngratuitadespotifyrequieredeconexiónainternetparaaccederalcontenido.EncuantoalaversiónPremiumpermitealosusuariosdescargarlamúsicaparareproducirlasinconexión.

Radio:Permitecrearradiosbasadasenartistas,álbumesocancionescreandounalistadereproducciónconcancionesdecaracterísticassimilaresalaspectoseleccionado.

Redsocial:Cumpleconalgunascaracterísticasbásicasdeunaredsocialcomoseguirotrosusuarios,teinformalaúltimacanciónescuchadadelosusuariosqueseguís,cuandounartistaelcualesseguidoporelusuariosesubenuevocontenido.

UI/UX:Elsitiopresentainterfazamigableyusabilidadintuitiva.Sedestacalaformaenquedespliegalasfuncionalidadesprincipales,usandounabarraizquierdalateralparanavegarentrecadauna,unabarrasuperiordondeseencuentraelbuscadorymuestraelusuarioqueseencuentrablogueado,elusodetabsparalanavegabilidaddentrodelcontenidodeunavistacomoloesladelartistayporúltimoelreproductorsituadoenelinferiordelsitiosiemprevisible.

99

Otrasfuncionalidades:Ofrecealosusuariosunalistallamadadescubrimientosemanalquesemodificasemanalmenteycontienecancionesbasadasenlosartistasqueunosigueylosqueescuchodurantelasemana.Tambiénpermitecrearplaylistalosusuarios.

SoundCloud

SoundCloudesunaplataformadedistribucióndeaudioenlíneaenlaquesususuariospuedencolaborar,promocionarydistribuirsusproyectosmusicales

Quienespuedensubirmúsica:Permitesubirmúsicaatodousuarioqueseencuentreregistrado.

Quienespuedenescucharmúsica:Noesnecesariotenerunaestarregistradoparareproducirmúsicayaquepermitereproducirybuscarcontenidodemaneraanónima.

Registro:Losusuariospuedenregistrasecompletandoelformulariowebosincronizandounacuentadefacebookogoogle.

Interoperabilidad:AdemásdecontarconunaaplicaciónwebtambiéncuentaconaplicacionesespecíficasparadistintossistemasoperativosestossonAndroid,iOSyFireOS.

Disponibilidaddelcontenido:Elcontenidoseencuentradisponibleacualquierpersonaconaccesoainternet.

Radio:Permitecrearradiosbasadasenartistasocancionescreandounalistadereproduccióndecaracterísticassimilaresalaspectoseleccionado.

100

Redsocial:Permitecomentarlascancionessubidasalaplataformadestacándosepodercomentarunmomentoespecificodelacancióndejandountagvisibleenlamisma,darmegustaalascanciones.Brindalafuncionalidaddeseguirotrosusuariosydenotificarsusactividadesdentrodelaaplicación.Porúltimopermiteelenviódemensajesentreusuarios.

UI/UX:Elsitiotieneunainterfazamigableeintuitiva.Tieneunabarrasuperiorparaaccederalasfuncionalidadesprincipalesademásseencuentraelbuscadorenestabarra,utilizatabsparalanavegacióndelcontenidodentrodelasvistasyelreproductorsituadoenelinferiordelsitiosiemprevisible.

Otrasfuncionalidades:Permitealusuarioelegirquecancionespuedenserdescardasporotrosdeformagratuita.Ofrececontadoresdereproduccióndelascanciones,likes,comentarios,descargas,repostsademásdegraficasdelaevolucióndelosanterioreseneltiempo,estasfuncionalidadessoloparausuariospremium.

Reverbnation

Quienespuedensubirmúsica:Permitesubirmúsicaatodousuarioqueseencuentreregistradoconelroldeartista.Elrolseseleccionaenelregistro.Lacuentasecreamedianteformulariowebosincronizandounacuentadegoogleofacebook

Quienespuedenescucharmúsica:Noesnecesariotenerunaestarregistradoparareproducirmúsicayaquepermitereproducirybuscarcontenidodemaneraanónima.

101

Interoperabilidad:Cuentaconunsitiowebpermitiendoseraccesibledecualquiersistemaoperativoconaccesoainternet.TieneunaaplicaciónparausuariosconelroldeartistascompatibleparaAndroideiOS.

Disponibilidaddelcontenido:Elcontenidoseencuentradisponibleacualquierpersonaconaccesoainternet.

Redsocial:Brindalasfuncionalidadesdeseguirotrosusuariosydejarcomentariosenelperfildeestos.

UI/UX:Lainterfazyusabilidadesaceptable.Lasdistintasfuncionalidadesseencuentranenlabarrasuperioragrupadasporcategorías,labúsquedatambiénseencuentraenestabarrayelnavegadorestásituadoenlaparteinferior.

Otrasfuncionalidades:Reverbnationestáenfocadoaldesarrollodelartistaporloqueestaplataformalebrindamuchasfuncionalidadesyoportunidadesentreellasseencuentralaposibilidaddeencontrarlocalespararealizarunapresentaciónenvivo,permitealartistavendersumúsica,permitecontactarconsellosdiscográficosybrindaherramientasaestosparaencontrarnuevostalentos.Muchasdeestasfuncionalidadesyoportunidadessonparausuariospremium.

Bandcamp

Bandcampesunatiendademúsicaenlíneaademásdeunaplataformadelanzamientoydepromoción.

Quienespuedensubirmúsica:Permitesubirmúsicaatodousuarioqueseencuentreregistradoconelroldeartistaosellodiscográfico.

102

Quienespuedenescucharmúsica:Noesnecesariotenerunaestarregistradoparareproducirmúsicayaquepermitereproducirybuscarcontenidodemaneraanónima.

Registro:Elregistroserealizacompletandounformulariowebysedebeseleccionarelrolconelcualseregistra.

Interoperabilidad:CuentaconunsitiowebpermitiendoseraccesibledecualquiersistemaoperativoconaccesoainternetademástieneaplicacionesparaiOSyAndroid.

Disponibilidaddelcontenido:Elcontenidoseencuentradisponibleacualquierpersonaconaccesoainternet.

Redsocial:Brindalasfuncionalidadesdeseguirotrosusuariosyenviaremailalartista.

UI/UX:Lainterfazyusabilidadnoesaceptable.Suprincipalcarenciaesquenopermitereproducirunacanciónynavegardentrodelaplataformaalavez.

Otrasfuncionalidades:Bandcampestáenfocadoenlaventademúsicaonlinelacualessuprincipalfuncionalidad.Brindaalartistatenerunatiendademerchandisingonline,estadísticasdelamúsicaquesetieneenelsitio.

103

15.4. Anexo4:SprintplannigmeetingSprintPlanningMeeting1Losobjetivosplanteadosporelequipoparaestesprintfuerontenerunabasedecódigodelbackendydelfrontendwebymóvil,empezaradiseñarlainterfazdelasplataformaswebymóvilyademásdecrearlaestructuradelabasededatosysusentidades.Lastareasquesedeterminaronparaestesprintfueron:CrearlaestructuradelabasededatosSQLCrearlasentidadescorrespondientesenRubyDiseñarinterfazparalasplataformaswebymóvilAdemásseseleccionaronlassiguientesusarstoriesdelproductbacklog:Lasuserstoriesdeberíanserdesarrolladasparatantoelbackendcomoparaelforntend(webymóvil).

104

SprintPlanningMeeting2Losobjetivosplanteadosporelequipoenestesprintfueronrealizarloscambiosplanteadosenlaestructuradelabase,lasentidadesyeldiseñodelainterfaz,ademásseseleccionaronlassiguientesuserstories: