Proposta de Método Afinada

A proposta de método com as alterações efetuadas pode ser vista de seguida. Para além da versão completa, existe também uma versão simplificada da proposta de método afinada que pode ser consultada no Anexo D. Esta versão simplificada é orientada ao desenvolvimento com Xamarim, com auxílio de print-screens.

4.2.1.1. Especificação

Existem quatro subactividades principais nesta fase:

1. Estudo de exequibilidade – de acordo com os dados de negócio, orçamentos, hardware e software disponível, esta é a altura em que tenta perceber-se se o projeto é fazível;

2. Evocação de requisitos e análise – derivar os requisitos de sistema através de entrevistas com os potenciais utilizadores finais, bem como a observação de sistemas já existentes. Pode envolver o desenvolvimento de alguns protótipos;

102

3. Especificação de requisitos – processar a informação recolhida na etapa anterior e traduzi-la para os vários tipos de requisitos – e.g. funcionais, não funcionais, de sistema;

4. Validação de requisitos – são examinados os requisitos de forma a perceber se se coadunam com a realidade, a sua consistência e acuidade com o seu desígnio.

Aquando da especificação de requisitos, subactividade 3, é recomendável que fique explícito que a interface com o utilizador tem que ser acessível, em conformidade com o tipo de projeto – e.g. acessibilidade em conformidade com o sistema operativo a que se destina; acessibilidade em conformidade com as WCAG 2.0 em caso de interface Web, criação de recursos de acessibilidade em caso de desenvolvimento de um sistema operativo, ou de uma Graphical User Interface (GUI) para um sistema operativo já existente – e, detalhando, que dificuldades funcionais se pretende mitigar – e.g. cegueira, baixa visão, problemas de motricidade, dificuldades de compreensão.

Aquando da validação de requisitos, subactividade 4, deve ser procurada e selecionada a documentação referente à acessibilidade, de acordo com o tipo de projeto, que será seguida durante a implementação do software e das dificuldades que tentam mitigar.

4.2.1.2. Desenho e Implementação

Nesta fase existem duas subactividades principais:

• Definição da plataforma onde o sistema vai ser executado – é necessário decidir a melhor forma de fazer a integração nesse ambiente;

• Desenho e implementação do software – é nesta fase que as especificações são implementadas e programado o software – e.g. modelos de dados, interfaces entre componentes.

Aquando do desenho do software a acessibilidade deve ser tida em conta, de acordo com o tipo de projeto:

103

• Em caso de desenvolvimento Web, a Graphical User Interface (GUI) deve ser pensada e desenhada de acordo com as recomendações referentes à acessibilidade plasmadas na documentação – e.g. WCAG. A implementação da UI previamente desenhada deve reger-se pelas mesmas normas utilizadas aquando do seu planeamento;

• Em caso de desenvolvimento de sistemas operativos, ou GUI para um sistema operativo já existente, e apesar da abordagem poder variar consoante os requisitos do software, dificilmente as interfaces com o utilizador não serão visadas. Assim, as interações referentes à acessibilidade devem ser pensadas e representadas para que, aquando da sua implementação, estejam sujeitas ao mesmo rigor aplicado a qualquer outra parcela do sistema;

• Em caso de desenvolvimento de software para executar em um sistema operativo já existente, as ações variam de acordo com a interface com o utilizador a ser implementada – i.e. componentes gráficos do sistema operativo previamente existentes; desenvolvimento de componentes gráficos exclusivos, desenvolvidos de raiz. No primeiro caso, devem ser seguidas as HIG do sistema e configurados os parâmetros de acessibilidade preexistentes nos componentes gráficos – estes componentes gráficos, tipicamente, já implementam a API de acessibilidade do sistema hospedeiro. No segundo caso, os componentes gráficos devem ser desenvolvidos incorporando as características de acessibilidade, via API de acessibilidade do sistema, respeitando o padrão de acessibilidade do sistema e, tanto quanto possível, mesmo considerando as idiossincrasias do projeto que levaram a que não fossem utilizados componentes gráficos preexistentes, as HIG do sistema operativo hospedeiro devem ser seguidas. Por fim, devem ser configurados os parâmetros referentes à acessibilidade, previamente implementados via API de acessibilidade do sistema.

4.2.1.3. Validação

Nesta atividade são realizados testes automáticos e que simulam o ambiente real a fim de verificar problemas no sistema e se as especificações estão a ser atingidas.

104

Quando esta fase se aproxima do fim, é realizado o teste de aceitação, ou teste alfa, onde o sistema é dado a um utilizador/cliente e, juntamente com a equipa de desenvolvimento, continua o teste até se concordar que a versão atual está em conformidade com os requisitos. De seguida, são realizados os testes beta, onde o sistema é entregue a um número maior de utilizadores/clientes finais. Os testers usam o sistema e, supostamente, descobrem problemas que são reportados à equipa de desenvolvimento que procede às correções e alterações necessárias.

Em caso de desenvolvimento Web, devem ser feitos testes automáticos com as ferramentas de avaliação de acessibilidade. Devem ser desenvolvidos guiões de teste ajustados às deficiências que se pretendem mitigar, onde são declaradas explicitamente as funcionalidades a testar, bem como o resultado esperado.

O cuidado durante o desenvolvimento dos guiões assume uma importância vital na qualidade dos resultados dos testes, uma vez que uma pessoa deficiente pode não se aperceber que algo correu mal caso desconheça o resultado esperado.

Na fase alfa é importante ter testers com deficiência, de forma a estarem representadas todas as deficiências que a acessibilidade implementada pretende mitigar, testers esses que devem executar os testes de acordo com um guião, bem como efetuar uma exploração livre.

Na fase beta, é importante que seja aumentado o número de testers com deficiência, em conformidade com base existente nos testes alfa.

Em caso de desenvolvimento de sistemas operativos, ou Graphical User Interface (GUI) para um sistema operativo já existente, os procedimentos não variam muito do caso anterior, com a ressalva de que não será possível utilizar as ferramentas de avaliação automáticas, a menos que sejam desenvolvidas para a situação em particular.

Em caso de desenvolvimento de software para executar em um sistema operativo já existente, os procedimentos são idênticos ao primeiro caso, com a ressalva de que as ferramentas de avaliação de acessibilidade são as específicas do sistema operativo hospedeiro.

105

4.2.1.4. Evolução

Nesta atividade a manutenção e evolução do sistema é feita de acordo com as alterações das regras de negócio ou a pedido do utilizador/cliente.

Nesta fase, para qualquer tipo de projeto, as alterações efetuadas têm que ter em conta a acessibilidade implementada nas fases anteriores. Qualquer alteração efetuada ao software deve comportar as características de acessibilidade existentes e, a par de qualquer outra alteração, deve ficar registada na documentação do projeto.