Thaísa Cardoso Lacerda

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA Thaísa Cardoso Lacerda thaisa_lacerda@hotmail.com Design de Interface de Ferramentas de GP: Melhorando a Usabilidade do dotproject Volume único FLORIANÓPOLIS 2014/2

2 2 Thaísa Cardoso Lacerda Design de Interface de Ferramentas de GP: Melhorando a Usabilidade do dotproject Trabalho de Conclusão de Curso apresentado ao Departamento de Informática e Estatística da Universidade Federal de Santa Catarina para a obtenção do Grau de Bacharel em Ciências da Computação. Orientadora: Prof.Dr.rer.nat. Christiane Gresse von Wangenheim, PMP Florianópolis, 30 de outubro de 2014 Profª. Dr. rer. nat. Christiane Gresse von WangenheimPMP Professora Orientadora Profª. Conceição Garcia Martins Membro da Banca Examinadora M.s. Rafael Queiroz Gonçalves Membro da Banca Examinadora

3 3 AGRADECIMENTOS À Deus, pela vida, pela família que Ele me concedeu e pelo privilégio de poder estudar. Aos meus pais, que além de me concederem tanto amor e carinho, me deixam os legados mais importantes que um filho pode receber, a educação na fé cristã e o incentivo à buscar o conhecimento. À professora Christiane pelas orientações, dicas, sugestões e paciência para revisar o relatório inúmeras vezes. Ao Rafael, pela disposição em implementar os protótipos em tempo hábil para a realização dos testes e a presteza com a qual sanou minhas dúvidas. Aos gerentes de projeto e experts do assunto que cederam seu tempo para colaborar com a realização dos testes de usabilidade.

4 4 RESUMO A boa prática de Gerencia de Projetos (GP) pode ser um importante fator contribuinte à vantagem competitiva das empresas de software. Para implanta-la com sucesso é fundamental o uso de tecnologia como suporte. Atualmente existe uma grande variedade de ferramentas para GP, entre elas o dotproject, uma alternativa de código livre. Porém, apesar de ser considerada uma das ferramentas de GP mais completas em termos de funcionalidades, o dotproject possui uma usabilidade muito pobre. Considerando a importância da usabilidade como fator que determina a adoção de um sistema de software surge a necessidade de melhorar o design de interface do dotproject melhorando a sua eficácia, eficiência e satisfação do usuário. Para isso é adotada uma metodologia com múltiplos métodos que inclui a análise da fundamentação teórica e do estado da arte de usabilidade do dotproject e outras ferramentas de suporte a GP e um estudo de caso melhorando a usabilidade do dotproject seguindo um processo de engenharia de usabilidade. Resultados da comparação da usabilidade da ferramenta original e do design de interface melhorado fornecem uma primeira indicação de melhoria na eficácia, eficiência e satisfação do usuário em relação à ferramenta. Palavras Chave: Usabilidade. Ferramenta de Gerência de Projetos. Ciclo de Vida de Engenharia de Usabilidade. Diretrizes de Usabilidade. dotproject

5 5 LISTA DE FIGURAS Figura 1: Planejamento do Experimento. Adaptado de WOHLIN et al. (2000) Figura 2:Estrutura de usabilidade Fonte: ISO Figura 3: Ciclo de Vida de Engenharia de Usabilidade Fonte: MAYHEW, Figura 4: Grupos de Processos do Ciclo de Vida de Engenharia de Usabilidade. Fonte: PMI, Figura 5: Competência Gerais de um Gerente de Projetos. Fonte: PMI (2004) Figura 6: Tela inicial dotproject Figura 7: Arquitetura do DotProject Figura 8: Fase Análise de requisitos Figura 9: Tela inicial do survey no Limesurvey Figura 10: Atividades mais realizadas pelos gerentes de projeto Figura 11: Definir as atividades. Fonte: PMI, Figura 12 Sequenciar as atividades. Fonte: PMI, Figura 13 Estimar Recursos. Fonte: PMI, Figura 14 Estimar Duração. Fonte: PMI, Figura 15: Desenvolver cronograma. Fonte: PMI, Figura 16: Controlar o cronograma. Fonte: PMI, Figura 17: Fasse de Instalação Figura 18: Etapas do processo de avaliação (WOHLIN, 2000) Figura 19: Imagens capturadas ao longo dos testes de usabilidade Figura 20: Fase Projeto/Teste/Implementação Figura 21: Hierarquia da atividade Decompor Atividades Figura 22:Hierarquia da atividade"sequenciar Atividades" Figura 23: Hierarquia da atividade "Estimar Tempo das Atividades Figura 24: Hierarquia da atividade"alocar RH" Figura 25: Hierarquia da atividade "Monitorar Cronograma" Figura 26: Diagrama de Navegação Figura 27: Protótipo de baixa fidelidade feito em papel Figura 28: Photoshop Figura 29: Pencil Figura 30: Tela 1 Inicial / Empresa... Erro! Indicador não definido. Figura 31: Tela 2 - Projeto Planejamento Figura 32: Tela 3 Menu da EAP... 78

6 6 Figura 33: Tela 4 - Menu da Atividade Figura 34: Tela 5 - Editar EAP Figura 35: Tela 6 - Editar Aividade Figura 36: Tela 7 - Editar Projeto Figura 37: Tela 8 Tela Inicial sem Empresa Figura 38: Tela 9 - Projeto sem EAP Figura 39: Tela 10 - Projeto - EAP sem Atividade Figura 40: Tela 11 - Monitoramento do Cronograma Figura 41: Tela 12 - Menu Figura 42: Tela 13 - Execução Figura 43: Tela 13.1 Editar Execução Figura 44: Mensagem Figura 45: Mensagem Figura 46: Mensagem Figura 47: Mensagem Figura 48: Mensagem Figura 49: Mensagem Figura 50: Mensagem Figura 51: Mensagem Figura 52: Screenshot da tela de Planejamento Figura 53: Screenshot da tela de edição de uma atividade Figura 54: Screenshot da tela Cronograma... 93

7 7 LISTA DE TABELAS Tabela 1: Processos por área de conhecimento Tabela 2: Módulos Core do DotProject Tabela 3: Módulos Addon do DotProject Tabela 4 Análise e Extração de Dados Tabela 5. Características da interface do Svet Tabela 6: Características dos Usuários Tabela 7: Identificação do grau de suporte oferecido pela ferramenta de software de GP Tabela 8 Características do processo de Definir as Atividades Tabela 9 Características da Atividade Estimar Duração Tabela 10: Características da ativade Monitoramento do Cronograma Tabela 11: Caso de uso 1: Decompor atividade Tabela 12: Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma Tabela 13: Caso de uso 3: Estimar Duração Tabela 14: Caso de uso 4: Controlar o Cronograma Tabela 15: Caso de uso 5: Visualizar Gantt Tabela 16: Caso de uso 6: Alocar Recursos Humanos Tabela 17: Caso de uso 7: Acompanhar Excecução de Atividade Tabela 18: Escala de Severidade (Nielsen, 1995) Tabela 19: Problemas de usabilidade encontrados via avaliação heurística Tabela 20: Descrição dos problemas de usabilidade mais severos Tabela 21: Perfil dos participantes dos testes de usabilidade Tabela 22: Completude das tarefas Tabela 23: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade Tabela 24: Resultado dos testes de usabilidade Tabela 25:Descrição do Conteúdo das Telas Tabela 26: Problemas de usabilidade / Sugestão de melhoria Tabela 27: Perfil dos participantes do teste de usabilidade Tabela 28: Completude das tarefas na versão proposta Tabela 29: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade Tabela 30: Resultado dos testes de usabilidade

8 SUMÁRIO 1 INTRODUÇÃO Contextualização Problema Objetivo Delimitações Justificativa Estrutura do Trabalho MÉTODO DE PESQUISA FUNDAMENTAÇÃO TEÓRICA Usabilidade Engenharia de Usabilidade Gerenciamento de Projetos Gerente de Projeto Ferramentas de Gerenciamento de Projetos ANÁLISE DO ESTADO DA ARTE Definição da Análise Execução da Busca Extração e Análise dos Dados Discussão MELHORIA DA USABILIDADE DO DOTPROJECT Análise de Requisitos Análise dos dados coletados Requisitos de Usabilidade Avaliação da Usabilidade do dotproject+ (versão 2.1.7) Definição da Avaliação Avaliação heurística Teste de Usabilidade do dotproject+ versão Aplicação do KLM na versão Desenvolvimento das Melhorias Modelo Conceitual Análise Hierárquica das Tarefas HTA e Diagrama de Navegação Protótipos de Baixa Fidelidade Implementação das Melhorias AVALIAÇÃO DA MELHORIA DA USABILIDADE Definição da avaliação Execução da Avaliação Teste de Usabilidade da versão 1.3 do dotproject Aplicação do KLM na versão Comparação da usabilidade dos designs de interface DISCUSSÃO DA COMPARAÇÃO DA USABILIDADE DOS DESIGNS DE INTERFACE DISCUSSÃO Ameaças à Validade CONSIDERAÇÕES FINAIS REFERÊNCIAS APÊNDICE A APÊNDICE B APÊNDICE C APÊNDICE D FERRAMENTAS DE APOIO PARA A REALIZAÇÃO DOS TESTES DE USABILIDADE

9 9 1 INTRODUÇÃO Neste capítulo são apresentados a contextualização, o problema, os objetivos, a metodologia e a justificativa do presente trabalho. 1.1 Contextualização O gerenciamento de projetos (GP) permite que empresas possam, entre outras atividades, prever os custos do projeto, adaptar seus trabalhos ao mercado consumidor e aos clientes, agilizar decisões, aumentar o controle gerencial e otimizar a alocação de pessoas, equipamentos e materiais necessários (VARGAS, 2005). Logo, a boa prática de GP pode ser um importante fator contribuinte à vantagem competitiva das empresas (JUGDEV, 2011). Entre os benefícios da boa prática da GP estão a redução de custo e prazo de desenvolvimento de novos produtos, aumento no tempo de vida dos novos produtos, das vendas e receitas, do número de clientes e de sua satisfação, bem como da chance de sucesso dos projetos (GUEDES, 2003). Dentro desse contexto compreende-se que o gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades de um projeto com a finalidade de alcançar os seus requisitos (PMI, 2013). Ele envolve desde as etapas de iniciação do projeto, o seu planejamento, execução, monitoramento e encerramento, bem como controla o escopo, tempo, custo e qualidade. Um significante critério de sucesso no gerenciamento de projetos na prática atualmente é o uso de tecnologia para auxiliar (GUEDES, 2003) (JESSEN, 2000). Tais ferramentas permitem a visualização do projeto de forma integrada, contemplando atividades, prazos, alocação de recursos, custos etc., além de tornar possível, acompanhar o status do projeto, sinalizando o atraso de tarefas, visualizar uma possível super ou sub-alocação de recursos humanos e identificar riscos afim de minimizá-los (GUEDES, 2003). Existe atualmente uma grande variedade de ferramentas para GP, que podem ser proprietárias (MS Project (MICROSOFT,2014.)) ou gratuitas (dotproject (2013)), desktop ou acessíveis via web (GONCALVEZ et al., 2012). Entre as de código livre, a mais popular e com foco em GP, é o dotproject (PMI BRASIL, 2008; GRESSE VON WANGENHEIM et al., 2009; GONCALVEZ,

10 ). O dotproject tem como objetivo auxiliar os usuários a planejar e monitorar múltiplos projetos. Ele é um software livre (sob a licença GPL), para gerenciar projetos de forma online (DOTPROJECT, 2013), que fornece funcionalidades para o gerenciamento de projetos, tarefas, usuários, recursos, entre outros. Com as vantagens advindas de modelos do software livre, o DotProject tornase uma escolha convidativa para as instituições brasileiras, principalmente aquelas que possuem capacidade de desenvolvimento e aprimoramento da ferramenta, podendo assim implementar customizações que dificilmente seriam conseguidas em sistemas proprietários (VIÉGAS,2005). Além disso, de acordo com o guia livre (GOVERNO FEDERAL, 2005), o governo incentiva organizações a adotarem ferramentas livres para diversas áreas do seu negócio. 1.2 Problema Apesar de em comparação com outras ferramentas de GP de código livre o dotproject ser uma das mais completas quanto à funcionalidade (PEREIRA et al., 2013), o dotproject possui uma usabilidade muito pobre (GRESSE VON WANGENHEIM et al., 2008; CASEY SOFTWARE LLC, 2005). Entende-se por usabilidade a medida pela qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com eficácia, eficiência e satisfação em um contexto de uso específico. (ISO , 1998). Gresse von Wangenheim (2008) e Casey Software Llc (2005) apontam diversos problemas de usabilidade do dotproject, como: falha no agrupamento por localização, no significado de códigos e títulos, na densidade informacional e na falta de homogeneidade nos alinhamentos. Além disso, também foi observado o uso de expressões em língua estrangeira e a existência de elementos e campos na interface que não possuem funcionalidade, além de possuir campos de formulários desordenados, sem um sequência lógica aparente. Há a apresentação repetida de informações, o que pode confundir o usuário e exige muitos passos para tarefas realizadas com muita frequência, como criar uma atividade, por exemplo. Considerando a importância da usabilidade como fator que determina a adoção de um sistema de software fica evidente a necessidade de melhorar o design de interface do dotproject. Porém, com a escassez de estudos sobre a usabilidade de ferramentas de GP e a consequente falta de diretrizes para guiar o desenvolvimento

11 11 de interfaces para este tipo de sistema torna-se necessário analisar quais são as características da interface que contribuem para o desenvolvimento de ferramentas de GP com boa usabilidade. 1.3 Objetivo O objetivo geral do presente trabalho é melhorar o design de interface de uma ferramenta de gerencia de projetos, dotproject+ versão Os objetivos específicos do trabalho são: 1. Analisar a fundamentação teórica em relação a GP, ferramentas de GP, e especialmente o dotproject e engenharia de usabilidade. 2. Analisar o estado da arte de estudos de usabilidade do dotproject+ e outras ferramentas de suporte a GP. 3. Melhorar a usabilidade da interface do dotproject+ usando um processo sistemático de engenharia de usabilidade. 4. Realizar uma análise comparativa da usabilidade do dotproject+ e da versão Delimitações As delimitações do trabalho são: 1. Como o estudo será realizado levando em consideração especificamente a ferramenta dotproject, quando os seus resultados forem aplicados à outras ferramentas, devem ser adaptados de acordo com as peculiaridades das mesmas. 2. O estudo tem como foco avaliar e melhorar os aspectos relacionados a usabilidade da ferramenta e as diretrizes são direcionadas ao design de interface, não abordando outros aspectos de qualidade de software. 3. É realizada a engenharia de usabilidade do dotproject, as implementações das melhorias propostas estão fora do escopo deste projeto. 1.5 Justificativa Com este trabalho é projetado um novo design de interface, com melhor usabilidade, para o dotproject que é uma das ferramentas de GP de código livre mais completas e utilizadas atualmente. Com uma nova alternativa de design a ser

12 12 utilizada, com maior qualidade em termos de usabilidade, procura-se incentivar o uso desta ferramenta. Como resultado, espera-se que a ferramenta com a interface melhorada facilite o trabalho das equipes de GP, aumentando a sua eficácia e eficiência e satisfação na utilização das ferramentas, que por sua vez poderá contribuir para a obtenção de taxas maiores de sucesso em projetos que utilizem o dotproject, com entregas de qualidade, dentro do prazo e sem estourar o orçamento, o que consequentemente aumenta a competitividade das empresas. 1.6 Estrutura do Trabalho Este trabalho está estruturado em 7 capítulos. No capítulo 2 é apresentado o método de pesquisa. No capítulo 3, Fundamentação Teórica, são apresentados os principais conceitos relacionados com esta pesquisa. No capítulo 4 é apresentada a análise do estado atual das pesquisas sobre a usabilidade de ferramentas de GP. O capítulo 5 apresenta o início de um estudo de caso no qual é melhorada da usabilidade do dotproject. No capítulo 6 é realizada a comparação da versão melhorada da ferramenta, com a versão No capítulo 7 são discutidos os resultados da comparação das ferramentas. No capítulo 8 é discutido o trabalho como um todo e por fim, o capítulo 8 apresenta as considerações finais do trabalho. 2 MÉTODO DE PESQUISA Em relação à natureza está pesquisa é do tipo aplicada, pois tem como resultado uma série de diretrizes que poderão ser utilizadas por desenvolvedores de interface de ferramentas de GP. De acordo com Gerhadt e Silveira (2009) esse tipo de pesquisa visa gerar novos conhecimentos de aplicação prática e dirigidos à solucionar problemas específicos. Quantos aos objetivos esta pesquisa é exploratória, pois envolve levantamento bibliográfico, bem como entrevistas com especialistas no problema de pesquisa. Para atingir os objetivos deste trabalho é realizado um estudo de caso aplicando um ciclo de vida de engenharia de usabilidade ao dotproject e comparando os resultados obtidos com a interface atual da ferramenta. O presente trabalho é realizado em 4 etapas utilizando múltiplos métodos:

13 13 Etapa 1 - Fundamentação teórica: na primeira etapa do projeto é analisada uma série de conceitos básicos que são utilizados ao longo deste trabalho. Para isso é realizada uma revisão teórica sobre Engenharia de Usabilidade, Ciclos de vida de Engenharia de Usabilidade. Também é analisada a área de GP, ferramentas de GP e especificamente o dotproject. As atividades desta etapa são: A1.1Revisar a teoria em termos de engenharia de usabilidade: A Revisar a teoria sobre engenharia de usabilidade; A Revisar a teoria sobre desenvolvimento de design de interface para aplicações web; A.1.2 Revisar a teoria em termos de GP: A.1.2.1Revisar a teoria sobre GP; A Revisar a teoria sobre ferramentas de apoio à GP/dotproject. Etapa 2 - Revisão do estado da arte: nesta etapa é realizada uma revisão sistemática da literatura seguindo o procedimento proposto por (KITCHENHAM, 2004) para identificar e analisar trabalhos similares ou que tenham como foco a usabilidade de ferramentas para GP. As atividades desta etapa são: A.2.1. Definir a revisão; A.2.2. Executar a busca; A.2.3. Extrair e analisar os dados. Etapa 3 Melhoria de usabilidade: Nesta etapa é realizada a melhoria do design de interface da ferramenta dotproject como uma ferramenta representativa das ferramentas de GP. Para isso é adotada uma customização do ciclo de vida de engenharia de usabilidade proposto por Mayhew (1999), que consiste em uma série de processes divididos 3 fases: Análise de requisitos (1), Design/teste/implementação(2) e Instalação/Operação(3). 1) Na fase de análise de requisitos são levantadas informações sobre o perfil dos usuários, das tarefas, equipamentos e ambiente de uso. Para isso é efetuada uma análise de estudos existentes e realizado um survey com usuários de ferramentas de GP. O desenvolvimento e aplicação do survey são feitos nas seguintes etapas:

14 14 1- Determinação das categorias de usuários: Os usuários das ferramentas de GP são todas as pessoas envolvidas nas atividades de desenvolvimento de software, como o gerente de projetos, programador, analista de sistemas etc. Ao longo deste projeto são priorizadas as funcionalidades do dotproject que dizem respeito as atividades desempenhadas pelo gerente de projetos, por entender que esta é a categoria de usuários que mais utiliza a ferramenta. 2- Desenvolvimento do questionário: o questionário desenvolvido, que pode ser visto no Apêndice C, possui 20 perguntas, divididas em duas categorias. A primeira categoria tem como objetivo levantar dados sobre o perfil dos usuários em termos de idade, dificuldades físicas, experiência no uso do computador e na prática da GP. A segunda parte tem como objetivo descobrir quais são as atividades que estes usuários mais utilizam em uma ferramenta de apoio à GP, que tipo de ferramenta utilizam e quais problemas de usabilidade encontram ao utilizá-la. A implementação e divulgação do questionário é feita utilizando o Limesurvey (LIMESURVEY, 2013) uma ferramenta livre e gratuita para desenvolvimento de surveys, Figura 1. Figura 1: Tela inicial do survey no Limesurvey 3- Aplicação piloto do questionário: Para avaliar o questionário quanto à sua clareza, completude e adequação das perguntas, ele é testado com dois gerentes de projetos do INCoD. Após os testes piloto são feitas as devidas alterações no questionário, todas elas são reformulações em algumas questões de modo a tornálas mais clara ou retirar ambiguidades.

15 15 4- Distribuição dos questionários: O convite para preencher o questionário é enviado por para 27 gerentes de projetos e 9 listas (como a PMI-Brasil, PMI- SC, SOFTEX) em setembro O survey é disponível até o dia 22 de Novembro. Como resultado final dessa fase é estabelecido um conjunto de metas de usabilidade. As atividades desta fase são: A.3.1 Submeter projeto ao do Comitê de Ética em Pesquisa com Seres Humanos da Universidade Federal de Santa Catarina (CEPSH/UFSC) para obter autorização do envolvimento de Gerentes de Projeto no presente trabalho; A.3.2 Definir e aplicar um questionário demográfico a um conjunto de usuários em potencial do dotproject, para levantar o perfil dos usuários, das atividades realizadas e do ambiente de uso da ferramenta; A.3.3 Analisar o perfil dos usuários, via descrição de personas, a partir dos dados obtidos com os questionários em A3.2; A.3.4 Analisar o contexto das tarefas, via de descrição das tarefas e diagramas de atividades, a partir dos dados obtidos com os questionários em A3.2; A.3.5 Analisar o ambiente, via descrição do ambiente organizacional e técnico, a partir dos dados obtidos com os questionários em A3.2. A.3.6 Definir os requisitos de usabilidade. 3) Considerando que o dotproject já está em uso, a etapa de Instalação/Operação se resume à análise do feedback dos usuários em relação a usabilidade do dotproject e a avaliação da usabilidade como objetivo de encontrar possíveis problemas de usabilidade da ferramenta. Essa avaliação é feita utilizando as técnicas de avaliação: teste de usabilidade e avaliação heurística, de forma complementar. O Teste de usabilidade é uma técnica empírica (CYBIS, 2003), no qual usuários que representam o público alvo do sistema são observados de forma sistemática, interagindo com a aplicação ou protótipo que está sendo avaliado. Enquanto o usuário realiza as tarefas, inspetores coletam dados referentes ao processo de interação do usuário, incluindo erros cometidos, situações de confusão ou frustração, rapidez com a qual realiza a tarefa, se obtém sucesso ou não na realização da mesma e sua satisfação com a experiência. A partir dos testes de usabilidade o projetista pode prever o comportamento dos usuários diante da

16 16 interface. Esse método pode ser considerado insubstituível pois fornece informações diretas sobre como o usuário realmente usa o sistema (NIELSEN, 1994). A Avaliação Heurística é um dos principais métodos analíticos para avaliação da usabilidade (que dispensa a participação do usuário) (CYBIS, 2003). Ele tem como objetivo encontrar problemas de usabilidade em designs de interface com o usuário (NIELSEN, 1993). Esse método envolve ter um pequeno conjunto de avaliadores que examinam a interface e julgam se ela está de acordo com princípios reconhecidos de usabilidade, as heurísticas. A avaliação heurística é realizada de forma individual por cada avaliador, assim que todos os avaliadores terminam a sua avaliação eles se reúnem e entram em consenso sobre os problemas encontrados (NIELSEN, 1994). Dado que algumas das atividades dos testes não são completadas pelos usuários, tornou-se inconveniente utilizar o tempo de execução das tarefas no teste de usabilidade como atributo de comparação da eficiência das interfaces. Por isso optou-se por fazer o cálculo estimado do tempo de execução das atividades utilizando a técnica Keystroke Level Model (KLM). O KLM (Card, Moran, e Newell, 1983), é uma técnica para predição do tempo de execução de uma tarefa específica. A aplicação desta técnica consiste em listar a sequência de operações que o usuário deve realizar para completar a tarefa e somar os tempos requeridos de cada uma das ações. Cada operador possui um tempo estimado para ser executado, conforme mostra a Tabela 1 abaixo. Tabela 1: Códigos, Operadores e Tempos no KLM Código Operador Tempo(s) K Apertar e soltar tecla do teclado Digitador experiente 0.08 Digitador bom 0.12 Digitador regular 0.28 Digitador com habilidade média 0.20 Digitador inexperiente 1.20 P Apontar o mouse para objeto na 1.10 B Aperta ou soltar botão do mouse 0.10 H Mover mão do mouse para o teclado (ou o contrário) 0.40 M Preparação mental 1.20 T(n) Digitar sequência de caracteres n K É aplicado o KLM para as mesmas tarefas realizadas nos testes de usabilidade, além do caso de uso Alterar o Status da Atividade. Cada uma das

17 17 tarefas é decomposta em um sequência de operadores, e a cada um é atribuído o respectivo tempo de execução (conforme a Tabela 1). Ao final são inseridos os operadores M (tempo de preparação mental). A inserção deste operador se baseia nas seguintes heurísticas: Inserir M: -No início de tarefas (o usuário tem que parar e pensar para definir o que tem que ser feito). Recuperar uma informação na memória. Encontrar algo na tela (o usuário precisa scannear a tela para achar a o item que ele ainda não sabe onde fica). Verificar se a ação foi executada corretamente antes de confirma-la. -Apontar para um objeto na tela. Se algo na tela muda em resposta à uma ação do usuário também há uma pausa para verificar a mudança ocorrida (Kieras, 2001). Como os dados e a quantidade de campos a serem preenchidos são similares em ambas às versões, os operadores que representam a ação de digitar são suprimidos do cálculo. O processo de avaliação é composto por cinco etapas: Definição, Planejamento, Operação, Análise e Interpretação e Documentação (WOHLIN, 2000) (Figura 2). Figura 2: Etapas do processo de avaliação (WOHLIN, 2000) As atividades desta fase são: A.3.7 Realizar uma avaliação heurística da versão da ferramenta; A.3.8 Realizar testes de usabilidade com a versão da ferramenta. A.3.9 Aplicar KLM com a versão da ferramenta. 3) A fase de design/teste/implementação é dividida em 3 níveis: o primeiro diz respeito a questões de design de alto nível no qual são definidos os casos de uso, o diagrama de atividades, representando o fluxo das atividades e ações de uma tarefa. O segundo nível trata do desenvolvimento de padrões por meio de protótipos

18 18 de baixa fidelidade, que são representações gráficas rudimentares da interface em desenvolvimento, que permitem aos designers testar rapidamente várias ideias (LANDAY e MYERS, 1995) sem se ater a detalhes operacionais e/ou estéticos do sistema (RUDD et al., 1996). No último nível é desenvolvido o design completo, por meio de protótipos de alta fidelidade, que possibilitam o reuso de partes do projeto e definem o look-and-feel do produto final (AGUIAR et al., 2007) e são baseados nos resultados nos níveis anteriores. Nesta fase são realizadas as atividades: A.3.10 Projetar o modelo mental, por meio do desenvolvimento de protótipos de baixa fidelidade; A.3.11 Avaliar os protótipos funcionais via teste de usabilidade Etapa 4: Estudo comparativo da usabilidade do dotproject: Nesta etapa é planejada e executada a comparação entre a interface atual da ferramenta dotproject com a interface proposta. Esta comparação tem o objetivo de verificar se as mudanças de fato melhoraram a usabilidade do dotproject. Para realizar o planejamento da comparação é utilizada a metodologia proposta por Wohlin et al. (2000), composta por 7 fases, conforme pode ser visto na Figura 3. (2000) Figura 3: Planejamento do Experimento. Adaptado de WOHLIN et al.

19 19 Primeiramente é definido o contexto do estudo de caso. Esta fase é importante para definir se o estudo é valido somente para um contexto específico ou para todo um domínio do problema. Em seguida, é formulada a hipótese de pesquisa. Na terceira etapa são selecionadas as variáveis, cujas medidas deverão ser coletadas ao longo do estudo de caso. Na sequência são selecionados os sujeitos. Por fim, é feito o desenho do estudo de caso, nessa fase é definido quantos testes são feitos e é descrito como eles são realizados. Na quinta fase são escolhidos e preparados os instrumentos de teste. Por fim é feita a avaliação da validade do estudo de caso. As atividades resumidas desta etapa são: A.4.1Definir e planejar o estudo de caso comparando a usabilidade das versões de design de interface; A.4.2 executar o estudo de caso A.4.2 Analisar os dados coletados. 3 FUNDAMENTAÇÃO TEÓRICA No presente capítulo são abordados os principais conceitos relacionados a este trabalho, como usabilidade, engenharia de usabilidade, GP, ferramentas de GP e a ferramenta dotproject. 3.1 Usabilidade No contexto deste trabalho é utilizada a definição de usabilidade proposta pela ISO (1998), por ser o resultado de um trabalho colaborativo entre diversos pesquisadores. De acordo com esta norma, esquematizado na Figura 2, usabilidade é a capacidade de um produto ser usado por usuários específicos para atingir objetivos determinados como eficácia, eficiência e satisfação em um contexto previsto para o uso. A eficácia é a acurácia e completude com as quais usuários alcançam objetivos da interação, e é geralmente avaliada em termos de completude de uma tarefa, e da qualidade do resultado obtido. Já a eficiência se refere à quantidade de esforço para chegar a um determinado objetivo. Os desvios que o usuário faz, o tempo de duração da interação e a quantidade de erros cometidos, podem servir para avaliar o nível de eficiência do software. Satisfação, se refere ao nível de conforto que o usuário sente ao utilizar a interface (ISO , 1998).

20 20 Figura 4:Estrutura de usabilidade Fonte: ISO Requisitos Ergonômicos para Trabalho de Escritórios com Computadores Parte 11 Orientações sobre Usabilidade. A ferramenta foco deste trabalho é uma aplicação web que tem um estilo de interface mais similar à de sistemas desktops do que de websites. Existem muitos estudos sobre a usabilidade de websites (NIELSEN e LORANGER, 2007; SCAPIN, 2000), porém, não há muita pesquisa a respeito da usabilidade de interfaces de sistemas desktop. Em função disso, na prática aplicam-se os mesmos princípios de usabilidade para ambas, levando-se em consideração as diferentes características entre elas, como: Em websites é comum ter pelo menos um espaço reservado para publicidade, o que dificilmente ocorre em aplicações web. Websites, geralmente possuem um campo para busca. Aplicações web determinam qual será o ponto de partido do usuário, diferentemente de websites, onde o usuário pode acessar por meio de páginas diferentes. Em websites normalmente há uma navegação global, disposta na lateral esquerda ou na parte superior da tela, isso nem sempre ocorre em aplicações web. Em aplicações web não há barra de URL. Diferentes modelos conceituais do layout das telas.

21 21 Neste contexto, por tanto, este projeto utiliza princípios de usabilidade para interfaces de websites considerando-se as suas características específicas de aplicação web Engenharia de Usabilidade Para desenvolver uma interface de qualidade, porém, nem sempre é suficiente aplicar técnicas de avaliação da usabilidade apenas no final da etapa de desenvolvimento. Para reduzir o risco de falhas conceituais do projeto e garantir que o sistema responda às expectativas e necessidades dos usuários em suas tarefas, os processos do ciclo de vida de engenharia de usabilidade devem ser implementados desde cedo no desenvolvimento (CYBIS, BETYOL e FAUST, 2007). O termo modelo do ciclo de vida é utilizado para definir um modelo que descreve um grupo de atividades, a forma como elas se relacionam ou ainda quando e como passar para a próxima atividade, e quais são os resultados de cada uma delas (PREECE et al, 2005). Entre os modelos existentes (HARTSON e HIX, 1989; ISO , 2010; MAYHEW, 1999) o Ciclo de vida de engenharia de usabilidade (MAYHEW, 1999), oferece uma visão holística acerca da engenharia de usabilidade e uma descrição detalhada de como realizar as avaliações. Ele é composto por 3 etapas, conforme a Figura 5. Na primeira delas é realizada a análise

22 22 Figura 5: Ciclo de Vida de Engenharia de Usabilidade Fonte: MAYHEW,1999. de contexto de uso e resulta na obtenção de Metas de Usabilidade, que deverão ser atingidas ao final do projeto. A fase 2, por sua vez é dividida em 3 níveis, todos eles iterativos, que possuem atividades de desenvolvimento de protótipos da interface, cada um com um nível de fidelidade maior que o outro. Ao final de cada nível os protótipos são avaliados. Por fim, há a fase de Instalação na qual é coletado o feedback dos usuários e feitas as melhorias necessárias. Reconhecendo que alguns projetos não terão a necessidade de realizar todas as atividades do ciclo de vida a autora sugere que alguns passos sejam pulados se forem muito complexos para o sistema que está sendo desenvolvido (MAYHEW, 1999). 3.2 Gerenciamento de Projetos O gerenciamento de projetos (GP) permite que empresas possam, entre outras atividades, prever gastos com o projeto, adaptar seus trabalhos ao mercado consumidor e aos clientes, agilizar decisões, aumentar o controle gerencial e

23 23 otimizar a alocação de pessoas, equipamentos e materiais necessários (VARGAS, 2005). Dentro desse contexto compreende-se que um projeto é um esforço temporário com o objetivo de criar um produto, serviço ou resultado. Ele possui um início e um término bem definidos, sendo o término atingido quando os seus objetivos forem alcançados ou concluir-se que eles não poderão ser atingidos (PMI, 2013). O gerenciamento de projetos, por sua vez é a aplicação de conhecimentos, habilidades ferramentas e técnicas às atividades de um projeto com a finalidade de alcançar os seus requisitos (PMI, 2013). Para isso é necessário identificar requisitos, se adaptar às diferentes necessidades e expectativas das partes interessadas e balancear as restrições do projeto que podem ser conflitantes, como escopo, orçamento, cronograma e recursos (PMI, 2013). O gerenciamento de projetos se dá a partir da aplicação de processos. Um processo é um conjunto de atividades inter-relacionadas que são realizadas para alcançar um produto ou serviço predefinido. Os processos de GP podem ser agrupados em 5 grupos conforme a Figura 6 (PMI, 2013). Iniciação: realizados para definir um novo projeto, ou fase através da obtenção de autorização para iniciar um projeto ou fase. Planejamento: realizados para definir o escopo do projeto, refinando objetivos e o curso de ação necessário para atingi-los. Execução: realizados para executar o trabalho definido no plano de gerenciamento. Monitoramento & Controle: necessários para acompanhar, revisar e regular o progresso e desempenho do projeto.

24 24 Encerramento: realizados para finalizar formalmente todas as atividades de todos os grupos de processos. Figura 6: Grupos de Processos do Ciclo de Vida de Engenharia de Usabilidade. Fonte: PMI, 2013 As áreas de conhecimento se referem aos fatores que são considerados no GP. Em cada área de conhecimento são detalhados os processos que as compõem, as entradas necessárias, as atividades executadas, e as saídas produzidas (PMI, 2013). A Tabela 2 apresenta de maneira de maneira sucinta o objetivo de cada área de conhecimento de acordo com PMI (2013). Área de conhecimento Integração Escopo Tempo Custos Qualidade Recursos humanos Comunicações Riscos Aquisições Stakeholder Tabela 2: Processos por área de conhecimento Possui processos para Identificar, definir, combinar, unificar e coordenar os vários processos e suas atividades de maneira adequada. Garantir que o projeto realize todo o trabalho necessário, e não mais que isso. Garantir a conclusão do projeto de acordo com o prazo previsto. Planejar, estimar e determinar o orçamento para assegurar que o projeto seja concluído dentro do orçamento aprovado. Planejar, monitorar e controlar para garantir que o projeto satisfaça os requisitos de qualidade especificados. Organizar e gerenciar a equipe do projeto. Garantir que as informações necessárias sejam coletadas, armazenadas e disseminadas da forma adequada. Identificar e analisar os riscos, bem como, planejar ações de contingência e realizar o controle e monitoramento dos mesmos. Assegurar a compra ou aquisição de produtos ou serviços, externos à equipe do projeto, necessários para o seu desenvolvimento. Identificar, planejar a gerência, e controlar a gerência dos stakeholders.

25 Gerente de Projeto No contexto deste trabalho é de fundamental importância conhecer o perfil do gerente de projetos, dado que ele é o principal responsável pela gerência de projetos e por atingir os objetivos do projeto. Entre suas atividades estão: iniciar e planejar o projeto, monitorar e controlar o andamento do projeto, identificar, rastrear, gerenciar e responder a problemas no projeto, comunicar pro-ativamente as informações do projeto para todos os interessados, motivar e liderar a equipe. Como suporte às suas atividades o gerente dispõem de metodologias e ferramentas, porém, saber aplicá-las não é o suficiente para um gerenciamento eficaz. A Figura 7 (PMI, 2004), mostra que além das competências gerais da área de gerenciamento, como saber o que são processos e quais são os grupos de processos, o gerente eficaz deve possuir conhecimentos sobre normas e regulamentação da área de aplicação, sobre o ambiente do projeto, sobre contabilidade, compras, aquisições e logística. Além disso, é desejável que ele possua habilidades pessoais, como ter atitude, espírito de liderança, além da capacidade de orientar a equipe ao mesmo tempo em que atinge os objetivos do projeto dentro das restrições impostas. Figura 7: Competência Gerais de um Gerente de Projetos. Fonte: PMI (2004) Ferramentas de Gerenciamento de Projetos O uso de tecnologia para gerenciar projetos tem um impacto positivo significante como critério de sucesso dos projetos atualmente, logo torna-se fundamental a utilização de uma ferramenta que suporte o GP no dia a dia

26 26 (GUEDES, 2003) (JESSEN, 2000). Para isso, as ferramentas devem reunir as informações necessárias para uma organização executar os seus projetos com sucesso e deve ajudar a planejar, executar e encerrar o projeto, alcançando as suas metas (RAYMOND e BERGERON, 2008). Patterson (2010) acrescenta ainda que ferramentas de apoio a GP são um conjunto de ferramentas de TI que devem suportar técnicas de GP para permitir a realização de todos os processos do ciclo de vida de um projeto, do seu início ao fim. Para isso elas permitem a visualização do projeto de forma integrada, contemplando atividades, prazos, alocação de recursos, custos e etc. Além de tornar possível, acompanhar o status do projeto, sinalizando o atraso de tarefas; visualizar uma possível super ou sub-alocação de recursos humanos e identificar riscos a fim de minimizá-los (GUEDES, 2003). Existe atualmente uma grande variedade de ferramentas para GP (GONCALVEZ et al, 2012). Algumas proprietárias, como o Microsoft Project (MICROSOFT, 2014), RationalPlan (SOFT LTD., 2014) e Primavera (ORACLE, 2014), outras gratuitas como o dotproject, o RedMine (REDMINE, 2014) e o GanttProject (GANTTPROJECT TEAM, 2014). As ferramentas gratuitas podem ser consideradas uma ótima opção para pequenas empresas que não podem investir em um produto pago, que normalmente são muito caros (MARGEA e MARGEA, 2011). A ferramentas podem ainda ser diferenciadas entre desktop (como o GanttProject e Open Workbench, por exemplo) e web (como o dotproject (DOTPROJECT, 2013)) que possuem a vantagem de permitir que membros do projeto relatem o status das atividades e detalhem o seu progresso de forma online (MARGEA e MARGEA, 2011). Algumas ferramentas são mais pontuais, oferecendo somente algumas das atividades realizadas ao longo do planejamento e gerenciamento de um projeto, como gerar um diagrama de Gantt (GanttProject (GANTTTPROJECT, 2013)), ou apenas estimar durações para as atividades e gerenciar contatos (DeskAway (DESKAWAY, 2013)). Há também ferramentas mais abrangentes, como por exemplo, o Primavera, que atende as práticas do PMBOK (GONCALVEZ, 2012) e outras, como o in-step, processmax, e Polarion que abrangem um nível inteiro de maturidade do CMMI e/ou MPS.BR incluindo entre outros processos, o GP (GRESSE VON WANGENHEIM et al., 2009).

27 27 Levando em consideração as necessidades de micro e pequenas empresas (MPEs) de software 1, que representam a grande maioria no mercado Brasileiro (SOFTEX, 2009) e que ferramentas web livres possuem a vantagem de ter um custo reduzido, decidiu-se por adotar neste trabalho uma ferramenta com estas características. Além disso, o fato de o código ser aberto permite a implementação das mudanças propostas para a interface da ferramenta. Optou-se também por usar uma ferramenta para plataforma web, possibilitando dessa forma a inserção e acesso de informações por vários stakeholders, principalmente pela equipe de projetos, e permitindo, dessa forma, o acompanhamento de todo o ciclo de vida de GP (principalmente a fase de monitoramento & controle). Uma das ferramentas livres e para plataforma web mais populares, que foca em GP, é o dotproject (Fig. 6), que tem mais de 1,443,670 de downloads no SourceForge ( um dos maiores repositórios de projetos de código aberto do mundo (PMI BRASIL, 2008; GRESSE VON WANGENHEIM et al., 2009; GONCALVEZ, 2012). O dotproject tem como objetivo auxiliar os usuários a planejar e monitorar múltiplos projetos. Ele é um software sob a licença GPL, para gerenciar projetos de forma online, desenvolvido por voluntários, utilizando a linguagem de programação PHP com banco de dados MySQL (DOTPROJECT, 2013). Figura 8: Tela inicial dotproject 1 Tem no máximo 19 colaboradores e receita anual bruta de até 240 mil reais (SEBRAE 2010).

28 28 O dotproject fornece suporte completo para desenvolvimento de melhorias e personalizações, permitindo que ele seja evoluído para atender de forma integral os requisitos almejados (DOTPROJECT, 2013). Em comparação com outras ferramentas de GP de código livre o dotproject é uma das mais completas quanto à definição de atividades, estabelecimento de estimativas para os produtos de trabalho, de esforço; atributos e duração de tarefas, sequenciamento de atividades, planejamento de recursos (PEREIRA et al., 2013). Tais funcionalidades estão distribuídas em módulos Core ou Addons. Os módulos core são funcionalidades agrupadas, fornecidas como parte do produto básico de instalação e que é suportada e mantida pela equipe de desenvolvimento Dev Team (DOTPROJECT, 2013). Os módulos core da versão utilizada neste projeto são: Tabela 3: Módulos Core do DotProject Módulos Administração de Usuários Tarefas Empresas Contatos Projeto Eventos Fóruns Calendário Descrição Permite cadastrar novos usuários do sistema. Provê uma lista das atividades alocadas para o usuário. É usado para gerenciar todos os recursos da companhia, como clientes, fornecedores, departamentos e projetos. Exibe todos os contatos e usuários do sistema armazenados no sistema. Este módulo é usado para gerenciar todas as atividades do projeto. Nele são exibidos os dados do projeto como nome, data de início e término e lista das atividades. Os eventos, exibidos no calendário, são através de um ícone, que indica o tipo de evento, mais o nome do mesmo. É um módulo para comunicação. Na tela principal do dotproject é exibida uma aba Fóruns que contém uma lista com todos os fóruns do projeto, a descrição, o número total de respostas e a data da última postagem de cada um deles. Este módulo exibe o calendário do mês atual. Arquivos Este módulo exibe uma lista com todos os arquivos anexados ao projeto. Os módulos addon são funcionalidades desenvolvidas e mantidas separadamente dos módulos Core e na sua maioria são desenvolvidas por diversas equipes do mundo todo e não pela Dev Team. O Grupo de Pesquisa de Qualidade de Software (GQS), integrante do Instituto Nacional de Convergência Digital (INCoD) vêm desenvolvendo diversos trabalhos acadêmicos focados na evolução da ferramenta dotproject para contemplar o gerenciamento de projetos em MPEs, alinhado aos guias e modelos de boas

29 29 práticas, principalmente o PMBOK (GONCALVEZ, 2012). Entre os trabalhos desenvolvidos, é possível destacar o desenvolvimento de módulos addon exibidos na Tabela 4. Tabela 4: Módulos Addon do DotProject+ Módulos addon Iniciação Planejamento de Recursos Humanos Planejamento de Riscos Monitoramento e Controle Planejamento de Tempo Planejamento de Custos Planejamento de Comunicação Descrição É desenvolvido o termo de abertura do projeto com título justificativa, objetivos, resultados esperados, premissas, restrições, orçamento, data início e fim marcos e critérios de aceite. São definidos os papéis e a política organizacional da empresa. Permite listar os riscos do projeto bem como distinguir os que estão em observação, criar uma lista de resposta e lições aprendidas. Permite coletar dados, como tempo e custo, analisar os dados, realizar reunião de monitoração equipe, revisar o plano de projeto. Os pacotes de trabalho da EAP são derivados em atividades, é desenvolvido o diagrama de precedência, são estimados os tempos de duração das atividades e os recursos necessários. Permite editar as estimativas de cursos de recursos humanos e não humanos. Permite criar canais de comunicação e definir o que será comunicado, por e para quem e com que frequência. Encerramento Exibe todos os documentos anexados ao projeto, bem como um relatório de acompanhamento de todo o projeto, permite criar e editar atas de reunião pós-morte e uma base de experiências básicas. No contexto deste trabalho, é adotada a versão do dotproject com módulos addon (o dotproject+) desenvolvidos no GQS. Sua arquitetura é exibida na Figura 9. Figura 9: Arquitetura do DotProject

30 30 4 ANÁLISE DO ESTADO DA ARTE O presente capítulo apresenta o estado atual das pesquisadas relacionadas às boas práticas de usabilidade para o desenvolvimento de interface para ferramentas de gerência de projetos. A análise do estado da arte foi realizada seguindo o método de revisão sistemática de literatura definido por Kitchenham (2004). 4.1 Definição da Análise O objetivo desta revisão sistemática da literatura é identificar e analisar trabalhos similares ou que abordem estudos sobre a usabilidade de ferramentas de GP. Com esta revisão espera-se identificar características do design de interface que contribuem com a melhoria da usabilidade destas ferramentas. Por entender que área de pesquisa deste projeto é transdisciplinar (podendo ser estudada a partir da IHC (Interação Humano Computador), design, ciência da computação, GP) a busca foi realizada no Google Scholar que concentra trabalhos acadêmicos de diversas áreas e bases de conhecimento e dessa forma reduz o risco de eliminar trabalhos relevantes que podem estar presentes em bases de somente uma das áreas. São considerados trabalhos científicos publicados no período entre Janeiro 2003 e Julho de 2013 e escritos em inglês ou português. São considerados trabalhos que avaliaram ou desenvolveram interfaces para ferramentas de GP discutindo aspectos positivos e negativos da mesma em termos da sua usabilidade. Todos os trabalhos que não apresentavam algum dos quesitos mencionados acima são excluídos. Foram realizadas buscas informais utilizando combinações de termos como tool, software, system, development, interface, design e evaluation com project management, com o objetivo de identificar qual deles abrange o maior número de trabalhos que atendem aos critérios de inclusão especificados. Após uma fase da calibração do termo de busca foi definida a seguinte string de busca: project management tool" interface design development usability. 4.2 Execução da Busca A pesquisa foi realizada no mês de Julho de A busca realizada no Google Scholar inicialmente retornou 474 artigos. Primeiramente foi feita uma

31 31 análise dos títulos e resumos dos artigos verificando se os mesmos estavam de acordo com os critérios de inclusão. Após esta análise somente 10 artigos foram considerados potencialmente relevantes. Em um segundo momento os 10 artigos foram lidos na íntegra. Foi constatado que 9 deles não abordavam o desenvolvimento de interface da ferramenta. Como resultado final foi encontrado somente um artigo que atende os critérios de inclusão. Além do artigo encontrado na busca, citado acima, também foram encontradas outras pesquisas em buscas informais. Entre elas o artigo intitulado A Practical Approach for Software Project Management (BOZHIKOVA, STOEVA e TSONEV, 2009). Nela são descritas as principais funcionalidades e telas da interface do Svet, uma ferramenta para gerência de projetos baseada na web. Apesar de não ser feita uma avaliação formal da interface, os autores destacam características (Tabela 5) do design que consideram positivas. Tabela 5: Características da interface do Svet Características da interface do Svet Na tela inicial são exibidas as informações relevantes do usuário, pra permitir um fácil monitoramento das atividades diárias. Possui uma estética unificada, intuitiva e um design de interface mínimo e fácil de usar. Adicionar um projeto e uma tarefa é muito similar e simples quando comparado com outras ferramentas como o dotproject. São usadas cores discretas, os controles são fáceis de encontrar na janelas. Todas as telas (como, anotações, tarefas, projetos, calendários, clientes, projetos, usuários, etc.) podem ser acessadas com um clique. Todo o conteúdo é organizado de forma clara e com relação a sua funcionalidade. As anotações são muito fáceis de serem movidas, simplesmente arrastando e soltando. Como ponto negativo foi citado o fato não poder ser usados atalhos de teclado. Outro trabalho relacionado é de Fachine e Araújo (2010), no qual foi feita a avaliação da ferramenta MSProject. Porém, a avaliação foi realizada somente com a execução de um teste de usabilidade com um participante. Este destacou como ponto positivo da ferramenta a familiaridade com o pacote MS Office, que tornou o seu uso mais fácil. Também foram elencados aspectos negativos como a dificuldade em achar algumas funcionalidades no momento em que eram necessárias. Isso ocorreu devido à grande quantidade de funções do sistema, que tornava difícil para o usuário encontrar o que estava procurando e em outras situações se porque as

32 32 funções estavam localizadas em lugar diferente do usado no pacote MS Office (FACHINE e ARAÚJO, 2010). 4.3 Extração e Análise dos Dados Em relação do objetivo desta analise foram extraídas informações do artigo relevante a respeito de aspectos positivos e negativos da usabilidade da ferramenta de GP analisada. Os dados extraídos estão na Tabela 6. Tabela 6: Análise e Extração de Dados Artigo Ferramenta Pontos Fortes da Interface Uma avaliação da interface de usuário de uma ferramenta Open Source de gerenciamento de projetos baseado na web. (GRESSE VON WANGENHEIM, 2008) 4.4 Discussão DotProject Padrão cromático Pontos Fracos da Interface Excesso de informação nas telas Cores brilhantes e com alta saturação Problemas de agrupamento por localização Problemas com o significado de códigos e denominações Falta de homogeneidade nos alinhamentos Uso de língua estrangeiras Uso de elementos e campos na interface sem funcionalidade Ordenação dos elementos é confusa Botões estão posicionados em lugares não convencionais Informações que deveriam ser preenchidas primeiro aparecem no final da tela Informações repetitivas Apesar da pequena quantidade de trabalhos relacionados encontrados, estudos indicam que as ferramentas de apoio a GP são uma das principais limitações entre os métodos/ferramentas/técnicas de GP (WHITE e FORTUNE (2002). Mesmo assim, ainda não existem propostas na literatura que busquem solucionar essas questões (ARAÚJO, 2008). Porém reconhecendo-se que para a criação de novas propostas de ferramenta de GP com qualidade, a questão da usabilidade deve ser avaliada (FACHINE e ARAÚJO, 2010). A usabilidade deve ser considerada principalmente quando é sabido que ela é um dos atributos mais importantes da qualidade de sistemas de software (CYSNEIROS, 2003) (FACHINE e ARAÚJO, 2010). Além disso, a usabilidade também é apontada como importante fator de aceitação de um produto de software por parte do usuário (CYSNEIROS, 2003). Logo, devido à escassez deste tipo de estudo este projeto é de fundamental

33 33 importância, para aprimorar a usabilidade, e por consequência, a qualidade das ferramentas de GP. 5 MELHORIA DA USABILIDADE DO DOTPROJECT Com objetivo de melhorar a usabilidade da interface do dotproject foram seguidas as etapas de processo sistemático de engenharia de usabilidade (MAYHEW, 1999) 2. Inicialmente são realizadas as tarefas da etapa 1 de Análise dos requisitos do sistema (Sessão 5.1.1), para analisar o perfil dos usuários, tarefas e ambiente de uso. Em seguida, como o sistema já está em funcionamento, é feita uma avaliação da usabilidade da ferramenta (Sessão 5.2), cujos resultados servem de entrada para a etapa 2 - Design/Teste/Implementação. Nesta etapa é desenvolvido o modelo conceitual da nova interface proposta, bem como foram desenvolvidos os protótipos de baixa fidelidade (Sessão 5.3) Análise de Requisitos Na fase de análise de requisitos são levantadas as informações de contexto de uso do dotproject. São analisados o perfil dos usuários, das tarefas, e do ambiente de uso, por meio da definição e aplicação de questionários a um conjunto de usuários em potencial do dotproject. Para coletar dados referente ao contexto de uso das ferramentas de GP, especificamente do dotproject foi realizado um survey. Figura 10: Fase Análise de requisitos 2 Esta pesquisa foi aprovada pela Comissão de Ética em Pesquisa Envolvendo Seres Humanos da UFSC - CEPSH, sob o número de parecer

34 Análise dos dados coletados Nesta sessão são analisados os dados coletados via survey. Ao final foram obtidas 28 respostas Perfil dos usuários Após a análise das respostas do questionário, foi traçado um perfil do usuário de ferramentas de apoio a GP. A Tabela 7 mostras as características dos mesmos. Característica Idade média Capacidades e limitações físicas Habilidades no uso do computador Formação profissional Experiência na tarefa Motivação Tabela 7: Características dos Usuários Usuário Gerente de Projeto de Software 60% tem entre 24 e 45, 14% tem entre 18 e 25 e 26% tem entre 46 e 60 anos. Não possuem limitações físicas. Possuem boas habilidades no uso do computador, 75% utiliza-o mais de 4 horas por dia. Possuem principalmente formação em computação (70%), mas também em administração ou engenharia. Geralmente realizaram mais de 80 horas de curso de capacitação em GP (65%). 50% dos gerentes não possuem nenhum tipo de certificação, dos que possuem, 70% são PMP. No geral, possuem boa experiência na tarefa, 35% atuam como gerente há mais de 10 anos e 45% entre 3 e 10 anos. Utilizam predominantemente métodos de gerência tradicionais (83%, destes, 50% também utilizam métodos ágeis). Utiliza software de apoio principalmente para: Monitorar e controlar o cronograma, definir o cronograma, realizar termo de abertura, monitorar e controlar custos, estimar tempo e definir as atividades. Acham que utilizar um software de apoio à GP ajuda muito no trabalho (42%) e às vezes se torna indispensável (46%). A partir dos dados coletados com o survey, é criada uma persona para ilustrar o perfil dos gerentes de projeto usuários de ferramentas de GP. Gerente de Projetos: João Silva sempre gostou de tecnologia, por isso decidiu fazer um curso de graduação na área de TI. Antes mesmo de se formar ele já estava empregado como programador

35 Quatidade de Votos 35 em uma pequena empresa de software em Florianópolis/SC. Devido ao seu bom desempenho no trabalho, o chefe de João o promoveu à gerente de projetos de software, cargo que ocupa há 8 anos. Neste período João fez alguns treinamentos profissionais e um curso de especialização na área de gerência de projetos de software, porém ainda não possui nenhuma certificação. Como João gerencia em média 3 projetos ao mesmo tempo, tendo cada um deles em torno de 5 membros, ele acha fundamental a utilização de uma ferramenta que o auxilie em algumas das suas atividades diárias, como definir o cronograma e planejar os recursos humanos Análise de contexto das tarefas Para direcionar o presente trabalho para as atividades realizadas com maior frequência pelos gerentes de projetos, foi feita uma análise das respostas do questionário para verificar quais as atividades mais realizadas pelos gerentes de projeto respondentes (Figura 11) Atividades 5 0 Monitorar e controlar o cronograma Definir o cronograma Realizar termo de abertura Atividades Monitorar e controlar custos Estimar tempo Definir as atividades Figura 11: Atividades mais realizadas pelos gerentes de projeto

36 36 Considerando que a maior parte das tarefas mais realizadas estão relacionadas a área de conhecimento de Tempo decidiu-se selecionar para avaliação e aperfeiçoamento todas as atividades dos processos associadas a esta área do conhecimento. As atividades detalhadas podem ser vistas na Tabela 7. Devido às suas peculiaridades, nem sempre os processos de GP podem ser totalmente automatizados, de modo a serem executados exclusivamente por uma ferramenta de software. Por exemplo, há diversas atividades nos processos de GP, como definir o organograma e descrição dos cargos e registrar ações corretivas, que precisam sempre ser executadas manualmente pelo GP. Porém, mesmo nesses casos, a ferramenta de GP tem um papel importante, fornecendo suporte à execução de tais atividades, tanto em relação à documentação das informações e artefatos envolvidos no processo, quanto em certos momentos automatizando algumas tarefas, como somar custos para a serem usados no cálculo do orçamento do projeto. São consideradas processos automatizadas, aquelas as quais a ferramenta de GP propõe uma saída, que depois pode ser revisada e ajustada pelo GP. Dessa forma não é necessário que o gerente execute toda a atividade manualmente, mas somente confira o resultado proposto pela ferramenta. Por exemplo, para gerar um gráfico de Gantt de forma automática, é suficiente que o gerente insira as atividades do projeto com as suas datas de início e fim e solicitar que a ferramenta gere o gráfico. Além de realizar determinadas atividades de forma automática, as ferramentas de GP também podem fornecer suporte para o registro e visualização de informações. Por exemplo, o registro de ações corretivas é feito de forma manual pelo gerente e pode ser registrado na ferramenta de GP, desse modo ele pode ser compartilhado com outros membros da equipe do projeto. Na sequência são descritas as ferramentas e técnicas utilizadas para realizar cada as atividades selecionadas que podem ser realizadas com algum tipo de suporte do software de gerência de projetos. A Tabela 8 exibe cada uma delas e as classifica entre as que podem ser feitas de forma automática pelo dotproject, e as que somente recebem suporte para registro/visualização das informações. Além disso, a última coluna informa se a atividade é suportada pelo dotproject+ usando a

37 37 seguinte escala: não, manualmente de forma gráfica, manualmente de forma textual, automaticamente. Tabela 8: Identificação do grau de suporte oferecido pela ferramenta de software de GP Processo Atividades/Técnica Automática Suporte para registro/visualização das informações Planejar gerenciamento do cronograma Definir atividades Sequenciar atividades Estimar recursos Estimar duração Desenvolver cronograma as São realizadas reuniões para realizar o planejamento do cronograma do projeto. Definir atividades a partir dos pacotes de trabalho da EAP (Decomposição) Identificar dependências entre atividades (Análise de rede do cronograma) Alocar recursos (Estimar recursos e Nivelamento de recursos) Estimar tamanho esforça, recursos e duração das atividades. Estabelece datas de início e fim para as atividades. Identificar o caminho crítico (Método do caminho crítico) Identificar a cadeia crítica (Método da cadeia crítica) Planejamento Ferramenta gera diagrama de rede do Ferramenta propõe esquema de alocação dos recursos / identifica possíveis conflitos na alocação dos recursos Ferramenta identifica na rede do cronograma qual o caminho crítico Ferramenta identifica na rede do cronograma Gerente registra/visualiza as atividades Gerente registra/visualiza as atividades Gerente cria/visualiza a rede Gerente registra/visualiza a atribuição dos recursos Gerente registra/visualiza a estimativas das atividades Gerente registra/visualiza a datas de início e fim das atividades Gerente registra/visualiza o caminho crítico da rede do cronograma Gerente registra/visualiza a cadeia crítica da rede do cronograma Suportada pelo dotproject+ Não Manualmente de forma textual Manualmente de forma gráfica Manualmente de forma textual. Manualmente de forma textual Manualmente de forma textual Não Não

38 38 qual a cadeia crítica Otimizar cronograma (Compressão cronograma) do Ferramenta paraleliza o maior número de atividades possível. Gerente registra alterações no cronograma Não Ajustar cronograma (Ajuste antecipações atrasos) de e Gerente registra alterações no cronograma Manualmente de forma textual Monitoramento e controle Controlar cronograma- o Acompanhar execução atividade de Ferramenta gera tabela com informação sobre as datas de início e fim das atividades e o seu status de progresso. Gerente visualiza o relatório Sim Visualizar cronograma controle de Gerente visualiza cronograma Sim (gráfico de Gantt) Calcular Variação de prazo (VP) e e índice de desempenho de prazos (IDP) (Análise de desempenho) Ferramenta compara o desempenho do cronograma com as datas de início e término, calcula VP, IDP, porcentagem completa e duração restante para o trabalho em andamento. Gerente registra/visualiza comparação do desempenho do cronograma com as datas de início e término e porcentagem completa e duração restante para o trabalho em andamento. Automaticamente Analisar a variação Gerente visualiza o VP e IDP para avaliar a variação da baseline Sim Registrar ações corretivas Gerente registra/visualiza ações corretivas Manualmente de forma textual

39 39 Uma análise da Tabela 8 revela que o dotproject+ oferece suporte para a maior parte das atividades/ técnicas dos processos, sendo alguma delas realizadas de forma automática (como o cálculo dos valores VP e IDP), outras o usuário deve realizar de forma manual textualmente (como estimar a duração das atividades) ou ainda de forma manual graficamente (como o sequenciamento das atividades). Foram selecionadas para melhoria neste trabalho os processos relacionados a cronograma que possuem algum tipo de suporte pelo dotproject Descrição dos Processos e Atividades Relacionados à Tempo Nesta sessão são apresentados todos os processos de GP relacionados à tempo e que possuem ao menos uma atividade suportada pelo dotproject+. Para poder fornecer suporte a essas atividades, via software de GP, é necessário já ter definido e inserido na ferramenta os artefatos de entrada. Após a realização das atividades a ferramenta de GP deve exibir os resultados contendo os elementos de saída, como mostram as Figura As características das atividades definidas a seguir são baseadas na teoria de GP (PMI, 2013), na análise dos dados coletados via survey e na experiência prática. Processo Definir Atividades: É o processo de identificar e documentar as ações específicas a serem realizadas para produzir os entregáveis do projeto. O principal benefício desse processo é decompor os pacotes de trabalho em atividades que provém uma base para estimar, executar, monitorar e controlar o trabalho do projeto. As ferramentas e técnicas para definir as atividades, são exibidas na Figura 12. Figura 12: Definir as atividades. Fonte: PMI, 2013

40 40 As ferramentas e técnicas para definir as atividades, que possuem suporte do dotproject+ são: Decomposição: é uma técnica usada para dividir o escopo e entregáveis do projeto em partes menores e mais fáceis de gerenciar. As atividades representam o esforço necessário para completar um pacote de trabalho. Atualmente no dotproject isso pode ser feito de duas formas, Decomposição das Atividades à partir da EAP. Após decompor as atividades é necessário editar cada uma delas preenchendo sua descrição. A segunda forma é criando atividade à partir da tela Nova Atividade, na qual os dados da atividades já são preenchidos. Ao longo deste projeto é usada a primeira alternativa, Decomposição das Atividades à partir da EAP, pois ela é uma evolução da segunda que será descontinuada. Ao analisar as respostas do questionário, pode-se levantar as seguintes características do processo definir as atividades, Tabela 9: Frequência de uso Tabela 9 Características do processo de Definir as Atividades Características Definir as Atividades Varia entre diariamente à uma vez no projeto, porém 50% dos respondentes a realiza mensalmente. Grau de dificuldade Tempo ideal pra executá-la Entre médio e baixo. Entre 1 ou mais de 20 minutos. 50% dos respondentes consideram o tempo ideal maior de 20 minutos. Processo Sequenciar as Atividades: Neste processo é analisada a sequência das atividades, suas durações e recursos requeridos. As ferramentas e técnicas para sequenciar as atividades, são exibidas na Figura 13, Figura 13 Sequenciar as atividades. Fonte: PMI, 2013

41 41 As ferramentas e técnicas para sequenciar as atividades, que possuem suporte do dotprojec+ são: Método de diagrama de precedência é uma técnica usada para desenvolver o modelo do cronograma, onde as atividades são representadas por nodos e estão graficamente ligadas de forma a mostrar a sequência em que devem ser executadas. Como esta não foi considerada uma das atividades mais realizadas pelos gerentes de projeto, o survey não levantou as características destas atividades, mas pode-se inferir que a frequência de uso seja a mesma de Definir a Atividade: Varia entre diariamente a uma vez no projeto, porém 50% dos respondentes a realiza mensalmente. Processo Estimar Recursos: é o processo de estimar o tipo e a quantidade de materiais e recursos humanos necessários para realizar cada atividade. Este processos permite estimar o custo e duração do projeto de forma mais acurada. As ferramentas e técnicas para estimar os recursos, são exibidas na Figura 14. Figura 14 Estimar Recursos. Fonte: PMI, 2013 As ferramentas e técnicas para estimar recursos, que possuem suporte do dotproject+ são: Alocação dos recursos (estimativa bottom-up): São estimados os recursos humanos e não humanos necessários para as atividades. É analisado se as dependências entre as atividades pode afetar a alocação dos recursos. No dotproject a alocação dos recursos não humanos é feita para o projeto como um todo, logo ela não interfere diretamente no cronograma, e por isso não será incluída na avaliação deste trabalho. Já os recursos humanos são alocados por atividade do projeto. Como a alocação dos recursos humanos influencia no tempo

42 42 mínimo para finalizar o projeto, esta atividade afeta diretamente o cronograma do projeto e por isso será incluída no escopo deste trabalho. Como a alocação de recursos humanos não foi considerada uma das atividades mais realizadas pelo gerentes de projeto, o survey não levantou as características desta atividade, mas pode-se inferir que a frequência de uso seja a mesma de Definir a Atividade: varia entre diariamente à uma vez no projeto, porém 50% dos respondentes a realiza mensalmente. Processo Estimar Duração: é o processo de estimar a quantidade de períodos de trabalho necessários para completar uma atividade com uma certa quantidade de recursos. As ferramentas e técnicas para estimar os recursos, são exibidas na Fig.14. As ferramentas e técnicas para estimar a duração das atividades, que possuem suporte do dorproject+ são: Estimar duração de atividade: Nesta atividade é estimada duração das atividades utilizando dados de projetos similares já realizados. As durações Figura 15 Estimar Duração. Fonte: PMI, 2013 estimadas podem incluir reservas de contingência e reservar buffers no cronograma do projeto. Ao analisar as respostas do questionário, pode-se levantar as seguintes características do processo definir as atividades, Tabela 10:

43 43 Frequência de uso Tabela 10 Características da Atividade Estimar Duração Características Estimar duração de atividade Varia entre semanal e somente uma vez no projeto, sendo que 50% realiza uma vez no mês ou somente uma vez. Grau de dificuldade Tempo ideal pra executá-la Varia igualmente entre não há dificuldade e dificuldade alta. Esta diferença pode ser justificada pelo fato de os respondentes utilizarem ferramentas distintas. 75% acredita que a tarefa pode ser realizada em mais de 20 minutos. Um dos respondentes da pesquisa afirmou que uma das maiores dificuldades encontradas para realizar as estimativas é quando a ferramenta não realiza uma atualização automática das datas das atividades, quando são alterados por exemplo, o esforço, recursos ou duração da atividade. Em relação à utilização de um software para auxiliar a estimar o cronograma os respondentes relataram dificuldades em alterar o esforço, duração, recursos, ou inclusão/remoção das atividades no cronograma, pois o software não faz uma atualização recursiva das datas das atividades em função das alterações. Além disso, foram relatados problemas de conflitos de recursos utilizados por outros projetos e que não eram apontados pelo software. Outra dificuldade encontrada foi a de planejar as datas de acordo com a disponibilidade dos recursos de forma a otimizar o prazo do projeto. Processo Desenvolver Cronograma: Nesta atividade é feita a análise da sequência das atividades, das suas durações e recursos necessários, bem como das restrições dos prazos com o objetivo de criar o cronograma do projeto. Inserindo estas informações a ferramenta gera um modelo de cronograma com o planejamento das datas para completar as atividades.

44 44 Figura 16: Desenvolver cronograma. Fonte: PMI, 2013 As ferramentas e técnicas para desenvolver o cronograma são em geral feitas de forma manual pelo gerente de projetos. Ao final deste projeto é gerado como saída o modelo do cronograma do projeto, que no dotproject+ é representado pelo gráfico de Gantt. O gráfico de Gantt é gerado a partir das estimativas de tempo realizadas pelo gerente. Para atualizar ou otimizar o gráfico é necessário editar as estimativas inseridas na ferramenta. A descrição da atividade Estimar Duração, pode ser vista na Tabela 10. Processo para Controlar o Cronograma: faz o controle das mudanças no cronograma do projeto e está relacionado à determinação do andamento atual e ao controle dos fatores que criam mudanças no cronograma. As ferramentas e técnicas para estimar os recursos, são exibidas na Figura 17. Figura 17: Controlar o cronograma. Fonte: PMI, 2013 Análise de desempenho: mede, compara e analisa o desempenho do cronograma como as datas de início e término, porcentagem completa e duração

45 45 restante para o trabalho em andamento. A partir dessa análise deve-se decidir se é necessário realizar ações corretivas. Essa atividade pode ser suportada pela visualização do gráfico de Gantt, funcionalidade disponível no dotproject+. Como a esta atividade não foi considerada uma das mais realizadas pelo gerentes de projeto, o survey não levantou as suas características, mas pode-se inferir que a sua frequência de uso seja no mínimo igual da atividade Monitoramento do Cronograma: varia entre diariamente e uma vez por projeto, sendo que 50% dos respondentes realiza diariamente. Como esta atividade é apenas de visualização, e não exige nenhuma ação do usuário pode-se estimar que ela demande apenas alguns segundos para ser efetuada (esse tempo não leva em consideração o período no qual o gerente analisa o gráfico, mas somente o tempo que leva para encontra-lo e abri-lo). Acompanhamento da Execução das Atividades: A ferramenta gera uma tabela com informação sobre as datas de início e fim das atividades e o seu status de progresso. Como a esta atividade não foi considerada uma das mais realizadas pelo gerentes de projeto, o survey não levantou as suas características, mas pode-se inferir que a sua frequência de uso seja no mínimo igual da atividade Monitoramento do Cronograma: varia entre diariamente e uma vez por projeto, sendo que 50% dos respondentes realiza diariamente. Como esta atividade é apenas de visualização, e não exige nenhuma ação do usuário pode-se estimar que ela demande apenas alguns segundos para ser efetuada (esse tempo não leva em consideração o período no qual o gerente analisa o gráfico, mas somente o tempo que leva para encontra-lo e abri-lo). Análise de variação: Medições do desempenho do cronograma (como VP e IDP) são usadas para avaliar a variação da baseline do cronograma. No dotproject essas atividades podem ser realizadas por meio da funcionalidade Monitoramento do Cronograma. Ao analisar as respostas do questionário, pode-se levantar as seguintes características do processo monitorar e controlar o cronograma, Tabela 11:

46 46 Frequência de uso Tabela 11: Características da ativade Monitoramento do Cronograma Características Monitoramento do Cronograma Entre diariamente e uma vez por projeto. 50% dos respondentes realiza diariamente. Grau de dificuldade Tempo ideal pra executá-la Entre médio e sem dificuldade. Entre 3 e mais de 20 minutos. 55% realiza em mais de 10 minutos. Em relação à utilização de um software para auxiliar a controlar o cronograma os respondentes relataram dificuldades em apontar as horas de trabalho da equipe e a falta de um diagrama Gantt de controle mostrando os dados reais e os planejados Descrição das Tarefas Com o objetivo de descrever a interação entre usuário e a ferramenta, nesta sessão, são apresentados os casos de uso das tarefas: definir atividade, sequenciar atividade, estimar recursos, estimar duração, desenvolver cronograma e controlar cronograma. Caso de uso 1: Decompor Atividade Pré-condição: EAP já foi criada. Tabela Erro! Use a guia Página Inicial para aplicar 0 ao texto que deverá aparecer aqui.12: Caso de uso 1: Decompor atividade Intenção do Usuário 1.Abre projeto Responsabilidade do Sistema Projeto é aberto Screenshoot 2.Clica na aba Planejamento 3.Seleciona botão de rádio Derivação Aba planejamento é aberta A tabela Definição das Atividades é aberta 4. Clica no ícone de Lâmpada para adicionar mais uma atividade no pacote Um novo campo é adicionado no pacote da EAP 5. Preenche o novo campo com o nome da atividade

47 47 6.Clica em salvar Fluxo alternativo 7. Clica no ícone de Lixeira ao lado da atividade Atividades são salvas Atividade é excluída Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma (Sequenciar atividade) Pré-condições: atividades foram criadas Intenção do Usuário 1.Abre projeto 2.Clica na aba Planejamento 3.Seleciona botão de rádio Sequenciament o 4. Ordena as atividade, arrastando-as para a posição desejada. 5. Conecta as atividades 6. Clica no botão Salvar Tabela 13: Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma Responsabilida de do Sistema Projeto é aberto Aba planejamento é aberta A janela Método do Diagrama de Sequenciamento é aberta O diagrama é salvo Screenshoot Caso de uso 3: Duração das atividades foram estimadas. Pré-condições: Criar organograma, criar papeis, criar atividades. Intenção do Usuário 1.Abre projeto 2.Clica na aba Planejame nto 3.Seleciona botão de rádio Tabela 14: Caso de uso 3: Estimar Duração Responsabilidade Screenshoot do Sistema Projeto é aberto Aba planejamento é aberta A janela Atas e Estimativas são abertas

48 48 Estimativa s 4. Preenche campos para cada atividade: -Esforço -Data início/fim -Seleciona papeis -Tamanho /métrica do esforço 5. Clica no botão Salvar Estimativas As Estimativas são salvas Fluxo Alternativo 4.a Clica no botão + para adicionar um papel 4.b Clica no botão x para excluir um papel Caso de uso 4:Controlar o cronograma: Pré-condições: as atividades foram criadas, o progresso das atividades foi atualizado, foram realizadas as estimativas, foram cadastrados e alocados os recursos humanos e não-humanos. Intenção do Usuário 1.Abre projeto 2.Clica na aba Monitoram ento e Controle 3.Seleciona o botão de rádio Cronogra Tabela 15: Caso de uso 4: Controlar o Cronograma Responsabilidade do Sistema Projeto é aberto Aba Monitoramento e Controle é aberta São exibidos os valores do VP, VA, VPR e IDP Screenshoot

49 49 ma Caso de uso 5: Visualizar Gantt: Pré-condições: atividade foi criada. Intenção do Usuário 1.Abre projeto Responsabilidade do Sistema Projeto é aberto Tabela 16: Caso de uso 5: Visualizar Gantt Screenshoot 2.Clica na aba Gráfico Gantt Aba Gráfico Gantt é aberta. Caso de uso 6:Alocar Recursos Humanos: Pré-condições: foram criados os papéis, foi definido o organograma e registrados os recursos humanos. Intenção do Usuário 1.Abre projeto 2.Clica na aba Planejame nto 3. Clica em Alocações Tabela 17: Caso de uso 6: Alocar Recursos Humanos Responsabilidade Screenshoot do Sistema Projeto é aberto Aba Planejamento é aberta Aba Alocação de pessoas a papeis é aberta. 4.Clica sobre a atividade a ser editada Tela Alocação é aberta

50 50 5.Clica sobre o papel a ser alocado Tela Alocação de Recursos humanos é aberta 6.Clica em Nova Alocação É aberta a tela Criação de alocação de recurso humano 7.Clica sobre o membro o RH a ser alocado para o papel Membro da equipe é selecionado. 8.Clica no botão Submeter Alocação é salva. Tela Alocação de Recursos é aberta. Fluxo Alternativo

51 51 6.a Clica sobre o membro o RH a ser alocado para o papel Membro da equipe já esta a alocado neste período de tempo 6.b Repete passo 6. Caso de uso 7: Acompanhar Execução de Atividade Pré-condições: Registrar atividade, registrar estimativa de tempo e atualizar status de progresso das atividades. Intenção do Usuário 1.Abre projeto 2.Clica na aba Execução 3. Clica em Acompanha mento da execução das atividades do projeto Tabela 18: Caso de uso 7: Acompanhar Excecução de Atividade Responsabilida de do Sistema Projeto é aberto Aba Execução é aberta A tabela Acompanhament o da execução das atividades do projeto é aberta. Screenshoot Análise do equipamento e do ambiente Conforme os dados coletados no survey as ferramentas de GP geralmente são utilizadas em computadores desktop com monitores entre 20 e 23 polegadas. A entrada de dados é realizada utilizando mouse e teclado QWERT. Os sistemas operacionais mais comumente utilizados são Windows (80%), Mac (9,5%) e Linux (5,6%) (W3SHCOOLS, a2014). Além disso, os gerentes provavelmente utilizam um dos seguintes browsers, que são os mais utilizados atualmente, Chrome (58,9%), Firefox (24,0%) e Internet Explorer (8,5%) (W3SHCOOLS, b2014). No caso da ferramenta dotproject+, ferramenta web utilizada no estudo de caso deste projeto, é necessário possuir uma conexão com a internet.

52 52 O usuário normalmente está sentado no seu escritório e pode ser interrompido por colegas de trabalho Requisitos de Usabilidade Com base na análise de contexto de uso das atividades e nas respostas dos questionários pós-teste, são estabelecidos os seguintes requisitos de usabilidade para as interfaces a serem desenvolvidas neste projeto. As tarefas: decompor atividade, estimar duração, controlar o cronograma e visualizar Gantt (representados pela atividade Encontrar VPR), alocar recursos humanos, acompanhar execução da atividade devem ter: -Eficácia: No mínimo 90% dos usuários sem experiência devem conseguir realizar as tarefas. -Eficiência: obter tempo de execução da atividade igual ou menor que o tempo de execução utilizando a versão Satisfação: A nova versão do sistema deve obter uma pontuação superior a 70 (usabilidade considerada boa) utilizando o questionário SUS (Bangor, Kortum e Miller, 2009). 5.2 Avaliação da Usabilidade do dotproject+ (versão 2.1.7) Figura 18: Fasse de Instalação Com o objetivo de obter o feedback dos usuários em relação ao dotproject+ e levantar possíveis problemas de usabilidade foi feita uma avaliação da ferramenta utilizando dois métodos: Avaliação Heurística e Teste de Usabilidade. Dado que a versão do dotproject+ já está instalada e em uso esta avaliação pertence à

53 53 fase de Instalação e servirá de input para as etapas seguintes de melhoria Definição da Avaliação A avaliação da usabilidade tem como objetivo levantar o maior número possível de problemas de usabilidade do dotproject+ para a sua posterior melhoria. Devido a extensão da ferramenta, que possui inúmeras funcionalidades, a avaliação focará em algumas das funcionalidades. As funcionalidades a serem avaliadas e melhoradas são: Decomposição das Atividades, Sequenciar Atividades, Estimar Recursos Humanos, Estimar Duração das Atividades, Controlar Cronograma, visualizar gráfico de Gantt e Acompanhar Execução de Atividades, conforme definido na análise do contexto Avaliação heurística A avaliação heurística do dotproject+ foi realizada de acordo com a definição de Nielsen (1995). A avaliação foi realizada no período entre 21/04/14 e 03/06/14 pela autora deste projeto. Inicialmente, foi preparado o material de apoio para a avaliação. Para isso, foi selecionado o conjunto de heurísticas de Nielsen (1994). A partir dele foram derivados itens de inspeção que resultaram em um checklist. Para complementar o checklist foram adicionadas questões do questionário Xerox Corporation (1995) e do LabUtil (2011) que eram pertinentes para avaliar a usabilidade de sistemas web. Uma vez definidas as funcionalidades a serem avaliadas e as heurísticas a serem observadas, foi realizada uma avaliação heurística da ferramenta. A medida em que eram encontradas violações às heurísticas elas eram registradas em uma planilha Excel. Ao final desse processo foi obtida uma lista com todos os problemas de usabilidade encontrados nas funcionalidades avaliadas. Em seguida cada um dos problemas foi classificado quanto a facilidade de ser corrigido e a sua gravidade. Para classificar a gravidade das violações foi usada uma escala proposta por Nielsen (1995). Tabela 19: Escala de Severidade (Nielsen, 1995) Valorização da Severidade 0 Pode não ser consensualmente identificado como um problema de usabilidade 1 Problema estético / cosmético 2 Problema menor 3 Problema importante de usabilidade que deve ser corrigido 4 Gravíssimo problema de usabilidade que deve ser obrigatoriamente corrigido

54 Análise & Interpretação dos Dados e Documentação Ao final da avaliação heurística foi obtida uma lista, com 44 problemas de usabilidade e seus respectivos graus de severidade, que pode ser visualizada na Tabela 20 a baixo. Tabela 20: Problemas de usabilidade encontrados via avaliação heurística Violação Severidade Grau de dificuldade para corrigir Visibilidade do Status do sistema: Não é evidente qual projeto/empresa/atividade está sendo trabalhado. Há campos de formulário sem rótulo (na aba para criar atividade). Título da atividade é extenso e incomum "método de diagrama de precedência" 2 Médio 2 Baixo 1 Baixo Possui rótulos em inglês. 1 Baixo Não há feedback após deletar atividades em Derivações 2 Baixo Forma do mouse não se altera sobre botões 1 Baixo O feedback das ações do usuário são quase imperceptíveis na parte superior esquerda da tela. Em Estimativa de tempo os itens de diferentes colunas se misturam. 3 Médio 2 Médio Possui legendas com cores indistinguíveis entre si. 2 Baixo Em algumas situações, ao submeter um formulário com um campo em branco é exibida uma mensagem de erro com um código e não é dito para o usuário qual campo deve ser preenchido. O sistema não deixa claro quais ações podem ser feitas a partir da execução de uma atividade e a sua organização não possui uma ordem lógica que guie o usuário a realizar as atividades na devida ordem. [Acompanhamento de atividade] Não há diferença na apresentação de opções que levam a outros paneis ou que são apenas rótulos. [Alocação de RH] Ao clicar no nome do RH ele é selecionado imediatamente, mas não há feedback informando isso. 2 Baixo 4 Alto 3 Baixo 3 Médio Compatibilidade entre Sistema e Mundo Real A ordenação das abas dentro de Projeto não tem nenhuma ordem logica O link para ver o plano de projeto está em local descontextualizado. (Projeto) Busca por atividades está fora do contexto de atividades. 2 Baixo 2 Baixo 2 Médio

55 55 Botões para adicionar e remover atividades ficam em posições muito distantes entre si. (Projetos) Link para relatórios está em local descontextualizado. (Projeto) Opção para criar atividade, evento, arquivo deletar/editar projeto não estão agrupadas de forma adequada. [Gantt] As setas pra navegar no gráfico, estão tão afastadas entre si que não deixam claro qual a sua função. [Gantt] As opções do filtro estão dispersas de forma que ele passa desapercebido. 3 Baixo 2 Baixo 2 Baixo 3 Baixo 2 Médio Consistência e padrões A navegação entre diferentes níveis da hierarquia do sistema (empresa, projeto) varia de acordo com a tela atual. A sequência de links parece ser breadcrumbs, mas são links relativos a funcionalidades da tela atual. Não há padronização nos formulários, alinhamento ou ordenação dos campos Não há padronização dos rótulos (novo=criar, salvar=submeter) Ícones não convencionais: ícone para adicionar uma atividade é uma lâmpada. Botões com a mesma funcionalidade em posições diferentes. A forma de inserir um item EAP e uma atividade é diferente. [Atividade] O formulário é dividido em duas partes, cada uma possui um botão de salvar, independente do botão a ser clicado as informações obrigatórias das duas abas devem ser preenchidas. Prevenção de Erros 4 Médio 2 Médio 2 Baixo 1 Baixo 2 Baixo 2 Baixo 3 Baixo 3 Baixo Não é possível desfazer ações. 2 Médio [Atividade] Formulário tem campos obrigatórios escondidos em outras abas. Reconhecimento em vez de Lembrança Ao descrever a atividade o usuário tem que lembrar da sequência das atividades já definida no diagrama Flexibilidade e Eficiência Mesmo quando as atividades são criadas com "atividade pai" o diagrama de precedência deve ser criado manualmente [Estimar RH] São necessários muitos passos (trocar muitas vezes de tela) para realizar a tarefa. 3 Médio 3 Alto 3 Alto 4 Médio

56 56 [Decompor atividade] As atividades são criadas na aba Planejamento, mas para preencher suas informações é necessário acessar as atividades em outro local, na Aba Atividades. [Decompor atividade] Após editar uma atividade é necessário voltar pra lista de atividades, selecionar a próxima atividade abrir novamente a tela de edição. Considerando que essa atividade é feita várias vezes em seguida a repetição desses passos diminui a eficiência da tarefa. Estética e Design Minimalista A organização do menu na aba planejamento ocupa muito espaço na tela. Os dados do projeto são constantemente exibidos mesmo quando não são necessários. As atividades sendo executadas são exibidas na parte inferior da tela. (Em projeto) Aba para atividade inativas não é necessária e ocupa espaço. Aba para organizar as atividade é desnecessária e ocupa espaço. Registro das atividades e Novo registro representam a mesma função. 4 Alta 3 Médio 2 Baixo 3 Baixo 2 Baixo 2 Baixo 2 Baixo A opção Novo Item no cabeçalho é redundante. 1 Baixo As opções Ajuda, Meus dados, to DO e Sair ocupam espaço e estão perdidos na tela. [Alocação de RH] Exibe as informações sobre conflito de recursos de forma confusa, com repetição de conteúdo e conteúdo não interativo que parecem ser controles de ação. 1 Baixo 3 Médio Analisando os resultados da avaliação heurística pode ser observado que as heurísticas mais violadas foram Visibilidade e status do sistema, Compatibilidade entre sistema e mundo real, Consistência e padrões e Design e estética minimalista. Este fato evidencia que a ferramenta provavelmente não informa continuamente o que o usuário está fazendo ou aonde ele está, a organização das informação não está de acordo com o modelo mental do usuário e não segue necessariamente uma ordem lógica. Além disso o sistema não se mostrou ser consistente em relação a apresentação da informação e na sua navegação. Tais problemas ameaçam o uso da ferramenta de forma eficiente e até mesmo eficaz, uma vez que o usuário gasta mais tempo procurando informações, tentando lembrar de como realizar atividades e descobrir se suas ações foram realizadas com sucesso ou não, por exemplo.

57 57 Apesar da necessidade de um layout mais atraente e do desenvolvimento de ícones mais adequados, este projeto focará na melhoria dos problemas relacionados a camada de design de informação e design de interação do (GARRETT, 2011) sistema. Para isso foram selecionados os problemas de usabilidade mais graves encontrados na avaliação heurística que estão destacados na Tabela 21. Tabela 21: Descrição dos problemas de usabilidade mais severos Violação Descrição O feedback das ações do usuário são quase imperceptíveis na parte superior esquerda da tela. Apesar de ser uma questão simples se ser resolvida a falta de feedback apropriado para as ações do usuário pode deixa-lo incerto sobre a execução correta das suas ações. O que pode resultar na repetição desnecessária de uma tarefa ou que uma atividade não seja corretamente executada caso o usuário não perceba o feedback informando o problema. O sistema não deixa claro quais ações podem ser feitas a partir da execução de uma atividade e a sua organização não possui uma ordem lógica que guie o usuário a realizar as atividades na devida ordem. Botões para adicionar e remover atividades ficam em posições muito distantes entre si. O sistema não deixa claro quais ações estão disponíveis para serem executadas. Por exemplo, não fica claro que para monitorar o cronograma é necessário estimar recursos humanos às atividades, criar papéis, o organograma, cadastrar os RH, e relacionar RH à papeis. O ícone para excluir itens está localizado no lado esquerdo da lista de itens e ícone para adicionar um novo item está no lado esquerdo da tela, isso pode aumentar o tempo de realização da tarefa uma vez que o usuário tende a procurar componentes relacionado na mesma região da tela. Ao adicionar uma atividade, os olhos do usuário estão sempre focados no último item adicionado, porém o botão para adicionar um novo item está posicionado no topo da lista.

58 58 A navegação entre diferentes níveis da hierarquia do sistema (empresa, projeto) varia de acordo com a tela atual. Quando o usuário está na visualizando um projeto ele deve clicar no link com nome da empresa na tabela de detalhes do projeto para acessar a empresa. Quando o usuário está visualizando uma atividade ele deve clicar no breadcrumb Visualizar projeto, fora da tabela de descrição da atividade, para acessar o projeto. A tabela de descrição contém o nome do projeto, mas ele não é um link. Essa inconsistência pode deixar o usuário sempre em dúvida de que forma proceder para navegar no sistema, isso demanda tempo já que o mesmo deve procurar qual o lugar deve clicar em cada situação. A forma de inserir um item EAP e uma atividade é diferente. No caso da EAP o botão de adicionar fica ao lado do botão de deletar. Também se pode ordenar os itens da lista, o que não é possível com as atividades. Essa inconsistência pode deixar o usuário sempre em dúvida de que forma proceder para navegar no sistema, isso demanda tempo já que o mesmo deve procurar qual o lugar deve clicar em cada situação além disso ele deve aprender a realizar duas atividades em vez de uma.

59 59 [Atividade] O formulário é dividido em duas partes, cada uma possui um botão de salvar, independente do botão a ser clicado as informações obrigatórias das duas abas devem ser preenchidas. Somente após clicar em Salvar o usuário descobre que deve completar os campos obrigatórios de ambas as partes do formulário, o que pode aumentar o tempo de execução da atividade. [Atividade] Formulário tem campos obrigatórios escondidos em outras abas. A aba Data possui um campo obrigatório, mas ao descrever a atividade está aba está em segundo plano. Essa falta de visibilidade pode fazer o usuário perder tempo procurando o campo que deve ser preenchido, mas que não está visível na tela.

60 60 Ao descrever a atividade o usuário tem que lembrar da sequência das atividades já definida no diagrama (ou o contrário). Tanto na atividade de descrever atividade e criar a rede do cronograma o usuário deve utilizar a mesma sequência de atividades, além dele ter que lembrar das informações de uma tela pra outra ele perde tempo realizando a mesma atividade duas vezes, pois uma vez que as atividades pai de uma atividade são definidas o diagrama poderia ser gerado automaticamente, ou vice-versa. Os dados do projeto são constantemente exibidos mesmo quando não são necessários. As atividades sendo executadas são exibidas na parte inferior da tela. Os dados do projeto ocupam um terço da tela, em função disso as atividades relacionadas ao projeto ficam na parte inferior da tela, ou abaixo, exigindo o uso do scroll. No exemplo a abaixo a atividade sendo realizada é Estimativas. [Estimar RH] São necessários muitos passos (trocar muitas vezes de tela) para realizar a tarefa. Considerando que a alocação de RH é realizada muitas vezes ao longo do projeto (para cada atividade) e provavelmente em

61 61 seguida, ela pode se tornar maçante e demorada desde que exige sem necessidade que o usuário selecione opções e abra novas telas. [Decompor atividade] As atividades são criadas na aba Planejamento, mas para preencher suas informações é necessário acessar as atividades em outro local, na Aba Atividades. A necessidade de mudar de aba não é evidente. Não é possível clicar na Atividade para acessar as suas informações e editá-las. O usuário pode ficar confuso sem saber como fazer para editar as atividades Teste de Usabilidade do dotproject+ versão Definição e Planejamento Para que seja possível comparar os resultados obtidos em ambas as formas de avaliação, os testes de usabilidade avaliam as mesmas atividades adotadas na

62 62 avaliação heurística. Durante o planejamento dos testes foram preparadas todas as ferramentas de apoio, incluindo (apêndice D): Script de introdução, Termo de consentimento livre e esclarecido e autorização para gravação, obtenção do certificado do Comitê de Ética em Pesquisa com Seres Humanos da UFSC, Roteiro para entrevista de background, questionário demográfico, questionário de satisfação, instrumento de coleta de dados e a lista de tarefas a serem realizadas nos testes. Os testes devem ocorrer no laboratório do GQS, ou no local de trabalho do participante. Operação Em um primeiro momento foi realizado um teste-piloto, com o objetivo de testar os equipamentos e avaliar os demais instrumentos do teste, em termos de corretude e clareza. Após o piloto, as devidas correções foram feitas no material. Em um segundo momento foram distribuídos convites para participar dos testes. Os convites foram enviados à pessoas que se sabia previamente que possuíam experiência com GP. Foram realizados 8 testes de usabilidade, que ocorreram em Setembro de 2014, no laboratório do GQS, no INE UFSC. Figura 19: Imagens capturadas ao longo dos testes de usabilidade Os equipamentos usados nos testes foram: um notebook Acer com sistema operacional Ubuntu, uma webcam e um script para sincronizar a imagem capturada da tela e a imagem da webcam.

63 63 A execução dos testes seguiu o seguinte roteiro: Dar as boas-vindas ao participante e faze-lo se sentir à vontade; Leitura do script de introdução; Apresentação e assinatura do termo de consentimento livre e esclarecido; Levantar as informações demográficas (solicitando o preenchimento de um questionário de background); Apresentar e entregar a lista com as tarefas ao participante (Apêndice 12); Participantes executam as tarefas (coletar dados em paralelo por exemplo via webcam/anotações do pesquisador) Aplicar o questionário de satisfação; Perguntar se o participante gostaria de fazer mais algum comentário sobre o sistema; Agradecer à colaboração do participante, ao realizar o teste Análise de Dados e Documentação Após a realização dos testes, foi feita a análise dos dados coletados.o perfil dos participantes dos testes está resumido na Tabela 22. Tabela 22: Perfil dos participantes dos testes de usabilidade Característica Idade Capacidades e limitações físicas Habilidades no uso do computador Formação profissional Motivação 100% tem entre 24 e 45 anos. Não possuem limitações físicas. Usuário Gerente de Projeto de Software Tem experiência no uso do computador, usando-o mais de 4 horas por dia. 87% possui formação em computação. Geralmente realizaram entre 40 e 80 horas de curso ou mais de 80 horas de curso de capacitação em GP. Um possui certificação PMI e outro Scrum Master. Acham que utilizar um software de apoio à GP ajuda muito no trabalho (75%) e às vezes se torna indispensável (25%). Dos oito participantes, quatro já conheciam o projeto dotproject+, sendo que um deles é expert no uso dessa ferramenta. Os resultados dos testes a usabilidade do dotproject+ versão foram: Eficácia: A Tabela 23 exibe a completude de cada uma das tarefas realizadas nos testes. A tarefa1 deveria ser executada na aba planejamento, somente dessa forma é possível definir o item da EAP a qual uma tarefa pertence, ainda assim, 7 usuários criaram as tarefas via o botão Nova Atividade. Alguns tentaram procurar a EAP, para derivar as atividades dentro dela, como não a encontraram facilmente na tela inicial do projeto, e viram o botão Nova Atividade, desistiram de encontrar a

64 64 EAP, utilizando a outra alternativa. Um usuário, após criar a tarefa pelo modo incorreto, percebeu o erro. Como ele já conhecia a ferramenta decidiu explorar as demais abas do projeto até que encontrou o local correto para derivar as atividades. A tarefa 2 obteve 100% de completude, os usuários não tinham dúvidas de que a edição da atividade deveria ser feita a partir da dela da atividade. Na tarefa 3 apenas três participantes que já conheciam a ferramenta tiveram êxito, os demais desistiram após não encontrar as estimativas na tela da atividade, ou concluíram que a tarefa estava completa após editar as datas de início e fim da atividade. Seis participantes concluíram a tarefa 4, porém somente 3 deles concluíram a tarefa do modo esperado (via planejamento), ainda assim, dentre eles, 2 tentaram inicialmente realiza-la a partir da tela da atividade. A tarefa 5 obteve um alto nível de completude por parte dos usuários, apesar de a maior parte deles ter gasto muito tempo para descobrir em que tela estava o VPR. Usuários 1-De forma errada via Nova Atividade Tabela 23: Completude das tarefas 1-De forma correta Tarefa Usuário 1 Sim Sim (via atividade) Sim Usuário 2 Sim Sim/mas procurou em atividade antes Usuário 3 Sim Sim (via atividade) Sim Usuário 4 Sim - - Sim - Sim Usuário 5 Sim Sim (via atividade) - Usuário 6 Sim Sim Sim Sim Sim/mas procurou em atividade antes Usuário 7 Sim Sim Usuário 8 - Sim Sim Sim Sim Sim Total 25% 100% 37% 75% 87% Sim Sim Eficácia :Em função de algumas das tarefas não terem sido completadas pela maioria dos participantes o uso do tempo de duração da tarefa como parâmetro para medir a eficiência da ferramenta ficou prejudicado e por isso foi descartado. Ainda assim foi observado que a realização das tarefas durou em média 15 minutos.

65 65 Satisfação: A análise das respostas do questionário SUS, revelou uma forte insatisfação dos usuários em relação a ferramenta. A pontuação média do dotproject+ foi 36,8, (segundo Bangor et al. (2009) considerado ser usabilidade pobre), com pequeno desvio padrão de 9,37. Problemas de usabilidade evidenciadas: Ao longo dos testes foram registrados os principais problemas enfrentados pelos usuários para realizar as tarefas. A lista de problemas encontrados pode ser vista na Tabela 24. Tabela 24: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade. Dificuldade Número de participantes Salvar formulário com campo obrigatório em branco. 8 Na aba planejamento, não percebeu que os botões de rádio eram 2 clicáveis. Dúvida sobre em qual botão Salvar deveria clicar. 3 Dificuldade em achar link para edição da atividade e nova alocação. 7 A lista de atividades na tela alocação de RH não parece clicável. 4 Tentou fazer as estimativas na Atividade. 5 Significado do ícone de lâmpada foi descoberto sem querer. 4 (todos q viram essa tela) A alocação parecia já ter sido feita (o nome sugerido estava em 2 verde). Procurou o VPR nas informações do projeto 4 Não associou a tarefa com a respectiva fase do projeto. 7(em pelo menos 1 tarefa) Em algum momento não sabia em que tela estava pois o título é 3 muito pequeno. Dúvida sobre como selecionar o RH na lista. 4 Além das dificuldades mencionadas na tabela acima foi percebido que no geral o usuários procuram botões para adicionar e editar no lado superior direito da tela. Porém, em algumas telas comandos como Editar, Nova Alocação ficam misturados com comandos de navegação, junto aos breadcrumbs, o que também aumentou o tempo de execução das tarefas Também houve certa confusão para identificar quais telas eram editáveis, pois algumas telas eram somente para leitura, e outras eram editáveis sem haver a necessidade de clicar no link Editar. Um dos usuários sugeriu que todas as telas já fossem editáveis.

66 66 O fato de vários componentes clicáveis se parecerem com texto (como a lista de atividades na rela RH e os processos na aba Planejamento) tomou mais tempo dos usuários, que por sua vez tentavam descobrir onde os comandos estavam. Em alguns casos, mesmo quando o cursor do mouse estava sobre o link, a sua aparência não mudava, o que reforçava a ideia de que o elemento era somente um texto. Essa situação impossibilitou que um usuário completasse uma das tarefas. Alguns textos usados na interface estavam escritos em inglês, quando isso acontecia em uma mensagem de feedback, normalmente ela era ignorada. Para algumas ações do usuário o feedback era exibido com fonte muito pequena no canto da tela, ou era inexistente, o que causava dúvida para o usuário se a tarefa tinha sido realizada com êxito ou não. Também foi observado que no geral as tarefas relacionadas à atividade, os usuários procuravam na tela da atividade (criação de atividade, edição, estimativas, alocação de RH) e o que era relacionado ao projeto os usuários procuravam no projeto (EAP, VPR), mesmo para alguns usuários que já conheciam a ferramenta. Como resultado disso 7 participantes realizaram a tarefa 1 criando uma nova atividade via o botão Nova Atividade na tela Atividades, 4 usuários fizeram/tentaram alocar o RH via atividade e somente 3 (que conheciam a ferramenta) fizeram pela aba planejamento. Além disso somente 3 usuários conseguiram realizar as estimativas na tarefa 3, os outros 5 ficaram procurando na tela da atividade. Também na tarefa 5, 3 participantes procuraram o VPR nas informações do projeto (mesmo um que já conhecia a ferramenta). Outros comentários Ao final de cada sessão de teste o participante era convidado a expor a sua opinião em relação ao dotproject+. Para 4 participantes a sequência das atividades na ferramenta não é exposta de forma lógica. A navegação não guia o usuário de uma tela para a outra, de forma que o usuário não sabe onde clicar na tela seguinte. Três participantes comentaram que o fato da aba Atividades, Fórum, Gantt, estar misturada com as abas de fases do projeto, o que não colaborou pra que eles percebessem o modelo conceitual da ferramenta (com a ideia de seguir as fases do projeto). Um dos participantes sugeriu que as abas iniciação e planejamento fossem as primeiras, pois ele considera que o que está em primeiro é mais importante. Outro participante sugeriu ainda que a aba

67 67 atividades ficasse dentro de uma das fases do projeto, como planejamento por exemplo. Ainda sobre a navegação foi criticado o fato de atributos que os usuários consideram pertencer às atividades serem alterados fora dela (como RH, estimativas, derivação de atividade etc.) e em janelas diferentes. A maior parte dos usuários acreditava que a as atividades estariam junto à EAP, alguns deles não acharam intuitiva a ideia de criar ambos separadamente. Outro fator que os usuários consideraram negativo foi a falta de consistência no posicionamento de controles, textos e títulos. Apesar de alguns participantes acharem que a aba Estimativas possui muitos campos, outros acharam positivo poder editar mais informações em uma mesma tela, pois isso evita a troca de tela e o salvamento constante das ações executadas. Apesar de algumas tarefas exigirem um número de passos maior que o necessário para completar a tarefa, o participantes no geral concordam que o tempo que levaram para completar as atividades é aceitável e além disso não difere muito dos tempos utilizando outras ferramentas de GP. Na primeira tela os participantes afirmaram que gostariam de ver as atividades em andamento, do dia e atrasadas / pessoa, bem como as tarefas em aberto (que não tem nenhum RH alocado), o gráfico de Gantt e até mesmo o valor agregado do projeto. Atendimento dos requisitos de usabilidade: A Tabela 25 apresenta os resultados em relação aos requisitos de usabilidade estabelecidos. Fica evidente que a ferramenta na versão não atende aos requisito definidos. Tabela 25: Resultado dos testes de usabilidade Eficácia Satisfação Requisitos de usabilidade No mínimo 90% dos usuários sem experiência devem conseguir realizar as tarefas. Atividade 1: Decompor atividade Atividade 2: Editar atividade Atividade 3: Realizar estimativas Atividade 4: Alocar recursos humanos Atividade 5: Monitorar cronograma A nova versão do sistema deve obter uma pontuação superior a 70 no SUS. Resultado da avaliação 25% completaram 100% completaram 37% completaram 75% completaram 87% completaram Média de 36,9 pontos

68 68 Ao final das avaliações foram encontrados 44 problemas de usabilidade via avaliação heurísticas e 12 dificuldades nos testes de usabilidade, sendo que metade delas não havia sido revelada na avaliação heurística. Foi observado que os problemas encontrados além de diminuírem a eficiência das tarefas em alguns casos (como A lista de atividades na tela alocação de RH não parece clicável ) impediram que o usuário completasse a tarefa Aplicação do KLM na versão O tempo estimado para a execução de cada uma das atividades na versão da ferramenta, por um usuário experiente pode ser visto na Tabela 26 e 27 (Os * indicam ações que devem ser repetidas ao realizar a tarefa pela segunda vez, em seguida). Tabela 26: Estimativa de tempo das atividades de 1 à 3 Atividade 1 Decompor atividade Tempo estimado (s) Atividade 2 Editar atividade Tempo estimado (s) Atividade 3: Estimativa atividade Pensa 1,2 Pensa 1,2 Pensa 1,2 Aponta 1,1 Aponta 1,1 Aponta 1,1 1 clique 1 clique 1 clique Projeto 0,2 Atividades 0,2 Estimativas 0,2 Pensa 1,2 *Pensa 1,2 Pensa 1,2 Aponta 1,1 *Aponta 1,1 Aponta 1,1 *1 clique 1 clique Nome Nome da 1 clique Projeto 0,2 atividade 0,2 Campo 0,2 Pensa 1,2 *Pensa 1,2 Pensa 1,2 Mouseteclado Aponta 1,1 *Aponta 1,1 0,4 1 clique *1 clique *Preenche Planejamento 0,2 Editar 0,2 campos Pensa 1,2 *Pensa 1,2 Pensa 1,2 Teclado - Aponta 1,1 *Apontar 1,1 mouse 0,4 1 clique *1 clique Derivações 0,2 Campo 0,2 *5 k Tabs 1 *Pensa 1,2 *Pensa 1,2 Pensa 1,2 *Mouse - *Aponta 1,1 teclado 0,4 Aponta 1,1 *1 clique *Preenche 1 clique Campo 0,2 campos Salvar 0,2 *Pensa 1,2 *Pensa 1,2 *Mouse para *Teclado - teclado 0,4 mão 0,4 *Preenche campos 0 *Pensa 1,2 *Pensa 1,2 *Aponta 1,1 *Teclado para *1 clique mouse 0,4 Salvar 0,2 Pensaverifica resultado 1,2 Tempo estimado (s)

69 69 Pensa 1,2 *Pensaverifica resultado 1,2 *Pensa - Nova tela*3 3,6 Aponta 1,1 1 clique Salvar 0,2 Pensaverifica resultado 1,2 *Pensa - Nova tela *5 6 Total 25,4 20,5 14,1 Total para 2 37,1 38,5 15,1 Total para ,7 182,5 59,1 Tabela 27: Estimativa de tempo das atividades de 4 à 6 Atividade 6: Atualizar status da atividade Atividade 4: Tempo Atividade 5: Tempo Alocar RH estimado (s) Ver VPR estimado (s) *Pensa 1,2 Pensa 1,2 *Pensa 1,2 *Aponta 1,1 Aponta 1,1 *Aponta 1,1 *1 clique 1 clique *1 clique Alocações 0,2 Monitoramento 0,2 Editar 0,2 *Pensa 1,2 Pensa 1,2 *Pensa 1,2 *Aponta 1,1 Aponta 1,1 *Aponta 1,1 *1 clique 1 clique Atividade 0,2 Cronograma 0,2 *1 clique Lista 0,2 Pensa- verifica *Pensa 1,2 resultado 1,2 *Pensa 1,2 *Aponta 1,1 Pensa - nova tela *1 1,2 *Aponta 1,1 *1 clique *1 clique Papel 0,2 Progresso 0,2 *Pensa 1,2 *Pensa 1,2 *Apontar 1,1 *Aponta 1,1 *1 clique *1 clique Editar 0,2 Salvar 0,2 *Pensa - *Pensa 1,2 Verifica 1,2 *Pensa - Nova tela 1,2 *Aponta 1,1 *1 clique RH 0,2 *Pensa 1,2 *Aponta 1,1 *1 clique Salvar 0,2 *Pensa (somente se repetir) 1,2 *Aponta 1,1 *1 clique Voltar 0,2 *Pensa- 1,2 Tempo estimado (s)

70 70 verifica resultado *Pensa - nova tela *4 6 Total 1: 24,7 7,4 11,2 Total para 2 46, ,6 Total para ,8 5.3 Desenvolvimento das Melhorias Com base nos resultados da análise, nesta sessão são propostas novas versões do design de interface para realizar as atividades sob análise neste projeto. Inicialmente é desenvolvido uma modelo conceitual, como as regras que guiam a relação entre as tarefas. Em seguida são desenvolvidos os protótipos da baixa fidelidade. As atividades desenvolvidas nesta sessão pertencem ao nível 1 da fase Projeto/Teste/Implementação no processo de engenharia de usabilidade de Mayhew (1999). Figura 20: Fase Projeto/Teste/Implementação Modelo Conceitual Modelo conceitual é a descrição do sistema em termos de ideias e conceitos sobre o que ele deve fazer, como deve se comportar e parecer, de modo que seja compreendido pelo usuário. Para desenvolver um modelo conceitual é necessário

71 71 definir qual o paradigma (desktop, mobile) e modelo de interação a ser usado (baseado em menus, falar, linha de comando) (PREECE et al., 2005). No caso do dotproject+ o paradigma é desktop, especificamente para web. Quanto ao modelo de interação ele possui interface gráfica, na qual os usuários interagem a partir de manipulação e navegação, exploração e busca. Durante o desenvolvimento do modelo conceitual também são definidas as funcionalidades do sistema, e de que forma elas serão divididas; como as atividades estão relacionadas entre si (de forma paralela, ou sequencial); quais as informações precisam estar disponíveis para realizar as atividades (PREECE et al, 2005; MAYHEW, 1999). Nesta sessão são explanadas as técnicas utilizadas e resultados obtidos para definir o modelo conceitual adotado na melhoria do dotproject Análise Hierárquica das Tarefas HTA e Diagrama de Navegação A partir do momento em que as atividades estão definidas (Sessão ) é necessário compreender de que forma elas se relacionam. Entender essa relação é importante, pois ela pode restringir as ações do usuário ou indicar uma alternativa melhor para estruturar a tarefa (PREECE et al., 2005). Por exemplo, se a tarefa B depende da tarefa A, ela pode ser desabilitada até que A seja terminada. Para analisar a relação entre as tarefas são utilizadas duas técnicas, a Análise da Hierarquia das Tarefas (HTA) e o desenvolvimento de Diagramas de Navegação (STANTON, 2002) e (HEUMANN, 2003). A HTA é uma técnica na qual as tarefas são quebradas em metas, planos e operações e são dispostas em uma estrutura hierárquica. Além da relação hierárquica das tarefas, essa técnica permite visualizar a sequência em que elas devem ser atendidas. Isso significa que para atingir uma das metas da hierarquia, as metas anteriores devem ser realizadas previamente (STANTON, 2002). Como nesta etapa o objetivo é verificar a ordem de precedência da execução das atividades esta sessão apresenta diagramas HTA mais abstratos, que exibem apenas as tarefas e não a forma como são executadas. Para diminuir a complexidade dos diagramas são exibidas apenas as tarefas quem devem obrigatoriamente preceder a tarefa sob análise. Os diagramas HTA podem ser vistos nas Figuras

72 72 Para todos os diagramas HTA é válido que: Se a empresa e o projeto estão criados, pode-se pular para o passo 3.Iniciação. Os passos 3.Iniciação e 4.Planejamento e Monitoramento podem ser feitos em paralelo. Figura 21: Hierarquia da atividade Decompor Atividades Figura 22:Hierarquia da atividade"sequenciar Atividades" Figura 23: Hierarquia da atividade "Estimar Tempo das Atividades

73 73 Figura 24: Hierarquia da atividade"alocar RH" Figura 25: Hierarquia da atividade "Monitorar Cronograma" Com base na hierarquia das tarefas foi desenvolvido o Diagrama de Navegação. Um diagrama de navegação é um modelo que representa todas as telas necessárias para realizar um caso de uso, suas conexões entre si e como o usuário pode navegar entre elas (HEUMANN, 2003). O design da navegação foi desenvolvido em acordo com Garrett (2011), de forma a permitir que o usuário a compreenda e consiga facilmente navegar de um ponto ao outro do sistema. A Figura 26 exibe o diagrama de navegação das telas do dotproject+ relacionadas com as atividades foco neste projeto destacadas em vermelho. Para todos os diagramas é válido que telas da mesma cor se acessam mutuamente com um clique.

74 74 Figura 26: Diagrama de Navegação Com base nestas informações foi definido o modelo do conteúdo das telas, no qual são estabelecidas as ferramentas e materiais necessários para a interação do usuário com as interfaces (CONSTANTINE e LOCKWOOD, 1999). Visando-se atingir as metas de usabilidade estipuladas, o conteúdo foi selecionado de forma a evitar redundâncias e a exibição de informações irrelevantes para a execução da tarefa. O conteúdo de cada uma das telas pode ser visto na Tabela 28. Tabela 28:Descrição do Conteúdo das Telas Tela inicial - gerente Tela Criar/editar Empresa Tela Empresa x Dotproject - versão Breadcrumbs Menu (Minha conta, Logout) Ajuda Calendário Empresa Lista de projetos Dotproject - versão Breadcrumbs Menu Ajuda Calendário Nome da empresa Formulário Botão Salvar Botão Cancelar Dotproject - versão Menu Ajuda Calendário Breadcrumbs Nome da empresa Dados da empresa Editar dados da empresa Deletar empresa Criar projeto Projetos RH Usuários Contatos Tela Projeto x Tela Detalhes do Projeto Tela Editar Projeto Dotproject - versão Breadcrumbs Menu Ajuda Calendário Nome do projeto Gerar relatórios Menu com opções: Atividades Iniciação Planejamento + Tela do Projeto x mais: Dados do projeto Editar dados do projeto Excluir projeto Tela detalhes do projeto mais: Formulário Botão Salvar Botão Cancelar Excluir projeto

75 75 Monitoramento Execução Encerramento Tela Atividade / Editar Atividade Tela Atividade mais: Formulário Botão Salvar Botão Cancelar Filtrar atividades por usuário Tela Execução Tela Projeto mais: Lista de atividades do usuário, com status editável. Tela Cronograma Tela do projeto mais: Gráfico Gantt Gráfico da análise do valor agregado Período dos índices Valor agregado, Valor planejado Variação do prazo Índice do desempenho do prazo Protótipos de Baixa Fidelidade Protótipos de baixa fidelidade permitem a interação com o produto imaginado para que se possa adquirir experiência sobre como usá-lo. A partir disso é possível discutir as ideias obtidas com os stakeholders, refletir sobre o design e escolher entre diferentes alternativas (PREECE et al., 2005). Nesta pesquisa, inicialmente os protótipos foram feitos em papel (Figura 27), com o objetivo de testar o posicionamento dos elementos definidos na sessão anterior. Figura 27: Protótipo de baixa fidelidade feito em papel

76 76 Em seguida as alternativas consideradas mais adequadas foram prototipadas com mais detalhes utilizando as ferramentas Pencil (Evoluts, 2012) e Photoshop (Adobe Systems, 2014). Figura 29: Pencil Figura 28: Photoshop Neste nível foram definidos os tipos dos componentes, por exemplo, se o campo de inserção de dados é textual ou uma lista de seleção, bem como foram adicionados rótulos e títulos. Foram definidas também as possíveis mensagens de erro e de feedback que o usuário pode receber ao navegar entre as telas. A seguir são apresentados os protótipos e os respectivos comentários sobre quando eles são exibidos, que tarefas é possível realizar e que telas é possível acessar a partir deles. Tela 1 Inicial Empresa É a tela inicial do gerente quando já existe uma empresa e projetos criados. Nela o gerente pode expandir detalhes da empresa clicando na seta para baixo (que leva para a Tela 8 - Empresa) e pode ir para a tela de um dos projetos, clicando no nome dele (Tela 2 projeto - planejamento). Onde está escrito Empresa X, deve aparecer o nome da empresa. Figura 30: Tela 1 Inicial / Empresa

77 77 Tela 2 Projeto Planejamento O projeto, após iniciado, sempre abre na opção do menu Planejamento e Monitoramento, onde o gerente realiza a maior parte das suas atividades. O ícone Relatório leva para a página onde são gerados os relatórios do projeto. O ícone Sequenciamento leva para a página onde as atividades são sequenciadas. Caso nenhuma atividade tenha sido criada, e o usuário clicar nesse ícone, deve ser exibida a Mensagem 1. A opção selecionada do menu deve estar em destaque (neste caso Planejamento e Monitoramento). O filtro permite selecionar as atividades de um determinado usuário. O conteúdo dos pacotes é retrátil. Duplo-clique sobre o pacote estende ou contrai as suas atividades e sub-pacotes. Duplo-clique na atividade expande os seus detalhes (similar a tela 6 - Editar Atividade, porém não é editável). Para ordenar as atividades dentro de um pacote usa-se as setas da coluna Ordem. Para criar uma nova atividade, editar ou excluir um pacote, clicar com o botão direito sobre o pacote (vai para a Tela 3 Menu EAP). Para editar, excluir, ver detalhes da atividade, clicar com o botão direito sobre a atividade (vai para Tela 4 Menu Atividade). Para ver os detalhes do projeto, clicar na seta para baixo ao lado do nome do projeto (Tela 7.1 Detalhes do Projeto. Para editar os dados do projeto, clicar no ícone de editar. Figura 31: Tela 2 - Projeto Planejamento

78 78 Tela 3 Menu EAP Para dar suporte aos processos de Criar EAP, pré-requisito para o processo Decompor atividades, Estimar a duração das tarefas e Estimar os recursos humanos (PMI,2013) é exibida a Tela 3. Clicar em Editar expande a linha da tabela (Tela 5 Editar EAP) Clicar em Excluir exibe a Mensagem 2. Se o usuário confirmar, o pacote é excluído. É exibida a Mensagem 3. Clicar em Dicionário leva para uma nova tela com o dicionário da EAP. Clicar Nova Atividade, adiciona uma nova linha no final do pacote (similar a Tela 6 editar atividade, mas com os campos em branco). Figura 32: Tela 3 Menu da EAP Tela 4 Menu Atividade Para dar suporte aos processos de Decompor atividades, Estimar a duração das tarefas e Estimar os recursos humanos (PMI, 2013) é exibida a Tela 4. Clicar em Editar expande a linha da tabela (Tela 6 Editar atividade) Clicar em Excluir exibe a Mensagem 2. Se o usuário confirmar, a atividade é excluída. É exibida a Mensagem 4. Clicar em Detalhes expande a linha exibindo os demais campos (similar a tela 6 Editar Atividade, porém não editável).

79 79 Figura 33: Tela 4 - Menu da Atividade Tela 5 Editar EAP Para dar suporte ao processo de Criar EAP, (PMI, 2013) é exibida a Tela 5. Clicar em Salvar exibe a Mensagem 4, fecha a expansão e altera os dados da atividade. Clicar em Cancelar exibe a Mensagem 5. Se o usuário confirmar o cancelamento a expansão é fechada e os dados da atividade não são alterados. Figura 34: Tela 5 - Editar EAP

80 80 Tela 6 Editar Atividade Clicar em Salvar exibe a Mensagem 4, fecha a expansão e altera os dados da atividade. Clicar em Cancelar exibe a Mensagem 5. Se o usuário confirmar o cancelamento a expansão é fechada e os dados da atividade não são alterados. Se mais papeis forem inseridos, a expansão fica mais longa e os novos campos são adicionados abaixo dos anteriores. Clicar na lista de RH exibe os recursos com o papel correspondente ao selecionado e após uma separação outros são exibidos os demais recursos. Se o usuário tentar alocar um RH, sem ter alocado um papel, é exibida a Mensagem 6. Se o usuário tentar alocar um papel, sem ter criado papeis, é exibida a Mensagem 6. Figura 35: Tela 6 - Editar Aividade Tela 7 Editar Projeto Após clicar em salvar é exibida a Mensagem 4. Fecha a expansão e altera os dados da atividade. Após clicar em cancelar é exibida a Mensagem 5. Se o usuário confirmar o cancelamento fecha a expansão e não altera os dados da atividade.

81 81 Figura 36: Tela 7 - Editar Projeto Tela 8 Tela inicial sem empresa/ Editar Empresa Ao logar pela primeira vez no dotproject+, quando nenhuma empresa ainda foi criada, o gerente é convidado a criar uma empresa, é exibida a tela 8.1 e a Mensagem: Crie uma empresa para começar a usar o dotproject+. Figura 37: Tela 8 Tela Inicial sem Empresa

82 82 Tela 9 Projeto Planejamento sem EAP Após criar o projeto a sua lista de EAP e atividades está inicialmente vazia. É exibida a tela 9 e a mensagem Clique com o botão direito para criar um item da EAP que convida o usuário a criar o primeiro item da EAP clicando com o botão direito. Figura 38: Tela 9 - Projeto sem EAP Tela 10 Projeto Planejamento EAP sem atividade Após criar s EAP, ainda não há atividades registradas. Para acompanhar o processo de Decompor as atividades (PMI,2013) é exibida a tela 11 e a mensagem Clique com o botão direito no Item da EAP para criar adicionar uma atividade. Figura 39: Tela 10 - Projeto - EAP sem Atividade Tela 11 - Monitoramento de Cronograma Para dar suporte ao processo Controlar Cronograma é apresentada a Tela 11. Nessa tela o gerente pode selecionar um período para o qual deseja ver o cronograma. Além disso são exibidos os índices do cronograma do projeto e o gráfico de Análise do Valor Agregado.

83 83 Figura 40: Tela 11 - Monitoramento do Cronograma Tela 12 Menu do Usuário No menu o usuário pode sair do sistema, acessar sua agenda e seus dados pessoais. Figura 41: Tela 12 - Menu

84 84 Tela 13 - Execução Essa tela exibe a lista de atividades do usuário. Figura 42: Tela 13 - Execução Tela 13.1 Editar Execução Para dar suporte ao processo Controlar Cronograma (PMI, 2013), é necessário atualizar os status das tarefas, conforme a tela Nessa tela o usuário pode alterar o status das suas atividades.

85 85 Figura 43: Tela 13.1 Editar Execução Também foram desenvolvidas as possíveis mensagens de erro e confirmação que o usuário pode encontrar durante a realização das atividades. -Caso o usuário clique no botão Sequenciar, sem ter criado atividades, é exibida a Mensagem 1: Por favor, crie as atividades antes de sequenciá-las.

86 86 Figura 44: Mensagem 1 -Se o usuário clicar no botão para excluir um item da EAP, pacote, atividade ou projeto, é exibida a Mensagem 2 correspondente: Você tem certeza de que quer excluir o Pacote (nome do pacote). Figura 45: Mensagem 2

87 87 -Após a exclusão de algum elemento, a ferramenta exibe a seguinte Mensagem 3: O Pacote (nome do pacote) foi excluído. Figura 46: Mensagem 3 -Se o usuário clicar em Salvar as alterações feitas em um item da EAP, pacote, atividade, projeto ou empresa é exibida a Mensagem 4 correspondente: A Atividade (nome da atividade) foi salva.

88 88 Figura 47: Mensagem 4 -Se o usuário clicar em Cancelar as alterações feitas em um item da EAP, pacote, atividade, projeto ou empresa é exibida a Mensagem 5: Você tem certeza que quer cancelar as alterações feitas na Atividade (nome da atividade)? Figura 48: Mensagem 5

89 89 -Se o usuário tentar alocar o RH sem selecionar o papel é exibida a Mensagem 6: Por favor, selecione o papel antes de alocar o RH. Figura 49: Mensagem 6 -Se o usuário tentar selecionar papéis sem ter criado os papéis da empresa é exibida a Mensagem 7: Por favor, crie os papéis da empresa antes de selecionar o papel.

90 90 Figura 50: Mensagem 7 -Se o usuário tentar alocar um RH sem ter cadastrado nenhum funcionário é exibida a Mensagem 8: Por favor, cadastre os funcionários da empresa antes de alocar um Recurso Humano. Figura 51: Mensagem 8

91 91 Após o desenvolvimento dos protótipos da nova versão pode-se observar que os problemas mais graves encontrados na avaliação da versão foram solucionados, conforme mostra a Tabela 29. Tabela 29: Problemas de usabilidade / Sugestão de melhoria Problema O feedback das ações do usuário são quase imperceptíveis na parte superior esquerda da tela. O sistema não deixa claro quais ações podem ser feitas a partir da execução de uma atividade e a sua organização não possui uma ordem lógica que guie o usuário a realizar as atividades na devida ordem. Botões para adicionar e remover atividades ficam em posições muito distantes entre si. A navegação entre diferentes níveis da hierarquia do sistema (empresa, projeto) varia de acordo com a tela atual. A forma de inserir um item EAP e uma atividade é diferente. [Atividade] O formulário é dividido em duas partes, cada uma possui um botão de salvar, independente do botão a ser clicado as informações obrigatórias das duas abas devem ser preenchidas. Os dados do projeto são constantemente exibidos mesmo quando não são necessários. As atividades sendo executadas são exibidas na parte inferior da tela. [Decompor atividade] As atividades são criadas na aba Planejamento, mas para preencher suas informações é necessário acessar as atividades em outro local, na Aba Atividades. [Atividade] Formulário tem campos obrigatórios escondidos em outras abas. Melhoria O feedback para as ações do usuário é exibido dentro de uma caixa de diálogo no centro da tela na parte superior. Foram inseridas dicas para guiar o usuário na realização da atividade pela primeira vez (por exemplo a mensagem Clique com o botão direito para adicionar uma atividade ). Além disso, quando uma atividade não está disponível para execução o sistema exibe uma mensagem dizendo o que o usuário deve fazer antes de realiza-la (por exemplo, antes de sequenciar o usuário deve criar as atividades). As opções do menu (abas) são dispostas seguindo uma ordem lógica, por exemplo a Iniciação deve ser feita antes da Execução. Na nova versão o usuário pode excluir ou adicionar uma atividade em um mesmo local. A navegação entre telas de diferentes níveis da hierarquia do sistema foi padronizada. A partir de cada tela do sistema é possível voltar para a anterior com apenas um clique. Na nova versão a forma de inserir itens na EAP e criar atividades é similar. Todas as informações inseridas pelo usuário em um formulário são confirmadas utilizando o mesmo botão de Salvar. Os dados do projeto foram reduzidos, eliminando informações desnecessárias, por default eles ficam escondidos, e podem ser exibidos quando o usuário desejar. A decomposição e o preenchimento das suas informações são feitos em uma mesma tela. Não há campos ou funcionalidades em partes da tela que não são visíveis ao usuário.

92 Implementação das Melhorias Para ser possível a comparação das interfaces de ambas as versões por meio de testes de usabilidade, as melhorias propostas para a versão 3.1 foram implementadas por um colaborador do GQS. Em seguida são apresentadas as principais telas desenvolvidas. A Figura 52 é o screenshot da tela Planejamento, implementação do protótipo representado pela Figura 33, Menu da Atividade. As principais diferenças entre as duas telas são a organização do menu, que na versão implementada foi representado por abas e disposto em uma posição mais baixa da tela. Além disso, não foi implementado o menu do usuário, com opção para visualizar dados do usuário, agenda e logout. Em função uma série de componentes continuaram espalhados pela parte superior da tela (ajuda, meus dados, hoje, etc.). Outra questão não contemplada na versão implementada são os breadcrumbs, para auxiliar a localização e navegação do usuário. Figura 52: Screenshot da tela de Planejamento A Figura 53 é a implementação da Figura 35, Editar Atividade. Foram implementadas todas as funcionalidades, faltando tratar o alinhamento dos campos na área de edição e dos dados do projeto.

93 93 Figura 53: Screenshot da tela de edição de uma atividade A Figura 54 é um screenshot do protótipo representado pela Figura 40, Monitoramento do Cronograma. Figura 54: Screenshot da tela Cronograma

94 94 6 Avaliação da Melhoria da Usabilidade Neste capítulo é apresentada a avaliação da melhoria da usabilidade por meio da comparação das medidas de usabilidade de ambas as versões do sistema dotproject. 6.1 Definição da avaliação O objetivo da comparação da versão da ferramenta dotproject+ com a versão 3.1 é verificar se a nova interface proposta de fato melhorou a usabilidade do sistema com respeito a eficácia, eficiência, e satisfação de uso do usuário. Se a hipótese for confirmada é verificado quais os elementos alterados na interface que geraram tal melhoria, com o intuito de identificar diretrizes de design para ferramentas de apoio a gerência de projetos. A usabilidade é comparada em termos da eficácia eficiência, e satisfação do usuário referente às seguintes tarefas: decompor atividade, estimar duração, controlar o cronograma e visualizar Gantt (representados pela atividade Encontrar VPR), alocar recursos humanos, acompanhar execução da atividade As medidas coletadas são: Eficácia: porcentagem dos usuários que conseguiram realizar as tarefas de forma completa. Eficiência: tempo estimado para realizar as atividades. Satisfação: pontuação no questionário SUS Para coletar as medidas são realizadas duas séries de testes de usabilidade, com a versão 2.1.7(descrito na sessão 5.2.3) e com a versão 1.3. Além disso é aplicada a técnica de predição de tempo KLM. 6.2 Execução da Avaliação Nesta sessão é descrito o processo de comparação das duas versões da ferramenta dotproject+. As medidas utilizadas na comparação das ferramentas são obtidas via execução de testes de usabilidade e aplicação da técnica KLM. A versão já foi avaliada por ambas as técnicas nas sessões e Em seguida são apresentados os resultados do testes de usabilidade e aplicação do KLM na versão 1.3.

95 Teste de Usabilidade da versão 1.3 do dotproject+ Os testes com a nova versão da ferramenta seguiram o mesmo processo e utilizaram os mesmos instrumentos da primeira sequência de testes Operação Os testes foram realizados de acordo com o mesmo roteiro utilizado na primeira rodada de testes (Apêndice D), bem como foi utilizado o mesmo notebook e webcam. Foram realizados 6 testes de usabilidade, que ocorreram em Outubro de 2014, no laboratório do GQS, no INE UFSC Análise e Documentação Após a realização dos testes, foi feita a análise dos dados coletados. O perfil dos participantes é exibido na Tabela 30. Tabela 30: Perfil dos participantes do teste de usabilidade 2 Característica Idade Capacidades e limitações físicas Habilidades no uso do computador Formação profissional Motivação Usuário Gerente de Projeto de Software 66% tem entre 24 e 45 anos e 34% tem entre anos. Não possuem limitações físicas. Tem experiência no uso do computador, usando-o mais de 4 horas por dia. 83% possui formação em computação. Geralmente realizaram entre 40 e 80 horas de curso ou mais de 80 horas de curso de capacitação em GP. Um possui certificação Scrum Master. Acham que utilizar um software de apoio à GP ajuda muito no trabalho (83%) e às vezes se torna indispensável (16%). Dos 6 participantes, dois já conheciam o projeto dotproject+, sendo que um deles é expert no uso da versão da ferramenta. Eficácia: A Tabela 31 abaixo exibe a completude de cada uma das tarefas realizadas nos testes.

96 96 Tabela 31: Completude das tarefas na versão proposta Tarefa Usuários Usuário 1 Não Sim Sim Sim Sim Usuário 2 Sim Sim Sim Sim Sim Usuário 3 Sim Sim Sim Sim Sim Usuário 4 Sim Sim Sim Sim Sim Usuário 5 Sim Sim Sim Sim Sim Usuário 6 Sim Sim Sim Sim Sim Total 83% 100% 100% 100% 100% Apesar de inicialmente os usuários passarem algum tempo procurando por um botão para adicionar uma nova atividade, a tarefa1 foi realizada com êxito por 5 dos 6 participantes. Após descobrir que o comando deve ser feito a partir do clique com o botão direito do mouse vários participantes elogiaram a solução que torna mais rápida a inserção e edição dos elemento na tabela. Um deles criou novos itens na EAP em vez de criar novas atividades, isso aconteceu pois o usuário, ao abrir o menu (após clicar com o botão direito do mouse) leu a primeira opção Novo Item e não leu as demais. As demais tarefas (2 à 4) obtiveram obtiveram 100% de completude. Após aprender a realizar a tarefa 1 os usuários não tiveram dúvidas sobre como realizar essas atividades. Os usuários que haviam testado a versão anterior elogiaram o fato de poder realizar todas as alterações relacionadas à atividade em uma mesma tela. A tarefa 5 também obteve 100% de completude por parte dos usuários. Um dos usuários inicialmente procurou o valor VPR juntamente aos dados do projeto, outro procurou na aba Execução por não encontrar a aba monitoramento (leu somente Planejamento). Os demais percorreram (e em algumas vezes abriram) outras abas até concluir que a informação procurada estava na aba Cronograma Eficiência: Foi observado que a realização das 5 tarefas levou em média 11,5 minutos. Satisfação: A análise das respostas do questionário SUS, revelou uma forte satisfação dos usuários em relação às tarefas realizadas na versão proposta da

97 97 ferramenta. A pontuação média do dotproject+ foi 77,9, (que Bangor et al. (2009) considera ser boa usabilidade), com pequeno desvio padrão de 11,97. Problemas de usabilidade observados: Ao longo dos testes foram registrados os principais problemas enfrentados pelos usuários para realizar as tarefas (Tabela 32). Nenhum dos problemas impediu a realização das tarefas. Tabela 32: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade 2. Dificuldade Encontrar o menu utilizando o clique com o botão direito do mouse Identificar em qual das abas deveria estar o VPR Dúvida sobre o que é considerado Item/Pacote/Atividade na tabela Planejamento Número de participantes No geral os participantes relataram satisfação quanto a possibilidade de realizar a EAP, derivar, editar e estimar tempo e recursos das atividades em uma mesma aba, sem a necessidade de navegar para outras telas. Os participantes concordaram que apesar de inicialmente perderem certo tempo até descobrir as funcionalidades sob o botão direito do mouse, após aprenderem esse comando, a realização das atividades que dependem dele ficou bem eficiente. Atendimento aos requisitos de usabilidade: Ao observar os dados da Tabela 33 pode-se afirmar que a nova versão atingiu os requisitos de usabilidade estabelecidos para satisfação e eficácia. Tabela 33: Resultado dos testes de usabilidade 2. Eficácia Satisfação Requisitos de usabilidade No mínimo 90% dos usuários sem experiência devem conseguir realizar as tarefas. Atividade 1: Decompor atividade Atividade 2: Editar atividade Atividade 3: Realizar estimativas Atividade 4: Alocar recursos humanos Atividade 5: Monitorar cronograma A nova versão do sistema deve obter uma pontuação superior a 70 no SUS. Resultado da avaliação 83%completaram 100% completaram 100% completaram 100% completaram 100% completaram Em média 77,9 pontos

98 Aplicação do KLM na versão 1.3 Foi aplicado o KLM para as mesmas tarefas realizadas nos testes de usabilidade, além do caso de uso Alterar o Status da Atividade. O processo de estimativa de tempo foi o mesmo usado para aplicar o KLM na versão da ferramenta. O tempo estimado para a execução de cada uma das atividades na nova versão da ferramenta, por um usuário experiente pode ser visto na Tabela 34 e 35 (Os * indicam ações que devem ser repetidas ao realizar a tarefa pela segunda vez, em seguida). Tabela 34: Estimativa de tempo das atividades de 1 à 3 Atividade 1 Decompor atividade Tempo estimado (s) Atividade 2 Editar atividade Tempo estimado (s) Atividade 3: Estimativa atividade Pensa 1,2 *Pensa 1,2 *Pensa 1,2 Aponta 1,1 *Aponta 1,1 *Aponta 1,1 1clique - *1 clique *1 clique Projeto 0,2 botão direito 0,2 botão direito 0,2 *1 clique *1 clique *Pensa 1,2 Editar 0,2 Editar 0,2 *Aponta 1,1 *Pensa 1,2 *Pensa 1,2 *1 clique botão direito 0,2 *Aponta 1,1 *Aponta 1,1 *1 clique Nova atividade 0,2 *1 clique no 1º campo 0,2 *1 clique no 1º campo 0,2 *Mão do *Mão do mouse para mouse p *Pensa 1,2 teclado 0,4 teclado 0,4 *Pensa 1,1 *Preenche campos *Preenche campos *1 clique 1º campo 0,2 *Pensa 1,2 *5 tabs 1 *Mão do mouse para *teclado -> teclado 0,4 mouse 0,4 *Pensa 1,2 *Preenche *Teclado -> campos *Pensa 1,2 mouse 0,4 *Pensa 1,2 *Aponta 1,1 Pensa 1,2 *Teclado para *1 clique mouse 0,4 Salvar 0,2 *Aponta 1,1 *Pensa 1,2 *Aponta 1,1 *1 clique Salvar 0,2 *Pensa - 1,2 *Pensa - verificar resultado 1,2 *1 clique Salvar 0,2 *Pensa - verificar resultado 1,2 Tempo estimado (s)

99 99 verificar resultado Total 1: 14,6 10,9 11,9 Total 2: 25,5 21,8 23,8 Total 10: 112, Tabela 35: Estimativa de tempo das atividades de 4 à 6 Atividade 4: Tempo Atividade 5: Tempo Alocar RH estimado (s) Ver VPR estimado (s) *Pensa 1,2 Pensa 1,2 Pensa 1,2 *Aponta 1,1 Aponta 1,1 Aponta 1,1 *1 clique 1 clique em 1 clique Botão direito 0,2 Monitoramento 0,2 Execução 0,2 Pensa - *1 clique verificar Editar 0,2 resultado 1,2 *Pensa 1,2 *Pensa 1,2 *Aponta 1,1 * 1 clique Lista 0,2 *Aponta 1,1 *1 clique no 1º campo 0,2 *Pensa 1,2 *Aponta 0,2 *Aponta 1,1 *1 clique no * 1 clique RH 0,2 Progresso 0,2 *Pensa 1,2 Pensa 1,2 *Aponta 1,1 Aponta 1,1 *1 clique Salvar 0,2 1 clique Salvar 0,2 *Pensa - verificar resultado 1,2 Pensa - verifica 1,2 Total 1: 9,3 4,9 11,2 Total para 2 18, ,2 Total para , Comparação da usabilidade dos designs de interface Nessa sessão são comparadas as medidas de eficiência, eficácia e satisfação do usuário dos designs de interface do dotproject e da versão 1.3. Eficácia: Em relação à eficácia pode ser observado, na Tabela 36, que em todas as atividades a nova versão da ferramenta obteve uma taxa de completude maior que a da versão (excetuando a atividade 2, para a qual ambas obtiveram 100%).

100 100 Tabela 36:Completude da atividade / versão da ferramenta Versão Completude da atividade 1 Completude da atividade 2 Completude da atividade 3 Completude da atividade 4 Completude da atividade 5 Versão Atual 25% 100% 37% 75% 87% Nova versão 83% 100% 100% 100% 100% Eficiência: A Tabela 37 abaixo exibe a comparação dos tempos estimados de execução das 6 atividades em ambas as versões do sistema: Tabela 37:Tempo de execução da atividade / versão da ferramenta Versão Atividade 1 Decompor atividade Atividade 2 Editar atividade Atividade 3: Estimativa atividade Atividade 4: Alocar RH Atividade 5: Ver VPR Atividade 6: Atualizar status da atividade 1 25,4 20,5 14,1 24,7 7,4 11,2 2 37,1 38,5 15,1 46, , ,7 182,5 59, ,8 1 14,6 10,9 11,9 9,3 4,9 11,2 2 25,5 21,8 23,8 18, , , ,2 Ao analisar os dados da tabela acima, nota-se que das 6 atividades, 5 são realizadas de forma mais rápida na nova versão do dotproject+. Satisfação: Em relação ao índice de satisfação da versão 1.3 do dotproject foi classificada como de boa usabilidade (média de pontos no SUS 77,9), enquanto a versão foi classificada como tendo usabilidade pobre, média de 36,8 pontos (ambas com desvio padrão pequeno de 11,97 e 9,37 respectivamente). Estes resultados revelam que a satisfação dos usuários em relação a nova versão aumentou mais do que duas vezes em relação a versão atual utilizada. que: Em relação ao tempo de execução de cada uma das atividades foi observado Atividade 1: um dos fatores que tornou essa atividade mais rápida na nova versão, é o fato de a tela para derivação das atividades ter sido colocada em um nível mais superficial na hierarquia de telas da ferramenta. Isso não acontece na

101 101 versão onde o usuário deve percorrer um número maior de telas até alcançar a função desejada. Atividade 2: Para editar cada uma das atividades na versão é necessário abrir uma nova tela de edição de atividade, além disso, como um dos campos obrigatórios fica em outra aba, é necessário carregar outra tela, o que totaliza a abertura de duas novas telas para editar cada atividade. Já na versão proposta todas as atividades podem ser editadas em uma única tela, o que torna esta versão mais eficiente. Atividade 3: Esta atividade foi a única que se mostrou mais eficiente na versão da ferramenta. Isso acontece porque o usuário poder estimar o tempo de todas as atividades e salvar as mudanças apenas uma vez ao final. A partir dessa constatação é levantada a possibilidade de utilizar a mesma ideia em uma nova versão da interface do dotproject. Implementando essa otimização os tempos para estimar a duração das atividades do projeto para uma, duas e dez atividades seriam respectivamente 11,9; 20,1; 85,7 segundos. Essa mudança também traria impacto para a atividade de Decompor Atividades, onde os tempos passariam a ser ainda mais eficientes 14,6; 21,8; 79,4 segundos. Atividade 4: Essa foi a atividade com maior ganho de eficiência em relação a versão 2.1.7, 2,6 vezes mais rápida. Novamente o ganho em eficiência se deve principalmente ao fato de a seleção do RH ser feita na mesma tela da lista de atividades, ao contrário da versão 2.1.7, na qual o usuário deve passar por 5 novas telas para completar a atividade. Atividade 5: Para esta atividade o tempo estimado de execução também foi reduzido. Para realizá-la na versão 1.3 da ferramenta (a partir da tela inicial do projeto), o usuário só precisa de um clique para acessar a tela de monitoramento do cronograma onde se encontra o VPR. Atividade 6: Apesar de o tempo estimado para uma realização da atividade ser o mesmo para ambas as versões, a partir da segunda execução em sequência, a versão 1.3 já se mostra ser mais eficiente, a diferença aumenta ainda mais quando se repete a atividade 10 vezes, quando ela passa a ser 2 vezes mais rápida. Se o usuário inserir as atividades na ferramenta quando já tiver estimado seu prazo e recursos, o tempo de execução das 4 primeiras tarefas (decompor atividade,

102 102 estimar tempo, estimar e alocar recursos humanos) pode ser ainda mais otimizado, resultando em um tempo total estimado de 23,98 segundos para inserir uma atividade e 206 segundos para inserir 10 atividades, enquanto que na versão o tempo permaneceria o mesmo, 82,2 para inserir uma atividade e 616,8 segundos para 10 atividades (soma dos tempos estimados para as 4 atividades na versão 1) Discussão da comparação da usabilidade dos designs de interface A comparação da usabilidade de ambas as versões do sistema revelou que a nova versão obteve melhores resultados em relação à eficácia, eficiência e satisfação, o que indica que ele possui melhor usabilidade que a versão da ferramenta. Com base na análise dos testes de usabilidade pode-se inferir determinadas melhorias implementadas que contribuíram para facilitar o uso da ferramenta. Notase que tais melhorias advém da correção de problemas de usabilidade encontrados na avaliação heurística e no teste de usabilidade da versão da ferramenta. Uma das melhorias se deu pela simplificação das atividades, por exemplo, pedindo que o usuário insira somente dados realmente necessários. Além disso, na nova versão são exibidas somente informações necessárias para realizar a tarefa, isso reduz a quantidade de informação nas telas, o que consequentemente permite que os usuários encontrem as informações que precisam mais facilmente, já que precisam scannear menos a tela. Outra preocupação no desenvolvimento das melhorias foi evitar a navegação desnecessária do usuário pela ferramenta, e a troca de telas quando não é necessário. Além de economizar tempo sem precisar esperar que a nova tela seja carregada o usuário não despende mais tempo para se localizar na nova tela. Outro ponto positivo na nova versão é que os controles para realizar as tarefas mais comuns estão mais próximos. De acordo com a Lei de Fitt o tempo de movimento do cursor está diretamente relacionado à distância e ao tamanho do alvo (Fitt, 1964), apesar de o KLM atribuir um tempo médio para o movimento do cursor, na prática esse tempo é menor para a nova versão da ferramenta onde os comandos não estão espalhados pela tela. Para editar uma atividade na versão antiga, por exemplo, o usuário deve clicar no ícone de lápis ao lado da atividade desejada e na nova tela que se abre ele deve clicar no link Editar atividade na parte superior da tela.

103 103 É importante ressaltar que nem todas as melhorias desenvolvidas foram implementadas na versão funcional utilizada nos testes de usabilidade, entre elas a retirada de componentes considerados desnecessários da parte superior da tela e a organização dos demais em um menu, que contribui para uma interface mais limpa, o formato das mensagens de feedback, que se mantiveram pequenas e sem destaque e a exibição das abas em forma de menu na parte superior da tela. Além disso, as setas que indicam expansão das linhas não mudam de direção para indicar se a linha já esta expandida ou não. É possível que com a implementação dessas melhorias o resultado dos testes de usabilidade e do questionário SUS fossem ainda mais positivos. Após a avaliação da nova versão foram identificados ainda alguns aspectos que devem ser melhorados na interface, como por exemplo, a possibilidade de editar várias atividades e salvá-las apenas uma vez no final (e não uma a uma). Outras mudanças não relacionadas com a arquitetura da informação, mas com a forma de apresentação do conteúdo também se mostraram relevantes ao longo dos testes, como o alinhamento e a coloração dos elementos da lista de atividades, que tornou difícil distinguir o que era item, pacote e atividade. Além disso, foi identificado que nesta nova versão era possível inserir um novo item EAP a partir de uma atividade, o que não deve acontecer, logo essa opção não deve ser exibida ao clicar com botão direito sobre uma atividade. 8 Discussão O uso de ferramentas de software para gerenciar projetos tem um impacto positivo significante como critério de sucesso dos projetos, logo torna-se fundamental a utilização de ferramentas de GP de qualidade. Apesar de a usabilidade ser considerada um dos principais atributos que determinam a qualidade de sistemas de software foi constatando que ainda há pouca pesquisa a respeito da usabilidade deste tipo de ferramenta. Ao longo deste trabalho foi possível comparar o uso de diferentes soluções de design para realizar diversas atividades típicas de ferramentas de GP. A partir dessa comparação foi possível identificar fatores que contribuem para o desenvolvimento/melhoria de ferramentas desse gênero com melhor usabilidade. Entre eles estão>

104 104 Exibir somente informações relacionadas/necessárias para realizar a tarefa. Ferramentas de GP no geral possuem uma quantidade extensa de conteúdo e funcionalidades. A exibição de conteúdo na tela, além do necessário para realizar a atividade, pode deixa-la poluída. Isso dificulta a localização de componentes necessários para realizar a tarefa atual. Deve ser fácil inserir e editar conteúdo (como atividades e recursos, por exemplo). As atividades de inserir e editar conteúdo são muito frequentes em uma ferramenta de GP, logo é essencial que o usuário consiga realiza-las de forma rápida, sem que lhe sejam exigidas muitas ações. Deve-se tentar realizar as atividades sem que seja necessário trocar de tela. A cada troca de tela o usuário gasta tempo para se localizar e encontrar o conteúdo que precisa para concluir a atividade em andamento, por isso, sempre que possível as atividades devem ser executadas em uma mesma tela. As mensagens de erro para o usuário devem deixar claro porque ele ocorreu e como corrigi-lo. Durante a execução de uma atividade é fundamental que o usuário compreenda porque certas ações não foram concluídas corretamente e que ele saiba como resolver o problema. Isso evita que o usuário despenda tempo tentando descobrir sozinho qual foi o problema e como resolve-lo. Conteúdo utilizado com mais frequência deve ser acessível. Foi reforçado ainda mais o princípio de que desde o momento que o usuário acessa a ferramenta ele deve conseguir acessar com facilidade os conteúdos usados mais frequentemente, sem ter que realizar muitas ações até alcança-los. Conteúdo pertinente às atividades do projeto deve ser exibido e editado nas respectivas atividades. Dado que os usuários tendem a inserir e editar conteúdo nas telas diretamente associadas a eles (por exemplo, os atributos da atividade (seja nome, tempo estimado de duração ou recurso, são procurados na atividade), os atributos da atividade devem ser inseridos e editados a partir dela e não em outros locais da ferramenta.

105 Ameaças à Validade Como em toda pesquisa podem existir ameaças à validade dos resultados. Com o objetivo de realizar uma revisão da literatura criteriosa foi seguido o processo proposto por Kitchenham (2004). Para prevenir a exclusão de qualquer trabalho importante para esta área foi construída uma string de busca a mais inclusiva possível. Apesar de terem sido solucionados uma série de problemas de usabilidade da versão há a possibilidade de ainda existirem problemas nas tarefas avaliadas, que não foram percebidos nem com a realização dos testes de usabilidade e nem com a avaliação heurística, e, portanto não foram corrigidos na versão 3.1. Apesar de os testes terem sido realizados com mais de 5 participantes (o que eleva a porcentagem de problemas encontrados para mais de 85%) (JEFF, 2010), não há garantia de encontrar 100% dos problemas. Situação similar ocorre com a avaliação heurística, realizada por um avaliador (NIELSEN, 1995). Essa ameaça também se mostra presente na avaliação da usabilidade da versão 3.1, que apesar de ser mais eficiente, eficaz e satisfatória que a versão anterior, ainda pode conter problemas não identificados nos testes. 9 Considerações Finais O objetivo do presente trabalho é melhorar, em termos da usabilidade, o design de interface de uma ferramenta de GP. Para isso foi analisada a fundamentação teórica em relação a GP e engenharia de usabilidade, bem como o estado da arte a respeito de estudos de usabilidade do dotproject e outras ferramentas de GP. Em um segundo momento foi realizado um estudo de caso no qual foi melhorada a usabilidade da interface do dotproject usando um processo sistemático de engenharia de usabilidade como estudo de caso. Foram analisados o contexto de uso, as tarefas e o perfil dos usuários da ferramenta. Foram selecionadas para melhoria todas as atividades relacionadas a cronograma. Com o objetivo de descobrir os problemas de usabilidade da versão do dotproject ele foi avaliado via testes de usabilidade e via avalição heurística. Em seguida foi desenvolvido o modelo conceitual para a versão proposta, que entre outras consistia do diagrama de navegação e dos protótipos de baixa fidelidade. Depois de implementadas as melhorias propostas a nova versão foi comparada com

106 106 a 2.1.7, em termos da sua usabilidade. As medidas comparadas foram eficácia eficiência, e satisfação do usuário ao utilizar a ferramenta. Os resultados são uma primeira indicação de que a versão 1.3 possui melhor usabilidade que a versão, inclusive atingindo os requisitos de usabilidade estipulados. Com base no resultados da comparação foram derivadas uma séries de fatores aos quais se atribui a vantagem da nova versão em detrimento da Acredita-se que a aplicação desses fatores em uma ferramenta do mesmo gênero sendo utilizada pelo mesmo perfil de usuários também deve obter resultados similares. Com este trabalho foi desenvolvida uma nova alternativa de design para uma ferramenta de GP com maior qualidade em termos de usabilidade. Como consequência, espera-se que a nova versão da ferramenta facilite o trabalho das equipes de GP, aumentando a sua eficácia, eficiência e satisfação na utilização das ferramentas, que por sua vez poderá contribuir para a obtenção de taxas maiores de sucesso em projetos que utilizem o dotproject. Como trabalhos futuros seria interessante a implementação das demais melhorias propostas nos protótipos de baixa fidelidade conforme mostra a Tabela 38: Tabela 38: Melhorias a serem implementadas na versão 3.1 Melhorias Tela Eliminação de componentes considerados desnecessários da parte superior da tela e organização dos demais em um menu. Adição dos breadcrumbs Modificar o formato das mensagens de feedback.

107 107 Disposição das abas em forma de menu na parte superior da tela. As setas que indicam expansão das linhas devem mudar de direção para indicar se a linha está expandida ou não. Alinhamento dos campos adequando dos campos dos formulários. A lista de RHs deve exibir primeiro os RHs que possuem o papel associado à tarefa. Além disso, seria fundamental realizar o mesmo processo de melhoria para as demais funcionalidades do dotproject+, com a preocupação de obter uma interface consistente. Outra questão de extrema importância para a boa usabilidade da ferramenta é o desenvolvimento de um layout mais agradável e convidativo ao usuário. Para melhorar a interface do dotproject foi adotado uma adaptação do ciclo de vida de engenharia de usabilidade (Mayhew, 1999), seguindo as fases de análise dos requisitos (levantando informações sobre o as tarefas, usuários e contexto de uso), implementação (na qual foram desenvolvidos e avaliados o modelo mental, os protótipos de baixa fidelidade e o protótipo funcional) e a instalação (na qual foram coletados os feedbacks dos usuários). Devido a constatada melhoria da usabilidade da versão 1.3 em relação à versão podese inferir que o uso desse método é eficaz para o desenvolvimento de interfaces com melhor usabilidade.