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
Thaísa Cardoso Lacerda
thaisa_lacerda@hotmail.com
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
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.
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
LISTA DE FIGURAS
Figura 1: Planejamento do Experimento. Adaptado de WOHLIN et al. (2000) ... 18
Figura 2:Estrutura de usabilidade Fonte: ISO 9241-11 ... 20
Figura 3: Ciclo de Vida de Engenharia de Usabilidade Fonte: MAYHEW,1999. .. 22
Figura 4: Grupos de Processos do Ciclo de Vida de Engenharia de Usabilidade. Fonte: PMI, 2013 ... 24
Figura 5: Competência Gerais de um Gerente de Projetos. Fonte: PMI (2004) ... 25
Figura 6: Tela inicial dotProject ... 27
Figura 7: Arquitetura do DotProject ... 29
Figura 8: Fase Análise de requisitos ... 33
Figura 9: Tela inicial do survey no Limesurvey ... 14
Figura 10: Atividades mais realizadas pelos gerentes de projeto ... 35
Figura 11: Definir as atividades. Fonte: PMI, 2013 ... 39
Figura 12 Sequenciar as atividades. Fonte: PMI, 2013 ... 40
Figura 13 Estimar Recursos. Fonte: PMI, 2013 ... 41
Figura 14 Estimar Duração. Fonte: PMI, 2013 ... 42
Figura 15: Desenvolver cronograma. Fonte: PMI, 2013 ... 44
Figura 16: Controlar o cronograma. Fonte: PMI, 2013 ... 44
Figura 17: Fasse de Instalação ... 52
Figura 18: Etapas do processo de avaliação (WOHLIN, 2000) ... 17
Figura 19: Imagens capturadas ao longo dos testes de usabilidade ... 62
Figura 20: Fase Projeto/Teste/Implementação ... 70
Figura 21: Hierarquia da atividade “Decompor Atividades” ... 72
Figura 22:Hierarquia da atividade"Sequenciar Atividades" ... 72
Figura 23: Hierarquia da atividade "Estimar Tempo das Atividades” ... 72
Figura 24: Hierarquia da atividade"Alocar RH"... 73
Figura 25: Hierarquia da atividade "Monitorar Cronograma" ... 73
Figura 26: Diagrama de Navegação ... 74
Figura 27: Protótipo de baixa fidelidade feito em papel ... 75
Figura 28: Photoshop ... 76
Figura 29: Pencil ... 76
Figura 30: Tela 1 – Inicial / Empresa ... Erro! Indicador não definido. Figura 31: Tela 2 - Projeto –Planejamento ... 77
Figura 33: Tela 4 - Menu da Atividade ... 79
Figura 34: Tela 5 - Editar EAP ... 79
Figura 35: Tela 6 - Editar Aividade ... 80
Figura 36: Tela 7 - Editar Projeto ... 81
Figura 37: Tela 8 – Tela Inicial sem Empresa ... 81
Figura 38: Tela 9 - Projeto sem EAP ... 82
Figura 39: Tela 10 - Projeto - EAP sem Atividade ... 82
Figura 40: Tela 11 - Monitoramento do Cronograma ... 83
Figura 41: Tela 12 - Menu ... 83
Figura 42: Tela 13 - Execução ... 84
Figura 43: Tela 13.1 – Editar Execução ... 85
Figura 44: Mensagem 1 ... 86 Figura 45: Mensagem 2 ... 86 Figura 46: Mensagem 3 ... 87 Figura 47: Mensagem 4 ... 88 Figura 48: Mensagem 5 ... 88 Figura 49: Mensagem 6 ... 89 Figura 50: Mensagem 7 ... 90 Figura 51: Mensagem 8 ... 90
Figura 52: Screenshot da tela de Planejamento ... 92
Figura 53: Screenshot da tela de edição de uma atividade ... 93
LISTA DE TABELAS
Tabela 1: Processos por área de conhecimento ... 24
Tabela 2: Módulos Core do DotProject ... 28
Tabela 3: Módulos Addon do DotProject ... 29
Tabela 4 Análise e Extração de Dados ... 32
Tabela 5. Características da interface do Svet ... 31
Tabela 6: Características dos Usuários ... 34
Tabela 7: Identificação do grau de suporte oferecido pela ferramenta de software de GP ... 37
Tabela 8 Características do processo de Definir as Atividades ... 40
Tabela 9 Características da Atividade Estimar Duração ... 43
Tabela 10: Características da ativade Monitoramento do Cronograma ... 46
Tabela 11: Caso de uso 1: Decompor atividade ... 46
Tabela 12: Caso de uso 2: Desenvolver Diagrama de Rede do Cronograma ... 47
Tabela 13: Caso de uso 3: Estimar Duração ... 47
Tabela 14: Caso de uso 4: Controlar o Cronograma ... 48
Tabela 15: Caso de uso 5: Visualizar Gantt ... 49
Tabela 16: Caso de uso 6: Alocar Recursos Humanos ... 49
Tabela 17: Caso de uso 7: Acompanhar Excecução de Atividade ... 51
Tabela 18: Escala de Severidade (Nielsen, 1995) ... 53
Tabela 19: Problemas de usabilidade encontrados via avaliação heurística ... 54
Tabela 20: Descrição dos problemas de usabilidade mais severos ... 57
Tabela 21: Perfil dos participantes dos testes de usabilidade ... 63
Tabela 22: Completude das tarefas ... 64
Tabela 23: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade. ... 65
Tabela 24: Resultado dos testes de usabilidade ... 67
Tabela 25:Descrição do Conteúdo das Telas ... 74
Tabela 26: Problemas de usabilidade / Sugestão de melhoria ... 91
Tabela 27: Perfil dos participantes do teste de usabilidade 2 ... 95
Tabela 28: Completude das tarefas na versão proposta ... 96
Tabela 29: Descrição dos problemas de usabilidade encontrados nos testes de usabilidade 2. ... 97
SUMÁRIO 1 INTRODUÇÃO ... 9 1.1 Contextualização ... 9 1.2 Problema ... 10 1.3 Objetivo ... 11 1.4 Delimitações ... 11 1.5 Justificativa ... 11 1.6 Estrutura do Trabalho ... 12 2 MÉTODO DE PESQUISA ... 12 3 FUNDAMENTAÇÃO TEÓRICA ... 19 3.1 Usabilidade ... 19 3.1.1 Engenharia de Usabilidade ... 21 3.2 Gerenciamento de Projetos ... 22 3.2.1 Gerente de Projeto ... 25
3.2.2 Ferramentas de Gerenciamento de Projetos ... 25
4 ANÁLISE DO ESTADO DA ARTE ... 30
4.1 Definição da Análise ... 30
4.2 Execução da Busca ... 30
4.3 Extração e Análise dos Dados ... 32
4.4 Discussão ... 32
5 MELHORIA DA USABILIDADE DO DOTPROJECT ... 33
5.1.1 Análise de Requisitos ... 33
5.1.2 Análise dos dados coletados ... 34
5.1.3 Requisitos de Usabilidade ... 52
5.2 Avaliação da Usabilidade do dotProject+ (versão 2.1.7) ... 52
5.2.1 Definição da Avaliação ... 53
5.2.2 Avaliação heurística ... 53
5.2.3 Teste de Usabilidade do dotProject+ versão 2.1.7 ... 61
5.2.4 Aplicação do KLM na versão 2.1.7 ... 68
5.3 Desenvolvimento das Melhorias ... 70
5.3.1 Modelo Conceitual ... 70
5.3.2 Análise Hierárquica das Tarefas – HTA e Diagrama de Navegação ... 71
5.3.3 Protótipos de Baixa Fidelidade ... 75
5.4 Implementação das Melhorias ... 92
6 AVALIAÇÃO DA MELHORIA DA USABILIDADE ... 94
6.1 Definição da avaliação ... 94
6.2 Execução da Avaliação ... 94
6.2.1 Teste de Usabilidade da versão 1.3 do dotProject+ ... 95
6.2.2 Aplicação do KLM na versão 1.3 ... 98
6.2.3 Comparação da usabilidade dos designs de interface ... 99
6.2.3.1 DISCUSSÃO DA COMPARAÇÃO DA USABILIDADE DOS DESIGNS DE INTERFACE ... 102 7 DISCUSSÃO ... 103 7.1 Ameaças à Validade ... 105 8 CONSIDERAÇÕES FINAIS ... 105 REFERÊNCIAS... 108 APÊNDICE A ... 113 APÊNDICE B ... 113 APÊNDICE C ... 114
APÊNDICE D FERRAMENTAS DE APOIO PARA A REALIZAÇÃO DOS TESTES DE USABILIDADE ... 118
1 INTRODUÇÃO
Neste capítulo são apresentados a contextualização, o problema, os objetivos, a metodologia e a justificativa do presente trabalho.
1.1 Contextualização
O gerenciamento de projetos (GP) permite que empresas possam, entre outras atividades, prever os custos do projeto, adaptar seus trabalhos ao mercado consumidor e aos clientes, agilizar decisões, aumentar o controle gerencial e otimizar a alocação de pessoas, equipamentos e materiais necessários (VARGAS, 2005). Logo, a boa prática de GP pode ser um importante fator contribuinte à vantagem competitiva das empresas (JUGDEV, 2011). Entre os benefícios da boa prática da GP estão a redução de custo e prazo de desenvolvimento de novos produtos, aumento no tempo de vida dos novos produtos, das vendas e receitas, do número de clientes e de sua satisfação, bem como da chance de sucesso dos projetos (GUEDES, 2003).
Dentro desse contexto compreende-se que o gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades de um projeto com a finalidade de alcançar os seus requisitos (PMI, 2013). Ele envolve desde as etapas de iniciação do projeto, o seu planejamento, execução, monitoramento e encerramento, bem como controla o escopo, tempo, custo e qualidade.
Um significante critério de sucesso no gerenciamento de projetos na prática atualmente é o uso de tecnologia para auxiliar (GUEDES, 2003) (JESSEN, 2000). Tais ferramentas permitem a visualização do projeto de forma integrada, contemplando atividades, prazos, alocação de recursos, custos etc., além de tornar possível, acompanhar o status do projeto, sinalizando o atraso de tarefas, visualizar uma possível super ou sub-alocação de recursos humanos e identificar riscos afim de minimizá-los (GUEDES, 2003). Existe atualmente uma grande variedade de ferramentas para GP, que podem ser proprietárias (MS Project (MICROSOFT,2014.)) ou gratuitas (dotProject (2013)), desktop ou acessíveis via web (GONCALVEZ et al., 2012).
Entre as de código livre, a mais popular e com foco em GP, é o dotProject (PMI BRASIL, 2008; GRESSE VON WANGENHEIM et al., 2009; GONCALVEZ,
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 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 torna-se 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 9241-11, 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 interface que contribuem para o desenvolvimento de ferramentas de GP com boa usabilidade.
1.3 Objetivo
O objetivo geral do presente trabalho é melhorar o design de interface de uma ferramenta de gerencia de projetos, dotProject+ versão2.1.7.
Os objetivos específicos do trabalho são:
1. Analisar a fundamentação teórica em relação a GP, ferramentas de GP, e especialmente o dotProject e engenharia de usabilidade.
2. Analisar o estado da arte de estudos de usabilidade do dotProject+ e outras ferramentas de suporte a GP.
3. Melhorar a usabilidade da interface do dotProject+ usando um processo sistemático de engenharia de usabilidade.
4. Realizar uma análise comparativa da usabilidade do dotProject+ e da versão 1.3.
1.4 Delimitações
As delimitações do trabalho são:
1. Como o estudo será realizado levando em consideração especificamente a ferramenta dotProject, quando os seus resultados forem aplicados à outras ferramentas, devem ser adaptados de acordo com as peculiaridades das mesmas.
2. O estudo tem como foco avaliar e melhorar os aspectos relacionados a usabilidade da ferramenta e as diretrizes são direcionadas ao design de interface, não abordando outros aspectos de qualidade de software.
3. É realizada a engenharia de usabilidade do dotProject, as implementações das melhorias propostas estão fora do escopo deste projeto.
1.5 Justificativa
Com este trabalho é projetado um novo design de interface, com melhor usabilidade, para o dotProject que é uma das ferramentas de GP de código livre mais completas e utilizadas atualmente. Com uma nova alternativa de design a ser
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 2.1.7. No capítulo 7 são discutidos os resultados da comparação das ferramentas. No capítulo 8 é discutido o trabalho como um todo e por fim, o capítulo 8 apresenta as considerações finais do trabalho.
2 MÉTODO DE PESQUISA
Em relação à natureza está pesquisa é do tipo aplicada, pois tem como resultado uma série de diretrizes que poderão ser utilizadas por desenvolvedores de interface de ferramentas de GP. De acordo com Gerhadt e Silveira (2009) esse tipo de pesquisa visa gerar novos conhecimentos de aplicação prática e dirigidos à solucionar problemas específicos. Quantos aos objetivos esta pesquisa é exploratória, pois envolve levantamento bibliográfico, bem como entrevistas com especialistas no problema de pesquisa.
Para atingir os objetivos deste trabalho é realizado um estudo de caso aplicando um ciclo de vida de engenharia de usabilidade ao dotProject e comparando os resultados obtidos com a interface atual da ferramenta.
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.1.2 Revisar a teoria sobre engenharia de usabilidade;
A.1.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.1.2.2 Revisar a teoria sobre ferramentas de apoio à GP/dotproject.
Etapa 2 - Revisão do estado da arte: nesta etapa é realizada uma revisão
sistemática da literatura seguindo o procedimento proposto por (KITCHENHAM, 2004) para identificar e analisar trabalhos similares ou que tenham como foco a usabilidade de ferramentas para GP. As atividades desta etapa são:
A.2.1. Definir a revisão; A.2.2. Executar a busca;
A.2.3. Extrair e analisar os dados.
Etapa 3 – Melhoria de usabilidade: Nesta etapa é realizada a melhoria do
design de interface da ferramenta dotProject – como uma ferramenta representativa das ferramentas de GP. Para isso é adotada uma customização do ciclo de vida de engenharia de usabilidade proposto por Mayhew (1999), que consiste em uma série de processes divididos 3 fases: Análise de requisitos (1), Design/teste/implementação(2) e Instalação/Operação(3).
1) Na fase de análise de requisitos são levantadas informações sobre o perfil dos usuários, das tarefas, equipamentos e ambiente de uso. Para isso é efetuada uma análise de estudos existentes e realizado um survey com usuários de ferramentas de GP. O desenvolvimento e aplicação do survey são feitos nas seguintes etapas:
1- Determinação das categorias de usuários: Os usuários das ferramentas de GP são todas as pessoas envolvidas nas atividades de desenvolvimento de software, como o gerente de projetos, programador, analista de sistemas etc. Ao longo deste projeto são priorizadas as funcionalidades do dotProject que dizem respeito as atividades desempenhadas pelo gerente de projetos, por entender que esta é a categoria de usuários que mais utiliza a ferramenta.
2- Desenvolvimento do questionário: o questionário desenvolvido, que pode ser visto no Apêndice C, possui 20 perguntas, divididas em duas categorias. A primeira categoria tem como objetivo levantar dados sobre o perfil dos usuários em termos de idade, dificuldades físicas, experiência no uso do computador e na prática da GP. A segunda parte tem como objetivo descobrir quais são as atividades que estes usuários mais utilizam em uma ferramenta de apoio à GP, que tipo de ferramenta utilizam e quais problemas de usabilidade encontram ao utilizá-la. A implementação e divulgação do questionário é feita utilizando o Limesurvey (LIMESURVEY, 2013) uma ferramenta livre e gratuita para desenvolvimento de
surveys, Figura 1.
Figura 1: Tela inicial do survey no Limesurvey
3- Aplicação piloto do questionário: Para avaliar o questionário quanto à sua clareza, completude e adequação das perguntas, ele é testado com dois gerentes de projetos do INCoD. Após os testes piloto são feitas as devidas alterações no questionário, todas elas são reformulações em algumas questões de modo a torná-las mais clara ou retirar ambiguidades.
4- Distribuição dos questionários: O convite para preencher o questionário é enviado por e-mail para 27 gerentes de projetos e 9 listas (como a Brasil, PMI-SC, SOFTEX) em setembro 20013. O survey é disponível até o dia 22 de Novembro.
Como resultado final dessa fase é estabelecido um conjunto de metas de usabilidade. As atividades desta fase são:
A.3.1 Submeter projeto ao do Comitê de Ética em Pesquisa com Seres Humanos da Universidade Federal de Santa Catarina (CEPSH/UFSC) para obter autorização do envolvimento de Gerentes de Projeto no presente trabalho;
A.3.2 Definir e aplicar um questionário demográfico a um conjunto de usuários em potencial do dotProject, para levantar o perfil dos usuários, das atividades realizadas e do ambiente de uso da ferramenta;
A.3.3 Analisar o perfil dos usuários, via descrição de personas, a partir dos dados obtidos com os questionários em A3.2;
A.3.4 Analisar o contexto das tarefas, via de descrição das tarefas e diagramas de atividades, a partir dos dados obtidos com os questionários em A3.2;
A.3.5 Analisar o ambiente, via descrição do ambiente organizacional e técnico, a partir dos dados obtidos com os questionários em A3.2.
A.3.6 Definir os requisitos de usabilidade.
3) Considerando que o dotProject já está em uso, a etapa de
Instalação/Operação se resume à análise do feedback dos usuários em relação a
usabilidade do dotProject e a avaliação da usabilidade como objetivo de encontrar possíveis problemas de usabilidade da ferramenta. Essa avaliação é feita utilizando as técnicas de avaliação: teste de usabilidade e avaliação heurística, de forma complementar. O Teste de usabilidade é uma técnica empírica (CYBIS, 2003), no qual usuários que representam o público alvo do sistema são observados de forma sistemática, interagindo com a aplicação ou protótipo que está sendo avaliado. Enquanto o usuário realiza as tarefas, inspetores coletam dados referentes ao processo de interação do usuário, incluindo erros cometidos, situações de confusão ou frustração, rapidez com a qual realiza a tarefa, se obtém sucesso ou não na realização da mesma e sua satisfação com a experiência. A partir dos testes de usabilidade o projetista pode prever o comportamento dos usuários diante da
interface. Esse método pode ser considerado insubstituível pois fornece informações diretas sobre como o usuário realmente usa o sistema (NIELSEN, 1994). A
Avaliação Heurística é um dos principais métodos analíticos para avaliação da
usabilidade (que dispensa a participação do usuário) (CYBIS, 2003). Ele tem como objetivo encontrar problemas de usabilidade em designs de interface com o usuário (NIELSEN, 1993). Esse método envolve ter um pequeno conjunto de avaliadores que examinam a interface e julgam se ela está de acordo com princípios reconhecidos de usabilidade, as heurísticas. A avaliação heurística é realizada de forma individual por cada avaliador, assim que todos os avaliadores terminam a sua avaliação eles se reúnem e entram em consenso sobre os problemas encontrados (NIELSEN, 1994).
Dado que algumas das atividades dos testes não são completadas pelos usuários, tornou-se inconveniente utilizar o tempo de execução das tarefas no teste de usabilidade como atributo de comparação da eficiência das interfaces. Por isso optou-se por fazer o cálculo estimado do tempo de execução das atividades utilizando a técnica Keystroke Level Model (KLM).
O KLM (Card, Moran, e Newell, 1983), é uma técnica para predição do tempo de execução de uma tarefa específica. A aplicação desta técnica consiste em listar a sequência de operações que o usuário deve realizar para completar a tarefa e somar os tempos requeridos de cada uma das ações. Cada operador possui um tempo estimado para ser executado, conforme mostra a Tabela 1 abaixo.
Tabela 1: Códigos, Operadores e Tempos no KLM
Código Operador Tempo(s)
K Apertar e soltar tecla do teclado
Digitador experiente 0.08
Digitador bom 0.12
Digitador regular 0.28 Digitador com habilidade média 0.20 Digitador inexperiente 1.20
P Apontar o mouse para objeto na 1.10
B Aperta ou soltar botão do mouse 0.10
H Mover mão do mouse para o teclado (ou o contrário) 0.40
M Preparação mental 1.20
T(n) Digitar sequência de caracteres n × K
É aplicado o KLM para as mesmas tarefas realizadas nos testes de usabilidade, além do caso de uso “Alterar o Status da Atividade”. Cada uma das
tarefas é decomposta em um sequência de operadores, e a cada um é atribuído o respectivo tempo de execução (conforme a Tabela 1). Ao final são inseridos os operadores M (tempo de preparação mental). A inserção deste operador se baseia nas seguintes heurísticas: Inserir M: -No início de tarefas (o usuário tem que parar e pensar para definir o que tem que ser feito). –Recuperar uma informação na memória. – Encontrar algo na tela (o usuário precisa scannear a tela para achar a o item que ele ainda não sabe onde fica). –Verificar se a ação foi executada corretamente antes de confirma-la. -Apontar para um objeto na tela. – Se algo na tela muda em resposta à uma ação do usuário também há uma pausa para verificar a mudança ocorrida (Kieras, 2001). Como os dados e a quantidade de campos a serem preenchidos são similares em ambas às versões, os operadores que representam a ação de digitar são suprimidos do cálculo.
O processo de avaliação é composto por cinco etapas: Definição, Planejamento, Operação, Análise e Interpretação e Documentação (WOHLIN, 2000) (Figura 2).
Figura 2: Etapas do processo de avaliação (WOHLIN, 2000)
As atividades desta fase são:
A.3.7 Realizar uma avaliação heurística da versão 2.1.7 da ferramenta; A.3.8 Realizar testes de usabilidade com a versão 2.1.7 da ferramenta. A.3.9 Aplicar KLM com a versão 2.1.7 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.
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.
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 9242-11 (1998), por ser o resultado de um trabalho colaborativo entre diversos pesquisadores. De acordo com esta norma, esquematizado na Figura 2, “usabilidade é a capacidade de um produto ser usado por usuários específicos para atingir objetivos determinados como eficácia, eficiência e satisfação em um contexto previsto para o uso”.
A eficácia é a acurácia e completude com as quais usuários alcançam objetivos da interação, e é geralmente avaliada em termos de completude de uma tarefa, e da qualidade do resultado obtido. Já a eficiência se refere à quantidade de esforço para chegar a um determinado objetivo. Os desvios que o usuário faz, o tempo de duração da interação e a quantidade de erros cometidos, podem servir para avaliar o nível de eficiência do software. Satisfação, se refere ao nível de conforto que o usuário sente ao utilizar a interface (ISO 9242-11, 1998).
Figura 4:Estrutura de usabilidade Fonte: ISO 9241-11
Requisitos Ergonômicos para Trabalho de Escritórios com Computadores Parte 11 – Orientações sobre Usabilidade.
A ferramenta foco deste trabalho é uma aplicação web que tem um estilo de interface mais similar à de sistemas desktops do que de websites. Existem muitos estudos sobre a usabilidade de websites (NIELSEN e LORANGER, 2007; SCAPIN, 2000), porém, não há muita pesquisa a respeito da usabilidade de interfaces de sistemas desktop. Em função disso, na prática aplicam-se os mesmos princípios de usabilidade para ambas, levando-se em consideração as diferentes características entre elas, como:
Em websites é comum ter pelo menos um espaço reservado para publicidade, o que dificilmente ocorre em aplicações web.
Websites, geralmente possuem um campo para busca.
Aplicações web determinam qual será o ponto de partido do usuário, diferentemente de websites, onde o usuário pode acessar por meio de páginas diferentes.
Em websites normalmente há uma navegação global, disposta na lateral esquerda ou na parte superior da tela, isso nem sempre ocorre em aplicações web.
Em aplicações web não há barra de URL.
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.
3.1.1 Engenharia de Usabilidade
Para desenvolver uma interface de qualidade, porém, nem sempre é suficiente aplicar técnicas de avaliação da usabilidade apenas no final da etapa de desenvolvimento. Para reduzir o risco de falhas conceituais do projeto e garantir que o sistema responda às expectativas e necessidades dos usuários em suas tarefas, os processos do ciclo de vida de engenharia de usabilidade devem ser implementados desde cedo no desenvolvimento (CYBIS, BETYOL e FAUST, 2007).
O termo modelo do ciclo de vida é utilizado para definir um modelo que descreve um grupo de atividades, a forma como elas se relacionam ou ainda quando e como passar para a próxima atividade, e quais são os resultados de cada uma delas (PREECE et al, 2005). Entre os modelos existentes (HARTSON e HIX, 1989; ISO 9241-210, 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 autora sugere que alguns passos sejam pulados se forem muito complexos para o sistema que está sendo desenvolvido (MAYHEW, 1999).
3.2 Gerenciamento de Projetos
O gerenciamento de projetos (GP) permite que empresas possam, entre outras atividades, prever gastos com o projeto, adaptar seus trabalhos ao mercado consumidor e aos clientes, agilizar decisões, aumentar o controle gerencial e
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
Encerramento: realizados para finalizar formalmente todas as atividades de todos os grupos de processos.
Figura 6: Grupos de Processos do Ciclo de Vida de Engenharia de Usabilidade. Fonte: PMI, 2013
As áreas de conhecimento se referem aos fatores que são considerados no GP. Em cada área de conhecimento são detalhados os processos que as compõem, as entradas necessárias, as atividades executadas, e as saídas produzidas (PMI, 2013). A Tabela 2 apresenta de maneira de maneira sucinta o objetivo de cada área de conhecimento de acordo com PMI (2013).
Tabela 2: Processos por área de conhecimento Área de
conhecimento Possui processos para
Integração Identificar, definir, combinar, unificar e coordenar os vários processos e
suas atividades de maneira adequada.
Escopo Garantir que o projeto realize todo o trabalho necessário, e não mais que
isso.
Tempo Garantir a conclusão do projeto de acordo com o prazo previsto.
Custos Planejar, estimar e determinar o orçamento para assegurar que o projeto
seja concluído dentro do orçamento aprovado.
Qualidade Planejar, monitorar e controlar para garantir que o projeto satisfaça os
requisitos de qualidade especificados.
Recursos humanos Organizar e gerenciar a equipe do projeto.
Comunicações Garantir que as informações necessárias sejam coletadas, armazenadas e
disseminadas da forma adequada.
Riscos Identificar e analisar os riscos, bem como, planejar ações de contingência
e realizar o controle e monitoramento dos mesmos.
Aquisições Assegurar a compra ou aquisição de produtos ou serviços, externos à
equipe do projeto, necessários para o seu desenvolvimento.
3.2.1 Gerente de Projeto
No contexto deste trabalho é de fundamental importância conhecer o perfil do gerente de projetos, dado que ele é o principal responsável pela gerência de projetos e por atingir os objetivos do projeto. Entre suas atividades estão: iniciar e planejar o projeto, monitorar e controlar o andamento do projeto, identificar, rastrear, gerenciar e responder a problemas no projeto, comunicar pro-ativamente as informações do projeto para todos os interessados, motivar e liderar a equipe. Como suporte às suas atividades o gerente dispõem de metodologias e ferramentas, porém, saber aplicá-las não é o suficiente para um gerenciamento eficaz. A Figura 7 (PMI, 2004), mostra que além das competências gerais da área de gerenciamento, como saber o que são processos e quais são os grupos de processos, o gerente eficaz deve possuir conhecimentos sobre normas e regulamentação da área de aplicação, sobre o ambiente do projeto, sobre contabilidade, compras, aquisições e logística. Além disso, é desejável que ele possua habilidades pessoais, como ter atitude, espírito de liderança, além da capacidade de orientar a equipe ao mesmo tempo em que atinge os objetivos do projeto dentro das restrições impostas.
Figura 7: Competência Gerais de um Gerente de Projetos. Fonte: PMI (2004)
3.2.2 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 necessárias para uma organização executar os seus projetos com sucesso e deve ajudar a planejar, executar e encerrar o projeto, alcançando as suas metas (RAYMOND e BERGERON, 2008). Patterson (2010) acrescenta ainda que ferramentas de apoio a GP são um conjunto de ferramentas de TI que devem suportar técnicas de GP para permitir a realização de todos os processos do ciclo de vida de um projeto, do seu início ao fim.
Para isso elas permitem a visualização do projeto de forma integrada, contemplando atividades, prazos, alocação de recursos, custos e etc. Além de tornar possível, acompanhar o status do projeto, sinalizando o atraso de tarefas; visualizar uma possível super ou sub-alocação de recursos humanos e identificar riscos a fim de minimizá-los (GUEDES, 2003).
Existe atualmente uma grande variedade de ferramentas para GP (GONCALVEZ et al, 2012). Algumas proprietárias, como o Microsoft Project (MICROSOFT, 2014), RationalPlan (SOFT LTD., 2014) e Primavera (ORACLE, 2014), outras gratuitas como o dotProject, o RedMine (REDMINE, 2014) e o GanttProject (GANTTPROJECT TEAM, 2014). As ferramentas gratuitas podem ser consideradas uma ótima opção para pequenas empresas que não podem investir em um produto pago, que normalmente são muito caros (MARGEA e MARGEA, 2011).
A ferramentas podem ainda ser diferenciadas entre desktop (como o GanttProject e Open Workbench, por exemplo) e web (como o dotProject (DOTPROJECT, 2013)) que possuem a vantagem de permitir que membros do projeto relatem o status das atividades e detalhem o seu progresso de forma online (MARGEA e MARGEA, 2011).
Algumas ferramentas são mais pontuais, oferecendo somente algumas das atividades realizadas ao longo do planejamento e gerenciamento de um projeto, como gerar um diagrama de Gantt (GanttProject (GANTTTPROJECT, 2013)), ou apenas estimar durações para as atividades e gerenciar contatos (DeskAway (DESKAWAY, 2013)). Há também ferramentas mais abrangentes, como por exemplo, o Primavera, que atende as práticas do PMBOK (GONCALVEZ, 2012) e outras, como o in-Step, processMax, e Polarion que abrangem um nível inteiro de maturidade do CMMI e/ou MPS.BR incluindo entre outros processos, o GP (GRESSE VON WANGENHEIM et al., 2009).
Levando em consideração as necessidades de micro e pequenas empresas (MPEs) de software1, que representam a grande maioria no mercado Brasileiro (SOFTEX, 2009) e que ferramentas web livres possuem a vantagem de ter um custo reduzido, decidiu-se por adotar neste trabalho uma ferramenta com estas características. Além disso, o fato de o código ser aberto permite a implementação das mudanças propostas para a interface da ferramenta. Optou-se também por usar uma ferramenta para plataforma web, possibilitando dessa forma a inserção e acesso de informações por vários stakeholders, principalmente pela equipe de projetos, e permitindo, dessa forma, o acompanhamento de todo o ciclo de vida de GP (principalmente a fase de monitoramento & controle).
Uma das ferramentas livres e para plataforma web mais populares, que foca em GP, é o dotProject (Fig. 6), que tem mais de 1,443,670 de downloads no SourceForge (http://sourceforge.net), um dos maiores repositórios de projetos de código aberto do mundo (PMI BRASIL, 2008; GRESSE VON WANGENHEIM et al., 2009; GONCALVEZ, 2012). O dotProject tem como objetivo auxiliar os usuários a planejar e monitorar múltiplos projetos. Ele é um software sob a licença GPL, para gerenciar projetos de forma online, desenvolvido por voluntários, utilizando a linguagem de programação PHP com banco de dados MySQL (DOTPROJECT, 2013).
Figura 8: Tela inicial dotProject
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ãoutilizada neste projeto são:
Tabela 3: Módulos Core do DotProject
Módulos Descrição
Administração de Usuários Permite cadastrar novos usuários do sistema.
Tarefas Provê uma lista das atividades alocadas para o usuário.
Empresas É usado para gerenciar todos os recursos da companhia, como
clientes, fornecedores, departamentos e projetos.
Contatos Exibe todos os contatos e usuários do sistema armazenados
no sistema.
Projeto
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.
Eventos Os eventos, exibidos no calendário, são através de um ícone,
que indica o tipo de evento, mais o nome do mesmo.
Fóruns
É 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.
Calendário 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, principalmente o PMBOK (GONCALVEZ, 2012). Entre os trabalhos desenvolvidos, é possível destacar o desenvolvimento de módulos addon exibidos na Tabela 4.
Tabela 4: Módulos Addon do DotProject+
Módulos addon Descrição
Iniciaçã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.
Planejamento de Recursos Humanos
São definidos os papéis e a política organizacional da empresa.
Planejamento de Riscos 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.
Monitoramento e Controle Permite coletar dados, como tempo e custo, analisar os dados,
realizar reunião de monitoração equipe, revisar o plano de projeto.
Planejamento de Tempo
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.
Planejamento de Custos Permite editar as estimativas de cursos de recursos humanos e não
humanos.
Planejamento de Comunicação
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+ 2.1.7 com módulos addon (o dotProject+) desenvolvidos no GQS. Sua arquitetura é exibida na Figura 9.
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 2013. 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. Como resultado final foi encontrado somente um artigo que atende os critérios de inclusão. Além do artigo encontrado na busca, citado acima, também foram encontradas outras pesquisas em buscas informais. Entre elas o artigo intitulado “A Practical Approach for Software Project Management” (BOZHIKOVA, STOEVA e TSONEV, 2009). Nela são descritas as principais funcionalidades e telas da interface do Svet, uma ferramenta para gerência de projetos baseada na web. Apesar de não ser feita uma avaliação formal da interface, os autores destacam características (Tabela 5) do design que consideram positivas.
Tabela 5: Características da interface do Svet Características da interface do Svet
Na tela inicial são exibidas as informações relevantes do usuário, pra permitir um fácil monitoramento das atividades diárias.
Possui uma estética unificada, intuitiva e um design de interface mínimo e fácil de usar.
Adicionar um projeto e uma tarefa é muito similar e simples quando comparado com outras ferramentas como o dotProject.
São usadas cores discretas, os controles são fáceis de encontrar na janelas.
Todas as telas (como, anotações, tarefas, projetos, calendários, clientes, projetos, usuários, etc.) podem ser acessadas com um clique.
Todo o conteúdo é organizado de forma clara e com relação a sua funcionalidade. As anotações são muito fáceis de serem movidas, simplesmente arrastando e soltando.
Como ponto negativo foi citado o fato não poder ser usados atalhos de teclado.
Outro trabalho relacionado é de Fachine e Araújo (2010), no qual foi feita a avaliação da ferramenta MSProject. Porém, a avaliação foi realizada somente com a execução de um teste de usabilidade com um participante. Este destacou como ponto positivo da ferramenta a familiaridade com o pacote MS Office, que tornou o seu uso mais fácil. Também foram elencados aspectos negativos como a dificuldade em achar algumas funcionalidades no momento em que eram necessárias. Isso ocorreu devido à grande quantidade de funções do sistema, que tornava difícil para o usuário encontrar o que estava procurando e em outras situações se porque as
funções estavam localizadas em lugar diferente do usado no pacote MS Office (FACHINE e ARAÚJO, 2010).
4.3 Extração e Análise dos Dados
Em relação do objetivo desta analise foram extraídas informações do artigo relevante a respeito de aspectos positivos e negativos da usabilidade da ferramenta de GP analisada. Os dados extraídos estão na Tabela 6.
Tabela 6: Análise e Extração de Dados Artigo Ferramenta Pontos
Fortes da Interface
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
4.4 Discussão
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.
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).
5.1.1 Análise de Requisitos
Na fase de análise de requisitos são levantadas as informações de contexto de uso do dotProject. São analisados o perfil dos usuários, das tarefas, e do ambiente de uso, por meio da definição e aplicação de questionários a um conjunto de usuários em potencial do dotProject. Para coletar dados referente ao contexto de uso das ferramentas de GP, especificamente do dotProject foi realizado um survey.
Figura 10: Fase Análise de requisitos
2 Esta pesquisa foi aprovada pela Comissão de Ética em Pesquisa Envolvendo Seres
5.1.2 Análise dos dados coletados
Nesta sessão são analisados os dados coletados via survey. Ao final foram obtidas 28 respostas.
5.1.2.1 Perfil dos usuários
Após a análise das respostas do questionário, foi traçado um perfil do usuário de ferramentas de apoio a GP. A Tabela 7 mostras as características dos mesmos.
Tabela 7: 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
Não possuem limitações físicas.
Habilidades no uso do computador
Possuem boas habilidades no uso do computador, 75% utiliza-o 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 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.
Motivação 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 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.
5.1.2.2 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).
0 5 10 15 20 25 Monitorar e controlar o cronograma Definir o cronograma Realizar termo de abertura Monitorar e controlar custos Estimar tempo Definir as atividades Qu atidad e d e Vo to s Atividades 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 na Tabela 7.
Devido às suas peculiaridades, nem sempre os processos de GP podem ser totalmente automatizados, de modo a serem executados exclusivamente por uma ferramenta de software. Por exemplo, há diversas atividades nos processos de GP, como definir o organograma e descrição dos cargos e registrar ações corretivas, que precisam sempre ser executadas manualmente pelo GP. Porém, mesmo nesses casos, a ferramenta de GP tem um papel importante, fornecendo suporte à execução de tais atividades, tanto em relação à documentação das informações e artefatos envolvidos no processo, quanto em certos momentos automatizando algumas tarefas, como somar custos para a serem usados no cálculo do orçamento do projeto.
São consideradas processos automatizadas, aquelas as quais a ferramenta de GP propõe uma saída, que depois pode ser revisada e ajustada pelo GP. Dessa forma não é necessário que o gerente execute toda a atividade manualmente, mas somente confira o resultado proposto pela ferramenta. Por exemplo, para gerar um gráfico de Gantt de forma automática, é suficiente que o gerente insira as atividades do projeto com as suas datas de início e fim e solicitar que a ferramenta gere o gráfico.
Além de realizar determinadas atividades de forma automática, as ferramentas de GP também podem fornecer suporte para o registro e visualização de informações. Por exemplo, o “registro de ações corretivas” é feito de forma manual pelo gerente e pode ser registrado na ferramenta de GP, desse modo ele pode ser compartilhado com outros membros da equipe do projeto.
Na sequência são descritas as ferramentas e técnicas utilizadas para realizar cada as atividades selecionadas que podem ser realizadas com algum tipo de suporte do software de gerência de projetos. A Tabela 8 exibe cada uma delas e as classifica entre as que podem ser feitas de forma automática pelo dotProject, e as que somente recebem suporte para registro/visualização das informações. Além disso, a última coluna informa se a atividade é suportada pelo dotProject+ usando a
seguinte escala: não, manualmente de forma gráfica, manualmente de forma textual, automaticamente.
Tabela 8: Identificação do grau de suporte oferecido pela ferramenta de software de GP
Processo Atividades/Técnica Automática Suporte para registro/visualização das informações Suportada pelo dotProject+ Planejamento Planejar gerenciamento do cronograma São realizadas reuniões para realizar o planejamento do cronograma do projeto. Gerente registra/visualiza as atividades Não Definir atividades Definir atividades a partir dos pacotes de trabalho da EAP (Decomposição) Gerente registra/visualiza as atividades Manualmente de forma textual Sequenciar as atividades Identificar dependências entre atividades (Análise de rede do cronograma) Ferramenta gera diagrama de rede do Gerente cria/visualiza a rede Manualmente de forma gráfica Estimar recursos Alocar recursos (Estimar recursos e Nivelamento de recursos) Ferramenta propõe esquema de alocação dos recursos / identifica possíveis conflitos na alocação dos recursos Gerente registra/visualiza a atribuição dos recursos Manualmente de forma textual. Estimar duração Estimar tamanho esforça, recursos e duração das atividades. Gerente registra/visualiza a estimativas das atividades Manualmente de forma textual Desenvolver cronograma Estabelece datas de início e fim para as atividades.
Gerente
registra/visualiza a datas de início e fim das atividades Manualmente de forma textual Identificar o caminho crítico (Método do caminho crítico) Ferramenta identifica na rede do cronograma qual o caminho crítico Gerente registra/visualiza o caminho crítico da rede do cronograma Não Identificar a cadeia crítica (Método da cadeia crítica) Ferramenta identifica na rede do cronograma Gerente registra/visualiza a cadeia crítica da rede do cronograma
qual a cadeia crítica Otimizar cronograma (Compressão do cronograma) Ferramenta paraleliza o maior número de atividades possível. Gerente registra alterações no cronograma Não Ajustar cronograma (Ajuste de antecipações e atrasos) Gerente registra alterações no cronograma Manualmente de forma textual Monitoramento e controle Controlar o cronograma- Acompanhar execução de atividade Ferramenta gera tabela com informação sobre as datas de início e fim das atividades e o seu status de progresso. Gerente visualiza o relatório Sim Visualizar cronograma de controle (gráfico de Gantt) Gerente visualiza cronograma Sim Calcular Variação de prazo (VP) e e índice de desempenho de prazos (IDP) (Análise de desempenho) Ferramenta compara o desempenho do cronograma com as datas de início e término, calcula VP, IDP, porcentagem completa e duração restante para o trabalho em andamento. Gerente registra/visualiza comparação do desempenho do cronograma com as datas de início e término e porcentagem completa e duração restante para o trabalho em andamento. Automaticamente
Analisar a variação Gerente visualiza o VP e IDP para avaliar a variação da baseline Sim Registrar ações corretivas Gerente registra/visualiza ações corretivas Manualmente de forma textual
