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