UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAO DE ENSINO EM GRADUAO EM CINCIA DA COMPUTAO

QualiCES UM METDO PARA GARANTIA DA QUALIDADE DE SOFTWARE NA FASE DE ENGENHARIA DE REQUISITOS

LU MARCELO MURIANA

CUIAB MT 2011

UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAO DE ENSINO EM GRADUAO EM CINCIA DA COMPUTAO

QualiCES UM METDO 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 Cincia da Computao da Universidade Federal de Mato Grosso, para obteno do Ttulo de Bacharel em Cincia da Computao.

CUIAB MT 2011

DEDICATRIA

minha me 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 no nada fcil. Chegar a um momento como esse com toda certeza um sonho que muitos tem, porm poucos tem o privilgio de alcan-lo. Eu estou vivendo esse privilgio! Chegar ao to esperado momento da concluso de um curso de nvel superior foi possvel graas a diversas pessoas que acreditaram em mim, as quais me incentivaram em momentos de dificuldades e me apoiaram nas decises que tomei. No meu caso, estar vivenciando esse momento vai muito alm 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, impossvel no voltar no tempo e perceber que tudo poderia ter sido diferente, e que tudo poderia nem ter sido. O ano era 1993... uma criana normal que brincava, fazia suas mulecagens e tinha fome de aprender foi diagnosticado com Leucemia Mieloide Aguda. Uma simples criana com uma doena destruidora dentro de si. Desespero! Angustia! Medo! O ano era 1994... no dia 27 de janeiro, ao terminar o transplante o mdico se virou minha me e disse: Parabns Me, 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 sade para ser mimado, um afilhado que pudesse desfrutar do prazer de viver e um primo que pudesse colaborar nas bagunas e nas artes de crianas, fez que com todos se unissem nessa guerra contra as clulas do mal. Sade! 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 privilgio de chegar a esse momento da minha vida. Primeiramente, quero agradecer a eles que so a razo desse momento que estou vivendo: minha me, 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 sentenas de morte. Quero agradecer por terem sido fortes

aguentando as dificuldades e sacrifcios necessrios. Por acreditarem no conhecimento e assim, por terem me proporcionado uma oportunidade de estudo com qualidade tambm 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. Me, Pai, pela vida e pela oportunidade de estudo e de me tornar homem, MUITO OBRIGADO! Uma outra pessoa especial que no posso deixar de agradecer minha irm, Tayara. Desde pequena, quando era uma simples criana de 2 anos, j se mostrava ser uma pessoa de corao grande. Sem ao menos entender o que estava acontecendo, foi compreensvel e aceitou a ausncia 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 avs, Fernando e Vilan, Joo e Nena por terem me agradado sempre e por terem cuidado de mim quando necessrio. A v Vilan quero agradecer pelas horas de dedicao ao meu tratamento da leucemia, e a toda preocupao, cuidados e dedicao 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 So Paulo para tratamento do cncer. A vocs, avs, MUITO OBRIGADO! A minha tia Ilca quero dizer o meu obrigado por toda dedicao durante o meu tratamento, pelo conforto dado aos meus pais quando necessrio e por no ter medido esforos para que o seu sobrinho sobrevivesse. Quero agradecer ainda pelo amizade que se formou nesses anos e por todas palavras amigas sempre que necessrio. Tia, MUITO OBRIGADO! Tia Ivete, a voc agradeo pelo esforo de agilizar as coisas necessrias, aqui em Cuiab, para que eu pudesse ir fazer o meu tratamento em So Paulo. Agradeo 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 necessrio, e por todos os momentos que juntos passamos nesses anos. Com toda certeza, isso foi fundamental para essa vitria. Tia, MUITO OBRIGADO! minha tia Eliana quero agradecer, principalmente, por ter cuidado da minha irm para que minha me 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 necessrios. Tia, MUITO OBRIGADO! Minha Madrinha tambm merece todo o meu agradecimento. Muitas vezes ajudou nos cuidados com minha irm e tambm, muitas vezes deixou casa, filhos e marido para ir a So Paulo cuidar de mim. Madrinha, MUITO OBRIGADO! Ainda tem meus primos, os quais tambm compreenderam a situao e aceitaram a ausncia de suas mes para que elas pudessem viajar e cuidar de mim. Alm disso, quero agradecer aos que eu morei junto aqui em Cuaib. A vocs, MUITO OBRIGADO! E por fim, agradeo 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 mdicos foram de extrema importncia. Quero agradecer a todos os mdicos que cuidaram de mim e ousaram na minha cura, permitindo assim, que eu vivesse e hoje, escrevesse essas linhas de agradecimento. A vocs, MUITO OBRIGADO! Mesmo sendo to pequeno e no entendo as consequncias e os porqus 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 no estando perto de mim, com toda certeza sero 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! Aps todos os procedimentos necessrios e com a cura alcanada, a fome pela aprendizagem voltou. Diversos anos de estudos e aprendizados, ensino fundamental, ensino mdio e ensino superior. Curso de ingls, aulas de msica 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 lpis, 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 Cincia da Computao por todo o conhecimento transmitido,

e, principalmente, por ajudarem na minha preparao para vida. A vocs que estiveram dispostos a tirar dvidas e ensinar, que compreenderam muitas vezes a situao de ns alunos, MUITO OBRIGADO! Em especial quero agradecer ao professor Cristiano por ter me mostrado que computao no somente linhas de cdigo, e por ter despertado em mim uma esperana nos estudos que no havia mais. Quero te agradecer ainda, professor, pelas palavras de incentivo quando desanimei durante o meu TCC, pelos puxes de orelha quando necessrio, e principalmente, por ter, brilhantemente, me orientado na monografia. A voc, Prof. Cristiano, MUITO OBRIGADO! A professora Fabiana, quero agradecer em especial tambm por toda dedicao na correo dos meus trabalhos, pela brilhante co-orientao do meu TCC, e por no ter medido esforos 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 esto sempre ao meu lado acompanhando minhas vitrias e tambm minhas dificuldades, que agora eu quero agradecer, como forma de demonstrar meu carinho, minha ternura e minha amizade. Amigos... A Fernanda, minha irm de corao, agradeo pela amizade durantes esses 17 anos que nos conhecemos, pelas palavras amigas, por compartilhar meus segredos, minhas preocupaes, 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 vocs 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 vocs; por terem alegrado minha vida nesses ltimos anos e fazerem toda diferena, MUITO OBRIGADO! Brunno, meu irmo, 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 tambm. 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 tambm, dividindo momentos de funk deluxe. Maaaaaarih, MUITO OBRIGADO! E a todos os outros amigos que esto sempre somando and shinying comigo, MUITO OBRIGADO! E por fim, quero agradecer a Deus por terem colocado as pessoas certas em meu caminho: os mdicos que foram responsveis pelo meu tratamento; minha famlia que participou junto na batalha da vida contra o cncer; 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 esto sempre ao meu lado. Deus, MUITO OBRIGADO! Assim, hoje quero compartilhar mais essa vitria com cada um de vocs, e reconhecer que isso se deve muito a vocs. Por isso, a todos eu digo: MUITO OBRIGADO!

Quem luta celebra vitria!

Ir. Lucinda Facchini

SUMRIO

LISTA DE ABREVIAES.......................................................................................................................7 LISTA DE FIGURAS..................................................................................................................................8 LISTA DE TABELAS.................................................................................................................................9 RESUMO....................................................................................................................................................16 ABSTRACT................................................................................................................................................17 1 INTRODUO .............................................................................................................................. 18 1.1 1.2 Justificativa .............................................................................................................................. 18 Objetivos .................................................................................................................................. 19 Objetivo geral .................................................................................................................. 19 Objetivos especficos ....................................................................................................... 20

1.2.1 1.2.2 1.3 1.4 2

Metodologia ............................................................................................................................. 20 Organizao do trabalho ........................................................................................................... 21

ENGENHARIA DE SOFTWARE ................................................................................................ 22 2.1 Especificao de Software........................................................................................................ 23 Requisitos ........................................................................................................................ 24 Casos de uso .................................................................................................................... 25 Prottipos......................................................................................................................... 26

2.1.1 2.1.2 2.1.3 2.2

Validao de software .............................................................................................................. 26 Inspeo de Software ....................................................................................................... 29 Teste de Software ............................................................................................................ 28 Falhas x Erros x Defeitos ................................................................................................. 30

2.2.1 2.2.2 2.2.3 3

QUALIDADE DE SOFTWARE ................................................................................................... 33 3.1 3.2 3.3 Qualidade de Requisitos ........................................................................................................... 34 Qualidade de Casos de Uso ...................................................................................................... 36 Tcnicas de Inspeo ................................................................................................................ 37 Tcnica baseada em Checklist ......................................................................................... 38 Tcnica baseada na deteco de defeitos ......................................................................... 39 Tcnica baseada em perspectivas .................................................................................... 40 Tcnica baseada no uso ................................................................................................... 40

3.3.1 3.3.2 3.3.3 3.3.4 4

TRABALHOS CORRELACIONADOS ...................................................................................... 43 4.1 Pressupostos para elaborao do checklist ............................................................................... 48

MTODO QualiCES ..................................................................................................................... 51 5.1 5.2 O mtodo .................................................................................................................................. 51 Checklist ................................................................................................................................... 54 Itens Analisados ............................................................................................................... 55

5.2.1

5.2.2 5.3

Classificao dos defeitos ................................................................................................ 60

Mtrica ..................................................................................................................................... 61 Coleta de dados................................................................................................................ 62 Anlise dos dados ............................................................................................................ 63 Forma de apresentao .................................................................................................... 64

5.3.1 5.3.2 5.3.3 6

AVALIAO DO QualiCES ........................................................................................................ 67 6.1 Projeto Social e-Gov ............................................................................................................. 67 O problema ...................................................................................................................... 68

6.1.1 6.2

Aplicao do mtodo ................................................................................................................ 68 Anlise dos documentos a serem inspecionados ............................................................. 68 Aplicao do checklist ..................................................................................................... 69 Aplicao da mtrica de consistncia .............................................................................. 69 Anlise dos resultados ..................................................................................................... 73 Anlise do Mtodo QualiCES ......................................................................................... 75

6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 7

CONSIDERAES FINAIS......................................................................................................... 78 7.1 7.2 Resultados Obtidos ................................................................................................................... 79 Limitaes e Trabalhos Futuros ............................................................................................... 81

REFERNCIAS BIBLIOGRFICAS ......................................................................................... 82

APNDICE A Checklist QualiCES.......................................................................................................78

LISTA DE ABREVIAES

PC PDF PEF PF poC poDF poEF poF poU PU QC QualiCES TBC TBDD TBP TBU TP TPNA TPV UFMT V&V

Peso do item contedo Peso do item dependncia entre funcionalidades Peso do item execuo da funcionalidade Peso do item funcionalidade Pontos do item contedo Pontos do item dependncia entre funcionalidades Pontos do item execuo da funcionalidade Pontos do item funcionalidade Pontos do item usurio Peso do item Usurio Qualidade de Consistncia Qualidade de Consistncia em Especificao de Software Tcnica baseada em checklist Tcnica baseada na deteco de defeito Tcnica baseada em perspectivas Tcnica baseada em uso Total de perguntas Total de perguntas no aplicveis Total de perguntas vlidas Universidade Federal de Mato Grosso Validao e Verificao

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 - Progresso do esforo necessrio para fixar os defeitos dos requisitos.. ....... 36 Figura 6 - Fluxograma de execuo do Mtodo QualiCES.......................................................53 Figura 7 - Trecho do checklist proposto para esse estudo. ............................................. 55 Figura 8 - Modelo grfico para apresentar os resultados obtidos. .................................. 65 Figura 9 - Quantidade de defeitos detectados por itens para cada nvel de consistncia definido pela mtrica de consistncia. ............................................................................ 75

LISTA DE TABELAS Tabela 1 - Correspondncia entre as classificaes de defeitos analisados. ................... 47 Tabela 2 - Definio dos valores para as respostas possveis. ........................................ 62 Tabela 3 - Pesos referentes a cada item analisado. ......................................................... 62 Tabela 4 - Modelo de apresentao dos resultados obtidos com a aplicao de 1 checklist. ......................................................................................................................... 65 Tabela 5 - Resultados obtidos com a aplicao do checklist e da mtrica de consistncia ........................................................................................................................................ 70 Tabela 6 - Quantidade de defeitos encontrados para cada classificao final da mtrica. ........................................................................................................................................ 74 Tabela 7- Atributos de qualidade e regras do QualiCES ................................................ 76 Tabela 8 - Checklist proposto para o mtodo QualiCES ................................................ 86

RESUMO

Em tempos em que a complexidade dos softwares requisitados por muitas empresas tem aumentado, a busca pela sua qualidade, tambm tem sido maior. Contudo, deixar para realizar a atividade de validao e verificao somente no final do processo de desenvolvimento do software pode tornar-se mais custoso e exigir um esforo maior. Estudos mostram que realizar esse processo de validao e verificao desde o incio do ciclo de vida do software pode reduzir os custos e os esforos gastos para consertar erros que possam surgir. Assim, aplicar algum mtodo de validao e verificao de software ainda na fase inicial de seu desenvolvimento, alm de detectar defeitos e impedi-los de se expandirem, permite garantir que a qualidade tambm est presente logo no incio da vida do software. Durante a fase inicial de especificao de software, diversos documentos e artefatos podem ser gerados como forma de auxiliar na sua construo. A consistncia entre esses documentos um atributo de qualidade que deve se destacar nessa fase do processo de desenvolvimento de software, uma vez que esses documentos so base para as fases futuras da vida do software. Por isso, esta pesquisa, alm de revisar trabalhos relacionados ao tema, apresenta como resultados um mtodo de avaliao da consistncia entre documentos e artefatos na fase de especificao de software, o qual se apoia em um checklist e em uma mtrica de consistncia desenvolvidos para esse fim, trazendo como benefcios a deteco de defeitos e a garantia de qualidade de software desde o incio do ciclo de vida de um software.

Palavras-Chave: especificao de software, inspeo de software, validao e verificao de software, qualidade de software.

ABSTRACT

In times that the requirement softwares 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 softwares 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 softwares life. During the early stage of the softwares 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 softwares 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 softwares cycle.

Key words: software specification, software inspection, verification and validation software, software quality.

18

INTRODUO
O desenvolvimento de software um processo que tem se tornado cada vez mais

importante na sociedade atual. A informatizao de diversas reas do conhecimento humano tem exigido que o desenvolvimento de software seja muito mais que programao. necessrio 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 especificaes feitas pelos clientes tambm tem se tornado maior. Assim, os custos de desenvolvimento, o tempo de produo e as dificuldades de manuteno aumentam. Alm disso, com o aumento da complexidade dos softwares, os produtos finais esto sujeitos a diversos erros, falhas e defeitos. Para que esses problemas no perdurem, existe uma srie de atividades de validao e verificao, tais como tcnicas de inspeo 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 construdo ou ao produto no que est em conforme o especificado. Este trabalho trata de anlise de consistncia entre documentos e artefatos na fase de engenharia de requisitos de software por meio de atividades de validao e verificao, aplicando-se tcnicas para garantir a qualidade de um software. Nas subsees seguintes ser melhor delineado o contedo da pesquisa representada neste estudo.

1.1 Justificativa
No mundo atual h uma demanda por qualidade em softwares. necessrio que eles sejam manutenveis, escalonveis e integrados com outros sistemas existentes ou em desenvolvimento. Entretanto, o aumento da complexidade, tem tornado cada vez mais difcil atender a demanda de qualidade.

19

Assim, muitas vezes, os softwares so entregues sem a qualidade desejada e/ou so entregues produtos finais diferentes do desejado ao cliente. Barti (2002), em um estudo realizado no mercado americano, apresenta algumas estatsticas 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 avanado desde o surgimento da informtica, a entrega de produtos sem nenhuma ou com pouca qualidade continua sendo no aceitvel. A qualidade do software frequentemente suspeita. Somente a partir da dcada passada esto comeando a ser seguidos conceitos quantitativos slidos 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 usurio final (IEEE, 1991). A busca por qualidade de um software desde a sua fase de anlise uma forma de diminuir os custos e esforos no desenvolvimento do sistema. Assim sendo, importante que se utilizem tcnicas de garantia da qualidade. Nesse estudo, isso ser realizado por meio de uma metodologia de validao e verificao que deve ser feita na fase de especificao de software.

1.2 Objetivos
Os objetivos desse estudo so divididos em objetivos geral e especficos, os quais so descritos a seguir.

1.2.1 Objetivo geral

Este trabalho tem por objetivo definir, desenvolver e analisar um mtodo de anlise de consistncia entre documentos e artefatos de software, por meio de pesquisa bibliogrfica e aplicaes prticas. Tal mtodo til j na fase de engenharia de requisitos, provendo qualidade no desenvolvimento de software.

20

1.2.2 Objetivos especficos

A fim de alcanar o objetivo geral desse Trabalho de Concluso de Curso (TCC), alguns objetivos especficos foram formulados: identificar, por meio de estudo bibliogrfico, o(s) mtodo(s) de validao de verificao disponvel(eis) para ser(em) aplicado(s) na fase de engenharia de requisitos; desenvolver um mtodo de avaliao de consistncia que apoie a validao e verificao 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 relao consistncia; desenvolver uma mtrica que seja capaz de colaborar com a anlise da consistncia entre os resultados obtidos, e analisar os resultados obtidos com o estudo de caso, como meio de validar o mtodo desenvolvido.

1.3 Metodologia
Para alcanar os objetivos propostos, foi feita uma pesquisa bibliogrfica acerca do tema deste trabalho, utilizando-se como referncia livros da engenharia e qualidade de software, artigos internacionais disponveis em bases da Institute of Electrical and Electronics Engineers (IEEE) e Association for Computing Machinery (ACM), revistas de engenharia de software, alm de dissertaes de mestrado e teses de doutorado. Dessa forma, tentou-se compreender como o processo de validao e verificao de software pode influenciar na obteno de qualidade desde o incio do processo de desenvolvimento de um software. Soma-se ao levantamento bibliogrfico desse estudo, trs macro-atividades fundamentais, as quais guiaram todo o desenvolvimento do estudo: 1. Desenvolvimento de um mtodo para validao e verificao da consistncia entre documentos e artefatos de software;

21

2. Aplicao do mtodo desenvolvido; e 3. Anlise dos resultados. Esta pesquisa de natureza aplicada, pois objetiva gerar conhecimentos para aplicao prtica dirigida soluo de um problema especfico. Este trabalho foi aplicada em documentos e artefatos que foram desenvolvidos no projeto Social eGov, contudo, espera-se que o mtodo possa ser utilizado em qualquer outro projeto desejado. Assim, alm do estudo da literatura referente qualidade de software, foi necessria, tambm, a leitura de documentos associados ao projeto Social e-Gov.

1.4 Organizao do trabalho

O trabalho, alm deste captulo introdutrio, possui mais seis captulos. O Captulo 2 apresenta uma reviso bibliogrfica acerca de temas da Engenharia de software referentes neste estudo: especificao de requisitos, validade e verificao de software, inspeo e teste de software, e uma explicao da diferena entre erros, falhas e defeitos. O Captulo 3 contm um apanhado de temas sobre qualidade de software, apresenta atributos de qualidade para os requisitos e casos de uso, e traz uma reviso sobre algumas tcnicas de inspeo de software. O Captulo 4 apresenta alguns trabalhos relacionados temtica dessa pesquisa. J o Captulo 5 apresenta o mtodo de avaliao de consistncia de documentos e artefatos de software desenvolvido nesse trabalho. E o Captulo 6 apresenta os resultados da aplicao do mtodo em um estudo de caso. Por fim, o Captulo 7 faz as consideraes finais, apresentando os principais resultados obtidos bem como as limitaes e trabalhos futuros.

22

ENGENHARIA DE SOFTWARE
Um software, segundo IEEE (1991), um programa de computador, procedimentos

e documentao associados ao funcionamento do cdigo, e os dados pertinentes operao do sistema, ou seja, ele composto de um programa de computador (cdigo), procedimentos, uma documentao, e dados necessrios para a operao do sistema (ISO, 1997, e ISO/IEC 9000-3). A Engenharia de Software uma disciplina de engenharia relacionada a todos os itens de produo de software, desde os estgios de especificao do sistema at sua manuteno (SOMMERVILLE, 2007). O desenvolvimento de um software composto por quatro etapas bsicas e fundamentais (SOMMERVILLE, 2007, p.6), como pode ser visto na Figura 1: Especificao de Software: trata da compreenso e definio das necessidades do usurio e da identificao das restries de operao e de desenvolvimento do sistema; Desenvolvimento de Software: a fase na qual a especificao de software ser convertida em um sistema executvel. Nesse estgio do processo de desenvolvimento de software esto envolvidos os processos de projeto e de programao de software. o Projeto de Software: trata da descrio da estrutura de software a ser implementada, dos dados que so partes do sistema, das interfaces entre os componentes do sistema, e s vezes, dos algoritmos usados. Ex. definio da arquitetura do sistema e diagramao de atividades e de classes. Validao de Software: este estgio do processo de desenvolvimento de software destina-se a analisar se o sistema est em conformidade com a sua especificao e que atende s expectativas dos usurios. Evoluo de Software: a fase na qual o software pode ser modificado para se adaptar s mudanas dos requisitos do cliente.

23

Figura 1- Processo de vida de um Software.

Este trabalho restringe-se as fases de especificao de software e validao de software, considerando que a ltima deve ocorrer durante todo o processo de desenvolvimento de software, e no somente aps 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 Seo 1, este trabalho desenvolveu um mtodo de validao a ser utilizada na fase de Especificao de Software e, por isso, a seo seguinte ir detalhar esta fase e a posterior, a fase de validao de software.

2.1 Especificao de Software

A fase de especificao de software fase em que so 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 sero consideradas. A seguir, so descritos os principais documentos e artefatos que so considerados para o desenvolvimento desse trabalho.

24

2.1.1 Requisitos
Requisitos so descries dos servios do sistema e de suas restries, geradas durante o processo da engenharia de requisitos (SOMMERVILLE, 2007, p.49). J o glossrio de termos de software do IEEE (1990) define um requisito como: uma condio ou capacidade necessria para o usurio resolver um problema ou alcanar um objetivo; e/ou uma condio ou capacidade que deve ser encontrada ou possuda por um sistema ou componente do sistema para satisfazer um contrato, padro, especificao ou outro documento imposto formalmente. Os requisitos podem ser divididos em vrias formas, dentre elas em funcionais e no funcionais. O primeiro refere-se ao que o sistema deve fazer. J o segundo, referese como deve ser feito, alm de representar as qualidades do sistema como, desempenho, usabilidade, confiabilidade, facilidade de manuteno e capacidade de expanso. O processo de elaborao de um requisito chama-se engenharia de requisitos, e a Figura 3 ilustrada a seguir demonstra o processo bsico 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 domnio do problema. Como atividades dessa fase, pode-se citar coleta de fatos, comunicao e identificao das fontes de informao;

25

Anlise de Requisitos: aqui feita a avaliao e reviso do escopo e dos requisitos do software por meio do processo de descoberta, refinamento, reviso e validao, obtendo, portanto, um entendimento sobre as funcionalidades do sistema; Especificao de requisitos: essa fase objetiva desenvolver o documento de requisitos identificados e desejados pelo cliente. Para isso, definem-se os requisitos funcionais e no funcionais, e as regras de negcio para que o requisito possa ser implementado e executado; Validao de requisitos: nessa fase se obtm o aceite do cliente em relao aos requisitos de software, ou seja, eles so aprovados juntos ao cliente. O principal documento trabalhado na engenharia de requisitos o documento de requisitos, sendo este uma declarao formal de todos os requisitos para a equipe de desenvolvimento de software. Para a anlise de requisitos, diversas tcnicas podem ser utilizadas, como o uso de cenrios, casos de uso e prototipagem. Neste trabalho so mais bem detalhados os prottipos e casos de uso por serem estes os documentos alvo do mtodo 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 usurios 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 usurios, chamados de atores, e as funcionalidades do sistema. O termo modelo utilizado para o conjunto do diagrama e descrio 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 descrio relacionada que descreva como os atores e os sistemas colaboram para alcanar o objetivo proposto para ele.

26

Uma descrio bsica de caso de uso contm, tipicamente, nome, atores relacionados, breve descrio do objetivo, fluxo bsico de eventos, fluxo(s) alternativo(s), requisitos funcionais, pr e ps-condies. Para Scott (2003) apud Gregolin (2007):
os casos de uso so bastante indicados para a definio de funcionalidades do sistema por expressarem a perspectiva dos usurios do sistema, e por serem expressos em linguagem natural, facilitando o entendimento entre o leitor e equipe de desenvolvimento.

A importncia dos casos de uso dada por formarem uma base para fases seguintes especificao de software no processo de desenvolvimento de software.

2.1.3 Prottipos
Outra forma de se obter os requisitos e/ou valid-los por meio da prototipao do software desejado. Sommerville (2007) diz que um prottipo pode ser utilizado em um processo de software de vrias maneiras, e dentro da engenharia de requisitos, um prottipo pode ajudar na descoberta e validao dos requisitos do sistema. O prottipo complementa o caso de uso, facilitando o entendimento das funcionalidades do sistema. Um prottipo uma verso inicial de um sistema de software usado para demonstrar conceitos, experimentar opes de projeto e, geralmente, conhecer mais sobre o problema e suas possveis solues

(SOMMERVILLE, 2007, p.271). Assim, atravs da visualizao, possvel capturar mais detalhes para o caso de uso, e por sua vez, detectar requisitos faltantes, bem como corrigir requisitos que estejam com informaes erradas e/ou ausentes.

2.2 Validao de software

Todo e qualquer software deve ser verificado durante e depois do processo de implementao para garantir que o programa em desenvolvimento atende as expectativas de quem o solicitou (SOMMERVILLE, 2007, p.341). Esse processo recebe o nome de Verificao e Validao (V & V), e embora paream sinnimos, Verificao

27

e Validao no so a mesma coisa (BOEHM, 1979 apud SOMMERVILLE, 2007, p.341). Verificao: tem como objetivo verificar se o software em desenvolvimento est de acordo com as especificaes, ou seja, se atende os requisitos funcionais e no funcionais especificados; Validao: a finalidade da validao garantir que o software atende s expectativas do cliente. Para a verificao h duas respostas possveis: correta e incorreta. J para validao, as duas respostas so: apropriadas e inapropriadas (DZIDA e FREITAG, 1998 apud POHL, 2010). O mtodo proposto neste estudo um mtodo para verificao. 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 correes, mudanas e adio de informaes requeridas em respeito especificao original e mudanas aprovadas; b) Identificar novos riscos e completude do projeto; c) Identificar os desvios dos padres estabelecidos para o projeto; d) Aprovar e analisar o design do produto. 2. Objetivos indiretos a) Melhorar uma reunio para troca de conhecimento sobre tcnicas, ferramentas e mtodos de desenvolvimento; b) Registrar as anlises e erros que serviro como base para correes 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: Inspeo 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 reviso em pares, segundo (MPS.BR,2011). Mas para este trabalho sero consideradas somente as duas citadas por Sommerville (2007). Alm disso, a inspeo e o teste de software so 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 inteno de encontrar erros (MYERS, 1979 apud GALIN, 2004). Portanto, a atividade de teste tem como objetivo demonstrar se as funes do software esto sendo executadas de acordo com as especificaes, se os requisitos de desempenho foram cumpridos e se, por consequncia, as informaes geradas por ele so confiveis. 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, no desejvel ou em no conformidade com sua especificao. O teste de software geralmente executado durante todo o processo de desenvolvimento e manuteno do software. Nesse contexto, trs 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 integrao: verifica o processo de integrao entre softwares componentes; Teste de sistema: preocupa-se com o comportamento do sistema como um todo; segurana, velocidade, hardwares, e ambiente de operao.

29

O teste de software pode ser executado utilizando-se de trs estratgias diferentes (BEIZAR, 1995 apud FARIA, 2003): Teste Funcional: checa se o software est de acordo com as especificaes, independente do cdigo-fonte. O teste funcional tambm conhecido como teste de caixa-preta; Teste Estrutural: utiliza o cdigo-fonte para que os testes possam ser realizados. Tambm conhecido por teste de caixa-branca; Teste Hbrido: usa uma mesclagem entre os testes funcional e estrutural. As estratgias para Testes de software so 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 no podem demonstrar que um software est livre de defeitos ou que ele se comportar conforme especificado em todas as circunstncias. 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 Inspeo de Software

Uma inspeo de software definida como uma tcnica de avaliao formal na qual requisitos e design de software e, at mesmo, o cdigo do programa so examinados em detalhes por uma pessoa ou por um grupo para detectar defeitos, violaes de padres de desenvolvimento e outros problemas (ANDA e SJBERG, 2002). Melo (2009) generaliza dizendo que a inspeo de software um tipo particular de reviso que pode ser aplicado a todos os artefatos de software e possui um processo de deteco de defeitos rigoroso e bem definido. Como mostrado por Pohl (2010), a validao de software em fases iniciais do processo de desenvolvimento de software reduz os custos e o esforo para correes de erros em fases seguintes ao processo de desenvolvimento. Portanto, detectar defeitos

30

ainda na fase de elicitao 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 tcnicas de garantia de qualidade na engenharia de software (PORTER et al., 1995; PARNAS and LAWFORD, 2003, apud AURUM et al., 2004) A inspeo de software apresenta vantagens em seu uso em relao 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, no se pode estar seguro de se outras anomalias de sada so devidas a um novo erro ou se erros causados pelo erro original. Assim, com a inspeo de software no h necessidade de se preocupar com interaes entre erros. Portanto, a inspeo descobre muitos erros em um sistema em uma nica inspeo; 2. Verses incompletas de um sistema podem ser inspecionadas sem custos adicionais. Se um programa est incompleto, necessrio desenvolver um conjunto de testes especficos para as partes disponveis; 3. Assim como procurar defeitos de programas, uma inspeo pode tambm considerar atributos de qualidade mais amplos de um programa como conformidade com padres de qualidade e facilidade de manuteno. Embora inspees de software sejam, atualmente, usadas amplamente, o teste de programa ser sempre a tcnica principal de verificao validao de software (SOMMERVILLE, 2007, p.354).

2.2.3 Falhas x Erros x Defeitos

O processo de Verificao e Validao tem por objetivo encontrar inconsistncias, seja com a especificao de requisitos e sua implementao, seja com o desejo do cliente. Para que essas inconsistncias sejam encontradas, o processo de V & V tem duas abordagens (SOMMERVILLE, 2007): inspeo e teste de software. Durante

31

a realizao delas, falhas, defeito e erros podem ser encontrados. A literatura l estabelece significados especficos para estes termos (DELAMARO et al., 2007). Para Delamaro et al. (2007) defeito um passo, processo ou definio 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 indivduo ao tentar entender uma determinada informao, resolver um problema ou utilizar um mtodo ou uma ferramenta. Por exemplo, uma instruo ou comando incorreto; Erro: uma manifestao concreta de um defeito num artefato de software. Diferena entre valor obtido e o valor esperado, ou seja, qualquer estado intermedirio incorreto ou resultado inesperado na execuo de um programa constitui um erro; Falha: o comportamento operacional do software diferente do esperado pelo usurio. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha. Neto (2009) separa esses conceitos em universos: fsico, da informao e do usurio; como pode ser visto na Figura 4. Para o autor, defeitos pertencem ao universo fsico (a aplicao propriamente dita), pois so ocasionados por mau uso da tecnologia, por exemplo. J os erros podem ser causados por um defeito e pertence ao universo da informao, pois a construo de um software pode ser diferente ao que foi especificado. Por fim, os erros geram falhas, que so comportamentos inesperados em um software, o que afeta diretamente o usurio final da aplicao, e por isso, falhas pertencem ao universo do usurio.

32

Figura 4 - Defeito x Erro x Falha. Adaptado de Neto (2009).

Apesar de reconhecer a diferena entre os trs termos acima explicados, esse estudo ir considerar os trs 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 validao e verificao de software. A deteco de erros, falhas e defeitos uma forma de buscar pela qualidade de software. Assim, no prximo captulo ser tratado sobre qualidade de software ser apresentado algumas tcnicas de inspeo de software que permitem detectar erros, falhas e defeitos.

33

QUALIDADE DE SOFTWARE
Atualmente software tem sido um dos produtos mais requisitados no mercado.

A preocupao com a qualidade tem se tornado requisito imprescindvel. Esta a ideia bsica para garantir a funcionalidade do software com o mnimo de erros, defeitos e maior satisfao s expectativas de qualidade (MAIA, 2003). Como forma de se garantir a qualidade de software, a inspeo e o teste de software so 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, alm de atingir as necessidades e expectativas do usurio final. J para Pressman (2006), qualidade de software definida como a conformidade de explicitar requisitos funcionais e de desempenho especificados, seguir padres de desenvolvimento de documentos e seguir as boas prticas 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 caractersticas de qualidade, as quais so: interna, externa e em uso. Abaixo, cada uma dessas melhor explicada a seguir: Qualidade Interna: especifica o nvel de qualidade requerido sob o ponto de vista interno do produto, isto , na parte estrutural, o cdigo-fonte; Qualidade Externa: especifica o nvel de qualidade requerido sob o ponto de vista externo, isto , visa qualidade do software durante a sua execuo, a qual, geralmente, ocorre em ambientes simulados e com dados simulados. Qualidade em Uso: especifica o nvel de qualidade requerido sob o ponto de vista do usurio, isto , visa medir o quanto usurios podem atingir seus objetivos num determinado ambiente e no 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 construo, como nos requisitos, casos de uso, prottipos, cdigo fonte etc. Por serem foco deste estudo, nas prximas sees sero melhor detalhado a qualidade de requisitos e de casos de uso.

3.1 Qualidade de Requisitos

Requisitos so a base de um software, so objetivos ou restries estabelecidas por clientes e usurios que definem as suas diversas propriedades do sistema e, so aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software. Para Jani (2010) requisitos devem ser completos, claros e no ambguos, porm, requerem muito esforo para serem alcanados. Aurum et al. (2004) diz que estabelecer requisitos completo, claros e no-ambguos e assegurar que os requisitos seguiro os padres da indstria, melhora as chances de se obter uma qualidade maior no software. Jani (2010) realizou um estudo que analisou a qualidade dos requisitos de especificao do software para assegurar que a qualidade aceitvel. Uma tcnica de garantia de qualidade de software, checklist, foi aplicada ao estudo para determinar se os padres de requisitos e procedimentos estavam ou no sendo seguidos dentro da fase de especificao dos requisitos. Para tanto, o autor identificou atributos de qualidade que so esperados em um documento de especificao de requisitos: Completo: uma especificao de requisitos completa quando define todas as situaes reais e inclui todas as caractersticas necessrias para o software; Consistente: uma especificao de requisitos consistente quando no h conflito entre os requisitos; Correto: uma especificao de requisitos est correta quando identifica com preciso e exatamente as condies e limitaes individuais de todos os casos desejados; Modificvel: uma especificao de requisitos modificvel quando os requisitos so agrupados juntos e em ordem, a fim de facilitar as modificaes quando necessrio;

35

Classificao por importncia: uma especificao de requisitos deve identificar os requisitos de acordo com o seu grau de importncia;

Rastrevel: em uma especificao de requisitos, os requisitos devem ser unicamente identificados para alcanar a rastreabilidade;

No-ambguo: um requisito deve ser escrita de forma a no permitir diversas interpretaes;

Compreensvel: uma especificao de requisitos compreensvel se o significado de cada afirmao pode ser facilmente entendida;

Testvel: uma especificao de requisito testvel se a partir dele consegue-se aprovar ou reprovar o requisito por meio de critrios de avaliao;

Verificvel: uma especificao de requisito dever possvel de ser verificada se foi atendida;

Validvel: uma especificao de requisitos validvel se ela pode ser analisada, validada e aprovada por responsveis e participantes do projeto de software. O mtodo aplicado por Jani (2010) um exemplo de mtodo de checagem de

requisitos realizado por meio da verificao dos atributos de qualidade desejados. Existem algumas prticas que colaboram com a obteno da qualidade de requisitos (GUSEV, 2010): Mtodos de desenvolvimento de Requisitos: tcnicas de elicitao de requisitos (aplicao de questionrio, por exemplo) e tcnicas de documentao (uso de templates, por exemplo); Mtodos de checagem de requisitos: inspeo em grupo ou individual, reviso pelo usurio, e prototipagem. A especificao de requisitos serve como referncia para as fases seguintes no processo de desenvolvimento de software. Se um erro no detectado logo no incio desse processo, ele pode se propagar e assim, afetar os demais artefatos que ainda sero desenvolvidos. Portanto, encontrar e corrigir erros nos artefatos de requisitos logo no incio do processo de desenvolvimento de software, evita correo de defeitos

36

futuramente, e dessa forma o esforo e o custo de correo so reduzidos, como a Figura 5 ilustra.

Figura 5 - Progresso do esforo necessrio para fixar os defeitos dos requisitos. Adaptado de Pohl (2010).

Neste contexto, a fase de especificao de requisitos merece uma ateno 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 usurios interagem com o sistema para resolver um problema. Como tal, ele descreve as metas dos usurios, as interaes entre os usurios e o sistema, bem como o comportamento necessrio do sistema para satisfazer estas metas. Um modelo de caso de uso pode se originar a partir de um documento de especificao de requisitos, ou pode ser desenvolvido a fim de representar os requisitos do sistema. Porm, ao construir um modelo de caso de uso a partir dos requisitos, Belgamo et al. (2007) diz que o desenvolvedor deve estar atento porque havero 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 alcanar a completude e a consistncia, 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. So eles:

37

Completeza: A descrio do caso de uso deve ser a especificao detalhada do seu objetivo, contendo todos os seus elementos bsicos. Alm de especificar os fluxos principal e alternativo da forma mais completa possvel;

Compreensibilidade: As sentenas devem evidenciar um dilogo exato entre o ator e o sistema, descrevendo o que deve ser feito e no como fazer, e definindo os requisitos do sistema. Alm disso, necessrio que haja uma breve descrio do propsito do caso de uso;

Preciso: Os termos utilizados devem ser precisos e quantificveis, isto , termos como muito, pouco, claro, fcil etc devem ser evitados.

No ambiguidade: Termos que do margem a diversas interpretaes devem estar claramente identificados e definidos no glossrio;

Consistncia: Os termos utilizados no caso de uso devem ser iguais sempre que se referirem mesma coisa;

Independncia de ferramentas: A descrio deve evitar termos que indicam dependncia de ferramenta ou interface com o usurio, como a presena do termo clicar, aba, boto etc;

Rastreabilidade: As frases dos fluxos principal e alternativo devem ser numeradas para permitir a rastreabilidade;

Objetividade: As sentenas devem ser objetivas e evitar redundncias.

3.3 Tcnicas de Inspeo

Como mencionado na Seo 2.2.1 deste trabalho, inspeo de software uma forma de avaliar documentos e artefatos de software a fim de encontrar problemas que possam impedir os usurios de interagirem com o software desenvolvido, e at mesmo problemas que podem impedir o desenvolvimento do software. A fim de melhorar a compreenso e a busca por defeitos, o processo de inspeo de software possui diversas tcnicas de reviso que podem ser utilizadas. Embora tenham sido desenvolvidas baseadas em diferentes suposies com referncia ao

38

processo de inspeo, essas tcnicas possuem um objetivo em comum: ajudar os revisores a focar nos documentos de software durante a inspeo e assim, encontrar mais erros (THELIN, 2003). Contudo, a inspeo tambm pode ser utilizada como forma de avaliar a usabilidade e acessibilidade dos softwares (MACIEL, 2005), no 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 props a Figura 1 deste trabalho. A seguir, uma reviso das tcnicas de inspeo de software, com finalidade de aplicao na fase de especificao de software, apresentada.

3.3.1 Tcnica baseada em checklist

A tcnica baseada em checklist (TBC) uma tcnica de inspeo que guia o revisor por uma srie de tpicos a serem analisados no artefato desejado, ajudando-o a procurar defeitos ou deficincias. Itens individuais de um checklist podem enumerar, priorizar ou propor questes 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 inspeo para deteco de defeitos nos documentos e/ou artefatos inspecionados. Contudo, Pohl (2010) diz que o checklist no deve ter um nmero muito grande de perguntas para o revisor analisar durante o processo de inspeo. O nmero de questes deve ser pequeno como forma de garantir uma validao mais efetiva. Pohl (2010) ainda diz que um checklist no deve conter todas as regras, ou critrios de qualidade, ou tipos de defeitos esperados em um nico checklist, necessrio separar os assuntos que se deseja inspecionar em vrios outros checklists. Pohl (2010) diz que se um checklist for bem desenvolvido, ser possvel fazer as seguinte anlises, as quais so as metas do processo de validao. Checagem de entrada: analisado se o contexto do sistema foi considerado corretamente, por exemplo, se todas as fontes de requisitos foram levadas em considerao;

39

Checagem de sada: analisado se os artefatos de requisitos se combinam entre si, analisando o contedo e a documentao, por exemplo. Checagem de execuo: analisado o processo de documentao, isto , analisado se a documentao seguiu regras, boas prticas e o processo de descrio da engenharia de software, por exemplo. Assim, para que possa ser possvel checar a entrada, sada e a execuo do software em desenvolvimento, necessrio estruturar as questes que faro parte do checklist assim como a prpria 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 genricas; Elaborar questes que permita a checagem de entrada, de sada e de execuo; Utilizar diferentes checklists para diferentes artefatos; Considerar diversas perspectivas para inspeo; A utilizao do checklist tida como tcnica padro de inspeo 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 tcnica de validao e verificao (POHL, 2010).

3.3.2 Tcnica baseada na deteco de defeitos

A tcnica baseada na deteco de defeitos (TBDD) visa identificar tipos de defeitos especficos. Essa tcnica define uma srie de cenrios e procedimentos que devem ser seguidos durante o processo de inspeo. Essa tcnica objetiva encontrar os mesmos tipos de defeitos da TBC, contudo, mais informaes so includas nos cenrios a fim de projetar uma tcnica mais estruturada (THELIN, 2003).

40

3.3.3 Tcnica baseada em perspectivas

A inspeo baseada em perspectiva (TBP) uma tcnica baseada em cenrios, que d ao revisor procedimentos a serem seguidos durante a inspeo. Em cada perspectiva definido um cenrio e um conjunto de questes e atividades que dizem ao indivduo o que ele deve fazer e como ele deve ler o documento. Essas questes auxiliam o indivduo a descobrir defeitos. Os cenrios descrevem as atividades que devem ser executadas pelo indivduo no momento da leitura a fim de descobrir defeitos em suma. Um cenrio, neste contexto, uma coleo de procedimentos que permitem operacionalizar estratgias para detectar defeitos (MELO, 2009). A inspeo baseada em perspectivas definida baseada em trs perspectivas: usurio, testador e designer. Pohl (2010): Perspectiva do Usurio: o revisor deve verificar se o artefato descreve a funcionalidade e a qualidade desejada pelo usurio; Perspectiva do Designer: o revisor deve verificar se os requisitos contm as informaes necessrias 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 afirmaes referentes a essa tcnica: i) revisores com um foco especfico inspecionam melhor do que revisores com a responsabilidade de detectar todos os tipos de defeitos e ii) que diferentes focos podem produzir uma inspeo mais completa. Essa tcnica pode ser utilizada durante todo o processo de desenvolvimento de software.

3.3.4 Tcnica baseada no uso

Thelin (2003) diz que muitos estudos focam em encontrar tantos defeitos quanto possvel, sem levar em considerao a importncia deles. Assim, a principal ideia por traz da tcnica de inspeo baseada no uso (TBU), segundo o autor, focar na deteco

41

dos defeitos mais crticos no artefato inspecionado. Aqui, os defeitos no so considerados de mesma importncia, e nessa tcnica procura-se detectar os defeitos que tem o maior impacto negativo de qualidade de sistema na perspectiva do usurio. A tcnica baseada em uso utiliza um conjunto de casos de uso como guia de foco na inspeo. Os casos de usos dizem aos revisores como inspecionar o documento de designer ou o documento do cdigo do software da mesma maneira como os casos de testes dizem aos testadores, como testar o sistema. Thelin (2003) d um exemplo do fluxo bsico para realizar o uso dessa tcnica: Antes da inspeo, priorizar os casos de uso em grau de importncia na perspectiva do usurio; Durante a preparao, 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 inspeo, 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 referncia; c. Assegure que o documento sob inspeo preenche as metas do caso de uso, que as funcionalidades so fornecidas, que a interface est correta. Identifique e registre os problemas encontrados; d. Repita todo o processo de inspeo utilizando o prximo caso de uso at que todos tenham sidos inspecionados. O objetivo dessa tcnica melhorar a eficincia e a efetividade da inspeo considerando o grau de importncia dos casos de uso de acordo com a viso do usurio. As tcnicas anteriormente descritas so uma das formas de se detectar defeitos, falhas e erros em um processo de desenvolvimento de software, assim como a deteco de defeitos uma forma de se garantir qualidade de software. Diversos estudos sobre essas tcnicas foram realizados a fim de tentar detectar as melhores tcnicas e a fim de

42

se buscar por mais qualidade de software. No prximo captulo alguns estudos sero relatados a fim de justificar o mtodo proposto neste estudo.

43

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 validao e verificao nos artefatos produzidos. Defeitos so encontrados em todas as fases do desenvolvimento, porm comprovado que a maioria encontra-se nas fases iniciais do processo de desenvolvimento. Isso gera prejuzos enormes para as empresas desenvolvedoras de software, pois o preo para corrigir um erro cresce muito com o passar do tempo. Com isso, fica clara a importncia 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 estratgia chave para garantia da qualidade. Assim, diversos estudos tm sido feitos com o intuito de detectar defeitos desde a fase inicial de especificao 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 props um sistema online que auxilia na percepo de qualidade entre os requisitos. O autor props um checklist online no qual o usurio deveria respond-lo para saber se a sua especificao de requisitos est ou no seguindo certos padres e procedimentos de desenvolvimento. Para isso, foram descritos atributos de qualidade de requisitos, tais como completude, rastreabilidade e corretude, por exemplo. Esses atributos so apresentados na seo 3.2.2 deste trabalho. Por outro lado, Gusev (2010) diz que um checklist geralmente esquece de analisar critrios 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 prope um meio mais iterativo de verificao e validao. O estudo define que uma forma de se obter uma qualidade maior no s na especificao 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 aps a atividade

44

anterior ser completamente terminada e aprovada, alguns defeitos no sero detectados uma vez que s iro surgir quando forem testados em outras fases do processo de desenvolvimento de software. Assim, o autor prope que outros artefatos sejam gerados para verificao e validao de requisitos, como prottipos, e que a verificao no se restrinja somente ao checklist, por exemplo. Para concluir, o autor ressalta que esse fluxo de atividades no garante que os requisitos estejam salvos de erros, mas garante que defeitos potencialmente crticos que afetam a implementao so pegos. Assim como Gusev (2010), Thelin et al. (2003) criticam a tcnica de inspeo de software baseada em checklist em seu estudo. Thelin et al. (2003) em seu estudo comparam duas tcnicas de inspeo de software: a baseada no uso, e a baseado em checklist. Os autores dizem que a tcnica baseada no uso melhor que o checklist em termos de efetividade e eficincia ao encontrar defeitos que mais afetam os usurios, alm de ser mais rpida a sua aplicao. J Belgamo et al. (2005) compararam a eficincia 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 tcnicas de inspeo: 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 tcnicas colaboram com a construo do caso de uso alm de revisarem o documento de especificao de Requisitos. Com o estudo e experimento realizados, os autores mostraram que o TUCCA efetivo na construo do caso de uso e na deteco de defeitos, uma vez que a tcnica desenvolvida obteve resultados to bons quanto o uso da tcnica 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 prximas fases no desenvolvimento de software, e por isso, o TUCCA auxiliar na deteco de defeitos na fase de construo de dos casos de uso, uma vez que o documento de requisitos base para a construo desse artefato. Uma vez construdo o caso de uso, Anda e Sjberg (2002) dizem que a sua qualidade em termos de corretude, completude, consistncia e bom entendimento do requisito funcional so importantes para a qualidade final do produto de software.

45

Assim, Anda e Sjberg (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 anlise: atores, o caso de uso, a descrio de cada caso de uso, e a relao entre os casos de uso. J Aurum et al. (2004) por meio de onze perguntas, analisaram outros itens: cobertura do caso de uso, preciso, abstrao da descrio, consistncias da estrutura do caso de uso e da linguagem utilizada, e fluxos alternativos. Os estudos relatados cima buscaram: comparar tcnicas de inspeo 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 especficos de caso de uso. Assim, algumas classificaes para os erros foram propostas, variando a forma e o objetivo com os quais deveriam ser analisados. A relao entre essas classificaes podem ser vistas na Tabela 1. Para Thelin et al. (2003), os defeitos encontrados em seu estudo foram classificados em trs classes em nvel de importncia para o usurio: Classe A: As funes afetadas por esses defeitos so cruciais para os usurios, isto , so importantes para os usurios e so frequentemente usadas; Classe B: As funes afetadas por esses defeitos so importantes para o usurio, isto , as funes afetadas ou so importantes e raramente usadas ou no so importantes mas, frequentemente utilizadas; Classe C: As funes afetadas no so importantes para os usurios. J para Aurum et al. (2004) os defeitos foram classificados em: Impacto Mnimo: defeito interno do caso de uso; Impacto de Especificao: falta de requisito na descrio do caso de uso; Impacto de Requisitos: os efeitos desejados no domnio do problema no so alcanados. Gregolin (2007) classificou os defeitos dos casos de uso em trs nveis:

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 no impede a compreensibilidade geral; Mdio: defeitos que no so nvel Alto e nem Baixo. Porm, Nielsen (1994) classificou o grau de severidade dos erros encontrados de acordo com a importncia de correo dos mesmos. Os erros, neste caso, eram problemas de usabilidade, porm a sua classificao pode ser adaptada para o mtodo proposto neste estudo. Cinco classificaes so possveis a partir dessa anlise: Sem importncia: o defeito encontrado no afeta o usurio; Cosmtico: o defeito no necessita ser reparado, a menos que haja tempo disponvel; Simples: o defeito pode ser reparado, com baixa prioridade de correo; Grave: o defeito deve ser reparado, com alta prioridade de correo; Catastrfico: o defeito deve ser reparado de qualquer forma antes do produto ser disponibilizado. A Tabela 1 a seguir, a partir das classificaes definidas por Nielsen (1994), Thelin et al. (2003), Gregolin (2007) e Aurum et al. (2004), faz uma relao entre as diversas classificaes mostrando que so semelhantes. Cada autor representado por uma coluna, e por fim feita um resumo da relao analisada.

47

Tabela 1 - Correspondncia entre as classificaes de defeitos analisados.

Nielsen (1994)

Thelin et al. (2003)

Gregolin (2007)

Aurum et al. (2004)

Sntese Defeitos que no afetam a operao e compreensibilidade geral, que se corrigidos

Sem importncia

Classe C

Baixo

Impacto Mnimo

aumentariam a qualidade do proposto; sendo funes que no so suficientemente

importante para os usurios e, portanto, no h necessidade de correo. Defeitos que no afetam a operao e compreensibilidade geral, que se corrigidos Cosmtico Classe C Baixo Impacto Mnimo aumentariam a qualidade do proposto; sendo funes que no so to importantes para os usurios e, portanto, no h necessidade de correo, somente se houver tempo. Defeitos em funcionalidades que so

importantes para os usurios, geralmente a Simples Classe B Mdio Impacto de Especificao falta de um requisito causa esse tipo de defeitos, os quais podem ser corrigidos com baixa prioridade de correo, uma vez que no afetam os usurios. Os objetivos desejados no so alcanados e, portanto, devem ser reparados com alta Grave Classe B Mdio/Alto Impacto de Requisito prioridade de correo, uma vez que se trata ou de funes importantes para os usurios, ou que no so importantes, mas so muito utilizadas por eles. Os objetivos desejados no so alcanados, Impacto de Requisito porm, devem ser corrigidos antes do produto ser disponibilizado, uma vez que so funes importantes e frequentemente utilizadas pelos usurios.

Catastrfico

Classe A

Alto

48

4.1 Pressupostos para elaborao do checklist

Os estudos relatados anteriormente apresentaram checklists como uma ferramenta de apoio de inspeo, os quais eram considerados como apenas um artefato do processo de desenvolvimento de software. Anda e Sjberg (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 esto definidos no caso de uso, se esto totalmente descritos e claros; ii) o caso de uso, investigando se falta requisitos na descrio do caso que impeam o ator de cumprir a meta do caso de uso, ou se o caso de uso considera o papel do ator na sua descrio; iii) a descrio do caso de uso, analisando o fluxo principal do caso de uso, os termos utilizados para a descrio dos passos do fluxo, as pr e ps condies; e iv) a relao entre casos de uso, analisando se a descrio 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 abrangncia do caso de uso, a coerncia e a consistncia dos passos dos fluxos principal e alternativos dos casos de uso e, analisaram se o caso de uso encontrase descrito em nvel abstrato. Alm disso, os autores tambm analisaram a linguagem da descrio, a estrutura e os fluxos dos casos de uso, assim como Anda e Sjberg (2002) tambm analisaram. Nessa mesma linha de estudo de inspeo de casos de uso, Gregolin (2007) tambm apresentou um checklist como ferramenta para inspeo, contudo, a autora considerou apenas a descrio e o diagrama do caso de uso como artefatos inspecionveis. Para a descrio dos casos de uso, a autora considerou a forma e organizao, escrita, termos utilizados, contedo e artefatos de suporte. Contudo, como observado, Anda e Sjberg (2002), Aurum et al. (2004) e Gregolin (2007) analisaram a inspeo da descrio e diagramao dos casos de uso, no 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 especificao de requisitos como base para seus estudos, a tcnica desenvolvida pelos autores, a TUCCA, utiliza o documento de requisitos como base para a construo dos casos de uso a partir de outras duas tcnicas, ou seja, o estudo tambm voltado para os casos de uso. Gusev (2010) em seu estudo mostrou que quando o processo de validao e verificao ocorre desde a fase inicial do desenvolvimento de software, e para isso apoia-se no uso de outros artefatos como prottipos, mais defeitos esto sujeitos a serem detectados, uma vez que alguns s aparecem aps a execuo do sistema ou em fases posteriores a especificao de software. Dessa forma, o autor prope um processo de inspeo mais interativo. Assim, o mtodo desenvolvido nesse estudo, considera como documentos a serem analisados: documento de especificao de requisitos, descrio dos casos de uso e prottipos de tela. Isto , proposto um mtodo que analisa a consistncia entre documentos e artefatos gerados durante o processo de especificao de software, no se restringindo somente a busca de qualidade de casos de uso, mas sim da qualidade do processo de especificao de software. Assim, como os estudos acima relacionados, o mtodo proposto neste estudo, intitulado de QualiCES (Qualidade de Consistncia em Especificao de Software), apoia-se na utilizao da tcnica de checklist, mesmo que alguns estudos tenham mostrado que a utilizao do checklist quando comparado com a aplicao de outras tcnicas no mesmo processo de validao e verificao, pode no ser to eficiente na deteco de defeitos. o caso do estudo proposto por Thelin et al. (2003), no qual os autores compararam a tcnica de checklist com a tcnica baseada em uso. Contudo, a comparao proposta por Thelin et al. (2003) analisa a deteco dos defeitos mais graves na perspectivado usurio. O mtodo desenvolvido neste trabalho tambm utiliza de checklist com o objetivo de analisar a consistncia entre documentos e artefatos de software, e assim, por consequncia, encontrar defeitos que afetariam os usurios, alm de colaborar com a qualidade de software desde o incio do ciclo de vida do software.

50

Em adio ao checklist, o mtodo QualiCES considera a tcnica baseada em perspectivas, ou seja, para a deteco de defeitos ser considerado e analisado se o defeito encontrado afeta ou no o usurio, como propem Thelin et al. (2003). Para a deteco dos defeitos que podem ser encontrados durante a inspeo dos casos de uso, Anda e Sjberg (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 validao e verificao. Em anlise a essa taxonomia e a essa Tabela de defeitos, percebeu-se que muitos desses erros podem ocorrer no somente em casos de usos, mas tambm em documentos de requisitos e prottipos de tela tambm. Assim, para a elaborao do checklist proposto neste estudo, alguns dos defeitos apontados por Aurum et al. (2004) e Anda e Sjberg (2002) foram considerados no processo de escrita das perguntas que iriam compor o checklist. Portanto, o checklist proposto como ferramenta de apoio ao mtodo desenvolvido no analisa questes 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 deteco de defeitos que trazem inconsistncia ao processo de especificao de software, como a falta de requisitos, a no considerao de informaes presentes nos requisitos funcionais que no foram seguidas nos casos de uso e nos prottipos, e incoerncia entre dicionrio de dados e prottipos, por exemplo. Buscando a consistncia entre os documentos da fase de anlise de requisitos, o checklist pretende apontar defeitos que sero classificados a partir de uma classificao 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 aplicao do mtodo proposto possa se alcanar os atributos de qualidade como propem Gregolin (2007) e Jani (2010). Na prxima seo, o mtodo proposto ser descrito. No decorrer da descrio, detalhes dos pressupostos utilizados para concepo do checklist sero descritos como forma a enaltecer suas caractersticas e a forma com a qual se espera alcanar a qualidade e a consistncia dos documentos e artefatos da especificao de software.

51

MTODO QualiCES
Este captulo est estruturado de forma a apresentar a proposta do mtodo

QualiCES, apresentando as etapas para sua aplicao, o checklist de apoio para o mtodo, alm da mtrica de consistncia desenvolvida para anlise dos resultados obtidos com a aplicao do checklist.

5.1 O mtodo
Consistncia a coerncia na exposio das ideias (AURELIO, 2010). Sendo assim, consistncia neste estudo significa coerncia entre os documentos e artefatos de requisitos de software. Sendo assim, apresenta-se nesta pesquisa um mtodo de anlise de consistncia entre documentos do desenvolvimento do software. O QualiCES um mtodo que tem como objetivo avaliar a consistncia entre documentos de requisitos de software, em especial entre Especificao de Requisitos, Casos de Usos e Prottipos. Por esse motivo, trata-se de um mtodo de garantia da qualidade que pode ser utilizado nas fases iniciais do desenvolvimento de software e, portanto, contribui para a diminuio dos custos de um projeto. O mtodo composto por cinco etapas, as quais so descritas a seguir e contm atividades correspondentes para a sua realizao. 1. Identificao das necessidades de qualidade: essa etapa consiste na identificao das necessidades da equipe de desenvolvimento de software. Assim, embora exija um pouco de esforo e custos extras para garantir a qualidade de software, em longo prazo os custos e esforos necessrios para consertar futuros defeitos sero menores. Por isso, para a aplicao do mtodo QualiCES, faz-se necessrio que se tenha os documentos de requisitos, descrio dos casos de uso e prottipos de tela; 2. Anlise dos documentos e artefatos necessrios: essa etapa responsvel por reunir os documentos necessrios para anlise e verificar se esto completos. Por exemplo, para o documento de requisitos, descrio de casos de uso e prottipos,

52

dever ser verificado para cada de uso, se h o seu prottipo correspondente, se o documento de requisitos est completo e com os requisitos numerados e identificados corretamente. Esta etapa constituda das seguintes atividades: a) Obter os documentos necessrios para a aplicao do mtodo; b) Analisar os documentos, analisando se h um caso de uso e um prottipo ou um conjunto de prottipos correspondentes, bem como analisando se o documento de requisitos est completo; 3. Aplicao do checklist: o checklist uma ferramenta que deve ser aplicada para cada de uso separadamente com o seu respectivo prottipo de tela, a fim de detectar defeitos entres os documentos e artefatos do processo de especificao de software. As seguintes atividades compem essa etapa: a) Escolher um caso de uso e seu prottipo correspondente e preencher o cabealho do checklist, com finalidade de identificar a aplicao realizada; b) Para cada pergunta do checklist analisar a regra e dar o parecer final da anlise; c) Se algum defeito for detectado, preencher os campos destinados a identificao dos defeitos; 4. Aplicao da Mtrica de consistncia: com a aplicao do checklist obtm-se os defeitos, e a partir dos defeitos possvel aplicar a mtrica de consistncia para anlise de qualidade dos artefatos e documentos inspecionados. Para tanto, faz-se necessrio a execuo das seguintes atividade. a) Aps preencher todo o questionrio, coletar os dados para aplicao da mtrica, ou seja, realizar a soma dos pontos de cada grupo de defeitos por itens e obter o total das perguntas vlidas; b) Aplicar a mtrica de consistncia de acordo com a frmula definida na Tabela 5;

53

5. Anlise dos resultados: os resultados obtidos com a aplicao da mtrica de consistncia devem ser analisados conforme parmetros definido na seo 5.4 deste estudo. As seguintes atividades compem 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 prottipos sejam inspecionados; c) Reportar os responsveis pela especificao de software para que as devidas correes possam ser realizadas, quando necessrio. Um fluxograma de execuo do Mtodo QualiCES pode ser visualizado na Figura 6.
Fim

No
Incio

H o desejo pela qualidade? Sim No

3c

2a

2b

Documentos ok?

Sim Defeitos detectados?

Sim

3b

3a

3a

No No

4a

4b

5a

Ainda h documentos para serem inspecionados? Sim

5c
Figura 6 - Fluxograma de execuo do Mtodo QualiCES.

54

5.2 Checklist
Para a criao do QualiCES foram considerados trs documentos de requisitos: especificao de requisitos, casos de uso e prottipos. Assim, como base de aplicao do QualiCES, um checklist, para auxiliar na percepo de inconsistncias entre os documentos citados. Atravs do checklist, possvel buscar por defeitos entre esses documentos e artefatos e, por consequncia, 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 anlise, 3) a classificao do defeito encontrado, e 4) uma rea para justificativa e/ou observaes a respeito do item analisado. O Item analisado refere-se ao assunto tratado nas perguntas do checklist. O Resultado da anlise refere-se a resposta dada a pergunta realizada. J classificao do defeito refere-se a alguns itens que devem ser analisado quando um defeito for detectado. Na rea para justificativa e/ou observao podem ser escritos comentrios para que se possa entender os defeitos detectados. O documento completo pode ser visto no Apndice A deste trabalho.

55

Itens

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 mtodo desenvolvido no se restringe somente a anlise do caso de uso como Anda e Sjberg (2002) Aurum et al. (2004) e Gregolin (2007) propuseram em seus estudos, ele busca tambm detectar inconsistncias entre os documentos de especificao de requisitos. O checklist proposto composto por 28 (vinte e oito) perguntas, as quais esto divididas em cinco itens a serem analisados simultaneamente entre o documento de requisitos, documento de descrio de caso de uso e prottipo de tela. So eles:

56

Contedo: responsvel por analisar a descrio geral do caso de uso, no sentido de se alcanar o objetivo proposto e a funcionalidade prevista no documento de requisitos, tanto por meio do caso de uso, quanto por meio do prottipo. Alm disso, esse item analisa se os dados do dicionrio de dados so seguidos, bem como se os termos utilizados para identificar o objetivo da funcionalidade so intuitivos. Esse item composto por quatro perguntas. Funcionalidade: responsvel por analisar se tanto o caso de uso quanto o prottipo consideram todos os requisitos funcionais relacionados funcionalidade descrita no caso de uso, bem como detectar a omisso de algum requisito e/ou detectar algum requisito que no se aplica ao caso de uso e prottipo inspecionado. Esse item composto por sete perguntas. Execuo da funcionalidade: para que se possa alcanar determinada funcionalidade do sistema necessrio seguir alguns passos, alm de ser necessrio seguir algumas restries e/ou alternativas. Assim, esse item responsvel por analisar se os fluxos principais e alternativos, bem como as restries de um caso de uso podem ser seguidos no prottipo de tela, alm de analisar se h passos faltantes ou sobrando em ambos os artefatos. Alm disso, so analisados se as pr e ps condies execuo do caso de uso so consideradas no prottipo. Esse item composto por nove perguntas. Dependncia entre funcionalidades: alguns casos de uso necessitam de outros para completar determinada funcionalidade em um sistema. Assim, esse item responsvel por analisar se a descrio do caso de uso e o prottipo consideram relao de include e exclude entre casos de uso. Esse item composto por quatro perguntas. Usurios: qualquer sistema desenvolvido por ter vrios usurios finais classificados de acordo com suas funes dentro do sistema. Assim, esse item analisa se todos os usurios/atores foram considerados tanto no caso de uso bem como no prottipo, alm de analisar se seus papis 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 informaes analisadas por Anda e Sjberg (2002) Aurum et al. (2004) e Gregolin (2007), mas abrangendo requisitos funcionais, casos de uso e prottipos. Na seo seguinte, so apresentadas algumas regras que auxiliam no processo de inspeo. Estas regras definem o que seria uma resposta as perguntas que no encontram qualquer no conformidade. 5.2.1.1 Critrios de avaliao do questionrio Para que cada pergunta relacionada a cada item pudesse ser analisada e por qualquer pessoa sem que isso acarretasse em m interpretao, fez-se necessrio definir alguns critrios. Para tanto, para cada um dos cincos item do checklist, foram definidas regras de validao do questionrio definidas neste trabalho. Como forma de facilitar o acesso a essas regras durante a etapa de aplicao do checklist, as regras foram inseridas no prprio checklist. 5.2.1.1.1 Contedo Regra 1.1 A descrio do caso de uso deve ser a especificao detalhada do seu objetivo, de forma a atender as suas funcionalidades previstas. Pergunta relacionada: 1; Regra 1.2 O prottipo desenvolvido deve atingir o objetivo do caso de uso por meio da sua descrio. Pergunta relacionada: 2; Regra 1.3 O prottipo deve seguir todas as definies do dicionrio de dados descrito no caso de uso. Pergunta relacionada: 3; Regra 1.4 Os ttulos dos botes das informaes no prottipo deve permitir ao usurio, 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 prottipo. 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 no devem ser conflitantes entre si. Pergunta relacionada: 8; Regra 2.5 As informaes descritas nos requisitos funcionais devem ser as mesmas informaes presentes no caso de uso e no prottipo. Pergunta relacionada: 9; Regra 2.6 O prottipo deve seguir todas as informaes 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 descrio. Pergunta relacionada: 11. 5.2.1.1.3 Execuo da funcionalidade Regra 3.1 As pr-condies definidas no caso de uso devem ser identificveis no prottipo. Pergunta relacionada: 12; Regra 3.2 A descrio do caso de uso deve especificar o fluxo principal e alternativo da forma mais completa possvel para que o prottipo 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 prottipo. Perguntas relacionadas: 14 e 17; Regra 3.4 Todos os passos necessrios 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 prottipo. Pergunta: 19;

59

Regra 3.6 As ps-condies quando muito importantes, devem ser identificadas no prottipo. Pergunta relacionada: 20. 5.2.1.1.4 Dependncia entre funcionalidades Regra 4.1 Os relacionamentos entre casos de uso no 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 includo deve ser identificado corretamente pelo caso de uso dependente. Perguntas relacionadas: 21, 22 e 24; Regra 4.3 O prottipo de um caso de uso dependente de outro caso de uso deve considerar o caso de uso includo. Pergunta relacionada: 23. 5.2.1.1.5 Usurios 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 prottipo. Pergunta relacionada: 26; Regra 5.3 O caso de uso e o prottipo deve considerar exatamente o papel dos atores identificados de acordo com a descrio de cada ator. Perguntas relacionadas: 27 e 28. 5.2.1.2 Resultados possveis da anlise das regras Por meio das regras descritas na Seo anterior, possvel ter quatro pareceres finais: sim, no, em partes, e no se aplica. Sim: quando a regra definida para a questo analisada for completamente atendida; No: quando de forma alguma a regra definida para a questo for cumprida; Em partes: quando a regra definida for cumprida em partes, isto , quando ela foi atendida, porm ainda falta alguma coisa para complet-la;

60

No se aplica: quando no for possvel responder a pergunta ou por ser impossvel analisar a o pedido, ou por porque alguma outra questo no foi atendida e por isso as perguntas relacionadas no podem ser respondidas. Devese ter ateno redobrada para esse parecer final, pois ele ser importante para a aplicao da mtrica de consistncia.

5.2.2 Classificao dos defeitos

O objetivo do QualiCES identificar defeitos a partir do descumprimento das regras descritas nas Seo 5.2.1.1. Alm disso, para cada defeito encontrado deve-se considerar quo grave ele . Para tanto, o mtodo considerar trs itens: 1. Objetivo: um defeito pode ou no afetar a implementao de uma funcionalidade. Quando for percebido algum problema, o revisor dever dizer, portanto, se ele afeta (sim ou no) o objetivo do caso de uso e sua funcionalidade. Sim: Quando o objetivo afetar o usurio, impedindo que ele utilize a funcionalidade analisada. Exemplos: falta de algum requisito funcional, no so consideradas determinadas caractersticas no papel de um usurio do sistema; No: Quando o defeito no afetar o alcance do objetivo da funcionalidade. Exemplo: diferena entre os atributos de um dicionrio de dados e os atributos identificados no prottipo. 2. Urgncia de correo: um defeito difere do outro em diversos itens, e um deles em relao a urgncia de correo. Assim, quando algum problema for detectado, a urgncia de correo dever ser analisada. A urgncia pode ser classificada em trs nveis. So eles: Curto Prazo: Quando o defeito detectado tem que ser corrigido antes de iniciar a fase de design do software. Exemplo: requisitos faltantes; Mdio prazo: Quando o processo de design de software pode ser seguido, porm o defeito deve ser consertado antes da implementao.

61

Exemplo: adicionar algum boto que faltou no prottipo porque o caso de uso no previu essa ao. Longo prazo: Quando o defeito pode ser corrigido durante ou aps a implementao do software. Exemplo: alterao de nome de campos. 3. Importncia da funcionalidade: Baseada na perspectiva do usurio, o defeito detectado dever ser classificado considerando a importncia da funcionalidade para o usurio, podendo ser: Muito importante: se o defeito encontrado impede que o usurio execute a funcionalidade. Exemplo: a falta de um requisito; Importante: se a funcionalidade afetar em partes a interao do usurio com o sistema. Exemplo: a falta de um boto cancelar; Pouco importante: se a funcionalidade no afetar em nada a interao do usurio com o sistema. Exemplo: nomes divergentes entre dicionrio de dados da descrio do caso de uso, e o nome utilizado no prottipo. Aps a deteco dos defeitos e da classificao a partir dos parmetros acima descritos, a prxima etapa do QualiCES proposto aplicar uma mtrica de consistncia que permita que os resultados possam ser analisados. Esta mtrica descrita na prxima seo.

5.3 Mtrica
Esta seo tem como objetivo apresentar a mtrica desenvolvida para acompanhar o nvel de consistncia entre os documentos e artefatos analisados por meio do mtodo QualiCES. A mtrica de consistncia foi desenvolvida para apoiar o mtodo QualiCES e composta de trs etapas: coleta de dados, anlise dos dados e apresentao dos resultados. O pblico alvo dela so todos os interessados nos resultados, como profissionais de qualidade e analista de requisitos. A seguir so descritas as etapas que constituem a mtrica.

62

5.3.1 Coleta de dados

A etapa de coleta de dados destina-se obteno dos dados nos quais a mtrica de consistncia ser aplicada. Assim, seguem descritos os passos para a realizao dessa atividade. 1. Para cada pergunta respondida no checklist que for encontrado algum defeito, some a pontuao poX obtida em relao aos atributos atrapalha objetivo, urgncia de correo, e importncia da funcionalidade, onde X o nmero da pergunta em questo. Essa pontuao dada considerando a Tabela 2.
Tabela 2 - Definio dos valores para as respostas possveis.
Atrapalha o alcance do objetivo Sim = 1 No = 0 Urgncia da correo Curto prazoe = 3 Mdio prazo = 2 Longo prazo = 1 Importncia da funcionalidade Muito importante = 3 Importante = 2 Pouco importante = 1

2. Para cada item (contedo, funcionalidade, execuo da funcionalidade, dependncia entre funcionalidades, e usurios), some a pontuao X (poX) das perguntas que o constituem, obtendo, assim, pontuao das perguntas relacionadas ao item contedo (poC), a pontuao das perguntas relacionadas ao item funcionalidade (poF), a pontuao das perguntas relacionadas ao item execuo da funcionalidade (poEF), a pontuao das perguntas relacionadas ao item dependncia entre funcionalidades (poDF) e a pontuao das perguntas relacionadas ao item usurio (poU). 3. Para cada pontuao de itens obtida anteriormente, multiplique pelo peso correspondente, para tanto considere a Tabela 3.
Tabela 3 - Pesos referentes a cada item analisado.
Item Contedo (C) Funcionalidade (F) Peso (P) PC = 0,1 PF = 0,3

63

Execuo da funcionalidade (EF) Dependncia entre funcionalidades (DF) Usurios (U)

PEF = 0,4 PDF = 0,1 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 pontuao obtida entre os itens e seus respectivos pesos, e divida o resultado obtido pelo total de perguntas vlidas(TPV), obtendo assim, o coeficiente de qualidade de consistncia (QC). Observe a frmula a seguir.

QC = (poC*PC + poF*PF + poFE*PFE + poDF*PDF + poU*pU)/TPV.

TPV = TP TPNA, onde TPV o nmero total de perguntas vlidas, TP o nmero total de perguntas do checklist, e TPNA o total de perguntas no aplicveis.

5.3.2 Anlise dos dados

Aps a aplicao da mtrica de consistncia para cada caso de uso e ao seu respectivo prottipo, o mtodo proposto prev que o resultado seja analisado. Assim, esse estudo considera que a consistncia entre os documentos e artefatos analisados durante a especificao de software dada seguindo os seguintes valores:

64

Consistente: quando o resultado da aplicao da mtrica resultar em resultados menores ou iguais a 0,199;

Pouco consistente: quando o resultado da aplicao da mtrica resultar em resultados maiores que 0,3 e menor que 0,699;

Inconsistente: quando o resultado da aplicao da mtrica resultar em resultados maiores que 0,7.

Os valores definidos para classificao dos resultados obtidos foram escolhidos com base na mdia dos resultados da aplicao do QualiCES (Captulo 6). So necessrios mais testes para que esses valores possam ser mais slidos e confiveis. Aps a anlise dos resultados necessrio reportar os responsveis pela especificao de software para que as devidas providncias de correo sejam tomadas.

5.3.3 Forma de apresentao

Aps a aplicao da mtrica e da anlise dos resultados, faz-se necessrio que os resultados sejam apresentados aos responsveis. Assim, h duas formas para que essa atividade possa ser realizada: tabular e grfica. 1. Tabular: a forma tabular constituda de uma Tabela formada pelas colunas, caso de uso, itens, pontuao de cada item, total de perguntas no aplicveis (TPNA), qualidade de consistncia (QC), e a classificao 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 pontuao obtida. Para o checklist, coloque o TPNA, QC e a classificao obtida. Observe a Tabela 4 a seguir.

65

Tabela 4 - Modelo de apresentao dos resultados obtidos com a aplicao de 1 checklist.

Identificao

Itens Contedo Funcionalidade

Pontuao <poC> <poF> <poEF>

TPNA

QC

Classificao

<nome do caso de uso ou do prottipo>

Execuo da funcionalidade Dependncia entre funcionalidades Usurios

TPNA <poDF> <poU>

QC

<Consistente ou Pouco consistente ou Inconsistente>

2. Grfica: para a forma grfica, monte um grfico 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 apresentao deve ser utilizada para apresentar os resultados considerando todas as aplicaes do checklist, apresentando um grfico resumo de todos os defeitos detectados. Veja Figura 8 a seguir.

Figura 8 - Modelo grfico para apresentar os resultados obtidos.

66

No prximo captulo ser descrita a aplicao do mtodo QualiCES em um estudo de caso, demonstrando a aplicao do checklist e da mtrica propostos pelo mtodo.

67

AVALIAO DO QualiCES
Para mostrar a aplicabilidade do mtodo proposto para avaliao da consistncia

entre os documentos e artefatos do processo de especificao de software, ele foi aplicado em um projeto de pesquisa desenvolvido na UFMT (Universidade Federal de Mato Grosso). Nesta seo sero apresentados o projeto utilizado como fonte de dados para a aplicao do mtodo desenvolvido, os resultados obtidos e os benefcios que o mtodo 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 Computao da UFMT. O projeto que tem como ttulo Um Framework para o desenvolvimento de Aplicaes Governamentais e-Participativas na Web desenvolvido pelo grupo de pesquisa Laboratrio de Ambientes Virtuais Interativos (LAVI) e objetiva desenvolver um ambiente customizvel para o desenvolvimento de aplicaes governamentais eparticipativas na web, utilizando uma estrutura de componentes (MACIEL et al.,2007). Atualmente composto por 14 pesquisadores, sendo 7 alunos da iniciao cientfica, 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 durao de aproximadamente de 3 anos e at o momento j produziu a seguinte documentao do software que se prope a desenvolver: documento viso do projeto, o qual contm os requisitos funcionais e no funcionais do sistema a ser desenvolvido; o documento de interface, o qual descreve os padres adotados para a interface da plataforma de governo eletrnico desenvolvida pelo Projeto Social eGov, alm de conter os casos de uso do sistema; prottipos de tela, os quais so 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 estgio de implementao.

68

6.1.1 O problema
O termo Governo Eletrnico tem como princpio a utilizao das modernas TICs (Tecnologias de Informao e Comunicao) para democratizar o acesso informao, ampliar discusses e dinamizar a prestao de servios pblicos com foco na eficincia e efetividade das funes governamentais. Nesse contexto, o Projeto de pesquisa Social e-Gov tem como finalidade colaborar e ampliar a participao dos cidados nos assuntos relacionados ao Governo. Para isso, o grupo tem desenvolvido um framework de componentes, os quais permitem customizao de recursos durante o desenvolvimento de sistemas e-participativos.

6.2 Aplicao do mtodo

Para que o mtodo QualiCES seja aplicado faz-se necessrio que haja o desejo e a busca pela qualidade de software desde o incio do processo de desenvolvimento de software por parte dos envolvidos nesse processo, como prope a etapa 1 do mtodo proposto. Assim, com esse desejo e necessidade, o Projeto Social e-Gov possibilitou que o mtodo QualiCES pudesse ser aplicado e testado em seus documentos. No decorrer dessa Seo, todo o processo de aplicao ser descrito, bem como ser descrita a estrutura da documentao obtida para os testes, alm dos resultados obtidos com o mtodo.

6.2.1 Anlise dos documentos a serem inspecionados

Conforme definido pelo mtodo QualiCES, os documentos a serem inspecionados so o documento de requisitos, casos de uso e prottipos de tela relacionados aos casos de uso. A anlise desses documentos levou s seguintes concluses: 1. No documento de requisitos do sistema h 23 requisitos funcionais; 2. No documento de requisitos assim como no documento de descrio dos casos de uso, h quatro classificaes de usurios para o sistema: usurio

69

normal autenticado no sistema, moderador, administrador, e usurio convidado o qual no est validado no sistema; 3. O documento de descrio de casos de uso contm a descrio de 42 casos de uso; 4. H somente 17 prottipos criados. Aps a anlise dos documentos foi possvel aplicar o checklist.

6.2.2 Aplicao do checklist

O checklist proposto foi aplicado pelo autor desta pesquisa que tambm um membro do grupo de pesquisa Social e-Gov. Por existirem apenas 17 prottipos, apensa 17 casos de usos puderam ser analisados. E assim, o checklist foi aplicado dezessete vezes. Como resultado da aplicao do checklist, foi possvel encontrar inconsistncias em todos documentos analisados. Os itens que mais apresentaram defeitos foram funcionalidades e execuo da funcionalidade. Com relao ao item funcionalidades, destaque-se que a ausncia de algum requisito no documento de especificao de requisitos, responsvel pela deteco de diversos defeitos, por mais que se refiram ao mesmo problema. Na Tabela 5 possvel visualizar as pontuaes de grupos de defeitos separados por itens e por caso de uso, e a quantidade de perguntas no aplicveis (TPNA) ao caso de uso inspecionado. Na Tabela 5 possvel visualizar as pontuaes de grupos de defeitos separados por itens e por caso de uso, e a quantidade de perguntas no aplicveis (TPNA) ao caso de uso inspecionado. A prxima seo ir mostrar os resultados da aplicao do checklist por meio da anlise dos dados obtidos com a aplicao da mtrica.

6.2.3 Aplicao da mtrica de consistncia

Com as pontuaes por grupos obtidas e com a quantidade de perguntas no aplicveis foi possvel aplicar a mtrica de consistncia descrita na seo 5.4 deste

70

estudo. Os resultados obtidos para cada aplicao do checklist podem ser visualizados na Tabela 5.
Tabela 5 - Resultados obtidos com a aplicao do checklist e da mtrica de consistncia.
Caso de Uso Itens Contedo Funcionalidades Acessar mural de notcias Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Aprovar demanda Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Cadastrar informao na biblioteca Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Cadastrar localidade Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Cadastrar manifestao Funcionalidades Execuo da Pontuao 5 0 7 TPNA QC Classificao

0,143

Consistente

0 0 11 28 18 Pouco consistente

0,695

0 0 7 28 12 Pouco consistente

0,576

5 0 2 0 4

0,069

Consistente

0 0 12 28 18 6 0,763 Inconsistente

71

funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Cadastrar notcia Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Cadastrar temtica Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Cadastrar biblioteca Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Efetivar voluntrios a moderao Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Enviar convite Funcionalidades Execuo da funcionalidade 0 0 6 28 7 Pouco consistente

0,538

22 0 0 0 4

0,061

Consistente

0 0 10 21 0 Pouco consistente

0,280

0 0 19 33 29

1,113

Inconsistente

8 14 2 0 8 4 0,141 Consistente

72

Dependncia entre funcionalidades Usurios Contedo Funcionalidades Execuo da Inserir ressalva funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Execuo da Moderar notcia funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Execuo da Opinar demanda funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Visualizar demanda Execuo da funcionalidade Dependncia entre funcionalidades Usurios Contedo Voluntariar-se a moderador da demanda Funcionalidades Execuo da funcionalidade Dependncia entre

0 0 0 4 11 Pouco Consistente

0,279

4 7 7 28 18

0,763

Inconsistente

5 0 0 0 11 Pouco Consistente

0,261

4 20 3 2 0

0,040

Consistente

0 0 0 0 1 6 24 0,213 Pouco Consistente

73

funcionalidades Usurios Contedo Funcionalidades Execuo da Votar demanda funcionalidade Dependncia entre funcionalidades Usurios Contedo Funcionalidades Votar pela liberao da demanda Execuo da funcionalidade Dependncia entre funcionalidades Usurios 0 0 7 4

0,148

Consistente

0 0 7 28 11

0,891

Inconsistente

0 0

A partir da Tabela 5 pode-se observar a forma de apresentao, definida na Seo 5.4.3, dos resultados obtidos com a aplicao do checklist. Com os dados expostos dessa forma, fica claro analisar em qual item encontra-se a maior concentrao de defeitos. Na prxima seo, sero analisados os resultados da obtidos na Tabela 4.

6.2.4 Anlise dos resultados

De acordo com a mtrica de consistncia proposta neste estudo, a aplicao do checklist poderia apontar que os documentos e artefatos analisados so consistente, pouco consistente e inconsistente. A partir dos valores obtidos na Tabela 5, foi possvel elaborar a Tabela 6 que contm a classificao dos resultados analisados.

74

Tabela 6 - Quantidade de defeitos encontrados para cada classificao final da mtrica.

Quantidade de defeitos detectados 12 54 44 110

Nvel de consistncia Consistente Pouco consistente Inconsistente TOTAL

Classificao final 6 7 4 17

Porcentagem 32,73% 43,63% 23,64% 100%

A Tabela 6 mostra que das 17 aplicaes do checklist, apenas 6 casos de uso com seus respectivos prottipos e requisitos so coerentes na funcionalidades que representam. Os demais, ou so pouco consistente, ou exigem total anlise para buscar a consistncia. A Tabela 6 ainda mostra a quantidade de defeitos detectados por meio da aplicao 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 nvel de consistncia obtido analisado considerando a quantidade de erros obtidos em cada item, percebe-se que a maior concentrao de erros encontra-se nos itens funcionalidade e execuo da funcionalidade, como pode ser visto na Figura 9. Provavelmente, esse grande nmero deve-se falta de uma especificao de requisitos mais completa. Portanto, com a aplicao do mtodo QualiCES foi possvel 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 nvel de consistncia definido pela mtrica de consistncia.

Na prxima seo, feita uma anlise a respeito do mtodo QualiCES aps a sua validao por meio de um estudo de caso.

6.2.5 Anlise do Mtodo QualiCES

O QualiCES proposto neste trabalho tem por objetivo inspecionar documentos e artefatos de software ainda na fase de especificao de software com intuito de analisar a consistncia entre esses documentos. Para isso, o mtodo proposto apoiou-se em um checklist desenvolvido para esse a fim, e analisou os resultados a partir de uma mtrica de consistncia tambm proposta para esse trabalho. Para esse estudo considerou-se que o mtodo desenvolvido enquadra-se como uma forma de inspeo de software, que por sua vez pertence ao processo de validao e verificao de software. Como mencionado na Seo 2.2, o processo de V & V uma das formas de garantir a qualidade de software. Neste sentido, com a aplicao do mtodo QualiCES, alguns atributos de qualidade puderam ser analisados: completude, consistncia interna, alcanabilidade, rastreabilidade, corretude e preciso. 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 prottipo, alm de ter todas as informaes necessrias no requisito funcional correspondente; Consistncia Interna: os requisitos funcionais, casos de uso e prottipos no podem conflitar entre si; Alcanabilidade: o prottipo relacionado ao caso de uso deve acompanhar toda a sua descrio e a especificao do requisito funcional; Rastreabilidade: cada requisitos e caso de uso devem ser corretamente identificados para que possam ser rastreveis; Corretude: a funcionalidade representada pelo caso de uso e pelo prottipo deve representar exatamente o que a funcionalidade deve fazer, a qual deve ser exatamente especificada pelo requisito funcional; Preciso: Os requisitos funcionais e casos de usos devem ser precisamente descritos a fim de garantir a alcanabilidade por parte do prottipo. As regras descritas na Seo 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 mtrica de consistncia definida neste estudo Regra 1.1 Regra 1.3 Completude Regra 2.2 Regra 2.4 Consistncia Interna Regra 2.3 Regra 1.2 Alcanabilidade Regra 2.1 Regra 3.1 Regra 5.2 Regra 1.3 Regra 2.4 Regra 3.23 Regra 3.1 Regra 3.2 Regra 3.3

77

Regra 5.2 Rastreabilidade Regra 2.1 Regra 1.1 Corretude Regra 2.1 Regra 2.4 Regra 1.1 Regra 2.1 Preciso Regra 2.4 Regra 3.2 Regra 4.1 Regra 2.2 Regra 1.2 Regra 2.2 Regra 3.1 Regra 1.3 Regra 2.2 Regra 3.1 Regra 3.3 Regra 5.2

Como pode ser visto, todos os atributos so cobertos por mais de uma regra. Assim, possvel afirmar que o uso do checklist auxilia no processo de garantia de qualidade de software.

78

CONSIDERAES FINAIS
Em tempos em que informatizar o conhecimento humano tornou-se necessrio, o

desenvolvimento de software com mais rigor e qualidade tambm se tornou necessrio. A busca e o desejo por qualidade de software podem ser alcanados e supridos por meio de diversas tcnicas que apoiam nesse processo. O desenvolvimento de software, na sua forma mais simplista, composta pelas fases de especificao de software, design e implementao de software e pela validao do software. Muitos estudos relatam que deixar o processo de validao e verificao de software somente para o final do processo acaba exigindo um custo e esforo 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 mtodo chamado QualiCES, que deve ser aplicado na fase de especificao de software. Diversas tcnicas que apoiam o processo de inspeo de software foram identificadas durante a pesquisa bibliogrfica. Essas tcnicas foram avaliadas em termos de eficcia e efetividade por meio da comparao entre elas. Alm disso, foi notado que na literatura analisada, os estudos prezavam por analisar a qualidade por meio das tcnicas de inspeo de software, na sua grande maioria, como foi relatado na seo 3.1 deste trabalho. Estas tcnicas, entretanto avaliavam apenas a qualidade dos casos de uso. Portanto, sentiu-se falta de estudos que analisassem a consistncia entre os documentos e artefatos, que encontrasse defeitos e que prezasse pela qualidade de software desde o incio do processo de desenvolvimento. Com esse objetivo, foi proposta, o QualiCES, um mtodo para verificao de software avalia a consistncia entre os documentos e artefatos ainda na fase de especificao de software. Assim, o restante desde captulo est organizado da forma que se segue.

79

A seo 7.1 apresenta os resultados obtidos em relao ao que foi proposto para esse trabalho. J a seo 7.2 discute as limitaes e prope trabalhos futuros relacionados a este.

7.1 Resultados Obtidos

Diante da atual preocupao existente pela garantia da qualidade de software, este estudo props um mtodo, o QualiCES, o qual por meio da deteco de defeitos e por meio da anlise da consistncia entre documentos e artefatos relacionados ao processo de especificao de software, pudesse trazer qualidade ao software em

desenvolvimento. Este estudo como alguns outros identificados na literatura, consideram que defeitos detectados logo no incio do processo da especificao do software diminuem os custos e os esforos por dimurem o retrabalho nas fases posteriores do desenvolvimento de software. Dessa forma, auxilia-se a obteno de qualidade desde o comeo da vida do software. O mtodo QualiCES prope uma sequncia de passos alinhados com as fases de desenvolvimento de software deve ser aplicado na fase de especificao de software. Ele objetiva analisar a consistncia entre documentos e artefatos de software nessa fase do desenvolvimento. Para tanto, o mtodo propem um checklist, que torna a avaliao mais independente de pessoas. O checklist proposto analisa cinco itens (contedo, funcionalidade, execuo da funcionalidade, dependncia entre funcionalidades e usurios) que relacionam o documento de requisitos, descrio de casos de uso e prottipos de tela como forma de verificar a consistncia entre eles. Alm disso, o mtodo prope uma mtrica de consistncia, a qual se baseia em dados obtidos por meio da aplicao do checklist e sempre que uma regra de consistncia no estiver em conformidade. Os defeitos detectados so classificados e analisados em trs itens: defeito atrapalha o alcance do objetivo da funcionalidade (sim ou no), urgncia de correo do

80

defeito (imediatamente, mdio prazo e curto prazo) e importncia da funcionalidade na perspectiva do usurio (muito importante, importante e pouco importante). Com a obteno desses dados, possvel realizar a classificao em consistente, pouco consistente e inconsistente, baseando-se em valores definidos pelo mtodo QualiCES. O mtodo proposto ainda prope uma forma de, claramente, mostrar os resultados da inspeo. Para que o mtodo QualiCES proposto neste estudo pudesse ser testado e analisado, foram utilizados documentos de requisitos, descrio de casos de uso e de prottipos de tela do software em desenvolvimento pelo grupo de pesquisa Social eGov desenvolvida por um grupo da UFMT. A aplicao do mtodo QualiCES diz que para cada caso de uso e prottipo correspondente, deve-se aplicar o checklist proposto uma vez. Assim, de acordo com a documentao tida em mos, o checklist foi aplicado 17 vezes e, para cada uma, a mtrica de consistncia, tambm proposta por esse estudo, foi aplicada, resultando na classificao de consistncia 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 classificao, nos seis casos consistentes, doze defeitos foram encontrados; nos sete pouco consistente, cinquenta e quatro defeitos foram detectados; e nos quatro inconsistentes, quarenta e trs defeitos foram encontrados. Contudo, alm da deteco de defeitos, como era desejado, o mtodo 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, consistncia interna, alcanabilidade, rastreabilidade, corretude e preciso. Dentro do que foi proposto nos objetivos deste estudo e por meio do estudo de caso realizado, conclui-se que eles foram alcanados: foi definido um mtodo de

81

validao e verificao para a fase de especificao de requisitos, inspeo de software; foi definido um mtodo de avaliao que apoiasse o processo de validao e verificao, o QualiCES; e foram desenvolvidos um checklist e uma mtrica de consistncia que auxiliassem na aplicao do mtodo e anlise dos dados obtidos com a aplicao do checklist, respectivamente.

7.2 Limitaes e Trabalhos Futuros

Esse estudo, conforme definido na Seo 1.3 deste trabalho, limitou a aplicao do mtodo QualiCES em apenas um caso. Dessa forma, este um estudo inicial que carece de mais testes para que, tanto o checklist quanto a mtrica de consistncia possam ser validados e comprovados, alm de serem melhorados. Estes outros estudos iro calibrar os valores QC da mtrica de consistncia desenvolvida neste trabalho. Alm disso, necessrio que outros revisores utilizem o mtodo como forma de validar o mtodo bem como analisar o entendimento deles na aplicao do checklist e da mtrica desenvolvidos. Assim, trabalhos futuros espera-se, portanto, i) realizar mais experimentos em outros projetos, e ii) analisar a aplicao do mtodo por parte de outros revisores. Ainda, pode ser considerado como trabalho futuro, o desenvolvimento de uma ferramenta que automatize o mtodo QualiCES, auxiliando na aplicao e anlise dos resultados desse processo. Esse trabalho restringiu-se a inspeo da fase de especificao de software. Assim, como trabalho futuro, deseja-se que eo mtodo de inspeo seja adaptado para a anlise de consistncia entre os documentos e artefatos de software relacionados aos requisitos no funcionais, mais especificamente na rea de usabilidade e acessibilidade, analisando a interao humano-computador.

82

REFERNCIAS BIBLIOGRFICAS

ANDA, Bente, SJBERG, Dag I. K., Towards na Inspection Technique for Use Case Models. SEKE02 -14th IEEE Conference on Software Engineering and Knowledge Engineering, Ischia, Italy, July 15-19, 2002, pp. 127-134. AURELIO, Dicionrio Aurelio Online. Disponvel 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 prticas 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 Produo de software do Cercomp. 2010. Disponvel em:

<http://www.cercomp.ufg.br//uploads/files/17/manual.pdf>, Acessado em: 10/11/11 DELAMARO, E., MALDONADO, J.C., JINO, M. Introduo ao teste de software. Rio de Janeiro, RJ: Campus Elsevier, 2007. ELBERZHAGER, F., MNCH, 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, Rosngela, Uma proposta de inspeo de em modelos de caso de uso. So Paulo, 2007. Dissertao de mestrado. Instituto de Pesquisas Tecnolgicas do Estado de So 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 mtodo para avaliao da qualidade dos stios de e-Gov.

84

In: VIII ESCOLA DE INFORMTICA 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. Disponvel em:

<http://www.euax.com.br/system/attachments/4/original/2006.013Metricas_software.pdf?1265047553> Acessado em: 10/09/2011. MELO, Silvana M., Inspeo de Software. USP: So Carlos, SP, 2009. Disponvel 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 Informao Multi-Modelo. Goinia, 2010. Dissertao de Mestrado. Instituto de Informtica, Universidade Federal de Gois. MPS.BR. MPS. BR Guia de Melhoria de Processo do Software Brasileiro. 2011. Disponvel 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 Introduo a Teste de Software. DevMedia, 2009. Disponvel Acessado em: em:

<http://www.devmedia.com.br/articles/viewcomp.asp?comp=8035>, 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. So Paulo: McGraw-Hill, 2006.

85

PRESSMAN, R. S., Software Engineering A Practitioners Approach, 5 ed. McGraw-Hill International, London. 2000. SOCIAL E-GOV a, Projeto. Documento de Interface. Cuiab, MT.2010 _______________. Documento de Viso. Cuiab, MT.2010 _______________. Prottipos de Tela. Cuiab, MT.2010 SOMMERVILLE, I. Engenharia de Software So Paulo, SP: Pearson AdissonWesley, 2007. SWEBOK, Software Engineering Body of Knowledge IEEE Computer Society, 2004. Disponvel 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

APNDICE A - Checklist QualiCE

O modelo checklist utilizado no mtodo QualiCES apresentado na Tabela 8. Este checklist foi aplicado em 17 casos de uso e 17.
Tabela 8 - Checklist proposto para o mtodo QualiCES.

Componente: Caso de Uso: Prottipo:

Subcomponente:

Concluso Atrapalha o alcance do objetivo? (sim ou no)

Contedo A descrio do UC atende o seu objetivo?

A descrio do Caso de Uso deve ser a especificao detalhada do seu objetivo, de forma a atender as suas funcionalidades previstas.

possvel, por meio do uso do prottipo sugerido, atingir o objetivo do caso 2 de uso (por meio da descrio)?
O prottipo desenvolvido deve atingir o objetivo do Caso de Uso por meio da sua descrio.

No se aplica

Em partes

Itens analisados/Perguntas No Sim

Qual a Qual a importncia urgncia da da correo? funcionalidad Justificativas (imediatame e? (muito /Observae nte, mdio importante, s prazo ou importante, curto prazo) pouco importante)

87

Para cada atributo definido no dicionrio de dados do UC, respeitado seu tipo, mscara, domnio, 3 tamanho e atributos no prottipo?
O prottipo deve seguir todas as definies do Dicionrio de Dados descrito no Caso de Uso.

Os rtulos de botoes das informaes nos prottipos permitem intuitivamente identificar a inteno do UC? Os ttulos dos 4 botes das informaes no prottipo deve permitir ao usurio, intuitivamente, identificar o objetivo do Caso de Uso. Funcionalidade As funcionalidades representadas no prottipo, so 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 prottipo que no foi descrita no 6 UC?

O Caso de Uso deve descrever todas as funcionalidades representadas pelo prottipo.

H requisitos identificados nesse UC que no 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 contradio entre os requisitos relacionados ao 8 UC?

Os requisitos funcionais identificados no caso de uso no devem ser conflitantes entre si.

89

Todas informaes necessrias para o UC foram descritas nos requisitos 9 funcionais?

As informaes descritas nos requisitos funcionais devem ser as mesmas informaes presentes no caso de uso e no prottipo.

Todas as informaes descritas nos requisitos funcionais foram seguidas no 10 prottipo?

O prottipo deve seguir todas as informaes 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 descrio.

Qual(is)?

12 As pr-condies definidas no caso de uso devem ser identificveis no prottipo.

Execuo da funcionalidade As pr-condies do UC foram consideradas no prottipo?

90

13 A descrio do caso de uso deve especificar o fluxo principal e alternativo da forma mais completa possvel para que o prottipo permita que cada passo seja seguido.

possvel executar cada um dos passos do fluxo principal utilizando-se do prottipo definido?

Durante a inspeo do UC e do prottipo, todos os passos apresentados pelo prottipo foram 14 descritos no fluxo principal?
Os passos dos fluxos do Caso de Uso devem ser exatamente os mesmos passos a serem executados no prottipo.

H algum passo faltante que no foi identificado nem no fluxo principal nem no 15 prottipo?
Todos os passos necessrio para atingir o objetivo da funcionalidades devem ser descritos e representados.

possvel executar cada um dos passos do fluxo alternativo 16 utilizando-se do(s) prottipo(s) definido(s)?
A descrio do caso de uso deve

91

especificar o fluxo principal e alternativo da forma mais completa possvel para que o prottipo permita que cada passo seja seguido.

Durante a inspeo do UC e do prottipo, todos os fluxos alternativos e/ou restries possveis 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 prottipo.

H algum passo faltante que no foi identificado nem no fluxo alternativos nem 18 no prottipo?
Todos os passos necessrio para atingir o objetivo da funcionalidades devem ser descritos e representados

Os fluxos documentados no UC so os nicos permitidos na interao descrita 19 no prottipo?

Os fluxos descritos no caso de uso devem ser os nicos permitidos pelo prottipo.

92

As aes decorrentes das ps-condies do UC so perceptveis no 20 prottipo?

As ps-condies quando muito importantes, devem ser identificadas no prottipo.

Dependncia 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 includo deve ser identificado corretamente pelo caso de uso dependente.

Qual(is)?

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 includo deve ser identificado corretamente pelo caso de uso dependente

23

Se h include, o prottipo considera as aes do UC includo?

O prottipo de um caso de uso dependente de outro caso de uso deve considerar o caso de uso includo.

93

Se no h include, deveria existir alguma relao com outro UC?

Quando um caso de 24 uso depender de outro caso de uso, o caso de uso includo deve ser identificado corretamente pelo caso de uso dependente.

Qual(is)?

Usurios Os diferentes grupos de usurios 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 usurios que possam vir a utilizar o sistema so identificveis 26 no prottipo?
Todos os atores identificados no caso de uso devem ser considerados nos fluxos do caso de uso e no prottipo.

O nome do ator reflete seu papel no UC?

O caso de uso e o prottipo deve 27 considerar exatamente o papel dos atores identificados de acordo com a descrio de cada ator.

94

O nome do ator reflete seu papel no prottipo?

O caso de uso e o prottipo deve 28 considerar exatamente o papel dos atores identificados de acordo com a descrio de cada ator.