LUÃ MARCELO MURIANA - IC

UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO EM GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
QualiCES
UM METÓDO PARA GARANTIA DA
QUALIDADE DE SOFTWARE NA FASE DE
ENGENHARIA DE REQUISITOS
LUÃ MARCELO MURIANA
CUIABÁ – MT
2011
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO EM GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO
QualiCES
UM METÓDO PARA GARANTIA DA
QUALIDADE DE SOFTWARE NA FASE DE
ENGENHARIA DE REQUISITOS
LUÃ MARCELO MURIANA
Orientador: Prof. Dr. Cristiano Maciel
Co-orientadora: Prof.ª Ms. Fabiana Freitas Mendes
Monografia apresentada ao Curso de Ciência da
Computação da Universidade Federal de Mato
Grosso, para obtenção do Título de Bacharel em
Ciência da Computação.
CUIABÁ – MT
2011
DEDICATÓRIA
À minha mãe e ao meu pai pelo amor incondicional, pela vida e por terem me dado à
oportunidade de me tornar homem.
AGRADECIMENTOS
Chegar a um momento como esse não é nada fácil. Chegar a um momento como esse
com toda certeza é um sonho que muitos tem, porém poucos tem o privilégio de
alcançá-lo. Eu estou vivendo esse privilégio! Chegar ao tão esperado momento da
conclusão de um curso de nível superior foi possível graças a diversas pessoas que
acreditaram em mim, as quais me incentivaram em momentos de dificuldades e me
apoiaram nas decisões que tomei. No meu caso, estar vivenciando esse momento vai
muito além do simples fato dessas pessoas terem me apoiado de uma forma ou de outra
durante os meus estudos. Hoje, ao concluir mais essa fase e subir mais um degrau da
minha vida, é impossível não voltar no tempo e perceber que tudo poderia ter sido
diferente, e que tudo poderia nem ter sido.
O ano era 1993... uma criança normal que brincava, fazia suas mulecagens e
tinha fome de aprender foi diagnosticado com Leucemia Mieloide Aguda. Uma simples
criança com uma doença destruidora dentro de si. Desespero! Angustia! Medo!
O ano era 1994... no dia 27 de janeiro, ao terminar o transplante o médico se
virou à minha mãe e disse: “Parabéns Mãe, seu filho acaba de nascer novamente!”. A
batalha foi árdua e exaustiva, mas a vontade de ver um filho vivo por muitos mais anos
perto de si, um sobrinho que pudesse ter vontade de aprender novamente, um neto que
tivesse com saúde para ser mimado, um afilhado que pudesse desfrutar do prazer de
viver e um primo que pudesse colaborar nas bagunças e nas artes de crianças, fez que
com todos se unissem nessa guerra contra as “células do mal”. Saúde! Alegria! Sonhos!
Vida! De volta para o futuro...
Hoje ao agradecer, quero dizer “meu muito obrigado!” a cada um que me
permitiu VIVER para que assim, eu pudesse ter o privilégio de chegar a esse momento
da minha vida.
Primeiramente, quero agradecer a eles que são a razão desse momento que estou
vivendo: minha mãe, Ione, e meu pai, Muriana. Quero agradecer pelo amor
incondicional que os fez buscarem ajuda, e nunca desistirem da vida de um filho mesmo
escutando diversas sentenças de morte. Quero agradecer por terem sido fortes
aguentando as dificuldades e sacrifícios necessários. Por acreditarem no conhecimento e
assim, por terem me proporcionado uma oportunidade de estudo com qualidade também
quero agradecer. E por fim, quero agradecer pelos momentos de conforto nos momentos
de desespero, pelas palavras amigas e de incentivo, e principalmente, por acreditarem
em mim. Mãe, Pai, pela vida e pela oportunidade de estudo e de me tornar homem,
MUITO OBRIGADO!
Uma outra pessoa especial que não posso deixar de agradecer é minha irmã,
Tayara. Desde pequena, quando era uma simples criança de 2 anos, já se mostrava ser
uma pessoa de coração grande. Sem ao menos entender o que estava acontecendo, foi
compreensível e aceitou a ausência de nossos pais para que eles pudessem cuidar de
mim. Ainda preciso agradecer a ela por morar comigo e por aturar o meu jeito de ser.
Tah, MUITO OBRIGADO!
Aos meus avós, Fernando e Vilaní, João e Nena por terem me agradado sempre
e por terem cuidado de mim quando necessário. A vó Vilaní quero agradecer pelas
horas de dedicação ao meu tratamento da leucemia, e a toda preocupação, cuidados e
dedicação nesses anos que moro perto dela aqui em Cuiabá. A vó Nena quero agradecer
por ter ajudado no cuidado da minha irmã e dos meus primos quando morava em São
Paulo para tratamento do câncer. A vocês, avós, MUITO OBRIGADO!
A minha tia Ilca quero dizer o meu obrigado por toda dedicação durante o meu
tratamento, pelo conforto dado aos meus pais quando necessário e por não ter medido
esforços para que o seu sobrinho sobrevivesse. Quero agradecer ainda pelo amizade que
se formou nesses anos e por todas palavras amigas sempre que necessário. Tia, MUITO
OBRIGADO!
Tia Ivete, a você agradeço pelo esforço de agilizar as coisas necessárias, aqui em
Cuiabá, para que eu pudesse ir fazer o meu tratamento em São Paulo. Agradeço ainda
por tudo que fez por mim nesses últimos anos dos meus estudos: ir na escola buscar
meu boletim, me buscar e levar em algum lugar quando necessário, e por todos os
momentos que juntos passamos nesses anos. Com toda certeza, isso foi fundamental
para essa vitória. Tia, MUITO OBRIGADO!
À minha tia Eliana quero agradecer, principalmente, por ter cuidado da minha
irmã para que minha mãe e meu pai pudessem estar perto de mim durante a “batalha
contra o mal”. E quero agradecer por muitas vezes ter deixado seus filhos e marido para
ir até mim para ajudar nos cuidados necessários. Tia, MUITO OBRIGADO!
Minha Madrinha também merece todo o meu agradecimento. Muitas vezes
ajudou nos cuidados com minha irmã e também, muitas vezes deixou casa, filhos e
marido para ir a São Paulo cuidar de mim. Madrinha, MUITO OBRIGADO!
Ainda tem meus primos, os quais também compreenderam a situação e
aceitaram a ausência de suas mães para que elas pudessem viajar e cuidar de mim. Além
disso, quero agradecer aos que eu morei junto aqui em Cuaibá. A vocês, MUITO
OBRIGADO!
E por fim, agradeço a todos os outros familiares que direta ou indiretamente
ajudaram em todo esse processo, tanto do meu tratamento quanto dos meus estudos.
MUITO OBRIGADO! Embora o apoio familiar seja muito importante, os cuidado
médicos foram de extrema importância. Quero agradecer a todos os médicos que
cuidaram de mim e ousaram na minha cura, permitindo assim, que eu vivesse e hoje,
escrevesse essas linhas de agradecimento. A vocês, MUITO OBRIGADO!
Mesmo sendo tão pequeno e não entendo as consequências e os porquês de tudo
que eu fazia em SP durante todo o tratamento que eu fui submetido, tudo parecia uma
grande festa: correr pelo hospital, brincar na sala de brinquedos, andar de metrô e de
trem, e muitas viagens. E assim, nas rotinas que eu estava submetido, diversas pessoas
entraram em minha vida e, mesmo hoje não estando perto de mim, com toda certeza
serão lembradas e agradecidas eternamente. Cleide, Eurides, amigos que doaram
plaquetas, sangue, rezaram por mim, e de uma forma ou de outra colaboraram com o
meu tratamento, MUITO OBRIGADO!
Após todos os procedimentos necessários e com a cura alcançada, a fome pela
aprendizagem voltou. Diversos anos de estudos e aprendizados, ensino fundamental,
ensino médio e ensino superior. Curso de inglês, aulas de música e tudo mais que uma
pessoa normal pode fazer. A todos os professores que passaram por minha vida,
compartilhando conhecimento, me ensinando a pegar em um lápis, a ler, a escrever e a
somar, MUITO OBRIGADO!
Durante os últimos 5 anos que se passaram, quero agradecer a todos os
professores do curso de Ciência da Computação por todo o conhecimento transmitido,
e, principalmente, por ajudarem na minha preparação para vida. A vocês que estiveram
dispostos a tirar dúvidas e ensinar, que compreenderam muitas vezes a situação de nós
alunos, MUITO OBRIGADO!
Em especial quero agradecer ao professor Cristiano por ter me mostrado que
computação não é somente linhas de código, e por ter despertado em mim uma
esperança nos estudos que não havia mais. Quero te agradecer ainda, professor, pelas
palavras de incentivo quando desanimei durante o meu TCC, pelos puxões de orelha
quando necessário, e principalmente, por ter, brilhantemente, me orientado na
monografia. A você, Prof. Cristiano, MUITO OBRIGADO!
A professora Fabiana, quero agradecer em especial também por toda dedicação
na correção dos meus trabalhos, pela brilhante co-orientação do meu TCC, e por não ter
medido esforços para me ajudar o meu TCC ser 10. Fabiana, MUITO OBRIGADO!
Nesses longos anos de caminhada em busca desse momento, diversas pessoas
me deixaram feliz pelo simples fato de terem cruzado o meu caminho. Algumas
percorrem ao meu lado, vendo muitas luas passarem, mas outras apenas vi entre um
passo e outro. E é a essas que estão sempre ao meu lado acompanhando minhas vitórias
e também minhas dificuldades, que agora eu quero agradecer, como forma de
demonstrar meu carinho, minha ternura e minha amizade.
Amigos...
A Fernanda, minha irmã de coração, agradeço pela amizade durantes esses 17
anos que nos conhecemos, pelas palavras amigas, por compartilhar meus segredos,
minhas preocupações, medo e angustias, e por todos os momentos que juntos passamos.
Fefa, MUITO OBRIGADO!
Nara, Nancy e Lidiane, as minhas meninas, as quais me ensinaram o significado
da palavra HUMILDADE. A vocês minhas amigas, por terem aturado um “nerd cheio
de espinhas”, um aluno que tinha o caderno exemplo da sala, e que duvida da
capacidade de vocês; por terem alegrado minha vida nesses últimos anos e fazerem toda
diferença, MUITO OBRIGADO!
Brunno, meu irmão, aquele que me ouve, me entende, briga comigo, me dá
conselhos, apronta e festa comigo, MUITO OBRIGADO!
A você Marih, devo um agradecimento muito especial também. Nesses últimos
anos tem sido minha comparsa de faculdade, dividindo problemas, angustias,
dificuldades, alegrias e tristezas; dividindo momentos de estudos e desespero para com
os estudos, e também, dividindo momentos de “funk deluxe”. Maaaaaarih, MUITO
OBRIGADO!
E a todos os outros amigos que estão sempre somando “and shinying” comigo,
MUITO OBRIGADO!
E por fim, quero agradecer a Deus por terem colocado as pessoas certas em meu
caminho: os médicos que foram responsáveis pelo meu tratamento; minha família que
participou junto na batalha da vida contra o câncer; os meus pais e irmã que me
proporcionaram a oportunidade de estudar e de viver; os professores que
compartilharam seus conhecimentos para comigo; e os meus bons amigos que estão
sempre ao meu lado. Deus, MUITO OBRIGADO!
Assim, hoje quero compartilhar mais essa vitória com cada um de vocês, e
reconhecer que isso se deve muito a vocês. Por isso, a todos eu digo: MUITO
OBRIGADO!
“Quem luta celebra vitória!”
Irª. Lucinda Facchini
SUMÁRIO
LISTA DE ABREVIAÇÕES.......................................................................................................................7
LISTA DE FIGURAS..................................................................................................................................8
LISTA DE TABELAS.................................................................................................................................9
RESUMO....................................................................................................................................................16
ABSTRACT................................................................................................................................................17
1
2
INTRODUÇÃO .............................................................................................................................. 18
1.1
Justificativa .............................................................................................................................. 18
1.2
Objetivos .................................................................................................................................. 19
1.2.1
Objetivo geral .................................................................................................................. 19
1.2.2
Objetivos específicos ....................................................................................................... 20
1.3
Metodologia ............................................................................................................................. 20
1.4
Organização do trabalho ........................................................................................................... 21
ENGENHARIA DE SOFTWARE ................................................................................................ 22
2.1
2.1.1
Requisitos ........................................................................................................................ 24
2.1.2
Casos de uso .................................................................................................................... 25
2.1.3
Protótipos......................................................................................................................... 26
2.2
3
4
Validação de software .............................................................................................................. 26
2.2.1
Inspeção de Software ....................................................................................................... 29
2.2.2
Teste de Software ............................................................................................................ 28
2.2.3
Falhas x Erros x Defeitos ................................................................................................. 30
QUALIDADE DE SOFTWARE ................................................................................................... 33
3.1
Qualidade de Requisitos ........................................................................................................... 34
3.2
Qualidade de Casos de Uso ...................................................................................................... 36
3.3
Técnicas de Inspeção ................................................................................................................ 37
3.3.1
Técnica baseada em Checklist ......................................................................................... 38
3.3.2
Técnica baseada na detecção de defeitos ......................................................................... 39
3.3.3
Técnica baseada em perspectivas .................................................................................... 40
3.3.4
Técnica baseada no uso ................................................................................................... 40
TRABALHOS CORRELACIONADOS ...................................................................................... 43
4.1
5
Especificação de Software........................................................................................................ 23
Pressupostos para elaboração do checklist ............................................................................... 48
MÉTODO QualiCES ..................................................................................................................... 51
5.1
O método .................................................................................................................................. 51
5.2
Checklist ................................................................................................................................... 54
5.2.1
Itens Analisados ............................................................................................................... 55
5.2.2
5.3
6
Métrica ..................................................................................................................................... 61
5.3.1
Coleta de dados................................................................................................................ 62
5.3.2
Análise dos dados ............................................................................................................ 63
5.3.3
Forma de apresentação .................................................................................................... 64
AVALIAÇÃO DO QualiCES ........................................................................................................ 67
6.1
Projeto “Social e-Gov” ............................................................................................................. 67
6.1.1
6.2
7
8
Classificação dos defeitos ................................................................................................ 60
O problema ...................................................................................................................... 68
Aplicação do método ................................................................................................................ 68
6.2.1
Análise dos documentos a serem inspecionados ............................................................. 68
6.2.2
Aplicação do checklist ..................................................................................................... 69
6.2.3
Aplicação da métrica de consistência .............................................................................. 69
6.2.4
Análise dos resultados ..................................................................................................... 73
6.2.5
Análise do Método QualiCES ......................................................................................... 75
CONSIDERAÇÕES FINAIS......................................................................................................... 78
7.1
Resultados Obtidos ................................................................................................................... 79
7.2
Limitações e Trabalhos Futuros ............................................................................................... 81
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................................... 82
APÊNDICE A – Checklist QualiCES.......................................................................................................78
LISTA DE ABREVIAÇÕES
PC
Peso do item conteúdo
PDF
Peso do item dependência entre funcionalidades
PEF
Peso do item execução da funcionalidade
PF
Peso do item funcionalidade
poC
Pontos do item conteúdo
poDF
Pontos do item dependência entre funcionalidades
poEF
Pontos do item execução da funcionalidade
poF
Pontos do item funcionalidade
poU
Pontos do item usuário
PU
Peso do item Usuário
QC
Qualidade de Consistência
QualiCES
Qualidade de Consistência em Especificação de Software
TBC
Técnica baseada em checklist
TBDD
Técnica baseada na detecção de defeito
TBP
Técnica baseada em perspectivas
TBU
Técnica baseada em uso
TP
Total de perguntas
TPNA
Total de perguntas não aplicáveis
TPV
Total de perguntas válidas
UFMT
Universidade Federal de Mato Grosso
V&V
Validação e Verificação
LISTA DE FIGURAS
Figura 1- Processo de desenvolvimento de Software. .................................................... 23
Figura 2 - Processo de desenvolvimento de Software adotado para este trabalho. ........ 23
Figura 3 - Processo de Engenharia de Requisito. ........................................................... 24
Figura 4 - Defeito x Erro x Falha. ................................................................................... 32
Figura 5 - Progressão do esforço necessário para fixar os defeitos dos requisitos.. ....... 36
Figura 6 - Fluxograma de execução do Método QualiCES.......................................................53
Figura 7 - Trecho do checklist proposto para esse estudo. ............................................. 55
Figura 8 - Modelo gráfico para apresentar os resultados obtidos. .................................. 65
Figura 9 - Quantidade de defeitos detectados por itens para cada nível de consistência
definido pela métrica de consistência. ............................................................................ 75
LISTA DE TABELAS
Tabela 1 - Correspondência entre as classificações de defeitos analisados. ................... 47
Tabela 2 - Definição dos valores para as respostas possíveis. ........................................ 62
Tabela 3 - Pesos referentes a cada item analisado. ......................................................... 62
Tabela 4 - Modelo de apresentação dos resultados obtidos com a aplicação de 1
checklist. ......................................................................................................................... 65
Tabela 5 - Resultados obtidos com a aplicação do checklist e da métrica de consistência
........................................................................................................................................ 70
Tabela 6 - Quantidade de defeitos encontrados para cada classificação final da métrica.
........................................................................................................................................ 74
Tabela 7- Atributos de qualidade e regras do QualiCES ................................................ 76
Tabela 8 - Checklist proposto para o método QualiCES ................................................ 86
RESUMO
Em tempos em que a complexidade dos softwares requisitados por muitas empresas tem
aumentado, a busca pela sua qualidade, também tem sido maior. Contudo, deixar para
realizar a atividade de validação e verificação somente no final do processo de
desenvolvimento do software pode tornar-se mais custoso e exigir um esforço maior.
Estudos mostram que realizar esse processo de validação e verificação desde o início do
ciclo de vida do software pode reduzir os custos e os esforços gastos para consertar
erros que possam surgir. Assim, aplicar algum método de validação e verificação de
software ainda na fase inicial de seu desenvolvimento, além de detectar defeitos e
impedi-los de se expandirem, permite garantir que a qualidade também está presente
logo no início da vida do software. Durante a fase inicial de especificação de software,
diversos documentos e artefatos podem ser gerados como forma de auxiliar na sua
construção. A consistência entre esses documentos é um atributo de qualidade que deve
se destacar nessa fase do processo de desenvolvimento de software, uma vez que esses
documentos são base para as fases futuras da vida do software. Por isso, esta pesquisa,
além de revisar trabalhos relacionados ao tema, apresenta como resultados um método
de avaliação da consistência entre documentos e artefatos na fase de especificação de
software, o qual se apoia em um checklist e em uma métrica de consistência
desenvolvidos para esse fim, trazendo como benefícios a detecção de defeitos e a
garantia de qualidade de software desde o início do ciclo de vida de um software.
Palavras-Chave: especificação de software, inspeção de software, validação e
verificação de software, qualidade de software.
ABSTRACT
In times that the requirement software’s complexity for much companies has grown, the
quality seeking also has been bigger. However, doing the verification and validation
activity only in the end of the development software process can be more expensive end
demands a big effort. Some studies say that realize this verification and validation
process since the beginning of the software’s life cycle can reduce outgoings costs and
efforts to fix defects which can emerge. Thereby, applying some verification and
validation software method still in the beginning of its development, besides detecting
and thwarting defects, it allows to guarantee the quality also will there be since the
initial of the software’s life. During the early stage of the software’s specification,
several documents and artifacts can come to development assistance. The consistence
among those documents is a quality attribute must highlight in this process of software
development, once those documents are base to next activities of software’s life.
Therefore, this research also does a review among related works, and presents a method
of evaluation of consistency among documents and artifacts in the requirement software
engineer, which it draws heavily on a checklist and on a consistency metric, both were
developed for this reason, surfacing as a benefit of defects detection and the guarantee
of software quality since the beginning of the software’s cycle.
Key words: software specification, software inspection, verification and validation’
software, software quality.
18
1
INTRODUÇÃO
O desenvolvimento de software é um processo que tem se tornado cada vez mais
importante na sociedade atual. A informatização de diversas áreas do conhecimento
humano tem exigido que o desenvolvimento de software seja muito mais que
programação. É necessário que softwares sejam rigorosamente projetados e que a
qualidade esteja presente durante todo o processo de desenvolvimento.
Ao mesmo tempo em que o desenvolvimento de software tem crescido, a
complexidade das especificações feitas pelos clientes também tem se tornado maior.
Assim, os custos de desenvolvimento, o tempo de produção e as dificuldades de
manutenção aumentam. Além disso, com o aumento da complexidade dos softwares, os
produtos finais estão sujeitos a diversos erros, falhas e defeitos.
Para que esses problemas não perdurem, existe uma série de atividades de
validação e verificação, tais como técnicas de inspeção de software e testes de software,
que colaboram com a descoberta de problemas relacionados à qualidade do software.
Esses problemas podem estar relacionados ao modo pelo qual o software está sendo
construído ou ao produto não que está em conforme o especificado.
Este trabalho trata de análise de consistência entre documentos e artefatos na
fase de engenharia de requisitos de software por meio de atividades de validação e
verificação, aplicando-se técnicas para garantir a qualidade de um software.
Nas subseções seguintes será melhor delineado o conteúdo da pesquisa
representada neste estudo.
1.1 Justificativa
No mundo atual há uma demanda por qualidade em softwares. É necessário que
eles sejam manuteníveis, escalonáveis e integrados com outros sistemas existentes ou
em desenvolvimento. Entretanto, o aumento da complexidade, tem tornado cada vez
mais difícil atender a demanda de qualidade.
19
Assim, muitas vezes, os softwares são entregues sem a qualidade desejada e/ou
são entregues produtos finais diferentes do desejado ao cliente.
Bartié (2002), em um estudo realizado no mercado americano, apresenta
algumas estatísticas sobre qualidade: (i) mais de 70% dos projetos falham nas entregas
das funcionalidades esperadas; (ii) os custos extrapolam em 180% os valores
originalmente previstos; (iii) os prazos excedem em 200% os cronogramas originais.
Embora o tempo tenha avançado desde o surgimento da informática, a entrega
de produtos sem nenhuma ou com pouca qualidade continua sendo não aceitável. A
qualidade do software frequentemente é suspeita. Somente a partir da década passada
estão começando a ser seguidos conceitos quantitativos sólidos de confiabilidade e de
garantia de qualidade de software (PRESSMAN, 2000, p.247). Por qualidade de
software entende-se o grau no qual um sistema, componente ou processo encontra-se de
acordo com o requisito especificado, e/ou com as expectativas do usuário final (IEEE,
1991).
A busca por qualidade de um software desde a sua fase de análise é uma forma de
diminuir os custos e esforços no desenvolvimento do sistema.
Assim sendo, é importante que se utilizem técnicas de garantia da qualidade.
Nesse estudo, isso será realizado por meio de uma metodologia de validação e
verificação que deve ser feita na fase de especificação de software.
1.2 Objetivos
Os objetivos desse estudo são divididos em objetivos geral e específicos, os quais
são descritos a seguir.
1.2.1 Objetivo geral
Este trabalho tem por objetivo definir, desenvolver e analisar um método de
análise de consistência entre documentos e artefatos de software, por meio de pesquisa
bibliográfica e aplicações práticas. Tal método é útil já na fase de engenharia de
requisitos, provendo qualidade no desenvolvimento de software.
20
1.2.2 Objetivos específicos
A fim de alcançar o objetivo geral desse Trabalho de Conclusão de Curso
(TCC), alguns objetivos específicos foram formulados:
•
identificar, por meio de estudo bibliográfico, o(s) método(s) de validação de
verificação disponível(eis) para ser(em) aplicado(s) na fase de engenharia de
requisitos;
•
desenvolver um método de avaliação de consistência que apoie a validação e
verificação dos documentos e artefatos de requisitos;
•
analisar, em um estudo de caso, os documentos e artefatos de software
desenvolvidos na fase de engenharia de requisitos em relação à consistência;
•
desenvolver uma métrica que seja capaz de colaborar com a análise da
consistência entre os resultados obtidos, e
•
analisar os resultados obtidos com o estudo de caso, como meio de validar o
método desenvolvido.
1.3 Metodologia
Para alcançar os objetivos propostos, foi feita uma pesquisa bibliográfica acerca
do tema deste trabalho, utilizando-se como referência livros da engenharia e qualidade
de software, artigos internacionais disponíveis em bases da Institute of Electrical and
Electronics Engineers (IEEE) e Association for Computing Machinery (ACM), revistas
de engenharia de software, além de dissertações de mestrado e teses de doutorado.
Dessa forma, tentou-se compreender como o processo de validação e verificação de
software pode influenciar na obtenção de qualidade desde o início do processo de
desenvolvimento de um software.
Soma-se ao levantamento bibliográfico desse estudo, três macro-atividades
fundamentais, as quais guiaram todo o desenvolvimento do estudo:
1. Desenvolvimento de um método para validação e verificação da consistência
entre documentos e artefatos de software;
21
2. Aplicação do método desenvolvido; e
3. Análise dos resultados.
Esta pesquisa é de natureza aplicada, pois objetiva gerar conhecimentos para
aplicação prática dirigida à solução de um problema específico. Este trabalho foi
aplicada em documentos e artefatos que foram desenvolvidos no projeto “Social eGov”, contudo, espera-se que o método possa ser utilizado em qualquer outro projeto
desejado. Assim, além do estudo da literatura referente à qualidade de software, foi
necessária, também, a leitura de documentos associados ao projeto “Social e-Gov”.
1.4 Organização do trabalho
O trabalho, além deste capítulo introdutório, possui mais seis capítulos.
O Capítulo 2 apresenta uma revisão bibliográfica acerca de temas da Engenharia
de software referentes neste estudo: especificação de requisitos, validade e verificação
de software, inspeção e teste de software, e uma explicação da diferença entre erros,
falhas e defeitos.
O Capítulo 3 contém um apanhado de temas sobre qualidade de software,
apresenta atributos de qualidade para os requisitos e casos de uso, e traz uma revisão
sobre algumas técnicas de inspeção de software.
O Capítulo 4 apresenta alguns trabalhos relacionados à temática dessa pesquisa.
Já o Capítulo 5 apresenta o método de avaliação de consistência de documentos e
artefatos de software desenvolvido nesse trabalho. E o Capítulo 6 apresenta os
resultados da aplicação do método em um estudo de caso.
Por fim, o Capítulo 7 faz as considerações finais, apresentando os principais
resultados obtidos bem como as limitações e trabalhos futuros.
22
2
ENGENHARIA DE SOFTWARE
Um software, segundo IEEE (1991), é um programa de computador, procedimentos
e documentação associados ao funcionamento do código, e os dados pertinentes à
operação do sistema, ou seja, ele é composto de um programa de computador (código),
procedimentos, uma documentação, e dados necessários para a operação do sistema
(ISO, 1997, e ISO/IEC 9000-3).
A Engenharia de Software é uma disciplina de engenharia relacionada a todos os
itens de produção de software, desde os estágios de especificação do sistema até sua
manutenção (SOMMERVILLE, 2007).
O desenvolvimento de um software é composto por quatro etapas básicas e
fundamentais (SOMMERVILLE, 2007, p.6), como pode ser visto na Figura 1:
• Especificação de Software: trata da compreensão e definição das necessidades
do usuário e da identificação das restrições de operação e de desenvolvimento
do sistema;
• Desenvolvimento de Software: é a fase na qual a especificação de software será
convertida em um sistema executável. Nesse estágio do processo de
desenvolvimento de software estão envolvidos os processos de projeto e de
programação de software.
o Projeto de Software: trata da descrição da estrutura de software a ser
implementada, dos dados que são partes do sistema, das interfaces entre
os componentes do sistema, e às vezes, dos algoritmos usados. Ex.
definição da arquitetura do sistema e diagramação de atividades e de
classes.
• Validação de Software: este estágio do processo de desenvolvimento de
software destina-se a analisar se o sistema está em conformidade com a sua
especificação e que atende às expectativas dos usuários.
• Evolução de Software: é a fase na qual o software pode ser modificado para se
adaptar às mudanças dos requisitos do cliente.
23
Figura 1- Processo de vida de um Software.
Este trabalho restringe-se as fases de especificação de software e validação de
software, considerando que a última deve ocorrer durante todo o processo de
desenvolvimento de software, e não somente após a fase de desenvolvimento de
software, conforme ilustra a Figura 2.
Figura 2 - Processo de desenvolvimento de Software adotado para este trabalho.
Conforme descrito na Seção 1, este trabalho desenvolveu um método de
validação a ser utilizada na fase de Especificação de Software e, por isso, a seção
seguinte irá detalhar esta fase e a posterior, a fase de validação de software.
2.1 Especificação de Software
A fase de especificação de software á fase em que são determinadas as funcionalidades
e necessidades do software que se pretende desenvolver. Assim, diversos documentos e
artefatos podem ser desenvolvidos a fim de garantir que todas as necessidades do
software serão consideradas.
A seguir, são descritos os principais documentos e artefatos que são
considerados para o desenvolvimento desse trabalho.
24
2.1.1 Requisitos
Requisitos são descrições dos serviços do sistema e de suas restrições, geradas
durante o processo da engenharia de requisitos (SOMMERVILLE, 2007, p.49). Já o
glossário de termos de software do IEEE (1990) define um requisito como: uma
condição ou capacidade necessária para o usuário resolver um problema ou alcançar um
objetivo; e/ou uma condição ou capacidade que deve ser encontrada ou possuída por um
sistema ou componente do sistema para satisfazer um contrato, padrão, especificação ou
outro documento imposto formalmente.
Os requisitos podem ser divididos em várias formas, dentre elas em funcionais e
não funcionais. O primeiro refere-se ao que o sistema deve fazer. Já o segundo, referese como deve ser feito, além de representar as qualidades do sistema como,
desempenho, usabilidade, confiabilidade, facilidade de manutenção e capacidade de
expansão.
O processo de elaboração de um requisito chama-se engenharia de requisitos, e a
Figura 3 ilustrada a seguir demonstra o processo básico dessa atividade.
Figura 3 - Processo de Engenharia de Requisito. Adaptado de Sommerville (2007, p. 96).
• Elicitar requisitos: essa fase tem como objetivo captar os requisitos do
software, buscando obter conhecimento do domínio do problema. Como
atividades dessa fase, pode-se citar coleta de fatos, comunicação e identificação
das fontes de informação;
25
• Análise de Requisitos: aqui é feita a avaliação e revisão do escopo e dos
requisitos do software por meio do processo de descoberta, refinamento, revisão
e validação, obtendo, portanto, um entendimento sobre as funcionalidades do
sistema;
• Especificação de requisitos: essa fase objetiva desenvolver o documento de
requisitos identificados e desejados pelo cliente. Para isso, definem-se os
requisitos funcionais e não funcionais, e as regras de negócio para que o
requisito possa ser implementado e executado;
• Validação de requisitos: nessa fase se obtém o aceite do cliente em relação aos
requisitos de software, ou seja, eles são aprovados juntos ao cliente.
O principal documento trabalhado na engenharia de requisitos é o documento de
requisitos, sendo este uma declaração formal de todos os requisitos para a equipe de
desenvolvimento de software.
Para a análise de requisitos, diversas técnicas podem ser utilizadas, como o uso
de cenários, casos de uso e prototipagem. Neste trabalho são mais bem detalhados os
protótipos e casos de uso por serem estes os documentos alvo do método desenvolvido.
2.1.2 Casos de uso
Caso de uso é um meio de especificar e capturar requisitos de um sistema,
definindo seu comportamento de acordo com as necessidades dos usuários ou outras
entidades que interagem com o sistema, representados como atores (OMG, 2007 apud
GREGOLIN, 2007). Um modelo de caso de uso, portanto, representa o relacionamento
entre os usuários, chamados de atores, e as funcionalidades do sistema. O termo modelo
é utilizado para o conjunto do diagrama e descrição do caso de uso.
Um diagrama de caso de uso é um modelo que mostra os atores, os nomes dos
casos de uso e os relacionamentos entre eles. Para cada caso de uso no diagrama, deve
haver uma descrição relacionada que descreva como os atores e os sistemas colaboram
para alcançar o objetivo proposto para ele.
26
Uma descrição básica de caso de uso contém, tipicamente, nome, atores
relacionados, breve descrição do objetivo, fluxo básico de eventos, fluxo(s)
alternativo(s), requisitos funcionais, pré e pós-condições. Para Scott (2003) apud
Gregolin (2007):
“os casos de uso são bastante indicados para a definição de funcionalidades
do sistema por expressarem a perspectiva dos usuários do sistema, e por
serem expressos em linguagem natural, facilitando o entendimento entre o
leitor e equipe de desenvolvimento”.
A importância dos casos de uso é dada por formarem uma base para fases
seguintes à especificação de software no processo de desenvolvimento de software.
2.1.3 Protótipos
Outra forma de se obter os requisitos e/ou validá-los é por meio da prototipação
do software desejado. Sommerville (2007) diz que um protótipo pode ser utilizado em
um processo de software de várias maneiras, e dentro da engenharia de requisitos, um
protótipo pode ajudar na descoberta e validação dos requisitos do sistema.
O protótipo complementa o caso de uso, facilitando o entendimento das
funcionalidades do sistema. “Um protótipo é uma versão inicial de um sistema de
software usado para demonstrar conceitos, experimentar opções de projeto e,
geralmente,
conhecer
mais
sobre
o
problema
e
suas
possíveis
soluções”
(SOMMERVILLE, 2007, p.271). Assim, através da visualização, é possível capturar
mais detalhes para o caso de uso, e por sua vez, detectar requisitos faltantes, bem como
corrigir requisitos que estejam com informações erradas e/ou ausentes.
2.2 Validação de software
Todo e qualquer software deve ser verificado durante e depois do processo de
implementação para garantir que o programa em desenvolvimento atende as
expectativas de quem o solicitou (SOMMERVILLE, 2007, p.341). Esse processo recebe
o nome de Verificação e Validação (V & V), e embora pareçam sinônimos, Verificação
27
e Validação não são a mesma coisa (BOEHM, 1979 apud SOMMERVILLE, 2007,
p.341).
• Verificação: tem como objetivo verificar se o software em desenvolvimento
está de acordo com as especificações, ou seja, se atende os requisitos funcionais
e não funcionais especificados;
• Validação: a finalidade da validação é garantir que o software atende às
expectativas do cliente.
Para a verificação há duas respostas possíveis: correta e incorreta. Já para
validação, as duas respostas são: apropriadas e inapropriadas (DZIDA e FREITAG,
1998 apud POHL, 2010). O método proposto neste estudo é um método para
verificação.
O processo de V & V possui objetivos diretos e indiretos, como enumera Galin
(2004):
1. Objetivos diretos
a) Detectar e analisar erros bem como detectar correções, mudanças e adição de
informações requeridas em respeito à especificação original e mudanças
aprovadas;
b) Identificar novos riscos e completude do projeto;
c) Identificar os desvios dos padrões estabelecidos para o projeto;
d) Aprovar e analisar o design do produto.
2. Objetivos indiretos
a) Melhorar uma reunião para troca de conhecimento sobre técnicas, ferramentas e
métodos de desenvolvimento;
b) Registrar as análises e erros que servirão como base para correções futuras.
Os objetivos diretos lidam com o projeto corrente, já os objetivos indiretos,
lidam de uma forma geral, com o conhecimento profissional.
28
Dentro do processo de V & V, há duas abordagens complementares: Inspeção de
Software e Testes de software (SOMMERVILLE, 2007, p.342). Contudo, ressalta-se
que há outras abordagens para o processo de V & V como walkthrough e revisão em
pares, segundo (MPS.BR,2011). Mas para este trabalho serão consideradas somente as
duas citadas por Sommerville (2007). Além disso, a inspeção e o teste de software são
as duas mais comuns maneiras de garantir a qualidade de software nos dias atuais
(Elberzhager et al., 2011).
2.2.1 Teste de Software
Teste de software é o processo de executar um programa com a intenção de
encontrar erros (MYERS’, 1979 apud GALIN, 2004). Portanto, a atividade de teste tem
como objetivo demonstrar se as funções do software estão sendo executadas de acordo
com as especificações, se os requisitos de desempenho foram cumpridos e se, por
consequência, as informações geradas por ele são confiáveis. Assim, segundo
Sommerville (2007) o processo de teste de software tem duas metas distintas:
1. Demonstrar ao desenvolvedor e ao cliente que o software atende aos
requisitos;
2. Descobrir falhas ou defeitos no software que apresenta comportamento
incorreto, não desejável ou em não conformidade com sua especificação.
O teste de software é geralmente executado durante todo o processo de
desenvolvimento e manutenção do software. Nesse contexto, três tipos de teste podem
ser distinguidos, segundo SWEBOK (2004):
• Teste de unidade: verifica as funcionalidades de partes isoladas do software.
Pode ser um subprograma ou um componente;
• Teste de integração: verifica o processo de integração entre softwares
componentes;
• Teste de sistema: preocupa-se com o comportamento do sistema como um
todo; segurança, velocidade, hardwares, e ambiente de operação.
29
O teste de software pode ser executado utilizando-se de três estratégias
diferentes (BEIZAR, 1995 apud FARIA, 2003):
• Teste Funcional: checa se o software está de acordo com as especificações,
independente do código-fonte. O teste funcional também é conhecido como teste
de caixa-preta;
• Teste Estrutural: utiliza o código-fonte para que os testes possam ser
realizados. Também é conhecido por teste de caixa-branca;
• Teste Híbrido: usa uma mesclagem entre os testes funcional e estrutural.
As estratégias para Testes de software são formas de se abordar o modelo de
qualidade de produto definido pela NBR ISO/IEC 9126 (2003) dentro do processo de
desenvolvimento de um software. Pode-se dizer que o teste funcional está para a
qualidade externa, assim como o teste estrutural está para a qualidade interna.
Os testes não podem demonstrar que um software está livre de defeitos ou que
ele se comportará conforme especificado em todas as circunstâncias. Portanto, a meta
do teste de software é apenas convencer os desenvolvedores e clientes do sistema de que
o software é bom o suficiente para o uso operacional (SOMMERVILLE, 2007, p.355).
2.2.2 Inspeção de Software
Uma inspeção de software é definida como uma técnica de avaliação formal na
qual requisitos e design de software e, até mesmo, o código do programa são
examinados em detalhes por uma pessoa ou por um grupo para detectar defeitos,
violações de padrões de desenvolvimento e outros problemas (ANDA e SJØBERG,
2002). Melo (2009) generaliza dizendo que a inspeção de software é um tipo particular
de revisão que pode ser aplicado a todos os artefatos de software e possui um processo
de detecção de defeitos rigoroso e bem definido.
Como mostrado por Pohl (2010), a validação de software em fases iniciais do
processo de desenvolvimento de software reduz os custos e o esforço para correções de
erros em fases seguintes ao processo de desenvolvimento. Portanto, detectar defeitos
30
ainda na fase de elicitação de requisitos, evita que erros se propaguem por todo o ciclo
de desenvolvimento de um software. Detectar defeitos no documento de requisitos é
visto com uma das mais eficientes e efetivas técnicas de garantia de qualidade na
engenharia de software (PORTER et al., 1995; PARNAS and LAWFORD, 2003, apud
AURUM et al., 2004)
A inspeção de software apresenta vantagens em seu uso em relação aos testes de
software, como enumera Sommerville (2007, p.345):
1. Durante os testes, erros podem ocultar outros erros. Uma vez que um erro é
descoberto, não se pode estar seguro de se outras anomalias de saída são
devidas a um novo erro ou se erros causados pelo erro original. Assim, com
a inspeção de software não há necessidade de se preocupar com interações
entre erros. Portanto, a inspeção descobre muitos erros em um sistema em
uma única inspeção;
2.
Versões incompletas de um sistema podem ser inspecionadas sem custos
adicionais. Se um programa está incompleto, é necessário desenvolver um
conjunto de testes específicos para as partes disponíveis;
3. Assim como procurar defeitos de programas, uma inspeção pode também
considerar atributos de qualidade mais amplos de um programa como
conformidade com padrões de qualidade e facilidade de manutenção.
Embora inspeções de software sejam, atualmente, usadas amplamente, o teste de
programa será sempre a técnica principal de verificação validação de software
(SOMMERVILLE, 2007, p.354).
2.2.3 Falhas x Erros x Defeitos
O processo de Verificação e Validação tem por objetivo encontrar
inconsistências, seja com a especificação de requisitos e sua implementação, seja com o
desejo do cliente. Para que essas inconsistências sejam encontradas, o processo de V &
V tem duas abordagens (SOMMERVILLE, 2007): inspeção e teste de software. Durante
31
a realização delas, falhas, defeito e erros podem ser encontrados. A literatura l
estabelece significados específicos para estes termos (DELAMARO et al., 2007).
Para Delamaro et al. (2007) “defeito” é um passo, processo ou definição de
dados incorretos causados por erro humano. Já um “erro”, o qual se origina a partir de
um defeito, se caracteriza por um estado inconsistente ou inesperado. E por fim, o autor
define “falha” como sendo um resultado diferente daquilo que se é esperado. Já para a
IEEE 610 (1990),
•
Defeito: é um ato inconsistente cometido por um indivíduo ao tentar
entender uma determinada informação, resolver um problema ou utilizar um
método ou uma ferramenta. Por exemplo, uma instrução ou comando
incorreto;
•
Erro: é uma manifestação concreta de um defeito num artefato de software.
Diferença entre valor obtido e o valor esperado, ou seja, qualquer estado
intermediário incorreto ou resultado inesperado na execução de um programa
constitui um erro;
•
Falha: é o comportamento operacional do software diferente do esperado
pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns
erros podem nunca causar uma falha.
Neto (2009) separa esses conceitos em universos: físico, da informação e do
usuário; como pode ser visto na Figura 4. Para o autor, “defeitos” pertencem ao
universo físico (a aplicação propriamente dita), pois são ocasionados por mau uso da
tecnologia, por exemplo. Já os “erros” podem ser causados por um defeito e pertence ao
universo da informação, pois a construção de um software pode ser diferente ao que foi
especificado. Por fim, os erros geram “falhas”, que são comportamentos inesperados em
um software, o que afeta diretamente o usuário final da aplicação, e por isso, falhas
pertencem ao universo do usuário.
32
Figura 4 - Defeito x Erro x Falha. Adaptado de Neto (2009).
Apesar de reconhecer a diferença entre os três termos acima explicados, esse
estudo irá considerar os três termos como se fossem apenas um. Por isso, para esse
trabalho, opta-se por trabalhar com o termo “defeito” para expressar um problema
encontrado durante o processo de validação e verificação de software.
A detecção de erros, falhas e defeitos é uma forma de buscar pela qualidade de
software. Assim, no próximo capítulo será tratado sobre qualidade de software será
apresentado algumas técnicas de inspeção de software que permitem detectar erros,
falhas e defeitos.
33
3
QUALIDADE DE SOFTWARE
Atualmente software tem sido um dos produtos mais requisitados no mercado.
“A preocupação com a qualidade tem se tornado requisito imprescindível. Esta é a ideia
básica para garantir a funcionalidade do software com o mínimo de erros, defeitos e
maior satisfação às expectativas de qualidade” (MAIA, 2003).
Como forma de se garantir a qualidade de software, a inspeção e o teste de
software são ferramentas que auxiliam nesse processo ao colaborarem com a descoberta
de defeitos, erros e falhas.
Qualidade de software segundo IEEE (1991) refere-se ao grau que um sistema,
componente ou processo encontra-se de acordo com o especificado, além de atingir as
necessidades e expectativas do usuário final. Já para Pressman (2006), qualidade de
software é definida como a conformidade de explicitar requisitos funcionais e de
desempenho especificados, seguir padrões de desenvolvimento de documentos e seguir
as boas práticas de engenharia de software.
A Qualidade de um sistema de software pode ser entendida de diversas formas e
utilizando diferentes abordagens. Assim, a norma NBR ISO/IEC 9126 (2003) define um
modelo de qualidade de produto composto por características de qualidade, as quais são:
interna, externa e em uso. Abaixo, cada uma dessas é melhor explicada a seguir:
•
Qualidade Interna: especifica o nível de qualidade requerido sob o ponto
de vista interno do produto, isto é, na parte estrutural, o código-fonte;
•
Qualidade Externa: especifica o nível de qualidade requerido sob o ponto
de vista externo, isto é, visa à qualidade do software durante a sua execução,
a qual, geralmente, ocorre em ambientes simulados e com dados simulados.
•
Qualidade em Uso: especifica o nível de qualidade requerido sob o ponto de
vista do usuário, isto é, visa medir o quanto usuários podem atingir seus
objetivos num determinado ambiente e não as propriedades do software em
si.
34
A qualidade de software pode estar presente em todos os documentos e artefatos
de software que possam ser produzidos durante a sua construção, como nos requisitos,
casos de uso, protótipos, código fonte etc. Por serem foco deste estudo, nas próximas
seções serão melhor detalhado a qualidade de requisitos e de casos de uso.
3.1 Qualidade de Requisitos
Requisitos são a base de um software, são objetivos ou restrições estabelecidas
por clientes e usuários que definem as suas diversas propriedades do sistema e, são
aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.
Para Jani (2010) requisitos devem ser completos, claros e não ambíguos, porém,
requerem muito esforço para serem alcançados. Aurum et al. (2004) diz que estabelecer
requisitos completo, claros e não-ambíguos e assegurar que os requisitos seguirão os
padrões da indústria, melhora as chances de se obter uma qualidade maior no software.
Jani (2010) realizou um estudo que analisou a qualidade dos requisitos de
especificação do software para assegurar que a qualidade é aceitável. Uma técnica de
garantia de qualidade de software, checklist, foi aplicada ao estudo para determinar se os
padrões de requisitos e procedimentos estavam ou não sendo seguidos dentro da fase de
especificação dos requisitos. Para tanto, o autor identificou atributos de qualidade que
são esperados em um documento de especificação de requisitos:
•
Completo: uma especificação de requisitos é completa quando define todas as
situações reais e inclui todas as características necessárias para o software;
•
Consistente: uma especificação de requisitos é consistente quando não há
conflito entre os requisitos;
•
Correto: uma especificação de requisitos está correta quando identifica com
precisão e exatamente as condições e limitações individuais de todos os casos
desejados;
•
Modificável: uma especificação de requisitos é modificável quando os
requisitos são agrupados juntos e em ordem, a fim de facilitar as modificações
quando necessário;
35
•
Classificação por importância: uma especificação de requisitos deve
identificar os requisitos de acordo com o seu grau de importância;
•
Rastreável: em uma especificação de requisitos, os requisitos devem ser
unicamente identificados para alcançar a rastreabilidade;
•
Não-ambíguo: um requisito deve ser escrita de forma a não permitir diversas
interpretações;
•
Compreensível: uma especificação de requisitos é compreensível se o
significado de cada afirmação pode ser facilmente entendida;
•
Testável: uma especificação de requisito é testável se a partir dele consegue-se
aprovar ou reprovar o requisito por meio de critérios de avaliação;
•
Verificável: uma especificação de requisito dever possível de ser verificada se
foi atendida;
•
Validável: uma especificação de requisitos é validável se ela pode ser analisada,
validada e aprovada por responsáveis e participantes do projeto de software.
O método aplicado por Jani (2010) é um exemplo de método de checagem de
requisitos realizado por meio da verificação dos atributos de qualidade desejados.
Existem algumas práticas que colaboram com a obtenção da qualidade de
requisitos (GUSEV, 2010):
•
Métodos de desenvolvimento de Requisitos: técnicas de elicitação de
requisitos (aplicação de questionário, por exemplo) e técnicas de documentação
(uso de templates, por exemplo);
•
Métodos de checagem de requisitos: inspeção em grupo ou individual, revisão
pelo usuário, e prototipagem.
A especificação de requisitos serve como referência para as fases seguintes no
processo de desenvolvimento de software. Se um erro não é detectado logo no início
desse processo, ele pode se propagar e assim, afetar os demais artefatos que ainda serão
desenvolvidos. Portanto, encontrar e corrigir erros nos artefatos de requisitos logo no
início do processo de desenvolvimento de software, evita correção de defeitos
36
futuramente, e dessa forma o esforço e o custo de correção são reduzidos, como a
Figura 5 ilustra.
Figura 5 - Progressão do esforço necessário para fixar os defeitos dos requisitos. Adaptado de
Pohl (2010).
Neste contexto, a fase de especificação de requisitos merece uma atenção
especial, dela derivam todos os outros artefatos de desenvolvimento de software.
3.2 Qualidade de Casos de Uso
Um modelo de caso de uso descreve como diferentes tipos de usuários interagem
com o sistema para resolver um problema. Como tal, ele descreve as metas dos
usuários, as interações entre os usuários e o sistema, bem como o comportamento
necessário do sistema para satisfazer estas metas.
Um modelo de caso de uso pode se originar a partir de um documento de
especificação de requisitos, ou pode ser desenvolvido a fim de representar os requisitos
do sistema. Porém, ao construir um modelo de caso de uso a partir dos requisitos,
Belgamo et al. (2007) diz que o desenvolvedor deve estar atento porque haverão
defeitos originados em fases anteriores, mesmo que tenham sido inspecionados.
Um caso de uso pode satisfazer diversos requisitos ou um requisito pode ser
descrito por diversos casos de uso. Isso, frequentemente, dificulta alcançar a
completude e a consistência, o que pode causar problemas nas fases seguintes do
processo de desenvolvimento de software (AURUM et al., 2004).
Gregolin (2007) definiu atributos de qualidade de casos de uso. São eles:
37
•
Completeza: A descrição do caso de uso deve ser a especificação detalhada do
seu objetivo, contendo todos os seus elementos básicos. Além de especificar os
fluxos principal e alternativo da forma mais completa possível;
•
Compreensibilidade: As sentenças devem evidenciar um diálogo exato entre o
ator e o sistema, descrevendo o que deve ser feito e não como fazer, e definindo
os requisitos do sistema. Além disso, é necessário que haja uma breve descrição
do propósito do caso de uso;
•
Precisão: Os termos utilizados devem ser precisos e quantificáveis, isto é,
termos como “muito”, “pouco”, “claro”, “fácil” etc devem ser evitados.
•
Não ambiguidade: Termos que dão margem a diversas interpretações devem
estar claramente identificados e definidos no glossário;
•
Consistência: Os termos utilizados no caso de uso devem ser iguais sempre que
se referirem à mesma coisa;
•
Independência de ferramentas: A descrição deve evitar termos que indicam
dependência de ferramenta ou interface com o usuário, como a presença do
termo “clicar”, “aba”, “botão” etc;
•
Rastreabilidade: As frases dos fluxos principal e alternativo devem ser
numeradas para permitir a rastreabilidade;
•
Objetividade: As sentenças devem ser objetivas e evitar redundâncias.
3.3 Técnicas de Inspeção
Como mencionado na Seção 2.2.1 deste trabalho, inspeção de software é uma
forma de avaliar documentos e artefatos de software a fim de encontrar problemas que
possam impedir os usuários de interagirem com o software desenvolvido, e até mesmo
problemas que podem impedir o desenvolvimento do software.
A fim de melhorar a compreensão e a busca por defeitos, o processo de inspeção
de software possui diversas técnicas de revisão que podem ser utilizadas. Embora
tenham sido desenvolvidas baseadas em diferentes suposições com referência ao
38
processo de inspeção, essas técnicas possuem um objetivo em comum: ajudar os
revisores a focar nos documentos de software durante a inspeção e assim, encontrar
mais erros (THELIN, 2003). Contudo, a inspeção também pode ser utilizada como
forma de avaliar a usabilidade e acessibilidade dos softwares (MACIEL, 2005), não
somente documentos e artefatos de software na fase de engenharia de requisitos, como
é o foco deste trabalho, ou somente na fase final do processo de desenvolvimento do
software, como propôs a Figura 1 deste trabalho.
A seguir, uma revisão das técnicas de inspeção de software, com finalidade de
aplicação na fase de especificação de software, é apresentada.
3.3.1 Técnica baseada em checklist
A técnica baseada em checklist (TBC) é uma técnica de inspeção que guia o
revisor por uma série de tópicos a serem analisados no artefato desejado, ajudando-o a
procurar defeitos ou deficiências. “Itens individuais de um checklist podem enumerar,
priorizar ou propor questões para ajudar o revisor a descobrir defeitos” (MELLO,
2009). Belgamo et al. (2005) diz que espera-se que um checklist guie os revisores
durante todo o processo de inspeção para detecção de defeitos nos documentos e/ou
artefatos inspecionados.
Contudo, Pohl (2010) diz que o checklist não deve ter um número muito grande
de perguntas para o revisor analisar durante o processo de inspeção. O número de
questões deve ser pequeno como forma de garantir uma validação mais efetiva. Pohl
(2010) ainda diz que um checklist não deve conter todas as regras, ou critérios de
qualidade, ou tipos de defeitos esperados em um único checklist, é necessário separar os
assuntos que se deseja inspecionar em vários outros checklists.
Pohl (2010) diz que se um checklist for bem desenvolvido, será possível fazer as
seguinte análises, as quais são as metas do processo de validação.
• Checagem de entrada: é analisado se o contexto do sistema foi considerado
corretamente, por exemplo, se todas as fontes de requisitos foram levadas em
consideração;
39
• Checagem de saída: é analisado se os artefatos de requisitos se combinam entre
si, analisando o conteúdo e a documentação, por exemplo.
• Checagem de execução: é analisado o processo de documentação, isto é, é
analisado se a documentação seguiu regras, boas práticas e o processo de
descrição da engenharia de software, por exemplo.
Assim, para que possa ser possível checar a entrada, saída e a execução do
software em desenvolvimento, é necessário estruturar as questões que farão parte do
checklist assim como a própria ferramenta a ser elaborada. Para isso, Pohl (2010) cita
algumas boas maneiras para elaborar um bom checklist, como:
• Evitar um checklist com muitas perguntas;
• Evitar perguntas genéricas;
• Elaborar questões que permita a checagem de entrada, de saída e de execução;
• Utilizar diferentes checklists para diferentes artefatos;
• Considerar diversas perspectivas para inspeção;
A utilização do checklist é tida como técnica padrão de inspeção de software em
muitas empresas, segundo Thelin et al. (2003). Talvez isso se justifique, pois,a TBC
pode ser aplicada como complemento em qualquer outra técnica de validação e
verificação (POHL, 2010).
3.3.2 Técnica baseada na detecção de defeitos
A técnica baseada na detecção de defeitos (TBDD) visa identificar tipos de
defeitos específicos. Essa técnica define uma série de cenários e procedimentos que
devem ser seguidos durante o processo de inspeção. Essa técnica objetiva encontrar os
mesmos tipos de defeitos da TBC, contudo, mais informações são incluídas nos
cenários a fim de projetar uma técnica mais estruturada (THELIN, 2003).
40
3.3.3 Técnica baseada em perspectivas
A inspeção baseada em perspectiva (TBP) é uma técnica baseada em cenários,
que dá ao revisor procedimentos a serem seguidos durante a inspeção. Em cada
perspectiva é definido um cenário e um conjunto de questões e atividades que dizem ao
indivíduo o que ele deve fazer e como ele deve ler o documento. Essas questões
auxiliam o indivíduo a descobrir defeitos. Os cenários descrevem as atividades que
devem ser executadas pelo indivíduo no momento da leitura a fim de descobrir defeitos
em suma. Um cenário, neste contexto, é uma coleção de procedimentos que permitem
operacionalizar estratégias para detectar defeitos (MELO, 2009).
A inspeção baseada em perspectivas é definida baseada em três perspectivas:
usuário, testador e designer. Pohl (2010):
•
Perspectiva do Usuário: o revisor deve verificar se o artefato descreve a
funcionalidade e a qualidade desejada pelo usuário;
•
Perspectiva do Designer: o revisor deve verificar se os requisitos contém as
informações necessárias para desenvolver a arquitetura do software;
•
Perspectiva do Testador: o revisor deve verificar se o artefato pode ser
utilizado como base para o desenvolvimento de casos de testes.
Thelin (2003) faz duas afirmações referentes a essa técnica: i) revisores com um
foco específico inspecionam melhor do que revisores com a responsabilidade de
detectar todos os tipos de defeitos e ii) que diferentes focos podem produzir uma
inspeção mais completa.
Essa técnica pode ser utilizada durante todo o processo de desenvolvimento de
software.
3.3.4 Técnica baseada no uso
Thelin (2003) diz que muitos estudos focam em encontrar tantos defeitos quanto
é possível, sem levar em consideração a importância deles. Assim, a principal ideia por
traz da técnica de inspeção baseada no uso (TBU), segundo o autor, é focar na detecção
41
dos defeitos mais críticos no artefato inspecionado. Aqui, os defeitos não são
considerados de mesma importância, e nessa técnica procura-se detectar os defeitos que
tem o maior impacto negativo de qualidade de sistema na perspectiva do usuário.
A técnica baseada em uso utiliza um conjunto de casos de uso como guia de foco
na inspeção. Os casos de usos dizem aos revisores como inspecionar o documento de
designer ou o documento do código do software da mesma maneira como os casos de
testes dizem aos testadores, como testar o sistema.
Thelin (2003) dá um exemplo do fluxo básico para realizar o uso dessa técnica:
•
Antes da inspeção, priorizar os casos de uso em grau de importância na
perspectiva do usuário;
•
Durante a preparação, confira os documentos a serem utilizados durante essa
atividade: documento de design, os casos de usos a serem utilizados como
guia, e o documento de requisitos;
•
Durante a inspeção, seguir os passos a seguir:
a. Selecione o caso de uso com a maior prioridade;
b. Rastreie e execute manualmente o caso de uso por meio do
documento de design e use os requisitos como referência;
c. Assegure que o documento sob inspeção preenche as metas do caso
de uso, que as funcionalidades são fornecidas, que a interface está
correta. Identifique e registre os problemas encontrados;
d. Repita todo o processo de inspeção utilizando o próximo caso de uso
até que todos tenham sidos inspecionados.
O objetivo dessa técnica é melhorar a eficiência e a efetividade da inspeção
considerando o grau de importância dos casos de uso de acordo com a visão do usuário.
As técnicas anteriormente descritas são uma das formas de se detectar defeitos,
falhas e erros em um processo de desenvolvimento de software, assim como a detecção
de defeitos é uma forma de se garantir qualidade de software. Diversos estudos sobre
essas técnicas foram realizados a fim de tentar detectar as melhores técnicas e a fim de
42
se buscar por mais qualidade de software. No próximo capítulo alguns estudos serão
relatados a fim de justificar o método proposto neste estudo.
43
4
TRABALHOS CORRELACIONADOS
Qualidade de Software é um processo que visa garantir a conformidade de
processos e produtos, prevenindo e eliminando defeitos por meio do processo de
validação e verificação nos artefatos produzidos. Defeitos são encontrados em todas as
fases do desenvolvimento, porém é comprovado que a maioria encontra-se nas fases
iniciais do processo de desenvolvimento. Isso gera prejuízos enormes para as empresas
desenvolvedoras de software, pois o preço para corrigir um erro cresce muito com o
passar do tempo. Com isso, fica clara a importância de um processo de Garantia da
Qualidade que atue em todas as fases do processo de desenvolvimento (MELO, 2009).
Estabelecer requisitos livres de defeitos é a estratégia chave para garantia da
qualidade. Assim, diversos estudos têm sido feitos com o intuito de detectar defeitos
desde a fase inicial de especificação de requisitos, uma vez que é sabido que quanto
mais cedo defeitos forem descobertos, menor será o custo de reparo em fases futuras do
processo de desenvolvimento de software.
Jani (2010) em seu estudo propôs um sistema online que auxilia na percepção de
qualidade entre os requisitos. O autor propôs um checklist online no qual o usuário
deveria respondê-lo para saber se a sua especificação de requisitos está ou não seguindo
certos padrões e procedimentos de desenvolvimento. Para isso, foram descritos atributos
de qualidade de requisitos, tais como completude, rastreabilidade e corretude, por
exemplo. Esses atributos são apresentados na seção 3.2.2 deste trabalho.
Por outro lado, Gusev (2010) diz que um checklist geralmente esquece de
analisar critérios de qualidade de requisitos. Para Gusev (2010), a qualidade dos
requisitos é mais importante do que a qualidade de qualquer outro documento do ciclo
de desenvolvimento de software. Sendo assim, o autor propõe um meio mais iterativo
de verificação e validação. O estudo define que uma forma de se obter uma qualidade
maior não só na especificação de requisitos, mas sim em todo o processo de
desenvolvimento de software, é ir verificando e validando todos os artefatos gerados
durante todo o processo de software. O autor coloca que quando se opta em trabalhar
com um fluxo de atividades na qual uma atividade só será iniciada após a atividade
44
anterior ser completamente terminada e aprovada, alguns defeitos não serão detectados
uma vez que só irão surgir quando forem testados em outras fases do processo de
desenvolvimento de software. Assim, o autor propõe que outros artefatos sejam gerados
para verificação e validação de requisitos, como protótipos, e que a verificação não se
restrinja somente ao checklist, por exemplo. Para concluir, o autor ressalta que esse
fluxo de atividades não garante que os requisitos estejam salvos de erros, mas garante
que defeitos potencialmente críticos que afetam a implementação são pegos.
Assim como Gusev (2010), Thelin et al. (2003) criticam a técnica de inspeção de
software baseada em checklist em seu estudo. Thelin et al. (2003) em seu estudo
comparam duas técnicas de inspeção de software: a baseada no uso, e a baseado em
checklist. Os autores dizem que a técnica baseada no uso é melhor que o checklist em
termos de efetividade e eficiência ao encontrar defeitos que mais afetam os usuários,
além de ser mais rápida a sua aplicação.
Já Belgamo et al. (2005) compararam a eficiência e a efetividade do checklist
com a ferramenta desenvolvida pelo estudo. TUCCA (Technique for Use Case Model
Construction and Construction-based Requiremnts Document Analysis) é composta por
duas técnicas de inspeção: AGRT (Actor Goal Reading Technique) que visa determinar
os atores do sistema e suas metas, e UCRT (Use Case Reading Technique) que tem por
objetivo determinar o modelo de caso de uso. Em conjunto, essas técnicas colaboram
com a construção do caso de uso além de revisarem o documento de especificação de
Requisitos. Com o estudo e experimento realizados, os autores mostraram que o
TUCCA é efetivo na construção do caso de uso e na detecção de defeitos, uma vez que
a técnica desenvolvida obteve resultados tão bons quanto o uso da técnica baseada no
checklist. Os autores consideram que defeitos sempre existem em qualquer artefato
desenvolvido e que a fase de engenharia de requisitos é essencial para o sucesso das
próximas fases no desenvolvimento de software, e por isso, o TUCCA auxiliar na
detecção de defeitos na fase de construção de dos casos de uso, uma vez que o
documento de requisitos é base para a construção desse artefato.
Uma vez construído o caso de uso, Anda e SjØberg (2002) dizem que a sua
qualidade em termos de corretude, completude, consistência e bom entendimento do
requisito funcional são importantes para a qualidade final do produto de software.
45
Assim, Anda e SjØberg (2002) desenvolveram um checklist como tentativa para o
desenvolvimento de uma taxonomia de defeitos para os casos de uso. O checklist
desenvolvido é composto por dezenove perguntas divididas em quatro itens de análise:
atores, o caso de uso, a descrição de cada caso de uso, e a relação entre os casos de uso.
Já Aurum et al. (2004) por meio de onze perguntas, analisaram outros itens: cobertura
do caso de uso, precisão, abstração da descrição, consistências da estrutura do caso de
uso e da linguagem utilizada, e fluxos alternativos.
Os estudos relatados à cima buscaram: comparar técnicas de inspeção de
software por meio da quantidade erros encontradas ou em buscar a qualidade somente
por meio do desenvolvimento de um checklist que levava a erros específicos de caso de
uso. Assim, algumas classificações para os erros foram propostas, variando a forma e o
objetivo com os quais deveriam ser analisados. A relação entre essas classificações
podem ser vistas na Tabela 1.
Para Thelin et al. (2003), os defeitos encontrados em seu estudo foram
classificados em três classes em nível de importância para o usuário:
•
Classe A: As funções afetadas por esses defeitos são cruciais para os usuários,
isto é, são importantes para os usuários e são frequentemente usadas;
•
Classe B: As funções afetadas por esses defeitos são importantes para o usuário,
isto é, as funções afetadas ou são importantes e raramente usadas ou não são
importantes mas, frequentemente utilizadas;
•
Classe C: As funções afetadas não são importantes para os usuários.
Já para Aurum et al. (2004) os defeitos foram classificados em:
• Impacto Mínimo: defeito interno do caso de uso;
• Impacto de Especificação: falta de requisito na descrição do caso de uso;
• Impacto de Requisitos: os efeitos desejados no domínio do problema não são
alcançados.
Gregolin (2007) classificou os defeitos dos casos de uso em três níveis:
46
• Alto: defeitos relacionados aos relacionamentos entre casos de usos e atores,
afetando a compreensibilidade do modelo, e caso de uso que poderia ser
agrupado a outro caso de uso;
• Baixo: defeitos que se corrigidos aumentariam a qualidade do caso de uso, mas
não impede a compreensibilidade geral;
• Médio: defeitos que não são nível Alto e nem Baixo.
Porém, Nielsen (1994) classificou o grau de severidade dos erros encontrados de
acordo com a importância de correção dos mesmos. Os erros, neste caso, eram
problemas de usabilidade, porém a sua classificação pode ser adaptada para o método
proposto neste estudo. Cinco classificações são possíveis a partir dessa análise:
• Sem importância: o defeito encontrado não afeta o usuário;
• Cosmético: o defeito não necessita ser reparado, a menos que haja tempo
disponível;
• Simples: o defeito pode ser reparado, com baixa prioridade de correção;
• Grave: o defeito deve ser reparado, com alta prioridade de correção;
• Catastrófico: o defeito deve ser reparado de qualquer forma antes do produto
ser disponibilizado.
A Tabela 1 a seguir, a partir das classificações definidas por Nielsen (1994),
Thelin et al. (2003), Gregolin (2007) e Aurum et al. (2004), faz uma relação entre as
diversas classificações mostrando que são semelhantes. Cada autor é representado por
uma coluna, e por fim é feita um resumo da relação analisada.
47
Tabela 1 - Correspondência entre as classificações de defeitos analisados.
Nielsen
Thelin et
Gregolin
Aurum et al.
(1994)
al. (2003)
(2007)
(2004)
Síntese
Defeitos que não afetam a operação e
compreensibilidade geral, que se corrigidos
Sem
importância
Classe C
Baixo
Impacto
aumentariam a qualidade do proposto; sendo
Mínimo
funções
que
não
são
suficientemente
importante para os usuários e, portanto, não
há necessidade de correção.
Defeitos que não afetam a operação e
compreensibilidade geral, que se corrigidos
Cosmético
Classe C
Baixo
Impacto
aumentariam a qualidade do proposto; sendo
Mínimo
funções que não são tão importantes para os
usuários e, portanto, não há necessidade de
correção, somente se houver tempo.
Defeitos
em
funcionalidades
que
são
importantes para os usuários, geralmente a
Simples
Classe B
Médio
Impacto de
falta de um requisito causa esse tipo de
Especificação
defeitos, os quais podem ser corrigidos com
baixa prioridade de correção, uma vez que
não afetam os usuários.
Os objetivos desejados não são alcançados e,
portanto, devem ser reparados com alta
Grave
Classe B
Médio/Alto
Impacto de
prioridade de correção, uma vez que se trata
Requisito
ou de funções importantes para os usuários,
ou que não são importantes, mas são muito
utilizadas por eles.
Os objetivos desejados não são alcançados,
Catastrófico
Classe A
Alto
Impacto de
Requisito
porém, devem ser corrigidos antes do
produto ser disponibilizado, uma vez que
são funções importantes e frequentemente
utilizadas pelos usuários.
48
4.1 Pressupostos para elaboração do checklist
Os estudos relatados anteriormente apresentaram checklists como uma
ferramenta de apoio de inspeção, os quais eram considerados como apenas um artefato
do processo de desenvolvimento de software.
Anda e SjØberg (2002) no seus estudos desenvolveram um checklist para
inspecionar casos de uso, e para tanto, consideraram quatro itens: i) os atores,
analisando se os atores estão definidos no caso de uso, se estão totalmente descritos e
claros; ii) o caso de uso, investigando se falta requisitos na descrição do caso que
impeçam o ator de cumprir a meta do caso de uso, ou se o caso de uso considera o papel
do ator na sua descrição; iii) a descrição do caso de uso, analisando o fluxo principal do
caso de uso, os termos utilizados para a descrição dos passos do fluxo, as pré e pós
condições; e iv) a relação entre casos de uso, analisando se a descrição do caso de uso e
o seu digrama combinam, se o comportamento do caso de uso está em conflito com
outro.
Já Aurum et al. (2004), com o checklist desenvolvido em sua pesquisa,
analisaram a abrangência do caso de uso, a coerência e a consistência dos passos dos
fluxos principal e alternativos dos casos de uso e, analisaram se o caso de uso encontrase descrito em nível abstrato. Além disso, os autores também analisaram a linguagem da
descrição, a estrutura e os fluxos dos casos de uso, assim como Anda e SjØberg (2002)
também analisaram.
Nessa mesma linha de estudo de inspeção de casos de uso, Gregolin (2007)
também apresentou um checklist como ferramenta para inspeção, contudo, a autora
considerou apenas a descrição e o diagrama do caso de uso como artefatos
inspecionáveis. Para a descrição dos casos de uso, a autora considerou a forma e
organização, escrita, termos utilizados, conteúdo e artefatos de suporte.
Contudo, como observado, Anda e SjØberg (2002), Aurum et al. (2004) e
Gregolin (2007) analisaram a inspeção da descrição e diagramação dos casos de uso,
não considerando outros documentos e artefatos de software que há no processo de
desenvolvimento de software.
49
Por outro lado, Belgamo et al. (2005), embora tenham utilizado o documento de
especificação de requisitos como base para seus estudos, a técnica desenvolvida pelos
autores, a TUCCA, utiliza o documento de requisitos como base para a construção dos
casos de uso a partir de outras duas técnicas, ou seja, o estudo também é voltado para os
casos de uso.
Gusev (2010) em seu estudo mostrou que quando o processo de validação e
verificação ocorre desde a fase inicial do desenvolvimento de software, e para isso
apoia-se no uso de outros artefatos como protótipos, mais defeitos estão sujeitos a serem
detectados, uma vez que alguns só aparecem após a execução do sistema ou em fases
posteriores a especificação de software. Dessa forma, o autor propõe um processo de
inspeção mais interativo. Assim, o método desenvolvido nesse estudo, considera como
documentos a serem analisados: documento de especificação de requisitos, descrição
dos casos de uso e protótipos de tela. Isto é, é proposto um método que analisa a
consistência entre documentos e artefatos gerados durante o processo de especificação
de software, não se restringindo somente a busca de qualidade de casos de uso, mas sim
da qualidade do processo de especificação de software.
Assim, como os estudos acima relacionados, o método proposto neste estudo,
intitulado de QualiCES (Qualidade de Consistência em Especificação de Software),
apoia-se na utilização da técnica de checklist, mesmo que alguns estudos tenham
mostrado que a utilização do checklist quando comparado com a aplicação de outras
técnicas no mesmo processo de validação e verificação, pode não ser tão eficiente na
detecção de defeitos. É o caso do estudo proposto por Thelin et al. (2003), no qual os
autores compararam a técnica de checklist com a técnica baseada em uso. Contudo, a
comparação proposta por Thelin et al. (2003) analisa a detecção dos defeitos mais
graves na perspectivado usuário.
O método desenvolvido neste trabalho também utiliza de checklist com o
objetivo de analisar a consistência entre documentos e artefatos de software, e assim,
por consequência, encontrar defeitos que afetariam os usuários, além de colaborar com
a qualidade de software desde o início do ciclo de vida do software.
50
Em adição ao checklist, o método QualiCES considera a técnica baseada em
perspectivas, ou seja, para a detecção de defeitos será considerado e analisado se o
defeito encontrado afeta ou não o usuário, como propõem Thelin et al. (2003).
Para a detecção dos defeitos que podem ser encontrados durante a inspeção dos
casos de uso, Anda e SjØberg (2002) propuseram uma taxonomia de defeitos em casos
de uso e Aurum et al. (2004) apresentaram uma tabela com os principais erros
detectados nesse processo de validação e verificação. Em análise a essa taxonomia e a
essa Tabela de defeitos, percebeu-se que muitos desses erros podem ocorrer não
somente em casos de usos, mas também em documentos de requisitos e protótipos de
tela também. Assim, para a elaboração do checklist proposto neste estudo, alguns dos
defeitos apontados por Aurum et al. (2004) e Anda e SjØberg (2002) foram
considerados no processo de escrita das perguntas que iriam compor o checklist.
Portanto, o checklist proposto como ferramenta de apoio ao método desenvolvido não
analisa questões como estrutura do caso de uso, e o modo pelo qual o caso de foi
descrito e do documento de requisitos, por exemplo. O checklist proposto está baseado
na detecção de defeitos que trazem inconsistência ao processo de especificação de
software, como a falta de requisitos, a não consideração de informações presentes nos
requisitos funcionais que não foram seguidas nos casos de uso e nos protótipos, e
incoerência entre dicionário de dados e protótipos, por exemplo.
Buscando a consistência entre os documentos da fase de análise de requisitos, o
checklist pretende apontar defeitos que serão classificados a partir de uma classificação
originada a partir das classes de defeitos feitas por Nielsen (2003), Aurum et al. (2004),
Thelin et al. (2003) e Gregolin (2007).
Por fim, espera-se que ao final da aplicação do método proposto possa se
alcançar os atributos de qualidade como propõem Gregolin (2007) e Jani (2010).
Na próxima seção, o método proposto será descrito. No decorrer da descrição,
detalhes dos pressupostos utilizados para concepção do checklist serão descritos como
forma a enaltecer suas características e a forma com a qual se espera alcançar a
qualidade e a consistência dos documentos e artefatos da especificação de software.
51
5
MÉTODO QualiCES
Este capítulo está estruturado de forma a apresentar a proposta do método
QualiCES, apresentando as etapas para sua aplicação, o checklist de apoio para o
método, além da métrica de consistência desenvolvida para análise dos resultados
obtidos com a aplicação do checklist.
5.1 O método
Consistência é a coerência na exposição das ideias (AURELIO, 2010). Sendo
assim, consistência neste estudo significa coerência entre os documentos e artefatos de
requisitos de software. Sendo assim, apresenta-se nesta pesquisa um método de análise
de consistência entre documentos do desenvolvimento do software.
O QualiCES é um método que tem como objetivo avaliar a consistência entre
documentos de requisitos de software, em especial entre Especificação de Requisitos,
Casos de Usos e Protótipos. Por esse motivo, trata-se de um método de garantia da
qualidade que pode ser utilizado nas fases iniciais do desenvolvimento de software e,
portanto, contribui para a diminuição dos custos de um projeto.
O método é composto por cinco etapas, as quais são descritas a seguir e contém
atividades correspondentes para a sua realização.
1. Identificação das necessidades de qualidade: essa etapa consiste na
identificação das necessidades da equipe de desenvolvimento de software.
Assim, embora exija um pouco de esforço e custos extras para garantir a
qualidade de software, em longo prazo os custos e esforços necessários para
consertar futuros defeitos serão menores. Por isso, para a aplicação do método
QualiCES, faz-se necessário que se tenha os documentos de requisitos, descrição
dos casos de uso e protótipos de tela;
2. Análise dos documentos e artefatos necessários: essa etapa é responsável por
reunir os documentos necessários para análise e verificar se estão completos. Por
exemplo, para o documento de requisitos, descrição de casos de uso e protótipos,
52
deverá ser verificado para cada de uso, se há o seu protótipo correspondente, se
o documento de requisitos está completo e com os requisitos numerados e
identificados corretamente. Esta etapa é constituída das seguintes atividades:
a) Obter os documentos necessários para a aplicação do método;
b) Analisar os documentos, analisando se há um caso de uso e um
protótipo ou um conjunto de protótipos correspondentes, bem como
analisando se o documento de requisitos está completo;
3. Aplicação do checklist: o checklist é uma ferramenta que deve ser aplicada para
cada de uso separadamente com o seu respectivo protótipo de tela, a fim de
detectar defeitos entres os documentos e artefatos do processo de especificação
de software. As seguintes atividades compõem essa etapa:
a) Escolher um caso de uso e seu protótipo correspondente e preencher o
cabeçalho do checklist, com finalidade de identificar a aplicação
realizada;
b) Para cada pergunta do checklist analisar a regra e dar o parecer final da
análise;
c) Se algum defeito for detectado, preencher os campos destinados a
identificação dos defeitos;
4. Aplicação da Métrica de consistência: com a aplicação do checklist obtêm-se
os defeitos, e a partir dos defeitos é possível aplicar a métrica de consistência
para análise de qualidade dos artefatos e documentos inspecionados. Para tanto,
faz-se necessário a execução das seguintes atividade.
a) Após preencher todo o questionário, coletar os dados para aplicação da
métrica, ou seja, realizar a soma dos pontos de cada grupo de defeitos por
itens e obter o total das perguntas válidas;
b) Aplicar a métrica de consistência de acordo com a fórmula definida na
Tabela 5;
53
5. Análise dos resultados: os resultados obtidos com a aplicação da métrica de
consistência devem ser analisados conforme parâmetros definido na seção 5.4
deste estudo. As seguintes atividades compõem esta etapa.
a) Analisar o resultado obtido e registrá-lo;
b) Retornar a atividade 3 e executar as demais atividades até que todos
os casos de uso e seus protótipos sejam inspecionados;
c) Reportar os responsáveis pela especificação de software para que as
devidas correções possam ser realizadas, quando necessário.
Um fluxograma de execução do Método QualiCES pode ser visualizado na
Figura 6.
Fim
Não
Início
Há o desejo pela qualidade?
1
Sim
Não
2a
3c
2b
Documentos ok?
Sim
Sim
3b
Defeitos detectados?
3a
3a
Não
Não
4a
4b
Ainda há documentos para serem
5a
inspecionados?
Sim
5c
Figura 6 - Fluxograma de execução do Método QualiCES.
54
5.2 Checklist
Para a criação do QualiCES foram considerados três documentos de requisitos:
especificação de requisitos, casos de uso e protótipos. Assim, como base de aplicação
do QualiCES, um checklist, para auxiliar na percepção de inconsistências entre os
documentos citados. Através do checklist, é possível buscar por defeitos entre esses
documentos e artefatos e, por consequência, auxiliar o alcance da qualidade de um
software.
Como pode ser visto na Figura 7, o checklist proposto é composto por quatro
partes: 1) o item analisado, 2) o resultado da análise, 3) a classificação do defeito
encontrado, e 4) uma área para justificativa e/ou observações a respeito do item
analisado. O “Item analisado” refere-se ao assunto tratado nas perguntas do checklist. O
“Resultado da análise” refere-se a resposta dada a pergunta realizada. Já “classificação
do defeito” refere-se a alguns itens que devem ser analisado quando um defeito for
detectado. Na “área para justificativa e/ou observação” podem ser escritos comentários
para que se possa entender os defeitos detectados. O documento completo pode ser visto
no Apêndice A deste trabalho.
55
Itens
1
2
3
4
Figura 7 - Trecho do checklist proposto para esse estudo, identificando cada parte sua.
A seguir segue descrita cada uma das partes do checklist proposto.
5.2.1 Itens Analisados
O método desenvolvido não se restringe somente a análise do caso de uso como
Anda e SjØberg (2002) Aurum et al. (2004) e Gregolin (2007) propuseram em seus
estudos, ele busca também detectar inconsistências entre os documentos de
especificação de requisitos.
O checklist proposto é composto por 28 (vinte e oito) perguntas, as quais estão
divididas em cinco itens a serem analisados simultaneamente entre o documento de
requisitos, documento de descrição de caso de uso e protótipo de tela. São eles:
56
• Conteúdo: é responsável por analisar a descrição geral do caso de uso, no
sentido de se alcançar o objetivo proposto e a funcionalidade prevista no
documento de requisitos, tanto por meio do caso de uso, quanto por meio do
protótipo. Além disso, esse item analisa se os dados do dicionário de dados são
seguidos, bem como se os termos utilizados para identificar o objetivo da
funcionalidade são intuitivos. Esse item é composto por quatro perguntas.
• Funcionalidade: é responsável por analisar se tanto o caso de uso quanto o
protótipo
consideram
todos
os
requisitos
funcionais
relacionados
à
funcionalidade descrita no caso de uso, bem como detectar a omissão de algum
requisito e/ou detectar algum requisito que não se aplica ao caso de uso e
protótipo inspecionado. Esse item é composto por sete perguntas.
• Execução da funcionalidade: para que se possa alcançar determinada
funcionalidade do sistema é necessário seguir alguns passos, além de ser
necessário seguir algumas restrições e/ou alternativas. Assim, esse item é
responsável por analisar se os fluxos principais e alternativos, bem como as
restrições de um caso de uso podem ser seguidos no protótipo de tela, além de
analisar se há passos faltantes ou sobrando em ambos os artefatos. Além disso,
são analisados se as pré e pós condições à execução do caso de uso são
consideradas no protótipo. Esse item é composto por nove perguntas.
• Dependência entre funcionalidades: alguns casos de uso necessitam de outros
para completar determinada funcionalidade em um sistema. Assim, esse item é
responsável por analisar se a descrição do caso de uso e o protótipo consideram
relação de include e exclude entre casos de uso. Esse item é composto por quatro
perguntas.
• Usuários: qualquer sistema desenvolvido por ter vários usuários finais
classificados de acordo com suas funções dentro do sistema. Assim, esse item
analisa se todos os usuários/atores foram considerados tanto no caso de uso bem
como no protótipo, além de analisar se seus papéis e responsabilidades foram
respeitados dentro da funcionalidade proposta. Esse item é composto de quatro
perguntas.
57
Por meio desses cinco itens, o checklist proposto investiga as informações
analisadas por Anda e SjØberg (2002) Aurum et al. (2004) e Gregolin (2007), mas
abrangendo requisitos funcionais, casos de uso e protótipos.
Na seção seguinte, são apresentadas algumas regras que auxiliam no processo de
inspeção. Estas regras definem o que seria uma resposta as perguntas que não
encontram qualquer não conformidade.
5.2.1.1 Critérios de avaliação do questionário
Para que cada pergunta relacionada a cada item pudesse ser analisada e por
qualquer pessoa sem que isso acarretasse em má interpretação, fez-se necessário definir
alguns critérios. Para tanto, para cada um dos cincos item do checklist, foram definidas
regras de validação do questionário definidas neste trabalho. Como forma de facilitar o
acesso a essas regras durante a etapa de aplicação do checklist, as regras foram inseridas
no próprio checklist.
5.2.1.1.1 Conteúdo
Regra 1.1 – A descrição do caso de uso deve ser a especificação detalhada do seu
objetivo, de forma a atender as suas funcionalidades previstas. Pergunta relacionada:
1;
Regra 1.2 – O protótipo desenvolvido deve atingir o objetivo do caso de uso por meio
da sua descrição. Pergunta relacionada: 2;
Regra 1.3 – O protótipo deve seguir todas as definições do dicionário de dados descrito
no caso de uso. Pergunta relacionada: 3;
Regra 1.4 – Os títulos dos botões das informações no protótipo deve permitir ao
usuário, intuitivamente, identificar o objetivo do caso de uso e sua respectiva
funcionalidade. Pergunta relacionada: 4.
5.2.1.1.2 Funcionalidade
58
Regra 2.1 – O caso de uso deve descrever todas as funcionalidades desejadas por ele e
pelos Requisitos Funcionais relacionados. Pergunta relacionada: 5;
Regra 2.2 – O caso de uso deve descrever todas as funcionalidades representadas pelo
protótipo. Pergunta relacionada: 6;
Regra 2.3 – O caso de uso deve identificar todos e somente os requisitos funcionais que
realmente se referem a este caso de uso. Pergunta relacionada: 7;
Regra 2.4 – Os requisitos funcionais identificados no caso de uso não devem ser
conflitantes entre si. Pergunta relacionada: 8;
Regra 2.5 – As informações descritas nos requisitos funcionais devem ser as mesmas
informações presentes no caso de uso e no protótipo. Pergunta relacionada: 9;
Regra 2.6 – O protótipo deve seguir todas as informações descritas pelo requisito
funcional correspondente. Pergunta relacionada: 10;
Regra 2.7 – Todos os requisitos funcionais referentes a esse caso de uso devem ser
considerados na sua descrição. Pergunta relacionada: 11.
5.2.1.1.3 Execução da funcionalidade
Regra 3.1 As pré-condições definidas no caso de uso devem ser identificáveis no
protótipo. Pergunta relacionada: 12;
Regra 3.2 – A descrição do caso de uso deve especificar o fluxo principal e alternativo
da forma mais completa possível para que o protótipo permita que cada passo seja
seguido. Perguntas relacionadas: 13 e 16;
Regra 3.3 – Os passos dos fluxos do caso de uso devem ser exatamente os mesmos
passos a serem executados no protótipo. Perguntas relacionadas: 14 e 17;
Regra 3.4 – Todos os passos necessários para atingir o objetivo da funcionalidade
devem ser descritos e representados. Perguntas relacionadas: 15 e 18;
Regra 3.5 – Os fluxos descritos no caso de uso devem ser os únicos permitidos pelo
protótipo. Pergunta: 19;
59
Regra 3.6 – As pós-condições quando muito importantes, devem ser identificadas no
protótipo. Pergunta relacionada: 20.
5.2.1.1.4 Dependência entre funcionalidades
Regra 4.1 – Os relacionamentos entre casos de uso não podem interferir na
compreensibilidade do caso de uso;
Regra 4.2 – Quando um caso de uso depender de outro caso de uso, o caso de uso
incluído deve ser identificado corretamente pelo caso de uso dependente. Perguntas
relacionadas: 21, 22 e 24;
Regra 4.3 – O protótipo de um caso de uso dependente de outro caso de uso deve
considerar o caso de uso incluído. Pergunta relacionada: 23.
5.2.1.1.5 Usuários
Regra 5.1 – Todos os atores que podem interagir com o caso de uso devem ser
corretamente identificados no caso de uso. Pergunta relacionada: 25;
Regra 5.2 – Todos os atores identificados no caso de uso devem ser considerados nos
fluxos do caso de uso e no protótipo. Pergunta relacionada: 26;
Regra 5.3 – O caso de uso e o protótipo deve considerar exatamente o papel dos atores
identificados de acordo com a descrição de cada ator. Perguntas relacionadas: 27 e 28.
5.2.1.2 Resultados possíveis da análise das regras
Por meio das regras descritas na Seção anterior, é possível ter quatro pareceres
finais: sim, não, em partes, e não se aplica.
• Sim: quando a regra definida para a questão analisada for completamente
atendida;
• Não: quando de forma alguma a regra definida para a questão for cumprida;
• Em partes: quando a regra definida for cumprida em partes, isto é, quando ela
foi atendida, porém ainda falta alguma coisa para completá-la;
60
• Não se aplica: quando não for possível responder a pergunta ou por ser
impossível analisar a o pedido, ou por porque alguma outra questão não foi
atendida e por isso as perguntas relacionadas não podem ser respondidas. Devese ter atenção redobrada para esse parecer final, pois ele será importante para a
aplicação da métrica de consistência.
5.2.2 Classificação dos defeitos
O objetivo do QualiCES é identificar defeitos a partir do descumprimento das
regras descritas nas Seção 5.2.1.1. Além disso, para cada defeito encontrado deve-se
considerar quão grave ele é. Para tanto, o método considerar três itens:
1. Objetivo: um defeito pode ou não afetar a implementação de uma
funcionalidade. Quando for percebido algum problema, o revisor deverá
dizer, portanto, se ele afeta (sim ou não) o objetivo do caso de uso e sua
funcionalidade.
•
Sim: Quando o objetivo afetar o usuário, impedindo que ele utilize a
funcionalidade analisada. Exemplos: falta de algum requisito funcional,
não são consideradas determinadas características no papel de um usuário
do sistema;
•
Não: Quando o defeito não afetar o alcance do objetivo da
funcionalidade. Exemplo: diferença entre os atributos de um dicionário
de dados e os atributos identificados no protótipo.
2. Urgência de correção: um defeito difere do outro em diversos itens, e um
deles é em relação a urgência de correção. Assim, quando algum problema
for detectado, a urgência de correção deverá ser analisada. A urgência pode
ser classificada em três níveis. São eles:
•
Curto Prazo: Quando o defeito detectado tem que ser corrigido antes de
iniciar a fase de design do software. Exemplo: requisitos faltantes;
•
Médio prazo: Quando o processo de design de software pode ser
seguido, porém o defeito deve ser consertado antes da implementação.
61
Exemplo: adicionar algum botão que faltou no protótipo porque o caso de
uso não previu essa ação.
•
Longo prazo: Quando o defeito pode ser corrigido durante ou após a
implementação do software. Exemplo: alteração de nome de campos.
3. Importância da funcionalidade: Baseada na perspectiva do usuário, o
defeito detectado deverá ser classificado considerando a importância da
funcionalidade para o usuário, podendo ser:
•
Muito importante: se o defeito encontrado impede que o usuário
execute a funcionalidade. Exemplo: a falta de um requisito;
•
Importante: se a funcionalidade afetar em partes a interação do usuário
com o sistema. Exemplo: a falta de um botão “cancelar”;
•
Pouco importante: se a funcionalidade não afetar em nada a interação
do usuário com o sistema. Exemplo: nomes divergentes entre dicionário
de dados da descrição do caso de uso, e o nome utilizado no protótipo.
Após a detecção dos defeitos e da classificação a partir dos parâmetros acima
descritos, a próxima etapa do QualiCES proposto é aplicar uma métrica de consistência
que permita que os resultados possam ser analisados. Esta métrica é descrita na próxima
seção.
5.3 Métrica
Esta seção tem como objetivo apresentar a métrica desenvolvida para acompanhar
o nível de consistência entre os documentos e artefatos analisados por meio do método
QualiCES.
A métrica de consistência foi desenvolvida para apoiar o método QualiCES e é
composta de três etapas: coleta de dados, análise dos dados e apresentação dos
resultados. O público alvo dela são todos os interessados nos resultados, como
profissionais de qualidade e analista de requisitos. A seguir são descritas as etapas que
constituem a métrica.
62
5.3.1 Coleta de dados
A etapa de coleta de dados destina-se à obtenção dos dados nos quais a métrica
de consistência será aplicada. Assim, seguem descritos os passos para a realização dessa
atividade.
1. Para cada pergunta respondida no checklist que for encontrado algum defeito,
some a pontuação poX obtida em relação aos atributos “atrapalha objetivo”,
“urgência de correção”, e “importância da funcionalidade”, onde X é o número
da pergunta em questão. Essa pontuação é dada considerando a Tabela 2.
Tabela 2 - Definição dos valores para as respostas possíveis.
Atrapalha o alcance do
objetivo
Sim = 1
Curto prazoe = 3
Importância da
funcionalidade
Muito importante = 3
Médio prazo = 2
Importante = 2
Longo prazo = 1
Pouco importante = 1
Urgência da correção
Não = 0
2. Para cada item (conteúdo, funcionalidade, execução da funcionalidade,
dependência entre funcionalidades, e usuários), some a pontuação X (poX) das
perguntas que o constituem, obtendo, assim, pontuação das perguntas
relacionadas ao item conteúdo (poC), a pontuação das perguntas relacionadas ao
item funcionalidade (poF), a pontuação das perguntas relacionadas ao item
execução da funcionalidade (poEF), a pontuação das perguntas relacionadas ao
item dependência entre funcionalidades (poDF) e a pontuação das perguntas
relacionadas ao item usuário (poU).
3. Para cada pontuação de itens obtida anteriormente, multiplique pelo peso
correspondente, para tanto considere a Tabela 3.
Tabela 3 - Pesos referentes a cada item analisado.
Item
Peso (P)
Conteúdo (C)
PC = 0,1
Funcionalidade (F)
PF = 0,3
63
Execução da funcionalidade (EF)
PEF = 0,4
Dependência entre funcionalidades (DF)
PDF = 0,1
Usuários (U)
PU = 0,1
Os pesos definidos na tabela anterior foram obtidos por meio da quantidade de
perguntas existentes em cada item analisado. Para isso, dividiu-se o total de perguntas
de cada item analisado pelo total de perguntas do checklist. Os resultados obtidos foram
aproximados e assim obteve-se os valores da Tabela 3.
PC = 4 perguntas / 28 perguntas = 0,14
PF = 7 perguntas / 28 perguntas = 0,25
PEF = 9 perguntas / 28 perguntas = 0,32
PDF = 4 perguntas / 28 perguntas = 0,14
PU = 4 perguntas / 28 perguntas = 0,14
4. Some a pontuação obtida entre os itens e seus respectivos pesos, e divida o
resultado obtido pelo total de perguntas válidas(TPV), obtendo assim, o
coeficiente de qualidade de consistência (QC). Observe a fórmula a seguir.
QC = (poC*PC + poF*PF + poFE*PFE + poDF*PDF + poU*pU)/TPV.
TPV = TP – TPNA,
onde TPV é o número total de perguntas válidas, TP é o número total de perguntas do
checklist, e TPNA é o total de perguntas não aplicáveis.
5.3.2 Análise dos dados
Após a aplicação da métrica de consistência para cada caso de uso e ao seu
respectivo protótipo, o método proposto prevê que o resultado seja analisado. Assim,
esse estudo considera que a consistência entre os documentos e artefatos analisados
durante a especificação de software é dada seguindo os seguintes valores:
64
•
Consistente: quando o resultado da aplicação da métrica resultar em
resultados menores ou iguais a 0,199;
•
Pouco consistente: quando o resultado da aplicação da métrica resultar em
resultados maiores que 0,3 e menor que 0,699;
•
Inconsistente: quando o resultado da aplicação da métrica resultar em
resultados maiores que 0,7.
Os valores definidos para classificação dos resultados obtidos foram escolhidos
com base na média dos resultados da aplicação do QualiCES (Capítulo 6). São
necessários mais testes para que esses valores possam ser mais sólidos e confiáveis.
Após a análise dos resultados é necessário reportar os responsáveis pela
especificação de software para que as devidas providências de correção sejam tomadas.
5.3.3 Forma de apresentação
Após a aplicação da métrica e da análise dos resultados, faz-se necessário que os
resultados sejam apresentados aos responsáveis. Assim, há duas formas para que essa
atividade possa ser realizada: tabular e gráfica.
1. Tabular: a forma tabular é constituída de uma Tabela formada pelas
colunas, caso de uso, itens, pontuação de cada item, total de perguntas não
aplicáveis (TPNA), qualidade de consistência (QC), e a classificação final.
Para cada checklist preenchido, gere uma entrada na tabela com sublinhas
contendo o nome do caso de uso e cada um dos itens analisados. Para cada
item, coloque ao lado a pontuação obtida. Para o checklist, coloque o TPNA,
QC e a classificação obtida. Observe a Tabela 4 a seguir.
65
Tabela 4 - Modelo de apresentação dos resultados obtidos com a aplicação de 1 checklist.
Identificação
<nome do
caso de uso
ou do
protótipo>
Itens
Pontuação
Conteúdo
<poC>
Funcionalidade
<poF>
Execução da
funcionalidade
<poEF>
Dependência
entre
funcionalidades
<poDF>
Usuários
<poU>
TPNA
TPNA
QC
Classificação
QC
<Consistente
ou Pouco
consistente ou
Inconsistente>
2. Gráfica: para a forma gráfica, monte um gráfico de barras onde o eixo y é o
total de defeitos e o eixo x os itens do checklist. Observer o modelo a seguir.
Essa forma de apresentação deve ser utilizada para apresentar os resultados
considerando todas as aplicações do checklist, apresentando um gráfico
resumo de todos os defeitos detectados. Veja Figura 8 a seguir.
Figura 8 - Modelo gráfico para apresentar os resultados obtidos.
66
No próximo capítulo será descrita a aplicação do método QualiCES em um
estudo de caso, demonstrando a aplicação do checklist e da métrica propostos pelo
método.
67
6
AVALIAÇÃO DO QualiCES
Para mostrar a aplicabilidade do método proposto para avaliação da consistência
entre os documentos e artefatos do processo de especificação de software, ele foi
aplicado em um projeto de pesquisa desenvolvido na UFMT (Universidade Federal de
Mato Grosso).
Nesta seção serão apresentados o projeto utilizado como fonte de dados para a
aplicação do método desenvolvido, os resultados obtidos e os benefícios que o método
QualiCES pode trazer para o processo de desenvolvimento de software.
6.1 Projeto “Social e-Gov”
O projeto conhecido por “Social e-Gov” é um projeto de pesquisa desenvolvido
no Instituto de Computação da UFMT.
O projeto que tem como título “Um Framework para o desenvolvimento de
Aplicações Governamentais e-Participativas na Web” é desenvolvido pelo grupo de
pesquisa Laboratório de Ambientes Virtuais Interativos (LAVI) e objetiva desenvolver
um ambiente customizável para o desenvolvimento de aplicações governamentais eparticipativas na web, utilizando uma estrutura de componentes (MACIEL et al.,2007).
Atualmente é composto por 14 pesquisadores, sendo 7 alunos da iniciação científica, 5
professores da UFMT, e 2 alunos mestrandos, sendo um da Universidade Federal do
Mato Grosso do Sul (UFMS) e outro aluno da Universidade Federal Fluminense (UFF).
O projeto já tem uma duração de aproximadamente de 3 anos e até o momento já
produziu a seguinte documentação do software que se propõe a desenvolver: documento
visão do projeto, o qual contém os requisitos funcionais e não funcionais do sistema a
ser desenvolvido; o documento de interface, o qual descreve os padrões adotados para a
interface da plataforma de governo eletrônico desenvolvida pelo Projeto “Social eGov”, além de conter os casos de uso do sistema; protótipos de tela, os quais são de
baixa fidelidade; e modelagem entidade-relacionamento, o qual auxilia no entendimento
entre os diversos componentes do projeto. Atualmente, o software a ser desenvolvido
pelo grupo de pesquisa encontra-se em estágio de implementação.
68
6.1.1 O problema
O termo Governo Eletrônico tem como princípio a utilização das modernas
TIC’s (Tecnologias de Informação e Comunicação) para democratizar o acesso à
informação, ampliar discussões e dinamizar a prestação de serviços públicos com foco
na eficiência e efetividade das funções governamentais.
Nesse contexto, o Projeto de pesquisa “Social e-Gov” tem como finalidade
colaborar e ampliar a participação dos cidadãos nos assuntos relacionados ao Governo.
Para isso, o grupo tem desenvolvido um framework de componentes, os quais permitem
customização de recursos durante o desenvolvimento de sistemas e-participativos.
6.2 Aplicação do método
Para que o método QualiCES seja aplicado faz-se necessário que haja o desejo e
a busca pela qualidade de software desde o início do processo de desenvolvimento de
software por parte dos envolvidos nesse processo, como propõe a etapa 1 do método
proposto. Assim, com esse desejo e necessidade, o Projeto “Social e-Gov” possibilitou
que o método QualiCES pudesse ser aplicado e testado em seus documentos.
No decorrer dessa Seção, todo o processo de aplicação será descrito, bem como
será descrita a estrutura da documentação obtida para os testes, além dos resultados
obtidos com o método.
6.2.1 Análise dos documentos a serem inspecionados
Conforme definido pelo método QualiCES, os documentos a serem
inspecionados são o documento de requisitos, casos de uso e protótipos de tela
relacionados aos casos de uso. A análise desses documentos levou às seguintes
conclusões:
1. No documento de requisitos do sistema há 23 requisitos funcionais;
2. No documento de requisitos assim como no documento de descrição dos
casos de uso, há quatro classificações de usuários para o sistema: usuário
69
normal autenticado no sistema, moderador, administrador, e usuário
convidado o qual não está validado no sistema;
3. O documento de descrição de casos de uso contém a descrição de 42 casos
de uso;
4. Há somente 17 protótipos criados.
Após a análise dos documentos foi possível aplicar o checklist.
6.2.2 Aplicação do checklist
O checklist proposto foi aplicado pelo autor desta pesquisa que também é um
membro do grupo de pesquisa “Social e-Gov”. Por existirem apenas 17 protótipos,
apensa 17 casos de usos puderam ser analisados. E assim, o checklist foi aplicado
dezessete vezes.
Como resultado da aplicação do checklist, foi possível encontrar inconsistências
em todos documentos analisados. Os itens que mais apresentaram defeitos foram
funcionalidades e execução da funcionalidade. Com relação ao item funcionalidades,
destaque-se que a ausência de algum requisito no documento de especificação de
requisitos, é responsável pela detecção de diversos defeitos, por mais que se refiram ao
mesmo problema.
Na Tabela 5 é possível visualizar as pontuações de grupos de defeitos separados
por itens e por caso de uso, e a quantidade de perguntas não aplicáveis (TPNA) ao caso
de uso inspecionado. Na Tabela 5 é possível visualizar as pontuações de grupos de
defeitos separados por itens e por caso de uso, e a quantidade de perguntas não
aplicáveis (TPNA) ao caso de uso inspecionado.
A próxima seção irá mostrar os resultados da aplicação do checklist por meio da
análise dos dados obtidos com a aplicação da métrica.
6.2.3 Aplicação da métrica de consistência
Com as pontuações por grupos obtidas e com a quantidade de perguntas não
aplicáveis foi possível aplicar a métrica de consistência descrita na seção 5.4 deste
70
estudo. Os resultados obtidos para cada aplicação do checklist podem ser visualizados
na Tabela 5.
Tabela 5 - Resultados obtidos com a aplicação do checklist e da métrica de consistência.
Caso de Uso
Acessar mural de
notícias
Itens
Conteúdo
5
Funcionalidades
0
Execução da
funcionalidade
Dependência entre
funcionalidades
Aprovar
demanda
Conteúdo
11
Funcionalidades
28
Execução da
funcionalidade
biblioteca
Conteúdo
7
Funcionalidades
28
funcionalidade
Dependência entre
localidade
Conteúdo
2
Funcionalidades
0
funcionalidade
funcionalidades
manifestação
Classificação
5
0,143
Consistente
4
0,695
3
0,576
2
0,069
Consistente
6
0,763
Inconsistente
Pouco
consistente
Pouco
consistente
5
0
Dependência entre
Cadastrar
12
Usuários
Execução da
QC
0
0
funcionalidades
Cadastrar
18
Usuários
Execução da
TPNA
0
0
funcionalidades
informação na
7
Usuários
Dependência entre
Cadastrar
Pontuação
4
0
Usuários
0
Conteúdo
12
Funcionalidades
28
Execução da
18
71
funcionalidade
Dependência entre
funcionalidades
Cadastrar
notícia
Usuários
0
Conteúdo
6
Funcionalidades
28
Execução da
funcionalidade
Dependência entre
funcionalidades
Cadastrar
temática
Conteúdo
0
Funcionalidades
0
Execução da
funcionalidade
Conteúdo
10
Funcionalidades
21
funcionalidade
funcionalidades
voluntários a
moderação
Conteúdo
19
Funcionalidades
33
funcionalidade
Dependência entre
29
14
Conteúdo
2
Funcionalidades
0
funcionalidade
0,061
2
0,280
5
1,113
Inconsistente
4
0,141
Consistente
Consistente
Pouco
consistente
8
Usuários
Execução da
2
consistente
0
0
funcionalidades
Enviar convite
0
Usuários
Execução da
0,538
0
0
Dependência entre
Efetivar
4
Usuários
Execução da
Pouco
2
22
0
funcionalidades
biblioteca
7
Usuários
Dependência entre
Cadastrar
0
8
72
Dependência entre
funcionalidades
Usuários
0
Conteúdo
0
Funcionalidades
4
Execução da
Inserir ressalva
funcionalidade
Dependência entre
funcionalidades
Conteúdo
7
Funcionalidades
28
funcionalidade
funcionalidades
Conteúdo
0
Funcionalidades
0
funcionalidade
funcionalidades
demanda
Conteúdo
3
Funcionalidades
2
funcionalidade
funcionalidades
moderador da
demanda
0
0
Conteúdo
0
Funcionalidades
0
funcionalidade
Dependência entre
0,763
2
0,261
6
0,040
1
0,213
Consistente
Inconsistente
Pouco
Consistente
Consistente
0
Usuários
Execução da
6
Pouco
4
20
Dependência entre
Voluntariar-se a
11
Usuários
Execução da
0,279
5
0
Dependência entre
Visualizar
18
Usuários
Execução da
4
4
7
Dependência entre
Opinar demanda
11
Usuários
Execução da
Moderar notícia
0
6
24
Pouco
Consistente
73
funcionalidades
Usuários
0
Conteúdo
0
Funcionalidades
7
Execução da
Votar demanda
funcionalidade
Dependência entre
funcionalidades
Votar pela
liberação da
demanda
4
0
Conteúdo
7
Funcionalidades
28
funcionalidade
Dependência entre
funcionalidades
Usuários
0,148
Consistente
5
0,891
Inconsistente
0
Usuários
Execução da
3
11
0
0
A partir da Tabela 5 pode-se observar a forma de apresentação, definida na
Seção 5.4.3, dos resultados obtidos com a aplicação do checklist. Com os dados
expostos dessa forma, fica claro analisar em qual item encontra-se a maior concentração
de defeitos.
Na próxima seção, serão analisados os resultados da obtidos na Tabela 4.
6.2.4 Análise dos resultados
De acordo com a métrica de consistência proposta neste estudo, a aplicação do
checklist poderia apontar que os documentos e artefatos analisados são consistente,
pouco consistente e inconsistente. A partir dos valores obtidos na Tabela 5, foi possível
elaborar a Tabela 6 que contém a classificação dos resultados analisados.
74
Tabela 6 - Quantidade de defeitos encontrados para cada classificação final da métrica.
Classificação final
Quantidade de defeitos
detectados
Porcentagem
Consistente
6
12
32,73%
Pouco consistente
7
54
43,63%
Inconsistente
4
44
23,64%
17
110
100%
Nível de consistência
TOTAL
A Tabela 6 mostra que das 17 aplicações do checklist, apenas 6 casos de uso
com seus respectivos protótipos e requisitos são coerentes na funcionalidades que
representam. Os demais, ou são pouco consistente, ou exigem total análise para buscar a
consistência.
A Tabela 6 ainda mostra a quantidade de defeitos detectados por meio da
aplicação dos 17 checkllist, 110 no total. Como era de se esperar, os casos pouco
consistentes e inconsistentes apresentaram mais defeitos, representando juntos, quase
70% dos defeitos detectados no total.
Quando o nível de consistência obtido é analisado considerando a quantidade de
erros obtidos em cada item, percebe-se que a maior concentração de erros encontra-se
nos itens funcionalidade e execução da funcionalidade, como pode ser visto na Figura 9.
Provavelmente, esse grande número deve-se à falta de uma especificação de requisitos
mais completa.
Portanto, com a aplicação do método QualiCES foi possível perceber as
melhorias que devem ser realizadas no software em desenvolvimento pelo grupo de
pesquisa “Socail e-Gov”.
75
Figura 9 - Quantidade de defeitos detectados por itens para cada nível de consistência definido
pela métrica de consistência.
Na próxima seção, é feita uma análise a respeito do método QualiCES após a sua
validação por meio de um estudo de caso.
6.2.5 Análise do Método QualiCES
O QualiCES proposto neste trabalho tem por objetivo inspecionar documentos e
artefatos de software ainda na fase de especificação de software com intuito de analisar
a consistência entre esses documentos. Para isso, o método proposto apoiou-se em um
checklist desenvolvido para esse a fim, e analisou os resultados a partir de uma métrica
de consistência também proposta para esse trabalho.
Para esse estudo considerou-se que o método desenvolvido enquadra-se como
uma forma de inspeção de software, que por sua vez pertence ao processo de validação
e verificação de software.
Como mencionado na Seção 2.2, o processo de V & V é uma das formas de
garantir a qualidade de software. Neste sentido, com a aplicação do método QualiCES,
alguns atributos de qualidade puderam ser analisados: completude, consistência interna,
alcançabilidade, rastreabilidade, corretude e precisão. Enquanto Gregolin (2007) adapta
76
esses atributos para qualidade de caso de uso, e Jani (2010) os adaptam para qualidade
de requisitos. Para este trabalho foram considerados os seguintes atributos:
• Completude: tudo que a funcionalidade deve fazer deve ser descrito tanto pelo
caso de uso quanto representado pelo protótipo, além de ter todas as informações
necessárias no requisito funcional correspondente;
• Consistência Interna: os requisitos funcionais, casos de uso e protótipos não
podem conflitar entre si;
• Alcançabilidade: o protótipo relacionado ao caso de uso deve acompanhar toda
a sua descrição e a especificação do requisito funcional;
• Rastreabilidade: cada requisitos e caso de uso devem ser corretamente
identificados para que possam ser rastreáveis;
• Corretude: a funcionalidade representada pelo caso de uso e pelo protótipo
deve representar exatamente o que a funcionalidade deve fazer, a qual deve ser
exatamente especificada pelo requisito funcional;
• Precisão: Os requisitos funcionais e casos de usos devem ser precisamente
descritos a fim de garantir a alcançabilidade por parte do protótipo.
As regras descritas na Seção 5.3.1.1 foram relacionadas aos atributos
anteriormente descritos. O resultado é apresentado na Tabela 7.
Tabela 7- Atributos de qualidade e regras do QualiCES.
Atributos de Qualidade detectados com a métrica de consistência
definida neste estudo
Completude
Regra 1.1
Regra 3.1
Regra 1.3
Regra 3.2
Regra 2.2
Regra 3.3
Regra 2.4
Consistência Interna
Alcançabilidade
Regra 2.3
Regra 5.2
Regra 1.2
Regra 1.3
Regra 2.1
Regra 2.4
Regra 3.1
Regra 3.23
77
Regra 5.2
Rastreabilidade
Corretude
Precisão
Regra 2.1
Regra 2.2
Regra 1.1
Regra 1.2
Regra 2.1
Regra 2.2
Regra 2.4
Regra 3.1
Regra 1.1
Regra 1.3
Regra 2.1
Regra 2.2
Regra 2.4
Regra 3.1
Regra 3.2
Regra 3.3
Regra 4.1
Regra 5.2
Como pode ser visto, todos os atributos são cobertos por mais de uma regra.
Assim, é possível afirmar que o uso do checklist auxilia no processo de garantia de
qualidade de software.
78
7
CONSIDERAÇÕES FINAIS
Em tempos em que informatizar o conhecimento humano tornou-se necessário, o
desenvolvimento de software com mais rigor e qualidade também se tornou necessário.
A busca e o desejo por qualidade de software podem ser alcançados e supridos por meio
de diversas técnicas que apoiam nesse processo.
O desenvolvimento de software, na sua forma mais simplista, é composta pelas
fases de especificação de software, design e implementação de software e pela
validação do software. Muitos estudos relatam que deixar o processo de validação e
verificação de software somente para o final do processo acaba exigindo um custo e
esforço maior para consertar os defeitos que possam surgir.
Esse trabalho mostrou que a busca de qualidade deve ocorrer desde o inicio do
ciclo e vida de desenvolvimento de software. Concentrou-se no desenvolvimento de um
método chamado QualiCES, que deve ser aplicado na fase de especificação de software.
Diversas técnicas que apoiam o processo de inspeção de software foram
identificadas durante a pesquisa bibliográfica. Essas técnicas foram avaliadas em termos
de eficácia e efetividade por meio da comparação entre elas.
Além disso, foi notado que na literatura analisada, os estudos prezavam por analisar
a qualidade por meio das técnicas de inspeção de software, na sua grande maioria, como
foi relatado na seção 3.1 deste trabalho. Estas técnicas, entretanto avaliavam apenas a
qualidade dos casos de uso.
Portanto, sentiu-se falta de estudos que analisassem a consistência entre os
documentos e artefatos, que encontrasse defeitos e que prezasse pela qualidade de
software desde o início do processo de desenvolvimento.
Com esse objetivo, foi proposta, o QualiCES, um método para verificação de
software avalia a consistência entre os documentos e artefatos ainda na fase de
especificação de software.
Assim, o restante desde capítulo está organizado da forma que se segue.
79
A seção 7.1 apresenta os resultados obtidos em relação ao que foi proposto para
esse trabalho. Já a seção 7.2 discute as limitações e propõe trabalhos futuros
relacionados a este.
7.1 Resultados Obtidos
Diante da atual preocupação existente pela garantia da qualidade de software, este
estudo propôs um método, o QualiCES, o qual por meio da detecção de defeitos e por
meio da análise da consistência entre documentos e artefatos relacionados ao processo
de
especificação
de
software,
pudesse
trazer
qualidade
ao
software
em
desenvolvimento.
Este estudo como alguns outros identificados na literatura, consideram que
defeitos detectados logo no início do processo da especificação do software diminuem
os custos e os esforços por dimuírem o retrabalho nas fases posteriores do
desenvolvimento de software. Dessa forma, auxilia-se a obtenção de qualidade desde o
começo da vida do software.
O método QualiCES propõe uma sequência de passos alinhados com as fases de
desenvolvimento de software deve ser aplicado na fase de especificação de software.
Ele objetiva analisar a consistência entre documentos e artefatos de software nessa fase
do desenvolvimento.
Para tanto, o método propõem um checklist, que torna a avaliação mais
independente de pessoas. O checklist proposto analisa cinco itens (conteúdo,
funcionalidade, execução da funcionalidade, dependência entre funcionalidades e
usuários) que relacionam o documento de requisitos, descrição de casos de uso e
protótipos de tela como forma de verificar a consistência entre eles.
Além disso, o método propõe uma métrica de consistência, a qual se baseia em
dados obtidos por meio da aplicação do checklist e sempre que uma regra de
consistência não estiver em conformidade.
Os defeitos detectados são classificados e analisados em três itens: defeito
atrapalha o alcance do objetivo da funcionalidade (sim ou não), urgência de correção do
80
defeito (imediatamente, médio prazo e curto prazo) e importância da funcionalidade na
perspectiva do usuário (muito importante, importante e pouco importante).
Com a obtenção desses dados, é possível realizar a classificação em consistente,
pouco consistente e inconsistente, baseando-se em valores definidos pelo método
QualiCES.
O método proposto ainda propõe uma forma de, claramente, mostrar os
resultados da inspeção.
Para que o método QualiCES proposto neste estudo pudesse ser testado e
analisado, foram utilizados documentos de requisitos, descrição de casos de uso e de
protótipos de tela do software em desenvolvimento pelo grupo de pesquisa “Social eGov” desenvolvida por um grupo da UFMT.
A aplicação do método QualiCES diz que para cada caso de uso e protótipo
correspondente, deve-se aplicar o checklist proposto uma vez. Assim, de acordo com a
documentação tida em mãos, o checklist foi aplicado 17 vezes e, para cada uma, a
métrica de consistência, também proposta por esse estudo, foi aplicada, resultando na
classificação de consistência dos documentos e artefatos analisados(consistente, pouco
consistente e inconsistente).
Dos 17 casos analisados, seis mostraram-se consistente, sete pouco consistente e
quatro inconsistente. Quando analisado a quantidade de defeitos detectados em cada
classificação, nos seis casos consistentes, doze defeitos foram encontrados; nos sete
pouco consistente, cinquenta e quatro defeitos foram detectados; e nos quatro
inconsistentes, quarenta e três defeitos foram encontrados.
Contudo, além da detecção de defeitos, como era desejado, o método proposto
mostrou apoiar o processo de garantia de qualidade. Assim, por meio do checklist
desenvolvido nesse estudo, diversos atributos de qualidade de software puderam ser
contemplados: completude, consistência interna, alcançabilidade, rastreabilidade,
corretude e precisão.
Dentro do que foi proposto nos objetivos deste estudo e por meio do estudo de
caso realizado, conclui-se que eles foram alcançados: foi definido um método de
81
validação e verificação para a fase de especificação de requisitos, inspeção de software;
foi definido um método de avaliação que apoiasse o processo de validação e
verificação, o QualiCES; e foram desenvolvidos um checklist e uma métrica de
consistência que auxiliassem na aplicação do método e análise dos dados obtidos com a
aplicação do checklist, respectivamente.
7.2 Limitações e Trabalhos Futuros
Esse estudo, conforme definido na Seção 1.3 deste trabalho, limitou a aplicação
do método QualiCES em apenas um caso. Dessa forma, este é um estudo inicial que
carece de mais testes para que, tanto o checklist quanto a métrica de consistência
possam ser validados e comprovados, além de serem melhorados. Estes outros estudos
irão calibrar os valores QC da métrica de consistência desenvolvida neste trabalho.
Além disso, é necessário que outros revisores utilizem o método como forma de
validar o método bem como analisar o entendimento deles na aplicação do checklist e
da métrica desenvolvidos.
Assim, trabalhos futuros espera-se, portanto, i) realizar mais experimentos em
outros projetos, e ii) analisar a aplicação do método por parte de outros revisores.
Ainda, pode ser considerado como trabalho futuro, o desenvolvimento de uma
ferramenta que automatize o método QualiCES, auxiliando na aplicação e análise dos
resultados desse processo.
Esse trabalho restringiu-se a inspeção da fase de especificação de software.
Assim, como trabalho futuro, deseja-se que eo método de inspeção seja adaptado para a
análise de consistência entre os documentos e artefatos de software relacionados aos
requisitos não funcionais, mais especificamente na área de usabilidade e acessibilidade,
analisando a interação humano-computador.
82
8
REFERÊNCIAS BIBLIOGRÁFICAS
ANDA, Bente, SJØBERG, Dag I. K., Towards na Inspection Technique for Use
Case Models. SEKE’02 -14th IEEE Conference on Software Engineering and
Knowledge Engineering, Ischia, Italy, July 15-19, 2002, pp. 127-134.
AURELIO,
Dicionário
Aurelio
Disponível
Online.
em:
<http://www.dicionariodoaurelio.com> Acessado em 09/11/2011.
AURUM, A., COX, K., JEFFERY, R., An Experiment in Inspection the Quality of
Use Case Descriptions. Journal or Research and Practice in Information Technology,
Vol. 36, No. 4, November 2004.
BARTIÉ, A. Garantia da Qualidade de Software: as melhores práticas de
engenharia de software aplicada a sua empresa. Rio de Janeiro, RJ: Campus
Elsevier, 2002. p. 06.
BELGAMO,A., FABBRI, S., MALDONADO, J. C., TUCCA: Improving the
Effectiveness of Use Construction and Requirement Analysis. Empirical Software
Engineering, 2005. 2005 International Symposium on , vol., no., pp. 10 pp., 17-18 Nov.
2005.
GPS, Grupo de Processos de Software do Cercomp, Manual de Produção de software
do
Cercomp.
2010.
Disponível
em:
<http://www.cercomp.ufg.br//uploads/files/17/manual.pdf>, Acessado em: 10/11/11
DELAMARO, E., MALDONADO, J.C., JINO, M. Introdução ao teste de software.
Rio de Janeiro, RJ: Campus Elsevier, 2007.
ELBERZHAGER, F., MÜNCH, J., FREIMUT, B., Optimizing Cost and Quality by
Integrating Inspection and Test Processes. Waikiki, Honolulu, HI, USA. ACM 2011.
GALIN, Daniel. Software Quality Assurance – From Theory to Implementation.
England : Person Adisson-Wesley, 2004.
83
GREGOLIN, Rosângela, Uma proposta de inspeção de em modelos de caso de uso.
São Paulo, 2007. Dissertação de mestrado. Instituto de Pesquisas Tecnológicas do
Estado de São Paulo.
GUSEV, Grigory,
Practical Review of Software Requirements. Software
Engineering Conference (CEE-SECR), 2010 6th Central and Eastern European , vol.,
no., pp.185-188, 13-15 Oct. 2010.
IEEE, IEEE Std 610.12-1990 – IEEE Standard Glossary of Software Engineering
Terminology, Corrected Edition, em IEEE Software Engineering Standards Collection,
The Institute of Electrical and Electronics Engineers, New York. 1991.
IEEE. IEEE Std 1028-1997 – IEEE Standard for Software Reviews, in IEEE
Software Engineering Standards Collection, The Institute of Electrical and
Electronics Engineers, New York, 1997.
IEEE. IEEE Std 610.12-1990 – IEEE Standard Glossary of Software Engineering
Terminology, in IEEE Software Engineering Standards Collection, The Institute of
Electrical and Electronics Engineers, New York, 1990.
ISO. ISO 9000-3:1997(E), Quality Management and Quality Assurance Standards
– Part 3: Guidelines for the Application of ISO 9001:1994 to the Development,
Supply, Installation and Maintenance of Computer Software, 2nd edn. International
Organization for Standardization (ISO), Geneva, 1997.
ISO/IEC. ISO 9000-3:2001 Software and System Engineering – Guidelines for the
Application of ISO 9001:2000 to Software, Final draft, International Organization
for Standardization (ISO), Geneva, unpublished draft, December 2001.
JANI, Haja Mat, Applying Case-Based Reasoning to Software Requirements
Specifications Quality Analysis System, Software Engineering and Data Mining
(SEDM), 2010 2nd International Conference on , vol., no., pp.140-144, 23-25 June
2010.
MACIEL, Cristiano; NOGUEIRA, José Luiz Thomaselli; GARCIA, Ana Cristina
Bicharra. g-Quality: um método para avaliação da qualidade dos sítios de e-Gov.
84
In: VIII ESCOLA DE INFORMÁTICA DO SBC -CENTRO-OESTE, 2005, Cuiabá.
SUCESU-MT. Cuiabá: PAK Multimidia, 2005.
MACIEL, C.; ROQUE, L.; GARCIA, A. C. B., Design and Metrics of a Democratic
Citizenship community in Support of Deliberative Decision-Making. Lecture Notes
in Computer Science, v. 4656, p. 388-400, 207.
MAIA, J. R. C. Garantia a Qualidade de Projeto Orientado a Objeto. Project
Management
Institute.
Santa
Catarina,
2003.
Disponível
em:
<http://www.euax.com.br/system/attachments/4/original/2006.013Metricas_software.pdf?1265047553> Acessado em: 10/09/2011.
MELO, Silvana M., Inspeção de Software. USP: São Carlos, SP, 2009. Disponível em:
<http://moodle.stoa.usp.br/file.php/559/InspecaoArtigo.pdf?forcedownload=1>
Acessado em: 15/09/2011.
MENDES, Fabiana Freitas. Melhoria de Processos de Tecnologia da Informação
Multi-Modelo. Goiânia, 2010. Dissertação de Mestrado. Instituto de Informática,
Universidade Federal de Goiás.
MPS.BR. MPS. BR – Guia de Melhoria de Processo do Software Brasileiro. 2011.
Disponível
em:
<http://softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_4_2011.
pdf>, Acessado em: 10/11/2011.
NBR ISO/IEC 9126-1 Engenharia de Software – Qualidade de Produto. 2003.
NETO, A. C. D., Artigo Engenharia de software – Introdução a Teste de Software.
DevMedia,
2009.
Disponível
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=8035>,
em:
Acessado
em:
03/11/2011.
NIELSEN, Jakob; MACK, R. L.; Usability Inspection Method, 1994.
POHL, K., Requirement Engineering. Springer – Verlag Berlin Heidelberg 2010.
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.
85
PRESSMAN, R. S., Software Engineering – A Practitioner’s Approach, 5º ed.
McGraw-Hill International, London. 2000.
SOCIAL E-GOV a, Projeto. Documento de Interface. Cuiabá, MT.2010
_______________. Documento de Visão. Cuiabá, MT.2010
_______________. Protótipos de Tela. Cuiabá, MT.2010
SOMMERVILLE, I. Engenharia de Software São Paulo, SP: Pearson AdissonWesley, 2007.
SWEBOK, Software Engineering Body of Knowledge IEEE Computer Society, 2004.
Disponível em: <http://www.computer.org/portal/web/swebok/htmlformat> Acessado
em: 19/05/2011.
THELIN, T., RUNESON, P., WHOLIN, C., An Experimental Comparison of UsageBased and Checklist Reading. IEEE Transictions on Sofware Engineering, vol.29, no
8, August 2003.
86
APÊNDICE A - Checklist QualiCE
O modelo checklist utilizado no método QualiCES é apresentado na Tabela 8.
Este checklist foi aplicado em 17 casos de uso e 17.
Tabela 8 - Checklist proposto para o método QualiCES.
Componente:
Caso de Uso:
Protótipo:
Subcomponente:
N
1
Conteúdo
A descrição do
UC atende o seu
objetivo?
A descrição do Caso
de Uso deve ser a
especificação
detalhada do seu
objetivo, de forma a
atender
as
suas
funcionalidades
previstas.
É possível, por
meio do uso do
protótipo
sugerido, atingir
o objetivo do caso
2 de uso (por meio
da
descrição)?
O
protótipo
desenvolvido
deve
atingir o objetivo do
Caso de Uso por meio
da sua descrição.
Não se aplica
Não
Sim
Itens
analisados/Perguntas
Em partes
Conclusão
Atrapalha o
alcance do
objetivo?
(sim ou
não)
Qual a
Qual a
importância
urgência da
da
correção?
funcionalidad Justificativas
(imediatame
e? (muito
/Observaçõe
nte, médio
importante,
s
prazo ou
importante,
curto prazo)
pouco
importante)
87
Para
cada
atributo definido
no dicionário de
dados do UC, é
respeitado
seu
tipo,
máscara,
domínio,
3 tamanho
e
atributos
no
protótipo?
O protótipo deve
seguir
todas
as
definições
do
Dicionário de Dados
descrito no Caso de
Uso.
Os rótulos de
botoes
das
informações nos
protótipos
permitem
intuitivamente
identificar
a
intenção do UC?
Os títulos dos
4
botões
das
informações
no
protótipo
deve
permitir
ao
usuário,
intuitivamente,
identificar
o
objetivo do Caso
de Uso.
Funcionalidade
As
funcionalidades
representadas no
protótipo, são as
funcionalidades
representadas
requisitos
5 pelos
relacionados ao
UC?
O Caso de Uso deve
descrever todas as
funcionalidades
desejadas por ele e
pelos
Requisitos
88
Funcionais
relacionados
Há
alguma
funcionalidade
representada no
protótipo que não
foi descrita no
6
UC?
O Caso de Uso deve
descrever todas as
funcionalidades
representadas
pelo
protótipo.
Há
requisitos
identificados
nesse UC que não
se referem a este
Caso de Uso?
Todos
os
requisitos
identificados
7
nesse
UC
se
referem a este
Caso de Uso?
O Caso de Uso deve
identificar todos e
somente os requisitos
funcionais
que
realmente se referem a
este caso de uso.
Há contradição
entre
os
requisitos
relacionados ao
8 UC?
Os
requisitos
funcionais
identificados no caso
de uso não devem ser
conflitantes entre si.
89
Todas
informações
necessárias para
o
UC
foram
descritas
nos
requisitos
9 funcionais?
As
informações
descritas
nos
requisitos funcionais
devem ser as mesmas
informações presentes
no caso de uso e no
protótipo.
Todas
as
informações
descritas
nos
requisitos
funcionais foram
seguidas
no
10
protótipo?
O protótipo deve
seguir
todas
as
informações descritas
pelo
requisito
funcional
correspondente.
Todos
os
requisitos
funcionais
referentes a esse
UC
foram
11 atendidos?
Todos os requisitos
funcionais referentes a
esse caso de uso
devem
ser
considerados na sua
descrição.
Execução da funcionalidade
As pré-condições
do UC foram
consideradas no
protótipo?
12 As
pré-condições
definidas no caso de
uso
devem
ser
identificáveis
no
protótipo.
Qual(is)?
90
É
possível
executar cada um
dos passos do
fluxo
principal
utilizando-se do
protótipo
definido?
13 A descrição do caso
de
uso
deve
especificar o fluxo
principal e alternativo
da
forma
mais
completa
possível
para que o protótipo
permita que cada
passo seja seguido.
Durante
a
inspeção do UC e
do
protótipo,
todos os passos
apresentados pelo
protótipo foram
14 descritos no fluxo
principal?
Os passos dos fluxos
do Caso de Uso devem
ser exatamente os
mesmos passos a
serem executados no
protótipo.
Há algum passo
faltante que não
foi
identificado
nem no fluxo
principal nem no
15 protótipo?
Todos
os
passos
necessário
para
atingir o objetivo da
funcionalidades devem
ser
descritos
e
representados.
É
possível
executar cada um
dos passos do
fluxo alternativo
16 utilizando-se
do(s) protótipo(s)
definido(s)?
A descrição do caso
de
uso
deve
91
especificar o fluxo
principal e alternativo
da
forma
mais
completa
possível
para que o protótipo
permita que cada
passo seja seguido.
Durante
a
inspeção do UC e
do
protótipo,
todos os fluxos
alternativos e/ou
restrições
possíveis foram
17 descritas no fluxo
alternativo
do
caso de uso?
Os passos dos fluxos
do Caso de Uso devem
ser exatamente os
mesmos passos a
serem executados no
protótipo.
Há algum passo
faltante que não
foi
identificado
nem no fluxo
alternativos nem
18 no
protótipo?
Todos
os
passos
necessário
para
atingir o objetivo da
funcionalidades devem
ser
descritos
e
representados
Os
fluxos
documentados no
UC são os únicos
permitidos
na
interação
descrita
19
no
protótipo?
Os fluxos descritos no
caso de uso devem ser
os únicos permitidos
pelo protótipo.
92
As
ações
decorrentes das
pós-condições do
UC
são
perceptíveis
no
20
protótipo?
As
pós-condições
quando
muito
importantes,
devem
ser identificadas no
protótipo.
Dependência entre funcionalidades
O UC depende de
outro
UC
(include)?
Quando um caso de
uso depender de outro
21 caso de uso, o caso de
uso incluído deve ser
identificado
corretamente
pelo
caso
de
uso
dependente.
Se há include, o
nome do UC
chamado
está
correto?
Quando um caso de
22 uso depender de outro
caso de uso, o caso de
uso incluído deve ser
identificado
corretamente
pelo
caso
de
uso
dependente
23
Se há include, o
protótipo
considera
as
ações do UC
incluído?
O protótipo de um
caso
de
uso
dependente de outro
caso de uso deve
considerar o caso de
uso incluído.
Qual(is)?
93
Se não há include,
deveria
existir
alguma relação
com outro UC?
Quando um caso de
24 uso depender de outro
caso de uso, o caso de
uso incluído deve ser
identificado
corretamente
pelo
caso
de
uso
dependente.
Usuários
Os
diferentes
grupos
de
usuários
que
possam vir a
utilizar o sistema
foram
25 considerados no
UC?
Todos os atores que
podem interagir com o
caso de uso devem ser
corretamente
identificados no caso
de uso.
Os
diferentes
grupos
de
usuários
que
possam vir a
utilizar o sistema
são identificáveis
26
no
protótipo?
Todos
os
atores
identificados no caso
de uso devem ser
considerados
nos
fluxos do caso de uso
e no protótipo.
O nome do ator
reflete seu papel
no
UC?
O caso de uso e o
protótipo
deve
27 considerar exatamente
o papel dos atores
identificados
de
acordo
com
a
descrição de cada
ator.
Qual(is)?
94
O nome do ator
reflete seu papel
no
protótipo?
O caso de uso e o
protótipo
deve
28 considerar exatamente
o papel dos atores
identificados
de
acordo
com
a
descrição de cada
ator.