D IFFUSION IONIQUE DANS UN BETON CEM V

Conforme destacado na Seção 1.2, três hipóteses foram levantadas neste trabalho. Cada uma delas é analisada individualmente a seguir.

Hipótese 1:

Processos para desenvolvimento de software convencionais atendem as necessidades para a criação de soluções de TA.

Apesar dos trabalhos recuperados pelo MSL não revelarem, explicitamente, a utili- zação das técnicas de desenvolvimento adotadas na concepção das soluções propos- tas, diversos indícios presentes nos trabalhos apontam para a aplicação de técnicas convencionais, e com algum nível de adaptação no processo. Isso pode ser percebido inicialmente em termos relacionados a projeto e modelagem das soluções desenvol- vidas. As formas de representação utilizadas em diversas das soluções corroboram a isto. A utilização de diagramas semelhantes aos defendidos pelo modelo C4, apre- sentados na Seção 2.1.1, evidenciam esta utilização no nível de projeto.

Na outra ponta do processo, encontra-se a aplicação de métodos de avaliação so- bre as soluções desenvolvidas. As TA são submetidas a testes funcionais para validar se a aplicação executa os requisitos básicos estabelecidos. Neste ponto, pode-se con- siderar os impactos alcançados quando os usuários finais (ou profissionais de saúde) estão envolvidos no processo. Os resultados destas avaliações são mais ricos quando estes aspectos humanos são contemplados neste processo. Por outro lado, o fato dos trabalhos acadêmicos (listados na Tabela 6 da subseção 3.3.2) usualmente gerarem protótipos, desencorajam a incorporação dos usuários finais no processo construtivo, pois não garantem o suporte adequado após a criação das soluções assistivas. Neste contexto, os aspectos psicológicos e emocionais dos usuários devem ser considera- dos, de modo a não gerar expectativa, e consequentemente frustrações aos usuários. De qualquer forma, a inclusão de usuários ao longo do processo construtivo também é defendida em processos de desenvolvimento convencionais, em especial, os ágeis.

Assim, apesar de não ser explicitamente apresentado nos trabalhos, a adoção de metodologias e técnicas de desenvolvimento de software entre o projeto e a avaliação das aplicações de TA é factível. Neste cenário, a utilização de prototipação, examinada na Seção 2.1.2, foi uma técnica recorrente nos trabalhos recuperados pelo MSL. Em termos práticos, a prototipação se mostrou especialmente eficaz no levantamento de requisitos de um domínio de aplicação.

Diante do exposto, esta hipótese se mostrou verdadeira, ou seja, os processos de desenvolvimento de software convencionais são aplicáveis à construção de TA. No en- tanto, vale ressaltar que tais processos podem ser adaptados para incluir alguma fase específica de projeto e avaliação. Estas etapas adicionais dizem respeito a especifi- cação ou prescrição de elementos relacionados à limitação que está sendo avaliada. Preferencialmente elas devem envolver os usuários finais ou profissionais de saúde habilitados, com o intuito de perceber as formas mais adequadas para potencializar as habilidades preservadas dos indivíduos beneficiados pela solução de TA.

Hipótese 2:

A concepção de soluções assistivas reutilizáveis é simplificada com a identificação de elementos recorrentes em aplicações dentro de domínio específico, mesmo em

diferentes contextos de utilização.

Esta hipótese se mostrou verdadeira, uma vez que elementos essenciais aparece- ram recorrentemente, em diferentes cenários de uso. Os trabalhos recuperados pelo MSL no Capítulo 3, relacionados ao AsTeRICS, são exemplos nos quais isso ocorre na prática (OSSMANN et al., 2012, 2014; VEIGL et al., 2013). Uma série de apli- cações é abordada por estes trabalhos, explorando a estrutura reutilizável proposta para desenvolver soluções particularmente dentro de um âmbito assistivo, mas dentro de contextos de utilização variados. Outro trabalho encontrado na literatura que am- plia esta percepção é o GNomon (ACED LOPEZ; CORNO; DE RUSSIS, 2015). Este trabalho destaca o desenvolvimento dos jogos Ladybugs e Invaders, os quais são con- cebidos a partir de um framework aplicável ao domínio específico de jogos assistivos, utilizando o modo de interação NOMON (MIESENBERGER et al., 2014).

De forma complementar, o emprego desta técnica de desenvolvimento se mos- trou bastante eficaz na elicitação de requisitos, visando a proposição de arcabouço de domínio específico. Conforme salientado no Capítulo 4, os ciclos de desenvol- vimento sobre o SCCIOM (XAVIER et al., 2016), Doce Labirinto (CARDOSO et al., 2016), IOM4Home (PEROBA et al., 2017) e IOM4TV (CARDOSO et al., 2018) per- mitiram a detecção de funcionalidades e propriedades que foram aplicadas no arca- bouço, destacado no Capitulo 5. Assim, estes ciclos de desenvolvimento executados em cenários de utilização particulares se mostraram relevantes e eficazes tanto para

identificar as necessidades comuns compartilhadas, quanto para constatar aspectos inerentes apenas à conjectura peculiar de cada experimento.

Hipótese 3:

Obstáculos tecnológicos de desenvolvimento impactam diretamente no suporte aos diferentes perfis de usuários finais.

Assim como as hipóteses anteriores, esta suposição também foi confirmada. Dado que as soluções de TA se diferem das convencionais pelo fato de, em um dado mo- mento, precisarem ser adaptadas em algum nível, considerando especificidades do usuários. Isso é necessário pelo fato das habilidades funcionais preservadas geral- mente serem aptidões individuais das pessoas que irão usufruir da TA. Assim, as soluções criadas investem na potencialização das capacidades únicas conservadas pelas pessoas beneficiadas por uma TA específica, conforme pôde ser percebido nos trabalhos discutidos na Seção 3.2.

Desta forma, as aplicações e os dispositivos desenvolvidos acabam sendo orien- tados pelo tipo de deficiência física ou cognitiva que se busca atenuar. No entanto, a criação de soluções genéricas de software acaba sendo valiosa, já que provém um conjunto básico de funcionalidades que simplificam o processo de desenvolvimento inicial. Esta característica pode ser observada, por exemplo, nos arcabouços de soft- ware analisados no MSL, e listados na Tabela 4 da Seção 3.3.1. Estas soluções, por sua vez, devem ser adaptáveis e flexíveis de forma que, posteriormente, possam ser especializadas buscando abordar as necessidades individuais dos usuários.

Em termos práticos, isso pôde ser observado durante as avaliações sobre as apli- cações que utilizavam o IOM como objeto de estudo (vide Capítulo 4), em especial nos testes efetuados sobre o Doce Labirinto e o IOM4TV. No caso do primeiro, o público in- fantil apresentou mais destreza e facilidade de utilização do jogo, quando comparado ao público adulto ou sênior. Este fator pode estar relacionado ao fato das crianças possuírem menos experiências vividas, o que faz o processo de aprendizado sobre o funcionamento da solução ser simplificado. Já no IOM4TV, foi percebido que os obs- táculos tecnológicos tendem a ser superados à medida que os usuários utilizam as soluções assistivas repetitivamente.