Datainnsamlingen

A validade externa de um estudo de caso se relaciona com fatores que limitam a generalização dos resultados alcançados por este. Desta maneira, quatro ameaças à validade externa foram detectadas. Essas ameaças abrangem as três etapas do estudo de caso, apresentado por esta pesquisa.

A primeira das ameaças à validade externa desse estudo de caso se relaciona à quantidade de projetos definidos para o mesmo. Definimos apenas dois projetos, a fim de avaliar a estratégia de elicitação proposta. Para obtermos resultados mais precisos e comparativos, seria ideal então, no futuro, a realização deste estudo de caso com uma quantidade maior de projetos.

A segunda ameaça à validade externa está relacionada ao tamanho e a complexidade dos projetos. Tendo em vista que os projetos definidos para esse estudo de caso foram baseados em escopos simples, contendo uma quantidade

pequena de requisitos. Para futuros testes o ideal é utilizar a abordagem proposta por esta pesquisa em projetos mais robustos, a fim de testar a eficácia da mesma.

A terceira ameaça à validade externa está relacionada à quantidade de situações elaboradas na etapa de elicitação desse estudo de caso. Essas situações foram criadas para definir a utilização dos recursos de elicitação disponibilizados por esta pesquisa (veja seção 6.2.1.2). Para essa etapa foram definidas apenas 3 situações, para cada situação havia uma definição específica sobre qual recurso de elicitação seria disponibilizados aos elicitadores. Essas três situações permitiu comparar os resultados alcançados, na execução das atividades de elicitação, através de três cenários distintos. Visando gerar e analisar resultados que possibilite novas comparações, se torna interessante definir novas situações, a fim de verificar a eficácia na utilização de cada recurso de elicitação disponibilizado.

Por fim, citamos a ameaça à validade externa que está relacionada à quantidade de participantes desse estudo de caso. A pequena quantidade de participantes que conseguimos selecionar, nos limita na questão de generalização dos resultados alcançados. Dessa forma, visando obter resultados mais expressivos, que nos permita, por exemplo, estimular a utilização em larga escala da estratégia de elicitação proposta, seria ideal no futuro, a realização deste estudo com um número maior de participantes.

6.6 Considerações finais sobre o Capítulo

Este capítulo apresentou o estudo de caso elaborado para avaliar o suporte que a estratégia apresentada nesta pesquisa oferece à atividade de elicitação dos requisitos de Acessibilidade Web. Inicialmente foi abordada toda a parte de planejamento desse estudo, a fim de mostrar os detalhes de sua estrutura que foi dividida em três etapas: I – Elicitação, II – Prototipação e III – Análise da acessibilidade.

Essas etapas foram elaboradas para responder três questões de pesquisas (veja tabela 13 na seção 6.1). Para cada uma dessas etapas foram definidos os artefatos a serem processados e produzidos, a seleção dos participantes e a preparação do ambiente. Após a descrição do planejamento de cada uma das etapas, foram

abordados detalhes sobre a execução destas. Através da execução das etapas, as questões de pesquisas foram respondidas.

Os dados extraídos na etapa de elicitação foram utilizados para responder a QP1 (primeira questão de pesquisa). Para isso, foram considerados os seguintes fatores: I - a corretude dos dados obtidos na elicitação dos requisitos de Acessibilidade Web, II - O tempo total despendido para execução da elicitação e - III A análise sobre a documentação gerada. Os dados extraídos na etapa de prototipação foram utilizados para responder a QP2. Para isso, foram considerados os fatores: I - Controle sobre a prototipação dos requisitos, II – A avaliação dos desenvolvedores em relação a documentação de requisitos recebida. Os dados extraídos da etapa de Análise da acessibilidade foram utilizados para responder a QP3. Para isso, foram considerados os resultados da análise manual e automatizada do grau de Acessibilidade Web nos protótipos.

Com a configuração do estudo de caso estabelecida em três etapas, foi possível analisar o impacto que a estratégia de elicitação, proposta por esta dissertação, causou em diferentes contextos. Na etapa de elicitação foi possível concluir que o método de elicitação e sua ferramenta de apoio oferecem um nível de suporte satisfatório aos elicitadores, promovendo a otimização do tempo gasto tanto para a extração das informações do catálogo de RNFs como para a geração de artefatos. Além disso, a estratégia de elicitação proposta fornece uma maior abrangência sobre as informações a serem extraídas do catálogo, graças à definição de parâmetros que auxiliam na identificação e seleção dos requisitos.

Na etapa de prototipação foi constatado que a documentação gerada, através da estratégia de elicitação aqui proposta, promove um maior controle sobre a prototipação dos requisitos de Acessibilidade Web. Mesmo diante de algumas limitações, como falta de disponibilidade e conhecimento defasado, por parte dos participantes, artefatos como o checklist ofereceram um suporte satisfatório, mostrando a viabilidade de utilizá-los durante a prototipação. De acordo com informações passadas pelos participantes, sem o checklist, que foi obtido a partir dos requisitos elicitados, a quantidade de requisitos de acessibilidade a serem considerados seria precária, pois a visão alternativa que ele oferece dos elementos

contidos no catálogo foi fundamental na compreensão dos requisitos, e sobre o que deve ser feito em relação a eles, com base nas operacionalizações. A produção bem abaixo do esperado, disponibilizada pelo participante 4 da etapa de prototipação, auxilia na confirmação de que a falta de artefatos representando visões alternativas dos RNFs pode ocasionar implementações problemáticas.

Na etapa de análise da acessibilidade, foi possível constatar que os projetos prototipados pelos participantes que receberam todos os artefatos do método proposto, apresentaram um desempenho melhor durante os testes manuais e automatizados. Os desempenhos dos protótipos gerados pelos participantes 2 e 3, da etapa 2 do estudo de caso, fundamentaram essa constatação. Inclusive, o protótipo gerado pelo participante 2 foi eleito o mais acessível pelos participantes da etapa 3. Em contra partida, o projeto prototipado pelo participante 1 não apresentou resultados satisfatórios, apesar desse participante ter recebido todas as documentações necessárias, assim como os participantes 2 e 3. O participante 1 apresentou justificativas que isentaram a estratégia de elicitação proposta, o mesmo informou limitações na disponibilidade de tempo e outros problemas, inclusive de saúde. O pior desempenho foi apresentado pelo protótipo do participante 4, lembrando que esse participante recebeu apenas o SIG do produto como artefato. Esse fato indica que a estratégia de elicitação adotada e sua consequente documentação podem influenciar de maneira profunda o produto final.

Por fim, este capítulo apresentou as ameaças à validade dos resultados obtidos no estudo de caso elaborado. Foram abordadas ameaças à validade interna como o “Nível de conhecimento dos participantes da etapa de elicitação”, o “Controle no tempo de disponibilidade dos participantes da etapa de prototipação” e o “Grau de limitações físicas apresentadas pelos participantes da terceira etapa”.

Em relação às ameaças à validade externa, ao todo foram identificadas 4 ameaças, todas abrangendo as três etapas do estudo de caso. Entre as ameaças externas destacamos o tamanho e a complexidade dos projetos, que se relaciona com a necessidade realizar o estudo de caso, apresentado neste documento, em projetos mais robustos. Essas ameaças levantadas, tanto as internas como as externas, devem ser controladas de maneira mais rígida, a fim de garantir o melhor andamento de um

estudo de caso. Aumentando assim, a chance de alcançar resultados mais expressivos e conclusivos.

7 Trabalhos relacionados

Na literatura foram encontrados trabalhos voltados tanto para alcançar a acessibilidade durante o processo de desenvolvimento, quanto para sites ou aplicações web já finalizados. Além de pesquisas envolvendo a acessibilidade, destacamos também estudos contendo estratégias para a elicitação de RNFs. A seguir, apresentamos os principais trabalhos relacionados à nossa pesquisa. Para facilitar a compreensão, distribuímos esses trabalhos em tópicos que levamos em consideração quando definimos nossa estratégia:

 Interdependência entre componentes técnicos e humanos: Na pesquisa de Chisholm e HENRY (2005) defende-se a idéia de que a acessibilidade na web depende da relação entre componentes técnicos e humanos. No passado a responsabilidade sobre acessibilidade era direcionada apenas para os produtores de conteúdo web, mas esta visão mudou, e a relação entre componentes humanos e técnicos tornou-se um aspecto importante para o desenvolvimento, eliminando assim a responsabilidade sobre um único elemento. Assim, para Chisholm e HENRY (2005) a inserção da acessibilidade no ciclo de desenvolvimento é extremamente necessária. Entretanto, os autores não esclarecem em qual estágio do desenvolvimento seria adequado considerar a acessibilidade, tornando-se uma das limitações desta pesquisa. Outra limitação é a falta de uma análise sobre a interação dos usuários com as funcionalidades do sistema, onde um levantamento sobre o público alvo e suas respectivas limitações, poderiam gerar funcionalidades mais adequadas ou agilizar o processo de elicitação dos requisitos de acessibilidade. Não há também uma preocupação clara sobre os possíveis conflitos existentes entre os requisitos de acessibilidade e outros RNFs.  Integração entre requisitos de Acessibilidade Web e RFs: Baguma et al (2009)

afirma que analisar acessibilidade na fase inicial do desenvolvimento é mais viável, pois facilita o andamento do projeto, evitando o retrabalho na fase de implementação, uma vez que a equipe de desenvolvimento não precisará perder tempo fazendo adaptações, podendo assim se preocupar com outras tarefas. A

pesquisa deixa explícito que esses requisitos devem ser integrados já nas fases de análise e especificação de requisito. O estudo mostra a integração dos requisitos de acessibilidade com requisitos funcionais, indicando os benefícios que os engenheiros de software podem extrair desta abordagem como, por exemplo, a detecção precoce de eventuais conflitos entre o projeto de interface com os princípios de acessibilidade. Essa ideia de existir um relacionamento entre os RFs e os requisitos de Acessibilidade Web influenciou a definição da primeira atividade do processo de elicitação proposto por esta dissertação. Porém, a pesquisa de Baguma et al (2009) não fornece uma estratégia clara para estabelecer esse relacionamento. Nossa pesquisa propõe uma análise em cada RF, a fim de compreender quais os tipos de conteúdos que aquele RF irá trabalhar. Dessa forma o relacionamento que passará a existir entre o RF e os requisitos de acessibilidade se torna mais explícito, facilitando controlar o que de acessibilidade aquele RF precisará. Outra limitação do trabalho é a não sistematização da elicitação, os autores utilizam algumas definições, porém não chegam a propor um processo sistematizado que possa guiar a elicitação dos requisitos de Acessibilidade Web.

 Transformação do conteúdo web: Uma ferramenta que garante uma transformação menos exaustiva de conteúdo web é proposta por HANSON e RICHARDS (2003), os autores fornecem exemplos sobre como a capacidade de transformação conhecida como “on the fly” (transformação instantânea ou em tempo real) pode ser dinâmica. Esse trabalho defende que a acessibilidade pode ser alcançada com baixo custo para o desenvolvimento e abranger uma quantidade maior de usuários. Essa estratégia para a transformação de conteúdo visa a acessibilidade web, em produtos já implementados ou finalizados, enquanto a pesquisa aqui proposta visa uma estratégia que considere o tratamento para os requisitos de Acessibilidade Web já nas atividade de elicitação e análise de requisitos.

 Acessibilidade através de auxilio colaborativo: Um framework de avaliação em camadas é definido no trabalho de Boldyreff (2002), onde uma melhor compreensão sobre a acessibilidade é o fator chave para alcançá-la. Buscando

atender a esse propósito, o autor criou um modelo abstrato e específico para esse domínio. Essa pesquisa abrange conceitos sobre o trabalho de auxílio colaborativo através da computação, com o intuito de refinar e estender as questões técnicas, além disso, destaca a necessidade de se considerar a acessibilidade sob o ponto de vista dos desenvolvedores e mantenedores (bem como, também, o usuário da web). O framework se apresenta como um diagrama em camadas mostrando a interdependência de componentes, fazendo uma analogia entre os sistemas web e sistemas CSCW (Computer Supported Cooperative Work). Os critérios de avaliação das camadas são dependentes uns dos outros em relação a sua eficácia. As camadas de avaliação contidas nesse framework são: confiança, eficiência, funcionalidade, usabilidade, eficácia, manutenibilidade e padrões. Os autores dessa pesquisa definem um framework para compreensão da Acessibilidade Web, porém não define procedimentos ou estratégias para elicitar e analisar as alternativas a serem consideradas de acordo com esse domínio. Nossa pesquisa, além de definir um processo e uma ferramenta de apoio, indica a utilização de um catálogo que possa servir como base de conhecimento comum sobre o domínio da Acessibilidade Web.

 Framework para elicitação dos requisitos de Acessibilidade Web: Na pesquisa de Masuwa (2008) é apresentado um framework, chamado AccessOnto, visando o apoio à especificação de requisitos de acessibilidade. O framework fornece um repositório de diretrizes de acessibilidade e mais uma linguagem de especificação para ajudar os desenvolvedores de software a incluírem os requisitos de acessibilidade no documento de requisitos. O AccessOnto mescla as diretrizes de acessibilidade com a engenharia de requisitos, fornecendo uma plataforma para a localização dos requisitos através do repositório contido no framework. Entretanto, uma limitação do Framework AccessOnto, se refere ao fato de não oferecer suporte para análise dos requisitos funcionais do sistema, a fim de compreender o que de acessibilidade está relacionada com cada funcionalidade elicitada. Apesar de promover a facilidade na localização dos requisitos de Acessibilidade Web, a pesquisa de Masuwa (2008) não oferece estratégias claras para conduzir o processo de análise e especificação dos requisitos. E por fim, o framework

AccessOnto não oferece uma estrutura para que o engenheiro de requisitos possa efetuar análises de conflitos entre os RNFs e refinamento dos requisitos de Acessibilidade Web.Acessibilidade através da Engenharia Web: O trabalho apresentado por Dias et al. (2012) ) aborda uma extensão do framework criado para Engenharia Web de Pressman e Lowe (2008). O Foco dessa pesquisa é a inserção dos requisitos de acessibilidade durante o processo de desenvolvimento de software. O framework estendido aborda especificamente o processo de elicitação dos requisitos presente na fase de comunicação da Engenharia Web. A idéia dos autores é a elicitação dos requisitos considerando as características dos usuários. Nesse contexto, os requisitos são elicitados levando em consideração apenas o perfil dos utilizadores em relação a suas limitações. O trabalho de Dias et al (2012) influenciou a definição do processo para elicitação dos requisitos de acessibilidade proposto nesta dissertação, a idéia dos autores de considerar as limitações do usuário para elicitação foi incorporada, pois influencia diretamente na escolha do tipo de conteúdo a ser disponibilizado pelas funcionalidades do sistema (vídeos, imagens, textos, etc.). Ao analisar esse trabalho, ficou evidente que a forma de elicitar os requisitos de acessibilidade é limitada, uma vez que a lista de requisitos criada contém descrições genéricas, englobando de forma reduzida as diretrizes da W3C. Não há na pesquisa nenhuma indicativa de análise ou refinamento dos requisitos de acessibilidade elicitados. Dessa forma, não se define estratégias para operacionalizar a acessibilidade.

 Uso de catálogo de RNFs para reutilização de modelos: A pesquisa de Serrano, M. M. (2013) aborda a elicitação de requisitos para os domínios da computação invisível, invasiva e móvel. Visando oferecer um corpo adequado para a reutilizável de conhecimento, os autores disponibilizam um catálogo de RNFs baseado na abordagem NFR Framework e para sua utilização foi elaborado um método e uma ferramenta. O método proposto é composto por 5 atividades, sendo estas: Exploração, Coleta, Modelo, Operacionalização e Validação. A atividade de Exploração é composta pelas sub-atividades de Consulta e Extração, e auxilia os desenvolvedores na exploração e extração de conhecimento do catálogo. A atividade de Coleta é composta pelas sub-atividades Recolhimento e

Instanciação, nessa etapa ocorre a escolha dos requisitos, onde os elicitadores podem pegar os requisitos tal como estão especificados no catálogo ou adaptá-los para a aplicação em desenvolvimento. Na atividade Modelo os elicitadores devem trabalhar na decomposição ou determinação das interdependências, essa atividade só é necessária caso o elicitador tiver efetuado adaptações ou evoluções em algum requisito na atividade de Coleta. A atividade de Operacionalização auxilia o elicitador disponibilizando estratégias pré-definidas que podem ser utilizadas durante a fase de implementação. A atividade de Validação é composta pelas sub-atividades Avaliar e Resolver conflitos, de acordo com a avaliação do elicitador os requisitos e seus descendentes podem ou não ser aceitos. Em caso de algum conflito entre os requisitos, o elicitador deve buscar soluções ou negar a aceitação do requisito conflitante. Em relação a ferramenta desenvolvida para utilização do catálogo há poucas informações, baseando-se unicamente na descrição dos autores foi possível identificar que ela ajuda na apresentação e navegação do conteúdo do catálogo através de uma árvore de exploração. Pela descrição das atividades foi possível identificar também que não existe automatização para nenhum dos procedimentos existentes no método de uso do catálogo, e que realmente a ferramenta desenvolvida trata basicamente questões especificas, tais como: exploração, visualização, seleção manual dos RNFs e suas interdependências. Em Serrano, M. M. (2013) apesar dos autores informarem que o acesso ao catálogo e a ferramenta está aberto ao público para análises e contribuições, não foi possível acessar nenhum dos dois para maiores verificações. Mas analisando esse trabalho foi possível perceber alguns pontos em comum com a nossa pesquisa, tais como: o uso de abordagens orientadas a meta, a intenção de melhorar a utilização do catálogo de RNFs proposto através de atividades agrupadas em um método, e por fim o desenvolvimento de uma ferramenta. As limitações detectadas na pesquisa, que na verdade também revelam algumas das principais diferenças para a nossa pesquisa, inicialmente referem-se à composição do método proposto pelos autores, onde basicamente existem procedimentos comuns ou nativos da própria abordagem NFR Framework. No método de elicitação apresentado por nossa pesquisa há uma

estrutura voltada para considerar os RFs e o perfil do público alvo para controlar a elicitação dos requisitos. Esses controles se encontram presentes na primeira atividade de Análise sobre os requisitos funcionais. Em relação às atividades comuns ao NFR Framework, houve um encapsulamento dessas atividades em apenas duas atividades do nosso processo, sendo estas: Seleção dos requisitos para acessibilidade e Análise para operacionalização dos requisitos de acessibilidade. E por fim, o fator automatização está presente em boa parte do nosso processo, primeiro na etapa de Seleção dos requisitos para acessibilidade, e segundo na quarta e última atividade de Geração de Artefatos, onde são gerados automaticamente um XML contendo os requisitos elicitados, um Checklist para controle de implementação e um catálogo de correlações. O processo de Serrano, M. M. (2013) é basicamente manual.

 Adaptação em projetos web: Casteleyn et al. (2006) aborda a necessidade de fazer adaptações nos projetos de aplicações web, visando atender interesses como: privacidade, acessibilidade entre outros requisitos não funcionais. Para exemplificar como seria a execução do projeto utilizam a abordagem HERA (Vdovjak et al., 2003), a ideia é mostrar como estender aplicações de sistemas já existentes, cuja necessidade de alteração é complexa e necessária, a técnica é baseada na implementação de componentes genéricos (GAC). Para tratar a natureza crosscuting dos requisitos os autores utilizam orientação a aspecto.  Eficácia no uso de catálogos de RNFs: A pesquisa de Cysneiros (2007) aborda

um estudo empírico para comprovar a eficácia da utilização dos catálogos para elicitação de RNFs. O Framework i* foi escolhido para construção do catálogo de RNFs utilizado no experimento, para auxiliar na utilização do catálogo o autor elaborou uma abordagem sistemática de exploração. Essa abordagem compreende 4 etapas, sendo estas: I Construção do modelo funcional, II Investigação dos RNFs necessários, III Cópia das alternativas para o modelo i* e IV Avaliação das alternativas. A primeira atividade compreende a identificação dos requisitos funcionais da aplicação. A segunda etapa compreende a elicitação do RNFs e suas operacionalizações. A terceira atividade compreende integrar os RNFs e as operacionalizações selecionadas com o modelo funcional. E por fim a

quarta atividade compreende a análise de conflitos presentes entre os RNFs elicitados. O experimento consistia em verificar a eficácia dos participantes para encontrar e criar novas operacionalizações.

A ausência de uma análise sobre a Acessibilidade Web, em relação ao levantamento e refinamento dos requisitos, citada como limitação nos trabalhos de Masuwa (2008) e Dias et al (2012), foi abordada em nossa pesquisa através da