Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
ESPECIALIZAÇÃO EM ENGENHARIA WEB E GOVERNO
ELETRÔNICO
INTEGRAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE
SOFTWARE DA SEGES-MT E DE PRÁTICAS DE IHC
ELISÂNGELA SOUZA FERREIRA
CUIABÁ – MT
2016
UF MT
2
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
ESPECIALIZAÇÃO EM ENGENHARIA WEB E GOVERNO
ELETRÔNICO
INTEGRAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE
SOFTWARE DA SEGES-MT E DE PRÁTICAS DE IHC
ELISÂNGELA SOUZA FERREIRA
Orientador: Prof.ª Dra. PATRICIA CRISTIANE DE SOUZA
Co-orientador: Prof. Dr. JOSE VITERBO
Monografia apresentada ao Curso de
Especialização em Engenharia Web e Governo
Eletrônico do Instituto de Computação da
Universidade Federal de Mato Grosso, como
requisito para conclusão do Curso de Pós-
Graduação Lato Sensu em Engenharia Web e
Governo Eletrônico.
CUIABÁ – MT
2016
UF MT
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
ESPECIALIZAÇÃO EM ENGENHARIA WEB E GOVERNO
ELETRÔNICO
CERTIFICADO DE APROVAÇÃO
TÍTULO: INTEGRAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE
SOFTWARE DA SEGES-MT E DE PRÁTICAS DE IHC
AUTOR: ELISÂNGELA SOUZA FERREIRA
Aprovada em 01/12/2016
UF MT
4
DEDICATÓRIA
À minha mãe Iracema Sena de Souza pelo apoio incondicional em todos os momentos
da minha vida.
Ao meu noivo Éder Braga Martins pelo super amor e confiança.
AGRADECIMENTOS
Agradeço a Deus por me manter firme no caminho e pela oportunidade de aprendizado.
Agradeço aos professores Patrícia Cristiane de Souza e José Viterbo por doarem seu
tempo e dedicação a minha orientação.
Agradeço ao coordenador do setor de Tecnologia de Informação da SEGES-MT, Marcel
Ribeiro Primo de Souza, por intermediar a autorização para essa pesquisa.
Agradeço ao meu noivo, Éder Braga Martins, e minha mãe, Iracema Sena de Souza,
pelo apoio e confiança durante os momentos de fraqueza.
6
RESUMO
É comum as organizações possuírem um Processo de Desenvolvimento de Sistemas
(PDS) próprio, formalizado, cada um com suas características e métodos. Um PDS
consiste em um conjunto de passos ordenados e executados com o objetivo de criar um
sistema de informação, visando assegurar o desenvolvimento com prazos e necessidades
de recursos definidos, com alta produtividade, de forma econômica e com qualidade. As
áreas de Engenharia de Software (ES) e de Interação Humano-Computador propõem o
desenvolvimento de sistemas interativos de forma sistemática, definindo modelos,
técnicas, processos e métodos específicos. Entretanto, é comum ainda hoje,
encontrarmos trabalhos que discutem a integração das duas áreas. Para transpor a
dificuldade de fazer a integração de ES e IHC é necessária uma identificação mais
detalhada das tarefas a serem realizadas e a necessidade de uma boa comunicação entre
os especialistas das duas áreas durante o processo de desenvolvimento do sistema. Neste
sentido, com o intuito de verificar como estão estruturados os PDS nas organizações em
nossa região, foi desenvolvida uma pesquisa preliminar na qual foram analisados os
PDSs de seis instituições: três públicas e três privadas. E constatou-se que nenhum
destes PDS possuíam processos de IHC efetivamente formalizados, somente realizam
algumas atividades isoladas. Uma das instituições é a Secretaria de Estado de Gestão de
Mato Grosso (SEGES-MT, Brasil). Esta possui um PDS que foi desenvolvido com o
intuito de facilitar o intercâmbio de informações e experiências adquiridas no
desenvolvimento e manutenção de sistemas em todas as instituições do estado. Uma vez
que este PDS é utilizado como referência pelas instituições públicas do Estado de Mato
Grosso, na sua concepção, foi considerada a disparidade existente entre as equipes de
desenvolvimento de software de cada instituição. Por isso, as atividades e artefatos
recomendados no PDS são definidos como essenciais, pois é possível a inclusão de
outras atividades e artefatos conforme necessidade dos projetos. Neste trabalho é feita
uma análise detalhada de todo o documento PDS desta Secretaria, inicialmente com o
intuito de entender seu funcionamento e, em seguida analisou-se o processo afim de
identificar atividades presentes relacionadas a área de IHC. A partir desta análise uma
proposta de inserção de métodos, técnicas e atividades da área de IHC nas fases da PDS
é discutida.
Palavras-chave: Interação Humano-computador, Engenharia de Software,
Processo de Desenvolvimento de Sistemas.
8
SUMÁRIO
DEDICATÓRIA ............................................................................................................. 4
AGRADECIMENTOS ................................................................................................... 5
RESUMO ......................................................................................................................... 6
SUMÁRIO ....................................................................................................................... 8
LISTA DE FIGURAS ................................................................................................... 10
LISTA DE TABELAS .................................................................................................. 11
LISTA DE SIGLAS E ABREVIATURAS ................................................................. 12
INTRODUÇÃO ............................................................................................................ 13
1.1 APRESENTAÇÃO ............................................................................................... 13
1.2 OBJETIVOS ......................................................................................................... 15
1.2.1. OBJETIVO GERAL ...................................................................................... 15
1.2.2. OBJETIVOS ESPECÍFICOS ........................................................................ 15
1.3 JUSTIFICATIVA ................................................................................................. 15
1.4 METODOLOGIA ................................................................................................. 17
1.5 ORGANIZAÇÃO DO TRABALHO .................................................................... 17
INTERAÇÃO HUMANO-COMPUTADOR ............................................................. 18
2.1 ENGENHARIA DE USABILIDADE .................................................................. 18
2.2 MODELOS DE CICLO DE VIDA ....................................................................... 19
2.3 MÉTODOS E TÉCNICAS DE ENGENHARIA DE USABILIDADE................. 24
2.4 INTEGRAÇÃO COM ENGENHARIA DE SOFTWARE ................................... 28
2.5 TRABALHOS RELACIONADOS ...................................................................... 30
PROCESSO DE DESENVOLVIMENTO DE SISTEMAS DA SEGES-MT ......... 46
3.1 APRESENTAÇÃO ............................................................................................... 46
3.2 ANÁLISE DO PROCESSO .................................................................................. 52
PROPOSTA DE INTEGRAÇÃO ............................................................................... 56
4.1 CONSIDERAÇÕES INICIAIS ............................................................................ 56
4.2 A PROPOSTA ...................................................................................................... 58
CONSIDERAÇÕES FINAIS ....................................................................................... 70
REFERÊNCIAS ........................................................................................................... 72
APÊNDICE A - AUTORIZAÇÃO PARA PESQUISA ............................................ 78
APÊNDICE B - DOCUMENTO DE VISÃO ............................................................. 79
APÊNDICE C - DOCUMENTO DE REQUISITOS ................................................. 88
APÊNDICE D - PROJETO DE IHC .......................................................................... 95
APÊNDICE E - PLANO DE TESTE ........................................................................ 100
<APÊNDICE F - CASO DE TESTE ......................................................................... 114
APÊNDICE G - AVALIAÇÃO HEURÍSTICA ....................................................... 116
APÊNDICE H - DOCUMENTO DE HOMOLOGAÇÃO ...................................... 122
APÊNDICE I - TESTE DE USABILIDADE ........................................................... 126
APÊNDICE J - DOCUMENTO DE FEEDBACK .................................................. 129
ANEXO A - PDS SEGES-MT ................................................................................... 131
10
LISTA DE FIGURAS
Figura 1. Sequência genérica de atividades durante o processo de design [Fonte:
Barbosa; Silva, 2010] ..................................................................................................... 20
Figura 2. Modelo simples de design de interação [Fonte: PREECE et al., 2005] .......... 21
Figura 3. Modelo de ciclo de vida estrela [Fonte: BARBOSA; SILVA, 2010] ............. 22
Figura 4. Modelo de ciclo da engenharia de usabilidade de Débora Mayhew [Fonte:
PREECE et al., 2005] ..................................................................................................... 23
Figura 5. Proposta de adaptação do PDS DATAPREV [Fonte: DE SOUSA FERREIRA;
DE OLIVEIRA, 2010] .................................................................................................... 32
Figura 6. PDS da Fábrica GAIA [Fonte: MIRANDA et al., 2011] ................................ 33
Figura 7. Integração das visões do designer, desenvolvedor, cliente e usuário. [Fonte:
MIRANDA et al., 2011] ................................................................................................. 34
Figura 8. Modelo de integração da GD à Gerência de Requisitos do PDS GAIA [Fonte:
MIRANDA et al., 2011] ................................................................................................. 35
Figura 9. Modelo proposto com as ações de projeto da WebApp. [Fonte: DE SOUZA et
al., 2013] ......................................................................................................................... 36
Figura 10. Framework UEF-WEB [Fonte: SILVEIRA; SCHNEIDER, 2015] .............. 39
Figura 11. Roteiro Básico de Questões para Entrevista e Reunião. [Fonte: SILVEIRA;
SCHNEIDER, 2015] ...................................................................................................... 40
Figura 12. Artefato Formulário de Feedback. [Fonte: SILVEIRA; SCHNEIDER, 2015]
........................................................................................................................................ 40
Figura 13. Artefato Formulário de Inspeção. [Fonte: SILVEIRA; SCHNEIDER, 2015]
........................................................................................................................................ 41
Figura 14. Visão geral do processo de desenvolvimento de software de XPlus. [Fonte:
GUIMARAES et al., ] .................................................................................................... 42
Figura 15. Modelo de teste de usabilidade XPlus. [Fonte: GUIMARAES et al., ] ........ 43
Figura 16. Quadro Geral do PDS da SEGES-MT [Fonte: MATO GROSSO, 2010] ..... 47
Figura 17. Adaptações sugeridas ao PDS da SEGES-MT [Fonte: Adaptado de MATO
GROSSO, 2010] ............................................................................................................. 59
LISTA DE TABELAS
Tabela 1 - Técnicas de entendimento de requisitos de design ........................................ 25
Tabela 2 - Técnicas de representação de design ............................................................. 26
Tabela 3 - Técnicas de avaliação de design .................................................................... 27
Tabela 4 - Resumo das Fases do Modelo proposto [DE SOUZA et al., 2012] .............. 37
Tabela 5 - Resumo do PDS da SEGES-MT ................................................................... 48
Tabela 6 - Atividades de IHC identificadas no PDS ...................................................... 53
Tabela 7 - Adaptação do PDS na fase de Concepção ..................................................... 60
Tabela 8 - Adaptação do PDS na fase de Projeto ........................................................... 62
Tabela 9 - Adaptação do PDS na fase de Implementação .............................................. 63
Tabela 10 - Adaptação do PDS na fase de Teste ............................................................ 65
Tabela 11 - Adaptação do PDS na fase de Homologação .............................................. 66
Tabela 12 - Adaptação do PDS na fase de Implantação/ Encerramento ........................ 68
12
LISTA DE SIGLAS E ABREVIATURAS
CSS Cascading Style Sheets
CTI Coordenadoria de Tecnologia de Informação
ECMAScript JavaScript
ES Engenharia de Software
EU Engenharia de Usabilidade
GOMS Gols, Operators, Methods, and Selection Rules.
HTML HyperText Markup Language
IHC Interação Humano-Computador
MUMMS Measuring the Usability of Multi-Media Systems
PDS Processo de Desenvolvimento de Sistemas
SEGES-MT Secretaria de Estado de Gestão de Mato Grosso
SUMI Software Usability Measurement Inventory
SUS System Usability Scale
UWIS Methodology for Usability Assessment and Design of web based
Information Systems
W3C Cascading Style Sheets
XHTML Extensible Hypertext Markup Language
XML Extensible Markup
1
INTRODUÇÃO
1.1 APRESENTAÇÃO
Atualmente existem vários Processos de Desenvolvimento de Sistemas (PDS)
formalizados, cada um com suas características e métodos próprios. Um PDS consiste
em um conjunto de passos ordenados e executados com o objetivo de criar um sistema
de informação, visando assegurar o desenvolvimento com prazos e necessidades de
recursos definidos, com alta produtividade, de forma econômica e com qualidade.
Assim, Pressman (2011, p. 52) conceitua PDS como uma “metodologia para as
atividades, ações e tarefas necessárias para desenvolver um software de alta
qualidade”.
Diante dessa demanda pelo projeto de sistemas de qualidade e mais adequados às
necessidades do usuário, a área de interação humano-computador (IHC) tem despertado
cada vez mais interesse, devido a sua preocupação em melhorar a comunicação e
interação entre pessoas e sistemas. Como citado na Cartilha de Usabilidade do governo
Federal (2010), IHC refere-se à clareza e facilidade de uso de interfaces eletrônicas,
visando construir o conhecimento necessário para embasar o desenho de interfaces que
garantam uma boa usabilidade.
Da Silva (2014) afirma que tanto as áreas de IHC, quanto de Engenharia de
Software (ES) propõem o desenvolvimento de sistemas interativos de forma sistemática,
definindo modelos de técnicas, processos e métodos específicos. Para Barbosa e Silva
(2010), a área de IHC objetiva projetar e desenvolver sistemas com alta usabilidade, ou
seja, objetiva projetar, avaliar e implementar sistemas interativos para uso humano com
foco na facilidade de uso de aplicações. Já a área de Engenharia de Software (ES) tem
direcionado seus esforços para desenvolver sistemas levando em consideração fatores
14
relacionados à qualidade em engenharia, ou seja, no que diz respeito às fases de
construção instalação e manutenção de sistemas.
Para transpor a dificuldade de fazer a integração de ES e IHC é necessária uma
identificação mais detalhada das tarefas a serem realizadas e o estabelecimento de uma
boa comunicação entre os especialistas das duas áreas durante o processo de
desenvolvimento do sistema. É importante considerar os aspectos dessas duas áreas
durante o desenvolvimento de sistemas, pois assim é possível desenvolver sistemas que
sejam de fácil manutenção, que satisfaçam o usuário quanto ao prazo de entrega e ao
custo, que sejam mais confiáveis e de fácil utilização (DA SILVA, 2014).
A fim de conhecer o PDS utilizado pela Secretaria de Estado de Gestão de Mato
Grosso (SEGES-MT), foi realizada uma visita à Coordenadoria de Tecnologia de
Informação (CTI), vinculada à Superintendência de Administração Sistêmica, com o
intuito de investigar se o processo utilizado pela equipe incluía atividades de IHC. Para
isso, nesse primeiro momento, foram realizadas entrevistas com quatro servidores da
coordenadoria que afirmaram que o PDS da SEGES-MT não possuía práticas de IHC de
maneira efetiva, disponibilizando tal documento para constatação e estudo. É importante
salientar que para realização dessa pesquisa solicitou-se à SEGES-MT, consentimento
para disponibilização de dados sobre o PDS da Secretaria e autorização para realização
das entrevistas com os servidores da CTI da Secretaria. O documento de autorização de
pesquisa encontra-se no Apêndice A desse trabalho.
A CTI é responsável por todas as atividades de desenvolvimento, manutenção e
suporte em tecnologia de informação da SEGES-MT. O setor nos disponibilizou o
documento utilizado pela secretaria como guia para o desenvolvimento de sistemas, que
está no Anexo I desse trabalho. Assim foi possível fazer uma análise do PDS da
SEGES-MT, que será apresentada de maneira mais detalhada no Capítulo 03 desse
trabalho.
1.2 OBJETIVOS
1.2.1. OBJETIVO GERAL
O objetivo geral desse trabalho é apresentar uma proposta de integração de
práticas de IHC ao PDS da SEGES-MT, visando garantir o atendimento aos critérios de
usabilidade no desenvolvimento de sistemas e, consequentemente, aumentar a
aceitabilidade do produto de software pelos usuários e clientes da Secretaria.
1.2.2. OBJETIVOS ESPECÍFICOS
Os objetivos específicos relacionam os resultados que se pretende alcançar, na
forma de etapas a serem cumpridas para a realização do objetivo geral. Levando isso em
consideração foram definidos os seguintes objetivos específicos para esse trabalho:
Pesquisar sobre a importância de IHC no desenvolvimento de sistemas;
Estudar os diferentes tipos de práticas de IHC voltadas para o design de
interfaces e suas aplicações no projeto de sistemas;
Pesquisar trabalhos semelhantes que agreguem valor ao projeto;
Analisar detalhadamente o PDS da SEGES-MT;
Sugerir adaptações ao PDS da SEGES-MT afim de inserir atividades de IHC.
1.3 JUSTIFICATIVA
Durante o desenvolvimento de Sistemas de Informação, a participação do
usuário é fundamental, uma vez que uma experiência de uso de baixa qualidade diminui
a produtividade, aumenta a possibilidade de erro, desmotiva a interação e requer maior
treinamento e aprendizado, podendo levar ao fracasso de negócios e serviços
(BARBOSA; SILVA, 2010).
16
A fim de minimizar tais problemas e garantir a aceitabilidade dos sistemas pelos
usuários, tem-se procurado inserir atividades de IHC nas fases de desenvolvimento de
sistemas de modo a incluir o usuário de maneira efetiva ao desenvolvimento de
sistemas.
Esse trabalho originou-se de uma atividade desenvolvida na disciplina de Projeto
de Interfaces do Curso de Especialização em Engenharia Web e Governo Eletrônico, do
Instituto de Computação da UFMT, em que foram analisados os PDSs de seis
instituições, três públicas e três privadas, com o intuito de verificar se havia integração
entre as áreas de ES e IHC nos PDSs utilizados por essas instituições.
Ao analisar os trabalhos da atividade constatou-se que as instituições não
possuem processos de IHC formalizados efetivamente nos PDSs correspondentes,
porém foram identificadas algumas atividades de IHC em cada um deles.
A instituição que possui a área de IHC mais avançada é uma empresa privada
que possui um profissional responsável pelo controle de qualidade e documentação,
padronizações de interface e teste de usabilidade. As outras duas empresas privadas
procuram atender requisitos de usabilidade durante a prototipação dos sistemas. Em
duas instituições públicas o desenvolvedor é responsável por validar os quesitos de
qualidade e usabilidade dos sistemas através de testes unitários. O PDS da SEGES-MT
possui, além disso, dois papéis definidos exclusivamente para atividades relacionados a
teste: o “Projetista de Teste” que planeja e implementa os procedimentos de teste e o
“Testador” que executa os testes propriamente ditos. No capítulo 3 desse trabalho será
feito uma descrição mais aprofundada do PDS da SEGES-MT.
A equipe de desenvolvimento e manutenção de sistemas da CTI da SEGES-MT
é composta por oito servidores, seis efetivos e dois contratados, sendo que o
desenvolvimento de sistemas é realizado de maneira individual. Por exemplo, o último
sistema desenvolvido pela coordenadoria, foi um sistema de frequência de assiduidade,
criado por um servidor terceirizado, que também está dando manutenção ao mesmo.
Porém a CTI futuramente sofrerá uma reestruturação e pretende aumentar seu quadro de
servidores, por isso este trabalho pode ser importante na tomada de decisões durante
esse processo, no que diz respeito à definição da equipe de desenvolvimento,
especialmente profissionais de IHC, por exemplo.
1.4 METODOLOGIA
O trabalho foi desenvolvido a partir de pesquisa aplicada e exploratória. O
Estudo bibliográfico teve como finalidade conhecer as diversas formas de contribuições
científicas já realizadas com foco na integração das áreas de IHC e ES pertinentes ao
tema de pesquisa. A partir desse estudo foi possível, após análise experimental do PDS
da SEGES-MT, elaborar uma proposta de melhoria do processo, descrita no capítulo 4
desse trabalho.
1.5 ORGANIZAÇÃO DO TRABALHO
Este trabalho está estruturado em cinco capítulos: no capítulo seguinte são
apresentados alguns conceitos acerca de IHC, destacando a importância e benefícios da
integração entre as áreas de IHC e ES, além de descrever e citar alguns trabalhos
relacionados e alguns métodos e técnicas de EU (Engenharia de Usabilidade). No
terceiro capítulo é apresentado o PDS da SEGES-MT resumidamente, descrevendo as
atividades relacionadas a área de IHC presentes nas fases do processo. Já no quarto
capítulo é apresentada a proposta desse trabalho, assim como as atividades de IHC,
métodos, técnicas e artefatos sugeridos. Por fim, o trabalho encerra-se com algumas
considerações acerca dos resultados obtidos e sugestões de trabalhos futuros.
18
2
INTERAÇÃO HUMANO-COMPUTADOR
Interação humano-computador (IHC) é uma área de pesquisa dedicada a estudar os
fenômenos de comunicação entre sistemas computacionais e pessoas, de acordo com
GASPARINI (2013 apud ACM SIGCHI). Barbosa e Silva (2010 apud HEWETT et al.,
1992, p.10) conceituam IHC como “uma disciplina interessada no projeto,
implementação e avaliação de sistemas computacionais interativos para o uso humano,
juntamente com os fenômenos relacionados a esse uso”.
A área de IHC está relacionada com diversas áreas do conhecimento: Ciência da
Computação, Sistemas de Informação, Linguística, Semiótica, Psicologia, Antropologia,
Engenharia, Design, etc., sendo uma área multidisciplinar, que envolve diversas
disciplinas, buscando a solução de um problema, interdisciplinar, que há diferentes
disciplinas que podem adotar uma perspectiva metodológica comum, e em constante
evolução (GASPARINI, 2013; DE SOUZA et al., 2008).
De acordo com Barbosa e Silva (2010) a área de IHC privilegia a qualidade de
uso dos sistemas interativos. Nesse contexto, o aumento da qualidade de uso de sistemas
apresenta vários benefícios para a experiência do usuário: aumento da produtividade;
redução do número e gravidade dos erros cometidos; redução do custo de treinamento,
do suporte técnico e do desenvolvimento; aumento das vendas e fidelidade do cliente ou
usuário. Por isso a importância do estudo e cuidado da interação entre pessoas e
sistemas computacionais.
2.1 ENGENHARIA DE USABILIDADE
Os aspectos da Engenharia de Usabilidade (EU) são fundamentais no contexto de
ES. Da Costa e Ramalho (2010 apud QUEIROZ, 2001, p.14) define engenharia de
usabilidade como “uma área de conhecimento na qual os pesquisadores e
desenvolvedores procuram desenvolver e implementar técnicas que sistematicamente
tornem os produtos de software mais usáveis, otimizando os produtos através da
otimização do processo”.
A EU está focada na interface do software com o usuário, diferentemente da ES
que direciona a atenção para a lógica de funcionamento do sistema. Assim, EU é um
processo de construção de interfaces que visa proporcionar facilidade de aprendizado e
de uso e satisfação dos usuários ao interagir com as interfaces de um sistema
(SILVEIRA; SCHNEIDER, 2015 apud BARANAUSKAS, 2003).
É importante destacar que Rabello (2012), encontrou alguns trabalhos que
buscavam integrar EU a ES, através de revisão do estado da arte, que mostraram que
este é um processo difícil, porém, apresenta grandes benefícios para qualidade do
produto final.
Segundo Da Costa e Ramalho (2010) o termo usabilidade começou a ser utilizado
na década de 1980, como um substituto da expressão user-friendly, principalmente nas
áreas de Psicologia e Ergonomia. No trabalho de Silveira e Schneider (2015 apud ISSO,
2010) conceitua-se usabilidade como um atributo de qualidade associado à facilidade e
eficiência de uso e ao grau de satisfação em se fazer algo. Já para Rabello et al. (2012)
usabilidade é a medida na qual um produto pode ser utilizado por usuários específicos
para atingir objetivos bem definidos com eficácia, eficiência e satisfação em um
contexto de aplicação também específico. Nesse cenário, Preece et al. (2005, p. 35-36)
afirma que a usabilidade é dividida em cinco metas: ser fácil de usar (eficácia); ser
eficiente no uso (eficiência); ser segura no uso (segurança); ser de boa utilidade
(utilidade); ser fácil de aprender (learnability) e fácil de lembrar como de usa
(memorability).
2.2 MODELOS DE CICLO DE VIDA
As atividades básicas do design de interação, segundo Preece et al. (2005),
consistem em identificar necessidades e estabelecer requisitos, desenvolver designs
alternativos, construir versões interativas dos designs e avalia-las. Barbosa e Silva
20
(2010) apresentam o processo em três atividades básicas: a análise da situação
(identificação do problema), síntese de uma intervenção e a avaliação dessa intervenção
projetada ou já aplicada à situação atual. As autoras ressaltam que essas atividades são
detalhadas de forma particular em cada processo, no que diz respeito a execução,
sequência, atividades que devem repetir, artefatos consumidos e produzidos etc. A
Figura 1 ilustra essa sequência genérica de atividades que engloba cada modelo de ciclo
de vida em IHC.
Figura 1. Sequência genérica de atividades durante o processo de design [Fonte:
Barbosa; Silva, 2010]
Os processos de design de IHC envolvem, segundo Preece et al. (2005), a
execução das atividades de forma interativa permitindo refinamentos sucessivos do
design com base em feedbacks dos usuários. Corroborando, Barbosa e Silva (2010)
enfatizam o foco no usuário, ressaltando a necessidade de atender e servir os usuários e
demais envolvidos (stakeholders), ajudando-os a alcançar seus objetivos. Nesse
contexto, o projeto de interação e interface do sistema interativo devem ser centrados no
usuário.
Existem muitas propostas de processos de design de IHC na literatura, nesse
trabalho serão apresentadas sucintamente apenas quatro delas: modelo de ciclo de vida
simples, modelo de ciclo de vida estrela e modelo de ciclo de vida da engenharia de
usabilidade de Jakob Nielsen e de Débora Mayhew.
O modelo de ciclo de vida simples para o design de interação foi proposto por
Preece et al. (2005) e ilustrado na Figura 2. Nesse modelo, cada atividade pode retornar
a uma atividade anterior para aprimorar ou corrigir algum requisito ou artefato. A
iteração entre as atividades ocorre quantas vezes forem necessárias sendo limitadas
apenas pelos recursos disponíveis. O desenvolvimento termina com uma atividade de
avaliação que garante que o produto final, ou uma especificação da interação e da
interface com o usuário, respeite os critérios de usabilidade prescritos.
Figura 2. Modelo simples de design de interação [Fonte: PREECE et al., 2005]
O modelo de ciclo de vida estrela foi proposto por Hix e Hartson na década de
1990 (BARBOSA; SILVA, 2010) e tem como principal característica a alta
flexibilidade. Esse processo, que pode ser observado na Figura 3, não especifica
ordenamento das atividades que o compõem, sendo estas altamente conectadas: pode-se
ir de uma para outra atividade, contudo que se passe pela atividade central de avaliação
(PREECE et al., 2005).
22
Figura 3. Modelo de ciclo de vida estrela [Fonte: BARBOSA; SILVA, 2010]
O Modelo de ciclo de vida da engenharia de usabilidade de Débora Mayhew foi
proposto por ela em 1999. Segundo Preece et al. (2005, p.214), esse modelo oferece
uma visão holística acerca da engenharia de usabilidade, uma descrição detalhada de
como realizar testes de usabilidade e especifica como tarefas de usabilidade podem ser
integradas nos ciclos de vida tradicionais da ES. Esse ciclo de vida possui três, tarefas:
análise de requisitos, onde são definidas metas de usabilidade que devem ser captadas
em um guia de estilo utilizado em todo o projeto; projeto/teste/implementação, que
envolve maior número de subtarefas; e instalação, conforme Figura 4.
Figura 4. Modelo de ciclo da engenharia de usabilidade de Débora Mayhew
[Fonte: PREECE et al., 2005]
Em 1993, Jakob Nielsen definiu engenharia de usabilidade, em seu modelo de
ciclo de vida, como o seguinte grupo de atividades que devem ocorrer durante o
processo de desenvolvimento do produto: conhecer seu usuário; realizar uma análise
24
competitiva; definir as metas de usabilidade; fazer designs paralelos; adotar o design
participativo; fazer o design coordenado da interface como um todo; aplicar diretrizes e
análise heurística; fazer protótipos; realizar testes empíricos e praticar design iterativo
(BARBOSA, 2010).
É importante ressaltar que, os modelos de ciclo de vida fornecem instruções, por meio
de princípios e atividades de projeto, que ajudam no desenvolvimento de interfaces com
maior qualidade de uso. Esses modelos, como os apresentados nessa seção, procuram
sustentar o desenvolvimento de soluções de interfaces mais sólidas, que respondam
positivamente às expectativas dos usuários. Entretanto não fornecem detalhes sobre
instrumentos e artefatos de apoio às atividades que os compõe, o que, na prática, dificulta a
realização dessas atividades e, consequentemente, a conquista dos objetivos estabelecidos
(SILVEIRA, SCHNEIDER, 2015).
2.3 MÉTODOS E TÉCNICAS DE ENGENHARIA DE USABILIDADE
Nas últimas décadas foram propostos vários métodos e técnicas para EU, que
podem ajudar as organizações a realizar atividades como, por exemplo, levantamento e
registro de informações, definição e especificação de requisitos, projeto e
desenvolvimento de versões de interfaces, avaliação de soluções, dentre várias outras.
(SILVEIRA; SCHNEIDER, 2015). Nessa seção são apresentadas resumidamente
algumas dessas técnicas e métodos.
De acordo com Silva e Mendonça (2014 apud BERVIAN et al. 2002) técnicas são
procedimentos específicos utilizados por uma ciência determinada, sendo que um
conjunto dessas técnicas constituem os métodos. Silva e Mendonça (2014 apud CYBIS
et al. 2010) ainda dividem as técnicas e métodos de EU em três grupos: concepção,
análise e avaliação. Nesse trabalho resolveu-se dividir as técnicas de EU também em
três grupos, porém considerando o estudo de algumas obras, principalmente de Benyon
(2011). A partir do estudo dessas publicações, resolveu-se dividir as técnicas
apresentadas em três tipos: técnicas de entendimento de requisitos de design, técnicas de
representação de design e técnicas de avaliação de design.
As técnicas de entendimento dos requisitos de design têm como objetivo
principal ajudar o designer a entender as pessoas que estão envolvidas no produto ou
sistema, suas atividades, os contextos que essas atividades estão inseridas e as
aplicações para o design que as tecnologias representam. Assim essas técnicas ajudam
os designs a identificar, de maneira geral, os requisitos de design no contexto de um
produto ou sistema. A Tabela 1 apresenta algumas técnicas de entendimento de
requisitos de design amplamente utilizadas e uma descrição resumida de cada uma
delas.
Tabela 1 - Técnicas de entendimento de requisitos de design
Técnica Descrição
Entrevistas
Uma maneira vital de reunir histórias é conversando com os
stakeholders afim de descobrir o que querem e quais
problemas possuem. As entrevistas estruturadas utilizam
perguntas elaboradas com antecedência e seguem um roteiro
com precisão (BENYON, 2011).
Cenários/ histórias
Histórias são experiências reais, ideias, fatos e conhecimentos
das pessoas que podem ser capturados de diversas formas.
Cenários são histórias sobre pessoas realizando atividades em
contextos, usando determinadas tecnologias. Essa técnica é
utilizada na ES, no design de sistemas interativos e nos
trabalhos de IHC há anos (BENYON, 2011).
Questionários
É uma maneira de obter informação com os stakeholders a
distância. Coletar grande quantidade de dados quantificáveis
ou captar respostas de pessoas que não podem se envolver
diretamente (BENYON, 2011).
Personas
Representação de um grupo de usuários reais criada para
descrever usuários típicos utilizando como critérios de criação
seus objetivos (BARBOSA; SILVA, 2010).
Card Sorting
Refere-se a uma série de técnicas voltadas para o
entendimento de como se classificam e categorizam as coisas.
Pode ser feita de várias maneiras, a mais básica consiste em
escrever conceitos em cartões e depois agrupa-los de diversas
maneiras (BENYON, 2011).
Brainstorming
Uma atividade em grupo que visa levantar de forma bastante
livre um conjunto grande e abrangente de opiniões e ideias
dos participantes em torno de um tema. Fornece mais
26
benefícios quanto aplicada na fase conceitual do
desenvolvimento do produto (BARBOSA; SILVA, 2010).
Focus Groups
Nessa técnica um facilitador realiza um conjunto de perguntas
específicas para um grupo de pessoas, que são estimuladas a
interagir aos comentários umas das outras. Os grupos de
interesse podem ser aperfeiçoados com protótipos e outros
estímulos (BENYON, 2011).
Estudo da
documentação
Procedimento que não compromete o tempo dos stakeholders
e ajudam substancialmente no entendimento de requisitos.
São exemplo de documentações que podem ser estudadas:
manuais, diários ou logs de trabalho, legislação etc
(BENYON, 2011).
Observação natural
Essa técnica é interessante quanto há dificuldades por parte
dos stakeholders em descrever o que fazem e como realizam
suas tarefas. Nesse caso o observador acompanha de perto um
deles, tomando notas, fazendo algumas perguntas e
observando o que está sendo feito no contexto natural da
atividade (PREECE et al., 2005).
GOMS
É um método que tem como objetivo descrever tarefas e o
conhecimento do usuário sobre como realizar-las em termos
de objetivo, operadores, métodos e regras de seleção. A
análise desse método aplica-se principalmente a situações em
que o usuário realizam tarefas que dominam muito bem
(BARBOSA; SILVA, 2010).
As técnicas de representação de design têm como objetivo principal ajudar o
designer a tornar suas ideias visíveis, ajudam na geração, comunicação e avaliação junto
aos envolvidos das propostas apresentadas. A Tabela 2 apresenta resumidamente
algumas técnicas (BENYON, 2011) de representação de requisitos de design muito
utilizadas e também uma descrição resumida dessas técnicas.
Tabela 2 - Técnicas de representação de design
Técnica Descrição
Esboços Nessa técnica idéias e pensamentos podem ser rapidamente
visualizados e explorados.
Storyboards
Técnica extraída do cinema que possui uma estrutura simples
no estilo de desenho animado. É uma opção muito econômica
e vantajosa por permitir uma percepção do “fluxo” da
experiência.
Mapas de
Navegação
Enfocam como as pessoas se movimentam pelo site ou
aplicação, de maneira a evidenciar a experiência das pessoas
ao utilizar o produto de software.
Mapas mentais/
Fluxogramas
Os mapas mentais relacionam os principais conceitos de
design, evidenciando suas ligações. Os fluxogramas mostram
informações através da representação gráfica, utilizando
símbolos gráficos, para descrever passo a passo a natureza e o
fluxo do processo de design.
Protótipos
É uma representação ou implementação efetiva, porem
incompleta, do design de um sistema. Podem ser usados para
demostrar conceitos nas fases iniciais do design, para testar
detalhes desses conceitos nas fases posteriores e até mesmo
como especificação para o produto final. Pode ser feito de
materiais simples, como papel e papelão, e muito complexo,
sendo desenvolvido com um pacote de software sofisticado.
Por fim, as técnicas de avaliação de design têm como objetivo auxiliar o designer
a revisar, experimentar ou testar uma ideia de design, um sistema, produto ou serviço e
descobrir se esse atende a alguns critérios estabelecidos. A Tabela 3 apresenta
resumidamente algumas técnicas de avaliação de design utilizadas e suas descrições
resumidas.
Tabela 3 - Técnicas de avaliação de design
Técnica Descrição
Avaliação heurística
Existem dois tipos principais: métodos baseados em
especialista e métodos com participantes. A avaliação
heurística consiste em examinar o design proposto e avaliar
sua qualificação considerando uma lista de princípios,
diretrizes ou “heurísticas” (BENYON, 2011).
Acompanhamento
cognitivo
Um profissional de usabilidade percorre passo a passo as
tarefas cognitivas que precisam ser realizadas na interação
com a tecnologia. Envolve simular um processo de solução
de problemas, verificando se é possível constatar que os
objetivos e a memória dos usuários conduzem a uma próxima
ação correta (PREECE et al., 2005).
Teste de usabilidade
Tem o objetivo de avaliar a usabilidade de um sistema
interativo a partir de experiências do uso de seus usuários,
sendo que os critérios utilizados são definidos dependendo
dos objetivos da avaliação (BARBOSA; SILVA, 2010).
28
Checklists
Técnica de inspeção que oferece uma abordagem rápida, fácil
e de baixo custo para a avaliação de interfaces, permitindo
que usuários que não são especialistas em usabilidade
identificarem problemas menores e repetitivos (SILVA;
MENDONÇA, 2014 apud CYBIS et al., 2010).
Avaliação de
comunicabilidade
Esse método consiste na aplicação de avaliações de
comunicabilidade a um grupo pequeno de usuários em
ambiente controlado e tem o objetivo de avaliar a qualidade
da recepção da metacomunicação do designer pelo usuário,
sendo um método qualitativo de análise profunda
(BARBOSA; SILVA, 2010).
É através da comunicação que as soluções de design surgirão, serão avaliadas e
serão transformadas em um produto final (BENYON, 2011). Daí a importância da
preocupação em manter uma comunicação clara e eficiente entre os envolvidos no
desenvolvimento do produto de software.
As técnicas descritas nessa seção podem ser combinadas entre si e com outras
técnicas, sendo que para a escolha de cada uma é importante analisar as possibilidades
dos recursos necessários e disponíveis e as expectativas de resultados da avaliação de
usabilidade (SILVA; MENDONÇA, 2014).
2.4 INTEGRAÇÃO COM ENGENHARIA DE SOFTWARE
A área de IHC, desde sua origem, tem sido proposta em contraste com o
desenvolvimento centrado no sistema tipicamente praticado pela ES (BARBOSA;
SILVA, 2010 apud NORMAN; DRAPER, 1986; SHNEIDERMAN 1998; SHARP et
al., 2007). Para Barbosa e Silva (2010) reforçam afirmando que as áreas de IHC e ES
possuem perspectivas diferentes sobre o que é importante em sistemas interativos, no
que diz respeito ao desenvolvimento e significado de utilização. Segundo eles, na
perspectiva de design centrado no sistema, os fatores de qualidade mais valorizados
estão relacionados com a construção do sistema interativo (disponibilidade, integridade,
robustez, manutenibilidade e recuperabilidade) e que para alcançar tais fatores essa
perspectiva foca em conceitos fundamentais para a construção de sistemas interativos
como, por exemplo, a arquitetura do sistema, estrutura de dados, mecanismos de
persistências desses dados, comunicação entre sistemas, linguagens de programação,
ambiente de desenvolvimento etc.
Já a perspectiva do design centrada no uso, tipicamente utilizada pela área de
IHC, tem o objetivo de desenvolver um sistema interativo que apoie o usuário na
realização de suas tarefas e alcance de seus objetivos. Para tanto, trabalha com conceitos
relacionados ao uso do sistema, tais como: contextos de usos, objetivos dos usuários,
características dos usuários, possíveis formas de interação do usuário com a interface do
sistema.
Levando em consideração esse contraste de perspectivas, para tornar o
desenvolvimento de sistemas interativos de qualidade é necessário conciliar as boas
práticas tanto de ES quanto de IHC, afim de evitar problemas de usabilidade e
consequentemente experiências de uso de baixa qualidade (BASTOS; OLIVEIRA,
2010). Para isso, Barbosa e Silva (2010, p.123) apresentam as três principais
abordagens de integração de processos de IHC e ES: definição de características de um
processo de desenvolvimento que se preocupa com a qualidade de uso; definição de
processos de IHC paralelos que devem ser incorporados aos processos propostos pela
ES; indicação de pontos em processos propostos pela ES em que atividades e métodos
de IHC podem ser inseridos. No capítulo 4 é feito uma descrição das abordagens de
integração utilizadas nesse trabalho.
Os principais desafios encontrados para essa integração, segundo Rabello (2012
apud ANDERSON et al. 2001, p.60), resume-se na boa comunicação entre os
profissionais das duas áreas e entendimento dos processos de desenvolvimento
propostos por cada uma. O autor lista os seguintes desafios: “compreensão dos
processos, do vocabulário e ferramentas utilizados pelas equipes; alinhamento das
ferramentas usadas pelas equipes de desenvolvimento; capacidade de cada elemento de
ambas as equipes abordarem os desenvolvedores, independentemente de sua formação
e experiência; capacidade da equipe de usabilidade de explicar como integrar o projeto
centrado no usuário em qualquer um dos processos de desenvolvimento; mudança
cultural e organizacional”.
30
Corroborando, Da Silva (2014) afirma que para superar os desafios da integração
entre as duas áreas é necessária uma identificação mais detalhada das tarefas a serem
realizadas e a necessidade de uma boa comunicação entre os especialistas das duas áreas
durante todo PDS, pois assim é possível desenvolver sistemas que sejam de fácil
manutenção, que satisfaçam o usuário quanto ao prazo de entrega e custo, que o tornem
mais confiável e de fácil utilização.
2.5 TRABALHOS RELACIONADOS
Há muitos trabalhos publicados sobre IHC no contexto de desenvolvimento de
sistemas, entretanto poucos abordam todas as fases de desenvolvimento (DIAS, 2010).
Com relação a quantidade de publicações, o trabalho de Gasparini et al. (2013)
corrobora tal afirmação, uma vez que apresenta, dentro do período de 15 anos, uma
exploração visual de 236 artigos completos do IHC, submetidos ao principal evento da
SBC na área: o simpósio IHC, desde sua primeira ocorrência em 1998.
Durante a fase de levantamento bibliográfico procurou-se por publicações que
objetivavam contornar a dificuldade de fazer a integração entre as áreas de IHC e ES.
Foram encontradas publicações na área de dispositivos móveis (DE LIMA JUNIOR et
al., 2016), avaliações de usabilidade em sistemas (KLOCK et al. 2016), (DE
OLIVEIRA et al., 2016), dentre outros (BARBOSA; FURTADO, 2008), (DE
OLIVEIRA et al., 2004), (PRATES; BARBOSA, 2007), (BIM, 2010), (MIRANDA;
DE BARROS, 2011), (PEREIRA; PAIVA, 2011), (VALENTIM; DE OLIVEIRA,
2012), (VILLELA et al., 2012), (DE OLIVEIRA et al. 2012), (DE MENDONÇA; DA
SILVA, 2014), (GOMES; CENDÓN, 2015), (DE SOUZA; FERNANDES, 2015).
Além desses, o trabalho de Dias (2010) descreve uma revisão sistemática sobre a
inserção de acessibilidade nas fases de desenvolvimento da ES em sistemas Web, com
base no grupo de processos de Engenharia da Norma ISSO/IEC 12207. Já Lapolli
(2011) propõe um modelo integrado de desenvolvimento de sistemas embasado no uso
de metodologias ágeis de ES com conceitos de IHC para o desenvolvimento de objetos
de aprendizagem baseados em simulações. O modelo apresentado por Lapolli aborda as
principais fases do PDS educacional: levantamento de requisitos, projeto instrucional,
projeto de interface e a metodologia de desenvolvimento.
Lapolli (2011) propõe na etapa de Levantamento de Requisitos do modelo a
aplicação do método Gols, Operators, Methods, and Selection Rules (GOMS). O
resultado dessa etapa consiste na criação de modelos ágeis que fazem a descrição das
necessidades do usuário e os objetivos da tarefa. Na próxima etapa, Ciclo Inicial de
Produção, o processo de identificação da solução de projeto é guiado por avaliações de
interface do usuário sendo proposto a geração de protótipos mais detalhados e
interativos e o refinamento de cenários. No ciclo de Construção e Testes de pequenas
versões é proposto a criação de unidades de testes de aceitação, que são utilizados para
avaliar as partes da arquitetura do sistema e da interface do usuário. E finalmente nas
últimas etapas do ciclo, Implementação e Produção, novas funcionalidades podem ser
solicitadas, assim como, questões de usabilidade e de design podem ser levantadas,
sendo possível retornar as fases anteriores para atender a essas novas exigências.
Em De Araújo Camargo e Fazani (2014) são apresentados alguns princípios e
práticas de Design Participativo que podem ser utilizados no contexto da ES durante o
processo de coleta e tratamento de informação. Princípios que levam em consideração
tanto o design direcionado para o usuário, quanto as experiências dos usuários no
design. São eles: depoimentos, oficinas, maquetes, descrição de cenários, card-sorting,
análise de redes sociais, braindraw, prototipação, etc. Os autores ainda afirmam que a
prática deve ser mais explorada no contexto de “interação usuário-sistema” e que
depende muito da situação de modo que não se pode generalizar, porém alguns
elementos são recorrentes no processo.
A seguir são descritas cinco publicações mais detalhadamente, dando foco nas
propostas de integração entre as áreas de IHC e ES apresentadas por elas. Tais
publicações são semelhantes a essa pesquisa e contribuíram substancialmente para a
elaboração da proposta desse trabalho. O capítulo 4 apresenta detalhadamente a
32
contribuição de cada publicação, descrevendo as atividades de IHC propostas por elas
adicionadas no PDS da SEGES-MT.
a) Inclusão de usabilidade no processo de desenvolvimento de software da
DATAPREV (DE SOUSA FERREIRA; DE OLIVEIRA, 2010)
O trabalho De Sousa Ferreira e De Oliveira (2010) descreve como se deu a
inclusão de usabilidade no PDS da DATAPREV, que é baseado no RUP, abreviação de
Rational Unified Process (ou Processo Unificado da Rational). Após análise constatou-
se que a metodologia utilizada apresentava lacunas quanto aos aspectos relacionados à
usabilidade. A fim de minimizar tais problemas, propôs-se adaptação do processo de
forma que envolvesse práticas do desenvolvimento centrado no usuário. Para isso foram
feitas reuniões e entrevistas de maneira à elicitar os principais problemas de usabilidade
e identificar práticas isoladas de projeto centrado no usuário, levando em consideração o
contexto dos projetos da empresa. A Figura 5 ilustra a proposta de adaptação realizada
no processo. No trabalho, essas atividades não foram detalhas.
Figura 5. Proposta de adaptação do PDS DATAPREV [Fonte: DE SOUSA
FERREIRA; DE OLIVEIRA, 2010]
Com a adaptação do PDS, que não foi detalhada no trabalho, os autores
esperavam que os problemas encontrados fossem minimizados, tais como: dificuldade
na execução das tarefas por parte dos usuários; mensagens de erro inadequadas;
padronização incipiente de elementos de interface; maior necessidade de treinamento;
manual de ajuda ineficiente; ausência de ajuda contextual online; e grande número de
chamados ao suporte.
b) A integração da Gestão do Design a um Processo de Desenvolvimento de
Software de maturidade nível G uma experiência acadêmica na Fábrica de
Software GAIA (MIRANDA et al., 2011)
O trabalho de Miranda et al. (2011) apresenta um modelo de integração da
gestão do design ao PDS utilizado na fábrica de Software GAIA, que é um projeto de
pesquisa e extensão da Universidade Estadual de Londrina (UEL), no qual viabilize e
facilite sua melhoria contínua visando obter níveis elevados de maturidade no modelo
MPS.Br (Melhoria de Processo do Software Brasileiro). A partir de uma visão de
gerenciamento baseada no PMBOK, o PDS da GAIA contempla oito macroatividades,
ilustrado na Figura 6: análise inicial, análise e planejamento, execução e
implementação, validação e teste, entrega, finalização, manter requisitos e gerenciar
portfólio.
Figura 6. PDS da Fábrica GAIA [Fonte: MIRANDA et al., 2011]
34
Com o intuito de dar andamento ao processo de integração da Gestão de Design
ao PDS GAIA foi feita a inclusão de um gestor de design a fábrica, de modo a
apresentar um modelo de incorporação sob uma perspectiva de design integradora de
funções. A principal ação para viabilizar esse processo de integração foi a inclusão da
visão do designer no PDS de forma altamente conectada a necessidade do negócio e as
características do sistema (Figura 7).
Figura 7. Integração das visões do designer, desenvolvedor, cliente e usuário.
[Fonte: MIRANDA et al., 2011]
As alterações foram feitas na macroatividade análise e planejamento do PDS,
implantando as atividades de geração de ideias como auxílio à etapa de levantar
Requisitos e Arquitetura da Informação e Design da Informação auxiliando as
atividades Expandir a WBS, Revisar Requisitos e Validar Requisitos, conforme Figura
8. No trabalho a proposta foi exemplificada através do estudo de caso de um sistema de
prontuários odontológicos.
Figura 8. Modelo de integração da GD à Gerência de Requisitos do PDS GAIA
[Fonte: MIRANDA et al., 2011]
Na etapa de Gestão de Design integrada à Gerência de Requisitos o gestor de
desing deve conduzir a definição de três itens: identificação dos usuários, situações,
cenários e contextos de uso; equalização dos fatores projetuais (econômicos,
geométricos, filosóficos, mercadológicos, psicológicos, tecnológicos, ergonômicos,
ecológicos e antropológicos); organização do produto. As técnicas sugeridas pelos
autores são: geração de alternativas, que consiste na utilização de ferramentas como
brainstorming, card sorting etc; etnografia rápida que consiste em estudos cujo objetivo
é fornecer informações sobre o ambiente onde o sistema será implantado e entrevistas
com usuários.
O artefato resultante da atividade auxiliar à etapa de Levantar Requisitos é o
levantamento de requisitos não funcionais, como as necessidades do cliente e dos
possíveis usuários do sistema a ser desenvolvido e aspectos favoráveis à melhoria da
experiência do usuário. Já para as atividades complementares às etapas de Revisar e
Validar Requisito sugeriu-se a modelagem do registro dos requisitos dos usuários do
sistema, com a definição das suas principais ações, criação do fluxo de navegação dos
usuários e relacionamento dos usuários com as telas do sistema.
36
Por fim, os autores concluiram afirmando que, com o estudo realizado, foi
possível constatar que a Gestão de Design pode integrar-se facilmente ao processo de
Gerência de Requisitos, auxiliando e contribuindo para a melhoria do processo de
desenvolvimento de softwares.
c) Projetando sistemas web com o uso de técnicas de interação humano-
computador (DE SOUZA et al., 2012)
O trabalho De Souza et al. (2012) descreve uma proposta de integração de
técnicas de projeto de IHC no desenvolvimento de aplicações Web, baseando-se em um
arcabouço ágil dentro da ES, que contempla o projeto de interface, estético, de
conteúdo, funcional, navegacional, de componente e arquitetural. A Figura 9 apresenta
o modelo proposto no trabalho:
Figura 9. Modelo proposto com as ações de projeto da WebApp. [Fonte: DE
SOUZA et al., 2013]
O modelo proposto por De Souza et al. permite que as ações sejam executadas
ciclicamente, tendo o usuário como centro do processo. Para cada etapa são propostas
ações, métodos, técnicas e artefatos. A Tabela 4 descreve as etapas, atividades e
artefatos sugeridos pelos autores no modelo proposto.
Tabela 4 - Resumo das Fases do Modelo proposto [DE SOUZA et al., 2012]
Etapa Atividades Artefatos
Projeto de
informação: junção dos
projetos de conteúdo e
arquitetura.
Definição do conteúdo; análise
sobre a necessidade de um
sistema de gerenciamento de
conteúdo; definição da estrutura
conceitual do conteúdo;
detalhamento dos elementos
tecnológicos.
Definição dos conteúdos
e elementos necessários
para a aplicação;
Prototipação:
storyboarding e
wireframe;
Projeto de navegação:
baseado no projeto de
informação.
Descrição da sintaxe e da
semântica de navegação;
elaboração do mapa de
navegação.
Mapa de Navegação;
definição da semântica
de navegação utilizando-
se da técnica de
diagramas de sequência e
classes.
Projeto de interação:
composto pelo projeto
de interface e estético;
foca-se nos objetivos
dos usuários; baseia-se
nos projetos de
informação e
navegação.
Detalhamento das tarefas dos
usuários; desenvolvimento de
protótipos; elaboração do projeto
gráfico e de relatórios das
mensagens; estabelecimento dos
critérios de usabilidade,
acessibilidade e
internacionalização ao projeto;
avaliação dos layouts de alta
fidelidade.
Wireframes e layouts em
alta fidelidade.
Projeto funcional:
interação entre sistema
e usuário por meio das
suas funcionalidades.
Checagem dos perfis de usuários;
elaboração dos diagramas de
modelagem das funcionalidades
do sistema.
Diagramas de caso de
uso, sequência, atividade
e estado.
Projeto de Pesquisa de mercado; descrição e Diagramas de UML que
38
componentes: opcional análise quanto a viabilidade do
componente; desenvolver o
modelo da sua integração com a
aplicação.
melhor representem o
comportamento do
sistema junto ao
componente.
Apesar de focar apenas na fase de projeto do PDS, o trabalho de De Souza et al.
(2012) é muito interessante pois demonstra e descreve como é possível fazer a
integração de processos de ES e IHC na prática.
d) UEF-WEB Um Framework Para Desenvolvimento De Aplicações Web
Ergonômicas (SILVEIRA; SCHNEIDER, 2015)
O Trabalho de Silveira e Schneider (2015) propõe um framework de apoio à EU
para aplicações WEB (UEF-WEB), resultado de uma dissertação de mestrado, que
consiste em um arcabouço sucinto de fases, atividades, recursos e artefatos de suporte à
usabilidade. Esse framework, segundo os autores, tem como objetivo ajudar as
organizações a inserir, de maneira sistemática, recursos de usabilidade no processo de
desenvolvimento de interfaces, com o objetivo de aumentar a qualidade de uso das
interfaces.
O framework UEF-WEB segue as prescrições da norma ISO 9241-210, tendo
como ideia central a execução cíclica e evolutiva de um conjunto de fases, atividades,
recursos e artefatos de suporte a usabilidade, com participação dos usuários. A Figura
10 ilustra sua estrutura geral, composta pelas fases de planejamento, desenvolvimento e
avaliação.
Figura 10. Framework UEF-WEB [Fonte: SILVEIRA; SCHNEIDER, 2015]
A fase de planejamento tem como objetivo especificar o contexto de uso e de
requisitos de usabilidade das interfaces da aplicação. É composta pela atividade de
análise e especificação do contexto de uso, que visa levantar informações dos usuários,
das tarefas e do ambiente onde a aplicação será utilizada e a atividade especificação de
requisitos de usabilidade, onde deve-se definir os requisitos de usabilidade com mais
detalhes. Nessa fase foi estabelecido um roteiro de questões, demostrado na Figura 11,
para auxiliar os recursos de entrevista e reuniões sugeridos.
40
Figura 11. Roteiro Básico de Questões para Entrevista e Reunião. [Fonte:
SILVEIRA; SCHNEIDER, 2015]
A finalidade da fase de desenvolvimento é projetar e construir as interfaces da
aplicação através das atividades de projeto e implementação características da ES
relacionadas a aspectos de construção e modelagem. Para a atividade de projeto foi
definido a utilização do recurso de prototipação e para apoia-lo o artefato formulário de
feedback, apresentado na Figura 11.
Figura 12. Artefato Formulário de Feedback. [Fonte: SILVEIRA; SCHNEIDER,
2015]
Afim de auxiliar na descoberta de problemas de interface, durante atividade de
implementação, foi definido o recurso de inspeção de usabilidade baseada em
perspectivas, que consiste na análise das interfaces a partir de um conjunto de questões
de usabilidade sob o ponto de vista de perspectivas de projeto. A adoção desse recurso
se deu por meio da técnica Web Design Perspectives- Basead Usability Evaluation
(WDP), que combina as perspectivas de projeto apresentação, conceituação e navegação
com as dez heurísticas de usabilidade de Nielsen. O artefato formulário de inspeção,
ilustrado na Figura 13, foi definido no framework para apoiar a aplicação desta técnica.
Figura 13. Artefato Formulário de Inspeção. [Fonte: SILVEIRA; SCHNEIDER,
2015]
Ainda sobre a técnica WDP é definido um roteiro com três etapas (sessões de
inspeção individuais, consolidação das inspeções e seleção dos problemas a serem
corrigidos), que é executado pela equipe de desenvolvimento após treinamento, o que
reduz a dependência de especialistas em usabilidade no processo de avaliação das
interfaces.
Por fim, a fase de avaliação do framework tem como objetivo medir a satisfação
dos usuários ao interagir com a interface. Para isso a atividade de teste de usabilidade
foi definida afim de colocar o usuário em contato com a aplicação para que possam
relatar suas perspectivas e nível de satisfação ao utiliza-las.
e) XPlus- Integrando o Design de Interfaces Centrado na Experiência do Usuário
ao Processo de Desenvolvimento de Software com eXtreme Programming
(GUIMARAES et al., )
Em 2008 foi proposto a metodologia XPlus (MENDONÇA; DA SILVA, 2014), que
propõe uma integração entre práticas de design de interface centrado na experiência do
usuário aos valores e práticas do processo de desenvolvimento ágil XP. A Figura 14
mostra uma visão geral da metodologia Xplus. Em seguida é feita uma descrição
sintética das suas fases.
42
Figura 14. Visão geral do processo de desenvolvimento de software de XPlus.
[Fonte: GUIMARAES et al., ]
Fase preparação do projeto: através do contrato de escopo negocial prepara-se o
ambiente físico e virtual, definindo-se ferramentas, linguagem de programação e banco
de dados.
Fase especificação do software: propõe-se a dinâmica do jogo do planejamento para
decidir quais funcionalidades e interfaces serão implementadas na iteração. Na primeira
iteração já se discute o layout da aplicação (aspectos de cores e formas da interface) e
implementa-se um protótipo inicial que deve ser melhorado continuamente durante o
projeto. Em conversas com o cliente, as estórias são elaboradas e afim de auxiliários
desenvolve-se protótipos de baixa fidelidade das interfaces. Depois de aceitos pelos
clientes os protótipos são registrados no verso do cartão de estória, que possuem a
seguinte estrutura: nome, descrição, estimativa e prioridade. Após concluir os cartões de
estórias (funcionalidades e protótipos) deve-se estimá-los, levando em consideração a
dificuldade do desenvolvimento das interfaces. Fazer protótipos antes da estimativa é
importante, pois dependendo da complexidade das interfaces o valor estimado varia
também.
Fase desenvolvimento de software: durante o desenvolvimento do sistema, a
metodologia XPlus recomenda com ênfase a utilização das práticas de XP “Sentar-se
junto”, “Trabalho Energizado”, Programação em par”, “Integração contínua”, “Build de
10 minutos”, “Design incremental”, “Código coletivo”, “Código e testes”, “Base de
código unificada”. Durante o desenvolvimento é utilizado o design de interação, onde as
duplas devem ser formadas por um profissional de implementação e um de interface e
recomenda-se a utilização de padrões de design de interfaces.
Fase Validação: Em relação ao código deve-se utilizar o desenvolvimento orientado a
testes (TDD). Ao final de uma iteração, o cliente deverá validar a aplicação quanto as
funcionalidades e interfaces. Com o intuito de garantir que os usuários reais façam bom
uso da aplicação a metodologia indica a realização de testes de usabilidade com esses
usuários. Quanto a execução dos testes, atentando-se ao valor de simplicidade e ao
princípio “software funcionando vale mais do que documentação externa”, optou-se por
simplificar o esquema de planejamento proposto por Jackob Nielsen, resultando no
modelo especificado na Figura 13. Os testes devem ser realizados com a presença do
facilitador que observará o comportamento do usuário e extrairá informações que
ajudem na melhoria da usabilidade da aplicação.
Figura 15. Modelo de teste de usabilidade XPlus. [Fonte: GUIMARAES et al., ]
44
A Tabela 5 exibe, de maneira sucinta, as práticas de IHC (atividades, técnicas e
métodos) identificados nos cinco trabalhos descritos anteriormente. A maioria das
atividades encontradas nessas publicações foram utilizadas na proposta de adaptação
apresentada no capítulo 4 deste trabalho.
Tabela 5. Práticas de IHC identificadas nos trabalhos relacionados
Trabalho Atividades/ métodos/ técnicas
a) DE SOUSA
FERREIRA; DE
OLIVEIRA, 2010
Análise de contexto de uso;
Definição de padrões e heurísticas de projeto de
interface;
Uso de validadores de código;
Testes com métodos analíticos (avaliação
heurística e inspeções de conformidade) e
empíricos (teste de usabilidade);
Prototipação, mapas de navegação;
b) MIRANDA et al., 2011
Inclusão de um gestor de design a fábrica (visão do
designer);
Identificar usuários, situações, cenários e contextos
de uso;
Criar fluxo de navegação dos usuários e
relacionamento destes com as telas;
Brainstorming, card sorting, etnografia rápida,
entrevistas;
c) DE SOUZA et al., 2012
Definição de conteúdo;
Detalhamento das tarefas dos usuários;
Estabelecimento de critérios de usabilidade;
Avaliação dos layouts de alta fidelidade;
Prototipação, storyboarding, wireframes, mapas de
navegação;
d) SILVEIRA;
SCHNEIDER, 2015
Análise e especificação do contexto de uso;
Especificação de requisitos de usabilidade;
Teste de Usabilidade;
Entrevistas, reuniões, prototipação, inspeção de
usabilidade baseada em perspectivas, questionário;
e) GUIMARAES et al.,
Definição de funcionalidades e interfaces;
Utilização de padrões de interface;
Prototipação, avaliação heurística;
Programação aos pares (um profissional de
implementação e um de interface);
Testes de unidade, testes de aceitação e testes de
usabilidade;
Captura de feedback dos usuários;
46
3
PROCESSO DE DESENVOLVIMENTO DE SISTEMAS DA SEGES-MT
3.1 APRESENTAÇÃO
A SEGES-MT utiliza como Processo de Desenvolvimento de Sistemas (PDS) o
documento apresentado no Anexo I, que é utilizado como referência pelas instituições
públicas do estado de Mato Grosso. O objetivo do PDS é facilitar o intercâmbio de
informações e experiências adquiridas no desenvolvimento e manutenção de sistemas
em todas as instituições do estado. Para isso durante o desenvolvimento desse
documento, foi considerado a disparidade existente entre as equipes de desenvolvimento
de software de cada instituição. Por isso as atividades e artefatos recomendados no
processo são definidos como essenciais, pois é possível a inclusão de outras atividades e
artefatos conforme necessidade dos projetos.
A Figura 14 fornece uma visão geral da estrutura do PDS utilizado pela SEGES-
MT. Nela pode-se notar quais documentos são produzidos, as atividades que devem ser
realizadas e os papéis envolvidos agrupados em seis fases de desenvolvimento:
concepção, projeto, implementação, teste, homologação, implantação/encerramento. As
linhas na cor violeta indicam os artefatos de uma fase que servem de entrada para
elaboração de artefatos das fases seguintes. As linhas na cor verde indicam a sequência,
nem sempre obrigatória, para elaboração dos artefatos de cada fase.
Figura 16. Quadro Geral do PDS da SEGES-MT [Fonte: MATO GROSSO, 2010]
As fases do processo podem ser planejadas iterativamente, de forma a fracionar
a entrega do produto em vários subprodutos. Dessa forma, é possível fazer o
planejamento das iterações, ou seja, repetição de atividades de cada fase, onde cada
iteração produz uma release, ou parte do sistema executável, que juntas compõem a
versão completa do sistema.
A fim de favorecer a melhor compreensão do PDS foi elaborada uma descrição
resumida de cada fase do processo contendo uma pequena descrição, os papéis dos
envolvidos, as atividades e os artefatos gerados conforme apresenta a Tabela 6.
48
Tabela 6 - Resumo do PDS da SEGES-MT
É importante ressaltar que a atividade de diagnóstico não compõe o
processo, mas é fundamental para iniciá-lo, pois tem como objetivo
analisar a viabilidade de execução do projeto. Com a ajuda do líder
de projeto, o cliente deve definir o fluxo de negócio que será
automatizado e os requisitos do sistema a serem desenvolvidos. Dessa
forma, dois documentos são produzidos nessa atividade e são
necessários para o início de processo: o fluxo de negócio e o
documento de requisitos.
Deve-se também fazer registro em Ata, das visitas e reuniões com
clientes e catalogação dos termos identificados durante o processo em
um Glossário, que tem como finalidade registrar termos pertinentes
do negócio com seus respectivos significados de forma a facilitar o
entendimento dos documentos elaborados e comunicação com o
cliente.
É na fase de concepção que o desenvolvimento do sistema é
iniciado. O objetivo dessa fase é o estabelecimento de um acordo
formal entre a equipe de desenvolvimento e o cliente por meio dos
documentos de visão e estimativa de Pontos por Função produzidos
nessa fase.
Papéis envolvidos: Líder de Projeto, Analista de Requisitos e o
Cliente.
Artefatos de entrada: Fluxo de Negócio e Documento de Requisitos.
Atividades: 1- Elaborar documento de Visão; 2- Criar repositório
para projeto; 3– Complementar Documento de Requisitos; 4–
Elaborar cronograma; 5– Elaborar Glossário; 6- Elaborar Diagrama
de Caso de Uso; 7- Especificação do Caso de Uso; 8- Elaborar
Protótipo; 9 – Calcular Pontos por Função;10 – Encerrar a fase.
Durante essa fase são realizados estudos mais abrangentes sobre o
projeto, sendo possível ao final dois caminhos: a interrupção ou
continuidade do processo, iniciando a fase de projeto. Essa decisão
deve ser tomada pelo cliente em conjunto com o líder de projeto.
50
A fase de projeto tem como objetivo apresentar uma estimativa de
prazos e custos a ser aprovado pelo Cliente e, após aprovação, definir
os quesitos para a fase de implementação, tais como arquitetura,
modelo de dados etc.
Papéis envolvidos: Projetista, Arquiteto de Software, Projetista de
Banco de dados, Analista de Requisitos, Líder de Projeto.
Artefatos de Entrada: Documento de Visão, Glossário,
Especificação de Casos de Uso e Cronograma de Atividades.
Atividades: 11 -Apresentar prazos e custos e atualizar Cronograma;
12-Definir Arquitetura; 13- Elaborar Modelo de Dados; 14- Realizar
Casos de Uso; 15- Definir Infraestrutura.
A atividade 11, apresentar prazos e custos, é muito importante para a
continuidade do projeto, uma vez que sem a aprovação do custo e
prazo pelo cliente o sistema não deve ser implementado.
A fase de implementação tem como objetivo produzir o código fonte
do sistema e realizar testes iniciais para garantir-se que a aplicação ou
módulo desenvolvido pode passar para a fase de testes do processo.
Papéis envolvidos: Implementador, Projetista, Líder de Projeto.
Artefatos de Entrada: Especificação de Casos de Uso, Realização
do Caso de Uso e Protótipo.
Atividade: 16- Desenvolver código fonte; 17- Disponibilizar em
ambiente de teste.
A finalidade da fase de teste é assegurar que a aplicação tenha
disponibilidade ao usuário final com comportamento inesperado
mínimo.
Papéis envolvidos: Projetista de Teste, Testador, Analista de
Requisitos.
Artefatos de entrada: Especificação de Casos de Uso, Aplicação
disponível em ambiente de teste.
Atividades: 18 – Planejar o Teste; 19 – Executar e disponibilizar
correções.
Na atividade 18, planejar o teste são elaborados o Plano de Teste e os
Casos de Teste para requisitos funcionais e de interface. Ao final o
líder de projeto, caso de acordo, deve solicitar ao implementador que
disponibilize a aplicação no ambiente de homologação.
A fase de homologação tem como objetivo certificar que o sistema
está pronto para ser utilizado pelo usuário.
Papéis envolvidos: Líder de Projeto, Analista de Requisitos, Cliente.
Artefatos de Entrada: aplicação esteja disponível em ambiente de
homologação.
Atividades: 20 – Treinar usuários finais; 21- Homologar a aplicação.
Durante a atividade 21, homologar aplicação, o Líder de Projeto deve
preencher o Documento de Homologação, acionar atividades de
ajuste, como correção de erros, melhoria no desempenho e
usabilidade, assim como providenciar a produção da documentação
complementar no Documento de Visão - Manual do Usuário do
Sistema, Help Online, Manual de Instalação e Configuração (artefatos
obrigatórios para desenvolvimento terceirizado de sistemas).
52
A fase de Implantação e Encerramento tem como objetivo marcar o
encerramento de um projeto ou módulo do sistema.
Papéis envolvidos: Líder de Projeto, Analista de Requisitos, Superior
imediato do líder de projeto, Cliente.
Artefatos de Entrada: aplicação homologada pelo cliente.
Atividades: 22 – Implantar o Sistema; 23- Formalizar o aceite.
Na atividade 23, formalizar o aceite, deve-se confeccionar o Termo de
Entrega e Termo de Aceite, que devem ser assinados pelos
envolvidos.
3.2 ANÁLISE DO PROCESSO
A primeira atividade metodológica realizada foi a análise do PDS da SEGES-MT,
com o objetivo de identificar atividades relacionadas a área de IHC presentes no
processo. Durante essa análise foram identificadas algumas atividades de IHC e outras
apenas relacionadas a área. NA Tabela 7 podem ser visualizadas as atividades
encontradas em cada fase do PDS, sendo que as destacadas em negrito foram
consideradas atividades de IHC e as demais apenas relacionadas a área. Essas atividades
são descritas de forma mais detalhada no texto dessa seção.
Tabela 7 - Atividades de IHC identificadas no PDS
Fase Atividades
Diagnóstico Elaborar documento de Requisitos (requisitos de interface)
Concepção
Elaborar Documento de Visão (entrevistas e visitas ao
ambiente), Complementar Documento de Requisitos e
Elaborar Protótipo
Implementação Realizar testes unitários locais
Teste Elaborar Planos de Teste e Caso de Teste (requisitos de
interface e padrões de telas)
Homologação Elaborar Manual do Usuário do Sistema, Help Online e
o Manual de Instalação e Configuração do Sistema
Na fase Diagnóstico, que antecede o início do PDS tendo como objetivo analisar a
viabilidade do projeto, o cliente define o fluxo de negócio e os requisitos do sistema,
com auxílio do Líder de Projeto/Analista de Sistemas. No PDS, durante essa fase, nada
é mencionado sobre requisitos de IHC, porém na prática são definidos requisitos de
interface. Ao final é produzido o Documento de Requisitos, que é refinado na Fase de
Concepção através da atividade Complementar Documento de Requisitos. Desse modo,
foram identificadas as atividades Elaborar Documento de Requisitos e Complementar
Documento de Requisitos como atividades relacionadas a área de IHC.
Na fase de Concepção identificou-se as atividades Elaborar Documento de Visão
e Elaborar Protótipo, além da atividade Complementar Documento de Requisitos já
mencionada. A Atividade Elaborar Documento de Visão contempla a realização de
entrevistas com o cliente e visitas ao ambiente onde o sistema será implantado. Por
meio do Documento de Visão é possível acordar com o cliente os requisitos e
funcionalidades do sistema. Já a atividade Elaborar Protótipo permite que o cliente
verifique se todas as funcionalidades solicitadas foram contempladas. Dessa maneira,
identificou-se a atividade Elaborar Protótipo como uma atividade efetivamente de IHC e
a atividade Elaborar Documento de Visão como relacionada a área.
54
Na fase de Implementação, durante a atividade Desenvolver Código Fonte é
descrito no PDS que devem realizados, em ambiente de desenvolvimento, testes
unitários locais, pelo papel do implementador, que deve considerar as recomendações
do Documento de Arquitetura, Modelagem de Dados e Documento de Requisitos,
produzidos nas fases de Concepção e Projeto do processo. Assim, considerou-se a
atividade Realizar Testes Unitários Locais como uma atividade relacionada a área de
IHC, pois são realizados testes de interface durante o desenvolvimento.
Na fase de Teste foi identificada a atividade Elaborar Plano de Teste e Caso de
Teste como uma atividade de IHC que precisa ser melhor especificada no PDS. Nessa
fase é elaborado, pelo Projetista de Teste, os documentos Plano de Teste e Casos de
Teste, para requisitos funcionais e de interface, com objetivo de orientar o Testador
durante a execução. Este deve considerar o funcionamento correto do sistema, o
cumprimento das padronizações de telas e relatórios e a performance do sistema na
operacionalização de funcionalidades complexas. Nessa fase, é apenas mencionado os
requisitos de interface e padrões de telas, porém não é especificado nada sobre o
assunto.
Na fase de Homologação a palavra “usabilidade” é mencionada na atividade
Homologar aplicação, em que o Líder de Projeto deve demandar atividades de ajuste,
como correção de erros, melhoria no desempenho e na usabilidade, se forem
necessárias. Nessa fase o Documento de Visão é finalizado contemplando o Manual do
Usuário do Sistema, Help Online e o Manual de Instalação e Configuração do Sistema.
Assim, foi identificada a atividade Elaborar Manual do Usuário do Sistema, Help
Online e o Manual de Instalação e Configuração do Sistema como uma atividade
relacionada a área de IHC, uma vez que auxilia o usuário a interagir com o sistema caso
haja alguma dúvida.
Ao final dessa análise, chegou-se à conclusão de que o PDS da SEGES-MT
possui duas atividades de IHC, entretanto tem uma “perspectiva de design centrada no
sistema” (BARBOSA, 2010, p.121) em que a área de IHC recebe pouca atenção já que
algumas atividades são citadas no processo e outras possuem apenas ações relacionadas
a área de IHC, com exceção das atividades Elaborar Protótipo, na fase de Concepção e a
atividade Elaborar Plano de Teste e Caso de Teste na fase de Teste.
56
4
PROPOSTA DE INTEGRAÇÃO
4.1 CONSIDERAÇÕES INICIAIS
Com o objetivo de fazer a integração de métodos e técnicas de IHC ao PDS da
SEGES-MT, optou-se em considerar as principais abordagens de integração, segundo
Barbosa e Silva (2010, p. 123): “definição de características de um processo de
desenvolvimento que se preocupa com a qualidade de uso; definição de processos de
IHC paralelos que devem ser incorporados aos processos propostos pela ES; indicação
de pontos em processos propostos pela ES em que atividades e métodos de IHC podem
ser inseridos”.
Assim, essa proposta abordou duas das três formas de integração mencionadas.
Uma das formas foi a definição de algumas características inseridas ou enfatizadas no
processo afim de tratar adequadamente a qualidade de uso. Características como foco no
usuário, participação ativa dos usuários, representação de design simples, customização
do processo de forma que possibilite adaptação para outras instituições governamentais,
participação de profissional de IHC continuamente no processo, presença de atividades
de design explícitas e conscientes, avaliação das propostas de solução considerando
critérios de qualidade de uso definidos inicialmente (BARBOSA; SILVA, 2010 apud
GULLIKSEN et al. 2005, p.124).
A segunda forma de integração utilizada foi a sugestão de inserção de atividades,
métodos e práticas de IHC em alguns pontos do processo.
Algumas considerações acerca das adaptações sugeridas:
Durante o processo de desenvolvimento da aplicação, as partes interessadas
devem avaliar as soluções propostas, sejam na forma de protótipos ou produto
final, para garantir que os requisitos estabelecidos previamente sejam atendidos
(MELO; BARANAUSKAS, 2006). Durante esse processo é importante uma boa
comunicação entre os envolvidos no PDS, sendo muito importante a
participação do cliente/usuário durante os estágios de desenvolvimento;
Os métodos e técnicas apresentados por essa proposta devem ser escolhidos
conforme necessidade de desenvolvimento. Nesse trabalho, os métodos e
técnicas são descritos como uma sugestão, podendo ser utilizados em parte ou
até mesmo adicionados outros não citados, conforme necessidade;
Considerando que as aplicações desenvolvidas pela SEGES-MT são todas web,
as atividades propostas ao PDS são adequadas especificamente para o
desenvolvimento web;
Encontram-se nos apêndices do trabalho, sugestões de modelos (templates) dos
artefatos alterados e adicionados em cada uma das fases, com exceção do
documento Guia de Estilo, que está em fase de desenvolvimento pela
Coordenadoria de Tecnologia de Informação (CTI) da SEGES-MT, fato este que
será explicado com mais detalhes na próxima seção;
Os artefatos existentes que foram modificados são: Documento de Visão
(Apêndice B), Documento de Requisitos (Apêndice C), Plano de Teste
(Apêndice E), Caso de Teste (Apêndice F) e Documento de Homologação
(Apêndice H). Os artefatos criados e adicionados foram: Projeto de IHC
(Apêndice D), Avaliação heurística (Apêndice G), Teste de Usabilidade
(Apêndice I) e Documento de Feedback (Apêndice J);
Foi adicionado ao PDS o papel Designer de IHC, um profissional especialista
em design de interação ou usabilidade que deve trabalhar em conjunto com os
outros papéis definidos no processo. Na próxima seção serão indicadas em quais
atividades é importante a atuação desse papel.
58
Como mencionado, inicialmente realizou-se uma análise da documentação do
PDS da SEGES-MT com o intuito de entender seu funcionamento. Em seguida
analisou-se o processo afim de identificar atividades presentes relacionadas a área de
IHC. Os resultados desta análise foram descritos no Capítulo 3 desse trabalho, seção
3.2. Com o levantamento bibliográfico foi possível encontrar variadas obras que
contribuíram para elaboração da proposta dessa pesquisa, sendo algumas descritas com
mais detalhes no Capítulo 2, seção 2.5. Na próxima seção será apresentada
detalhadamente a proposta dessa pesquisa.
4.2 A PROPOSTA
Essa seção apresenta as adaptações recomendadas ao PDS da SEGES-MT e
descreve as atividades alteradas e adicionadas, técnicas e métodos de EU sugeridos,
assim como os artefatos alterados e adicionados para cada fase do processo. A Figura 17
ilustra uma visão geral das adaptações realizadas no PDS da SEGES-MT. Nela as
marcações em vermelho indicam as atividades e artefatos modificados e as marcações
em amarelo as atividades e artefatos adicionados ao processo.
Figura 17. Adaptações sugeridas ao PDS da SEGES-MT [fonte: Adaptado de
MATO GROSSO, 2010]
A seguir é feita uma descrição mais detalhada das adaptações ilustradas na
Figura 17, por fase do PDS.
Fase de Concepção
Na fase de Concepção do processo as atividades Elaborar Documento de Visão e
Complementar Documento de Requisitos foram modificadas, conforme especificado na
Tabela 8, que representa resumidamente a adaptação realizada na fase, especificando as
atividades adicionadas, os métodos e técnicas sugeridos e artefatos alterados.
60
Tabela 8 - Adaptação do PDS na fase de Concepção
Atividades Métodos/Técnicas Artefatos
Elaborar
Documento de
Visão
Especificar Perfis de
Usuários, Contexto de
uso e de tarefas
Entrevistas, grupo focal,
questionários,
brainstorming, card
sorting, estudos de
documentação,
observação natural,
personas, cenários,
prototipação de baixa
fidelidade
Documento de
Visão
Complementar
Documento de
Requisitos
Definir Critérios de
Qualidade em IHC Documento de
Requisitos Especificar Requisitos
de Usabilidade e
Design
Barbosa e Silva (2010) mencionam que nessa fase devem ser definidos quem são
os usuários, os clientes e demais stakeholders, seus objetivos e quais tarefas realizam
para atingi-los em um determinado contexto. Assim, na atividade Elaborar Documento
de Visão foi adicionada a atividade Especificar Perfis de Usuários (lista de hierarquia),
Contexto de uso e de tarefas (descrição de tarefas por categoria) (Silveira; Sheneider,
2015; De Souza et al., 2012). Essa atividade foi adicionada com o intuito de deixar mais
evidente a importância da definição desses itens no Documento de Visão, onde devem
ser inseridos os resultados obtidos com essa atividade. O modelo do Documento de
Visão é detalhado no Apêndice B.
Na atividade Complementar Documento de Requisitos foram adicionadas duas
atividades: Especificar requisitos de usabilidade e design e Definir critérios de
qualidade em IHC (Bastos; Oliveira, 2010). Na atividade Especificar requisitos de
usabilidade e design devem ser especificados os critérios de qualidade em IHC
definidos na atividade Definir critérios de IHC, ou seja, as duas atividades se
complementam e dependem uma da outra. Os dados coletados a partir dessas atividades
devem ser adicionados no Documento de Requisitos que consta no Apêndice C desse
trabalho.
A atividade Definir Critérios de Qualidade em IHC foi inspirada na atividade
Definição de “paradigmas de interação” do trabalho de Bastos e Oliveira (2010).
Enquanto os autores colocaram a atividade na fase de Projeto, aqui essa atividade foi
inserida na fase de Concepção pois acredita-se que ela faz parte das atividades de
levantamento de requisitos do sistema, que são necessários na próxima fase, para o
projeto das soluções de software considerando tais critérios.
Durante a atividade Definir Critérios de qualidade em IHC, o cliente deve
acordar quais critérios de qualidade em IHC devem ser inicialmente definidos e
posteriormente validados na entrega do produto. Barbosa e Silva (2010), por exemplo,
apresentam como critérios de qualidade de uso em sistemas interativos: usabilidade
(facilidade de aprendizado, facilidade de recordação, eficiência, segurança no uso,
satisfação do usuário), experiência do usuário, acessibilidade e comunicabilidade.
As atividades descritas nessa fase podem ser realizadas conforme necessidade e
contexto do sistema a ser desenvolvido, por exemplo, por meio de entrevistas com os
stakeholders, grupo focal, questionários, brainstorming de necessidades e desejos do
usuário, card sorting, estudos de documentação existentes ou legislação vigente,
observação natural, personas, estudos de campo etc.
Fase de Projeto
Na fase de Projeto do processo foi adicionada a macro atividade Elaborar Projeto de
IHC, conforme especificado na Tabela 9, que representa resumidamente a adaptação
realizada na fase, especificando também os métodos e técnicas sugeridos e os artefatos
envolvidos.
62
Tabela 9 - Adaptação do PDS na fase de Projeto
Atividades Métodos/ Técnicas Artefatos
Elaborar Projeto de IHC
Prototipação
(storyboarding, wireframes,
mapas de navegação)
Guia de Estilo
Projeto de IHC
Protótipo
A atividade Elaborar Projeto de IHC foi adaptada do trabalho de De Souza et al.
(2012). Aqui o projeto de IHC contempla os projetos de conteúdo, projeto de
arquitetura, projeto de navegação e projeto de interação. Os resultados obtidos com
esses projetos devem ser inseridos no documento Projeto de IHC (Apêndice D), com
exceção dos protótipos interativos de média e alta fidelidade, que devem compor o
artefato Protótipo descrito no processo.
O projeto de conteúdo, segundo De Souza et al. (2012) é importante porque
apresenta toda a informação que deve conter na aplicação, ou seja, é feito uma descrição
dos conteúdos e elementos necessários a aplicação com base nas informações passadas
pelos clientes e usuários.
Na fase de Projeto do PDS há a atividade Definir Arquitetura, porém esta se
refere à definição de arquitetura de software da área de ES. O projeto de arquitetura
presente no projeto de IHC trata da disponibilidade das informações na aplicação e seu
refinamento pelos stakeholders, podendo ser elaborado por meio das técnicas de
storyboarding e wireframes de conteúdo.
Segundo Benyon (2011), a navegação é uma característica importante para
muitos sistemas. Considerando isso, nesse trabalho, o projeto de navegação consiste
basicamente no desenvolvimento de mapas de navegação, que focam na experiência que
o usuário terá com a aplicação, destacando como estes se movimentam por ela.
A Coordenadoria de Tecnologia da Informação (CTI) da SEGES-MT, está
desenvolvendo um Guia de Estilo, que deve ser utilizado como base para o
desenvolvimento das novas aplicações e também algumas existentes. A ideia é
desenvolver um padrão de interfaces e componentes que caracterizem a identidade da
secretaria nas aplicações. Um ponto positivo na utilização de um guia de estilo é que
este torna o desenvolvimento do sistema mais ágil, uma vez que os componentes da tela
estão previamente definidos. Considerando isso, o projeto de interação, aqui
apresentado, consiste no desenvolvimento de protótipos de média e alta fidelidade
considerando o documento Guia de Estilo, que está em desenvolvimento.
Fase de Implementação
Na fase de Implementação do processo foi alterada a macro atividade
Implementar Sistema, conforme demonstrado na Tabela 10, que representa
resumidamente a adaptação realizada na fase, especificando também os métodos
sugeridos e os artefatos envolvidos.
Tabela 10 - Adaptação do PDS na fase de Implementação
Atividades Método Artefatos
Implementar
Sistema
Utilizar Padrões Pré-
definidos Guia de Estilo
Guia de Estilo
Código Fonte
Validar Páginas
Validadores
Automáticos de
Código
A atividade Implementar Sistema foi alterada adicionando a atividade Utilizar
Padrões Pré-definidos para o desenvolvimento das interfaces das aplicações. Essa
atividade foi adaptada do trabalho de De Souza Ferreira et al. (2010) e considera como
fonte o artefato Guia de Estilo. Essa adaptação reflete também no artefato Código
Fonte.
Na atividade Implementar Sistema também foi adicionada a atividade Validar
Páginas, inspirada no trabalho de De Souza Ferreira et al. (2010). Sonza et al. (2015)
afirma que a validação das páginas web é obtida por meio de testes automáticos e
64
manuais que devem ser feitos desde o início do desenvolvimento. É importante ressaltar
que a validação manual é indispensável, uma vez que nem todos os problemas de
acessibilidade são identificados mecanicamente através dos validadores automáticos. Há
questões que somente podem ser identificadas pelo ser humano.
A conformidade com os padrões World Wide Web Consortium (W3C) são
fundamentais para garantir questões de acessibilidade, uma vez que, os navegadores e
ferramentas como leitores de tela, que se baseiam nesses padrões, podem interpretar o
conteúdo da página de maneira indesejada/incorreta (SANTANA et al., 2010). Assim, a
atividade Validar Páginas consiste no uso de validadores de código automáticos para
avaliar se as páginas desenvolvidas seguem padrões estabelecidos e tem como objetivo
principal garantir questões de acessibilidade.
Esta atividade deve ser realizada pelo Implementador (programador) em
conjunto com Designer de IHC. A validação de padrões, como HyperText Markup
Language (HTML) e Cascading Style Sheets (CSS), Extensible Hypertext Markup
Language (XHTML), o Extensible Markup Language (XML) e o ECMAScript
(JavaScript), por exemplo, pode ser feita com os diversos avaliadores automáticos
online disponibilizados pelo W3C conforme descrito nos trabalhos de Oliveira e Eler
(2015) e Sonza et al. (2015).
Fase de Teste
Na fase de Teste do processo, as duas atividades presentes (Elaborar Plano de
Teste e Elaborar Casos de Teste) foram modificadas. A Tabela 11 representa
resumidamente a adaptação realizada nessa fase, especificando as atividades
adicionadas, os métodos e técnicas sugeridos e artefatos alterados.
Tabela 11 - Adaptação do PDS na fase de Teste
Atividades Métodos Artefatos
Elaborar Plano
de Teste
Planejar Avaliação de
IHC Avaliação Heurística,
Percurso Cognitivo,
Método de Inspeção
Semiótica
Documento Plano de
Teste
Elaborar Casos
de Teste
Realizar Avaliação
com Especialista em
IHC
Documento Caso de
Teste
Na perspectiva de quem desenvolve o sistema, o objetivo principal da avaliação
é verificar se o sistema funciona de acordo com a especificação de requisitos
(BARBOSA; SILVA, 2010, p.287). Assim, a atividade Elaborar Plano de Teste foi
alterada adicionando a atividade Planejar Avaliação de IHC, que consiste no plano de
teste considerando a realização de avaliações da interação e de interfaces por
profissionais especializados (p.ex. Designer de IHC) e pelos usuários da aplicação. Os
testes com profissionais especializados são realizados nessa fase, já os testes com
usuários são aplicados na fase de homologação do processo.
Segundo Benyon (2010), o plano de teste tem o objetivo de orientar a avaliação,
especificando os objetivos da sessão de teste, detalhes práticos (onde, quando, tempo de
duração, equipamentos e materiais necessários), número e tipo de participantes e tarefas
a serem realizadas com a especificação de término bem-sucedido. A definição de como
os testes serão realizados devem ser descritas no Documento Plano de Teste, que se
encontra no Apêndice E.
Os métodos de inspeção não envolvem a participação de usuários e tratam de
experiências potenciais de uso realizadas pelo avaliador que tenta se colocar no lugar
dos usuários afim de identificar possíveis problemas que estes podem vir a ter ao
interagirem com a aplicação (BARBOSA; SILVA, 2010). Considerando isso, na
atividade Elaborar Casos de Teste foi inserida a atividade Realizar Avaliação com
Especialista em IHC. Os casos de testes devem ser implementados com profissional
especialista em design de interação ou usabilidade com o uso de métodos tais como:
66
avaliação heurística (DE SOUZA FERREIRA, 2010; GUIMARAES et al.; SILVEIRA;
SCHENEIDER, 2015), percurso cognitivo (BARBOSA; SILVA, 2010; PREECE et al.,
2005; BENYON, 2011), método de inspeção semiótica (BARBOSA; SILVA, 2010) etc.
No documento Caso de Teste, que se encontra no Apêndice F, devem ser descritos os
resultados obtidos com as avaliações realizadas.
Preece et al. (2005) definem avaliação heurística como uma técnica de inspeção
de usabilidade em que especialistas avaliam se os elementos de interface estão de
acordo com um conjunto de princípios de usabilidade. Considerando a natureza diversa
dos produtos de software possíveis, os autores recomendam que os avaliadores devem
desenvolver seu próprio conjunto de heurísticas, moldando-as as dez heurísticas de
Jakob Nielsen. Os critérios de qualidade em IHC estabelecidos na Atividade Definir
critérios de qualidade em IHC durante a fase de concepção do processo, devem ser
inseridos no conjunto de heurísticas citado. No Apêndice G, consta um roteiro de
atividades e um modelo de avaliação heurística que pode ser utilizado como base. Este
modelo foi produzido pela autora em uma atividade em grupo da disciplina de
Avaliação em IHC e adaptado para essa pesquisa.
Fase de Homologação
Segundo Preece et al. (2005), os testes com usuários são mais adequados para
avaliar protótipos e sistemas que estejam funcionando, uma vez que, segundo Barbosa e
Silva (2010, p. 287) o objetivo principal da avaliação é verificar se o sistema apoia
adequadamente os usuários a atingirem seus objetivos em um determinado contexto de
uso. Considerando as colocações, na fase de Homologação, optou-se por modificar a
atividade Realizar Homologação com o Cliente, conforme representado na Tabela 12.
Tabela 12 - Adaptação do PDS na fase de Homologação
Atividades Métodos/ Técnicas Artefatos
Realizar
homologação
Realizar Teste de
Usabilidade
Teste de Usabilidade e
Teste de
Documento de
Homologação
com o
Cliente
Realizar Avaliação de
Comunicabilidade
Comunicabilidade
A atividade Realizar Homologação com o Cliente foi alterada inserindo duas
atividades: Realizar Teste de Usabilidade e Realizar Avaliação de Comunicabilidade,
sendo que a consolidação das análises dos resultados obtidos com essas atividades deve
ser descrita no Documento de Homologação, que consta no Apêndice H. É importante
lembrar que essas atividades não são obrigatórias e devem ser aplicadas considerando o
contexto da aplicação desenvolvida.
A atividade Realizar Teste de Usabilidade consiste na aplicação de testes de
usabilidade, também utilizados nos trabalhos de De Souza Ferreira (2010), Guimaraes et
al., Silveira e Scheneider (2015). O teste de usabilidade tem por objetivo, segundo
Silveira e Scheneider (2015), proporcionar a interação dos usuários com a aplicação
desenvolvida afim de que esses possam relatar as suas percepções e nível de satisfação
com relação às interfaces utilizadas. Os autores optaram por adotar, para isso, o
questionário System Usability Scale (SUS) proposto por Brooke (1986) acrescido de
questões fechadas e abertas para obter informações acerca do perfil e da percepção dos
usuários. E o trabalho de Secco et al. (2016) demostra como se deu a avalição de
usabilidade do Chamilo, um ambiente virtual de aprendizagem, por meio do SUS.
Além do SUS, existem outras escalas de usabilidade, como por exemplo, o
Software Usability Measurement Inventory (SUMI), Methodology for Usability
Assessment and Design of webbased Information Systems (UWIS), Measuring the
Usability of Multi-Media Systems (MUMMS) (DA COSTA LIMA et al., 2015),
DaSilva, eScanner (OLIVEIRA; ELER, 2015). Porém, na atividade Realizar Teste de
Usabilidade, sugere-se a utilização da escala SUS, por ser um questionário amplamente
utilizado sendo possível encontrar muitas publicações sobre o assunto, como em Souza
(2015), pelo número reduzido de questões e principalmente por ser gratuito. No
Apêndice I é feita uma sugestão de como o teste de usabilidade pode ser aplicado
utilizando o SUS.
68
A atividade Realizar Avaliação de Comunicabilidade compreende a aplicação de
avaliações de comunicabilidade a um grupo pequeno de usuários (cinco a dez) em
ambiente controlado. Esse método tem o objetivo de avaliar a qualidade da recepção da
metacomunicação do designer pelo usuário, sendo um método qualitativo de análise
profunda. É foco dessa análise identificar prováveis caminhos de interpretação dos
usuários, suas intenções de comunicação e rupturas de comunicação que podem ocorrer
durante a interação. Daí é possível identificar possíveis problemas na comunicação da
metamensagem do designer e na comunicação dos usuários com o sistema (BARBOSA;
SILVA, 2010). Um exemplo de aplicação desse método pode ser visto no trabalho de
Oliveira et al. (2015).
Nesta fase, portanto, são sugeridos dois métodos (teste de usabilidade e
avaliação de comunicabilidade), que permitem o registro e análise de dados que
identificam problemas reais enfrentados pelos usuários e não apenas potenciais
problemas previstos pelo avaliador, como podem identificar os métodos de inspeção
mencionados na fase de teste do PDS.
Fase de Implantação/ Encerramento
Na fase de Implantação/ Encerramento, após a atividade Entregar Sistema/
Release, optou-se por adicionar a atividade Realizar Teste de Aceitação, conforme
apresentado pela Tabela 13.
Tabela 13 - Adaptação do PDS na fase de Implantação/ Encerramento
Atividades Métodos/ Técnicas Artefato
Realizar Teste de
Aceitação
Entrevistas e questionários
de satisfação Documento de Feedback
A atividade Realizar Teste de Aceitação consiste na aplicação de técnicas como
entrevistas e questionários de satisfação afim de averiguar a satisfação dos usuários após
um tempo de utilização da aplicação. A forma como essa atividade deve ser realizada
vai depender do tamanho da aplicação, podendo ser realizada após entrega de módulos
ou somente quando o produto estiver finalizado. Essa é uma decisão tomada pela equipe
de desenvolvimento juntamente com os clientes e/ou usuários. Os resultados dessa
atividade devem ser descritos no Documento de Feedback, apresentado no Apêndice J.
70
5
CONSIDERAÇÕES FINAIS
Esse trabalho apresentou uma proposta de adaptação do processo de
desenvolvimento de sistemas (PDS) da SEGES-MT com práticas de interação humano-
computador (IHC). Inicialmente foi realizada análise do PDS com o objetivo de
identificar as atividades de IHC presentes no processo (Capítulo 3). A partir dos
resultados dessa análise e com os estudos bibliográficos realizados anteriormente foi
possível elaborar a proposta de adaptação do PDS apresentada no capítulo 4 desse
trabalho. Acredita-se que com as alterações propostas, o PDS tenha adquirido uma
perspectiva de desenvolvimento centrada no uso.
Como trabalhos futuros, pretende-se melhorar a proposta apresentada adicionando
atividades que contemplem questões de acessibilidade de maneira mais ampla, uma vez
que a proposta apresentada fez menção a acessibilidade, na fase de Implementação do
PDS, onde se adicionou a atividade Validar Página, que tem como objetivo garantir
questões de acessibilidade e consiste no uso de validadores de código automáticos para
avaliar se as páginas desenvolvidas seguem padrões estabelecidos.
Futuramente, pretende-se apresentar formalmente a proposta de adaptação do PDS
para a Coordenadoria de Tecnologia de Informação (CTI) da SEGES-MT, com o
objetivo de receber sugestões de melhorias e validação da mesma, para que seja
utilizada futuramente pela Secretaria no desenvolvimento de suas aplicações.
A CTI da SEGES-MT deu início recentemente ao desenvolvimento de um novo
sistema de gestão de viagens (SGV) que será utilizado por todas as secretarias do
estado. O sistema atual possui uma série de inconsistências, de modo que é inviável
correções e melhorias. Desse modo, optou-se por desenvolver o novo sistema do zero,
uma vez que constatou-se ser mais vantajoso do que reaproveitar o existente.
Atualmente o desenvolvimento está no primeiro release, na fase de concepção, com a
modelagem de processos e entendimento do negócio.
Acredita-se que a CTI da SEGES-MT tem a oportunidade de dar continuidade ao
desenvolvimento do SGV, seguindo a proposta desse trabalho, pois assim será possível
averiguar se os resultados obtidos com a utilização do PDS adaptado serão positivos e
se trarão melhorias aos produtos de softwares no que diz respeito ao atendimento de
critérios de usabilidade e aceitabilidade do sistema pelos usuários e clientes da
secretaria.
Caso seja possível aplicar essa proposta no desenvolvimento do SGV, pretende-se
ao final do desenvolvimento da aplicação, realizar entrevistas e questionários junto aos
usuários do sistema e servidores envolvidos no desenvolvimento com o intuito de
coletar informações que comprovem melhorias no processo, e constatem que problemas
anteriormente existentes foram minimizados, tais como redução do custo de
desenvolvimento, diminuição de atrasos com retrabalho, aumento da produtividade,
aceitação e satisfação dos usuários etc.
É interessante ressaltar que tanto as atividades quanto os artefatos adicionados ao
PDS são sugestões que podem ser utilizadas ou não a depender das particularidades de
cada aplicação a ser desenvolvida. Dessa forma, espera-se também que a SEGES-MT e
outras instituições públicas de Mato Grosso possam utilizar esse processo como um
guia para o desenvolvimento de suas aplicações, de forma a auxiliar o desenvolvimento
de soluções de software com maior qualidade de uso e de acordo com as necessidades e
anseios de seus clientes e usuários.
72
REFERÊNCIAS
BARBOSA, D. F.; FURTADO, E. S.; GOMES, A. S. Uma estratégia de apoio à
institucionalização da usabilidade em ambientes de desenvolvimento ágil. In:
Proceedings of the VIII Brazilian Symposium on Human Factors in Computing
Systems. Sociedade Brasileira de Computação, 2008. p. 214-223.
BARBOSA, S. D. J.; SILVA, B.S. Interação Humano-Computador. Rio de Janeiro:
Elsevier, 2010.
BASTOS, J. C. S., OLIVEIRA, S. R. B. Práticas de IHC versus Processos de
Engenharia de Software: Uma Análise para Adoção. Encontro Anual de
Computação (ENACOMP), 2010.
BENYON, D. Interação Humano-Computador. Editora Pearson, 2011.
BIM, S. A. Uma experiência de integração entre as disciplinas de IHC, Engenharia
de Software e Banco de Dados. IHC2010–IX Simpósio de Fatores Humanos em
Sistemas Computacionais, 2010.
DA COSTA LIMA, A. K., DE MELO, F. C. C., FERREIRA, J. S. C., CUNHA, M. A.
Usabilidade: Avaliação de uma Escala de Medição em Sistema de Matrícula On-
Line em uma Universidade Pública. Revista Cesumar–Ciências Humanas e Sociais
Aplicadas, v. 20, n. 1, 2015.
DA COSTA, L. F.; RAMALHO, F. A. A usabilidade nos estudos de uso da
informação: em cena, usuários e sistemas interativos de informação. Perspectivas
em Ciência da Informação, v. 15, n. 1, p. 92-117, 2010.
DA SILVA, A. C., SILVA, J. C. A., PENTEADO, R. A. D., DA SILVA, S. R. P.
(2004). Aplicabilidade de Padrões de Engenharia de Software e de IHC no
Desenvolvimento de Sistemas Interativos. In IV Congresso Brasileiro de
Computação-CBComp (pp. 118-123).
DE ARAÚJO CAMARGO, L. S.; FAZANI, A. J. Explorando o Design Participativo
como Prática de Desenvolvimento de Sistemas de Informação. InCID: Revista de
Ciência da Informação e Documentação, v. 5, n. 1, p. 138-150, 2014.
SOUSA, V. E. C. D. Desenvolvimento e validação de software para apoio ao ensino-
aprendizagem sobre diagnósticos de enfermagem. 2015. Tese de Doutorado.
DE LIMA JUNIOR, G. A. F., DA SILVA, R. C. Guia de Boas Práticas para
Desenvolvimento de Interface e Interação para Desenvolvedores da Plataforma
Android. III Workshop de Iniciação Científica em Sistemas de Informação,
Florianópolis - SC, 2016.
DE MENDONÇA, J. M.; DA SILVA, R. M. S. Técnicas de usabilidade e testes
automatizados em processos de desenvolvimento de software empírico. Trabalho de
Conclusão de Curso – Universidade de Brasília – UnB Faculdade UnB Gama - FGA –
Brasília, DF, 2014-110 p.
DE OLIVEIRA, A. A. F.; DA CRUZ, D. T.; EZEQUIEL, J. P. Interface Homem-
Computador para Desenvolvimento de Software Educativo. 2004.
DE OLIVEIRA, A. C. A., BALDESSAR, M. J., MELO, L. R., FAGUNDES, P. B.
Análise de Usabilidade em Sistema de Resposta Audível automatizada, com base
no Percurso Cognitivo, Critérios Ergonômicos de Bastien e Scapin e Heurísticas de
Nielsen. III Workshop de Iniciação Científica em Sistemas de Informação,
Florianópolis- SC, 2016.
DE OLIVEIRA, D. H. D., DE MIRANDA, L. C., DE MIRANDA, E. E. C., DA
SILVA, L. F. (2012, November). Prototipação de interfaces de aplicativos para
dispositivos móveis: estado da arte e desafios de IHC. In Proceedings of the 11th
Brazilian Symposium on Human Factors in Computing Systems (pp. 315-324).
Brazilian Computer Society.
DE OLIVEIRA, T. N., SCHEFER, R. P., ZAINA, L. A., DA SILVA, N. G. A.
Aplicação do Método de Avaliação de Comunicabilidade em Dispositivos Móveis
74
para Surdos em Rede Social. Revista Interdisciplinar de Tecnologias e Educação, v. 1,
p. 37-47, 2015.
DE SOUZA, B. P., FERNANDES, P. S. A Influência da Meta-usabilidade e
Comunicabilidade nas Técnicas de Inspeção de Aplicações Web. II Workshop de
Iniciação Científica em Sistemas de Informação, Goiânia – GO, 2015.
DE SOUSA FERREIRA, D.; DE OLIVEIRA, K. Ma. A.; DE ARAÚJO ALENCAR, A.
Inclusão de Usabilidade no Processo de Desenvolvimento de Software da
DATAPREV. In: Proceedings of the IX Symposium on Human Factors in Computing
Systems. Brazilian Computer Society, 2010. p. 263-264.
DE SOUZA, P. C.; MACIEL, C.; DE MORAES, L. AO. Verificação de um modelo
para o projeto de aplicações web com ações integradas entre WebE e IHC. In:
Proceedings of the 12th Brazilian Symposium on Human Factors in Computing
Systems. Brazilian Computer Society, 2013. p. 296-299.
DE SOUZA, P. C., MACIEL, C., DE MORAES, L. A. Projetando sistemas web com
o uso de técnicas de interação humano-computador. In: Companion Proceedings of
the 11th Brazilian Symposium on Human Factors in Computing Systems. Brazilian
Computer Society, 2012. p. 55-58.
DIAS, A. L., FORTES, M. P. R., MASIERO, P., GOULARTE, R. Uma Revisão
Sistemática sobre a inserção de Acessibilidade nas fases de desenvolvimento da
Engenharia de Software em sistemas Web. In: Proceedings of the IX Symposium on
Human Factors in Computing Systems, IHC. 2010. p. 39-48.
FEDERAL, Governo. Cartilha de Usabilidade para Sítios e Portais do Governo
Federal. Versão 01–30/06/2004. Acesso em junho de 2016./em Português.
GASPARINI, I., KIMURA, M. H., PIMENTA, M. S. Visualizando 15 anos de IHC.
In: Proceedings of the 12th Brazilian Symposium on Human Factors in Computing
Systems. Brazilian Computer Society, 2013. p. 238-247.
GOMES, G. M. R.; CENDÓN, B. V. Análise da integração da recuperação da
informação, information search behaviour e interação humano-computador para
avaliação de sistemas de recuperação da informação. TransInformação, v. 27, n. 3,
2015.
KLOCK, A. C. T., CAMPOS, I. A., GASPARINI, I., HOUNSELL, M. D. S. Avaliação
de Usabilidade de Sistemas de Gerenciamento de Referências Bibliográficas. XII
Brazilian Symposium on Information Systems, Florianópolis - SC, 2016.
MATO-GROSSO. Secretaria de Estado de Gestão. Guia de Referência para o
Processo de Desenvolvimento de Software nas Instituições Públicas do Estado de
Mato Grosso. Cuiabá, 2010. 22 p.
MELO, A. M., BARANAUSKAS, M. C. C. Design para a inclusão: desafios e
proposta. In: Proceedings of VII Brazilian symposium on Human factors in computing
systems. ACM, 2006. p. 11-20.
MIRANDA, A. J. D. B.; DE BARROS, R. M.; PROENÇA, M. L. A integração da
Gestão do Design a um Processo de Desenvolvimento de Software de maturidade
nível G: uma experiência acadêmica na Fábrica de Software GAIA. Projetica, v.2,
n. 2, p. 16-30, 2011.
OLIVEIRA, A. D. A.; ELER, M. M. Acessibilidade em Governo Eletrônico: um
estudo sobre a aplicação de padrões web em sítios gov. br. 2015.
PEREIRA, S. R.; PAIVA, P. B. A importância da Engenharia da Usabilidade para a
Segurança de Sistemas Informatizados em Saúde. Journal of Health Informatics, v.
3, n. 3, 2011.
PRATES, R. O.; BARBOSA, S. D. J. Introdução à teoria e prática da interação
humano computador fundamentada na engenharia semiótica. Atualizações em
informática, p. 263-326, 2007.
PREECE, J.; ROGERS, Y.; SHARP, H. Design de interação. Bookman, 2005.
76
PRESSMAN, R. Engenharia de Software: Uma abordagem Profissional, 7ª edição,
Amgh Editora, 2011.
RABELLO, R. B., BARBALHO, R. A., NUNES, J. V., & VON WANGENHEIM, C.
G. Integração de engenharia de usabilidade em um modelo de
capacidade/maturidade de processo de software. In: Proceedings of the 11th
Brazilian Symposium on Human Factors in Computing Systems. Brazilian Computer
Society, 2012. p. 175-184.
SANTANA, F., ALMEIDA, A., HORNUNG, H. H., & BARANAUSKAS, C. Um
Processo de Avaliação de Acessibilidade Web Universal Aplicado ao Website da
Receita Federal: do Código a Testes com Usuários. IX Simpósio de Fatores Humanos
em Sistemas Computacionais, Belo Horizonte, 2010.
SECCO, A., CASSENOTE, M. R. S., CHICON, P. M. M. Integração do System
Usability Scale ao AVA CHAMILO. Simpósio de Pesquisa e Desenvolvimento em
Computação, v. 2, n. 1, 2016.
SILVEIRA, D. S.; SCHNEIDER, H. Nou. Utilização Do Framework Uef-Web No
Desenvolvimento De Uma Aplicação Web Ergonômica. RENOTE, v. 13, n. 1.
SONZA, A. P., CONFORTO, D., & SANTAROSA, L. Acessibilidade nos portais da
educação profissional e tecnológica do Ministério da Educação. Revista Brasileira
da Educação Profissional e Tecnológica, v. 1, n. 1, p. 131-145, 2015.
VALENTIM, N. M. C.; DE OLIVEIRA, K. M.; CONTE, T. Definindo uma
Abordagem para Inspeção de Usabilidade em Modelos de Projeto por meio de
Experimentação. In: Proceedings of the 11th Brazilian Symposium on Human Factors
in Computing Systems. Brazilian Computer Society, 2012. p. 165-174.
VILLELA, M. L. B.; XAVIER, S.; PRATES, R. O. Método de avaliação de
comunicabilidade para sistemas colaborativos: um estudo de caso. In: Proceedings
of the 11th Brazilian Symposium on Human Factors in Computing Systems. Brazilian
Computer Society, 2012. p. 277-286.
78
APÊNDICE A
AUTORIZAÇÃO PARA PESQUISA
APÊNDICE B
DOCUMENTO DE VISÃO
<Nota1: Este documento é uma template. O texto contido
dentro desta marcação “< >” é a instrução de elaboração do
documento. A instrução, assim como as marcações deverão ser
lidas e deletadas à medida que o documento for elaborado. Todas
deverão ser deletadas, inclusive as notas.>
<Nota2: Para que a numeração seja mantida, consistente
com o padrão, os títulos das seções e subseções devem continuar
aparecendo no documento, indicando-se “Não se aplica.” no
respectivo corpo quando não houver informações a serem
colocadas.>
DOCUMENTO DE VISÃO
Projeto: <Nome do Projeto>
Versão: <1.0>
Data de Revisão: <dd/mm/aaaa>
80
Histórico de Revisão
<As atualizações do documento devem ser reportadas, obrigatoriamente, neste
histórico.>
Data Descrição Autor
<dd/mm/aaaa> <Descrição da atualização realizada no
documento>
<Nome do
responsável pela
atualização>
Sumário
VISÃO ESTRATÉGICA ...................................................................................................... 82
ESCOPO ............................................................................................................................ 82
NÃO-ESCOPO ................................................................................................................... 82
DEFINIÇÕES E ABREVIATURAS ....................................................................................... 82
REFERÊNCIAS .................................................................................................................. 82
BENEFÍCIOS DO PROJETO ............................................................................................... 83
DESCRIÇÃO DO PROBLEMA ............................................................................................ 83
USUÁRIOS ENVOLVIDOS NO PROJETO ............................................................................ 84
USUÁRIO FINAL ............................................................................................................... 84
DESCRIÇÃO DE PERFIS DE USUÁRIOS ............................................................................. 84
DESCRIÇÃO DE TAREFAS POR CATEGORIA .................................................................... 84
DESCRIÇÃO DE CONTEXTOS DE USO E AMBIENTE DO USUÁRIO ................................... 85
PERSPECTIVA DO PRODUTO ............................................................................................ 85
LICENÇA E INSTALAÇÃO ................................................................................................. 86
82
Visão do Projeto
Introdução
O objetivo deste documento é a coleta, análise e definição das necessidades e
características do projeto <Nome do Projeto> em alto nível de abstração.
O foco deste documento é identificar as necessidades dos stakeholders
(patrocinadores do projeto) e usuários-alvo e o porquê delas existirem.
O detalhamento de como o <Nome do Projeto> suprirá estas necessidades será
realizado nas especificações de casos de uso e especificações suplementares.
Visão Estratégica
<Obrigatória a informação e deve ser vinculada a uma medida.>
<Transcrever a visão estratégica deste projeto que deve, obrigatoriamente,
delimitar e direcionar a concepção do escopo do projeto.>
Escopo
<Descrever texto explicativo e estruturado sobre o escopo do projeto, sendo
obrigatório sua aderência a Visão Estratégica. Identificar os módulos, funcionalidades e
sistemas associados.>
Não-Escopo
<Descrever texto explicativo e estruturado sobre o que não está dentro escopo do
projeto. Identificar os módulos, funcionalidades e sistemas associados.>
Definições e Abreviaturas
Vide Glossário do projeto.
Referências
<Identificar os documentos utilizados como referência para a definição do
projeto.> <Reportar as referências: existentes; existentes mais com necessidade de
atualização; e a serem criadas sob demanda deste projeto >
Nome do Documento de
Referência
Data de Criação Autor Situação
Atual
<nome do documento>
<Leis, Portarias,
Convênios, Atas...>
<dd/mm/aaaa>
<em caso de referência
a ser criada, não
informar data>
<Identificação do
autor>
<Expressar
segundo
legenda
abaixo>
Legenda de Situação: (1) Referência existente; (2) Referência existente, mas com necessidade de
atualização; (3) Referência deve ser criada sob demanda deste projeto.
Posicionamento
Benefícios do Projeto
<Descrever os benefícios que o projeto trará ao cliente e demais envolvidos.>
<Descrição do benefício 1>
<Descrição do benefício 2>
Descrição do Problema
<Descrever de forma resumida sobre o problema a ser resolvido por este projeto,
identificando os usuários afetados e o impacto causado pelo problema.>
Priorização das Necessidades
<Lista dos problemas chaves, por ordem de prioridade, com as soluções
existentes, percebidas pelo usuário, detalhando os seguintes tópicos de cada problema:
Quais são as razões do problema?
Como o problema está sendo resolvido atualmente?
Quais soluções propostas para o problema?>
84
Descrição da Necessidade
(Problema)
Solução Atual Solução Proposta
Descrição dos Usuários
Usuários Envolvidos no Projeto
Papel na Organização Entidade Representada Papel no Projeto
<tipo do papel na
organização>
<Descrição de que entidade o
usuário gestor está
representando no contexto do
desenvolvimento do projeto>
<Descrição do papel do
usuário gestor no processo
de desenvolvimento>
Usuário Final
Papel na Organização Descrição das Atividades Representado por
<tipo do papel na
organização>
<Descrição das atividades
que o usuário executará no
sistema>
<Usuário envolvido no
projeto que representa este
usuário>
Descrição de Perfis de Usuários
É interessante criar uma representação hierárquica dos perfis de usuários definidos.
Grupo Descrição Permissões
<nome do grupo> <Descrição do grupo> <Descrição das atividades
que esse grupo pode
realizar >
Descrição de Tarefas por Categoria
Categoria: <Nome da Categoria>
Tarefa Descrição da Tarefa Perfil de Usuário
<Nome da Tarefa> <Descrição da tarefa que o
usuário executará no
sistema>
<Usuário (s) envolvido no
projeto com permissão
para realizar a tarefa>
Descrição de Contextos de Uso e Ambiente do Usuário
<Descrever o ambiente de trabalho do usuário. Sugestões:
Descrever variáveis como número de pessoas necessárias para executar a
função e se este número pode sofrer alteração.
Descrever o número de pessoas envolvidas para a realização das tarefas
críticas do sistema.
Descrever tempo para conclusão das tarefas primordiais.
Descrever as plataformas utilizadas.
Citar aplicações que são utilizadas atualmente e citar aplicações que deverão
ser integradas com o sistema proposto (se existirem)
Se necessário descrever cenários de uso específicos>
Visão Geral do Produto
Esta seção descreve a visão geral das características do projeto <Nome do
Projeto> (textual e gráfica), expressando relação entre funcionalidades e interfaces com
as aplicações <Nomes das aplicações externas, caso exista>.
Perspectiva do Produto
<Descrição geral - textual e gráfica, do produto, expressando relações internas e
externas (integrações com outras aplicações). Pode-se apresentar o diagrama de
contexto do produto. Por exemplo: ilustrar interações entre funcionalidades e
integrações com aplicações>.
86
Licença e Instalação
<Especificar necessidades do usuário quanto ao controle de licença e instalação
do software desenvolvido e que impactam no esforço de desenvolvimento>
Características Funcionais
Esta seção define e descreve as características funcionais do <Nome do
Projeto>. As características funcionais são capacidades necessárias ao sistema para que
o mesmo possa atender a demanda funcional do usuário.
<Como o documento de visão é revisado por diversos papéis durante o projeto,
as funcionalidades devem ser descritas de forma resumida, permitindo o entendimento
de todos, contudo as informações devem ser necessárias o suficiente para a modelagem
de casos de uso. Tais funcionalidades devem fornecer a base fundamental para
identificar as operações, definição do produto, gerência de escopo e gerência do projeto,
sob um ponto de vista externo. Cada funcionalidade será explicada detalhadamente na
modelagem de casos de uso.>
<Nome da característica funcional>
<Descrição da funcionalidade e operações necessárias para executar a
característica funcional>
Funcionalidade: <nome da funcionalidade>
Operação: <nome da operação>
Impacto: <criação ou atualização ou exclusão>
Exemplo (Sistema ECF):
Exemplo (Sistema ECF):
Intervenção
Descrição: O sistema deve permitir que uma empresa interventora efetue uma
solicitação de intervenção. Na conclusão da solicitação o sistema deve gerar lacre
eletrônico do equipamento que sofrerá intervenção, podendo esta solicitação ser
consultada e/ou cancelada.
Funcionalidade: Intervenção
Operação: Solicitação de Intervenção
Impacto: criação
Operação: Cancelamento de Intervenção
Impacto: criação
Aprovação
Autor: <Nome>
Data Função Nome Assinatura
<<dd/mm/aaaa>>
<<dd/mm/aaaa>>
<<dd/mm/aaaa>>
88
APÊNDICE C
DOCUMENTO DE REQUISITOS
<Nota1: Este documento é uma template. O texto contido
dentro desta marcação “< >” é a instrução de elaboração do
documento. A instrução, assim como as marcações deverão ser lidas
e deletadas à medida que o documento for elaborado. Todas deverão
ser deletadas, inclusive as notas.>
<Nota2: Para que a numeração seja mantida, consistente com
o padrão, os títulos das seções e subseções devem continuar
aparecendo no documento, indicando-se “Não se aplica.” no
respectivo corpo quando não houver informações a serem
colocadas.>
DOCUMENTO DE REQUISITOS
Projeto: <Nome do Projeto>
Versão: <1.0>
Data de Revisão: <dd/mm/aaaa>
Histórico de Revisão
<As atualizações do documento devem ser reportadas, obrigatoriamente, neste
histórico.>
Data Descrição Autor
<dd/mm/aaaa> <Descrição da atualização realizada no
documento>
<Nome do
responsável pela
atualização>
90
Sumário
INTRODUÇÃO ........................................................................................................................ 91
DESCRIÇÃO TEXTUAL DOS REQUISITOS ....................................................................... 91
PRIORIDADE DOS REQUISITOS ......................................................................................... 91
REQUISITOS FUNCIONAIS .................................................................................................. 92
REQUISITOS NÃO-FUNCIONAIS ........................................................................................ 93
REQUISITOS DE USABILIDADE ......................................................................................... 93
APROVAÇÃO ......................................................................................................................... 94
Documento de Requisitos
Introdução
Este documento tem por objetivo capturar os requisitos a serem utilizados no
sistema, na forma textual e estruturada, do projeto <Nome do Projeto>.
<Descrever o contexto e a finalidade so software.>
Descrição Textual dos Requisitos
<Descrever os requisitos a serem contemplados no projeto>
<Essa descrição pode ser estruturada em itens e subitens, que definirão as
entidades e as operações a serem realizadas.>
<Entende-se por Entidade qualquer coisa, objeto, concreto ou abstrato que
possui existência distinta sobre o qual precisa-se armazenar e/ou recuperar
informações.>
<Entende-se por Operação qualquer ação a ser executada com as informações da
entidade. As entidades podem ter mais de uma operação.>
Prioridade dos requisitos
Para estabelecer a prioridade dos requisitos, sugere-se as denominações
“essencial”, “importante” e “desejável”.
1. Essencial é o requisito sem o qual o sistema não entra em funcionamento.
Requisitos essenciais são requisitos imprescindíveis, que têm que ser
implementados impreterivelmente.
1. Importante é o requisito sem o qual o sistema entra em funcionamento, mas de
forma não satisfatória. Requisitos importantes devem ser implementados, mas,
se não forem, o sistema poderá ser implantado e usado mesmo assim.
2. Desejável é o requisito que não compromete as funcionalidades básicas do
92
sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele.
Requisitos desejáveis podem ser deixados para versões posteriores do sistema,
caso não haja tempo hábil para implementá-los na versão que está sendo
especificada.
Requisitos Funcionais
<Operação>
Prioridade: <nome da prioridade>
Descrição: <Descrever a operação referente a entidade a ser executada, os dados
utilizados e as regras para execução.>
Exemplo:
Cadastrar fabricante
Prioridade: Essencial
Consiste em cadastrar os fabricantes ou montadoras de equipamento emissor de cupom
fiscal que tiveram seus modelos de equipamento autorizados pela Cotepe. Durante o
cadastro de fabricantes, o usuário deverá informar os seguinte dados:
Tipo de produção *: indica se o fabricante tem:
o Produção própria
o Produção O&M
o Ambos os tipos de produção.
Número do CNPJ *: deve ser selecionar um CNPJ válido no cadastro de
pessoas. Se o CNPJ não estiver cadastrado, deverá efetuar o cadastro a
partir de um serviço disponível no sistema de cadastro.
Fabricante(s) vinculado(s): para fabricantes que tem produção O&M, o
usuário será obrigado a informar o(s) fabricante(s) fornecedores de peças
para confecção dos modelos de ECF que serão montados. Neste caso, o
usuário deverá informar pelo menos um fabricante modelo. É importante
observar que os fabricante informados como modelo terão
obrigatoriamente que ter tipo de produção própria ou ambos os tipos de
produção. Além disso, o fabricantes modelo devem estar cadastrados e
sua situação deve ser Ativo.
No caso o fabricante ter ambos os tipos de produção, o fabricante vinculado
poderá corresponder a ele próprio, já que é possível ter a célula de produção própria
fornecendo peças para a célula O&M. Assim sendo, o fabricante vinculado não é
obrigatório.
Um fabricante, cujo tipo de produção for própria, não poderá ter fabricantes
vinculados associado.
Caso o fabricante se trate de um contribuinte não inscrito, o usuário deverá
informar adicionalmente:
Responsável (is) *: responsável(is) pessoa física do fabricante. O usuário
deverá informar pelo menos um responsável com as seguinte
informações:
Número do CPF
Nome do responsável
(*) Informações obrigatórias
Caso o fabricante a ser cadastrado corresponda a um contribuinte inscrito na
Sefaz-MT, este deverá estar com a situação Ativa para que o cadastro seja permitido.
Requisitos Não-Funcionais
<Operação>
Prioridade: <nome da prioridade>
Descrição: <Descrever a operação referente a entidade a ser executada, os dados
utilizados e as regras para execução.>
Requisitos de Usabilidade
Deve-se definir critérios de qualidade em IHC, que posteriormente serão validados
94
pelos clientes/usuários na entrega do produto. Exemplo: usabilidade (facilidade de
aprendizado, facilidade de recordação, eficiência, segurança no uso, satisfação do
usuário), experiência do usuário, acessibilidade e comunicabilidade.
Especificar Requisitos de Usabilidade e Design:
<Requisito>
Prioridade: <nome da prioridade>
Descrição: <Descrever o requisito de usabilidade relacionando atividades, usuários,
dados e regras de execução>
Aprovação
Autor: <Nome do Analista de Requisitos>
Data Função Nome Assinatura
<dd/mm/aaaa>
<dd/mm/aaaa>
APÊNDICE D
PROJETO DE IHC
PROJETO DE IHC
Projeto: <Nome do Projeto>
Versão: <1.0>
Data de Revisão: <dd/mm/aaaa>
<Nota1: Este documento é uma template. O texto contido
dentro desta marcação “< >” é a instrução de elaboração do
documento. A instrução, assim como as marcações deverão ser lidas
e deletadas à medida que o documento for elaborado. Todas deverão
ser deletadas, inclusive as notas.>
<Nota2: Para que a numeração seja mantida, consistente com
o padrão, os títulos das seções e subseções devem continuar
aparecendo no documento, indicando-se “Não se aplica.” no
respectivo corpo quando não houver informações a serem
colocadas.>
96
Histórico de Revisão
<As atualizações do documento devem ser reportadas, obrigatoriamente, neste
histórico.>
Data Descrição Autor
<dd/mm/aaaa> <Descrição da atualização realizada no
documento>
<Nome do
responsável pela
atualização>
Sumário
INTRODUÇÃO ........................................................................................................................ 98
PROJETO DE CONTEÚDO .................................................................................................... 98
PROJETO DE ARQUITETURA ............................................................................................. 98
PROJETO DE NAVEGAÇÃO ................................................................................................ 99
PROJETO DE INTERAÇÃO ................................................................................................... 99
APROVAÇÃO ......................................................................................................................... 99
98
Projeto de IHC
Introdução
Este documento tem por objetivo descrever as soluções de software propostas
relacionadas a área de IHC do projeto <Nome do Projeto>. Esse documento é dividido
em quatro projetos: projetos de conteúdo, projeto de arquitetura, projeto de navegação e
projeto de interação.
Projeto de Conteúdo
Apresentar toda a informação que deve conter na aplicação, ou seja, descrever os
conteúdos e elementos necessários a aplicação com base nas informações passadas
pelos clientes e usuários.
Projeto de Arquitetura
Propor como deve ser a disponibilidade das informações na aplicação através,
por exemplo, das técnicas de storyboarding e wireframes de conteúdo. Abaixo um
exemplo de wireframe de conteúdo:
Artefato: < Nome do artefato>
Wireframe de Conteúdo [Fonte: De Souza et al., 2012]
<Descrição do artefato>
Projeto de Navegação
Desenvolver mapas de navegação que devem focar na experiência que o usuário
terá com a aplicação, destacando como estes se movimentam pela ela.
Projeto de Interação
Desenvolver protótipos de média e alta fidelidade considerando o documento
Guia de Estilo. Pode ser inserido aqui capturas de telas desses protótipos.
Aprovação
Autor: <Nome do Analista>
Data Função Nome Assinatura
<dd/mm/aaaa>
<dd/mm/aaaa>
100
APÊNDICE E
PLANO DE TESTE
PLANO DE TESTE
Projeto: <Nome do Projeto>
Versão: <1.0>
Data de Revisão: <dd/mm/aaaa>
<Nota1: Este documento é uma template. O texto contido
dentro desta marcação “< >” é a instrução de elaboração do
documento. A instrução, assim como as marcações deverão ser lidas
e deletadas à medida que o documento for elaborado. Todas deverão
ser deletadas, inclusive as notas.>
<Nota2: Para que a numeração seja mantida, consistente com
o padrão, os títulos das seções e subseções devem continuar
aparecendo no documento, indicando-se “Não se aplica.” no
respectivo corpo quando não houver informações a serem
colocadas.>
Histórico de Revisão
<As atualizações do documento devem ser reportadas, obrigatoriamente, neste
histórico.>
Data Descrição Autor
<dd/mm/aaaa> <Descrição da atualização realizada no
documento>
<Nome do
responsável pela
atualização>
102
Sumário
INTRODUÇÃO .................................................................................................................... 103
PROPÓSITO .......................................................................................................................... 103 ESCOPO................................................................................................................................ 105 IDENTIFICAÇÃO DO PROJETO ............................................................................................... 106
REQUISITOS DE TESTE ................................................................................................... 107
ESTRATÉGIA DE TESTE ................................................................................................. 107
TESTE DE INTEGRIDADE DE DADOS E DO BANCO DE DADOS ............................................... 107 TESTES FUNCIONAIS ............................................................................................................ 108
PLANO DE TESTE - AVALIAÇÃO DE IHC ................................................................... 108
TESTE DA INTERFACE COM ESPECIALISTAS EM IHC ............................................................ 108 TESTE DA INTERFACE COM USUÁRIOS ................................................................................. 109
TESTE DE SEGURANÇA E CONTROLE DE ACESSO ............................................... 110
FERRAMENTAS ................................................................................................................. 111
RECURSOS .......................................................................................................................... 111
PAPÉIS ................................................................................................................................. 111
SISTEMA .............................................................................................................................. 112
PRAZO DE EXECUÇÃO .................................................................................................... 112
HOMOLOGAÇÃO .............................................................................................................. 113
LOGS DE TESTE .................................................................................................................... 113 RELATÓRIOS DE DEFEITOS ................................................................................................... 113
Plano de Teste
Introdução
Propósito
Este documento de Plano de Testes do projeto <nome do projeto> tem os
seguintes objetivos:
<Indique as informações de projeto e os componentes de software a serem testados;>
Serão testados:
i. Requisitos funcionais através dos casos de uso, modelo de casos de
uso, especificações funcionais e diagramas de atividade.
ii. Requisitos não funcionais, descritos no documento de especificações
suplementares;
iii. Desempenho, derivados do documento de especificações
suplementares.
Tipo de testes:
i. Funcionais: com foco na execução dos casos de uso. A estratégia a
ser utilizada é o de caixa preta (black box), isto é, comportamento
externo do sistema.
ii. Desempenho do sistema (Performance): foco na medição do tempo
de resposta.
iii. Configuração: identificar e validar o comportamento da aplicação
sobre testes em diferentes configurações, derivados das
especificações suplementares.
iv. Documentação: entrada derivada das especificações suplementares
Objetivos do Teste:
104
i. Verificar se a navegação, entrada de dados, processamento e
recuperação dos dados está em conformidade com os requisitos do
sistema.
ii. Avaliar o desempenho do sistema.
iii. Avaliar o comportamento do sistemas em diferentes configurações
de hardware e software.
Técnicas:
i. Identificar transações
ii. Identificar e executar caso de testes em condições positivas (caminho
feliz) e negativas.
iii. Criar os procedimentos de testes:
Onde começar.
Como implementar, executar, verificar e validar a execução.
Critério de validação:
i. Todos os erros encontrados serão registrados <indique a ferramenta
ou planilha>.
Será enviado um relatório dos resultados obtidos para o Gerente de projeto.
i. Recursos humanos
ii. Projetista de teste
iii. Testador/Implementador/Especialista em IHC
iv. Especialista nas ferramentas de teste
Ambiente de Teste:
Hardware
i. Plataforma para implementação dos testes
ii. Plataforma para execução dos testes (ambiente do cliente)
Ferramentas
i. <Indique a ferramenta utilizada, se houver>.
Dados
i. Definir carregamento de dados para teste (datapool, arquivo texto e
banco de dados)
ii. Definir área no banco de dados para os testes
Escopo
Os principais motivos são:
i. Realizar testes de verificação do sistema (inexistência de erros);
ii. Realizar testes de interação com outros sistemas;
iii. Realizar testes do comportamento do sistema em ambientes de
produção.
iv. Realizar avaliações de inspeção de conformidade e observação
Tipo de testes:
i. Funcionais: com foco na execução dos casos de uso da interface do
usuário. O estratégia a ser utilizada é o de caixa preta (black box),
isto é, comportamento externo do sistema.
ii. Desempenho do sistema (Performance): foco na medição do tempo
de resposta.
iii. Configuração: identificar e validar o comportamento da aplicação
sobre testes em diferentes configurações.
iv. Volume/carga: impactos da disponibilização do sistema.
v. Stress: identificar o comportamento do sistema em situação de sobre-
uso.
<Entre com uma lista de características e funcionalidades dos elementos a serem
testados. Entre com uma lista restrições, riscos ou contingências que podem
afetar o projeto, desenvolvimento ou execução dos testes.>
106
Identificação do Projeto
A tabela abaixo identifica os documentos disponíveis usados para desenvolver o Plano
de Teste:
<Nota: Remova ou inclua itens de acordo com a necessidade>
Documento
(versão/data)
Disponível Recebido
ou
Revisado
Autor ou
Recurso
Observações
Especificação de
Requisitos
Sim
Não
Sim
Não
Especificações
Funcionais
Sim
Não
Sim
Não
Relatório de Casos de
uso
Sim
Não
Sim
Não
Plano de Projeto Sim
Não
Sim
Não
Projeto de IHC Sim
Não
Sim
Não
Especificações do
Projeto
Sim
Não
Sim
Não
Protótipo Sim
Não
Sim
Não
Manual do Usuário Sim
Não
Sim
Não
Modelo de Negócio Sim
Não
Sim
Não
Modelo de Dados Sim
Não
Sim
Não
Regras e Funções de
Negócio
Sim
Não
Sim
Não
Avaliação de Risco de
Negócio ou Projeto
Sim
Não
Sim
Não
Lista de Riscos do
Projeto
Sim
Não
Sim
Não
Requisitos de Teste
A lista abaixo indica os itens – requisitos funcionais e não funcionais – que
foram identificados como alvos para testes. Esta lista representa o que será testado:
<Descreva os requisitos funcionais e não funcionais>
Estratégia de Teste
O objetivo principal é verificar se os requisitos do projeto foram atendidos
corretamente de acordo com as necessidades levantadas junto ao cliente.
Teste de Integridade de Dados e do Banco de Dados
O banco de dados e os processos deverão ser testados como um subsistema do
<nome do projeto>. Esses subsistemas serão testados sem a interface do usuário.
Objetivo do Teste: Garantir que os processos e métodos de acesso à base de
dados funcionem adequadamente e sem corrupção de dados.
Mecanismo:
Acionar todos os processos e métodos de acesso à base de
dados, passando para cada um dos dados válidos e inválidos.
Inspecionar a base de dados para garantir que os dados
tenham sido incluídos corretamente, que todos os eventos do
banco de dados tenham ocorrido adequadamente e analisar os
dados retornados para garantir que os mesmos tenham sido
recuperados corretamente.
Critério de
Completude:
Todos os processos e métodos de acessos ao banco de dados
estejam como projetado e sem qualquer corrupção nos dados.
Considerações
Especiais:
Este teste pode necessitar que seja utilizado um ambiente
adequado para acesso às informações do banco de dados
diretamente, viabilizando a inclusão ou alteração direta contra
a base de dados.
Este processo deve ser acionado manualmente.
É interessante que a base de dados de teste tenha poucos
registros de forma a melhorar a visibilidade de eventos de
erros.
108
Testes Funcionais
A meta deste teste é verificar a aceitação dos dados, processamento, resposta e a
implementação apropriada das regras de negócio. Este tipo de teste é baseado nas
técnicas de caixa preta (black Box).
Objetivo do Teste: Garantir o funcionamento adequado do objeto em teste,
incluindo a navegação, entrada de dados, processamento e
recuperação.
Mecanismo:
Executar cada caso de uso, fluxo de caso de uso ou função,
usando dados válidos e inválidos de forma a verificar se:
É apresentado o resultado esperado quando um dado
válido é usado;
É apresentada uma mensagem de erro (ou atenção)
apropriada quando um dado inválido e usado;
Cada regra de negócio é aplicada adequadamente.
Critério de
Completude:
Todos os testes planejados foram executados;
Foi dado encaminhamento para todos os defeitos
observados.
Considerações
Especiais:
Plano de Teste - Avaliação de IHC
O plano de teste para avaliação de IHC descreve a avaliação, especificando os objetivos
da sessão de teste, detalhes práticos (onde, quando, tempo de duração, equipamentos e
materiais necessários), número e tipo de participantes e tarefas a serem realizadas com a
especificação de término bem-sucedido.
Teste da Interface com Especialistas em IHC
Os testes com especialistas têm o objetivo de identificar possíveis problemas que os
usuários teriam ao interagirem com o sistema. Os métodos de inspeção não envolvem a
participação de usuários e tratam de experiências potenciais de uso realizadas pelo
avaliador. A meta é assegurar que os objetos dentro da UI funcionem como esperado e
em conformidade com padrões estabelecidos.
Sugestões de métodos que podem ser utilizados: Avaliação Heurística, Percurso
Cognitivo e Método de Inspeção Semiótica.
Teste: <Nome do Teste>
Objetivo: <Descrever objetivos do teste>
Métodos/ técnicas: <Nome da técnica/ método>
Detalhes práticos: <onde, quando, tempo de duração, equipamentos e materiais
necessários, ferramentas>
Participantes: <Número e tipo de participantes>
Tarefas: <Tarefas a serem realizadas com a especificação de término
bem-sucedido>
Considerações
Especiais:
Teste da Interface com Usuários
Os testes com usuários são mais adequados para avaliar protótipos e sistemas que
estejam funcionando. Este teste verifica a interação do usuário com o software. A meta
é assegurar que os objetos dentro da UI funcionem como esperado e em conformidade
com padrões estabelecidos. Sugestões de métodos que podem ser utilizados: Teste de
usabilidade e Teste de Comunicabilidade.
Teste: Teste de Usabilidade
Objetivo: <Descrever objetivos do teste>
Métodos/ técnicas: <Ex: Questionário>
Detalhes práticos: <onde, quando, tempo de duração, equipamentos e materiais
necessários , ferramentas>
Participantes: <Número e tipo de participantes>
Tarefas: <Tarefas a serem realizadas com a especificação de término
bem-sucedido>
Considerações
Especiais:
110
Teste de Segurança e Controle de Acesso
Este teste tem seu foco em duas áreas principais de segurança:
Segurança em nível aplicação, incluindo acesso as funções de dados e
negócio.
Segurança em nível sistema, incluindo logar ou acessar remotamente o
sistema.
Objetivo do Teste: Segurança em nível de aplicação: Verifique se um ator
pode acessar somente as funcionalidades ou dados para
os qual tenha sido dada permissão ao seu tipo de
usuário;
Segurança em nível de sistema: Verifique se somente
os atores com acesso ao sistema e aplicações tenha
permissões para acessá-lo;
Mecanismo: Utilizar testes desenvolvidos para perfis de
desempenho ou testes de carga.
Crie testes para cada tipo de usuário e verifique cada
permissão, criando transações específicas para cada
tipo de usuário;
Altere o tipo do usuário e execute os mesmos testes
para os mesmos usuários. Em cada caso, verifique se
as funcionalidades adicionais ou dados foram
disponibilizados ou negados adequadamente;
Definir um limite para o tamanho do banco de dados
(real, adaptável ou preenchido com dados
representativos) e múltiplos clientes para executar
consultas e reportar transações simultaneamente por
longos períodos.
Critérios
Complementares:
Para cada tipo de ator, as funcionalidades ou dados
estejam disponíveis e todas as transações funcionem
como esperado e de acordo com a execução prévia dos
testes funcionais da aplicação.
Considerações Especiais: O acesso ao sistema deve ser revisado ou discutido
com o administrador do sistema ou da rede. Este teste
pode não ser necessário uma vez que pode ser
responsabilidade do administrador do sistema ou da
rede.
Ferramentas
As seguintes ferramentas serão usadas neste projeto:
Finalidade Ferramenta Terceirizada/In-house Versão
<qual a finalidade da
ferramenta>
<Nome> <Propriedade> <versão>
Testes Funcionais Robot, Test
Manager
2001A
04
Recursos
Esta sessão apresenta os recursos recomendados para o <nome do projeto>, suas
responsabilidades principais e seu conhecimento ou conjunto de habilidades.
Papéis
Esta tabela mostra os recursos humanos alocados para os testes
Recursos Humanos
Papel Recursos mínimos
necessários
Responsabilidades Específicas
Gerente de projeto de
teste
Supervisiona os testes
Adquire recursos necessários
Fornece relatório de
gerenciamento
Projetista de teste
(especialista em IHC)
Gerar plano de teste
Gerar modelo de teste
Avaliar a efetividade do esforço
de teste
Testador (especialista
em IHC)
executar testes
recuperar os erros
documentar solicitação de
mudança
Gerente de banco de
dados
administrar dados para teste
(banco de dados)
112
Implementador criar as classes e pacotes de teste
implementados no modelo de
teste.
Sistema
A tabela seguinte apresenta recursos do sistema para o projeto de teste.
Recursos do Sistema
Recursos Nome/tipo
Servidor de Banco de Dados
Rede
—Nome do servidor
—Nome do banco de dados
Maquinas de teste Cliente
—Incluir configuração de requisitos
Repositório de teste
—Rede
—Nome do servidor
Máquinas (PC´s) de desenvolvimento
de testes
Prazo de execução
O teste do Sistema de <nome do projeto> deve incorporar as atividades para
cada esforço de teste identificado nas sessões anteriores.
Atividade Duração Data de
Início
Data de
Término
Criar plano de teste 2 dias
Projetar teste 2,5 dias por caso de uso
Implementar teste 1,5 dia por caso de uso
Executar teste 1 dia por caso de uso
Avaliar teste 0,5 dia por caso de uso
Homologação
Logs de teste
<Ferramenta utilizada para registro de log, quando aplicável>.
Relatórios de defeitos
<Ferramenta utilizada para registro ou local onde os erros foram registrados>
114
APÊNDICE F
CASO DE TESTE
<Nome do Caso de Uso>
Projeto: <Nome do Projeto> Módulo: <Nome do módulo>
Data: <dd/mm/aaaa> Versão: <x.x> Responsável: <Nome>
Objetivo
O objetivo deste documento é fornecer uma visão geral dos Casos de Testes levantados
para o caso de uso <Nome do Caso de Uso>.
Escopo
<Enumerar casos de teste para cada fluxo descrito no documento de especificação do
caso de uso Identificar e comunicar as condições que serão implementadas no teste e
que são necessárias para verificar uma implementação de sucesso e aceitável dos
requisitos do produto (casos de uso, características de performance, etc).>
Definições e Abreviaturas
Vide Glossário do Projeto e documento Abreviaturas.
Referências
Os casos de teste a serem realizados utilizam as seguintes documentações:
Especificação do Caso de Uso <Nome do Caso de Uso>;
Diagramas de Caso de Uso;
Plano de Teste.
<Acrescente outros, se houver>
Interface
Teste com especialistas
Especificar condições de aplicação dos métodos utilizados nos testes com especialistas.
Sugere-se a utilização dos métodos avaliação heurística, percurso cognitivo e inspeção
semiótica, conforme explicado no capítulo 4.
Exemplo: avaliação heurística, ide Apêndice G.
Teste com usuários
Especificar condições de aplicação dos métodos utilizados nos testes com usuários.
Sugere-se a utilização dos métodos teste de usabilidade e avaliação de
comunicabilidade, conforme explicado no capítulo 4.
Exemplo: teste de usabilidade, ide Apêndice I.
Funcionais
<<Nome do Caso de Teste>>
Cenário/ Condição: <descrição do cenário/ condição inicial de teste >
Fator: <descrição dos fatores>
Resultados Esperados: <descrição da ação a ser executada>
Legenda
V - Para situações válidas
I - Para situações inválidas
A - Para situações alternativas
N/A - Não se aplica
116
APÊNDICE G
AVALIAÇÃO HEURÍSTICA
Roteiro de Atividades
A tabela abaixo apresenta um roteiro de atividades e tarefas para aplicação do método
de avaliação heurística proposto por BARBOSA e SILVA (2010).
Atividade Tarefa
Preparação Todos os avaliadores:
Aprendem sobre a situação atual: usuários, domínio etc.
Selecionam as partes da interface que devem ser
avaliadas
Coleta Cada avaliador, individualmente:
Inspeciona a interface para identificar violações das
heurísticas
Lista os problemas encontrados pela inspeção, indicando
local, gravidade, justificativa e recomendações de solução
Interpretação
Consolidação dos
resultados
Todos os avaliadores:
Revisam os problemas encontrados, julgando sua
relevância, gravidade, justificativa, e recomendações de
solução
Geram um relatório consolidado que deve inserido no
artefato Caso de Teste
Relato dos
Resultados
O Checklist de usabilidade, a seguir, pode ser utilizado como ferramenta de coleta de
dados no processo de avaliação heurística.
Checklist de Usabilidade – Avaliação Heurística
Avaliador: <Nome do Avaliador> Data: <dd/mm/aaaa>
Aplicação: <Nome da Aplicação>
Interface: <Listar partes da Interface avaliadas, pode ser por páginas,
módulos, funcionalidades, ou até a aplicação como um todo>
Marque N para “Não”, P para “Parcial”, S para “Sim” e NA para “Não se aplica”.
Visibilidade do status do sistema
1. Para cada ação do usuário a aplicação oferece feedback imediato e adequado
sobre seu status?
( ) N ( ) P ( ) S ( ) NA
2. Os itens selecionados são claramente distintos dos demais?
( ) N ( ) P ( ) S ( ) NA
3. As mensagens sobre o status da aplicação possuem uma linguagem clara e
concisa?
( ) N ( ) P ( ) S ( ) NA
4. Todas as telas possuem identificação?
( ) N ( ) P ( ) S ( ) NA
5. Todas as telas mantêm acessíveis menus e funções comuns da aplicação?
( ) N ( ) P ( ) S ( ) NA
6. Fornece um update do status para operações mais lentas?
( ) N ( ) P ( ) S ( ) NA
7. A aplicação oferece informações sobre sua versão?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Compatibilidade entre sistema e mundo real
8. A linguagem utilizada é adequada a linguagem do usuário?
( ) N ( ) P ( ) S ( ) NA
9. O significado de símbolos e ícones são compreensíveis e intuitivos?
( ) N ( ) P ( ) S ( ) NA
10 10. As informações são dispostas em uma ordem lógica e natural?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Controle e liberdade para o usuário
11. É o usuário quem inicia e encerra tarefas e não a aplicação?
( ) N ( ) P ( ) S ( ) NA
118
12. É possível identificar o número de passos necessários para a realização de uma
tarefa?
( ) N ( ) P ( ) S ( ) NA
13. A aplicação oferece mensagens de fechamento para tarefas que envolvam um
conjunto de etapas?
( ) N ( ) P ( ) S ( ) NA
14. É possível retornar a tela anterior a qualquer momento?
( ) N ( ) P ( ) S ( ) NA
15. O usuário pode desfazer uma ação?
( ) N ( ) P ( ) S ( ) NA
16. O usuário pode refazer uma ação?
( ) N ( ) P ( ) S ( ) NA
17. Em aplicações com sobreposição de janelas, estas possuem transparência para
que seu contexto fique visível?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Consistência e padrões
18. As telas com o mesmo tipo de conteúdo possuem o mesmo título?
( ) N ( ) P ( ) S ( ) NA
19. Controles e botões se distinguem do restante do layout, deixando evidente que
são clicáveis?
( ) N ( ) P ( ) S ( ) NA
20. Itens não clicáveis deixam evidente que não o são?
( ) N ( ) P ( ) S ( ) NA
21. O nome do botão/ícone é consistente com o nome da tela que abre?
( ) N ( ) P ( ) S ( ) NA
22. Todas as informações textuais da aplicação utilizam o mesmo idioma?
( ) N ( ) P ( ) S ( ) NA
23. Funções diferentes são apresentadas de maneira distinta ao usuário?
( ) N ( ) P ( ) S ( ) NA
24. Funções semelhantes são apresentadas de forma similar?
( ) N ( ) P ( ) S ( ) NA
25. A forma de navegação é consistente entre as telas da aplicação?
( ) N ( ) P ( ) S ( ) NA
26. Os links são tratados de forma consistente entre as telas?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Prevenção de erros
27. Em caso de erros, o sistema permite corrigi-los com facilidade?
( ) N ( ) P ( ) S ( ) NA
28. Nas primeiras interações do usuário com a aplicação são mostradas instruções
básicas?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Reconhecimento em lugar de lembrança
29. Os títulos das telas são curtos?
( ) N ( ) P ( ) S ( ) NA
30. Utiliza o nome da tela anterior ao invés de “voltar” para nomes de botões e
links?
( ) N ( ) P ( ) S ( ) NA
31. Há padronização de cores para identificação e sinalização das áreas da
aplicação?
( ) N ( ) P ( ) S ( ) NA
32. A aplicação utiliza em seus textos e rótulos, uma linguagem habitual e
conhecida pelo usuário?
( ) N ( ) P ( ) S ( ) NA
33. Os títulos das telas descrevem adequadamente seu conteúdo?
( ) N ( ) P ( ) S ( ) NA
34. Os rótulos dos links descrevem adequadamente seu conteúdo?
( ) N ( ) P ( ) S ( ) NA
35. Em campos onde há a necessidade de inserção de dados isso é evidente?
( ) N ( ) P ( ) S ( ) NA
Anotações:
120
Flexibilidade e eficiência de uso
36. A aplicação possui funcionalidades que são acessíveis a usuários com
deficiência visual?
( ) N ( ) P ( ) S ( ) NA
37. A aplicação possui funcionalidades que são acessíveis a usuários com
deficiência motora?
( ) N ( ) P ( ) S ( ) NA
38. O propósito/função da aplicação é claro?
( ) N ( ) P ( ) S ( ) NA
39. A aplicação é carregada rapidamente?
( ) N ( ) P ( ) S ( ) NA
40. A aplicação funciona corretamente, sem apresentar problemas durante a
interação?
( ) N ( ) P ( ) S ( ) NA
41. 46. As funções mais utilizadas são facilmente acessadas?
( ) N ( ) P ( ) S ( ) NA
42. A aplicação utiliza objetos (ícones) ao invés de botões?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Projeto minimalista e estético
43. São exibidas apenas informações relacionadas a tarefa que está sendo
realizada?
( ) N ( ) P ( ) S ( ) NA
44. São usados textos somente quando estes são realmente indispensáveis?
( ) N ( ) P ( ) S ( ) NA
45. Em textos o uso de abreviaturas é evitado?
( ) N ( ) P ( ) S ( ) NA
46. O menu é esteticamente simples e claro?
( ) N ( ) P ( ) S ( ) NA
47. Os títulos de telas/janelas e rótulos de botões/links são curtos?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Auxiliar os usuários a reconhecer, diagnosticar e recuperar erros
48. As mensagens de erro são expressas em linguagem natural (sem código),
sugerindo uma solução?
( ) N ( ) P ( ) S ( ) NA
49. As mensagens de erros são claras e simples de forma a não intimidar o
usuário?
( ) N ( ) P ( ) S ( ) NA
Anotações:
Ajuda e documentação
50. O usuário utiliza com frequência a funcionalidade de ajuda?
( ) N ( ) P ( ) S ( ) NA
51. A ajuda está disposta de forma fácil de ser encontrada?
( ) N ( ) P ( ) S ( ) NA
52. Possui ajuda interativa e centrada na tarefa do usuário?
( ) N ( ) P ( ) S ( ) NA
Anotações:
122
APÊNDICE H
DOCUMENTO DE HOMOLOGAÇÃO
HOMOLOGAÇÃO
Projeto: <Nome do Projeto>
Versão: <1.0>
Data de Revisão: <dd/mm/aaaa>
<Nota1: Este documento é uma template. O texto contido dentro
desta marcação “< >” é a instrução de elaboração do documento. A
instrução, assim como as marcações deverão ser lidas e deletadas à
medida que o documento for elaborado. Todas deverão ser deletadas,
inclusive as notas.>
<Nota2: Para que a numeração seja mantida, consistente com o
padrão, os títulos das seções e subseções devem continuar aparecendo
no documento, indicando-se “Não se aplica.” no respectivo corpo
quando não houver informações a serem colocadas.>
Sumário
FUNCIONALIDADES DO PRODUTO/VERSÃO ............................................................... 124
FUNCIONALIDADE DO DOCUMENTO DE VISÃO ........................................................ 124
RESULTADOS DOS TESTES COM USUÁRIOS ............................................................... 124
APROVAÇÃO DO DOCUMENTO ...................................................................................... 125
124
Documento de Homologação
Funcionalidades do Produto/Versão
<Nesta seção deverão ser avaliadas as características funcionais e não funcionais
definidas no documento de visão, quanto ao seu atendimento.>
<Cada item deverá ser classificado em: Atendido Totalmente, Atendido Parcialmente,
Não atendido.>
Funcionalidade do documento de visão
<<Nome/Descrição da Funcionalidade>> <<Classificação>>
<<Nome/Descrição da Funcionalidade>> <<Classificação>>
<<Nome/Descrição da Funcionalidade>> <<Classificação>>
<<Nome/Descrição da Funcionalidade>> <<Classificação>>
Exemplo:
Criar Funcionalidade de Consulta de Laudo Preenchido. <Atendido Totalmente>
Criar Funcionalidade de inclusão de Laudo < Atendido Parcialmente>
Resultados dos Testes com Usuários
Os testes com usuários proporcionam a interação destes com a aplicação desenvolvida
de maneira que seja possível o relato das suas percepções e nível de satisfação com
relação às interfaces utilizadas.
Descrever de maneira mais objetiva e clara possível os resultados obtidos com os testes
com usuários. Sugestão: utilizar relatórios com gráficos e tabelas que sumarizam as
medições realizadas.
No caso da aplicação do método teste de usabilidade, as informações que devem conter
o relatório de resultados, segundo Barbosa e Silva (2010), são:
Objetivos e escopo da avaliação;
Uma breve descrição do método utilizado;
O número e perfil dos avaliadores e dos participantes;
As tarefas executadas;
Uma lista de problemas encontrados, indicando para cada problema: local onde
ocorreu; descrição e justificativa; discussão, indicando os fatores de usabilidade
prejudicados e sugestões de melhoria.
Aprovação do Documento
As funcionalidades descritas são homologadas pela <área solicitante>, abaixo
representada.
Cargo/Função Nome Assinatura
<<Usuário Gestor>> <<Nome>>
<<Usuário Gestor>> <<Nome>>
<<Lider do Projeto>> <<Nome>>
126
APÊNDICE I
TESTE DE USABILIDADE
Roteiro de Atividades
A tabela abaixo apresenta um roteiro de atividades e tarefas para aplicação do método
teste de usabilidade. Esse roteiro foi adaptado da obra de BARBOSA e SILVA (2010).
Atividade Tarefa
Preparação Definir tarefas para os participantes executarem
Definir o perfil dos participantes e recrutá-los
Preparar material para observar e registrar o uso
Executar um teste-piloto
Coleta de dados Observar e registrar a performance e opinião dos
participantes durante sessões de uso controladas através
de vídeo, áudio etc.
Aplicar questionário SUS
Interpretação Reunir, contabilizar e sumarizar os dados coletados dos
participantes Consolidação dos
resultados
Relato dos
Resultados
Relatar a performance e a opinião dos participantes
Lembrete: As atividades apresentadas aqui devem ser descritas com mais detalhes no
documento Caso de Teste (Apêndice F). O relato dos resultados dos testes também deve
ser incluído, de forma resumida, no documento de Homologação (Apêndice H).
SUS (System Usability Scale)
Introdução
O questionário de usabilidade SUS consiste em uma avaliação subjetiva simples
composta por dez questões que mostram uma visão geral do usuário em relação ao
sistema (SOUZA, 2015 apud BROOKE, 1996, p. 105).
O SUS é uma escala de Likert com cinco níveis (discordo plenamente, discordo, nem
concordo nem discordo, concordo, concordo plenamente). A interpretação das
respostas a escala SUS envolve o cálculo do “escore SUS”, que sintetiza em um valor
numérico a utilização geral do sistema a ser estudado, visto que os escores dos itens
individuais não significativos isoladamente. Para obter o escore SUS é necessário
calcular as contribuições de cada item do instrumento com valores de 0 a 4: para
questões ímpares a contribuição é calculada pela posição da escala menos 1; para
questões pares calcula-se 5 menos o valor da posição na escala. Multiplica-se a soma
dos valores por 2.5 e obtém-se o escore SUS, cuja amplitude total varia de 0 a 100%
(SOUZA, 2015 apud BROOKE, 1996, p. 105).
Questionário SUS - adaptado de Souza (2015)
Projeto: <Nome do Projeto> Data: <dd/mm/aaaa>
Participante: <Nome do Participante Sexo: <Descrição>
As afirmativas apresentadas abaixo se destinam a avaliar a usabilidade do sistema
<Nome do Sistema>. Analise cuidadosamente as afirmativas e, de acordo com usa
opinião, atribua um valor de 1 a 5 conforme escala abaixo:
1 Discordo plenamente
2 Discordo
3 Nem concordo nem discordo
4 Concordo
5 Concordo plenamente
128
1 Eu acho que gostaria de utilizar este sistema frequentemente. 1 2 3 4 5
2 Eu achei o sistema desnecessariamente complexo. 1 2 3 4 5
3 Eu achei o sistema fácil de usar. 1 2 3 4 5
4 Eu acho que precisaria do apoio de um suporte técnico para ser
possível usar este sistema.
1 2 3 4 5
5 Eu achei que as diversas funções neste sistema foram bem
integradas.
1 2 3 4 5
6 Eu achei que houve muita inconsistência neste sistema. 1 2 3 4 5
7 Eu imagino que a maioria das pessoas aprenderia a usar esse
sistema rapidamente.
1 2 3 4 5
8 Eu achei o sistema muito pesado para uso. 1 2 3 4 5
9 Eu me senti muito confiante usando esse sistema. 1 2 3 4 5
10 Eu precisei aprender uma série de coisas antes que eu pudesse
continuar a utilizar esse sistema.
1 2 3 4 5
Sugestões:
APÊNDICE J
DOCUMENTO DE FEEDBACK
Analista: <Nome> Data: <dd/mm/aaaa>
Aplicação: <Nome da Aplicação>
Introdução
Esse documento foi criado com o objetivo de descrever os métodos utilizados e
resultados obtidos durante a atividade Realizar Teste de Aceitação com os usuários.
Essa atividade consiste na aplicação de técnicas como entrevistas e questionários de
satisfação afim de averiguar a satisfação dos usuários após um tempo de utilização da
aplicação. Os testes de aceitação podem ser realizados após entrega de módulos ou
somente quando o produto estiver finalizado. Essa é uma decisão tomada pela equipe de
desenvolvimento juntamente com os clientes e/ou usuários.
Método
Descrever método utilizado (entrevista/ questionário) e condições de aplicação (local,
usuários, tarefas, contexto de uso etc.).
Resultados
Descrever os resultados obtidos de maneira clara e objetiva destacando problemas
encontrados que eventualmente poderão ser solucionados.
Aprovação do Documento
As funcionalidades descritas são homologadas pela <área solicitante>, abaixo
representada.
130
Cargo/Função Nome Assinatura
<<Usuário Gestor>> <<Nome>>
<<Usuário Gestor>> <<Nome>>
<<Lider do Projeto>> <<Nome>>
ANEXO A PDS SEGES-MT
Guia de Referência para o
Processo de Desenvolvimento de Software nas Instituições
Públicas do Estado de Mato Grosso
132
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................................. 134
1.1. HISTÓRICO............................................................................................................................. 134
1.2. A QUEM SE DESTINA ........................................................................................................... 134
1.3. LIMITAÇÕES .......................................................................................................................... 135
1.4. TERMOS UTILIZADOS NESTE DOCUMENTO ............................................................... 135
1.5. ENVOLVIDOS NA EXECUÇÃO DO PROCESSO ............................................................. 136
1.6. ESTRUTURA DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ............... 137
1.7. INFORMAÇÕES DE CARÁTER GERAL ........................................................................... 138
1.8. ORGANIZAÇÃO DO DOCUMENTO .................................................................................. 140
2. DIAGNÓSTICO ............................................................................................................................ 140
3. FASE CONCEPÇÃO.................................................................................................................... 141
3.1. OBJETIVO ............................................................................................................................... 141
3.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 141
3.3. ARTEFATOS DE ENTRADA ................................................................................................ 142
3.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 142
4. FASE PROJETO .......................................................................................................................... 150
4.1. OBJETIVO ............................................................................................................................... 150
4.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 151
4.3. ARTEFATOS DE ENTRADA ................................................................................................ 151
4.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 151
5. FASE IMPLEMENTAÇÃO......................................................................................................... 153
5.1. OBJETIVO ............................................................................................................................... 153
5.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 154
5.3. ARTEFATOS DE ENTRADA ................................................................................................ 154
5.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 154
6. FASE TESTE ................................................................................................................................ 155
6.1. OBJETIVO ............................................................................................................................... 155
6.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 155
6.3. ARTEFATOS DE ENTRADA ................................................................................................ 155
6.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 155
7. FASE HOMOLOGAÇÃO ............................................................................................................ 157
7.1. OBJETIVO ............................................................................................................................... 157
7.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 157
7.3. ARTEFATOS DE ENTRADA ................................................................................................ 157
7.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 157
8. FASE IMPLANTAÇÃO E ENCERRAMENTO ....................................................................... 158
8.1. OBJETIVO ............................................................................................................................... 158
8.2. PAPÉIS IDENTIFICADOS NESTA FASE ........................................................................... 158
8.3. ARTEFATOS DE ENTRADA ................................................................................................ 159
8.4. ATIVIDADES E ARTEFATOS PRODUZIDOS .................................................................. 159
134
1. INTRODUÇÃO
Este documento apresenta a descrição do Processo de Desenvolvimento de
Software que será adotado pelas instituições públicas do estado de Mato Grosso (PDS-
MT). O objetivo é facilitar o intercâmbio de informações e experiências adquiridas no
desenvolvimento e manutenção de produtos de software em todas as instituições
públicas do estado. Para atingir este fim foi considerado durante a elaboração deste
documento a disparidade existente entre as equipes de desenvolvimento de software de
cada instituição, por este motivo, as atividades e artefatos recomendados foram
definidas pelos representantes de todas as instituições como essenciais para desenvolver
um produto de software de qualidade que atenda às necessidades do solicitante e cuja
manutenção seja facilitada.
O processo apresenta as atividades que devem ser realizadas e os documentos
que serão produzidos agrupados em seis fases de desenvolvimento: concepção, projeto,
implementação, teste, homologação, implantação/entrega. Estas fases são antecedidas
pela atividade de diagnóstico que fornecem parâmetros importantes para o início do
processo.
1.1. Histórico
O Grupo Temático de Software foi constituído em 2009, com a finalidade de
desenvolver uma política de padronização dos processos de planejamento, aquisição,
desenvolvimento, avaliação e manutenção de software no Estado de Mato Grosso. Este
guia consiste no resultado do trabalho desenvolvido pelo grupo.
1.2. A quem se destina
A todas as instituições públicas do estado de Mato Grosso que desenvolvem ou
contratam empresas de desenvolvimento de software.
1.3. Limitações
Considerando que há uma grande disparidade em relação ao tamanho das
equipes de desenvolvimento de software no setor público estadual optou-se por propor
um processo enxuto que contemple atividades essenciais para o desenvolvimento de
software, por isto é possível que seja necessário incluir outras atividades e artefatos para
desenvolver projetos em algumas instituições.
1.4. Termos utilizados neste documento
Artefato: resultado que deve ser obtido após a execução de cada atividade.
Atividade: o que deve ser feito;
Funcionalidade: uma ação disponível para o usuário através do sistema e para a
qual ele pode visualizar um início e um fim;
Função: operação realizada pelo sistema;
Módulo: conjunto de funcionalidades do sistema agrupadas de acordo com
características similares. Exemplo: Módulo de Conta Corrente. Funcionalidades: Abrir
Conta, Sacar, Depositar, Consultar, Encerrar.
Participante: pessoa convidada pelo responsável para auxiliar na execução de
uma atividade ou designada como revisor;
Regra de negócio: normas, regulamentações, leis e restrições que o sistema deve
obedecer.
Requisito funcional: descrição de uma função que o cliente deseja que o
software permita executar;
Requisito não funcional: qualidade geral de um software como facilidade de
manutenção, usabilidade, desempenho, entre outras.
136
Responsável: pessoa responsável pela execução da atividade;
1.5. Envolvidos na execução do processo
Para que o processo seja realizado devemos envolver pessoas com
conhecimentos e responsabilidades bem definidas. A esta responsabilidade foi dado o
nome de papel. Uma pessoa pode assumir vários papéis durante o processo de
desenvolvimento de software.
Cliente: contratante ou representante legal que a represente. Responsável por
retirar dúvidas relacionadas ao negócio ou designar quem poderá fazê-lo; aprovar
artefatos e verificar se os requisitos estão sendo atendidos pela equipe desenvolvedora.
Líder de Projeto: planeja recursos, define prioridades, coordena ações com os
clientes, e mantêm o projeto com o foco nos objetivos planejados. O líder de projeto
também estabelece um conjunto de práticas para garantir a integridade e qualidade dos
artefatos do projeto.
Analista de requisitos: responsável pelo levantamento das necessidades,
requisitos funcionais e requisitos não funcionais, definindo o escopo do sistema através
de casos de uso. Deve ser um bom facilitador e possuir habilidade de comunicação. O
conhecimento do negócio é essencial e ele deve estar familiarizado com o modelo de
negócio. Deve estar preparado para entender as necessidades dos clientes, suas
estratégias e seus objetivos.
Analista de CM:
Projetista: define responsabilidades, operações, atributos e relacionamentos
entre classes, e determina como eles serão ajustados para o ambiente de implementação.
Além disso, é responsável também por um ou mais pacotes de projetos ou subsistemas.
Arquiteto de Software: lidera e coordena as atividades técnicas e a construção
de artefatos de todo o projeto. Ele estabelece a estrutura completa para cada arquitetura:
a decomposição da visão, os elementos agrupados e as interfaces entre os grupos.
Projetista do Banco de Dados: define tabelas, índices, visões, constraints,
triggers, procedimentos de armazenamento e parâmetros de bancos de dados específicos
construídos para armazenar, recuperar e apagar objetos persistentes.
Implementador: é responsável por desenvolver e testar componentes de acordo
com o padrão de projeto adotado.
Projetista de Testes: é responsável por planejar e implementar os procedimentos
de teste e gerar um sumário com os resultados dos testes.
Testador: executa os testes elaborados pelo projetista de teste e registra os erros
e melhorias identificados.
1.6. Estrutura do Processo de Desenvolvimento de Software
O processo de software descreve quais atividades são necessárias para produzir o
software. A Figura 1 fornece uma visão geral destas fases, papéis, atividades e artefatos.
As linhas mais espessas (na cor violeta) indicam os artefatos de uma fase que servem de
entrada para elaboração de artefatos das fases seguintes. As linhas mais finas (em verde)
indicam a seqüência, nem sempre obrigatória, para elaboração dos artefatos de cada
fase.
138
Figura 18: Fluxo do PDSMT
Através da figura é possível notar que a atividade de diagnóstico não compõe o
processo, mas é primordial para iniciá-lo. Estão representadas também as seis fases do
processo e os artefatos gerados em cada uma delas.
1.7. Informações de caráter geral
I. O acompanhamento e homologação com assinatura, quando assim
padronizado, dos artefatos normatizados neste guia é de responsabilidade do
analista responsável pelo projeto.
II. As atividades necessárias à evolução/criação de software só serão
autorizadas após 06 (seis) meses da disponibilização em produção da versão
atual.
III. Quanto às alterações no escopo ou funcionalidades do projeto sugeridas após
a Fase de Concepção:
a. As alterações no escopo do projeto que, em seu conjunto, sejam menor
ou igual 10% do escopo, poderão ser adicionadas na versão em
desenvolvimento, sem autorização prévia, sendo obrigatório à
atualização do cálculo FPA com as alterações demandadas;
b. Caso o percentual do conjunto de alterações exceda a 10% do escopo, a
relação de alterações deve ser encaminhada pelo Superior Imediato do
Líder de Projeto aos gestores (cliente) do projeto para avaliação,
validação e autorização das alterações.
IV. Quanto aos sistemas terceirizados, o líder de projeto tem como atribuição:
a. Acompanhar e monitorar o projeto;
b. Validar os artefatos com suporte dos responsáveis pela auditoria do
processo;
c. Efetuar contato com os usuários;
d. Formalizar decisões (atas e documentos pertinentes);
e. Manter a gerência direta ciente das atividades do desenvolvimento;
V. O acompanhamento do andamento das atividades deve ser realizado através
reuniões de acompanhamento do projeto com a elaboração de atas de reunião
e atualização do cronograma.
VI. Todos os projetos solicitados pelas instituições públicas do estado devem,
obrigatoriamente, apresentar o Documento de Visão.
VII. Todas as fases podem ser planejadas iterativamente, de forma a
particionar a entrega do produto em vários sub-produtos. Efetuar-se-á o
140
planejamento das iterações (repetição de atividades de cada fase), onde cada
iteração produz uma release (ou parte do sistema executável), sendo o
conjunto das releases a versão completa da aplicação;
VIII. Recomenda-se que os arquivos sejam inseridos em um repositório para o
controle de versionamento.
1.8. Organização do documento
A seção seguinte apresenta a atividade de diagnóstico que antecede a execução
do processo. A seção 3 apresenta as atividades e artefatos da fase de Concepção, a seção
4 descreve a fase de Projeto, e a seção 5 a fase de Implementação, os testes e a
homologação são descritos na seção 6 e 7 respectivamente, a seção 8 aborda a última
fase do desenvolvimento a implantação e encerramento. Encontram-se em anexo os
modelos (templates) dos artefatos que são produzidos em cada fase.
2. DIAGNÓSTICO
A atividade de diagnóstico antecede o início da execução do processo e tem
como finalidade analisar a viabilidade de execução do projeto e, por conseguinte, o
início do desenvolvimento do processo. Através desta atividade o cliente deve definir o
fluxo do negócio que será automatizado e os requisitos que o sistema deve conter. Estas
definições devem ser realizadas com o auxílio do analista de sistemas. Sendo assim,
dois documentos serão utilizados para iniciar o processo: o fluxo de negócio, cuja
elaboração é altamente recomendável e cujo modelo encontra-se definido no template
de Fluxo de Negócio e o documento de requisitos ilustrado através do template de
Requisitos, cuja elaboração é indispensável.
Outros pontos importantes são o registro em Ata, das visitas e reuniões com o
cliente e a catalogação dos termos identificados durante a atividade de levantamento de
requisitos e durante a execução do processo que devem ser registrados em um
Glossário. A finalidade do glossário é registrar os termos pertinentes a área de negócio e
seus significados facilitando o entendimento dos documentos elaborados e a
comunicação com o cliente.
3. FASE CONCEPÇÃO
A fase de concepção dá início ao desenvolvimento do software, por este motivo
as decisões sobre a viabilidade de desenvolvimento e a disponibilidade da equipe já
devem ter sido tomadas quando as atividades desta fase começarem. É evidente que
após a conclusão da fase de concepção o projeto pode ser considerado inviável, mas
espera-se que a inviabilidade de uma grande parte dos projetos possa ser identificada
ainda na atividade de diagnóstico.
Durante a Fase de Concepção, pode ocorrer necessidade de modelar
Funcionalidades/Operações não capturadas no Documento de Visão, em função deste
ser elaborado em contexto de alto nível de abstração. Caso ocorra, o Documento de
Visão deverá ser atualizado somente em suas Funcionalidades/Operações, não sendo
necessária nova assinatura dos envolvidos. O Histórico do Documento de Visão deve
ser atualizado e a versão anterior que foi assinada pelos envolvidos deve ser mantida em
arquivo.
3.1. Objetivo
O objetivo da fase de Concepção é o estabelecimento de um acordo formal, entre
a equipe de desenvolvimento e o solicitante sobre o produto que será desenvolvido. Para
que este acordo seja firmado é necessário que o cliente aprove o documento de visão e a
estimativa de Pontos por Função realizada.
3.2. Papéis identificados nesta fase
Participam desta fase o Líder de Projeto, o Analista de TI – Requisitos e o
Cliente.
Para cada atividade descrita será identificado qual papel será responsável (R) e
participante (P) pela execução da atividade e pelo artefato gerado.
142
3.3. Artefatos de entrada
Os seguintes artefatos devem ser produzidos para que esta fase tenha início:
Fluxo de Negócio e Documento de Requisitos.
3.4. Atividades e Artefatos produzidos
Esta seção lista todas as atividades que devem ser executadas para concluir a
fase de concepção do projeto e os artefatos (documentos) resultantes de cada uma das
atividades.
Atividade 1 Elaborar Documento de Visão
Papéis: Líder de Projeto (R); Cliente (P).
O Documento de Visão é um artefato fundamental na fase de concepção,
através deste documento é possível firmar um acordo com o cliente de quais os
principais requisitos do sistema, quais funcionalidades serão abordadas e quais
as expectativas do cliente sobre a forma que o sistema auxiliará em suas
necessidades e quais leis e normas o sistema deve obedecer.
As consequências de um descuido na elaboração deste documento podem
gerar um desgaste entre a equipe de desenvolvimento e o cliente e, se não for
corrigido a tempo, resultará na elaboração de uma ferramenta deficiente que
não atende as necessidades do solicitante.
Passo 1 Realize entrevistas com o cliente e visitas ao ambiente onde o
software será implantado registrando-as na Ata de Reunião;
Passo 2 Identifique as principais funcionalidades do sistema (escopo),
as funcionalidades que não serão contempladas (não-escopo)
e os envolvidos com o desenvolvimento do sistema;
Passo 3 Sintetize os resultados obtidos através do Documento de
Visão;
Passo 4 Obtenha a aprovação do cliente no Documento de Visão e
arquive em uma pasta de documentos do sistema.
Artefato 1 Documento de Visão.
Atividade 2 Criar repositório para o projeto
Papéis: Analista de CM (R), Líder de Projeto (P)
O repositório tem como finalidade armazenar e versionar os artefatos
gerados para o projeto. É interessante que seja utilizada uma ferramenta que auxilie
no controle de acesso e versionamento dos artefatos (Ex: SVN, ClearCase).
Os artefatos deverão ser armazenados seguindo a tabela abaixo:
Artefato Diretório
Documento de Visão Documentacao\Requisitos\Levantamento
Cronograma Documentacao\Gerencia de Projetos\Cronograma
Atas Documentação\Gerência de Projetos\Atas
Documento de Requisitos Documentação\Requisitos\Levantamento
Glossário Documentacao\Requisitos\Levantamento
Caso de Uso Documentacao\Requisitos\Casos de Uso
Protótipos Documentação\Requisitos\Protótipos
Planilha FPA Documentacao\Gerencia de Projetos
Arquivo - Modelagem de Classes e
Objetos
Documentacao\Modelos
144
Arquivo - Modelagem de Dados Documentacao\Modelos
Documento de Especificação de
Infra-estrutura
Documentacao\Analise e Design
Plano de Teste, Procedimento de
Teste e Casos de Teste
Documentacao\Testes
Documento de Homologação Documentacao\Gerencia de Projetos
Ajuda on-line Implementacao\web\ajuda
Documento de Entrega do Projeto Documentacao\Gerencia de Projetos
Documentos inerentes a modelagem
de negócio, tendo como origem o
cliente e/ou unidade fazendária
(POP, Matriz Insumo-Produto,
Normas, Procedimentos...)
Documentacao\Modelagem de Negocio
Passo 5 Solicite ao Analista de CM que crie um repositório para o
projeto.
Atividade 3 Complementar Documento de Requisitos
Papéis: Líder de Projeto (R); Cliente (P)
É possível que o Documento de Requisitos elaborado pelo cliente não
abranja todas as necessidades que ele deseja que o sistema atenda, por este
motivo é importante especificar melhor estes requisitos e organizá-los.
O Documento de Requisitos será utilizado para elaborar o cronograma da
fase de concepção, o diagrama de caso de uso e a especificação de caso de uso,
portanto ele é um dos alicerces da ferramenta e deve ser elaborado com calma
e atenção.
Passo 6 Atualize o Documento de Requisitos agrupando os requisitos
em termos de funcionalidades do sistema e estas
funcionalidades em módulos;
Passo 7 Identifique no Documento de Visão, durante as visitas e
entrevistas com usuários e gestores, através da consulta a leis,
regulamentações, políticas e padrões as regras de negócio e
requisitos do sistema e registrá-los no Documento de
Requisitos.
Passo 8 Providencie o arquivamento físico do Documento de
Requisitos do projeto assinado pelo cliente e o
armazenamento do arquivo no repositório do projeto.
Artefato 2 Documento de Requisitos.
Atividade 4 Elaborar cronograma
Papéis: Líder de Projeto (R); Cliente (P)
A elaboração do cronograma é importante para que a equipe de
desenvolvimento estime o tempo necessário para concluir o levantamento,
para que o cliente possa acompanhar as atividades desta fase e o tempo
requerido para conclusão de cada uma delas.
Passo 9 Com base no Documento de Visão e na Complementação do
Documento de Requisitos estime o tempo necessário para:
Elaborar o Diagrama e a Especificação de Caso de Uso, o
Protótipo e a Análise de Pontos por Função.
Passo 10 Efetue a validação do cronograma através de registro em ata
de reunião.
Passo 11 Providencie o arquivamento do Cronograma no repositório
do projeto.
Artefato 3 Cronograma.
Atividade 5 Elaborar Glossário
Papéis: Analista de TI - Requisitos (R) Cliente (P)
146
Passo 12 Identifique os termos característicos da área de negócio do
cliente e especifique no Glossário;
DICA 1: Este artefato deve ser atualizado durante o
desenvolvimento do projeto.
Passo 13 Providencie o arquivamento do Glossário no repositório do
projeto.
Artefato 4 Glossário.
Atividade 6 Elaborar Diagrama de Caso de Uso
Papéis: Analista de TI - Requisitos (R) Cliente (P)
Não há uma ordem de execução obrigatória entre as atividades 5 e 6.
Elas podem ser realizadas em paralelo, contudo, a realização de uma não
substitui a necessidade de execução da outra.
O Diagrama de Caso de Uso é importante por oferecer uma visão geral
do sistema e dos usuários (atores) que irão interagir com ele. Ao ver o
diagrama o cliente deve ter uma idéia das principais funcionalidades que o
sistema deve possuir.
Passo 14 Considerando a Especificação do Documento de Requisitos e
o Documento de Visão desenhe o Diagrama de Caso de Uso.
DICA 2: A Elaboração do Diagrama de Caso de
Uso e a Especificação podem ser realizadas em
paralelo com a elaboração do protótipo, uma vez
que, a visualização das telas facilita a escrita, e a
escrita, por sua vez, facilita o desenho das telas;
Passo 15 Providenciar assinatura do Líder de Projeto nos Diagramas
de Caso de Uso.
Passo 16 Providencie o arquivamento físico do Diagrama de Caso de
Uso assinado pelo líder de projeto e o armazenamento do
arquivo no repositório do projeto.
Artefato 5 Diagrama de Caso de Uso.
Atividade 7 Especificação do Caso de Uso
Papéis: Analista de TI - Requisitos (R) Cliente(P)
A Especificação de Caso de Uso detalha e documenta quais atores
podem realizar uma determinada funcionalidade, quais passos devem ser
seguidos para execução desta funcionalidade e o feedback que o usuário deve
receber no momento que a tarefa for concluída ou quando houver alguma
exceção. Por estes motivos este documento é fundamental para execução da
atividade de prototipação e para que os desenvolvedores identifiquem as
funcionalidades do sistema.
DICA 3: A especificação de casos de uso pode ser
planejada em iterações, sempre priorizando os casos
de uso mais complexos. Ou seja, o planejamento da
especificação do conjunto de casos de uso do projeto
pode ser dividido em sub-conjuntos ou módulos,
onde as atividades orientadas pelo sub-conjunto já
especificado poderão ser inicializadas, enquanto o
próximo sub-conjunto de casos de uso é
especificado;
DICA 4: Os casos de uso que integram com outros
sistemas devem possuir o nome do sistema com o
qual mantém integração. Nos “Pontos de Inclusão”
e/ou “Pontos de Extensão” do caso de uso, deve ser
148
reportado o caso de uso e o nome do sistema ao qual
pertence este caso de uso [p. ex. Caso de Uso:
Consultas de Histórico de Contribuinte (Sistema
Cadastro de Contribuintes), sendo também
necessário reportar no item “Requisitos Não
Funcionais” do caso de uso, as integrações mantidas
por este caso de uso.
Passo 17 Considerando o Diagrama de Caso de Uso e a Especificação
dos Requisitos especifique, conforme o template, cada caso
de uso identificado.
Passo 18 Obtenha a aprovação das Especificações de Caso de Uso
através da assinatura do Líder de Projeto e do Cliente.
Passo 19 Providencie o arquivamento físico das Especificações de
Caso de Uso assinadas e o armazenamento do arquivo no
repositório do projeto.
Artefato 6 Especificação do Caso de Uso.
Atividade 8 Elaborar Protótipo
Papéis: Analista de TI - Requisitos (R) Cliente(P)
O protótipo é muito importante para que o analista demonstre ao cliente
como as funcionalidades foram organizadas no menu e o desenho das
interfaces através da qual o cliente terá acesso a elas.
Além disso, o protótipo permite que o cliente verifique se todas as
funcionalidades solicitadas no Documento de Visão foram contempladas.
O protótipo também pode ser útil durante o cálculo dos pontos por
função e principalmente para os desenvolvedores que poderão, através da
especificação de casos de uso e da consulta ao protótipo, entender mais
rapidamente as características do sistema e as regras de negócio.
Passo 20 Desenhe as interfaces do sistema com base nas descrições dos
casos de uso.
DICA 5: O protótipo pode ser apresentado em
conjunto com os casos de uso para aprovação das
funcionalidades solicitadas pelo cliente.
Passo 21 Providencie o arquivamento dos Protótipos no repositório do
projeto.
Artefato 7 Protótipo elaborado.
Atividade 9 Calcular Pontos por Função
Papéis: Analista de TI - Requisitos (R) Cliente (P)
A principal finalidade da Análise de Pontos por Função é definir o custo,
em horas, do desenvolvimento de cada módulo. Com base nesta análise é
possível complementar o cronograma elaborado para fase inicial para que ele
abranja as fases posteriores estimando assim, o tempo total de
desenvolvimento do sistema. A partir desta análise é possível também, que o
cliente e a equipe de desenvolvimento analisem também a viabilidade da
implementação do sistema.
150
Passo 22 Consulte o Diagrama, a Especificação de Caso de Uso e o
Protótipo para elaborar o documento de entrada para Análise
de Pontos por Função;
Passo 23 Aplique a APF e registre os resultados;
Passo 24 Providencie o arquivamento físico do Documento de Análise
de Pontos por Função no repositório do projeto.
Artefato 8 Documento de Análise de Pontos por Função.
Atividade 10 Concluir a Fase de Concepção
Papéis: Líder de Projeto (R), Cliente (R).
Durante a fase de concepção foram realizados estudos mais abrangentes
sobre o projeto e como conseqüência dois caminhos são possíveis: a
interrupção ou o início da fase de projeto. Esta decisão deve ser tomada pelo
Cliente em conjunto com o Líder de Projeto.
Como forma de assinalar que esta fase já produziu os artefatos esperados
e necessários para dar início à fase de Projeto, o Documento de visão deve ter
sido aprovado pelo cliente e o Documento de Análise de Pontos por Função
deve estar disponível para uso.
4. FASE PROJETO
4.1. Objetivo
O objetivo da fase de Projeto é apresentar a estimativa de prazos e custos para
que seja aprovado pelo Cliente e, após a aprovação, definir os alicerces para construção
do sistema, tais como, arquitetura, modelo de dados e outros.
4.2. Papéis identificados nesta fase
Participam desta fase o Projetista (R), Arquiteto de Software (R), Projetista de
Banco de dados (R), Analista de Requisitos (P), Líder de Projeto (P).
4.3. Artefatos de entrada
Os seguintes artefatos devem estar disponíveis para que esta fase tenha início:
Documento de Visão, Glossário, Especificação de Casos de Uso e Cronograma de
Atividades.
4.4. Atividades e Artefatos produzidos
Atividade 11 Apresentar prazos e custos
Papéis: Líder de Projeto (R), Cliente (R).
Esta atividade é fundamental para continuação do projeto, uma vez que
sem a aquiescência do cliente em relação a prazos e custos o software não
deve ser desenvolvido.
Passo 25 Atualize o cronograma;
Passo 26 Apresente ao cliente o Cronograma e o resultado da Análise
de Pontos por Função e receba aprovação para dar
continuidade às atividades;
Passo 27 Providencie o arquivamento físico de todas as abas da
planilha de pontos por função e do cronograma aprovado pelo
cliente.
Artefato 9 Versão atualizada do cronograma aprovada pelo cliente.
Atividade 12 Definir Arquitetura
Papéis: Arquiteto de Software (R), Líder de Projeto (P).
152
Passo 28 Defina a Arquitetura de Software utilizando o template de
arquitetura em anexo.
Passo 29 Providencie o arquivamento do documento de Arquitetura
de Software no repositório do projeto.
Artefato 10 Arquitetura.
Atividade 13 Elaborar Modelo de Dados
Papéis: Projetista de BD (R), Líder de Projeto (P).
Passo 30 Elabore o Modelo de Dados seguindo orientações do Guia de
Referência de Criação e Manutenção de Modelo de Dados.
Passo 31 Providencie o arquivamento do Modelo de Dados no
repositório do projeto.
Artefato 11 Modelo de Dados.
Atividade 14 Realizar Casos de Uso
Papéis: Projetista (R), Líder de Projeto (P).
Esta atividade consiste em representar os fluxos e regras documentados
no caso de uso através de outros diagramas da UML (Unified Modeling
Language). É obrigatório para: projetos de evolução de versão que possuem
modelagem de classes e objetos, projetos novos e projetos terceirizados
(desenvolvimento externo), sendo para este último, obrigatória a realização
apenas para casos de uso de maior complexidade.
Passo 32 Elabore o Diagrama de Classe.
Passo 33 Elabore diagramas complementares caso necessário expressar
visualmente algum contexto de sistema onde os Diagramas de
Classe são avaliados como insuficientes, utilizar diagrama da
UML compatível com a necessidade.
Passo 34 Providencie o arquivamento dos Diagramas elaborados no
repositório do projeto.
Artefato 12 Diagrama de Classe e outros.
Atividade 15 Definir Infraestrutura
Papéis: Projetista (R), Líder de Projeto (P).
Passo 35 Elaborar Documento de Especificação de Infraestrutura,
seguindo template de infraestrutura, capturando necessidades
do projeto que dever ser atendidas pelo Sistema Gerenciador
de Banco de Dados, Servidores de Aplicação e Sistemas
Gerenciadores de Redes.
Artefato 13 Documento de Infraestrutura
5. FASE IMPLEMENTAÇÃO
5.1. Objetivo
O objetivo da fase de Implementação é elaborar o código fonte da aplicação e
realizar os testes iniciais para certificar-se que o sistema ou módulo desenvolvido pode
passar pela fase de testes para os ajustes finais.
154
5.2. Papéis identificados nesta fase
Participam desta fase o Implementador (R), Projetista (P), Líder de Projeto (P).
5.3. Artefatos de entrada
Os seguintes artefatos devem estar disponíveis para que esta fase tenha início:
Especificação de Casos de Uso, Realização do Caso de Uso e Protótipo.
5.4. Atividades e Artefatos produzidos
Atividade 16 Desenvolver código fonte
Papéis: Implementador (R), Projetista (P).
Passo 36 Construa o código-fonte considerando as recomendações do
Documento de Arquitetura, a Modelagem de Dados e o
Documento de Requisitos;
Passo 37 Execute o Teste Unitário Local, em ambiente de
desenvolvimento, nas funcionalidades da versão, verificando
se as regras de negócio descritas nos artefatos (Casos de Uso
e Diagramas) estão sendo plenamente atendidas pelas
funcionalidades.
Passo 38 Solicite à equipe responsável pelo Banco de Dados a
criação/atualização do banco de dados, necessário para o
funcionamento do sistema em ambiente de teste.
Artefato 14 Código fonte desenvolvido.
Atividade 17 Disponibilizar em ambiente de teste
Papéis: Implementador (R), Líder de Projeto (P).
Passo 39 Informe ao Líder de Projeto, que a aplicação está disponível
em ambiente de teste para ser operacionalizada e testada.
Passo 40 Execute os Testes de Integração (Suíte de Teste) das
funcionalidades, operacionalizando outras integrações, caso
exista.
Artefato 15 Aplicação disponível para teste.
6. FASE TESTE
6.1. Objetivo
A fase de teste tem a finalidade de assegurar que o sistema será disponibilizado
ao usuário final com a menor chance possível de apresentar um comportamento
inesperado.
6.2. Papéis identificados nesta fase
Participam desta fase o Projetista de Teste (R), Testador (R), Analista de
Requisitos (P).
6.3. Artefatos de entrada
Os seguintes artefatos devem estar disponíveis para que esta fase tenha início:
Especificação de Casos de Uso, Aplicação disponível em ambiente de teste.
6.4. Atividades e Artefatos produzidos
Atividade 18 Planejar o Teste
Papéis: Projetista de Teste (R), Analista de Requisitos (P).
156
A concepção dos Planos e Casos de Teste pode ser iniciada após a
modelagem de casos de uso, ocorrendo paralelamente com as demais
atividades.
Passo 41 Elabore o Plano de Teste e os Casos de Teste para requisitos
funcionais e de interface, com objetivo de orientar o Analista
responsável na execução de Testes Funcionais e de Interface,
em grau exaustivo na aplicação, verificando o descrito
abaixo:
a. O correto funcionamento do sistema, de acordo com todos os
artefatos referenciados na construção;
b. O correto cumprimento das padronizações de telas, relatórios,
etc.;
c. A performance do sistema na operacionalização de
funcionalidades complexas.
Artefato 16 Plano de Teste.
Artefato 17 Casos de Teste.
Atividade 19 Executar e disponibilizar correções
Papéis: Testador (R), Projetista de Teste (P).
Passo 42 Realize todos os testes prescritos nos Casos de Teste e
Registre os Resultados obtidos;
Passo 43 Encaminhe ao Líder de Projeto as melhorias e ajustes para
que sejam implementadas e disponibilizadas pelo
Implementador para novos testes.
Artefato 18 Resultados dos Testes.
É importante notar que após a implementação dos ajustes e melhorias
novos testes devem ser executados para certificar que as correções não
inseriram novos erros. Após estes novos testes o Testador deve encaminhar os
resultados para o Líder de Projeto que, caso considere o sistema em condições
de uso, deve solicitar ao Implementador que disponibilize a aplicação no
ambiente de homologação.
7. FASE HOMOLOGAÇÃO
7.1. Objetivo
A finalidade desta fase consiste em certificar que o sistema está pronto para ser
utilizado pelo usuário final.
7.2. Papéis identificados nesta fase
Participam desta fase o Líder de Projeto (R), Analista de Requisitos (P), Cliente
(P).
7.3. Artefatos de entrada
Para que esta fase tenha início é necessário que a aplicação esteja disponível em
ambiente de homologação.
7.4. Atividades e Artefatos produzidos
Atividade 20 Treinar usuários finais
Papéis: Analista de Requisitos (R), Cliente (P).
Passo 44 Planejar o Treinamento e elaborar cronograma;
Passo 45 Realizar o treinamento;
Atividade 21 Homologar a aplicação
Papéis: Líder de Projeto (R), Cliente (R).
158
Passo 46 O Líder de Projeto deve preencher o Documento de
Homologação do Sistema, que deve ser assinado pelo Cliente,
armazenado no arquivo físico e arquivado no repositório do
projeto.
Passo 47 Caso existam, o Líder de Projeto deve acionar atividades de
ajuste, como correção de erros, melhoria no desempenho e
usabilidade. E, após as correções, efetuar a homologação dos
itens afetados pela atualização/correção em conjunto com o
Cliente.
Passo 48 O Líder de Projeto deve providenciar confecção da
documentação definida no Documento de Visão - Manual do
Usuário do Sistema, Help Online, Manual de Instalação e
Configuração (artefatos obrigatórios para desenvolvimento
terceirizado de sistemas).
Artefato 19 Documento de Homologação
Artefato 20 Manual do Usuário
8. FASE IMPLANTAÇÃO E ENCERRAMENTO
8.1. Objetivo
Esta fase tem por objetivo marcar o encerramento de um projeto ou iteração de
desenvolvimento.
8.2. Papéis identificados nesta fase
Participam desta fase o Líder de Projeto (R), Analista de Requisitos (P),
Superior imediato do líder de projeto (P), Cliente (P).
8.3. Artefatos de entrada
Para que esta fase tenha início é necessário que a aplicação esteja homologada
pelo cliente.
8.4. Atividades e Artefatos produzidos
Atividade 22 Implantar o Sistema
Papéis: Líder de Projeto (R), Implementador (R).
Passo 49 Prepare ambiente de produção;
Passo 50 Disponibilize o sistema no ambiente de produção;
Atividade 23 Formalizar o aceite
Papéis: Líder de Projeto (R), Superior imediato do líder de projeto (P),
Cliente (P).
Passo 51 Confeccione o Termo de Entrega
Passo 52 Providencie a assinatura do termo pelo Cliente, pelo Líder de
Projeto e pelo Superior imediato do líder de projeto e arquive
na pasta de documentos do sistema.
Artefato 21 Termo de Aceite.
