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: Tela inicial do survey no Limesurvey Figura 2: Etapas do processo de avaliação Fonte: (WOHLIN, 2000) Figura 3: Planejamento do Experimento. Adaptado de WOHLIN et al. (2000) Figura 4:Estrutura de usabilidade Fonte: ISO Figura 5: Ciclo de Vida de Engenharia de Usabilidade Fonte: MAYHEW, Figura 6: Grupos de Processos do Ciclo de Vida de Engenharia de Usabilidade. Fonte: PMI, Figura 7: Competência Gerais de um Gerente de Projetos. Fonte: PMI (2004) Figura 8: Tela inicial dotproject Figura 9: Arquitetura do DotProject Figura 10: Fase Análise de requisitos Figura 11: Atividades mais realizadas pelos gerentes de projeto Figura 12: Definir as atividades. Fonte: PMI, Figura 13 Sequenciar as atividades. Fonte: PMI, Figura 14 Estimar Recursos. Fonte: PMI, Figura 15 Estimar Duração. Fonte: PMI, Figura 16: Desenvolver cronograma. Fonte: PMI, Figura 17: Controlar o cronograma. Fonte: PMI, Figura 18: Fasse de Instalação 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: Pencil Figura 29: Photoshop Figura 30: Tela 1 Inicial / Empresa Figura 31: Tela 2 - Projeto Planejamento Figura 32: Mensagem Figura 33: Tela 3 Menu da EAP... 78

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

7 7 LISTA DE TABELAS Tabela 1: Códigos, Operadores e Tempos no KLM Tabela 2: Escala de Severidade (Nielsen, 1995) Tabela 3: Percentual de Completude das tarefas Tabela 4: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade Tabela 5: Resultado dos testes de usabilidade Tabela 6: Completude das tarefas na versão proposta Tabela 7: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade Tabela 8: Resultado dos testes de usabilidade Tabela 9:Completude da atividade / versão da ferramenta Tabela 10:Tempo de execução da atividade / versão da ferramenta Lista de Quadros Quadro 1: Processos por área de conhecimento. Fonte: PMI, Quadro 2: Módulos Core do DotProject Quadro 3: Módulos Addon do DotProject Quadro 4: Características da interface do Svet Quadro 5: Análise e Extração de Dados Quadro 6: Características dos Usuários Quadro 7: Identificação do grau de suporte oferecido pela ferramenta de software de GP dotproject Quadro 8: Características do processo de Definir as Atividades Quadro 9: Características da Atividade Estimar Duração Quadro 10: Características da ativade Monitoramento do Cronograma Quadro 11: Caso de uso 1: Decompor atividade Quadro 12: Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma Quadro 13: Caso de uso 3: Estimar Duração Quadro 14: Caso de uso 4: Controlar o Cronograma Quadro 15: Caso de uso 5: Visualizar Gantt Quadro 16: Caso de uso 6: Alocar Recursos Humanos Quadro 17: Caso de uso 7: Acompanhar Excecução de Atividade Quadro 18: Problemas de usabilidade encontrados via avaliação heurística Quadro 19: Descrição dos problemas de usabilidade mais severos Quadro 20: Perfil dos participantes dos testes de usabilidade... 63

8 8 Quadro 21: Estimativa de tempo das atividades de 1 à Quadro 22: Estimativa de tempo das atividades de 4 à Quadro 23: Descrição do Conteúdo das Telas Quadro 24: Problemas de usabilidade / Sugestão de melhoria Quadro 25: Perfil dos participantes do teste de usabilidade Quadro 26: Estimativa de tempo das atividades de 1 à Quadro 27: Estimativa de tempo das atividades de 4 à Quadro 28: Melhorias a serem implementadas na versão

9 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

10 10 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 auxiliá-las (GUEDES, 2003) (JESSEN, 2000). Tais ferramentas permitem a visualização do projeto de forma integrada, contemplando atividades, prazos, alocação de recursos, custos, entre outros, 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 (GONÇALVES 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; GONÇALVES, 2012). 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

11 11 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 de interfaces para este tipo de sistema torna-se necessário analisar quais são as características da

12 12 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 gerência 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 das versões e 1.3 do dotproject 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. A realizada a engenharia de usabilidade do dotproject é realizada pela autora. A implementação das melhorias propostas são implementadas por um colaborador 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

13 13 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.

14 14 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. Quanto 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: 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.1.2 Revisar a teoria sobre engenharia de usabilidade; A.1.3 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 ao 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;

15 15 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: 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.

16 16 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. 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 esteve disponível até o dia 22 de Novembro de 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;

17 17 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. 2) 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 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

18 18 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. Tabela 1: Códigos, Operadores e Tempos no KLM Código Operador Tempo(s) Digitador experiente 0.08 Digitador bom 0.12 K Apertar e soltar tecla do teclado 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 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 confirmala. - 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 Fonte: (WOHLIN, 2000)

19 19 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 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.

20 20 Figura 3: Planejamento do Experimento. Adaptado de WOHLIN et al. (2000) 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.

21 21 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 4, 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). Figura 4:Estrutura de usabilidade Fonte: ISO Requisitos Ergonômicos para Trabalho de Escritórios com Computadores Parte 11 Orientações sobre Usabilidade.

22 22 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 partida 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. 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

23 23 (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 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

24 24 autora sugere que alguns passos sejam omitidos 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 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.

25 25 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). O Quadro 1 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 Quadro 1: Processos por área de conhecimento. Fonte: PMI, 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.

26 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 aos 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 (GUEDES, 2003) (JESSEN, 2000). Para isso, as ferramentas devem reunir as informações

27 27 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, entre outros. 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 (GONÇALVES 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 (GONÇALVES, 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).

28 28 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 (Figura 8), 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; GONÇALVES, 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).

29 29 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: Quadro 2: 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 e 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 práticas,

30 30 principalmente o PMBOK (GONÇALVES, 2012). Entre os trabalhos desenvolvidos, é possível destacar o desenvolvimento de módulos addon exibidos no Quadro 3. Quadro 3: 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 4

31 31 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 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

32 32 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 (Quadro 4) do design que consideram positivas. Quadro 4: 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, para permitir um fácil monitoramento das atividades diárias. Possui uma estética unificada, intuitiva e um design de interface minimalista 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 funções estavam localizadas em lugar diferente do usado no pacote MS Office (FACHINE e ARAÚJO, 2010).

33 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 no Quadro 5. 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) DotProject 4.4 Discussão Quadro 5: Análise e Extração de Dados 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 estrangeira 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 importância, para aprimorar a usabilidade, e por consequência, a qualidade das ferramentas de GP.

34 34 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 Análise dos dados coletados Nesta sessão são analisados os dados coletados via survey. Ao final foram obtidas 28 respostas. 2 Esta pesquisa foi aprovada pela Comissão de Ética em Pesquisa Envolvendo Seres Humanos da UFSC - CEPSH, sob o número de parecer

35 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. O Quadro 6 mostras as características dos mesmos. Característica Idade média Capacidades e limitações físicas Habilidades no uso do computador Quadro 6: 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% utilizao mais de 4 horas por dia. Formação profissional 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. Experiência na tarefa Motivação 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 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

36 Quatidade de Votos 36 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). Figura 11: Atividades mais realizadas pelos gerentes de projeto 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 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 no Quadro 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

37 37 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. O Quadro 7 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 seguinte escala: não, manualmente de forma gráfica, manualmente de forma textual, automaticamente. Quadro 7: Identificação do grau de suporte oferecido pela ferramenta de software de GP dotproject Processo Planejar gerenciament o do cronograma Definir atividades Sequenciar as atividades Atividades/Técnic a São realizadas reuniões para planejar o cronograma do projeto. Definir atividades a partir dos pacotes de trabalho da EAP (Decomposição) Identificar dependências entre Automática Planejamento Ferramenta gera Suporte para registro/visualizaçã o das informações Gerente registra/visualiza as atividades Gerente registra/visualiza as atividades Gerente cria/visualiza a rede Suportada pelo dotproject+ Não Manualmente de forma textual Manualmente de forma gráfica

38 38 Estimar recursos Estimar duração Desenvolver cronograma Controlar o cronograma- 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) Otimizar cronograma (Compressão cronograma) do Ajustar cronograma (Ajuste antecipações atrasos) Acompanhar execução atividade de e 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 qual a cadeia crítica Ferramenta paraleliza o maior número de atividades possível. Monitoramento e controle de Ferramenta gera tabela com informação sobre as datas de início e fim das atividades e 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 Gerente registra alterações no cronograma Gerente registra alterações no cronograma Gerente visualiza o relatório Manualmente de forma textual. Manualmente de forma textual Manualmente de forma textual Não Não Não Manualmente de forma textual Sim

39 39 o seu status de progresso. 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, porcentage m 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. Automaticament e 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 Uma análise do Quadro 7 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 a) Descrição dos Processos e Atividades Relacionados à Tempo

40 40 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 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

41 41 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, Quadro 8: Frequência de uso Quadro 8: 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 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

42 42 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 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.

43 43 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.15. 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 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 Figura 15 Estimar Duração. Fonte: PMI, 2013 características do processo definir as atividades, Quadro 9: Frequência de uso Quadro 9: 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

44 44 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. 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. 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

45 45 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 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

46 46 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 abrilo). 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, Quadro 10: Frequência de uso Quadro 10: 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. b) 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.

47 47 Intenção do Usuário 1.Abre projeto 2.Clica na aba Planejamento 3.Seleciona botão de rádio Derivação Quadro 11: Caso de uso 1: Decompor atividade Responsabilida de do Sistema Projeto é aberto Aba planejamento é aberta A tabela Definição das Atividades é aberta Screenshoot 4. Clica no ícone de Lâmpada para adicionar mais uma atividade no pacote 5. Preenche o novo campo com o nome da atividade 6.Clica em salvar Fluxo alternativo 7. Clica no ícone de Lixeira ao lado da atividade Um novo campo é adicionado no pacote da EAP 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 Quadro 12: Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma Intenção do Usuário Responsabilida de do Sistema Screenshoot 1.Abre projeto 2.Clica na aba Planejamento 3.Seleciona botão de rádio Sequenciament o 4. Ordena as atividade, arrastando-as Projeto é aberto Aba planejamento é aberta A janela Método do Diagrama de Sequenciamento é aberta

48 48 para a posição desejada. 5. Conecta as atividades 6. Clica no botão Salvar O diagrama é salvo Caso de uso 3: Duração das atividades foram estimadas. Pré-condições: Criar organograma, criar papéis, criar atividades. Intenção do Usuário 1.Abre projeto 2.Clica na aba Planejamento Quadro 13: Caso de uso 3: Estimar Duração Responsabilida Screenshoot de do Sistema Projeto é aberto Aba planejamento aberta é 3.Seleciona botão de rádio Estimativas 4. Preenche campos para cada atividade: -Esforço -Data início/fim -Seleciona papéis -Tamanho /métrica do esforço 5. Clica no botão Salvar Estimativas Fluxo Alternativo 4.a Clica no botão + para adicionar um papel 4.b Clica no botão x para excluir um papel A janela Atas e Estimativas são abertas As Estimativas são salvas Caso de uso 4:Controlar o cronograma:

49 49 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 ma Quadro 14: 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 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 Quadro 15: 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 Quadro 16: Caso de uso 6: Alocar Recursos Humanos Responsabilidade Screenshoot do Sistema Projeto é aberto Aba Planejamento é aberta

50 50 Planejame nto 3. Clica em Alocações Aba Alocação de pessoas a papeis é aberta. 4.Clica sobre a atividade a ser editada Tela Alocação é aberta 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.

51 51 8.Clica no botão Submeter Alocação é salva. Tela Alocação de Recursos é aberta. Fluxo Alternativo 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 Quadro 17: Caso de uso 7: Acompanhar Excecução de Atividade Responsabilida de do Sistema Projeto é aberto Screenshoot 2.Clica na aba Execução 3. Clica em Acompanha mento da execução das atividades do projeto Aba Execução é aberta A tabela Acompanhament o da execução das atividades do projeto é aberta.

52 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. 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).

53 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 à 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) 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,

54 54 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 2: 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 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 no Quadro 18. Quadro 18: 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. 2 Médio 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 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 2 Baixo

55 55 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. 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. 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. 2 Baixo 2 Baixo 2 Médio 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. 4 Médio 2 Médio 2 Baixo 1 Baixo 2 Baixo 2 Baixo 3 Baixo

56 56 [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 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. [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. 3 Médio 3 Alto 3 Alto 4 Médio 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

57 57 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 onde 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. 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 sistema (GARRETT, 2011). Para isso foram selecionados os problemas de usabilidade mais graves encontrados na avaliação heurística que estão destacados no Quadro 19. Quadro 19: 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 em dúvida 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. 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.

58 58 Botões para adicionar e remover atividades ficam em posições muito distantes entre si. 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. 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 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 teste 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 fazê-lo sentir-se à 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 no Quadro 20. Quadro 20: Perfil dos participantes dos testes de usabilidade Característica Idade Capacidades e limitações físicas Habilidades no uso do computador Formação profissional 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. Motivação 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 3 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 EAP,

64 64 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 tela 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 3: Percentual de 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 4. Tabela 4: 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 verde). 2 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 é muito 3 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. 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

66 66 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 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

67 67 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 por 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 5 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 5: 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 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

68 68 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 nos Quadros 21 e 22 (Os * indicam ações que devem ser repetidas ao realizar a tarefa pela segunda vez, em seguida). Quadro 21: 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 Campo 0,2 *Preenche campos 1 clique Salvar 0,2 *Pensa 1,2 *Pensa 1,2 *Mouse para teclado 0,4 *Teclado -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 Quadro 22: 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 Tempo estimado (s)

70 70 *1 clique Voltar 0,2 *Pensaverifica resultado 1,2 *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 Figura 20: Fase Projeto/Teste/Implementação 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) 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

71 71 compreendido pelo usuário. Para desenvolver um modelo conceitual é necessário 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 a)) é 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 são acessadas 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 no Quadro 23. Quadro 23: 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 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 Planejamento + 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. Em seguida as alternativas consideradas mais adequadas foram- prototipadas Figura 27: Protótipo de baixa fidelidade feito em papel com mais detalhes utilizando as ferramentas Pencil (Evoluts, 2012) e Photoshop (Adobe Systems, 2014).

76 76 Figura 28: Pencil Figura 29: 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 Figura 32: Mensagem 1 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 33: Tela 3 Menu da EAP Figura 34: Mensagem 2

79 79 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). Figura 35: 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.

80 80 Figura 36: Tela 5 - Editar EAP 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. 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. Se o usuário tentar cadastrar um RH, sem ter cadastrado algum funcionário antes, é exibida a mensagem 8.

81 81 Figura 37: 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. Se o usuário tentar alocar o RH sem selecionar o papel é exibida a Mensagem 6. Figura 38: Mensagem 4 Figura 39: Mensagem 5 Figura 40: Mensagem 6 Figura 41: Mensagem 7 Figura 42: Mensagem 8

82 82 Figura 43: 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 44: Tela 8 Tela Inicial sem Empresa

83 83 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 45: 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 46: 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.

84 84 Figura 47: 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 48: Tela 12 - Menu Tela 13 - Execução Essa tela exibe a lista de atividades do usuário.

85 85 Figura 49: 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.

86 86 Figura 50: Tela 13.1 Editar Execução 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 o Quadro 24. Quadro 24: Problemas de usabilidade / Sugestão de melhoria Problema Melhoria 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. 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.

87 87 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. 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. 5.4 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 1.3 foram implementadas por um colaborador do GQS. Em seguida são apresentadas as principais telas desenvolvidas. A Figura 51 é 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.

88 88 Figura 51: Screenshot da tela de Planejamento A Figura 52 é a implementação da Figura 37, Editar Atividade. Foram implementadas todas as funcionalidades, faltando tratar o alinhamento dos campos na área de edição e dos dados do projeto. Figura 52: Screenshot da tela de edição de uma atividade A Figura 53 é um screenshot do protótipo representado pela Figura 40, Monitoramento do Cronograma.

89 Figura 53: Screenshot da tela Cronograma 89

90 90 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 1.3 é 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.

91 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 no Quadro 25. Característica Idade Capacidades e limitações físicas Habilidades no uso do computador Formação profissional Motivação Quadro 25: Perfil dos participantes do teste de usabilidade 2 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 6 abaixo exibe a completude de cada uma das tarefas realizadas nos testes.

92 92 Tabela 6: 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

93 93 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 7). Nenhum dos problemas impediu a realização das tarefas. Tabela 7: 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 Número de participantes Identificar em qual das abas deveria estar o VPR 3 Dúvida sobre o que é considerado Item/Pacote/Atividade na tabela Planejamento 6 2 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 8 pode-se afirmar que a nova versão atingiu os requisitos de usabilidade estabelecidos para satisfação e eficácia. Tabela 8: 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

94 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 nos Quadros 26 e 27 (Os * indicam ações que devem ser repetidas ao realizar a tarefa pela segunda vez, em seguida). Quadro 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 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 *Pensa - verificar resultado 1,2 *1 clique Salvar 0,2 *Pensa - verificar resultado 1,2 *Aponta 1,1 *1 clique Salvar 0,2 *Pensa - verificar resultado 1,2 Total 1: 14,6 10,9 11,9 Tempo estimado (s)

95 95 Total 2: 25,5 21,8 23,8 Total 10: 112, Quadro 27: Estimativa de tempo das atividades de 4 à 6 Atividade 4: Alocar RH Tempo estimado (s) Atividade 5: Ver VPR Tempo 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 *1 clique Pensa - verificar Editar 0,2 resultado 1,2 *Pensa 1,2 *Pensa 1,2 *Aponta 1,1 * 1 clique *Aponta 1,1 Lista 0,2 *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 9, 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%).

96 96 Tabela 9: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 10 abaixo exibe a comparação dos tempos estimados de execução das 6 atividades em ambas as versões do sistema: Tabela 10: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 versão

97 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 pode 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,

98 98 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). 7 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 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. É importante ressaltar que nem todas as melhorias desenvolvidas foram implementadas na versão funcional utilizada nos testes de usabilidade, entre elas a

99 99 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:

100 100 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. 8.1 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

101 101 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 1.3. 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 1.3, 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 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.

102 102 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 o Quadro. Quadro 28: Melhorias a serem implementadas na versão 1.3 Tela Melhorias 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. Disposição das abas em forma de menu na parte superior da tela.

103 103 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 pode-se inferir que o uso desse método é eficaz para o desenvolvimento de interfaces com melhor usabilidade.

104 104 REFERÊNCIAS ADOBE SYSTEMS, Adobe Photoshop CC. Disponível em: Acesso em: 14 out AGUIAR, Y. et al. Uso de Protótipos no Processo de Concepção de Interfaces do Usuário. Anais do II Congresso de Pesquisa e Inovação da Rede Norte Nordeste de Educação Tecnológica: João Pessoa, Brasil, BANGOR, A., KORTUM, P., & MILLER, J. Determining What Individual SUS Scores Mean: Adding an Adjective Rating Scale. Journal of Usability Studies, v.4, n.3, p BOZHIKOVA, V.; STOEVA, M. e TSONEV, K. A practical approach for software project management. Anais da International Conference on Computer Systems and Technologies (CompSysTech):Ruse, Bulgária, BUTTON, G. e DOURISH, P. Technomethodology: Paradoxes and Possibilities. Anais da Conference on Human Factors in Computing Systems (CHI): Vancouver, Canadá, CHIN, G., Jr.; ROSSON, M.B., e CARROL, J. Participatory Analysis: Shared Development of Requiriments from Scenarios. Anais da Conference on Human Factors in Computing Systems (CHI): Atlanta, Estados Unidos, CARD, Stuart K.; MORAN, Thomas P.; NEWELL, Allen. The Psychology of Human Computer Interaction. Mahwah: Lawrence Erlbaum Associates Inc, p CASEY SOFTWARE LLC. Improving the dotproject User Interface. Disponível em: < Acesso em: 29 abr CONSTANTINE, L.L., e LOCKWOOD, L.A.D. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Desing. Reading, MA: Addison-Wesley, p. CYBIS, W.A; BETIOL, A.H. e FAUST, R. Ergonomia e Usabilidade Conhecimentos, Métodos e Aplicações. São Paulo: Novatec Editora, p. DESKAWAY. Disponível em: Acesso em: 16 maio DOTPROJECT BRASIL, Disponível em: < Acesso em: 15 Abr EVOLUTS, Disponível em: < >. Acesso em: 07 Out FACHINE, B.D. e ARAÚJO, C. de. Softwares de Gerenciamento de Projeto: Uma Avaliação da Usabilidade. Anais do Encontro Nacional de Engenharia de Produção (ENEGEP): São Carlos, Brasil, 2010.

105 105 FITTS, P. M., PETERSON, J. R. Information capacity of discrete motor responses" Journal of Experimental Psychology,v. 67,n.2, p GARRETT, J. J Os Elementos da Experiência do Usuário. Disponível em: Acesso em: 12 Jun GANTTPROJECT Disponível em: Acesso em: 16 maio GERHARDT, T. E. e SILVEIRA, D. T. (Org.). Métodos de Pesquisa. Porto Alegre: Editora da UFRGS, p. GRESSE VON WANGENHEIM, C.; HAUCK, J. C. R.; VON WANGENHEIM, A. Enhancing Open Source Software in Alignment with CMMI-DEV. IEEE Software, vol. 26, no. 2, March/April GRESSE VON WANGENHEIM, C.; FERNANDES, L.S., PACHECO, A. P., HAUCK, J. C. R. Uma avaliação da interface de usuário de uma ferramenta Open Source de Gerenciamento de Projetos Baseado na Web, Anais do Congresso Brasileiro de Pesquisa e Desenvolvimento em Design: São Paulo, Brasil, GONÇALVES, R. Q. Planejamento de Tempo em Projetos de Desenvolvimento de Software para Micro e Pequenas Empresas Alinhado ao PMBOK e CMMI f. Dissertação (Mestrado) - Universidade Federal de Santa Catarina (UFSC), Florianópolis, Brasil, GOVERNO FEDERAL. Guia Livre: Referência de Migração para Software Livre do Governo Federal. Relatório Técnico, Governo Federal, Brasília: , 297p. GUEDES, A. D. e GUADAGNIN, R. V. A Gestão de Projetos como Aprimoramento da Terceirização. Informática Pública, Belo Horizonte, v. 5, n. 1, p.65-78, 01 jun HARTSON, H.R. e HIX, D. Toward empirically derived methodologies and tools for humancomputer interface development. International Journal of Man-Machine Studies, v.31, no.4 p HEUMANN, J User experience storyboards: Building better UIs with RUP, UML, and use cases. Disponível em: Acesso em 08 Set ISO Requisitos Ergonômicos para Trabalho de Escritórios com Computadores Parte 11 Orientações sobre Usabilidade, ISO Requisitos Ergonômicos para Trabalho de Escritórios com Computadores Parte 210 Design Centrado no Usuário para Sistemas Interativos, 2010.

106 106 JESSEN, S.A. The impact on Project Success of Using Technology in Modern Project Planning and Control. Anais da Technology Management Conference (ITMC), 2011 IEEE International, p , jun JUGDEV, K.; e MATHUR, G; FUNG, T. Project Management Assets and Project Management Performance: Preliminary Findings. Anais da Technology Management in the Energy Smart World (PICMET): Athabasca, Canadá, KIERAS, D.E. Using the keystroke-level model to estimate execution times. Michigan: University of Michigan, KOOHANG, A. Expanding the Concept of Usability. Informing Science Journal, Santa Rosa, p LABUTIL. ErgoList Disponível em: Acesso em 12 de Jun LANDAY, J. A. e MYERS, B. A. Interactive Sketching for the Early Stages of User Interface Design. Anais da Conference on HumanFactors in Computing Systems (SIGCHI), Denver, Estados Unidos, LIMESURVEY. Disponível em: Acesso em 12 de set MAYHEW, D.J. The Usability Engineering Lifecycle: A Practitioner s Handbook for User Interface Design. Massachusetts: Morgan Kaufmann, p. MARGEA, R. e MARGEA, C. Disponível em: %20Margea,%20Margea.pdf. Acesso em 23 de ago MICROSOFT Project. Disponível em: Acesso em 31 Out NIELSEN, J. e LORANGER, H. Usabilidade na Web: Projetando Websites com Qualidade. São Paulo: Elsevier Brasil, p. NIELSEN, J. Usability Engineering, Nova York: Academic Press Inc, p. NIELSEN, J Severity Ratings for Usability Problems. Disponível em: Acesso em: 12 Jun NIELSEN, J How to Conduct Heuristic Evaluation. Disponível em: Acesso em: 23 Set ORACLE Primavera Enterprise Project Portfolio Management. Disponível em: Acesso em 31 Out

107 107 PASCHOARELLI, L.C. e SILVA, J.C.P. Design Ergonômico: Uma Revisão de Seus Aspectos Metodológicos. Conexão Comunicação e Cultura. Caxias Do Sul: UCS, v. 5, n. 10, p jul Patterson D. Taming an Unruly Schedule Using a 14 Point Schedule Assessment. Acumen Project Confidence, PEREIRA, A. M.; GOLÇALVEZ, R. Q.; GRESSE VON WANGENHEIM, C. ; Buglione, Luigi. Comparison of Open Source Tools for Project Management. International Journal of Software Engineering and Knowledge Engineering, v. 23 no.2, p , PREECE, J.; ROGERS, Y.; SHARP, H. Design de interação: Além da interação humanocomputador. Porto Alegre: Bookman, p. PROJECT MANAGEMENT INSTITUTE - PMI (USA). A Guide to the Project Management Body of Knowledge. 4. ed. Pennsylvania: Project Management Institute, p. PROJECT MANAGEMENT INSTITUTE - PMI (USA). A Guide to the Project Management Body of Knowledge. 5. ed. Pennsylvania: Project Management Institute, p. PROJECT MANAGEMENT INSTITUTE BRASIL, Inc. Benchmarking GP Rio de Janeiro. v. 7, RAYMOND, L. e BERGERON, F. Project management information systems: An empirical study of their impact on project managers and project success. International Journal of Project Management, vol.2, nº1. Nova York, p REDMINE Redmine. Disponível em: Acesso em: 31 Out RUDD, J.; STERN, K. e ISENSEE, S. Low vs. High-fidelity Prototyping Debate. Interactions. Vol.3, no. 1, SAURO, J Why You Only Need To Test With Five Users (Explained). Disponível em: Acesso em: 01 Nov SCAPIN, D.L.; LEULIER, C.; BASTIEN, C.; VANDERDONCKT, J.; MARIAGE, C.; FARENC, C.; PALANQUE, P. e BASTIDE, R. (2000) A Framework for Organizing Web Usability Guidelines. Anais da Conference on Human Factors and the Web: Austin, Texas, EUA, SEBRAE, SERVIÇO BRASILEIRO DE APOIO ÀS MICRO E PEQUENAS EMPRESAS (Brasil). Fatores Condicionantes e Taxas de Sobrevivência e Mortalidade das Micro e Pequenas Empresas no Brasil Disponível em: < 9736CB CBAD3>. Acesso em: 21 maio SOFT LTD Rational Plan. Disponível em: Acesso em 21 Out

108 108 SOFTEX. Software e Serviços de TI: A Indústria Brasileira em Perspectiva Resumo Executivo Disponível em: < documentostecnicos/download/resumoexecutivo.pdf?file_id= >. Acesso em: 21 de maio STANTON, N. A., YOUNG, M. Ergonomic methods in consumer product design and evaluation. In N.A. Stanton, N. A., YOUNG, M. Human factors in consumer products. London: Taylor & Francis, 1997, p VARGAS, R. V. Gerencia de projetos: estabelecendo diferenciais competitivos. 6. ed. Rio de Janeiro: Brasport, VIÉGAS, D. dotproject: Gerenciamento de Projetos em Software Livre. Brasília, Xerox Corporation Heuristic Evaluation a Systems Checklist. Disponível em: Acesso em: 12 Jun W3SCHOOLS. a2014. OS Platform Statistics. Disponível em: Acesso em 08 Set W3SCHOOLS. b2014. Browser Statistics. Disponível em: Acesso em 08 Set WOHLIN, C.; HÖST, M.; OHLSSON, M.C.; REGNELL, B.; RUNESON, P. e WESSLÉN. Experiment. Process Illustration. A Experimentation in Software Engineering an Introduction. Dordrecht: Kluwer Academic, 2000.

109 Apêndice A Termo de Consentimento Livre e Esclarecido Você está sendo convidado(a) a preencher um questionário que tem como objetivo levantar dados sobre o perfil dos gerentes de projetos de software e das principais atividades desempenhadas por eles usando ferramentas de software no dia a dia. O questionário faz parte do Trabalho de Conclusão de Curso Melhoria da Interface da Ferramenta de Gerência de Projetos DotProject desenvolvido pela aluna Thaisa C. Lacerda e orientado pela professora Christiane Gresse von Wangenheim no GQS Grupo de Qualidade de Software do INCoD Instituto Nacional de Convergência Digital no Departamento de Informática e Estatística da UFSC. Todos os seus dados serão mantidos confidenciais e serão utilizados somente para os fins da pesquisa, mantendo sempre o seu nome em sigilo. Você pode se recusar a participar do estudo, ou retirar seu consentimento a qualquer momento, sem precisar justificar. Se você estiver de acordo com esse termo, nós gostaríamos que você preenchesse este questionário, o que deve durar não mais do 5-10 minutos. Qualquer dúvida, por favor, entre em contato: Thaisa Cardoso Lacerda (thaisa@incod.ufsc.br (48) ). GQS Grupo de Qualidade de Software INCoD Instituto Nacional de Convergencia Digital INE - Departamento de Informática e Estatística UFSC - Universidade Federal de Santa Catarina.

110 Apêndice B Caro Gerente de Projetos, de Convite para o Survey Você está sendo convidado(a) a preencher um questionário que tem como objetivo levantar dados sobre o perfil dos gerentes de projetos de software e das principais atividades desempenhadas por eles usando ferramentas de software. O questionário faz parte do Trabalho de Conclusão de Curso Melhoria da Interface da Ferramenta de Gerência de Projetos DotProject desenvolvido pela aluna Thaisa C. Lacerda e orientado pela professora Christiane Gresse von Wangenheim no GQS Grupo de Qualidade de Software do INCoD Instituto Nacional de Convergência Digital no Departamento de Informática e Estatísca da UFSC. Todos os seus dados serão mantidos confidenciais e serão utilizados somente para os fins da pesquisa, mantendo sempre o seu nome em sigilo. Se você estiver de acordo com esse termo, nós gostaríamos que você preenchesse este questionário, o que não deve durar mais do 5-10 minutos. Para participar, clique no link abaixo: Qualquer dúvida, por favor, entre em contato: Thaisa Cardoso Lacerda (thaisa@incod.ufsc.br). GQS Grupo de Qualidade de Software INCoD Instituto Nacional de Convergência Digital INE - Departamento de Informática e Estatística UFSC - Universidade Federal de Santa Catarina. Desde já, agradecemos sua contribuição e colaboração neste estudo. Cordialmente, Thaisa Cardoso Lacerda Graduanda em Ciências da Computação Universidade Federal de Santa Catarina

111 111 Apêndice C 1.Qual a sua faixa etária? anos anos anos Mais de 61 Questionário 2.Você possui alguma deficiência ou dificuldade? visual motora auditiva Não possuo nenhuma deficiência ou dificuldade 3.Qual a sua área de formação? Computação Administração Outra? 4.Você possui alguma certificação na área de gerência de projetos de software? PMP CAPM PMI-ACP SCRUM Master Não possuo certificação. Outra? 5.Você teve uma formação formal (disciplina na universidade ou treinamento profissional) na área de gerência de projetos de software? Quantas horas? Nenhuma formação formal 0-8 horas 9-40 horas horas Mais do que 80 horas 6.Há quanto tempo trabalha com gerência de projetos de software? Menos de 1 ano Entre 1 e 3 anos Entre 3 e 10 anos Mais de 10 anos 7.Com que frequência você usa o computador? Não uso computador Semanalmente

112 112 Diariamente Menos de 4 horas por dia Mais de 4 horas por dia 8.Você usa algum software para auxiliar nas atividades de gerência? Não uso nenhum software para me auxiliar MS Project Primavera Systems ProjectBuilder DotProject Redmine Channel Outro (Qual?) 9.Qual o método de gerência de projetos você usa? Tradicional (seguindo PMBOK, PRINCE etc.) Ágil (SCRUM) Outro 10.O quanto você acha que usar um software de apoio à gerência de projetos auxilia no seu trabalho diário? Não ajuda Ajuda pouco Ajuda muito Não consigo gerenciar projetos sem ajuda de um software de apoio à GP. 11.Selecione 5 atividades de gerência de projetos para as quais você sente maior necessidade de suporte de um software de apoio à GP: Desenvolver termo de abertura Criar EAP Estrutura Analítica de Projetos Controlar o escopo Definir atividades Estimar duração das atividades Definir cronograma Monitorar e controlar o cronograma Estimar custo Planejar a qualidade Monitorar e controlar riscos Planejar as aquisições Identificar as partes interessadas Encerrar o projeto Monitorar e Controlar custos Planejar a comunicação

113 113 Planejar os recursos humanos Outras (Quais?) 12.Quantos projetos você geralmente gerencia ao mesmo tempo? 13.Em média quantas pessoas participam dos projetos que você gerencia? 14.Em média qual a duração dos projetos que você gerencia? 0-3 meses 4-6 meses 7-12 meses Mais de 1 ano 15.Sobre a atividade xxxxx: (essas perguntas serão repetidas para as 5 atividades realizadas com maior frequência pelo gerente) 15.a Com que frequência você geralmente a realiza? Uma vez por projeto Mensalmente Semanalmente Diariamente Outro: 15.b Qual o nível de dificuldade para executá-la? Não há dificuldade Baixo Médio Alto 15.c Qual o tempo de duração ideal para executá-la utilizando uma ferramenta de gerência de projetos? Menos de 30 segundos Entre 30 segundos e 1 minuto Entre 1 e 3 minutos Entre 3 e 5 minutos Entre 5 e 10 minutos Entre 10 e 20 minutos Mais de 20 minutos 15.d Você encontra algum tipo de problema ao utilizar um software de apoio à gerência de projetos para realizar esta atividade? Não uso software de apoio para realizar essa tarefa Não o software que uso suporta bem essa atividade Sim (qual?) 16.Como você avalia a usabilidade do dotproject? Muito ruim

114 114 Ruim Boa Muito boa 17.O quão difícil é realizar as tarefas do dotproject? Muito difícil Difícil Fácil Muito fácil 18.O quão satisfeito você fica com o tempo necessário para realizar as tarefas do dotproject? Muito insatisfeito Insatisfeito Satisfeito Muito satisfeito 19.O que você mais gostou na interface do dotproject? (Por exemplo: cores, disposição das informações na tela, navegação entre as telas de diferentes tarefas) 20.O que você menos gostou na interface do dotproject? (Por exemplo: cores, disposição das informações na tela, navegação entre as telas de diferentes tarefas).

115 Apêndice D Ferramentas de Apoio para a Realização dos Testes de Usabilidade Termo de Consentimento Livre e Esclarecido Eu...estou sendo convidado(a) a participar do teste de usabilidade da ferramenta de gerência de projetos dotproject+, desenvolvidos no projeto Diretrizes de Design de Interface para Ferramentas de GP: Melhorando a Usabilidade do dotproject, desenvolvido pela aluna Thaisa C. Lacerda e orientado pela Profª. Dra. rer. nat. Christiane A. Gresse von Wangenheim, PMP, no GQS Grupo de Qualidade de Software do INCoD Instituto Nacional de Convergência Digital no Departamento de Informática e Estatística da UFSC. O projeto tem como objetivo levantar diretrizes de design de interface para o desenvolvimento de ferramentas de GP com usabilidade e melhorar a usabilidade da interface do dotproject. O teste tem como objetivo avaliar e melhorar a usabilidade da ferramenta. A minha participação no referido projeto será no sentido de auxiliar na identificação de pontos fortes e fracos no design de interface test.do Recebi esclarecimentos sobre a pesquisa e estou ciente de que minha privacidade será respeitada, ou seja, meu nome será mantido em sigilo. Eu autorizo a gravação de áudio e vídeo durante os testes de usabilidade e entendo que as gravações de áudio e vídeo serão utilizadas somente para os fins desta pesquisa e não serão divulgados fora do contexto desta pesquisa. Fui informado(a) de que posso me recusar a participar do estudo, ou retirar meu consentimento a qualquer momento, sem precisar justificar. É assegurada a assistência durante toda a pesquisa. Manifesto meu livre consentimento em participar. Florianópolis,... de Setembro de 2014 Nome e assinatura do participante

116 116 1.Qual a sua faixa etária? anos anos anos Mais de 61 Questionário Demográfico 2.Você possui alguma deficiência ou dificuldade? visual motora auditiva Não possuo nenhuma deficiência ou dificuldade 3.Qual a sua área de formação? Computação Administração Outra? 4.Você possui alguma certificação na área de gerência de projetos de software? PMP CAPM PMI-ACP SCRUM Master Não possuo certificação. Outra? 5.Você teve uma formação formal (disciplina na universidade ou treinamento profissional) na área de gerência de projetos de software? Quantas horas? Nenhuma formação formal 0-8 horas 9-40 horas horas Mais do que 80 horas 6.Há quanto tempo trabalha com gerência de projetos de software? Menos de 1 ano Entre 1 e 3 anos Entre 3 e 10 anos Mais de 10 anos 7.Com que frequência você usa o computador? Não uso computador Semanalmente Diariamente Menos de 4 horas por dia Mais de 4 horas por dia

117 117 8.Você usa algum software para auxiliar nas atividades de gerência? Não uso nenhum software para me auxiliar MS Project Primavera Systems ProjectBuilder DotProject Redmine Channel Outro (Qual?) 9.Qual o método de gerência de projetos você usa? Tradicional (seguindo PMBOK, PRINCE etc.) Ágil (SCRUM) Outro 10.O quanto você acha que usar um software de apoio à gerência de projetos auxilia no seu trabalho diário? Não ajuda Ajuda pouco Ajuda muito Não consigo gerenciar projetos sem ajuda de um software de apoio à GP. Tarefas Você é gerente de projetos na empresa dotusability. No momento você está trabalhando em um projeto para desenvolver um website. Para auxiliar no gerenciamento do projeto é utilizada a ferramenta dotproject. Tarefa 1: Considerando que a EAP já foi desenvolvida, derive as seguintes atividades sob o Item Arquitetura de Informação da EAP: Atividade 1: Desenvolver estrutura do site/mapa do site Atividade 2: Desenvolver wireframes Tarefa 2: Na atividade Realizar testes de usabilidade, Altere a Prioridade para alta e o Tipo para Operativa. Tarefa 3: Insira as seguintes estimativas de tempo para as atividades: Atividade 1: Realizar testes de usabilidade Esforço: 2 pessoas por dia Data de Início: 20/10/2014

118 118 Data de Término: 25/10/2014 Recursos: 2 arquitetos de informação Atividade 2: Acompanhar a modelagem de dados Tarefa 4: Esforço: 3 pessoas por dia Data de Início: 26/10/2014 Data de Término: 05/11/2014 Recursos: 2 arquitetos de informação Após descrever as atividades, aloque para cada uma delas os respectivos recursos humanos: Atividade Realizar testes de usabilidade: Bruno Soares Atividade Acompanhar a modelagem de dados: Bruno Soares Tarefa 5: Durante o monitoramento do projeto é importante acompanhar valores com o VPR para verificar se o projeto está dentro do prazo e orçamento previstos. Leia em voz alta o valor VPR do projeto

119 119 Apêndice E DESIGN DE INTERFACE DE FERRAMENTAS DE GP: MELHORANDO A USABILIDADE DO DOTPROJECT Thaísa Cardoso Lacerda¹ 1 Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) thaisa_lacerda@hotmail.com Resumo. A boa prática de Gerencia de Projetos (GP) pode ser um importante fator contribuinte à vantagem competitiva das empresas de software. Um dos fatores para o sucesso da GP é o uso de tecnologia como suporte. Atualmente existe uma grande variedade de ferramentas para GP, entre elas o dotproject. 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 em termos da sua usabilidade. Para isso é adotada uma metodologia 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 Introdução 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). 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 (GONÇALVES 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; GONÇALVES, 2012). 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). Dentro deste contexto o objetivo deste trabalho é melhorar o design de interface de uma ferramenta de gerencia de projetos, dotproject+ versão Metodologia 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. 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

120 120 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: 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: 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: 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: determinação das categorias de usuários, desenvolvimento do questionário, aplicação piloto do questionário e distribuição dos questionários. Em seguida são analisados o perfil dos usuários, do contexto das tarefas e do ambiente de uso da ferramenta, bem como são definidos 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. A Avaliação 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. 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. É aplicado o KLM para as mesmas tarefas realizadas nos testes de usabilidade, além do caso de uso Alterar o Status da Atividade. 2) 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 de baixa fidelidade, que são representações

121 121 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: 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 Fundamentação Teórica 3.1. Engenharia de Usabilidade 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 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 1. Na primeira delas é realizada a análise 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).

122 122 Figura 1: Ciclo de Vida de Engenharia de Usabilidade Fonte: MAYHEW, 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 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 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 (PMI, 2013): iniciação, planejamento, execução, monitoramento & controle e encerramento. 4. Estado da Arte 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. A análise do estado da arte foi realizada seguindo o método de revisão sistemática de literatura definido por Kitchenham (2004).

123 123 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. 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 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. Além do artigo encontrado na busca, foram encontradas outras pesquisas em buscas informais. Entre elas o artigo A Practical Approach for Software Project Management (BOZHIKOVA, STOEVA e TSONEV, 2009). Nela são descritas as principais funcionalidades do Svet, uma ferramenta para gerência de projetos. Na Tabela 1, os autores destacam características do design que consideram positivas. Tabela 111: 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) (Tabela 2), 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 funções estavam localizadas em lugar diferente do usado no pacote MS Office (FACHINE e ARAÚJO, 2010).

124 124 Tabela 2: Análise e Extração de Dados Artigo Ferramenta Pontos Fracos 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) DotProject Padrão cromático 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). Logo, devido à escassez deste tipo de estudo este projeto é de fundamental 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) Análise dos 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. Para coletar dados referente ao contexto de uso das ferramentas de GP, especificamente do dotproject foi realizado um survey. 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 3 mostras as características dos mesmos. Tabela 312: Características dos Usuários Característica Usuário Gerente de Projeto de Software Idade média 60% tem entre 24 e 45, 14% tem entre 18 e 25 e 26% tem entre 46 e 60 anos. Capacidades e limitações físicas Habilidades no uso do computador Formação profissional 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.

125 Quatidade de Votos 125 Experiência na tarefa Motivação 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%). 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 2) Atividades Atividades Figura 2: Atividades mais realizadas pelos gerentes de projeto 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. Foram selecionadas para melhoria neste trabalho os processos relacionados a cronograma que possuem algum tipo de suporte pelo dotproject (decompor atividade, estimar duração das atividades, controlar o cronograma, alocar recursos humanos e acompanhar execução de atividade). 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. O usuário normalmente está sentado no seu escritório e pode ser interrompido por colegas de trabalho.

126 126 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.1 Avaliação da Usabilidade do dotproject+ (versão 2.1.7) 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, Estimar Recursos Humanos, Estimar Duração das Atividades, Controlar Cronograma,e Acompanhar Execução de Atividades, conforme definido na análise do contexto. Análise da Avaliação Heurística 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 4 a baixo. Tabela 4: 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). 2 Médio 2 Baixo Título da atividade é extenso e incomum "método de diagrama de precedência" 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. 2 Baixo

127 127 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. 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. 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. 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 2 Baixo 2 Baixo 2 Médio 3 Baixo 2 Baixo 2 Baixo 3 Baixo 2 Médio 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

128 128 [Atividade] Formulário tem campos obrigatórios escondidos em outras abas. 3 Médio 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 3 Alto 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. [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. 3 Alto 4 Médio 4 Alta [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. 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. Análise dos Testes de Usabilidade

129 129 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 5. Tabela 5: Perfil dos participantes dos testes de usabilidade Característica Idade Capacidades e limitações físicas Habilidades no uso do computador 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. Formação profissional Motivação 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 6 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 a 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. 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). 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. Tabela 6: Completude das tarefas Tarefa 1-De forma errada via Nova Atividade 1-De forma correta Usuário 1 Sim Sim (via atividade) Usuário 2 Sim Sim/mas procurou em atividade antes Usuário 3 Sim Sim (via atividade) Sim Sim 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 - Sim Usuário 7 Sim Sim

130 130 Usuário 8 - Sim Sim Sim Sim Sim Total 25% 100% 37% 75% 87% 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. 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. Atendimento dos requisitos de usabilidade: A Tabela 7 apresenta os resultados em relação aos requisitos de usabilidade estabelecidos. Fica evidente que a ferramenta na versão não atende aos requisitos definidos. Tabela 7: 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 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 8: Tabela 8: Estimativa de tempo das atividades Atividade 1 Decompor atividade Atividade 2 Editar atividade Atividade 3: Estimativa atividade Tempo estimado (s) Atividade 5: Ver VPR Atividade 6: Atualizar status da atividade Total (s) 25,4 20,5 14,1 24,7 7,4 11,2 Total para 2 atividades 37,1 38,5 15,1 46, ,6 Total para 10 atividades 130,7 182,5 59, ,8 5.2 Desenvolvimentos das Melhorias

131 131 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. 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. 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. 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. 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. 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 3 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. Figura 3: Diagrama de Navegação 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). Neste nível foram desenvolvidos os protótipos de baixa fidelidade, com

132 132 a definição dos tipos de 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 alguns dos protótipos e seus respectivos comentários sobre quando eles são exibidos, que tarefas é possível realizar e que telas é possível acessar a partir deles. 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 4: Tela 2 - Projeto Planejamento

133 133 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). 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 5: Tela 3 Menu da EAP Figura 6: Tela 6 - Editar Aividade 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.

134 134 6 Avaliação da Melhoria da Usabilidade Figura 7: Screenshot da tela de Planejamento 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. 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 de fato melhorou a usabilidade do sistema com respeito a eficácia, eficiência, e satisfação de uso do usuário. 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. Análise do Teste de Usabilidade da versão 1.3 Após a realização dos testes, foi feita a análise dos dados coletados. O perfil dos participantes é exibido na Tabela 9. Tabela 9: Perfil dos participantes do teste de usabilidade 2 Característica Idade Capacidades e limitações físicas Habilidades no uso do computador 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. Formação profissional Motivação 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%). Eficácia: A Tabela 10 abaixo exibe a completude de cada uma das tarefas realizadas nos testes. Tabela 1013: Completude das tarefas na versão proposta Tarefa