FaceSampler: Selección automática de mostras do usuario para un sistema non colaborativo de verificación de rostros

Escola T´ ecnica Superior de Enxe˜ nar ´ ıa Universidade de Santiago de Compostela FaceSampler Selecci´on autom´atica de mostras do usuario para un sistema non colaborativo de verificaci´on de rostros Autor: Fernando Est´evez Casado Titores: Xos´e Manuel Pardo L´opez Roberto Iglesias Rodr´ıguez Grao en Enxe˜nar´ıa Inform´atica Xullo 2017 Traballo de Fin de Grao presentado na Escola T´ecnica Superior de Enxe˜nar´ıa da Universidade de Santiago de Compostela para a obtenci´on do Grao en Enxe˜nar´ıa Inform´atica D. Xos´e Manuel Pardo L´opez, Profesor do Departamento de Electr´onica e Computaci´on da Universidade de Santiago de Compostela, e D. Roberto Iglesias Rodr´ıguez, Profesor do Departamento de Electr´onica e Computaci´on da Universidade de Santiago de Compostela, INFORMAN: Que a presente memoria, titulada FaceSampler: Selecci´on autom´atica de mostras do usuario para un sistema non colaborativo de verificaci´on de rostros, presentada por D. Fernando Est´evez Casado para superar os cr´editos correspondentes ao Traballo de Fin de Grao da titulaci´on de Grao en Enxe˜nar´ıa Inform´atica, realizouse baixo a nosa direcci´on no Departamento de Electr´onica e Computaci´on da Universidade de Santiago de Compostela. E para que as´ı conste aos efectos oportunos, expiden o presente informe en Santiago de Compostela, a 6 de xullo de 2017: O titor, O cotitor, O alumno, Xos´e M. Pardo L´opez Roberto Iglesias Rodr´ıguez Fernando Est´evez Casado i ii A Rub´en e Glauco, pola paciencia que tiveron escoitando os meus problemas a diario e por ser os primeiros voluntarios en probar a aplicaci´on. A Xos´e, Roberto e Carlos, por confiar en min e adicarme o seu tempo sempre que o necesitei. ´ A mi˜na familia, por apoiarme en todas as decisi´ons que levo tomado no meu cami˜no profesional e por axudarme tanto nos momentos dif´ıciles. iii iv ´ Indice xeral 1. Introduci´on 1 1.1. Obxectivos do proxecto . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Descrici´on t´ecnica . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Enunciado do alcance do proxecto . . . . . . . . . . . . . . . . . . 5 1.3.1. Descrici´on do alcance . . . . . . . . . . . . . . . . . . . . . 6 1.3.2. Criterios de aceptaci´on do produto . . . . . . . . . . . . . 6 1.3.3. Entregables .......................... 7 1.3.4. Exclusi´ons........................... 7 1.3.5. Restrici´ons........................... 8 1.3.6. Supostos............................ 8 1.4. Participantes ............................. 9 2. Especificaci´on de requisitos 11 2.1. Definici´on de prioridades . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Requisitos non funcionais . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1. Usabilidade .......................... 16 2.3.2. Seguridade........................... 18 2.3.3. Eficiencia ........................... 20 2.3.4. Portabilidade e escalabilidade . . . . . . . . . . . . . . . . 21 2.3.5. Fiabilidade .......................... 22 2.4. Cat´alogo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.1. Navegaci´on .......................... 23 2.4.2. Control de procesos . . . . . . . . . . . . . . . . . . . . . . 30 2.4.3. Xesti´on de preferencias . . . . . . . . . . . . . . . . . . . . 35 2.4.4. Matrices de trazabilidade . . . . . . . . . . . . . . . . . . . 40 3. Xesti´on do proxecto 41 3.1. Plan de xesti´on da configuraci´on . . . . . . . . . . . . . . . . . . . 42 3.2. Plan de xesti´on de riscos . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.1. Metodolox´ıa.......................... 45 3.2.2. Activos e ameazas . . . . . . . . . . . . . . . . . . . . . . 48 v 3.2.3. Especificaci´on de riscos . . . . . . . . . . . . . . . . . . . . 49 3.3. Planificaci´on temporal . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3.1. Estrutura de Descomposici´on do Traballo . . . . . . . . . . 55 3.3.2. Cronograma.......................... 57 3.4. Plan de xesti´on de Recursos Humanos . . . . . . . . . . . . . . . 60 3.4.1. Plan de formaci´on . . . . . . . . . . . . . . . . . . . . . . 61 3.5. Plan de xesti´on de custos . . . . . . . . . . . . . . . . . . . . . . . 62 3.5.1. Estimaci´on de custos . . . . . . . . . . . . . . . . . . . . . 63 3.5.2. Plan de control de custos . . . . . . . . . . . . . . . . . . . 65 3.6. Plandeprobas ............................ 66 3.6.1. Estratexia de construci´on . . . . . . . . . . . . . . . . . . 66 3.6.2. Riscos do plan de probas . . . . . . . . . . . . . . . . . . . 68 3.6.3. Definici´on de probas . . . . . . . . . . . . . . . . . . . . . 69 3.6.4. Definici´on de casos de proba . . . . . . . . . . . . . . . . . 70 3.7. Plan de xesti´on das comunicaci´ons . . . . . . . . . . . . . . . . . 79 3.7.1. Xesti´on dos interesados . . . . . . . . . . . . . . . . . . . . 79 3.7.2. Reuni´ons............................ 80 4. Proposta 81 4.1. A toma de decisi´ons . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.1.1. Obtenci´on do patr´on . . . . . . . . . . . . . . . . . . . . . 84 4.1.2. Algoritmos de clasificaci´on . . . . . . . . . . . . . . . . . . 86 4.2. A xesti´on eficiente dos recursos . . . . . . . . . . . . . . . . . . . 87 4.2.1. Procesos e sub-procesos . . . . . . . . . . . . . . . . . . . 88 4.2.2. Modalidades de execuci´on e eventos disparadores . . . . . 89 4.3. As tecnolox´ıas empregadas . . . . . . . . . . . . . . . . . . . . . . 91 4.3.1. Equipo e dispositivo de desenvolvemento . . . . . . . . . . 91 4.3.2. Ferramentas.......................... 91 4.3.3. Linguaxes de programaci´on . . . . . . . . . . . . . . . . . 92 4.3.4. Dependencias e bibliotecas . . . . . . . . . . . . . . . . . . 92 5. Dese˜no 93 5.1. Arquitectura do sistema . . . . . . . . . . . . . . . . . . . . . . . 93 5.2. Dese˜no da capa de presentaci´on . . . . . . . . . . . . . . . . . . . 98 5.2.1. Estratexia de dese˜no . . . . . . . . . . . . . . . . . . . . . 98 5.2.2. Interfacefinal......................... 99 5.2.3. An´alise heur´ıstica de usabilidade . . . . . . . . . . . . . . 104 5.3. Dese˜no da capa de control . . . . . . . . . . . . . . . . . . . . . . 106 5.4. Dese˜no da l´oxica de negocio . . . . . . . . . . . . . . . . . . . . . 109 5.4.1. M´odulo de Recolecci´on de datos . . . . . . . . . . . . . . . 109 5.4.2. M´odulo de Procesamento de imaxes . . . . . . . . . . . . . 113 5.4.3. M´odulo de Aprendizaxe . . . . . . . . . . . . . . . . . . . 116 5.5. Descrici´on da interacci´on . . . . . . . . . . . . . . . . . . . . . . . 119 vi 6. Execuci´on de probas e beta privada 127 6.1. Informe de execuci´on das probas . . . . . . . . . . . . . . . . . . . 127 6.2. Betaprivada.............................. 128 6.2.1. Postaapunto......................... 131 6.2.2. Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . 132 6.3. Informe de incidencias . . . . . . . . . . . . . . . . . . . . . . . . 135 7. Conclusi´ons e traballo futuro 141 A. Glosario 143 A.1.Siglaseacr´onimos........................... 143 A.2.Definici´ons............................... 143 B. Documentos anexos 145 C. Manual de usuario 147 C.1.Descrici´onxeral............................ 147 C.2. Requisitos de instalaci´on . . . . . . . . . . . . . . . . . . . . . . . 147 C.3. Descarga e instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . 148 C.4.Primeirospasos............................ 148 C.5.Preferencias.............................. 149 D. Prototipo de detector de rostros en Java 151 E. Estudo da precisi´on dos m´etodos usados 153 E.1. Medidores xen´ericos . . . . . . . . . . . . . . . . . . . . . . . . . . 153 E.2. Medidores espec´ıficos . . . . . . . . . . . . . . . . . . . . . . . . . 154 Bibliograf´ıa 157 vii 2CAP´ ITULO 1. INTRODUCI ´ ON Usualmente, nun sistema de reco˜necemento facial com´un, t´omase unha imaxe do rostro do individuo e proc´esase para obter os seus puntos caracter´ısticos. Logo, contr´astase esta informaci´on cun modelo dese suxeito, o que permite clasificar a cara como pertencente ´a persoa ou non. Para obter dito modelo, sen embargo, prec´ısase dispor dun n´umero suficiente de mostras de adestramento da cara do individuo, que permitan constru´ır unha codificaci´on do rostro o m´ais robusta e discriminante posible. Esta ´e a raz´on pola que se foron creando nos ´ultimos anos grandes bancos de datos de imaxes anotadas de acceso p´ublico como LFW [2], FDDB [3] ou YTF [4]. Sen embargo, s´o se constru´ıron uns poucos bancos de datos de acceso p´ublico para o reco˜necemento biom´etrico no ´ambito dos dispositivos m´obiles, como MOBIO [5] ou o de PASC [6], o que impediu o avance nesta li˜na. Pero, o que ´e peor, as imaxes provintes deste tipo de bancos soen estar moi nesgadas, isto ´e, existen diferenzas significativas entre elas. A captaci´on de imaxes mediante c´amaras en dispositivos m´obiles est´a suxeita a caracter´ısticas espec´ıficas non s´o a nivel de sensores (escala, resoluci´on, etc.), sen´on tam´en relacionadas coa forma de usar tales dispositivos (orientaci´on, expresi´on, iluminaci´on, etc.). Todo isto esixe que, para acadar o mellor rendemento, se deba dispor de mostras de caras para a aprendizaxe espec´ıficas do contexto. Neces´ıtase, por´en, unha ferramenta que poida ser instalada polo individuo no seu m´obil e que o “acompa˜ne” no seu d´ıa a d´ıa. Esta ferramenta debe traballar sen a colaboraci´on do suxeito, pero debe saber cando capturar imaxes para obter boas mostras do seu rostro. Para elo, compre que se axude da informaci´on relativa ao estado do dispositivo: orientaci´on, iluminaci´on ambiental, manipulaci´on por parte do usuario, etc. A trav´es deste traballo pret´endese apoiar esta li˜na de investigaci´on, en particular no relativo ´a aprendizaxe autom´atica (no propio dispositivo m´obil) para a captaci´on das caras dos usuarios. Pres´entase as´ı FaceSampler, unha aplicaci´on Android que implementa a proposta anterior e ten unha dobre utilidade. Por un lado, funciona como ferramenta stand-alone que permite obter as mostras dos rostros dos usuarios. Polo outro, nun futuro poder´ıan aproveitarse as s´uas funcionalidades para traballar como mecanismo de selecci´on de mostras de cada usuario durante todo o tempo de vida dunha aplicaci´on de verificaci´on de caras. 1.1. Obxectivos do proxecto Pres´entanse a continuaci´on os obxectivos do proxecto. Compre diferenciar entre obxectivos xerais e espec´ıficos. 1.1. OBXECTIVOS DO PROXECTO 3 Obxectivo xeral Identif´ıcase un ´unico obxectivo xeral, que se formula en base ´a motivaci´on e ´a finalidade principal do proxecto. Obxectivo OBX-1 Nome: Elaboraci´on dun software para a captura de rostros. Versi´on: 1.0 Descrici´on: Desenvolver un software para a captura de rostros de usuario en dispositivos m´obiles nun entorno non colaborativo que permita xerar un conxunto de mostras de adestramento de calidade para a posterior construci´on dun modelo que se poida empregar na fase posterior de identificaci´on. Sub-obxectivos: [OBX-2], [OBX-3] Importancia: Vital Urxencia: Alta Estado: Cumprido Estabilidade: Alta Obxectivos espec´ıficos Der´ıvanse do obxectivo xeral e pretenden concretalo, sinalando o cami˜no a seguir para conseguilo. Indican os efectos espec´ıficos que se queren acadar a´ında que non expliciten acci´ons directamente medibles. Obxectivo OBX-2 Nome: Reco˜necemento facial. Versi´on: 1.0 Descrici´on: Lograr que a aplicaci´on m´obil sexa capaz de tomar imaxes do usuario do dispositivo sen a participaci´on activa do mesmo, a partir desas imaxes, discriminar entre aquelas que presenten un rostro humano e aquelas nas que non se de esta situaci´on. Sub-obxectivos: Non aplica. Importancia: Vital Urxencia: Alta Estado: Cumprido Estabilidade: Alta Obxectivo OBX-3 Nome: Toma de decisi´ons. Versi´on: 1.0 4CAP´ ITULO 1. INTRODUCI ´ ON Obxectivo OBX-3(cont) Descrici´on: Dotar ´a aplicaci´on coa capacidade de aprendizaxe para a toma de decisi´ons na captura de fotograf´ıas en base a eventos e condici´ons do entorno, de xeito que se procure a maior eficiencia posible, maximizando as mostras de ´exito (sendo estas aquelas imaxes nas que se poida detectar alg´un rostro). Sub-obxectivos: Non aplica. Importancia: Alta Urxencia: Media Estado: Cumprido Estabilidade: Alta 1.2. Descrici´on t´ecnica Tal e como se resume nos obxectivos do apartado anterior, durante este proxecto desenvolveuse unha aplicaci´on para dispositivos m´obiles. Concretamente, elixiuse traballar con dispositivos Android fronte a iOS polas vantaxes que este sistema operativo aportaba para o afrontamento do problema (cota de mercado, bibliotecas de c´odigo aberto dispo˜nibles, etc.). A aplicaci´on ´e capaz de decidir en que momento tomar unha fotograf´ıa co fin de detectar na mesma o rostro do usuario. Para isto, int´egranse diferentes algoritmos de aprendizaxe que facilitan a toma de decisi´ons apoi´andose nun conxunto de datos de adestramento e a informaci´on do entorno (captada mediante os propios sensores do dispositivo e a identificaci´on de determinados comportamentos de usuario e demais eventos disparadores). Proc´urase a m´axima eficiencia da aplicaci´on [OBX-3] mediante a obtenci´on dunha boa porcentaxe de mostras v´alidas (imaxes de calidade e con rostro, que serven para a construci´on dun modelo) considerando os limitados recursos que un dispositivo m´obil pode ofertar. Compre lembrar que a aplicaci´on est´a suxeita a requirimentos de tempo real, polo que un factor importante ´e o consumo. Int´entase por´en minimizar o consumo de enerx´ıa e evitar monopolizar os recursos de procesamento. Para a detecci´on de rostros util´ızase un detector facial baixo o m´etodo de ViolaJones [7]. Concretamente, empregouse a biblioteca de uso libre de visi´on artificial OpenCV, xa que disp´on dunha versi´on para dispositivos Android. A algoritmia de aprendizaxe seleccionouse conforme evolucionou o proxecto, tendo presentes en todo momento as limitaci´ons temporais. Ata a data, integr´aronse dous algoritmos de clasificaci´on supervisada, con d´uas etapas diferenciadas (adestramento e explotaci´on). O primeiro deles ´e k-nearest neighbors (k-NN) [8], inclu´ıdo entre os m´ais simples de todos os algoritmos de aprendizaxe autom´ati- 1.3. ENUNCIADO DO ALCANCE DO PROXECTO 5 co. O segundo ´e a m´aquina de soporte vectorial (SVM) proporcionada pola biblioteca OpenCV [9]. No referente ´a informaci´on do entorno, foi preciso seleccionar aquelas fontes que realmente fosen de utilidade na toma de decisi´ons. En calquera caso, hai que ter en conta que a dotaci´on de intelixencia non supuxo unha fase illada do proxecto, pois implicou a realizaci´on de cambios ao longo da fase de implementaci´on en base ´a experimentaci´on de alternativas. Por iso, un requisito de dese˜no ´e a flexibilidade e modularidade da ferramenta, en canto a que a s´ua arquitectura permita a incorporaci´on de novas variables de entorno e novos algoritmos de aprendizaxe a posteriori. O dispositivo que se empregou nas fases de desenvolvemento e probas ´e un BQ Aquaris E5s. Este smartphone conta coa versi´on 5.1.1 de Android (Lollipop) que, a pesar de non ser a m´ais recente (a ´ultima ´e a 7.1.1, Nougat), non presentou ning´un problema de compatibilidade no referente ao desenvolvemento da aplicaci´on. Por outro lado, a calidade da imaxe poder´ıa chegar a ser un factor limitante hai tres ou catro anos, cando as c´amaras frontais dos m´obiles non ti˜nan un rol importante. Non obstante, debido ´a tendencia actual dos denominados selfies e da mellora constante das especificaci´ons dos smartphones, a maior´ıa dos dispositivos incl´uen unha c´amara frontal de 1 ou 2 MP como m´ınimo, sendo cada vez m´ais habituais os 5 ou 8 MP en gamas medias. No noso caso, o Aquaris E5s disp´on dunha c´amara frontal de 5 MP, Full HD a 30 fps. Finalmente, no relativo ao modelo de traballo, en vistas dun entorno variable, cuns requisitos pouco definidos que foron cambiando no transcurso do proxecto, onde a flexibilidade e a produtividade foron sempre fundamentais, optouse rexeitar os ciclos de vida tradicionais. No seu lugar, empregouse unha metodolox´ıa ´axil propia, baseada no modelo Scrum [10]. Isto facilitou a realizaci´on de entregas parciais e regulares do produto final, adoptando unha estratexia incremental que permit´ıa o solapamento das diferentes fases do desenvolvemento, en lugar de realizar unha tras outra de xeito illado nun ciclo secuencial ou en cascada. 1.3. Enunciado do alcance do proxecto A presente secci´on introduce un conxunto de detalles e compromisos relativos ao proxecto, os cales sentan as bases da envergadura do mesmo. Pret´endese as´ı asegurar que todos os stakeholders te˜nen un co˜necemento com´un do seu alcance. 6CAP´ ITULO 1. INTRODUCI ´ ON 1.3.1. Descrici´on do alcance A meta deste proxecto ´e crear unha aplicaci´on para dispositivos m´obiles Android que permita obter un banco de mostras do rostro do usuario. O proceso de mostraxe ser´a levado a cabo con certo criterio. Isto implica que o sistema integrar´a certa intelixencia artificial orientada ´a toma de decisi´ons. Para elo, empregaranse un ou m´ais algoritmos de aprendizaxe supervisado. Este tipo de algoritmos comp´o˜nense de d´uas etapas: adestramento e explotaci´on. O propio usuario do dispositivo poder´a efectuar o adestramento en base aos seus h´abitos persoais se o desexa. A aplicaci´on ser´a empregada como ferramenta de apoio ´a investigaci´on no Centro Singular de Investigaci´on en Tecnolox´ıas da Informaci´on da Universidade de Santiago de Compostela (CiTIUS). Ser´a utilizada por un grupo reducido de usuarios co fin de obter un banco de mostras de cada un. Estes bancos servir´an para elaborar modelos das caras dos individuos, que ser´an utilizados nun futuro sistema de identificaci´on biom´etrica. Realizarase un seguimento dos usuarios, de xeito que ser´an beta testers da aplicaci´on, co obxectivo de atopar erros no produto. A ferramenta tam´en ofrecer´a un amplo abanico de opci´ons de configuraci´on, co fin de concederlle autoridade ao usuario. No Cap´ıtulo 2 p´odese consultar a especificaci´on detallada de funcionalidades e requirimentos do sistema. 1.3.2. Criterios de aceptaci´on do produto A continuaci´on rec´ollense os criterios que seguir´a o cliente para aceptar o produto: A aplicaci´on resulta ´util como ferramenta de apoio ´a investigaci´on, de xeito que se poden empregar os bancos de mostras que xera para crear modelos dos usuarios. O produto amosa capacidade de adaptaci´on, permitindo a integraci´on de forma doada de novas fontes de informaci´on, eventos e algoritmos de aprendizaxe. As mostras obtidas pola aplicaci´on rompen as limitaci´ons actuais. Disponse de mostras de caras para a aprendizaxe espec´ıficas do contexto1. 1A captaci´on de rostros en dispositivos m´obiles est´a suxeita a caracter´ısticas espec´ıficas tanto a nivel de sensores como relacionadas coa forma de usar o dispositivo, o que esixe que para acadar o mellor rendemento se deba dispor de mostras tomadas no contexto propio do dispositivo e o individuo. 1.3. ENUNCIADO DO ALCANCE DO PROXECTO 7 A ferramenta ´e compatible cun 65 % dos dispositivos do mercado, tomando como preferencia as versi´ons m´ais recentes e estendidas de Android. As´umese que o software presenta erros. Sen embargo, co fin de maximizar o n´umero de mostras obtidas, a recuperaci´on da aplicaci´on despois dun fallo ten que ser inmediata. Do mesmo xeito, non se tolera que se produzan fallos cunha frecuencia maior ao 10 % do tempo de uso da aplicaci´on. Estes criterios impactan directamente na especificaci´on de requirimentos do Cap´ıtulo 2. 1.3.3. Entregables O proxecto ter´a unha ´unica data de entrega, prevista para o 7 de xullo de 2017, que incluir´a: ´ Ultima versi´on estable da aplicaci´on Android. Memoria do proxecto. Isto non implica que o cliente non vaia poder ter acceso a ning´un elemento da configuraci´on do proxecto ata a data de entrega. Ao contrario, seguindo a filosof´ıa Scrum, participar´a activamente en moitas das actividades contempladas no ciclo de vida, e poder´a probar a ferramenta nas sucesivas versi´ons orixinadas ao remate de cada sprint. 1.3.4. Exclusi´ons As funcionalidades da aplicaci´on limitaranse ao especificado no Cap´ıtulo 2. Para evitar a m´ais m´ınima confusi´on entre as partes, a continuaci´on d´eixase constancia de todo aquilo que o produto final non vai contemplar: A ferramenta non ter´a a capacidade para identificar ao usuario do dispositivo, limitarase a tomar mostras de caras, que poder´an perfectamente pertencer a un intruso. O filtrado desas mostras non v´alidas realizarase a posteriori pero en ning´un caso ser´a tarefa do produto deste proxecto. Non todas as mostras tomadas ter´an que ser v´alidas para o seu posterior emprego na construci´on dun modelo do usuario. As´umese que un pequeno porcentaxe (non m´as dun 10 %) poder´an ter mala calidade (pouca nitidez, demasiado escuras, etc.) ou pertencer´an a outro individuo. A ferramenta non est´a orientada a que os usuarios poidan adestrar o tel´efono de xeito exhaustivo. Poderase levar a cabo un adestramento propio, pero 8CAP´ ITULO 1. INTRODUCI ´ ON non se garante que os resultados superen aos obtidos co adestramento por defecto. O fin desta funcionalidade ´e puramente demostrativo. A´ında que existan criterios de aceptaci´on relativos ´a compatibilidade, a aplicaci´on non ´e concibida como un produto que vaia a ser distribu´ıdo de xeito masivo, sen´on que ser´a empregado por un colectivo acoutado. Tan s´o se garantir´a a compatibilidade para os dispositivos que cumpran cos requirimentos dispostos no Ap´endice C.2 deste documento. En ning´un caso a aplicaci´on ser´a compatible con calquera outro sistema operativo para dispositivos m´obiles que non sexa Android: Windows Phone, iOS, Ubuntu Phone, etc. Tam´en ´e importante remarcar que queda fora do alcance do equipo de desenvolvemento calquera tarefa que non sexa a implementaci´on, xesti´on, despregamento ou mantemento do produto. Ademais, calquera gasto non previsto no plan de custos da Secci´on 3.5 que encareza o desenvolvemento do proxecto, como poden ser licenzas necesarias para a elaboraci´on da aplicaci´on ou taxas adicionais impostas por provedores de servizos, correr´an a conta do cliente, neste caso a USC. 1.3.5. Restrici´ons O desenvolvemento do proxecto verase limitado polas seguintes restrici´ons: O equipo de traballo comporase por un s´o individuo, que asumir´a os roles de Scrum Master, xefe de proxecto, analista, dese˜nador, programador e encargado de probas (ver plan de xesti´on de RRHH, Secci´on 3.4). O traballador non poder´a adicar a totalidade da s´ua xornada ao proxecto, sen´on que de media asignaralle o 40 % do seu tempo, o que aproximadamente se corresponde con 14 horas semanais (ver planificaci´on temporal, Secci´on 3.3). A duraci´on m´axima do proxecto non superar´a as 420 horas de traballo. A data l´ımite de entrega ser´a o 7 de xullo. 1.3.6. Supostos Os supostos do proxecto son os seguintes: Empregarase a ferramenta asumindo que a mesma est´a lonxe de ser un produto rematado. 1.4. PARTICIPANTES 9 Os individuos aos que se lle conceda o acceso ´a mesma ter´an un m´ınimo co˜necemento do seu funcionamento: saber diferencias etapas de aprendizaxe, co˜necer o significado de cada opci´on de settings, saber localizar as mostras tomadas, etc. 1.4. Participantes A T´aboa 1.4 recolle todas as partes interesadas ou stakeholders do proxecto. Para simplificar a t´aboa, om´ıtese intencionalmente a informaci´on sobre a entidade ou organizaci´on ´a que pertence cada individuo posto que todos eles traballan para a Universidade de Santiago de Compostela (USC). Tampouco se proporciona informaci´on de contacto do voluntariado por garantir a s´ua privacidade. Para maior detalle sobre a xesti´on do persoal, p´odense consultar as Secci´ons 3.4 e 3.7. Nome Contacto Descrici´on Fernando Est´evez Casado [email protected] Desenvolvedor ´unico de FaceSampler Xos´e M. Pardo L´opez [email protected] Representante do cliente Roberto Iglesias Rodr´ıguez [email protected] Cliente Carlos V´azquez Regueiro [email protected] Cliente Eric L´opez L´opez [email protected] Cliente Voluntariado - Conxunto de usuarios que accederon a seren beta testers da aplicaci´on. T´aboa 1.4: Stakeholders do proxecto. 10 CAP´ ITULO 1. INTRODUCI ´ ON Cap´ıtulo 2 Especificaci´on de requisitos Tradicionalmente veuse a tratar a captura e a xesti´on de requisitos do proxecto dun xeito que, cada vez m´ais, se amosa err´oneo. Entendeuse a captura como unha fase temper´a, que unha vez se remataba nos daba a fotograf´ıa exacta do que necesitaba o cliente. Un problema habitual ´e o enorme esforzo que sup´on facer unha captura en detalle dos requisitos. Tan enorme que rara vez xustifica o resultado. Outro dos problemas com´uns ´e que o cliente case nunca ten claras as s´uas propias necesidades coa profundidade suficiente como para definilas a priori e a isto s´umase que, acot´ıo, durante a vida do proxecto, ditas necesidades cambian. En Scrum, os requisitos expr´esanse como elementos da Pila de Produto ou Product Backlog [10]. A Pila de Produto ´e unha lista viva ordenada e priorizada dos requisitos funcionais e non funcionais en base ao seu valor para o cliente. Isto implica que os requisitos que nela aparecen e a orde dos mesmos ´e cambiante ao longo da vida do proxecto. Utilizar a Pila de Produto como principal artefacto para a xesti´on de requisitos perm´ıtenos atallar os problemas relacionados coa xesti´on de requisitos. Constru´ır e manter a Pila de Produto ´e unha tarefa ardua, pero ´e moito m´ais sinxelo que facer una captura de requisitos tradicional, posto que tan s´o hai que expresar a grandes trazos en que consiste cada requisito. S´o ´e preciso o nivel de detalle suficiente para poder estimar os requisitos e priorizalos. Evidentemente, antes da s´ua implementaci´on ser´a necesario refinar en maior detalle os mesmos, pero en Scrum iso ´e algo que se pode pospor ata a planificaci´on do sprint (iteraci´on) no que vamos a abordar estes requisitos en concreto. Pospor o refinado detallado ata un momento pr´oximo ´a su implementaci´on permite que cando realicemos esta actividade te˜namos en conta de novo as necesidades do cliente que puideron cambiar e contar coa informaci´on que adquirimos durante a implementaci´on de outros requisitos. Deste xeito, ao contar con m´ais informaci´on teremos 11 18 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS RNF-3 Indicar a detecci´on dun rostro (cont.) Comentarios: Esc´ollese por defecto a cor verde clara #00FF00 para o debuxado do cadro sobre o rostro. RNF-4 Notificar captura Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3] Descrici´on: Durante o proceso de mostraxe, cando o sistema decida tomar unha captura, deber´a notificala por medio dun aviso textual e sonoro. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: O aviso sonoro ser´a o habitual click empregado nas aplicaci´ons de c´amara e poder´a ser silenciado se o usuario o desexa. RNF-5 Idiomas Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3] Descrici´on: A aplicaci´on estar´a dotada de traduci´ons ao ingl´es, espa˜nol e galego. A selecci´on do idioma ser´a tarefa autom´atica do dispositivo en base ´a s´ua configuraci´on ling¨u´ıstica xeral. O idioma por defecto ser´a o ingl´es no caso de que o usuario non te˜na o dispositivo configurado nunha destas tres linguas. Importancia: Pode esperar Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.3.2. Seguridade Esta categor´ıa define aspectos relativos ´a pol´ıtica de privacidade da aplicaci´on. Posto que esta non incl´ue sistemas de control de acceso ou autenticaci´on, o factor destacado aqu´ı ´e a protecci´on de datos. Identif´ıcanse os seguintes requisitos: [RNF-6]: Pol´ıticas de privacidade. [RNF-7]: Permisos do sistema. 2.3. REQUISITOS NON FUNCIONAIS 19 [RNF-8]: Control sobre capturas e mostras. RNF-6 Pol´ıticas de privacidade Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: A aplicaci´on contar´a cunha pol´ıtica de privacidade detallada, accesible para todo usuario da mesma. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: O feito de publicar a ferramenta na Google Play Store esixe dispor dunha pol´ıtica de privacidade definida cando se toman permisos delicados do sistema. RNF-7 Permisos do sistema Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: O sistema deber´a solicitar os permisos que necesite (acceso ´a c´amara e almacenamento interno) de xeito que o usuario sexa consciente dos privilexios que lle est´a outorgando. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: O xeito de cumprir con este requisito vir´a dado en funci´on da versi´on de Android do dispositivo co que traballe o usuario. RNF-8 Control sobre capturas e mostras Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: Toda captura realizada polo sistema ser´a almacenada de xeito local na memoria interna do dispositivo, incluso cando sexa descartada para poder ser unha mostra do seu rostro. Deste xeito haber´a transparencia co usuario, xa que saber´a que informaci´on se est´a a recadar e ter´a o control sobre a mesma, podendo borrar aquelas capturas ou mostras que considere inapropiadas. Importancia: Importante Urxencia: Moderada 20 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS RNF-8 Control sobre capturas e mostras (cont.) Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.3.3. Eficiencia Esta categor´ıa define aspectos que indican a proporci´on entre o nivel de cumprimento do software e a cantidade de recursos necesitados baixo condici´ons establecidas. Obt´e˜nense os seguintes requisitos: [RNF-9]: Velocidade de adestramento. [RNF-10]: Velocidade de mostraxe. [RNF-11]: Velocidade de obtenci´on do banco de mostras. [RNF-12]: Taxa de acerto na toma de mostras. RNF-9 Velocidade de adestramento Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3] Descrici´on: O sistema debe ser capaz de procesar 2 imaxes por segundo durante a fase de adestramento en primeiro plano. Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: O feito de procesar unha imaxe durante o adestramento implica tam´en obter a informaci´on do entorno necesaria para o aprendizaxe (o estado). RNF-10 Velocidade de mostraxe Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3] Descrici´on: O sistema deber´a ter un per´ıodo de mostraxe m´ınimo de 5 segundos. Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.3. REQUISITOS NON FUNCIONAIS 21 RNF-11 Velocidade de obtenci´on do banco de mostras Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3] Descrici´on: O sistema permitir´a que un usuario medio sexa capaz de xerar un banco dun m´ınimo de 200 mostras en menos de 15 d´ıas de uso continuado. Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. RNF-12 Taxa de acerto na toma de mostras Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-3] Descrici´on: O sistema deber´a tomar capturas con certo criterio, de xeito que se permita que, de media, polo menos un 40 % desas capturas se convertan en mostras v´alidas. Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.3.4. Portabilidade e escalabilidade Esta categor´ıa define aspectos relacionados coa capacidade do sistema para adaptarse aos cambios de requirimentos, as´ı como aos distintos dispositivos e plataformas. Os requisitos non funcionais asociados son: [RNF-13]: Escalabilidade do m´odulo de aprendizaxe. [RNF-14]: Compatibilidade software. [RNF-15]: Compatibilidade hardware. RNF-13 Escalabilidade do m´odulo de aprendizaxe Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1],[OBX-3] Descrici´on: O sistema debe ser capaz de incorporar novos algoritmos de aprendizaxe. 22 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS RNF-13 Escalabilidade do m´odulo de aprendizaxe (cont.) Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. RNF-14 Compatibilidade software Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: A aplicaci´on debe ser como m´ınimo compatible coas versi´ons m´ais recentes e extendidas de Android. Consid´erase imprescindible que poida ser instalada en dispositivos con Android 5.0 (Lollipop) ou superior. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. RNF-15 Compatibilidade hardware Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: A aplicaci´on deber´a funcionar con normalidade en todo aquel dispositivo que conte cos sensores m´ınimos indispensables para a captura e o aprendizaxe: sensor de c´amara interior, aceler´ometro e xiroscopio. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.3.5. Fiabilidade Esta categor´ıa define aspectos relacionados coa capacidade do produto para manter o seu nivel de prestaci´on baixo condici´ons definidas e durante un per´ıodo de tempo establecido. Identif´ıcase un ´unico requisito non funcional: 2.4. CAT ´ ALOGO DE CASOS DE USO 23 RNF-16 Dispo˜nibilidade Versi´on: 1.0 Autores: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: As´umese a inestabilidade no produto, pero a probabilidade de falla nun d´ıa completo de uso da ferramenta non poder´a exceder o 10 %. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Sen comentarios. 2.4. Cat´alogo de casos de uso A continuaci´on pres´entase o cat´alogo completo de casos de uso da aplicaci´on. A Figura 2.1 amosa un diagrama en UML cos mesmos, agrupados en tres categor´ıas: navegaci´on,control de procesos exesti´on de preferencias. Nesta aplicaci´on non se contemplan roles de usuario. Isto quere dicir que todo individuo que a empregue ter´a os mesmos privilexios. Por´en, o noso sistema contempla un ´unico actor: Usuario Todo individuo que instale a aplicaci´on e faga uso normal da mesma no seu dispositivo m´obil Android. 2.4.1. Navegaci´on Incl´uense nesta categor´ıa aqueles casos de uso relacionados coa interacci´on entre o usuario e as distintas vistas da aplicaci´on, que non te˜nen relaci´on directa coas funcionalidades principais que brinda a mesma: [CU-1]: Iniciar a aplicaci´on. [CU-2]: Permutar entre mostraxe e adestramento. [CU-3]: Acceder ao panel de preferencias. [CU-4]: Volver ´a vista anterior. [CU-5]: Pausar a aplicaci´on. [CU-6]: Retomar a aplicaci´on. 24 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS Figura 2.1: Diagrama global de casos de uso. 2.4. CAT ´ ALOGO DE CASOS DE USO 25 CU-1 Iniciar a aplicaci´on Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1] Descrici´on: O usuario identifica a aplicaci´on no men´u de aplicaci´ons do seu dispositivo persoal e in´ıciaa. Actor Principal: Usuario Precondici´ons: A aplicaci´on foi instalada exitosamente no dispositivo en cuesti´on. Postcondici´ons: Ao usuario amosar´aselle a vista principal da aplicaci´on. Escenario principal: 1. O usuario accede ao men´u de aplicaci´ons do dispositivo. 2. O usuario identifica FaceSampler en base ´a s´ua icona e/ou o seu nome. 3. O usuario preme co dedo na icona da ferramenta e esta ´e lanzada. 4. Durante o lanzamento da aplicaci´on, o sistema aval´ıa se o dispositivo cumpre coas dependencias necesarias para o correcto funcionamento da mesma. 5. O usuario ve a vista principal da aplicaci´on, que ser´a aquela que por defecto permita iniciar a mostraxe, posto que ´e a finalidade principal da mesma. Extensi´ons: 5.a Se por calquera motivo o usuario non conta coa biblioteca OpenCV instalada no dispositivo, non poder´a empregar a ferramenta con normalidade. Por´en, ao iniciarse a aplicaci´on amosarase un di´alogo que lle facilitar´a o acceso ´a descarga da biblioteca desde a Play Store de Google. Este di´alogo non poder´a pecharse ata que o usuario resolva o problema, imped´ındolle as´ı o acceso ´as demais funcionalidades da ferramenta. 5.b Se o dispositivo do usuario carece dalg´un sensor que prov´e ao sistema de informaci´on vital para o aprendizaxe, ent´on notificarase o problema por pantalla cun di´alogo s´o a primeira vez que se inicie a aplicaci´on. O sistema ser´a quen de resolver esta carencia e funcionar igualmente, a´ında que sexa de xeito menos efectivo ou eficiente. Importancia: Vital Urxencia: Alta Estado: Validado Estabilidade: Alta Comentarios: Non se impuxeron restrici´ons en canto ao nome da aplicaci´on nin o dese˜no da s´ua icona. Prop´uxose FaceSampler como t´ıtulo e o actual logo como icona. Ambos foron aceptados polo cliente. 26 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS CU-1 Iniciar a aplicaci´on (cont.) Proba de aceptaci´on: O cliente poder´a probar a iniciar a aplicaci´on de xeito habitual. A maiores, simularanse as situaci´ons nas que se careza de OpenCV e alg´un dos sensores necesarios, de xeito que el poida ver como se resolven estes inconvenientes. CU-2 Permutar entre mostraxe e adestramento Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[CU-1] Descrici´on: O usuario cambia entre os modos de adestramento e explotaci´on da aplicaci´on. Actor Principal: Usuario Precondici´ons: O usuario iniciou a aplicaci´on [CU-1] seguindo o escenario principal. Postcondici´ons: A interface gr´afica reflectir´a sen lugar a confusi´on a selecci´on do usuario. Escenario principal: 1. O usuario, situado na vista principal da aplicaci´on, en modo mostraxe, cambia ao modo adestramento deslizando co dedo de esquerda a dereita sobre a pantalla. 2. A interface gr´afica actual´ızase conforme ´a tem´atica de adestramento. Extensi´ons: 1.a Se o usuario xa houbese cambiado antes de modo, situ´andose agora na vista de adestramento, o proceso ser´a inverso, tendo neste caso que deslizar de dereita a esquerda. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: A pesar de que o cliente non solicitou esta funcionalidade, considerouse que aporta valor ao produto mellorando a s´ua usabilidade, pois non se pode comparar con ter todo o control de adestramento e mostraxe mesturado nunha vista simple. Nas cuesti´ons de est´etica e de usabilidade o cliente sempre deu liberdade. Proba de aceptaci´on: Deixarase que o cliente permute entre modos e pedirase a s´ua aprobaci´on da usabilidade da interface. 2.4. CAT ´ ALOGO DE CASOS DE USO 27 CU-3 Acceder ao panel de preferencias Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[CU-1] Descrici´on: O usuario entra no panel de preferencias da aplicaci´on. Actor Principal: Usuario Precondici´ons: O usuario iniciou a aplicaci´on [CU-1] seguindo o escenario principal. Postcondici´ons: Am´osase o panel de preferencias actualizado, permitindo axustar as preferencias dispo˜nibles no momento, xa que non todas poden ser modificadas en determinados estados do sistema (durante a mostraxe, en modo aforro de enerx´ıa, etc). Escenario principal: 1. O usuario, situado na vista principal da aplicaci´on (ben sexa en modo adestramento ou mostraxe), accede ao panel de axustes pulsando na icona en forma de engrenaxe situada na esquina superior dereita da pantalla. Extensi´ons: Non aplica Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Se algunha preferencia non pode ser modificada no momento non ten por que ocultarse, poder´a ser bloqueada e mostrarse nunha cor escurecida para que o usuario saiba que non pode manipulala. Proba de aceptaci´on: O cliente poder´a acceder ´a pantalla de preferencias e estas amosaranse actualizadas en funci´on do estado do sistema. CU-4 Volver ´a vista anterior Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[CU-1],[CU-3] Descrici´on: O usuario retrocede de xeito voluntario ´a vista inmediatamente precedente. Actor Principal: Usuario Precondici´ons: O usuario iniciou a aplicaci´on e, partindo da vista principal, accedeu a unha vista secundaria, ben sexa o panel de preferencias, a vista de adestramento en primeiro plano, etc. 34 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS CU-10 Iniciar adestramento (cont.) Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: No seguinte caso [CU-11] especif´ıcanse as caracter´ısticas da citada vista de aprendizaxe. Proba de aceptaci´on: O cliente poder´a iniciar o adestramento desde a vista principal. CU-11 Adestrar dispositivo Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3],[CU-1],[CU-10], [RNF-3] Descrici´on: O usuario instr´ue ao dispositivo, de xeito que este logo saiba elixir o momento oportuno para realizar capturas co fin de obter mostras v´alidas. Actor Principal: Usuario Precondici´ons: O usuario iniciou o adestramento. Postcondici´ons: Non aplica. Escenario principal: 1. O usuario iniciou o proceso, polo que se atopa na vista de adestramento en primeiro plano. 2. O usuario vese retratado en tempo real. O sistema proporciona, informaci´on continua dos par´ametros empregados na aprendizaxe. 3. Cando se detecta o rostro do usuario, o sistema notifica ao mesmo [RNF-3]. Extensi´ons: Non aplica. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Polo de agora, de cara a unha demostraci´on, ´e dabondo con permitir un adestramento en primeiro plano. Sen embargo, nun futuro, poder´ıase integrar o proceso en segundo plano, tal e como se fai na mostraxe. Proba de aceptaci´on: O cliente poder´a instru´ır ao seu dispositivo durante o tempo que desexe, comprobando que os par´ametros amosados por pantalla son correctos e se notifica a detecci´on do rostro. Posteriormente comprobarase que o co˜necemento adquirido se ve reflectido no proceso de mostraxe. 2.4. CAT ´ ALOGO DE CASOS DE USO 35 CU-12 Deter adestramento Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-3],[CU-1],[CU-4],[CU-10] Descrici´on: O usuario det´en o proceso de adestramento. Actor Principal: Usuario Precondici´ons: O usuario iniciou o proceso de adestramento. Postcondici´ons: Amosarase a vista principal da aplicaci´on, no modo adestramento. Escenario principal: 1. Desde a vista de adestramento o usuario retrocede ´a vista principal [CU-4]. 2. O sistema actualiza o banco de datos do aprendizaxe co novo modelo xerado. Extensi´ons: Non aplica. Importancia: Importante Urxencia: Moderada Estado: Validado Estabilidade: Alta Comentarios: Tras a finalizaci´on dun novo adestramento, o sistema esquecer´a, de existir, o adestramento previo realizado polo usuario. Proba de aceptaci´on: O cliente finalizar´a o adestramento premendo no bot´on de regreso (ben o f´ısico ou o proporcionado pola aplicaci´on). Poder´a comprobar que se actualizou o banco de datos accedendo aos arquivos da aplicaci´on. 2.4.3. Xesti´on de preferencias Nesta categor´ıa incl´uense todos os casos de uso relacionados coa xesti´on de preferencias da aplicaci´on, que afectan de forma directa ´a experiencia de usuario e ao funcionamento dos procesos principais (mostraxe e adestramento): [CU-13]: Cambiar o algoritmo de aprendizaxe. [CU-14]: Cambiar temporizaci´on. [CU-15]: Xestionar o adestramento por defecto. [CU-16]: Xestionar os factores da aprendizaxe. [CU-17]: Xestionar notificaci´ons. 36 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS CU-13 Cambiar o algoritmo de aprendizaxe Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-3],[CU-1],[CU-3],[CU-7] Descrici´on: O usuario cambia o algoritmo de aprendizaxe. Actor Principal: Usuario Precondici´ons: O usuario navegou ata o panel de preferencias. Postcondici´ons: Actualizarase a informaci´on do panel de preferencias conforme ´a selecci´on. Escenario principal: 1. Desde o panel de preferencias, o usuario toca sobre a opci´on de algoritmo de aprendizaxe. 2. Aparece un di´alogo onde se amosan todas as alternativas, coa selecci´on actual marcada. 3. O usuario escolle outro algoritmo e os efectos son aplicados de inmediato no funcionamento do sistema. Extensi´ons: Non aplica. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Se a mostraxe est´a en execuci´on, a opci´on aparece deshabilitada posto que os cambios non se poder´ıan aplicar ata o remate do proceso. Proba de aceptaci´on: O cliente escolle outro algoritmo. Para comprobar que realmente se efectuou o cambio, poder´a ver o log do sistema desde o IDE Android Studio co fin de comparar as trazas xeradas cun algoritmo e con outro durante o proceso de mostraxe. CU-14 Cambiar temporizaci´on Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-2],[OBX-3],[CU-1],[CU-3] Descrici´on: O usuario cambia a temporizaci´on do sistema. Actor Principal: Usuario Precondici´ons: O usuario navegou ata o panel de preferencias. Postcondici´ons: Actualizarase a informaci´on do panel de preferencias conforme ´a selecci´on. Escenario principal: 2.4. CAT ´ ALOGO DE CASOS DE USO 37 CU-14 Cambiar temporizaci´on (cont.) 1. Desde o panel de preferencias, o usuario toca sobre unha opci´on da categor´ıa “Temporizaci´on” (Timings). 2. Aparece un di´alogo cun selector num´erico (number picker) da magnitude apropiada (milisegundos, segundos, minutos, etc). 3. O usuario escolle outra cantidade e os efectos son aplicados de inmediato na velocidade do sistema, se ´e que alg´un proceso se est´a executando. Extensi´ons: Non aplica. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Actualmente perm´ıtense catro modificaci´ons temporais que afectan ´a velocidade dos procesos de adestramento e mostraxe (ver Secci´on 4.2.2) Proba de aceptaci´on: O cliente proba a cambiar cada un dos per´ıodos posibles. Para comprobar que realmente se efect´uan os cambios, poder´a ver o log do sistema desde Android Studio co fin de ver as trazas de cada proceso acompa˜nadas do momento no que se efect´ua cada acci´on. CU-15 Xestionar o adestramento por defecto Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-3],[CU-1],[CU-3],[CU-12] Descrici´on: O usuario cambia o dataset a empregar na mostraxe, pudendo escoller entre un por defecto ou un creado por el no ´ultimo adestramento realizado. A aplicaci´on instalarase coa opci´on de adestramento por defecto marcada, e non poder´a cambiarse ata que o usuario realice un. Actor Principal: Usuario Precondici´ons: O usuario realizou un adestramento propio e logo navegou ata o panel de preferencias. Postcondici´ons: Actualizarase o panel conforme ´a selecci´on. Escenario principal: 1. Desde o panel de preferencias, o usuario toca sobre o cadro de verificaci´on (checkbox) chamado “Adestramento por defecto” (Default training). 2. Se a opci´on estaba marcada, desmarcarase, e ao rev´es. Os efectos son aplicados na seguinte mostraxe. 38 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS CU-15 Xestionar o adestramento por defecto (cont.) Extensi´ons: Non aplica. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Se a mostraxe est´a en execuci´on, a opci´on aparece deshabilitada posto que os cambios non se poder´ıan aplicar ata o remate do proceso. Proba de aceptaci´on: O cliente proba a cambiar a configuraci´on. Para comprobar que realmente se efect´uan os cambios, poder´a ver de ver a traza da mostraxe onde se indica se se est´a a empregar o adestramento por defecto desde o IDE. CU-16 Xestionar os factores da aprendizaxe Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[OBX-3],[CU-1],[CU-3],[CU-7] Descrici´on: O usuario activa e desactiva os distintos par´ametros empregados no aprendizaxe. Actor Principal: Usuario Precondici´ons: O usuario navegou ata o panel de preferencias. Postcondici´ons: Actualizarase a informaci´on do panel de preferencias conforme ´a selecci´on. Escenario principal: 1. Desde o panel de preferencias, o usuario toca sobre un elemento da categor´ıa “Factores de aprendizaxe” (Learning factors). 2. Se dito elemento estaba activo pasar´a a estar inactivo, e ao rev´es. Cada elemento ´e, por´en un interruptor (switch). Os efectos son aplicados de inmediato no funcionamento do sistema. Extensi´ons: Non aplica. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Se a mostraxe est´a en execuci´on, a opci´on aparece deshabilitada posto que os cambios non se poder´ıan aplicar ata o remate do proceso. Debido a que os factores poder´an cambiar nun futuro, este panel tam´en se ver´a modificado de ser necesario. Non te˜nen por que proporcionarse axustes para todos os elementos, tan s´o os que se considere oportuno permitir modificar. 2.4. CAT ´ ALOGO DE CASOS DE USO 39 CU-16 Xestionar os factores da aprendizaxe (cont.) Proba de aceptaci´on: O cliente proba a cambiar alg´un elemento. Para comprobar que realmente se efect´uan os cambios, poder´a ver o log do sistema desde Android Studio co fin de ver a traza da mostraxe onde se indica os par´ametros empregados. CU-17 Xestionar notificaci´ons Versi´on: 1.0 Autor: Fernando Est´evez Dependencias: [OBX-1],[CU-1],[CU-3] Descrici´on: O usuario activa e desactiva as distintas notificaci´ons dispostas na aplicaci´on, ben sexan visuais, sonoras, mediante vibraci´on, etc. Actor Principal: Usuario Precondici´ons: O usuario navegou ata o panel de preferencias. Postcondici´ons: Actualizarase a informaci´on do panel de preferencias conforme aos cambios realizados. Escenario principal: 1. Desde o panel de preferencias, o usuario toca sobre un elemento da categor´ıa “Notificaci´ons” (Notifications). 2. Se a opci´on estaba marcada, desmarcarase, e ao rev´es. Os efectos son aplicados de inmediato no funcionamento do sistema. Extensi´ons: Non aplica. Importancia: Quedar´ıa ben Urxencia: Baixa Estado: Validado Estabilidade: Alta Comentarios: Non se ten por que permitir a xesti´on de todas as notificaci´ons do sistema. Por exemplo, a notificaci´on de execuci´on dun servizo en segundo plano non poder´a ser deshabilitada, seguindo os criterios de boas pr´acticas de Android. Proba de aceptaci´on: O cliente proba a cambiar alg´un elemento. Para verificar que realmente se efect´uan os cambios, poderase forzar a execuci´on do evento que lanza a notificaci´on en cuesti´on. 40 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS 2.4.4. Matrices de trazabilidade Para rematar o cat´alogo de casos de uso, pres´entanse a continuaci´on d´uas matrices de trazabilidade. A primeira delas, T´aboa 2.1, amosa as relaci´ons entre os diversos casos de uso e os tres obxectivos do proxecto, permit´ındonos avaliar o valor de cada CU e as´ı priorizalos correctamente. Unha fila baleira nesta matriz implicar´ıa un caso de uso innecesario, xa que non ten dependencias con ning´un obxectivo do proxecto. A segunda matriz, T´aboa 2.2, reflicte as dependencias entre os propios casos de uso (om´ıtense columnas baleiras para facilitar a s´ua observaci´on). [OBX-1] [OBX-2] [OBX-3] [CU-1] ⇑ [CU-2] ⇑ [CU-3] ⇑ [CU-4] ⇑ [CU-5] ⇑ [CU-6] ⇑ [CU-7] ⇑⇑⇑ [CU-8] ⇑⇑⇑ [CU-9] ⇑ [CU-10] ⇑ [CU-11] ⇑⇑⇑ [CU-12] ⇑ ⇑ [CU-13] ⇑ ⇑ [CU-14] ⇑⇑⇑ [CU-15] ⇑ ⇑ [CU-16] ⇑ ⇑ [CU-17] ⇑ T´aboa 2.1: Matriz de trazabilidade CU-OBX. [CU-1] [CU-3] [CU-4] [CU-5] [CU-7] [CU-10] [CU-12] [CU-1] [CU-2] ⇑ [CU-3] ⇑ [CU-4] ⇑ ⇑ ⇑ [CU-5] ⇑ [CU-6] ⇑ [CU-7] ⇑ [CU-8] ⇑ ⇑ [CU-9] ⇑ ⇑ [CU-10] ⇑ [CU-11] ⇑ ⇑ [CU-12] ⇑ ⇑ ⇑ [CU-13] ⇑ ⇑ ⇑ [CU-14] ⇑ ⇑ [CU-15] ⇑ ⇑ ⇑ [CU-16] ⇑ ⇑ ⇑ [CU-17] ⇑ ⇑ T´aboa 2.2: Matriz de trazabilidade CU-CU. Cap´ıtulo 3 Xesti´on do proxecto A xesti´on de proxectos ´e unha das fontes clave no proceso de desenvolvemento de software. De xeito breve, poder´ıase resumir como o conxunto de t´ecnicas e tarefas para lograr conducir o proxecto desde o seu comezo ata un final satisfactorio. Tradicionalmente, as metodolox´ıas de xesti´on de proxectos como PMBOK [12] tiveron unha forte orientaci´on preditiva. ´ E dicir, a partir do detalle do produto que se quere elaborar (an´alise funcional e t´ecnico, requirimentos, etc.), def´ınense fases e actividades perfectamente planificadas no tempo en base aos recursos dispo˜nibles. Partindo desta proxecci´on inicial, o obxectivo durante o transcurso do proxecto ´e conseguir que se cumpra aquelo que se previra no inicio: calendario, custos e calidade. Este tipo de metodolox´ıas poder resultar ´util, mellorando a calidade e reducindo as desviaci´ons nos proxectos nos que son aplicadas. Sen embargo, poden presentar determinados inconvenientes, sendo o m´ais destacado no noso caso a incerteza. Este proxecto situouse nun entorno r´apido e inestable, onde cumprir o plan inicial non ser´ıa garant´ıa de ´exito. Desde o seu inicio prev´ıanse cambios nas s´uas necesidades e prioridades, e ser´ıa fundamental ter capacidade de adaptaci´on a partir da retroalimentaci´on e incorporaci´on de novas ideas. En definitiva, a creaci´on de valor mediante a adaptaci´on ´as necesidades cambiantes aparece nun primeiro plano fronte ´a tradicional idea de dese˜nar un plan e cumprir uns calendarios e requirimentos est´aticos. A xesti´on ´axil de proxectos permite iniciar o desenvolvemento sen un detalle pechado do que vai a ser constru´ıdo. Neste caso elixiuse Scrum [10] como estratexia ´axil para a xesti´on e desenvolvemento da aplicaci´on. M´ais que unha metodolox´ıa, Scrum ´e un marco de traballo. Isto quere dicir que non define exactamente o que se debe facer, sen´on que proporciona un conxunto de boas pr´acticas a seguir para asegurar o ´exito do proxecto. Unha das caracter´ısticas m´ais destacadas de Scrum ´e o seu enfoque orientado a 41 42 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO maximizar o rendemento do equipo de traballo, sen embargo, neste proxecto o equipo ´e unipersoal, sendo moitas das pautas propostas moi dif´ıciles de aplicar. Por´en, compre remarcar que a estratexia seguida na xesti´on e o desenvolvemento do proxecto ´e unha adaptaci´on do marco Scrum ´as restrici´ons espec´ıficas deste proxecto. Nas vindeiras secci´ons rec´ollese a posta en pr´actica das peculiaridades da filosof´ıa Scrum ao longo da vida do mesmo. 3.1. Plan de xesti´on da configuraci´on Nesta secci´on exponse o plan de xesti´on da configuraci´on do proxecto. Este plan permite dispor dun conxunto de actividades dese˜nadas para identificar e definir os elementos do sistema que probablemente cambien, controlando o cambio dos mesmos ao longo do seu ciclo de vida, establecendo relaci´ons entre eles, definindo mecanismos para xestionar distintas versi´ons destes elementos e auditando e informando dos cambios realizados. Prop´osito e alcance O prop´osito deste plan ´e o de establecer e manter a integridade dos produtos resultado do proxecto a trav´es do ciclo de vida do proceso de software. Seguindo a filosof´ıa Scrum, evitarase a toda costa que a xesti´on da configuraci´on dete˜na o avance do proxecto. Para elo def´ınese unha estratexia de xesti´on lixeira, pero ao mesmo tempo efectiva e suficiente para o contexto do proxecto: aplicaci´on Android na que traballa un s´o desenvolvedor. Elementos de configuraci´on Identif´ıcanse os seguintes elementos de configuraci´on do software (ECS) como obxecto das t´ecnicas de xesti´on da configuraci´on: C´odigo fonte. Proxecto Android Studio con todo o c´odigo fonte da aplicaci´on. Memoria do proxecto. O presente documento. Elementos do dese˜no. Conxunto de diagramas UML e demais figuras e mockups relativos ao dese˜no do software. Elementos de xesti´on. Conxunto de documentos relativos ´a xesti´on do proxecto, como poden ser cronograma, cat´alogo de requisitos, informes e patr´ons, etc. 3.1. PLAN DE XESTI ´ ON DA CONFIGURACI ´ ON 43 Metodolox´ıa e ferramentas S´eguese unha metodolox´ıa propia que respecta o modelo proposto por Scrum. No caso do c´odigo fonte e da memoria do proxecto, requ´ırese dun sistema de control que permita recuperar calquera versi´on anterior destes elementos en calquera instante de tempo. Para isto, faise uso do sistema de control de versi´ons distribu´ıdo Git [13], asociado a dous repositorios remotos en GitLab (https: //gitlab.com), un para o c´odigo fonte e outro para a memoria. As regras xerais (RX-x) de emprego dos repositorios son: RX-1. Poderanse facer todos os commits que se consideren oportunos en ambos repositorios, coa ´unica restrici´on de aportar un comentario suficientemente descritivo do commit en cuesti´on. RX-2. Non ser´a preciso, salvo casos excepcionais, facer uso de ramas (branches) que non sexan a principal (master), posto que tan s´o traballar´a cos repositorios un ´unico individuo. No caso do c´odigo fonte, deben cumprirse tam´en as seguintes regras espec´ıficas (RE-x): RE-1. O remate dun sprint de traballo asociarase cunha nova tag no repositorio. Este etiquetado non ten por que coincidir coa versi´on do produto, pero ser´a o m´ais recomendable. RE-2. Non se impo˜nen restrici´ons respecto a cando definir as distintas versi´ons do produto. O desenvolvedor ter´a a potestade de decidir cando etiquetar o software cunha nova versi´on en base ao valor engadido que poida aportar a devandita ao p´ublico. RE-3. Para nomear unha nova versi´on da aplicaci´on deberase seguir o patr´on v<decimal> (por exemplo: v1.0,v4.1, etc). Cada nova versi´on deber´a etiquetarse cunha cifra superior a calquera das versi´ons anteriores, a´ında que non se require ning´un tipo de linearidade. Para os demais ECSs (de dese˜no e de xesti´on), posto que non se necesita acceder a versi´ons anteriores, empr´egase un sistema distribu´ıdo m´ais sinxelo, que consiste nun directorio Dropbox (https://www.dropbox.com/). Cr´eanse subdirectorios segundo se estima oportuno para garantir a boa accesibilidade dos elementos da configuraci´on. A´ında que en principio non se necesita recuperar versi´ons anteriores, o servizo Dropbox integra un control de versi´ons propio que permite acceder ao estado anterior dos elementos con criterio de data e hora. 50 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO ´ Indice de riscos [RSC-1]: Cambios nos requisitos. [RSC-2]: Atrasos na planificaci´on temporal. [RSC-3]: Perda de informaci´on. [RSC-4]: Mala implementaci´on ou dese˜no inadecuado. [RSC-5]: Manifestaci´on de erros. [RSC-6]: Atoamento por ausencia de persoal clave. [RSC-7]: Expectativas do cliente non acadadas. [RSC-8]: Incumprimento da lei. [RSC-9]: Mala xesti´on de riscos. [RSC-10]: Equipo inutilizado. [RSC-11]: Entrega de versi´on err´onea. Detalle dos riscos RSC-1 Cambios nos requisitos Versi´on: 1.3 Autor: Fernando Est´evez Descrici´on: Efect´uanse cambios nos requisitos, ben porque o cliente cambia de parecer respecto dalgunha funcionalidade, ou ben por mala captura dos mesmos. Activos: ACT-1,ACT-2,ACT-3,ACT-10,ACT-11 Ameazas: AMZ-4,AMZ-5,AMZ-6 Exposici´on: Alta Estratexia: Mitigar (previr e minimizar) Acci´on: Por un lado, como medida preventiva s´eguese a filosof´ıa Scrum tanto no que respecta ´a xesti´on dos requisitos como ´a interacci´on co cliente. Deste xeito, os requisitos vanse especificando ao longo do proxecto na Pila de Produto e o cliente pode seguir de preto a s´ua evoluci´on. Ademais, como medida de continxencia, definiuse un bo plan de xesti´on da configuraci´on que, xunto coa tolerancia a cambios ofrecida por Scrum, axudar´an ´a boa xesti´on deste tipo de eventos. Indicadores: Aplicadas medidas preventivas desde o inicio do proxecto. As medidas de continxencia ser´an tomadas en canto se produza unha solicitude de cambio. Incidencias: Solicitudes de cambio do 11/04, do 19/05 e do 02/06 de 2017. 3.2. PLAN DE XESTI ´ ON DE RISCOS 51 RSC-2 Atrasos na planificaci´on temporal Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: O proxecto non segue a planificaci´on prevista por motivos diversos: lentitude nos procesos de documentaci´on, desco˜necemento das tecnolox´ıas, lentitude na fase de probas, etc. Activos: ACT-1,ACT-2,ACT-3,ACT-10,ACT-12 Ameazas: AMZ-1 –AMZ-11 Exposici´on: Alta Estratexia: Mitigar (previr) Acci´on: De novo Scrum aporta un bo sistema preventivo. Coa metodolox´ıa ´axil aplicada, o equipo ´e o ´ultimo responsable de aceptar os prazos e de comprometerse coa cantidade de caracter´ısticas a implementar durante o sprint. Ningu´en pode impor prazos que no sexan realistas pois o equipo ten a potestade para non aceptalos. Respecto da burocracia, recordar que Scrum aposta pola documentaci´on lixeira. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-3 Perda de informaci´on Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: P´erdese informaci´on relativa ao proxecto, ben sexa c´odigo fonte ou documentaci´on, por motivos diversos (ver ameazas). Activos: ACT-1 –ACT-3,ACT-10 –ACT-14 Ameazas: AMZ-2,AMZ-3,AMZ-7,AMZ-8 Exposici´on: Alta Estratexia: Evitar Acci´on: Integrouse un plan de xesti´on da configuraci´on, sinxelo pero consistente, que evita este risco ao manter toda a informaci´on do proxecto de forma local no equipo de traballo e replicada na nube (ver Secci´on 3.1). Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-4 Mala implementaci´on ou dese˜no inadecuado Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: Prod´ucense problemas na codificaci´on do software ou ben durante o dese˜no, que poden carrexar a insatisfacci´on do cliente ou o incumprimento dalg´un requisito. Activos: ACT-1 –ACT-3,ACT-10 52 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO RSC-4 Mala implementaci´on ou dese˜no inadecuado (cont.) Ameazas: AMZ-6,AMZ-7 Exposici´on: Alta Estratexia: Mitigar (previr e minimizar) Acci´on: Definiuse un plan de formaci´on que tratar´a de evitar estes problemas no relativo ´a falta de experiencia coas tecnolox´ıas. O Sprint Review proposto en Scrum e a demostraci´on que se realiza durante o mesmo, alertan rapidamente da carencia dun dese˜no adecuado. Durante a Sprint Retrospective tam´en se poden detectar partes da aplicaci´on que deben ser refactorizadas. Scrum ´e unha metodolox´ıa preparada para o cambio e a refactorizaci´on. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-5 Manifestaci´on de erros Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: Detecci´on de erros na aplicaci´on, ben sexa a´ında na fase de desenvolvemento ou xa durante a distribuci´on e explotaci´on. Cobran especial interese os erros por problemas de compatibilidade. Activos: ACT-1 –ACT-3,ACT-10 Ameazas: AMZ-7,AMZ-11,AMZ-13 Exposici´on: Alta Estratexia: Mitigar (previr) Acci´on: Dese˜nouse un plan de probas completo e esixente, que incl´ue, como particularidade, a posta en marcha dunha beta privada que permita identificar por enriba de todo erros de compatibilidade, os cales non poden ser probados cun plan de probas tradicional. A maiores, o plan de formaci´on paliar´a a introduci´on de outros erros l´oxicos por parte do equipo de desenvolvemento. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-6 Atoamento por ausencia de persoal clave Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: Imposibilidade de cumprimento da planificaci´on por dependencias con stakeholders non dispo˜nibles cando son necesitados. Activos: ACT-1 –ACT-4,ACT-10,ACT-12 Ameazas: AMZ-1,AMZ-6,AMZ-10,AMZ-11 Exposici´on: Alta Estratexia: Evitar 3.2. PLAN DE XESTI ´ ON DE RISCOS 53 RSC-6 Atoamento por ausencia de persoal clave (cont.) Acci´on: Scrum segue o Manifesto ´ Axil e, por tanto, o principio de antepor a colaboraci´on co cliente sobre a negociaci´on de contratos. Para elo Scrum pon en todo proxecto un representante dos intereses do cliente, o Product Owner, e ademais permite e persegue a colaboraci´on e a comunicaci´on con todos os involucrados no proxecto durante os Sprint Reviews. Neste proxecto en concreto adicouse tempo a elaborar un bo plan de comunicaci´ons. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-7 Expectativas do cliente non acadadas Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: O produto non cumpre coas expectativas do cliente. Activos: ACT-1 –ACT-3,ACT-10 Ameazas: AMZ-1,AMZ-6,AMZ-10,AMZ-11 Exposici´on: Media Estratexia: Evitar Acci´on: T´omanse as medidas relativas ´a interacci´on cos clientes expostas nos riscos RSC-1,RSC-4 eRSC-6. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-8 Incumprimento da lei Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: O produto non cumpre coa normativa legal vixente de protecci´on de datos ou propiedade intelectual. Activos: ACT-1,ACT-10 Ameazas: AMZ-12 Exposici´on: Media Estratexia: Evitar Acci´on: En base aos co˜necementos b´asicos legais do equipo de desenvolvemento, rexeitarase calquera requisito, funcionalidade, tarefa ou actividade que incite a m´ınima d´ubida respecto da s´ua legalidade. Indicadores: Aplicadas medidas desde o inicio do proxecto. Incidencias: Sen incidencias. RSC-9 Mala xesti´on de riscos Versi´on: 1.0 Autor: Fernando Est´evez 54 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO RSC-9 Mala xesti´on de riscos (cont.) Descrici´on: Durante o proxecto real´ızase unha identificaci´on ou xesti´on dos riscos ineficiente, que pode implicar a manifestaci´on doutros riscos non contemplados. Activos: ACT-1,ACT-10 Ameazas: AMZ-7,AMZ-11 Exposici´on: Media Estratexia: Aceptar Acci´on: As´umese o risco. Parece moi improbable que nun proxecto desta envergadura se manifesten outros riscos non contemplados neste plan e, de manifest´arense, a metodolox´ıa de traballo de seguro facilitar´a o seu control. Indicadores: Non aplica. Incidencias: Sen incidencias. RSC-10 Equipo inutilizado Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: Un equipo de traballo (computador ou dispositivo m´obil) queda inutilizado. Activos: ACT-1,ACT-5 –ACT-9 Ameazas: AMZ-2,AMZ-3,AMZ-8,AMZ-13 Exposici´on: Baixa Estratexia: Mitigar (previr e minimizar) Acci´on: Se se estraga o dispositivo m´obil de probas empregarase outro de uso particular. De estragarse o equipo de traballo, o CiTIUS proporcionar´a un equipo de escritorio que o substituir´a. Documentarase o proceso de posta a punto do entorno de traballo (instalaci´on de sistema operativo, software de desenvolvemento e xesti´on, bibliotecas e outras dependencias, etc) co fin de axilizar o proceso de volta ´a normalidade. Indicadores: Non aplica. Incidencias: Sen incidencias. RSC-11 Entrega dunha versi´on err´onea Versi´on: 1.0 Autor: Fernando Est´evez Descrici´on: Entr´egase ao cliente unha versi´on incorrecta ou inconsistente do produto. Activos: ACT-1 –ACT-3,ACT-10 Ameazas: AMZ-6,AMZ-11 Exposici´on: Baixa Estratexia: Mitigar (previr) e aceptar. 3.3. PLANIFICACI ´ ON TEMPORAL 55 RSC-11 Entrega dunha versi´on err´onea (cont.) Acci´on: T´omanse as medidas relativas ao control de versi´ons expostas nos riscos RSC-1 eRSC-3. De non ser dabondo o control de versi´ons debido a un erro humano, o impacto ser´a insignificante en base ´a confianza e proximidade do cliente. Indicadores: Aplicadas medidas preventivas desde o inicio do proxecto. As medidas de continxencia ser´an tomadas en canto se avar´ıe o dispositivo en cuesti´on. Incidencias: Sen incidencias. 3.3. Planificaci´on temporal Nesta secci´on rec´ollese a planificaci´on temporal do proxecto. Pres´entase, en primeiro lugar a Estrutura de Descomposici´on do mesmo, seguida polo cronograma completo e actualizado. 3.3.1. Estrutura de Descomposici´on do Traballo A Figura 3.1 amosa unha representaci´on da Estrutura de Descomposici´on do Traballo (EDT) do proxecto. A descrici´on de cada un dos cadros da EDT p´odese consultar no dicionario disposto a continuaci´on. Dicionario da EDT 1. An´alise. Bloque adicado ´a etapa de an´alise, da cal se destacan estas catro subtarefas: 1.1. Definici´on de obxectivos e alcance. Fase inicial de estudo do problema, determinando de forma clara e un´ıvoca os obxectivos que se perseguen co proxecto e cuxa consecuci´on marcar´a a finalizaci´on exitosa do mesmo. 1.2. Especificaci´on de requisitos. Posto que se decidiu optar por unha metodolox´ıa ´axil baseada en Scrum, a especificaci´on de requisitos ´e continua (ver Cap´ıtulo 2). 1.3. Selecci´on da metodolox´ıa. Fase na que se decide a metodolox´ıa de traballo a seguir. Isto implica non s´o elixir o modelo, Scrum, sen´on tam´en adaptalo a este proxecto en concreto. 1.4. Selecci´on das tecnolox´ıas. Fase na que se determina que tecnolox´ıas, m´etodos e algoritmia empregar para afrontar os distintos retos. 56 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO FaceSampler 1. An´alise 1.1. Definici´on de obxectivos e alcance 1.2. Especif. de requisitos 1.3. Selecci´on da metodolox´ıa 1.4. Selecci´on das tecnolox´ıas 2. Formaci´on 2.1. Android 2.2. Visi´on artificial 2.3. Aprendizaxe m´aquina 2.4. Scrum 3. Desenvolvemento 3.1. Dese˜no da vista 3.2. Dese˜no da l´oxica e implementaci´on 3.2.1. Sistema de recolecci´on de datos 3.2.2. Sistema de procesado de imaxes 3.2.3. Sistema de aprendizaxe 4. Probas 4.1. Probas funcionais 4.2. Probas estruturais 4.3. Probas aleatorias 4.4. Beta privada 5. Documentaci´on 5.1. Memoria do proxecto 5.2. Manual de usuario Figura 3.1: EDT do proxecto. 2. Formaci´on. Bloque adicado ´a aprendizaxe das tecnolox´ıas empregadas. Cada un dos bloques derivados deste na EDT corresp´ondese con unha tecnolox´ıa que se necesita aprender. Recom´endase a lectura da Secci´on 3.4.1, onde se describe cada unha das mesmas. 3. Desenvolvemento. Este bloque comprende o dese˜no e a codificaci´on da aplicaci´on. Ao empregarse unha metodolox´ıa ´axil, ambas etapas est´an moi solapadas. 3.1. Dese˜no da vista. Dese˜no inicial das vistas da aplicaci´on, as´ı como da navegaci´on entre as mesmas. 3.2. Dese˜no da l´oxica e implementaci´on. Difer´encianse tres grandes subsistemas dentro da aplicaci´on. Recom´endase a lectura do Cap´ıtulo 5, onde se describe cada un en detalle. 4. Probas. Bloque adicado ´a aplicaci´on do plan de probas. Cada un dos bloques derivados deste na EDT corresp´ondese cunha compo˜nente da estratexia de dito plan. Recom´endase a lectura da Secci´on 3.6, onde se describe dita estratexia en detalle. 3.3. PLANIFICACI ´ ON TEMPORAL 57 5. Documentaci´on. Bloque correspondente ´a elaboraci´on da seguinte documentaci´on: 5.1. Memoria do proxecto. Memoria t´ecnica do proxecto, elaborada paralelamente ao desenvolvemento do mesmo, na que se recollen os detalles de t´odalas etapas abordadas, as´ı como as conclusi´ons finais. 5.2. Manual de usuario. Documento onde se detalla o modo de emprego da aplicaci´on. 3.3.2. Cronograma A Figura 3.2 amosa o cronograma final do proxecto representado mediante un diagrama de Gantt. As frechas indican as dependencias de realizaci´on entre tarefas ou grupos de tarefas. As tarefas coloreadas en vermello conforman o cami˜no cr´ıtico do mesmo. Co˜necer o cami˜no cr´ıtico permite saber cales son as actividades que deben realizarse para que nada se atrase e se cumpran os prazos estimados. O tempo medio de dedicaci´on ao proxecto foi de aproximadamente 14 horas ´a semana. Pese a todo, ao longo dos meses produciuse unha gran variaci´on nesta media en funci´on de factores alleos ao proxecto, maioritariamente acad´emicos. Existiron por´en etapas de dedicaci´on practicamente nula, como o per´ıodo de exames de decembro e xaneiro, e outras de maior entrega, como os meses de febreiro, maio e xu˜no, onde se adicaron ata 25 horas semanais. Todos os sprints se planificaron para equivaleren a 40 horas de traballo, aproximadamente. Isto traduciuse en sprints de entre 2 e 3 semanas, en funci´on da dispo˜nibilidade dos recursos e da prioridade do desenvolvemento en cada instante. En total, adic´aronse a este proxecto 419 horas. Recom´endase a consulta do documento adxunto planificacionTemporal.ods para ver os detalles da repartici´on das horas. A continuaci´on ap´ortase unha breve descrici´on de cada unha das actividades m´ais relevantes inclu´ıdas no diagrama de Gantt. An´alise inicial. Primeira etapa ´a que se lle adicou unha semana de traballo, 19 horas, e que coincide co bloque 1 da EDT anterior. Cabe destacar que, a´ında que a especificaci´on de requisitos sexa constante, realizouse a tarefa Especificaci´on inicial de requisitos para identificar aqueles requirimentos m´ais importantes e nos que se deb´ıa comezar a traballar de inmediato. Sprint 1. Coincide co inicio do desenvolvemento da aplicaci´on Android. O tempo total adicado ascendeu a 42 horas, repartidas ao longo de 3 semanas. Implementouse un detector facial en primeiro plano e en tempo real partindo do aprendido con OpenCV e Java (ver Ap´endice D) durante o 58 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO 2016 2017 Novembro Decembro Xaneiro Febreiro Marzo Abril Maio Xu˜no 1a2a3a4a1a2a3a4a1a2a3a4a1a2a3a4a1a2a3a4a1a2a3a4a1a2a3a4a1a2a3a4a An´alise inicial Definici´on de obxectivos e alcance Selecci´on da metodolox´ıa Especificaci´on inicial de requisitos Selecci´on de tecnolox´ıas Sprint 1 Detector de rostros en Android Obtenci´on da pose e iluminaci´on Aprendizaxe con k-NN F1. Preditor en primeiro plano Sprint 2 Implementaci´on do Touch Service Melloras na escalabilidade Sprint 3 Formaci´on Android complementaria Mostraxe en segundo plano Panel de preferencias F2. Preditor en segundo plano Sprint 4 Modos de execuci´on na mostraxe Sprint 5 Sistema de regras e eventos Always true e SVM Sprint 6 Interface gr´afica definitiva Pitch,yaw eacc. module M´ascara para os inputs Blur e clasificaci´on de fotos F3. Produto listo para beta Probas e beta privada Probas aleatorias Administraci´on da beta privada Correcci´ons menores F4. Produto listo para explotaci´on Documentaci´on Xesti´on Figura 3.2: Diagrama de Gantt coa planificaci´on do proxecto. 3.3. PLANIFICACI ´ ON TEMPORAL 59 anterior mes de xullo. Tam´en se comezaron a obter datos do entorno que servir´ıan como entradas da aprendizaxe. Concretamente, obt´ıvose a pose do dispositivo e a iluminaci´on do entorno. Finalmente, introduciuse o primeiro sistema de aprendizaxe supervisado, baseado no algoritmo (k-NN). Recom´endase ler a Secci´on 4.1 para co˜necer m´ais detalles. Sprint 2. A s´ua duraci´on foi de 2 semanas, 36 horas de traballo. Neste sprint realiz´aronse melloras na arquitectura da aplicaci´on para favorecer a s´ua escalabilidade respecto da captura de informaci´on e as entradas do sistema de aprendizaxe. Tam´en se comezou a obter informaci´on relacionada coa manipulaci´on do dispositivo, concretamente as pulsaci´ons de pantalla (Touch Service). Sprint 3. Durou un total de 40 horas, que se traducen en 2 semanas de traballo. Integrouse un sistema de mostraxe capaz de executarse en segundo plano mentres o usuario desenvolve outras tarefas. Tam´en se creou un panel de preferencias b´asicas relativas ´a aprendizaxe. Foi necesaria formaci´on complementaria en Android para levar a cabo ambas tarefas. Sprint 4. Adic´aronselle 2 semanas de traballo, un total de 36 horas. Implementouse o sistema de modos de execuci´on da mostraxe que se explica na Secci´on 4.2.2. Sprint 5. A s´ua duraci´on foi unha vez m´ais de 36 horas, traducidas en 3 semanas de traballo. P´uxose en funcionamento a permutaci´on entre os modos de execuci´on definidos no sprint anterior, mediante o emprego dun sistema de regras e eventos disparadores. Tam´en se revisou o dese˜no do m´odulo de aprendizaxe para que fose escalable a novos algoritmos, e integr´aronse Always true e SVM (ver Secci´on 4.1). Sprint 6. Durou 3 semanas, traballando un total de 40,5 horas. Fix´eronse melloras significativas: implementouse a interface de usuario definitiva, modificouse o conxunto de datos de entrada para empregar as rotaci´ons pitch eyaw e o m´odulo da aceleraci´on, implementouse unha m´ascara para poder deshabilitar estes inputs e comezou a detectarse o desenfoque (blur) nas imaxes e a facerse unha clasificaci´on das mesmas na galer´ıa do dispositivo. Probas e beta privada. O esforzo adicado a esta etapa foi de 29,5 horas, a´ında que se prolongou durante 5 semanas. En primeiro lugar realiz´aronse un conxunto de probas aleatorias. Posteriormente, iniciouse unha beta privada da aplicaci´on, que se prolongou por un mes. Paralelamente, f´oronse detectando fallos e corrixindo aqueles erros que requir´ıan de pouco tempo para solucionalos. Recom´endase ler a estratexia do plan de probas da Secci´on 3.6 para comprender a finalidade destas tarefas. Documentaci´on. Esta actividade corresp´ondese directamente co bloque 5 66 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO Secci´on 3.1. Dado que na planificaci´on temporal se chega a un nivel de detalle semanal, estes cambios deber´an ser documentados, canto menos, sempre que impliquen unha variaci´on de m´ais de 3 xornadas laborais (24 horas). 3.6. Plan de probas O obxectivo deste plan ´e presentar informaci´on sobre a calidade do produto, atopar defectos e facilitar informaci´on para a toma de decisi´ons. Pret´endese que, a medio prazo, estas acci´ons permitan evitar a manifestaci´on de erros e aumentar a confianza no nivel de calidade. O plan foise adaptando conforme avanzaba o proxecto. Pres´entase agora a versi´on final do mesmo. 3.6.1. Estratexia de construci´on Desde que se comezou a traballar en FaceSampler sab´ıase que ser´ıa inviable aplicar un plan de probas exhaustivo. As restrici´ons temporais foron sempre consideradas como o principal impedimento para acadar este fin. Sen embargo, posteriormente detectouse outro obst´aculo do mesmo calibre: a falta de experiencia coas ferramentas de testing do ecosistema Android. Por estes dous condicionantes, o plan de probas foi evolucionando de xeito que se sacrificou cobertura en profundidade (m´etodos e clases) para lograr acadala en amplitude (m´odulos e todo o sistema integrado). A filosof´ıa aplicada foi a de procurar a axilidade, garantindo sempre uns m´ınimos niveis de cobertura, que ser´an comentados nesta mesma secci´on. Aplicando tam´en as pautas de Scrum, as probas f´oronse dese˜nando e executando ao longo do proxecto, o cal permitiu obter unha realimentaci´on peri´odica que axudou a regular o plan. Estableceuse unha cobertura m´ınima do 50 % para cada unha das funcionalidades resultado de cada sprint do proxecto. De non acadarse dita cobertura, o seguinte sprint ´e replanificado para seguir traballando naquelas funcionalidades que non logren dito m´ınimo. Nunca se continuar´a coa implementaci´on de novas caracter´ısticas se non se cumpre este criterio. Deste xeito, sexa cal sexa o estado do produto, vai ter unha cobertura en amplitude de polo menos un 50 % na ´ultima das s´uas versi´ons (ver Secci´on 3.1). A maiores, compre destacar o fortemente ligadas que est´an as funcionalidades deste proxecto. Isto implica que, en moitas ocasi´ons, ao probar unha nova caracter´ıstica se estean probando de xeito indirecto as anteriores, o cal axudar´a a incrementar a cobertura das mesmas. Isto unido ao feito de que en Scrum se abarcan primeiro as funcionalidades m´ais priorizadas polo cliente axuda a que aquelas 3.6. PLAN DE PROBAS 67 m´ais importantes estean antes e mellor probadas, acadando graos de cobertura superiores aos daquelas outras menos prioritarias. Non obstante, as dependencias entre funcionalidades tam´en poden ser desfavorables a este plan. Por exemplo, probar unha nova funcionalidade que depende de outra anterior, por moi probada que esta estea, sempre pode carrexar problemas. Compre tomar decisi´ons durante as fases de proba de cada sprint respecto de que compo˜nentes mockear (empregar obxectos simulados) para garantir o correcto testeo da nova funcionalidade introducida. Acadando a cobertura desexada Considerouse (e confirmouse posteriormente) que unha cobertura do 50 % soe ser facilmente acadable realizando probas funcionais, ou de caixa negra. Seguindo a filosof´ıa ´axil, tom´aronse como probas funcionais aquelas establecidas como probas de aceptaci´on para cada un dos casos de uso do sistema. Evidentemente, efectu´aronse estas probas por duplicado, a segunda vez en presencia do cliente. En todas elas apl´ıcanse as t´ecnicas de conxectura de erros1eclases de equivalencia2para xerar suficientes casos de proba. FaceSampler caracter´ızase por ter a maior parte das funcionalidades “ligadas” ´a interface gr´afica, de xeito que as s´uas acci´ons repercuten na pantalla do dispositivo m´obil. Grazas a isto, moitas destas probas puideron realizarse monitorando a execuci´on normal da aplicaci´on e forzando a casu´ıstica oportuna para obter os resultados desexados por pantalla. Este plan conta tam´en con probas estruturais, ou de caixa branca, pensadas para asegurar o correcto funcionamento de obxectos complexos, con moitas dependencias ou que non poden ser facilmente cubertos coas probas funcionais descritas no par´agrafo anterior. Abordando o problema da compatibilidade Un problema que estivo moi presente ao longo do proxecto foi o da compatibilidade da aplicaci´on con distintos dispositivos e versi´ons de Android. Existe un requisito non funcional [RNF-14] no que se definen os niveis m´ınimos aceptables de compatibilidade (ver Secci´on 2.3). O problema, tal e como se recolle no plan de riscos (Secci´on 3.2) co risco “Manifestaci´on de erros” [RSC-5], ´e que resulta moi dif´ıcil calcular o grao de compatibilidade acadado pola aplicaci´on sen poder 1T´ecnica de probas consistente na elaboraci´on previa dunha lista de erros non contemplados anteriormente que serve para xerar novos casos de proba. 2T´ecnica de probas que consiste na divisi´on do campo de entrada para obter estados v´alidos e non v´alidos do sistema. 68 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO probala de xeito exhaustivo en diversas versi´ons e modelos do mercado. De feito, ´e posible que a aplicaci´on pase unha proba, funcional ou estrutural, no dispositivo m´obil de desenvolvemento pero non en outros. Como soluci´on, integrouse no plan un conxunto de probas aleatorias e a posta en explotaci´on dunha versi´on beta privada. As probas aleatorias realiz´aronse ao remate da etapa de implementaci´on. Para isto, empregouse a ferramenta web Firebase Test Lab de Google [17]. Esta, disp´on dun laboratorio de dispositivos de probas, tanto f´ısicos como virtuais. Deste xeito, permite seleccionar con que dispositivos, niveis da API de Android, orientaci´ons de pantalla e configuraci´ons rexionais se desexa probar a aplicaci´on. Logo, por cada configuraci´on seleccionada exec´utase unha proba autom´atica que analiza a estrutura da interface gr´afica e simula actividades de usuarios para explorala de maneira aut´onoma. De xeito posterior a esa execuci´on de probas aleatorias, planificouse a posta en marcha dunha versi´on beta da aplicaci´on limitando o acceso a un grupo de persoas de confianza. A idea consistiu en que os voluntarios empregasen FaceSampler durante un per´ıodo de tempo suficiente como para lograr obter 220 mostras do seu rostro. Paralelamente, o equipo de desenvolvemento seguiu o comportamento da aplicaci´on en cada dispositivo a trav´es da Google Play Console [18], detectando as incidencias (fallos e ANRs) que puidesen ocorrer. O obxectivo de inclu´ır estas medidas no plan de probas ´e dobre. Por un lado, axudar´an a obter un informe de compatibilidade que permita verificar o requisito non funcional asociado [RNF-14]. Ademais, tam´en servir´an como reforzo ´as probas funcionais e estruturais definidas anteriormente, co cal se espera mellorar a cobertura das diversas funcionalidades da aplicaci´on. 3.6.2. Riscos do plan de probas O ´unico risco identificado como propio deste plan ´e a incapacidade para lograr as coberturas m´ınimas definidas, o cal poder´ıa desencadear os riscos RSC-2,RSC-4 ou RSC-5 do proxecto. Este risco, polo tanto, xa est´a integrado de xeito indirecto nos plans de acci´on destes outros tres riscos globais. A estratexia espec´ıfica pensada para este risco ´e preventiva. Cando se detecte un atraso na planificaci´on [RSC-2] por lentitude nas probas, replanificarase o seguinte sprint para continuar traballando sobre os requisitos actuais, tal e como se comentaba na secci´on anterior. Scrum engade facilidade a esta estratexia, posto que o equipo ´e o ´ultimo responsable de aceptar os prazos e de comprometerse coa cantidade de caracter´ısticas a implementar durante o sprint e o cliente pode seguir a evoluci´on de preto do produto, sendo consciente das adversidades manifestadas. 3.6. PLAN DE PROBAS 69 Para maior detalle, recom´endase a lectura da Secci´on 3.2, de planificaci´on de riscos. 3.6.3. Definici´on de probas Exponse a continuaci´on a especificaci´on das probas dese˜nadas para a aplicaci´on durante os sucesivos sprints do desenvolvemento. Probas funcionais Como se explicaba previamente, as probas funcionais a realizar ao longo do proxecto xa est´an definidas como probas de aceptaci´on dos casos de uso. Poden ser consultadas na Secci´on 2.4. Probas estruturais Como probas estruturais, def´ınense as seguintes: PE-1 Proba de conexi´on de servizos Android Autor: Fernando Est´evez Prop´osito: Verificar a correcta conexi´on cos distintos services de Android integrados na aplicaci´on. Funci´ons abordadas: Inicio dos distintos servizos por medio de solicitudes de tipo start ou bindings. T´ecnicas aplicadas: Conxectura de erros e clases de equivalencia Casos de proba: CP-1,CP-2 Criterio(s) de paso: Compr´obase que os distintos servizos son iniciados e poden ser empregados con normalidade. Criterio(s) de fallo: Alg´un dos servizos non ´e iniciado correctamente, lanzando a excepci´on java.util.concurrent.TimeoutException. Requisitos do entorno: Esta proba require de dependencias Android, concretamente do Context da aplicaci´on, polo que deben definirse casos de proba instrumentais [19]. PE-2 Proba dos algoritmo de aprendizaxe Autor: Fernando Est´evez Prop´osito: Verificar que os algoritmos de aprendizaxe k-NN e SVM realizan predici´ons atinadas en casos libres de d´ubida. Funci´ons abordadas: Toma de decisi´ons con k-NN e SVM. T´ecnicas aplicadas: Conxectura de erros e clases de equivalencia 70 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO PE-2 Proba dos algoritmo de aprendizaxe (cont.) Casos de proba: CP-3,CP-4,CP-5,CP-6,CP-7,CP-8,CP-9,CP-10 Criterio(s) de paso: Realizar todas as predici´ons de xeito previsible. Criterio(s) de fallo: Fallar unha ou m´ais predici´ons. Requisitos do entorno: Requ´ırese de dependencias Android, concretamente do Context da aplicaci´on, polo que deben definirse casos de proba instrumentais [19]. PE-3 Proba do xestor de modos de execuci´on Autor: Fernando Est´evez Prop´osito: Comprobar que as permutaci´ons entre modos de execuci´on da mostraxe (Normal e Low Energy) se realizan de forma exitosa en resposta aos distintos eventos. Funci´ons abordadas: Cambio entre modos desde o BroadcastReceiver do que disp´on o ExecutionModeHandler. T´ecnicas aplicadas: Conxectura de erros e clases de equivalencia Casos de proba: CP-11,CP-12,CP-13,CP-14,CP-15,CP-16,CP-17, CP-18,CP-19 Criterio(s) de paso: Permutar entre os modos Normal e Low Energy tal e como se espera. Criterio(s) de fallo: Non permutar baixo o previsto nalg´un dos casos de proba. Requisitos do entorno: Esta proba require de dependencias Android, concretamente do Context da aplicaci´on, polo que deben definirse casos de proba instrumentais [19]. Probas aleatorias Pola s´ua natureza impredicible, non foi necesario realizar un dese˜no previo das acci´ons a levar a cabo neste tipo de probas. Non obstante, cumpriu facer unha selecci´on das distintas combinaci´ons de dispositivos e versi´ons Android a empregar nas mesmas. A estratexia aplicada consistiu en procurar a maior diversidade posible, tendo presente que se pretend´ıa estimar a compatibilidade da aplicaci´on. A T´aboa 3.5 recolle t´odalas configuraci´ons empregadas. No Cap´ıtulo 6 p´odese consultar como foi a execuci´on, as´ı como os detalles das incidencias reportadas derivadas da mesma. 3.6.4. Definici´on de casos de proba Exp´o˜nense a continuaci´on os casos de proba xerados a partir das probas estruturais definidas na secci´on previa. 3.6. PLAN DE PROBAS 71 Proba Dispositivo API Android Versi´on Android Orientaci´on PA-1 Samsung Galaxy Note 3 19 4.4 Retrato PA-2 Google Nexus 7 21 5.0 Retrato PA-3 Google Nexus 9 21 5.0 Paisaxe PA-4 Sony Xperia Z3 21 5.0 Retrato PA-5 OnePlus One 22 5.1 Retrato PA-6 Google Nexus 6 22 5.1 Retrato PA-7 Samsung Galaxy Note 4 22 5.1 Retrato PA-8 Motorola Moto G4 23 6.0 Retrato PA-9 Samsung Galaxy S7 edge 23 6.0 Retrato PA-10 Google Nexus 5 23 6.0 Retrato PA-11 Google Nexus 5 23 6.0 Paisaxe PA-12 Sony Xperia X 23 6.0 Retrato PA-13 Samsung Galaxy S7 24 7.0 Retrato PA-14 Google Pixel 25 7.1 Retrato PA-15 Google Nexus 5X 25 7.1 Retrato PA-16 Google Nexus 5X 25 7.1 Paisaxe T´aboa 3.5: Plan de probas aleatorias. PE-1 Proba de conexi´on de servizos CP-1 testStartService Responsable: Fernando Est´evez Datos precargados: Non hai datos precargados. M´etodo a invocar: Context.startService(i: Intent): ComponentName Entradas: ForegroundSamplingService.class Sa´ıdas: Comprobaci´on de que o servizo en cuesti´on, ForegroundSamplingService, est´a en execuci´on mediante o uso dun ActivityManager. Dependencias: •android.content.Context •android.support.test.rule.ServiceTestRule •android.app.ActivityManager CP-2 testWithBoundService Responsable: Fernando Est´evez Datos precargados: Non hai datos precargados. M´etodo a invocar: ServiceTestRule.bindService(i: Intent): IBinder Entradas: CameraService.class Sa´ıdas: CameraServie.isReady() == true Dependencias: •android.content.Context •android.support.test.rule.ServiceTestRule •android.os.IBinder 72 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO PE-2 Proba dos algoritmos de aprendizaxe CP-3 testKNNHasFaceFalseSimple Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: Knn.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {1, 1, 1, 1, 1} } •ArrayList<State> model = {s1, s1, s1, s1, s2, s2} Sa´ıdas: false Dependencias: •android.content.Context •model.learning.algorithms.knn.Knn CP-4 testKNNHasFaceTrueSimple Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: Knn.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {0, 0, 0, 0, 0} } •ArrayList<State> model = {s1, s1, s1, s1, s2, s2} Sa´ıdas: true Dependencias: •android.content.Context •model.learning.algorithms.knn.Knn CP-5 testKNNHasFaceFalse Responsable: Fernando Est´evez 3.6. PLAN DE PROBAS 73 CP-5 testKNNHasFaceFalse (cont.) Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {0, 0.1, 0.2, 0.05, 0} label = 1 } •State s3 { pattern = {0, 0.02, 0, 0.25, 0} label = 0 } •State s4 { pattern = {0.8, 1, 0.9, 1, 1} label = 0 } •State s5 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: Knn.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {0.1, 0, 0.1, 0.05, 0}} •ArrayList<State> model = {s1, s2, s3, s4, s5} Sa´ıdas: false Dependencias: •android.content.Context •model.learning.algorithms.knn.Knn CP-6 testKNNHasFaceTrue Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {0, 0.1, 0.2, 0.05, 0} label = 1 } •State s3 { pattern = {0, 0.02, 0, 0.25, 0} label = 1 } •State s4 { pattern = {0.8, 1, 0.9, 1, 1} label = 0 } •State s5 { pattern = {1, 1, 1, 1, 1} label = 0 } 74 CAP´ ITULO 3. XESTI ´ ON DO PROXECTO CP-6 testKNNHasFaceTrue (cont.) M´etodo a invocar: Knn.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {0.1, 0, 0.1, 0.05, 0} } •ArrayList<State> model = {s1, s2, s3, s4, s5} Sa´ıdas: true Dependencias: •android.content.Context •model.learning.algorithms.knn.Knn CP-7 testSVMHasFaceFalseSimple Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: OpenCvSVM.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {1, 1, 1, 1, 1} } •ArrayList<State> model = {s1, s1, s1, s1, s2, s2} Sa´ıdas: false Dependencias: •android.content.Context •model.learning.algorithms.svm.OpenCvSVM CP-8 testSVMHasFaceTrueSimple Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: OpenCvSVM.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean 3.6. PLAN DE PROBAS 75 CP-8 testSVMHasFaceTrueSimple (cont.) Entradas: •State s {pattern = {0, 0, 0, 0, 0} } •ArrayList<State> model = {s1, s1, s1, s1, s2, s2} Sa´ıdas: true Dependencias: •android.content.Context •model.learning.algorithms.svm.OpenCvSVM CP-9 testSVMHasFaceFalse Responsable: Fernando Est´evez Datos precargados: •State s1 { pattern = {0, 0, 0, 0, 0} label = 1 } •State s2 { pattern = {0, 0.1, 0.2, 0.05, 0} label = 1 } •State s3 { pattern = {0, 0.02, 0, 0.25, 0} label = 0 } •State s4 { pattern = {0.8, 1, 0.9, 1, 1} label = 0 } •State s5 { pattern = {1, 1, 1, 1, 1} label = 0 } M´etodo a invocar: OpenCvSVM.getInstance().hasFace(s: State, model: ArrayList<State>, context: Context): boolean Entradas: •State s {pattern = {0.1, 0, 0.1, 0.05, 0} } •ArrayList<State> model = {s1, s2, s3, s4, s5} Sa´ıdas: false Dependencias: •android.content.Context •model.learning.algorithms.svm.OpenCvSVM CP-10 testSVMHasFaceTrue Responsable: Fernando Est´evez 82 CAP´ ITULO 4. PROPOSTA respecto ao eixe y, o que poder´ıa orixinar que non se detecten rostros por non aparecer coa mesma orientaci´on que o dispositivo. Iluminaci´on do entorno. A iluminaci´on ´e outro factor importante a ter en conta cando tomamos a foto. Se a escena carece de luz, posiblemente a imaxe sexa demasiado escura como para detectar nela ning´un rostro. Inversa do tempo transcorrido desde o ´ultimo toque de pantalla. Se o usuario interact´ua coa pantalla, ´e probable que se estean dando as condici´ons ideais para obter unha mostra. M´odulo da aceleraci´on. Permite diferenciar cando o m´obil est´a en repouso e cando suceden movementos bruscos, os cales introducir´an desenfoque na imaxe. RECOLECCIÓN DE DATOS PROCESAMENTO DE IMAXES Entrada CAPTURA PROCESAMENT O APRENDIZAXE ADESTRAMENTO MOSTRAXE Etiquetas Dataset de adestramento Saída datos en bruto éxito/fracaso patrón patrón estado modelo mostra da cara predición atopouse cara? captura orde Figura 4.1: Representaci´on da proposta de toma de decisi´ons. As imaxes tomadas polo dispositivo pertencer´an a unha das seguintes clases: ´ Exito: unha imaxe na que se reco˜nece unha cara coa suficiente calidade (resoluci´on, iluminaci´on, ausencia de blur, etc). 4.1. A TOMA DE DECISI ´ ONS 83 y x z Figura 4.2: Rotaci´ons pitch,roll eyaw sobre un smartphone. Fracaso: unha imaxe que non cumpre alg´un dos requisitos para ser ´exito, ben sexa que non se atopa ningunha cara, det´ectanse varias ou a calidade non ´e a esperada. Estamos a falar dun problema de aprendizaxe supervisada1. M´ais concretamente, tr´atase dun problema de clasificaci´on, onde se debe etiquetar a cada estado coma un ´exito ou un fracaso. O m´odulo de Recolecci´on de datos ´e o responsable de obter o conxunto de datos de entrada e procesalo para xerar o patr´on de aprendizaxe, representado por un vector coa informaci´on do contexto. Este patr´on ´e a entrada principal do m´odulo de Aprendizaxe. A aprendizaxe div´ıdese en d´uas etapas. O que se debe facer na primeira fase, de adestramento, ´e crear un conxunto de datos de adestramento formado polo total de estados capturados e clasificados cunha etiqueta coma un ´exito ou un fracaso. O m´odulo de Procesamento de imaxes tomar´a unha foto por cada estado entrante para determinar a s´ua clase. Ser´a necesario procesar cada imaxe para ver se existen rostros na mesma. Unha vez que se disp´on dun dataset de adestramento, p´asase ´a segunda fase, de mostraxe, na que se tomar´an datos do contexto de forma peri´odica e se contrastar´an cos obtidos na fase anterior co fin de predicir se se dan as condici´ons axeitadas para facer unha nova captura e obter un ´exito. Unha vez que se decide tomar a imaxe, debe ser procesada para obter retroalimentaci´on acerca do ´exito ou fracaso da decisi´on. 1En aprendizaxe autom´atica e miner´ıa de datos, a aprendizaxe supervisada ´e unha t´ecnica para deducir una funci´on a partir de datos de adestramento. Os datos de adestramento consisten de pares de obxectos (normalmente vectores): unha compo˜nente do par son os datos de entrada e a outra, os resultados desexados. O obxectivo ´e poder predicir o valor correspondente a calquera obxecto de entrada v´alida despois de ver unha serie de exemplos, os datos de adestramento. 84 CAP´ ITULO 4. PROPOSTA 4.1.1. Obtenci´on do patr´on O patr´on que nos proporciona o estado do dispositivo incl´ue informaci´on relativa ´a s´ua pose, manipulaci´on e iluminaci´on do entorno. Vexamos en detalle como se obt´en cada compo˜nente. C´alculo da pose Necesitamos co˜necer a pose do tel´efono m´obil (pitch,yaw) respecto dun marco de referencia inercial para poder determinar o estado do mesmo. Este marco inercial ´e un sistema ortogonal composto de tres eixes: polo norte magn´etico, este terrestre e centro da Terra. Para proxectar as lecturas provintes dos sensores do sistema de referencia local do m´obil (Figura 4.2) no sistema inercial que acabamos de mencionar, empregamos unha representaci´on mediante un cuaterni´on. Un cuaterni´on (q) ´e un vector de catro dimensi´ons que representa a transformaci´on entre dous sistemas de referencia como a rotaci´on dun ´angulo θen torno ao eixe u= [uxuyuz]. Polo tanto: q=    cosθ sinθ ux sinθ uy sinθ uz    (4.1) Seguindo o m´etodo de Madgwick [20, 21], a trav´es da informaci´on provista polo xiroscopio e o aceler´ometro do dispositivo, podemos obter un cuaterni´on que represente as transformaci´ons para pasar do sistema local do m´obil ao inercial da Terra. O xiroscopio mide a velocidade angular ao redor dos eixes x,y, e zdo sistema local, denominados ωx,ωyeωzrespectivamente. Se estes par´ametros son dispostos no vector de catro dimensi´ons Sω, definido na Ecuaci´on (4.2), a derivada do cuaterni´on que describe a velocidade de cambio da orientaci´on do marco terrestre respecto do marco do sensor S E˙ qpode ser calculada empregando a Ecuaci´on (4.3). Polo tanto, a orientaci´on do sistema inercial da terra respecto do local no momento t,S Eqω,t, pode ser calculado integrando a trav´es do tempo a derivada do cuaterni´on, tal e como se describe na Ecuaci´on (4.4), onde Sωt´e a velocidade angular medida no momento t, ∆t´e o per´ıodo de obtenci´on da informaci´on e S Eb qest,t−1´e a estimaci´on previa da orientaci´on. Sω= [0 ωxωyωz] (4.2) 4.1. A TOMA DE DECISI ´ ONS 85 S E˙ q=1 2 S Eb q⊗Sω(4.3) S Eqω,t =S Eb qest,t−1+1 2 S Eb qest,t−1⊗Sωt×∆t(4.4) No referente ao aceler´ometro, este sensor mide as aceleraci´ons que experimenta o m´obil nos tres eixes do sistema de referencia local: ax,ayand az. De novo, estes valores poden ser dispostos nun vector, Sb a, como amosa a Ecuaci´on (4.5). Cando o m´obil non est´a sometido a ningunha outra forza externa que non sexa a gravidade, a ´unica aceleraci´on que o dispositivo debe experimentar ´e aquela da gravidade, isto ´e [0 0 9,8] m/s2, de acordo co sistema de referencia inercial. Polo tanto, a proxecci´on do vector de catro dimensi´ons normalizado Sb ano sistema de referencia inercial, Eb g, debe coincidir coa Ecuaci´on (4.6). Por conseguinte, deber´ıa suceder que S Eb q∗⊗Eb g⊗S Eb q=Sb a. Esta ´e a raz´on pola cal o cuaterni´on ser´a aquel que minimice a diferenza da Ecuaci´on (4.7). Sb a= [0 axayaz] (4.5) Eb g= [0 0 0 1] (4.6) S Eb q= arg min S E b q∈R4S Eb q∗⊗Eb g⊗S Eb q−Sb a(4.7) Finalmente, podemos combinar as d´uas fontes de informaci´on, Ecuaci´ons (4.4) e (4.7), para acadar o cuaterni´on en cada instante, tal e como se amosa na Ecuaci´on (4.8), onde fprov´en da Ecuaci´on (4.7), tal que f=S Eb q∗⊗Eb g⊗S Eb q−Sb a. S Eb qest,t =S Eb qest,t−1+γ−µ∇f ||∇f||+ (1 −γ)1 2 S Eb qest,t−1⊗Sωt×∆t(4.8) Iluminaci´on, toque de pantalla e movemento Evidentemente, o m´odulo da aceleraci´on tam´en emprega os datos do aceler´ometro para ser calculado. Valores pr´oximos a 9,8 corresponderanse cun estado de repouso no dispositivo. A informaci´on lum´ınica ´e capturada mediante o sensor de luz do dispositivo e a s´ua unidade de medida ´e o lux (lx). A ausencia de luz corresponde a 0 lx. Por ´ultimo, o toque de pantalla non se obt´en a trav´es 86 CAP´ ITULO 4. PROPOSTA de ning´un sensor, sen´on mediante un servizo Android expresamente creado e personalizado para ese obxectivo, que se executa en segundo plano detectando as pulsaci´ons. Calc´ulase a inversa do tempo transcorrido desde o ´ultimo toque para evitar que o valor almacenado medre de xeito incontrolado. Actualmente, o toque de pantalla est´a sempre deshabilitado na m´ascara do patr´on, ´e dicir, estase capturando pero non se aplica na aprendizaxe. Isto ´e porque co adestramento en primeiro plano ´e imposible simular unha interacci´on natural entre o usuario e a pantalla do dispositivo de cara a que esta compo˜nente aporte valor na fase de mostraxe. 4.1.2. Algoritmos de clasificaci´on FaceSampler est´a pensada para permitir integrar e probar novos algoritmos de forma doada. Ata a data, f´oronse introducindo de forma progresiva os que se comentan a continuaci´on. Always true Tr´atase dun algoritmo carente de capacidade preditiva. ´ E o m´ais sinxelo de todos os implementados. En ning´un caso ´e un algoritmo real de aprendizaxe supervisada, pero sim´ulao, xa que de cara ao exterior require dos mesmos par´ametros que as outras alternativas. P´odese considerar un algoritmo “optimista”, xa que cando se lle solicita unha predici´on, sempre considera que se trata dun bo momento para tomar unha captura e obter ´exito. Pese ´a s´ua simplicidade, always true ten d´uas aplicaci´ons relevantes. En primeiro lugar, ´e o algoritmo empregado cando un dispositivo ´e incapaz de obter informaci´on imprescindible do contexto para definir os patr´ons. Por exemplo, a´ında que non sexa habitual, hai modelos concretos que carecen de sensores como o aceler´ometro ou o xiroscopio, fundamentais para determinar a pose do dispositivo. Por outro lado, resultou unha boa ferramenta de depuraci´on durante a efectuaci´on daquelas probas de caixa negra nas que se precisaba de capturar o maior n´umero de imaxes ou coa maior velocidade posible. k-NN O m´etodo dos kveci˜nos m´ais pr´oximos (do ingl´es k-nearest neighbors, abreviado k-NN) [9, Chapter 4] ´e o algoritmo empregado por defecto en FaceSampler. Na fase de mostraxe, de forma peri´odica obtense o estado do dispositivo e apl´ıcase o kNN para saber se tomar a foto ou non en funci´on dos datos de adestramento que se 4.2. A XESTI ´ ON EFICIENTE DOS RECURSOS 87 almacenaron previamente. Nunha estratexia inicial procur´abanse os k= 5 veci˜nos m´ais pr´oximos, ´e dicir, os cinco estados aprendidos que m´ais se semellasen ao actual, e tom´abase a foto se polo menos a metade dos veci˜nos estaban etiquetados como ´exito. Esta estratexia era demasiado pouco restritiva, polo que se decidiu empregar k= 3, sendo a condici´on de tomar a foto que os tres veci˜nos tivesen caso de ´exito. O resultado con esta estratexia ´e moito mellor, posto que, a´ında que o dispositivo se volve moito m´ais cauto, a taxa de acertos aumenta notoriamente. Claro est´a, dita taxa de ´exito depende directamente da calidade do adestramento previo. SVM As m´aquinas de soporte vectorial (Support Vector Machines, SVMs) [9, Chapter 9] son un conxunto de algoritmos de aprendizaxe supervisada orixinariamente ideados para constru´ır un clasificador binario ´optimo. As SVMs representan o modelo provinte da fase de adestramento no espazo, separando as clases en d´uas rexi´ons o m´ais amplas posibles mediante un hiperplano de separaci´on definido como o vector entre os dous puntos, das d´uas clases, m´ais pr´oximos ao que se co˜nece como vector soporte. Cando os novos estados se contrastan con dito modelo, en funci´on da rexi´on ´a que pertenzan, poden ser etiquetados cunha ou outra clase. Neste caso, posto que OpenCV permite traballar con SVMs, decidiuse implementar un preditor SVM coa axuda de dita biblioteca. Na Figura 4.3 am´osase unha representaci´on simplificada do problema con k-NN (4.3a) e SVM (4.3b). En ambos casos, o punto azul ´e o estado actual e os demais son aqueles estados aprendidos durante o adestramento m´ais pr´oximos ao estado actual. Os vermellos son fracasos e os verdes ´exitos. 4.2. A xesti´on eficiente dos recursos O terceiro dos obxectivos do proxecto [OBX-3] tam´en compromete ´a aplicaci´on a traballar de forma eficiente, xestionando os recursos computacionais da mellor forma posible, minimizando o consumo de enerx´ıa e evitando monopolizar os recursos de procesamento. Para acadar estas metas, durante a evoluci´on do proxecto procurouse en todo momento manter un bo control sobre o traballo realizado pola aplicaci´on, xestionando os procesos e sub-procesos involucrados. Do mesmo xeito, de cara ´a fase de mostraxe, posto que se efect´ua durante tempo prolongado (horas, d´ıas e incluso semanas), definiuse un sistema de execuci´on en d´uas modalidades controlado por eventos disparadores. 88 CAP´ ITULO 4. PROPOSTA (a) Estratexia k-NN. (b) Estratexia SVM. Figura 4.3: Comparativa entre os dous algoritmos principais. 4.2.1. Procesos e sub-procesos De maneira predeterminada, todos os compo˜nentes da mesma aplicaci´on se executan no mesmo proceso e, por norma xeral, non se recomenda modificar isto [22]. Cando unha aplicaci´on Android se inicia, o sistema crea un thread (sub-proceso) de execuci´on para a mesma, que se denomina “principal”. Este thread ´e moi importante porque, entre outras cousas, ´e aquel sobre o cal a aplicaci´on interact´ua cos compo˜nentes do kit de ferramentas da interface de usuario (IU) de Android. Por iso, ao thread principal tam´en se lle co˜nece como o sub-proceso de IU. Sen embargo, cando a aplicaci´on realiza traballo intensivo en resposta a unha interacci´on do usuario, este modelo de thread ´unico pode xerar un rendemento deficiente. Especificamente, se todo sucede no sub-proceso de IU, realizar operaci´ons prolongadas, como ´e o caso do procesado continuo das imaxes e os patr´ons en FaceSampler, bloquear´a toda a IU. Desde a perspectiva do usuario, a aplicaci´on non responder´a. O que ´e peor, se o sub-proceso de IU est´a bloqueado por m´ais duns poucos segundos, ao usuario presentar´aselle un cadro de di´alogo de tipo ANR (“a aplicaci´on no responde”). Para evitar reportes de erros ANR, adicouse tempo a realizar unha xesti´on eficiente dos procesos e sub-procesos da aplicaci´on. Tan s´o se require do thread principal para o control da interface gr´afica e de outro m´ais para executar a mostraxe, ao cal lle chamaremos sub-proceso de mostraxe. Este segundo ´e imprescindible para executar as tarefas de captaci´on do estado do dispositivo, captura de imaxes, detecci´on de caras, etc., sen que o rendemento da IU se vexa afectado. Na etapa de mostraxe, o usuario pode seguir navegando por FaceSampler ou o resto de 4.2. A XESTI ´ ON EFICIENTE DOS RECURSOS 89 aplicaci´ons do seu dispositivo, e en ning´un caso se pode tolerar que o rendemento do mesmo se vexa prexudicado por unha mala xesti´on dos recursos. No caso da etapa de adestramento, en principio non ´e preciso outro thread xa que todo o traballo se realiza en primeiro plano, reflectindo todo o que sucede na IU. Non obstante, en determinadas ocasi´ons FaceSampler necesita realizar algunha actualizaci´on da IU con informaci´on provinte das sa´ıdas de tarefas pesadas, que poden retardar a velocidade de resposta da IU. O problema ´e que interface gr´afica de Android non permite chamadas desde outros threads que non sexan o seu, as´ı que se intentamos crear un novo thread con este obxectivo, a aplicaci´on finalizar´a. Unha boa soluci´on para este tipo de situaci´ons provista por defecto polo entorno Android ´e recorrer ao emprego de AsyncTasks (android.os.AsyncTask<Params, Progress, Result>) [23]. Unha AsyncTask permite realizar traballo as´ıncrono na interface de usuario. Leva a cabo as operaci´ons de bloqueo nun sub-proceso de traballo e logo publica os resultados no sub-proceso de IU, sen necesidade de que o programador te˜na que manexar subprocesos ou controladores. 4.2.2. Modalidades de execuci´on e eventos disparadores A mostraxe ´e un proceso que pode durar moito tempo, e non conv´en ocupar recursos como a c´amara de xeito prolongado nin estar continuamente analizando o estado do dispositivo cando sabemos que non ´e un bo momento para tomar unha captura. Por iso, a aplicaci´on diferenza dous modos de execuci´on da mostraxe: Modo normal (Normal mode). O proceso est´a “alerta” para realizar unha captura. T´omase o control sobre o recurso da c´amara. Periodicamente rec´ollese toda a informaci´on actualizada dos sensores e servizos, real´ızanse os c´alculos necesarios para obter o estado (c´alculo do cuaterni´on, m´odulo da aceleraci´on, proxecci´ons, etc.) e predise se ´e un bo momento para obter unha nova mostra. De selo, faise a captura, almac´enase na memoria do dispositivo, proc´esase, tr´atase de detectar o rostro do usuario e, de ser definitivamente un ´exito, almac´enase o mesmo na memoria como mostra. Modo aforro de enerx´ıa (Low Energy mode). O proceso est´a “durmido”, que non implica pausado nin detido. Periodicamente t´omase a informaci´on dos sensores e servizos, pero non se procesa nin se chega a obter o estado. O recurso da c´amara est´a libre. Este modo de execuci´on lim´ıtase a agardar que se orixine un evento para volver de novo ao modo normal. A permutaci´on entre modos real´ızase en base a unha serie de regras e eventos que poder´an ir variando en futuras versi´ons da ferramenta. A d´ıa de hoxe, son os seguintes: 90 CAP´ ITULO 4. PROPOSTA 1. Bloqueo. Cando se bloquee o dispositivo (evento ACTION SCREEN OFF en Android), solicitarase entrar en modo aforro de enerx´ıa. ´ E moi improbable que se den as circunstancias id´oneas para tomar unha mostra cando o tel´efono est´a bloqueado; o habitual ´e que estea gardado no peto do usuario, pousado nunha mesa, etc. 2. Desbloqueo. Cando se desbloquee o dispositivo (evento Android ACTION USER PRESENT), solicitarase pasar a modo normal. Compre remarcar a diferencia entre desbloqueo do dispositivo e acendido da pantalla (evento ACTION SCREEN ON), xa que o primeiro pode implicar que o usuario acceda ao escritorio do dispositivo mediante un patr´on, contrasinal, PIN, etc. Mentres o usuario estea a empregar o m´obil, ser´a moi probable obter unha boa mostra del. 3. Bater´ıa baixa. Cando o dispositivo entre en estado de “bater´ıa baixa”, o proceso pasar´a a modo aforro de enerx´ıa para procurar prolongar o tempo de uso do m´obil. 4. Solicitude do usuario. Perm´ıtese ao usuario permutar de xeito manual entre os dous modos, pulsando os bot´ons de control proporcionados na notificaci´on do proceso adherida ´a barra de notificaci´ons. Na secci´on 5.2.2 expl´ıcase en detalle esta interacci´on. 5. C´amara ocupada. Se o proceso se atopa en modo aforro de enerx´ıa e o usuario est´a empregando a c´amara do dispositivo para outras finalidades e, de s´upeto, se solicita entrar en modo normal, o proceso volver´a a durmirse. FaceSampler sempre ter´a a menor prioridade de acceso ´a c´amara, co fin de non interferir noutras actividades do usuario. 6. Reinicio do dispositivo. Cando se reinicie o m´obil, o proceso tam´en se reiniciar´a. Actualmente, por complicaci´ons t´ecnicas, non se comproba se a mostraxe estaba en execuci´on cando se apagou o dispositivo, polo que cando este se volva a acender, o proceso ser´a iniciado en modo aforro de enerx´ıa co obxectivo de recordar ao usuario a presencia da ferramenta. 7. ´ Exito. Se se toma unha imaxe que serve como mostra, ent´on solicitarase entrar en modo aforro de enerx´ıa durante un tempo. Por defecto esperaranse 30 segundos para volver a iniciar o modo normal, pero o usuario poder´a modificar esa cantidade desde o panel de preferencias. 8. Fracaso reiterado. Se durante a execuci´on en modo normal se decidiu por catro veces, consecutivas ou non, realizar unha captura, fracasando en todas as ocasi´ons, ent´on ´entrase en modo aforro de enerx´ıa durante un tempo, que de novo ser´a configurable polo usuario (30 segundos por defecto). O contador de fracasos reiniciarase ao momento de mandar o proceso a modo aforro de enerx´ıa. 4.3. AS TECNOLOX´ IAS EMPREGADAS 91 Nas ´ultimas d´uas situaci´ons, ao mesmo tempo que se solicita entrar en modo aforro de enerx´ıa tam´en se programa unha alarma para volver a modo normal. Esta ser´a lanzada transcorrido o tempo acordado. Evidentemente, se o m´obil ´e bloqueado e desbloqueado antes de que transcorra ese tempo, entrarase de novo no modo normal sen esperar pola alarma. 4.3. As tecnolox´ıas empregadas Esta secci´on recolle as ferramentas e tecnolox´ıas empregadas durante o proxecto. Farase maior fincap´e naquelas relativas ao desenvolvemento, pero tam´en se comentar´an as empregadas para labores de xesti´on, co fin de ter todo o material empregado resumido nunha ´unica secci´on. 4.3.1. Equipo e dispositivo de desenvolvemento Como equipo de traballo empregouse un ordenador de uso particular. Tr´atase dun Lenovo Yoga Pro 3 que conta con sistema operativo Ubuntu 16.04 LTS de 64 bits. Ademais, como xa se comentaba no cap´ıtulo introdutorio, necesitouse dun dispositivo Android para o despregamento da aplicaci´on durante o seu desenvolvemento. O Grupo de Sistemas Intelixentes da USC proporcionou un BQ Aquaris E5s, que conta con Android 5.1.1 (Lollipop), as´ı como con unha c´amara frontal de 5 MP, Full HD a 30 fps e unha pantalla IPS con Quantum Color de cinco polgadas con resoluci´on de 1.280x720 p´ıxeles. 4.3.2. Ferramentas Durante o desenvolvemento, empregouse o IDE Android Studio 2.1.2 para a construci´on da aplicaci´on. Escolleuse este IDE e non outro por ser o recomendado nas gu´ıas de desenvolvemento de Google. Tam´en se utilizou StarUML 2.8.0 como software de modelado UML. Neste caso a selecci´on veu dada en base ´a familiaridade existente coa ferramenta. Para a xesti´on do proxecto, empregouse Git por consola de comandos como software de control de versi´ons, tal e como se comentaba na Secci´on 3.1. A ferramenta empregada para a documentaci´on foi TeXstudio 2.11.2. O control da Pila de Produto realizouse con LibreOffice Calc 5.1.6.2. Finalmente, utilizouse ProjectLibre 1.5.7 para o control dos recursos e a planificaci´on temporal. 98 CAP´ ITULO 5. DESE ˜ NO O diagrama adianta alg´uns matices m´ais que ser´an desenvoltos en secci´ons posteriores, como o feito de que o m´odulo de Procesamento de Imaxes se apoie na biblioteca OpenCV ou que a base de co˜necemento utilizada polo m´odulo de Aprendizaxe sexa un ´unico arquivo. Ata aqu´ı chega o resumo do funcionamento xeral do sistema. Nas seguintes secci´ons presentarase o dese˜no detallado de cada unha das capas. 5.2. Dese˜no da capa de presentaci´on A capa de presentaci´on ´e aquela que lle presenta o sistema ao usuario, lle comunica a informaci´on e captura as instruci´ons do mesmo. Tam´en nos podemos referir a ela directamente como interface gr´afica ou de usuario. Nesta secci´on rec´ollese a estratexia seguida para o seu dese˜no, as´ı como os resultados obtidos. Na nosa arquitectura, esta capa comun´ıcase exclusivamente coa capa de control, da que falaremos tam´en neste cap´ıtulo. 5.2.1. Estratexia de dese˜no O dese˜no en Android est´a baseado nunha pulcritude brillante na composici´on da interface. Cada gr´afico, bot´on e texto est´a acompa˜nado pola idea da limpeza visual pero, ao mesmo tempo, sorprende con pequenos detalles. Roboto, a tipograf´ıa propia deste sistema operativo, ´e en gran parte o seu aceno de identidade e comb´ınase cun estilo de bot´ons e cores ben definido. Android avoga pola simplicidade, controlada pero non aburrida, que, en ocasi´ons, rompe os seus propios formalismos para encantar ao usuario. En FaceSampler pret´endese seguir as pautas xerais de Android, polo que a intenci´on foi dese˜nar unha interface nativa, baseada en elementos que ve˜nen preestablecidos na plataforma, pero que contase ao mesmo tempo cunha m´ınima capa de personalizaci´on que brindase un toque de identidade propia ´a aplicaci´on. A ferramenta est´a dotada de intelixencia, integrando para elo toda unha l´oxica de automatizaci´on, resposta a eventos do entorno e toma de decisi´ons notable, que lle outorga autonom´ıa e independencia do usuario. Isto fai que FaceSampler se poida caracterizar en gran medida por necesitar dunha interacci´on m´ınima coa pantalla por parte do usuario. ´ E por iso polo que o dese˜no se centrou tam´en en lograr unha facilidade de uso extrema, baseada nun dese˜no minimalista, que require de moi pouca navegaci´on entre pantallas e brinda escasa interacci´on de xeito intencionado para fomentar a despreocupaci´on por parte do usuario da ferramenta. 5.2. DESE ˜ NO DA CAPA DE PRESENTACI ´ ON 99 Por suposto, pret´endese que a aplicaci´on sexa agradable esteticamente. Para elo, ´optase por seguir as pautas Material Design1, respectando os principios de estruturaci´on, dimensionado e proporcionalidade das layouts, as´ı como as recomendaci´ons referentes ´as iconas (todas as empregadas cumpren os criterios para considerarse est´andar) e ´as cores (empr´eganse cores da propia paleta suxerida por Google) [29]. Esta interface ten en conta tam´en a adaptabilidade a variedade de tama˜nos e resoluci´ons de pantalla. Para facilitar o dese˜no, Android clasifica as pantallas en catro grupos para o tama˜no (pequeno,normal,grande eextragrande) e outros seis para a densidade de p´ıxeles (ldpi,mdpi,hdpi,xhdpi,xxhdpi exxxhdpi). Todas as iconas empregadas en FaceSampler dispo˜nen dunha versi´on distinta para cada unha das seis densidades posibles. O propio sistema Android realiza un axuste autom´atico que clasifica o dispositivo no grupo m´ais apropiado, seleccionando as iconas correspondentes. Na Figura 5.4 am´osase o primeiro bosquexo da interface, realizado inicialmente a man alzada e posteriormente volto a facer a limpo para integralo nesta memoria. Nel ind´ıcanse os compo˜nentes de cada pantalla, as´ı como o fluxo entre as mesmas. O m´ais destacable aqu´ı pode ser o feito de que nunha vi˜neta tan pequena se logra recoller a maior parte da navegaci´on da aplicaci´on. 5.2.2. Interface final Vista a estratexia de dese˜no podemos agora comentar a interface gr´afica resultado. A´ında que alg´uns compo˜nentes da mesma sexan xerados de xeito din´amico en Java, a maior´ıa rec´ollense en arquivos XML co˜necidos como recursos (resources). Todos os recursos XML mencionados nesta secci´on local´ızanse baixo a ruta app/src/main/res do proxecto Android Studio. A Figura 5.5 amosa a vista principal da aplicaci´on. Esta ofrece as d´uas funcionalidades principais, adestramento e mostraxe, e permite cambiar entre elas seleccionando a pestana desexada. Os elementos gr´aficos com´uns da vista principal est´an descritos no arquivo [...]/layout-v21/main view.xml, de tipo layout. A modalidade de mostraxe (5.5b) ´e a primeira que o usuario ve ao iniciar FaceSampler, e o seu dese˜no rec´ollese no recurso [...]/layout-v21/sampling view.xml. Ao premer no bot´on Start!2nesta modalidade comezar´a o proceso de captaci´on de mostras do usuario en segundo plano. 1Material Design ´e un concepto, unha filosof´ıa, unhas pautas enfocadas ao dese˜no utilizado en Android, pero tam´en na web e en calquera plataforma [28]. Recibe o seu nome por estar baseado en obxectos materiais, pezas colocadas nun espazo e nun momento determinado. 2Para a memoria optouse por empregar as vistas en ingl´es, pero hai que ter en conta que o texto inclu´ıdo nas mesmas variar´a en funci´on da linguaxe do sistema. 100 CAP´ ITULO 5. DESE ˜ NO START Icona de Training FaceSampler Training Category 1 START Icona de Sampling FaceSampler Training Sampling STOP Icona de Sampling FaceSampler Training Sampling Training Settings Setting 1 Setting 2 Category 2 Setting 3 Setting 4 . . . Sampling #00FF00 Sampling in progress... 11:35 Notificación do proceso Icona da app Figura 5.4: Bosquexo inicial da interface gr´afica de FaceSampler. A modalidade de adestramento (5.5a) emprega o dese˜no descrito no arquivo [...]/layout/training view.xml. Premendo no bot´on Start! deste modo redir´ıxese ao usuario ´a vista de adestramento en primeiro plano, a cal se pode ver na Figura 5.6. Nesta pantalla amosaranse en tempo real as imaxes capturadas pola c´amara frontal do dispositivo, as´ı como datos interesantes para a aprendizaxe (iluminaci´on, aceleraci´on, orientaci´on do dispositivo, etc.). Cando se detecte o rostro do usuario, marcarase cun cadro verde tal e como amosa a Figura 5.6b. Sexa cal sexa o estado da vista principal (Figura 5.5), premendo na icona con forma de engrenaxe situada na esquina superior dereita da pantalla estaremos accedendo ao panel de preferencias (Figura 5.7). Desde este poderanse realizar todos os axustes que se desexe, as´ı como consultar a informaci´on da versi´on ou acceder ´a p´axina web da ferramenta. A descrici´on XML das preferencias rec´ollese no arquivo [...]/xml/preferences.xml. O panel de preferencias non disp´on dunha pantalla ´unica. Existe informaci´on que ´e amosada nunha sub-vista ´a parte co obxectivo de evitar dispor dun panel ´unico e monol´ıtico no que custe acceder aos contidos. A Figura 5.7b ub´ıcase na subvista de Timings, e recolle a acci´on de modificar un valor num´erico por medio 5.2. DESE ˜ NO DA CAPA DE PRESENTACI ´ ON 101 (a) Modo adestramento. (b) Modo mostraxe. Figura 5.5: Vista principal de FaceSampler. dun di´alogo flotante de tipo number picker1. O dese˜no deste di´alogo at´opase no arquivo [...]/layout/preference number picker dialog.xml. Cando se ordena comezar a mostraxe desde a vista principal (Figura 5.5b), l´anzase un proceso en segundo plano que nunca se deter´a ata que o usuario prema expresamente no bot´on Stop! que substituir´a ao de Start! amosado antes do inicio. Para que o usuario sexa consciente da existencia de dito proceso, adh´ırese unha notificaci´on ´a barra de notificaci´ons de Android tal e como se amosa na Figura 5.8. A´ında que o seu obxectivo principal sexa o de servir como recordatorio, a notificaci´on tam´en se emprega como acceso directo ´a vista principal da aplicaci´on e permite durmir/despertar (Sleep/Wake) o proceso de mostraxe, as´ı como detelo totalmente (Stop). 1As preferencias do tipo number picker son aquelas que permiten axustar un valor de tipo num´erico enteiro (por exemplo, segundos, minutos, cantidades, etc.) por medio dunha roda deslizable. 102 CAP´ ITULO 5. DESE ˜ NO (a) O usuario non est´a presente. (b) Det´ectase un rostro. Figura 5.6: Vista de adestramento en primeiro plano. Icona de lanzamento Se pensamos na aplicaci´on como un produto que estar´a nun escaparate xunto a moitos outros, ent´on a icona de lanzamento ´e o embalaxe que o envolve. En primeiro lugar, esta icona ser´a s´ımbolo de identidade da aplicaci´on e permitir´a identificala nas tendas de aplicaci´ons como elemento de venta para convencer ao usuario de descargala. Sorteado este paso e unha vez instalada no dispositivo, esta ter´a que convivir con moitas outras das que dispo˜na o usuario. Tendo en conta a s´ua relevancia, para FaceSampler decidiuse por empe˜no en crear unha icona de lanzamento distintiva e representativa. Avogouse por formas simples, non moi cargadas e coidadas nos seus detalles. No est´andar de Android as iconas son obxectos representados frontalmente, que soen xogar coas sombras, lixeiras perspectivas ou transparencias para non caer na monoton´ıa. A Figura 5.9 amosa a icona de lanzamento elaborada. O dese˜no est´a inspirado na idea de “mostraxe intelixente”, onde a c´amara simboliza a mostraxe e o birrete a intelixencia. 5.2. DESE ˜ NO DA CAPA DE PRESENTACI ´ ON 103 (a) Pantalla principal. (b) Di´alogo flotante do tipo number picker. Figura 5.7: Panel de preferencias. (a) Icona adherida ´a barra de notificaci´ons. (b) Detalle da notificaci´on. Figura 5.8: Notificaci´on de mostraxe en execuci´on. 104 CAP´ ITULO 5. DESE ˜ NO Figura 5.9: Icona de lanzamento de FaceSampler. 5.2.3. An´alise heur´ıstica de usabilidade Nesta secci´on rec´ollese a avaliaci´on heur´ıstica da interface de usuario realizada previa implementaci´on da mesma na capa de presentaci´on. Como criterios de avaliaci´on empreg´aronse os 10 principios heur´ısticos de Nielsen [30]. O obxectivo desta an´alise foi detectar errores de usabilidade. Avaliaci´on A avaliaci´on consiste en tratar de demostrar que o dese˜no da interface gr´afica cumpre con cada un dos principios de Nielsen, argumentando para cada un deles as caracter´ısticas da aplicaci´on que conseguen ditos obxectivos. 1. Visibilidade do estado do sistema. A aplicaci´on indica en todo momento na barra de acci´on en que secci´on se atopa o usuario. Se se produce alg´un erro inesperado durante a execuci´on, o sistema Android encargarase de notificalo. Os procesos en execuci´on que non estean ´a vista do usuario notif´ıcanse por medio de alertas adheridas ´a barra de notificaci´ons do dispositivo. 2. Utilizaci´on da linguaxe dos usuarios. A aplicaci´on emprega unha linguaxe natural e nunca termos abstractos. Ademais, sop´ortanse tres linguaxes distintas: ingl´es (por defecto), espa˜nol e galego. Por ´ultimo, empr´eganse as iconas estandarizadas para a plataforma Android, que son perfectamente identificables polos usuarios deste sistema operativo. 3. Control e liberdade para o usuario. O usuario co˜necer´a en todo momento o estado da aplicaci´on grazas ao reforzo visual. Como se comentaba antes, se existe alg´un proceso en execuci´on que non estea ´a vista o usuario ser´a notificado. Se o usuario desexa reverter unha acci´on que realizou por 5.2. DESE ˜ NO DA CAPA DE PRESENTACI ´ ON 105 error, a aplicaci´on volver´a ´a vista ou estado anterior de xeito practicamente instant´aneo, a´ında que alg´uns efectos tal vez non poidan ser reversibles (como re-adestrar ao dispositivo). 4. Consistencia e est´andares. S´eguense as normas e convenci´ons xerais para o desenvolvemento de aplicaci´ons Android: Barra de acci´on na parte superior, con bot´on de retroceso na esquina esquerda e bot´on de preferencias na dereita. Iconas estandarizadas. Cadros de texto e etiquetas de tama˜no abundante para ver nunha pantalla pequena. Bot´ons grandes para facilitar a s´ua pulsaci´on co dedo. 5. Prevenci´on de erros. Un problema habitual ´e o uso indebido da aplicaci´on por parte dos usuarios. A estratexia en FaceSampler consiste en tratar de reducir ao m´aximo a posibilidade de fallo cando o usuario proporciona datos ao sistema. Para elo, ´optase por inputs de tipo button,radio button,combo box eon/off button. Este conxunto de entradas ´e dabondo para brindarlle ao usuario todas as funcionalidades previstas, inclu´ındo por suposto o control de preferencias. 6. Minimizaci´on da carga da memoria do usuario. Non existe ningunha acci´on que obrigue ao usuario a recordar ning´un dato dalg´un paso previo. 7. Flexibilidade e eficiencia de uso. A aplicaci´on implementa procesos sinxelos para o usuario. Ademais, a navegaci´on requirida ´e m´ınima, pois a interface componse de moi poucas pantallas. 8. Di´alogos est´eticos e dese˜no minimalista. Cada pantalla da aplicaci´on amosa a informaci´on m´ınima imprescindible, evitando sobrecargar a interface. Nos di´alogos, notificaci´ons e demais alertas proc´urase empregar sempre frases curtas e concisas. 9. Axudar aos usuarios a reco˜necer, diagnosticar e recuperarse de erros. Android xestiona os erros de forma doada, notificando debidamente cada tipo de erro (ANRs, bloqueos, procesamento lento, etc.). A recuperaci´on dos mesmos ser´a inmediata, pois bastar´a con volver abrir a aplicaci´on (moitas veces o propio sistema Android volver´a a lanzala automaticamente). 10. Axuda e documentaci´on. A aplicaci´on caracter´ızase en gran medida pola facilidade de uso. Non obstante, est´a previsto elaborar un manual de usuario por se nalg´un caso resulta necesario recorrer ao mesmo. 106 CAP´ ITULO 5. DESE ˜ NO Erros identificados A an´alise serviu para identificar alg´uns aspectos a mellorar no dese˜no da interface de usuario: Ao avaliar o cumprimento do principio 3 detectouse que poden darse ocasi´ons nas que o usuario non te˜na a capacidade de reverter unha acci´on tomada por accidente. Concretamente, se se toca por erro o bot´on de iniciar adestramento, o sistema esquecer´a no acto o adestramento previamente realizado, de existir. Soluci´on: No caso de que se vaia a sobrescribir un adestramento previo, o sistema debe solicitar confirmaci´on por parte do usuario cun cadro de di´alogo. Esta nova caracter´ıstica engadiuse ao final da Pila de Produto e est´a actualmente ´a espera de ser implementada nun futuro sprint, xa fora do marco deste proxecto, posto que a s´ua prioridade ´e baixa. Ao avaliar o cumprimento do principio 9 reco˜neceuse a carencia dunha personalizaci´on na xesti´on de erros. ´ E certo que Android ofrece un sistema de notificaci´on e reporte de incidencias moi bo, pero tal vez en ocasi´ons sexa necesario amosar mensaxes de erro m´ais concretas, prescindindo das xen´ericas que ofrece esta plataforma. Soluci´on: Fixouse como necesidade identificar durante o desenvolvemento aqueles erros que precisasen dun trato personalizado e propio de FaceSampler. Na actualidade, rematado xa o desenvolvemento, identificouse tan s´o un: o bloqueo producido durante o arranque da aplicaci´on por problemas de dependencias [CU-1]. Ao avaliar o cumprimento do principio 10 reafirmouse a necesidade de dispor dun manual de usuario. Soluci´on: Redactouse un manual de usuario, que pode consultarse no Ap´endice C. 5.3. Dese˜no da capa de control A capa de Control responde a eventos e invoca petici´ons ao modelo cando se fai algunha solicitude sobre a informaci´on. Ditos eventos soen ser acci´ons do usuario orixinadas ao interactuar coa capa de Presentaci´on, pero tam´en se xestionan aqueles eventos do sistema Android, como poden ser alarmas, rotaci´on do dispositivo, 5.3. DESE ˜ NO DA CAPA DE CONTROL 107 bloqueo do mesmo, etc. Esta capa da aplicaci´on corresp´ondese co contido completo do paquete Java com.citius.fernando.faceSampler.controller1. Para unha boa comprensi´on do dese˜no deste controlador, semella oportuno expo˜ner unha breve xustificaci´on a alto nivel de cada clase que o comp´on (polo menos das m´ais relevantes), de xeito previo ´a exposici´on de ning´un tipo de diagrama estrutural. As tarxetas CRC empregadas durante o desenvolvemento poden ser o mellor xeito de logralo. En primeiro lugar, para controlar as funcionalidades ofrecidas pola vista principal da aplicaci´on empr´egase a MainActivity, unha clase que estende da xa comentada Activity de Android (ver Secci´on 5.1) e que emprega dous fragmentos2, un para cada modo de uso (adestramento e mostraxe): CRC-1 MainActivity Autor: Fernando Est´evez Responsabilidades: •Controlar a interacci´on entre o usuario e a vista principal da aplicaci´on (ver Figura 5.5). Colaboradores: •TrainingFragment •SamplingFragment Para a xesti´on das preferencias, compre destacar as seguintes clases: CRC-2 SettingsActivity Autor: Fernando Est´evez Responsabilidades: •Controlar a interacci´on entre o usuario e o panel de preferencias da aplicaci´on (ver Figura 5.7). •Habilitar e deshabilitar a capacidade de manipular as preferencias en funci´on das condici´ons dadas polo contexto e o dispositivo. Colaboradores: Non aplica. CRC-3 NumberPickerPreference Autor: Fernando Est´evez Responsabilidades: •Controlar a interacci´on entre o usuario e as preferencias de tipo number picker (ver Figura 5.7b), non provistas por defecto no entorno Android. Colaboradores: Non aplica. 1Todo o c´odigo Java da aplicaci´on local´ızase baixo a ruta app/src/main/java do proxecto Android Studio. 2Un fragmento (android.app.Fragment) representa un comportamento ou unha parte da interface de usuario nunha Activity. P´odense combinar varios fragmentos nunha soa actividade para crear unha IU multipanel e volver a usar un fragmento en m´ultiples actividades [31]. 114 CAP´ ITULO 5. DESE ˜ NO Figura 5.12: Diagrama de clases do m´odulo de Procesamento de imaxes. 5.4. DESE ˜ NO DA L ´ OXICA DE NEGOCIO 115 CRC-11 ImageSubscriberInterface Autor: Fernando Est´evez Responsabilidades: •Definir os m´etodos que debe implementar todo aquel que desexe subscribirse ao sistema de captura de imaxes. Colaboradores: Non aplica. A interface ImageCaptorInterface ´e implementada por d´uas clases distintas, que empregan t´ecnicas distintas de captaci´on. A primeira delas ´e ImageCaptorViewer, pensada para a captura de xeito continuo, amosando os resultados por pantalla en tempo real. A segunda ´e CameraService, un servizo destinado a tomar imaxes puntuais incluso se a aplicaci´on est´a en segundo plano ou o seu proceso principal (da interface gr´afica) rematou. Este ´ultimo emprega ImageFileWriter para gardar as capturas e mostras na memoria do dispositivo. No sub-m´odulo de detecci´on de rostros atopamos: CRC-12 FaceDetectorInterface Autor: Fernando Est´evez Responsabilidades: •Servir como porta de entrada ao sub-m´odulo, para definir as operaci´ons que este ofrece ao exterior: detectar rostros nas imaxes que o solicitante proporcione. Colaboradores: Non aplica. CRC-13 FaceDetector Autor: Fernando Est´evez Responsabilidades: •Dar soporte ´as operaci´ons definidas por FaceDetectorInterface. Colaboradores: •ImageQualityAnalyzer [CRC-14] •ImagePreparer [CRC-15] CRC-14 ImageQualityAnalyzer Autor: Fernando Est´evez Responsabilidades: •Identificar problemas relacionados coa calidade da imaxe. Ata a data, perm´ıtese detectar cando unha imaxe ´e borrosa (ten blur). Colaboradores: Non aplica. CRC-15 ImagePreparer Autor: Fernando Est´evez 116 CAP´ ITULO 5. DESE ˜ NO CRC-15 ImagePreparer (cont.) Responsabilidades: •Marcar na imaxe as caras detectadas tal e como se describe no requisito non funcional [RNF-3]. •Rotar a imaxe e reverter a rotaci´on. •Recortar a imaxe orixinal (captura) deixando s´o a cara do usuario (mostra). Colaboradores: Non aplica. FaceDetectorInterface ´e implementada tan s´o por FaceDetector. Se nun futuro se desexa introducir un novo sistema de detecci´on, este tam´en deber´a respectar a interface definida. 5.4.3. M´odulo de Aprendizaxe Este m´odulo cont´en a algoritmia necesaria para poder aconsellar ´a capa de Control na toma de decisi´ons. A Figura 5.13 recolle o seu diagrama de clases UML. Nel podemos distinguir tres grandes paquetes: stateAnalyzer,algorithms e executionModes. En stateAnalyzer sit´uanse os analizadores de estados. A s´ua tarefa ´e estudar e contrastar o estado actual do dispositivo co dataset de adestramento baixo a supervisi´on do controlador con fins diversos. Debemos destacar as seguintes clases: CRC-16 StateAnalyzerInterface Autor: Fernando Est´evez Responsabilidades: •Empregarse como porta de entrada ao m´odulo de Aprendizaxe. •Definir os m´etodos que todo analizador de estados debe soportar. Colaboradores: •StateObtainerInterface [CRC-6] •ImageCaptorInterface [CRC-10] •FaceDetectorInterface [CRC-12] •LearningAlgorithmFactory CRC-17 TrainingStateAnalyzer Autor: Fernando Est´evez 5.4. DESE ˜ NO DA L ´ OXICA DE NEGOCIO 117 CRC-17 TrainingStateAnalyzer (cont.) Responsabilidades: •Dar soporte aos m´etodos definidos en StateAnalyzerInterface. •Crear o dataset de adestramento a partir da an´alise do estado do dispositivo en contraste coa informaci´on proporcionada polo m´odulo de Procesamento de imaxe. Colaboradores: Non aplica. CRC-18 SamplingStateAnalyzer Autor: Fernando Est´evez Responsabilidades: •Dar soporte aos m´etodos definidos en StateAnalyzerInterface. •Predicir cando ´e un bo momento para tomar unha captura e obter unha mostra v´alida para o modelo de usuario contrastando o dataset de adestramento co estado actual do dispositivo. Colaboradores: Non aplica. Os dous analizadores dese˜nados [CRC-17, CRC-18] ofrecen d´uas funcionalidades totalmente distintas, a´ında que ambas seguen o mesmo esquema. A s´ua inclusi´on sup´on un alivio na carga l´oxica da capa de Control, podendo considerarse helpers do mesmo (patr´on delegation). Os analizadores actuar´an periodicamente de xeito independente ao controlador, e s´o se deter´an baixo a s´ua orde expl´ıcita. O paquete algorithms proporciona os algoritmos de toma de decisi´ons implementados. Para elo integra dous co˜necidos patr´ons de dese˜no: singleton efactory. A LearningAlgorithmFactory ´e a factor´ıa que proporciona o algoritmo axeitado en cada momento, atendendo ao contexto. Todo algoritmo que se desexe integrar na aplicaci´on debe implementar a interface LearningAlgorithmInterface. Desde o panel de preferencias, o usuario poder´a escoller o algoritmo que desexe empregar e, ao momento, a factor´ıa comezar´a a subministrar a instancia correspondente. Para evitar instanciaci´ons innecesarias, tanto LearningAlgorithmFactory como cada un dos algoritmos empregan o patr´on singleton para proporcionar un ´unico punto de acceso global a cada elemento. Este dese˜no facilita a escalabilidade algor´ıtmica solicitada [RNF-13]. Para rematar, o paquete executionModes ´e o encargado de xestionar e notificar os cambios de modo entre execuci´on normal e aforro de enerx´ıa que se efect´uan no proceso de mostraxe. Introd´ucese aqu´ı o patr´on observer, onde ExecutionModeHandler ´e a clase observada, que controla os cambios efectuados, mentres que os observadores ser´an todas aquelas clases que implementen a interface ModeExecutionObserverInterface. Actualmente, os observadores do 118 CAP´ ITULO 5. DESE ˜ NO Figura 5.13: Diagrama de clases do m´odulo de Aprendizaxe. 5.5. DESCRICI ´ ON DA INTERACCI ´ ON 119 modo de execuci´on son dous: StateObtainer do m´odulo de recolecci´on de datos eForegroundSamplingService da capa de Control. 5.5. Descrici´on da interacci´on Para conclu´ır coa documentaci´on do dese˜no, nesta secci´on ach´egase unha descrici´on da interacci´on entre os distintos compo˜nentes presentados ao longo do cap´ıtulo. Para elo, rec´orrese ao emprego de diagramas de secuencia UML. Dada a inviabilidade dunha representaci´on exhaustiva de dita interacci´on (cumprir´ıa, cando menos, un diagrama de secuencia por cada caso de uso descrito na Secci´on 2.4), decidiuse plasmar o fluxo orixinado durante os dous procesos principais (e tam´en m´ais complexos): adestramento e mostraxe. Na Figura 5.14 am´osase o diagrama de secuencia do proceso de adestramento en primeiro plano. Abarca os tres casos de uso relacionados co mesmo [CU-10, CU-11, CU-12]. O adestramento comeza coa solicitude do usuario a trav´es da interface gr´afica. Na capa de control, MainActivity xestiona a petici´on e solicita a creaci´on dunha ForegroundTrainingActivity a trav´es dun intent1de Android. Se o dispositivo conta cunha versi´on Android 6.0 (Marshmallow) ou superior, os permisos de acceso ´a c´amara e ao almacenamento interno ter´an que pedirse de xeito din´amico2.ForegroundTrainingActivity instancia as dependencias necesarias e comeza o proceso de adestramento. Periodicamente, o analizador realiza a chamada as´ıncrona 10: takePicture(this) ao sistema de captura. Na resposta, obtense o estado actual, dev´olvese a imaxe e compr´obase que esta ´e o suficientemente n´ıtida (chamada est´atica 14: hasBlur(frame)). S´o en caso afirmativo se procede a detectar os rostros na mesma. A´ında que o diagrama non o recolle explicitamente, chegados a este punto etiqu´etase o estado como un ´exito ou un fracaso en base ´as condici´ons dadas. Finalmente, comun´ıcase a imaxe procesada ´a vista. Este proceso rep´ıtese durante todo o tempo que o usuario desexe, ata que prema o bot´on de retroceso, finalizando as´ı o adestramento. O diagrama da Figura 5.14 non recolle outras acci´ons como as contempladas nos casos de uso de pausar a aplicaci´on [CU-5] ou retomala [CU-6] porque a complexidade do mesmo aumentar´ıa notoriamente e non cumprir´ıa co seu obxectivo, que ´e o de axudar na comprensi´on da interacci´on orixinada neste escenario concreto. 1Un intent (android.content.Intent) ´e un obxecto de acci´on que se pode empregar para solicitar unha acci´on de outro compo˜nente da aplicaci´on. A´ında que os intents facilitan a comunicaci´on entre os compo˜nentes de moitas maneiras, existen tres casos de uso fundamentais: comezar unha actividade, comezar un servizo e entregar unha mensaxe [34]. 2Ditos permisos solicitaranse polo menos a primeira vez que se realice o adestramento ou a mostraxe. Se o usuario marca a opci´on de “lembrar elecci´on” non se lle volver´an a solicitar. Decidiuse plasmar esta comprobaci´on de permisos no diagrama xa que engade valor ao mesmo sen introducir demasiada complexidade. 120 CAP´ ITULO 5. DESE ˜ NO A Figura 5.15 presenta o diagrama de secuencia do proceso de mostraxe, abarcando os tres casos de uso relacionados co mesmo [CU-7, CU-8, CU-9]. O comezo ´e moi semellante ao do caso anterior: o usuario solicita que se inicie a mostraxe e a MainActivity comproba os permisos de ser necesario. Neste caso, solic´ıtase crear un ForegroundSamplingService, tam´en mediante un intent. O proceso de an´alise desta vez ´e diferente: com´ezase obtendo o estado para logo facer a predici´on. As chamadas ´a LearningAlgorithmFactory e ao algoritmo en cuesti´on son est´aticas sempre. No diagrama incl´uese a interface LearningAlgorithmInterface xa que o algoritmo a empregar depender´a das condici´ons do contexto. Logo da chamada 20: takePicture(this) om´ıtese o callback que realiza o sistema de captura, xa que engade demasiada complexidade ao diagrama. Nese callback comprobar´ıase se realmente a imaxe ´e un ´exito, de igual xeito a como se fai na Figura 5.14. Om´ıtense tam´en a almacenaxe das capturas e mostras en memoria. Igual que no caso do adestramento, non se contemplan outras casu´ısticas relacionadas (permutaci´ons entre modos de execuci´on) porque ´e inviable. 5.5. DESCRICI ´ ON DA INTERACCI ´ ON 121 Figura 5.14: Diagrama de secuencia do proceso de adestramento. 5.5. DESCRICI ´ ON DA INTERACCI ´ ON 123 130 CAP´ ITULO 6. EXECUCI ´ ON DE PROBAS E BETA PRIVADA (a) Execuci´on de PA-6.(b) Execuci´on de PA-10. Figura 6.3: Exemplos de mapas de actividade de Firebase (miniaturas). Proba Dispositivo v. Android Orientaci´on Duraci´on Resultado Incidencias PA-1 Galaxy Note 3 4.4 Retrato 38 s Erro INC-3 PA-2 Google Nexus 7 5.0 Retrato 5 min 21 s Ok PA-3 Google Nexus 9 5.0 Retrato 4 min 11s Ok PA-4 Sony Xperia Z3 5.0 Retrato 4 min 51s Ok PA-5 OnePlus One 5.1 Retrato 4 min 49 s Ok PA-6 Google Nexus 6 5.1 Retrato 4 min 15 s Ok PA-7 Galaxy Note 4 5.1 Retrato 4 min 15 s Ok PA-8 Motorola Moto G4 6.0 Retrato 2 min 18 s Ok PA-9 Galaxy S7 edge 6.0 Retrato 3 min 29 s Erro INC-4 PA-10 Google Nexus 5 6.0 Retrato 5 min 20 s Ok PA-11 Google Nexus 5 6.0 Paisaxe 4 min 50 s Ok PA-12 Sony Xperia X 6.0 Retrato 4 min 39s Ok PA-13 Galaxy S7 7.0 Retrato 3 min 26 s Ok PA-14 Google Pixel 7.1 Retrato 5 min 15 s Ok PA-15 Google Nexus 5X 7.1 Retrato 5 min 9 s Ok PA-16 Google Nexus 5X 7.1 Paisaxe 5 min 8 s Ok T´aboa 6.2: Resumo de execuci´on das probas aleatorias. 6.2. BETA PRIVADA 131 de voluntarios tiveron acceso ´as funcionalidades de FaceSampler. Nesta secci´on comentarase como foi o seu proceso de posta a punto, as´ı como os resultados obtidos. 6.2.1. Posta a punto En primeiro lugar, era necesario dispor dun m´etodo de distribuci´on do instalador da ferramenta. Decidiuse empregar a plataforma Google Play Store por diversas raz´ons. Por un lado, ´e o xeito m´ais habitual e seguro polo cal os usuarios de dispositivos Android poden descargar as aplicaci´ons que desexan; tr´atase, por´en, dunha tenda online co˜necida de xeito obrigado por todos os usuarios deste ecosistema. Polo outro, o feito de publicala pola v´ıa de Google permite empregar a Google Play Console para administrar todas as fases da publicaci´on, facer un seguimento dos usuarios, xestionar as versi´ons, controlar a distribuci´on e recompilar estat´ısticas antes e despois do lanzamento. A Figura 6.4 amosa un fragmento do panel principal de control desta consola, que recolle datos estat´ısticos sobre instalaci´ons, usuarios, valoraci´ons e bloqueos. FaceSampler  Publicada ENVIAR ACTUALIZACIÓN © 2017 Google · Ayuda · Condiciones del sitio web · Privacidad · Acuerdo de distribución para desarrolladores Publicación estándar  Instalaciones por usuario VER DETALLES 8 Desde el principio Desinstalaciones por usuario VER DETALLES 8 Desde el principio Instalaciones por usuario VER DETALLES Países principales España 8,00 Descargas en dispositivos activos VER DETALLES 4 Últimos 30 días Número de valoraciones VER DETALLES Estos datos no están disponibles. Valoración media VER DETALLES Estos datos no están disponibles. Bloqueos VER DETALLES 129 Desde el principio Android vitals VER DETALLES Estos datos no están disponibles. Las estadísticas de la aplicación se actualizan diariamente. Todas las estadísticas se calculan con base en la zona horaria PST/PDT. 8 may. 20178 may. 20178 may. 2017 15 may. 201715 may. 201715 may. 2017 22 may. 201722 may. 201722 may. 2017 29 may. 201729 may. 201729 may. 2017 3,53,53,5 444 4,54,54,5 555 8 may. 20178 may. 20178 may. 2017 15 may. 201715 may. 201715 may. 2017 22 may. 201722 may. 201722 may. 2017 29 may. 201729 may. 201729 may. 2017 222 444 666 888 8 may. 20178 may. 20178 may. 2017 15 may. 201715 may. 201715 may. 2017 22 may. 201722 may. 201722 may. 2017 29 may. 201729 may. 201729 may. 2017 454545 606060 757575 909090 7 DÍAS 30 DÍAS 1 AÑO DESDE EL PRINCIPIO Panel de control Buscar aplicaciones Tus aplicaciones  Panel de control  Estadísticas  Android vitals  Herramientas de desarrollo   Gestión de versiones  Panel de la versión Versiones de la aplicación Aplicaciones Instantáneas Android Biblioteca de artefactos Catálogo de dispositivos Firma de aplicaciones Informe previo al lanzamiento Presencia en Google Play Store   Adquisición de usuarios  Comentarios de los usuarios   Figura 6.4: Panel de control de Google Play Console. 132 CAP´ ITULO 6. EXECUCI ´ ON DE PROBAS E BETA PRIVADA Desex´abase garantir que todos os usuarios seleccionados fixesen un correcto uso da ferramenta. Sen embargo, non todos eles ´ıan estar necesariamente familiarizados co reco˜necemento de patr´ons. O feito de obrigar aos voluntarios a adestraren os seus dispositivos pod´ıa provocar que os adestramentos fosen pouco exhaustivos e, en consecuencia, que a mostraxe fose deficiente. Neste punto foi cando se introduciu o caso de uso “Xestionar o adestramento por defecto” [CU-15], inclu´ındo no instalador da ferramenta un dataset de adestramento “de f´abrica”, xerado co dispositivo de desenvolvemento (o Bq Aquaris E5s). Deste xeito, unha vez instalada a aplicaci´on no dispositivo dos usuarios pod´ıase comezar inmediatamente a mostraxe, sen necesidade dun adestramento previo. Evidentemente, se o usuario o desexase, sempre poder´ıa realizar el o adestramento e seleccionar que dataset empregar desde o panel de preferencias, tal e como se describe no caso de uso antes citado. De novo para garantir a eficiencia da mostraxe, alg´uns axustes foron bloqueados para forzar aos usuarios a empregar a mesma configuraci´on na aprendizaxe. Estableceuse k-NN como algoritmo a utilizar por ser prudente na toma de decisi´ons. Ademais, o conxunto de datos de entrada foi configurado para inclu´ır exclusivamente aquelas variables que realmente aportasen valor na aprendizaxe. Tan s´o quedou exclu´ıdo o tempo transcorrido desde o ´ultimo toque de pantalla. O motivo da exclusi´on foi que para poder instru´ır ao dispositivo en base a toques de pantalla de xeito natural necesitar´ıase levar a cabo un adestramento en segundo plano durante un tempo prolongado, realizando tarefas habituais e coti´as; sen embargo, o noso sistema est´a pensado para aplicar adestramentos r´apidos e en primeiro plano, de cara a demostraci´ons, que non permiten simular unha interacci´on normal co dispositivo no que respecta ao toque de pantalla. Para que todos os usuarios empregasen esta configuraci´on e non fose modificada por ningu´en, deshabilitouse a secci´on de preferencias relativa ´as entradas da aprendizaxe [CU-16]. 6.2.2. Resultados obtidos Durante este per´ıodo, un total de 8 voluntarios usaron a aplicaci´on de forma continua no seu d´ıa a d´ıa. Ped´ıuselles a todos agardar ata que a ferramenta obtivese un banco de 220 mostras (samples [RI-2]) das s´uas caras. O tempo de emprego por usuario variou en funci´on de diversos factores, como a frecuencia de uso do dispositivo, as condici´ons de contexto ´as que se someteu a aplicaci´on para tomar as fotos, ´a efectividade do adestramento por defecto en cada dispositivo, etc. Hai individuos que tan s´o precisaron tres d´ıas para acadar ese n´umero de mostras, mentres que outros requiriron de tres semanas. A T´aboa 6.3 amosa a variedade de dispositivos nos que se probou a aplicaci´on, as´ı como a versi´on Android de cada un. 6.2. BETA PRIVADA 133 Dispositivo Versi´on Android Samsung Galaxy Note 3 5.0 LG G4 5.1 Bq Aquaris E5s 5.1 OnePlus One 6.0 Asus Zenfone Selfie 6.0 HTC One M9 6.0 Nexus 5X 7.1 Bq Aquaris X5 Plus 7.1 T´aboa 6.3: Dispositivos da beta privada. De media, a taxa de acertos foi do 45,32 %. Isto implica que, practicamente, por cada d´uas capturas realizadas, unha serviu como mostra da cara do usuario. ´ E dicir, que o sistema necesita tomar en torno a 490 capturas para poder quedarse con 220 mostras. Agora ben, compre destacar que a configuraci´on empregada nesta beta volveu ao sistema moi conservador, de xeito que practicamente a totalidade das imaxes escollidas como mostras son perfectamente v´alidas e de calidade, pero moitas veces descart´aronse outras que, de rebaixar un pouco os requisitos, ser´ıan tam´en aceptadas sen problema. Vexamos alg´uns exemplos. Na Figura 6.5 am´osanse cinco mostras do modelo obtido para un ´unico usuario. P´odese apreciar que a calidade de todas elas cumpre con creces os m´ınimos desexados: conte˜nen o rostro do usuario perfectamente encadrado, coa iluminaci´on e nitidez suficientes. Evidentemente, algunhas son m´ais n´ıtidas e outras m´ais borrosas, as´ı como unhas son m´ais claras e outras m´ais escuras, pero esta variedade, orixinada pola dependencia co contexto, ´e precisamente do que desexamos dispor nos nosos modelo. Figura 6.5: Exemplos de imaxes clasificadas como mostras. Na Figura 6.6 vemos, pola contra, capturas que foron descartadas como mostras. Nestas imaxes non hai lugar a d´ubida sobre a raz´on do seu rexeitamento. Existe unha minor´ıa delas onde nin tan sequera aparece o usuario. En moitas outras si que sae, pero cortado e desenfocado debido normalmente a un movemento brusco efectuado xusto no momento en que o sistema toma a decisi´on de realizar 134 CAP´ ITULO 6. EXECUCI ´ ON DE PROBAS E BETA PRIVADA a captura. Tam´en existen outras nas que o rostro non se distingue ben por sa´ır a contraluz ou nun ambiente moi pouco iluminado. Figura 6.6: Exemplos de imaxes descartadas con mala calidade. Finalmente, a Figura 6.7 contempla outros exemplos de capturas que foron descartadas. Sen embargo, neste caso os motivos do rexeitamento son cuestionables. A partir destas imaxes p´odense obter sen problema os trazos biom´etricos do usuario. En ning´un caso a calidade da imaxe se pode comparar ´a de calquera outra escollida como mostra, pero de seguro moitas destas capturas poder´ıan formar parte do banco de mostras. As raz´ons principais do rexeitamento soen ser o blur que presentan ou o pequena que sae a cara en relaci´on ao tama˜no do cadro debido ´a excesiva distancia entre o usuario e o dispositivo. Figura 6.7: Exemplos de imaxes descartadas que poder´ıan servir como mostras. En definitiva, durante esta beta comprobouse que cun adestramento esixente e conservador se pode obter practicamente unha mostra do usuario por cada d´uas imaxes tomadas, pero poder´ıase aplicar un adestramento menos restritivo para pasar a integrar no modelo imaxes como as da Figura 6.7. Os resultados obtidos co dispositivo de desenvolvemento, o Aquaris E5s, excl´uense das cifras anteriores por diversas raz´ons. En primeiro lugar, este m´obil empregouse para probas, onde moitas veces se forzaron situaci´ons de ´exito ou fracaso que condicionar´ıan os resultados. Por outra parte, o contexto das imaxes tomadas por 6.3. INFORME DE INCIDENCIAS 135 este dispositivo foi sempre o do entorno de traballo: o laboratorio EmprendeLab do CiTIUS. Pese a todo, podemos comentar os resultados obtidos co E5s para comparalos cos dos voluntarios da beta. En total realiz´aronse 548 capturas, das cales 403 pasaron a ser mostras v´alidas, co cal a taxa de acertos acadou un 73,54 %. Estes valores son moito mellores ´a media, pero hai que ter en conta a influenza dos factores anteriores. En calquera caso ´e de esperar que estas cifras sexan mellores, pois compre recordar que foi neste dispositivo onde se realizou o adestramento que logo se integrou na beta para ser empregado por defecto nos m´obiles dos voluntarios. Como era previsible, durante esta beta xurdiron problemas e manifest´aronse fallos na aplicaci´on. Estes aparecen documentados xunto a aqueles detectados coas probas aleatorias no informe de incidencias da seguinte secci´on [INC-5, INC-6]. Para a s´ua detecci´on e seguimento empregouse a Play Console. A Figura 6.8 amosa o panel de bloqueos en tempo real producidos nos ´ultimos 14 d´ıas para todas as versi´ons de Android e de FaceSampler. Figura 6.8: Seguemento de fallos desde a Play Console. Para cada fallo, a consola ofr´ecenos cantidade de detalles, como o n´umero de usuarios afectados, os datos dos dispositivos, s´ua traza de erro, etc. Na Figura 6.9 podemos ver un exemplo. 6.3. Informe de incidencias Pres´entanse a continuaci´on as incidencias reportadas durante a execuci´on das probas e a beta privada. A escala empregada para cuantificar a gravidade das mesmas ´e a seguinte: Baixa. Tr´atase dun fallo pouco com´un ou cun impacto baixo de cara ´a 136 CAP´ ITULO 6. EXECUCI ´ ON DE PROBAS E BETA PRIVADA FaceSampler  Publicada ENVIAR ACTUALIZACIÓN java.lang.ClassCastEx ception com.citius.fernando.faceSampler.controller.preferences.SettingsActivity.setUpNestedScreen OCULTAR Informes de esta semana 0 Informes totales 20 Usuarios afectados 2 Último informe 14 de jun. 9:44 Número de informes para este error entre el 20/5/2017 y el 25/6/2017. Por versión de la aplicación 16 30,0% 44 20,0% 24 20,0% 53 15,0% Otras 3 15,0% MOSTRAR LISTA COMPLETA Por versión de Android Android 7.1 16 80,0% Android 5.1 4 20,0% Por dispositivo Nexus 5X (bullhead) 16 80,0% Aquaris E5 (Aquaris_E5) 4 20,0% Seguimientos de pilas Marca de tiempo del informe 14 de jun. 9:44 Versión de la aplicación 5 Versión de Android Android 7.1 Dispositivo Nexus 5X (bullhead) Fabricante: Google RAM (MB): 2048 Tamaño de la pantalla: 1080 × 1920 Densidad de pantalla (ppp): 420 Plataforma nativa: armeabi-v7a Versión de OpenGL ES: 3.1 Marca de CPU: Qualcomm Modelo de CPU: MSM8992 java.lang.ClassCastException: at com.citius.fernando.faceSampler.controller.preferences.SettingsActivity.setUpNestedS creen(SettingsActivity.java:98) at com.citius.fernando.faceSampler.controller.preferences.SettingsActivity.onPreference TreeClick(SettingsActivity.java:87) at android.preference.Preference.performClick(Preference.java:1008) at android.preference.PreferenceScreen.onItemClick(PreferenceScreen.java:249) at android.widget.AdapterView.performItemClick(AdapterView.java:310) at android.widget.AbsListView.performItemClick(AbsListView.java:1164) at android.widget.AbsListView$PerformClick.run(AbsListView.java:3132) at android.widget.AbsListView$3.run(AbsListView.java:4047) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6121) at java.lang.reflect.Method.invoke(Native Method:0) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779) Página 1 de 20 © 2017 Google · Ayuda · Condiciones del sitio web · Privacidad · Acuerdo de distribución para desarrolladores Publicación estándar  28/5/201728/5/201728/5/2017 4/6/20174/6/20174/6/2017 11/6/201711/6/201711/6/2017 18/6/201718/6/201718/6/2017 1,51,51,5 3,03,03,0 4,54,54,5 6,06,06,0 Errores ANR y bloqueos Buscar aplicaciones Tus aplicaciones  Panel de control  Estadísticas  Android vitals  Descripción general Errores ANR y bloqueos Archivos de desofuscación Herramientas de desarrollo   Gestión de versiones  Panel de la versión Versiones de la aplicación Aplicaciones Instantáneas Android Biblioteca de artefactos Catálogo de dispositivos Firma de aplicaciones Informe previo al lanzamiento Presencia en Google Play Store   Adquisición de usuarios  Comentarios de los usuarios   Figura 6.9: Detalles dun fallo desde a Play Console. 6.3. INFORME DE INCIDENCIAS 137 explotaci´on da ferramenta, afectando a funcionalidades secundarias da aplicaci´on, polo que a s´ua correcci´on pode esperar. Media. A s´ua repercusi´on ´e m´ais elevada que no caso anterior, podendo afectar a funcionalidades importantes da aplicaci´on. Non se remata de comprender a orixe do fallo, polo que non hai garant´ıas de que non se repita de novo. Compre realizar un estudo en detalle do problema. Alta. Desco˜n´ecese por completo a orixe do problema ou s´abese que pode afectar a funcionalidades cr´ıticas en gran n´umero de dispositivos. D´ebese abordar o problema canto antes. Incidencias INC-1 Mala predici´on con SVM Reporta: Fernando Est´evez (desenvolvedor) Data de detecci´on: 10/05/2017 Gravidade: Baixa Descrici´on: Executando as probas estruturais relativas ´a verificaci´on da boa predici´on con SVM CP-9 detectouse que este era m´ais impreciso que k-NN por alg´un motivo. Acci´ons tomadas: En primeira instancia realizouse unha depuraci´on da clase Java asociada a este algoritmo. Tras non detectar nada, asumiuse estar empregando mal as funci´ons da librer´ıa OpenCV relativas a SVM e realizouse unha proposta de cambio que ser´a abordada nun futuro sprint. INC-2 Fallo dos casos de proba CP-16 eCP-17 Reporta: Fernando Est´evez (desenvolvedor) Data de detecci´on: 10/05/2017 Gravidade: Baixa Descrici´on: Executando as probas estruturais relativas ´a permutaci´on entre os modos de execuci´on, os casos de proba CP-16 e CP-17 fallaron. En ambos, o motivo do fallo foi a imposibilidade de simular o evento desexado (USER PRESENT no CP-16 eSCREEN OFF no CP-17) por trat´arense de eventos do sistema e non ter permisos para tal acci´on. Acci´ons tomadas: Asumiuse como suficiente a cobertura acadada coas probas funcionais. INC-3 Bloqueo en Android 4.4 Reporta: Fernando Est´evez (desenvolvedor) Data de detecci´on: 18/05/2017 138 CAP´ ITULO 6. EXECUCI ´ ON DE PROBAS E BETA PRIVADA INC-3 Bloqueo en Android 4.4 (cont.) Gravidade: Baixa Descrici´on: Fallou a execuci´on da proba aleatoria PA-1, que deb´ıa realizarse sobre un dispositivo con versi´on Android 4.4. (KitKat). Acci´ons tomadas: Ningunha. Prev´ıase o fallo, posto que alg´uns dos compo˜nentes da aplicaci´on, como o servizo de captura de imaxes ou algunhas das vistas non soportan versi´ons da API de Android inferiores ´a 21 (versi´on 5.0 do sistema operativo). Esta proba fora planificada para ver o comportamento do sistema en versi´ons inferiores ao m´ınimo recomendado (5.0). INC-4 Bloqueo durante o adestramento Reporta: Fernando Est´evez (desenvolvedor) Data de detecci´on: 18/05/2017 Gravidade: Media Descrici´on: Executando a proba aleatoria PA-9 recolleuse unha excepci´on do tipo java.lang.NullPointerException ao tratar de acceder ´a informaci´on do aceler´ometro. Acci´ons tomadas: Compre revisar o fallo en detalle. Realizouse unha proposta de cambio que ser´a abordada nun futuro sprint. INC-5 Bloqueo no panel de preferencias, categor´ıa Timings Reporta: Carlos V´azquez Regueiro (cliente) Data de detecci´on: 22/05/2017 Gravidade: Alta Descrici´on: Durante a beta privada, o dispositivo do usuario (Nexus 5X e versi´on de Android 7.1) bloqueouse ao tratar de acceder ´a categor´ıa Timings do panel de preferencias. Observando a traza do fallo desde a Play Console descubriuse que se trataba dun problema de casteo de clases (java.lang.ClassCastException). Acci´ons tomadas: Abordouse o problema de inmediato por tratarse dun cambio menor. Resolveuse sen maior dilaci´on. INC-6 Inversi´on vertical da c´amara frontal Reporta: Marco A. Ara´ujo Matarazzo (beta tester) Data de detecci´on: 09/06/2017 Gravidade: Baixa 6.3. INFORME DE INCIDENCIAS 139 INC-6 Inversi´on vertical da c´amara frontal (cont.) Descrici´on: Durante a beta privada, o usuario, con dispositivo Bq Aquaris X5 Plus e versi´on de Android 7.1, non logrou obter mostras do seu rostro, a´ında que a aplicaci´on tomou 40 capturas. Citouse ao individuo para debuggear o proceso de mostraxe, comprobando que o sensor da c´amara frontal do seu dispositivo inverte verticalmente as imaxes, co cal o detector de rostros non ´e capaz de atopar a s´ua cara. Acci´ons tomadas: Ningunha: asumiuse como un caso illado e pouco probable. A soluci´on proposta foi inclu´ır unha comprobaci´on da orientaci´on, de xeito que se busquen caras rotando a imaxe. Descartouse por ser pouco eficiente.