RACHEL SANTANA OLIVEIRA. QTest: Uma Metodologia de Teste para a Qualidade no Processo de Software

Tamanho: px
Começar a partir da página:

Download "RACHEL SANTANA OLIVEIRA. QTest: Uma Metodologia de Teste para a Qualidade no Processo de Software"

Transcrição

1 RACHEL SANTANA OLIVEIRA QTest: Uma Metodologia de Teste para a Qualidade no Processo de Software Joinville 2008

2 RACHEL SANTANA OLIVEIRA QTest: Uma Metodologia de Teste para a Qualidade no Processo de Software Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação Orientador: Roberto Silvio Ubertino Rosso Jr. Doutor Joinville 2008

3 RACHEL SANTANA OLIVEIRA QTest: Uma Metodologia de Teste para a Qualidade no Processo de Software Este Trabalho de Conclusão de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação do CCT/UDESC. Aprovado em 11 de julho de 2008 BANCA EXAMINADORA Roberto Silvio Ubertino Rosso Jr. Doutor Edicarsia Barbiero Pillon Mestre Edson Murakami Doutor Éverlin Fighera Costa Marques Mestre Salvador Antonio dos Santos Mestre

4 Resumo Em um processo de desenvolvimento, a etapa de teste está fortemente relacionada à qualidade do sistema. Para que se tenha um bom resultado nesta etapa de teste é necessário um modo sistemático para a sua realização. Este trabalho de conclusão de curso visa a construção de uma metodologia para a realização de testes de forma sistemática e organizada. O trabalho contém o levantamento de algumas iniciativas de qualidade, a definição de modelos de processos bem como considerações sobre testes, tipos, técnicas e estratégias. Por final foi feita a explicação e posterior validação da metodologia proposta, além de uma conclusão com a definição das hipóteses alcançadas e comparativos com alguns modelos de processos verificados no trabalho. Finalmente foram explanadas as vantagens bem como sugestões de melhoria que podem ser desenvolvidas em trabalhos futuros. Palavras-chaves: metodologia de teste, teste de software, casos de teste, qualidade de software

5 Abstract In a process development, the test phase is strongly related to the system quality. To achieve a good result in this phase it is necessary to take a systematic way of testing. This work aims the construction of a Methodology to perform tests in such a systematic an organized way. The work has a list of some quality initiatives, define process models and gives some considerations on test strategies and techniques. At last, the proposed methodology has been explained and validated. Besides, a conclusion defining the achieved goals and comparations between some process models defined at this work. Finally, some advantages and improvement suggestions of future development were explained. Keywords: testing methodology, software testing, test case, software quality

6 Sumário Lista de Figuras 7 Lista de Tabelas 9 1 Introdução Objetivo geral Objetivos específicos Hipóteses acerca da metodologia Organização do Trabalho Iniciativas para a qualidade no processo de Engenharia de Software Introdução Elementos fundamentais na Engenharia de Software O processo O processo de software e algumas normas que contribuem com a sua qualidade ISO Modelo de Maturidade da Capacidade - CMM (Capability Maturity Model) Integração do Modelo de Maturidade da Capacidade - CMMI NBR ISO/IEC Processos de ciclo de vida de software SPICE (ISO/IEC 15504) Conclusões sobre qualidade no processo de software Visão genérica da Engenharia de software e Modelos de Processo Introdução

7 3.2 Engenharia de Software e sua composição Modelos de processo O modelo em cascata Modelo Incremental Modelo Espiral Desenvolvimento evolucionário Desenvolvimento formal de sistemas Desenvolvimento baseado em componentes Rational Unified Process - RUP Métodos Ágeis Resumo do Capítulo Teste de software Introdução Princípios básicos Estratégias de Teste Teste de Unidade Teste de Integração Teste de Validação Teste de Sistema Método dos Testes Mais Importantes - MITs Norma IEEE Resumo do Capítulo Metodologia de Teste para a Qualidade no Processo de software: QTest Introdução Elementos que deram base à metodologia de teste desenvolvida no trabalho A metodologia proposta

8 5.3.1 Conhecer os Requisitos e/ou elaborar conjecturas Validar os Requisitos Apanhar tudo o que pode ser testado Utilizar um critério de Escolha para Testar o que for mais Importante Planejar o Teste Especificação do Projeto de Teste Especificação dos Casos de Teste Execução dos Testes Relatório-Resumo dos Testes Resumo do Capítulo Validação da Metodologia Introdução O sistema utilizado para a Validação Conhecer os Requisitos e/ou Elaborar Conjecturas Apanhar tudo o que pode ser testado Critério de Escolha dos Testes Mais Importantes Teste de Requisitos Caso de uso Verificar assinaturas de documentos Caso de uso Manipular Keystore Caso de uso Manipular Assinaturas Digitais Documento Plano de Teste Projeto de Teste Projeto de Especificação dos Casos de Teste Execução dos Casos de Teste e Relatório de Incidentes Relatório-Resumo Teste Considerações Finais 113 5

9 Referências 137

10 Lista de Figuras 1.1 Elementos para a Qualidade Cronologia Os cinco níveis do maturidade do processo de software Os cinco níveis do maturidade do modelo CMMI Modelo em Cascata Modelo em Incremental Modelo Espiral Desenvolvimento Evolucionário Desenvolvimento Formal de Sistemas Modelo em Cascata com Teste compondo todas as etapas Relacionamento entre as práticas e as ferramentas Intersecção entre três vertentes que gera o método Ágil Processo Genérico de Teste Estágios de um processo de teste Testes de unidade Módulo de programa Curva S Relacionamento entre os documentos Fluxos dos Casos de Teste Representação do Modelo V (WIEGERS, 2003)

11 5.3 Cálculo para definição da criticidade para o apanhado de itens de teste de uma dada funcionalidade Relacionamento entre as etapas da Metodologia Teste de Requisitos procede a fase de Especificação dos Requisitos do Software Documentação utilizada para a construção do Plano de Teste (CRESPO et al., 2000) Documentação utilizada para a construção do Projeto de Teste (CRESPO et al., 2000) Documentação utilizada para a construção da Especificação dos Casos de Teste (CRESPO et al., 2000)

12 Lista de Tabelas 5.1 Custo da remoção de erros se multiplica através do ciclo de vida

13 10 1 Introdução As conseqüências de um software mal desenvolvido criam dúvidas com relação à qualidade e, conseqüentemente, com o seu conceito. Este conceito e sua aplicação é muitas vezes ignorado no mundo do software além disto existem algumas características que dificultam a obtenção da melhoria no processo de desenvolvimento de um sistema, tais como (KENETT; BAKER, 1999): Perda de dados: muitas organizações não têm idéia de quais dados compõem o desenvolvimento e, quando sabem, muitas vezes não têm a informação de como utilizá-los; Alto foco no mercado: preocupação com aquisição e atualizações de produtos, não dando ênfase à satisfação do cliente; Custo: o dinheiro muitas vezes é investido em aquisição de novas ferramentas ou equipamentos de computação e muito pouco investido na melhoria do processo; Gerentes que não entendem o processo: muitas organizações de desenvolvimento de software possuem desenvolvedores que sabem gerar códigos sob extrema pressão, mas não são supridos de um ambiente cujo foco é a qualidade. Estes, muitas vezes, tornam-se líderes de projetos, ou gerenciadores de desenvolvimento. Mas a questão que se faz diante desta situação é, por que os gerenciadores nunca seguiram o processo como desenvolvedores? Isto se refere ao conhecimento que todos devem possuir para seguir um caminho de qualidade; Gerenciamento Passivo: muitos gerentes que implementam melhoria acreditam que ela pode ser feita apenas de forma passiva, na qual ele não acompanha o processo em todas as suas etapas, preocupando-se apenas com o resultado. Existem outros fatores que não contribuem para um processo efetivo de melhoria. Porém este processo pode ser implementado e gerenciado de forma efetiva, através de plano e de monitoramento cuidadosos (KENETT; BAKER, 1999). Este tipo de execução efetiva de gerenciamento de processo pode ser considerada uma busca pela qualidade.

14 1 Introdução 11 Apesar da qualidade ser uma abstração de difícil descrição, sobre a qual uma definição comumente entendida e universalmente aceita é dificilmente encontrada (KENETT; BAKER, 1999), existem maneiras de se alcançar um bom nível de qualidade através do estabelecimento de atividades que apóiam sua obtenção. Antes de discorrer sobre estas atividades vê-se a necessidade de se definir a qualidade de software. Qualidade de software pode ser vista como a qualidade dos processos que participam do desenvolvimento, sendo assim, este nível de qualidade pode ser obtido pela melhoria da qualidade dos processos (TSUKUMO et al., 1997). Esta melhoria pode ser alcançada por meio da utilização de modelos de definição, avaliação e melhoria de processos. Estes modelos serão explanados no capítulo 2. Os processos de software podem ser analisados por meio de alguma(s) das iniciativas de qualidade. Existem elementos que irão apoiar os processos de forma que os mesmos sejam aprovados com relação à sua qualidade. Estes elementos podem ser vistos na figura 1.1. O foco do presente trabalho foi a construção e validação de uma Metodologia de Teste (um destes elementos) com o intuito de contribuir com o alcance da qualidade almejada para que a empresa que desenvolve seus processos tenha uma maior oportunidade de obter alguma certificação de qualidade e, o principal, um produto de software com qualidade, gerado por um processo que foca na melhoria do ciclo de desenvolvimento. Uma metodologia de teste sistemática é necessária pelo fato de existirem fatores que afetam a realização eficiente de um processo de teste, dificultando o processo de aquisição de qualidade, fatores estes que aumentam os custos da produção. As razões para que a execução dos testes não funcione adequadamente são (RIOS, 2005): Nem todos os requisitos são testados (por exemplo, não há requisitos de teste); Processos formais de teste inexistentes ou mal-definidos; Teste é considerado uma atividade dentro do processo de desenvolvimento; Pouca importância atribuída ao processo de testes; Equipe de testes não qualificada; Defeitos só detectados em produção, onde custam 100 a 1000 vezes mais para serem consertados;

15 1 Introdução 12 Abordagens únicas para novas tecnologias; Falta de automação de testes; Falta de metodologia de teste. O foco do presente trabalho foi a construção e validação de uma Metodologia de Teste, considerado um dos elementos essenciais para o alcance da qualidade. A sua utilização pode contribuir na obtenção de alguma certificação de qualidade pela empresa que a utiliza. A figura 1.1 contém a representação de alguns dos elementos básicos para a qualidade. Figura 1.1: Elementos para a Qualidade. (KENETT; BAKER, 1999) A metodologia proposta e validada verificou, dentre os vários aspectos do teste, que o teste de software tem o propósito de assegurar que sistemas de software trabalhem de acordo com o esperado pelos usuários (TIAN, 2005). Em suma, este processo deve completar dois propósitos primários: Demonstrar a qualidade ou comportamento próprio; Detectar e consertar problemas. Outro fator verificado foi que a atividade de teste possui seus princípios básicos a serem seguidos para um bom processo de teste, bem como algumas perguntas e respostas que devem dar base para esta atividade, como pode ser visto na seção 5.2. A elaboração de uma metodologia foi fundamentada no conhecimento e prática destes princípios, bem como na tentativa de responder a perguntas essenciais para um

16 1.1 Objetivo geral 13 processo de teste. Outros aspectos que fundamentaram a metodologia de teste foi a análise do momento em que os erros são melhores detectados e corrigidos sem muitos custos bem como a verificação de que a atividade de testes depende do tempo disponível, ou seja, é necessário escolher o que for prioritário para ser testado. Todos estes fatores serão melhor detalhados no decorrer do trabalho, que explana também sobre algumas iniciativas de qualidade por se tratarem de elementos importantes para uma organização de software e, além disso, possuem o teste nos seus respectivos processos de melhoria. 1.1 Objetivo geral Este Trabalho de Conclusão de Curso possui como objetivo principal a elaboração e validação de uma Metodologia de Teste, denominada QTest visando o alcance de maior qualidade em um processo de desenvolvimento de software e fazendo, ao final, uma análise da metodologia. 1.2 Objetivos específicos Os objetivos específicos necessários para se contemplar o objetivo geral estão descritos abaixo: Levantamento teórico e estudo acerca de qualidade e suas Iniciativas ; Estudo e visão genérica sobre Engenharia de Software e modelos de processos, com o intuito de situar a atividade de teste no processo de desenvolvimento; Definição e levantamento de princípios básicos das atividades de teste, sobre os quais se assentam os métodos e as técnicas, bem como a justificativa da importância desta atividade como participante de um processo de qualidade; Conhecimento de alguns atributos que dão base à Metodologia proposta pelo trabalho, fazendo um levantamento de padrões e normas para qualidade e/ou teste de software; Levantamento das principais metodologias de teste de software.

17 1.3 Hipóteses acerca da metodologia Hipóteses acerca da metodologia A Metodologia a ser utilizada deve: Servir como um guia para a atividade de teste; Facilitar a atividade de teste com a verificação de erros na fase de definição dos requisitos; Auxiliar o processo de escolha dos testes mais importantes, dando como opção a utilização de algum critério de análise de riscos; Ser independente do modelo de processo utilizado no desenvolvimento de uma dada aplicação a ser testada; Organizar o processo de teste através de uma documentação padronizada. 1.4 Organização do Trabalho Este trabalho está organizado da seguinte forma: O Capítulo 2 expõe os conceitos de qualidade e algumas iniciativas que a compõem; O Capítulo 3 mostra uma visão genérica sobre Engenharia de Software e seus modelos de processos; O Capítulo 4 discute estratégias de teste de Software; O Capítulo 5 explica a Metodologia construída, bem como os conceitos sobre os quais ela é baseada; O Capítulo 6 traz a validação da metodologia QTest; O Capítulo 7 traz as conclusões do trabalho e expõe os benefícios trazidos pelo metodologia bem como algumas sugestões de melhoria para trabalhos futuros;

18 15 2 Iniciativas para a qualidade no processo de Engenharia de Software 2.1 Introdução A Engenharia de Software é uma tecnologia em camadas. As quatro camadas que a compõem são camada de foco na qualidade, camada de processo, camada de métodos e camada de ferramentas, onde a primeira serve de alicerce para todas (PRESSMAN, 2002). No que tange à qualidade do software, existem algumas iniciativas que serão abordadadas neste capítulo devido à necessidade de se saber sobre processos de qualidade, são elas : os modelos CMM (Capability Maturity Model) e CMMI (Capability Maturity Model Integration), o projeto SPICE (Software Process Improvement and Capability determination) e as normas ISO Estas iniciativas são mencionadas e definidas neste trabalho por serem consideradas certificados para as empresas que possuem os elementos de qualidade necessários. Uma metodologia de teste pode contribuir de forma enfática para o alcance de alguma destas certificações. Antes da discussão das iniciativas que envolvem um processo de qualidade serão discutidos Processo de software, os elementos fundamentais que envolvem a Engenharia de Software e introduzida a evolução da construção das normas e modelos de qualidade. Será explanado sobre processo de software, visto que as normas de qualidade visam não apenas a qualidade do produto, mas também dos processos. Além disso será falado sobre Engenharia de software, pois os elementos que a compõem dão a base às normas de qualidade que tratam do software. 2.2 Elementos fundamentais na Engenharia de Software Existem várias definições de Engenharia de Software, mas ela pode ser vista como o estabelecimento e o uso dos princípios básicos de engenharia com o intuito de obter software

19 2.3 O processo 16 de maneira sistemática e econômica, que seja confiável e que trabalhe eficientemente em máquinas reais (NAUR; RANDALL, 1969). Conforme dito na seção anterior, a Engenharia de Software é uma tecnologia dividida em camadas, devido à necessidade que qualquer engenharia tem de estabelecer um comprometimento com a qualidade. Sendo assim, a base de uma Engenharia de Software é o foco na qualidade. O fundamento para a Engenharia de Software é a camada de processo, na qual são estabelecidos os objetivos parciais, onde a qualidade é assegurada, e as mudanças são propriamente gerenciadas (PRESSMAN, 2002). Através de processos os métodos são ligados às ferramentas (ROCHA; MALDONADO; WEBER, 2001) e é na camada de ferramentas que são controlados os projetos de software. A camada de métodos da Engenharia de software é composta de conjuntos de tarefas que incluem análises de requisitos, construção do programa, teste e suporte. Um método é a forma como as atividades são modeladas e como as técnicas são descritas, no qual o software é construído sob bases técnicas (ROCHA; MALDONADO; WEBER, 2001). A camada de ferramentas modela o ambiente no qual o produto do software está sendo desenvolvido. Ela oferece suporte automatizado aos métodos e processos que, quando são agregados, apresentam melhores resultados. (FUTRELL; SHAFER; SAFER, 2002). A próxima seção irá tratar do Processo, pois é onde a Engenharia de Software está fundamentada. 2.3 O processo Software de Computador é um conjunto de informações projetadas e construídas por um engenheiro de software e um conjunto de transformações e decisões associadas entre si (PRESSMAN, 2002). As informações de um software encontram-se em diferentes níveis de abstração (ROCHA; MALDONADO; WEBER, 2001). O engenheiro de software constrói o sistema e este é usado direta ou indiretamente em qualquer área do mundo informatizado. Paralelamente a essa universalização de sistemas de informação, existe uma grande exigência, por parte de usuários de sistemas quanto aos níveis cada vez maiores de qualidade. Para se construir um software de computador, são necessários os mesmos requisitos de construção de qualquer produto de sucesso, aplicando um processo guiado para um

20 2.3 O processo 17 resultado de alta qualidade e conhecendo as necessidades de pessoas que irão utilizar o produto. Mas antes de tratar de processo de software, é importante saber sua diferença com relação ao termo produto. Produto de software é gerado por um conjunto de atividades e resultados associados, ou seja ele resulta do processo de software. De um ponto de vista técnico, o processo de software é definido como um ambiente de trabalho para tarefas, que são requisitadas para a construção de um software de qualidade e essa abordagem é aplicada à Engenharia de Software (PRESSMAN, 2002). É importante também o conhecimento de conceitos de medição e métricas, além do esclarecimento sobre o processo de maturidade do software. Além de aspectos técnicos, outros são fundamentais para o sucesso no estabelecimento e na evolução dos processos de software, são eles: as características da organização, do pessoal técnico e do domínio da aplicação. A preocupação com a satisfação desses aspectos evidencia-se na norma internacional NBR ISO/IEC Tecnologia da Informação - Processos de Ciclo de Vida do Software, que classifica os processos em: fundamentais, de apoio, organizacionais, e de adaptação (ROCHA; MALDONADO; WEBER, 2001). Essa norma estabelece processos, atividades e tarefas que serão aplicadas durante a aquisição, fornecimento, desenvolvimento, operação e manutenção do software de um sistema. Seu estudo irá focar as atividades que envolvem teste. No que se refere à qualidade do software existem modelos que podem ser usados como referência para a avaliação de capacitação das organizações em processos de software, são eles: o modelo CMM (Capability Maturity Model), CMMI (Integração do Modelo de Maturidade da Capacidade), o projeto SPICE (Software Process Improvement and Capability determination), que elaborou a norma ISO 15504, e normas ISO 9000 (FILHO, 2000). O CMM trata de um modelo de capacitação específico para a área de software. Outras áreas importantes para uma organização produtora de software estão fora do escopo deste modelo. CMMI é um modelo mais recente e também provê auxílio no desenvolvimento de processos efetivos. O projeto SPICE visa dar subsídios para a melhoria de processos e para a determinação da capacidade do processo (EMAN; DROUIN; MELO, 1998). As normas ISO 9000 são conhecidas por todos os países e setores, além do setor de software e, segundo Rada (1996), a conquista da certificação ISO 9000 significa o alcance

21 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 18 internacional de qualidade nos processos para uma empresa. Em contrapartida, existem críticas desfavoráveis que atingem a família ISO 9000 (STELZER; MELLIS; HERZWURM, 1996), serão abordadas na seção O processo de software e algumas normas que contribuem com a sua qualidade As normas de qualidade discutidas neste capítulo não surgiram ao mesmo tempo, a elaboração delas seguiu uma ordem cronológica evidenciada na figura 2.1. A presente seção será composta da definição de algumas normas colocadas na figura 2.1. A explicação destas normas e modelos serão dadas seguindo a mesma ordem em que foram desenvolvidas, com exceção do CMMI que será explicado logo após o modelo CMM. Antes do detalhamento destas iniciativas será feita uma rápida visão acerca de processos e qualidade. Figura 2.1: Cronologia. (SHEARD, 1997) Segundo a norma internacional ISO/IEC 12207, em um processo de desenvolvimento de software existem atividades e processos básicos, independentemente de sua complexidade. Antes de serem discutidos esses processos e atividades é importante definir processo e qualidade de software: Processo é um conjunto limitado de atividades relacionadas que adquirem um ou mais tipos de entradas e criam saídas que são de grande valia para o cliente por meio de uma ou mais transformações. Na Engenharia de Software, transformações são feitas das requisições do usuário para o software (FUTRELL; SHAFER; SAFER, 2002).

22 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 19 Qualidade é a camada que serve como base à Engenharia de Software e, de forma análoga, a todas as outras camadas que a compõem. No que se refere a essa qualidade do processo de software existem as iniciativas mencionadas na seção 2.3 que serão elucidadas nas próximas seções. Este Trabalho de Conclusão de Curso diz respeito à construção e validação de uma metodologia de teste. Testar faz parte de qualquer processo de qualidade, dessa forma, a discussão das iniciativas citadas acima, dando ênfase ao que se refere a teste, é de fundamental importância, visto que elas focam na qualidade de um processo de software ISO 9000 A norma ISO 9000 estabelece uma estrutura de trabalho de gerenciamento de qualidade. Esta norma foi iniciada em 1979 através do British Standards Institute e visa a necessidade do controle de qualidade de processos relacionados a projetos, desenvolvimento, produção, instalação e serviços associados (ROCHA; MALDONADO; WEBER, 2001; RADA, 1996). A ISO 9000 descreve genericamente os elementos de garantia de qualidade, elementos estes que podem ser aplicados a qualquer negócio de forma independente dos produtos e serviços (PRESSMAN, 2002). Eles compõem um sistema que pode ser definido como uma estrutura na qual é descrita como será implementada a gestão da qualidade (PRESSMAN, 2002). A primeira versão das normas internacinais ISO 9001, 9002 e 9003 para a garantia de qualidade, foi lançada em Hoje em dia, o objetivo é a garantia de qualidade para a satisfação dos clientes (ROCHA; MALDONADO; WEBER, 2001). A partir do momento em que o país adota estas normas, ele permite apenas que as empresas registradas na ISO forneçam bens e serviços a agências governamentais e de utilidade pública (ROCHA; MALDONADO; WEBER, 2001; PRESSMAN, 2002). Dentre as normas que compõem a norma ISO 9000, a ISO 9001 é a mais completa, sendo a norma de garantia de qualidade aplicada à Engenharia de Software. Em um sistema de software devem estar presentes, no mínimo, 20 requisitos contidos nesta norma. Dentre esses requisitos pertinentes, o requisito de teste é um dos que são delineados pela norma ISO 9001 (ROCHA; MALDONADO; WEBER, 2001; PRESSMAN, 2002).

23 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 20 A ISO (International Organization for Standardization) propriamente dita não testa a conformidade à ISO Esta conformidade pode ser verificada das seguintes formas (RADA, 1996): Pela organização que quer obter a certificação e deseja seguir o padrão; Pela organização que compra o produto ou serviço da companhia que deseja obter a certificação; Por uma organização especializada em tal certificação; Para que uma empresa de software se certifique na norma ISO 9000 é necessário atendimento a cada um dos requisitos propostos pela mesma (PRESSMAN, 2002). Para tanto é necessário que a companhia apresente uma documentação que segue o padrão de qualidade, além da necessidade de as pessoas que compõem a empresa seguirem também esta documentação (RADA, 1996). Apesar dos padrões ISO 9000 contribuírem com a qualidade de produto e serviço, existem críticas não-favoráveis a esta família de padrões, críticas estas revisadas em 11 argumentos, entre eles (STELZER; MELLIS; HERZWURM, 1996): Sua implementação nem sempre leva a melhores produtos de software, nem a uma redução do tempo de entrega e também não necessariamente leva à melhora no retorno do investimento. Muitos dos que fazem afirmação contra ISO 9000 não entendem a extensão deste sistema de qualidade. Alguns não coletam dados e nem produzem a documentação esperada, dessa forma vê-se a dificuldade de enxergar a qualidade da certificação. Entretanto, nem sempre as sugestões da ISO 9000 apóiam a organização, devido à necessidade de que os objetivos da organização estejam de acordo com esse sistema de qualidade. Sua aplicação pode ser adequada em grandes companhias de desenvolvimento de software, mas pode não ser adequada a pequenas companhias.

24 2.4 O processo de software e algumas normas que contribuem com a sua qualidade Modelo de Maturidade da Capacidade - CMM (Capability Maturity Model) Trata-se de um modelo com foco no processo de maturidade que define as atividades necessárias neste processo, desenvolvido pelo Instituto de Engenharia de Software, The Software Engeneering Institute (SEI) (PRESSMAN, 2002). Este processo é visto como uma extensão no qual o conjunto de papéis é definido, gerenciado, medido e efetivado. A maturidade indica tanto a riqueza no processo de software da organização quanto à consistência com a qual a maturidade é aplicada aos projetos da organização (PAULK et al., 1993). O modelo CMM organiza os passos de um processo de melhora contínua em cinco níveis de maturidade compostos por funções sucessivas. Estes níveis definem uma escala ordinária para a medida de maturidade de um processo de software de uma organização (PAULK, 1999). Estes cinco níveis são referentes à maturidade que uma organização possui para desenvolver software, são eles: inicial, repetível, definido, gerenciado e otimizado. A figura 2.2 mostra como esses níveis se relacionam. Figura 2.2: Os cinco níveis do maturidade do processo de software. (PAULK, 1999) Antes de definir os cinco níveis, vê-se necessário uma definição do que são Key Process Area (KPA). KPA são áreas-chave que estabelecem grandes temas a serem abordados. Existe um total de 18 áreas-chave, cada uma com algumas práticas-chave que

25 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 22 especificam o que deve ser cumprido, exigindo documentos, treinamentos, ou políticas definidas para as atividades e que totalizam 316 práticas (ROCHA; MALDONADO; WEBER, 2001). A seguir serão definidos os cinco níveis deste modelo. Nível 1 - Inicial: nível que não é composto por nenhuma KPA, no qual o processo de software é considerado caótico, com poucos processos definidos e com o sucesso dependente de esforços individuais. Nível 2 - Repetitível: nesse, nível políticas para gerenciamento do projeto de software e procedimentos para implementar essas políticas são estabelecidas. Ou seja, é onde os métodos de gerenciamento de software são documentados e acompanhados. Um dos objetivos desse nível é institucionalizar processos de gerenciamento efetivos para projetos de software, os quais asseguram às organizações a repetição de práticas em novos projetos, práticas estas que tiveram sucesso quando desenvolvidas em projetos anteriores (PAULK et al., 1993). Existem seis áreas-chave nesse nível (ROCHA; MALDONADO; WEBER, 2001): Gerenciamento de requisitos; Planejamento de projeto de software; Acompanhamento de projeto de software; Gerenciamento de subcontrato de software; Garantia da qualidade do software; Gerenciamento da configuração do software. Nível 3 - Definido: no qual o processo padrão para desenvolvimento é documentado, incluindo tanto a Engenharia de Software quanto os processos de gerenciamento, e esses processos são integrados em um conjunto coerente (PAULK, 1999). Ao todo existem sete áreas-chave neste nível (ROCHA; MALDONADO; WEBER, 2001): Enfoque no processo da organização; Definição do proceso da organização; Programa de treinamento; Gerenciamento integrado de software; Engenharia de produto de software;

26 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 23 Coordenação de intergrupos; Revisões. Nível 4 - Gerenciado: este nível é focado tanto nos produtos do software quanto nos processos, estes são quantitativamente entendidos e controlados. Neste nível as medidas detalhadas do processo de software e da qualidade do produto são coletadas (PAULK, 1999). No nível 4 existem duas áreas-chave: Gerenciamento quantitativo do processo; Gerenciamento da qualidade de software. Nível 5 - Otimizado: focaliza na melhoria contínua do processo, na qual é evitado que mudanças de tecnologia e do próprio processo causem impacto na qualidade do produto final (PAULK et al., 1993). Existem três áreas-chave no nível 5: Prevenção de defeitos; Gerenciamento da mudança tecnológica; Gerenciamento da mudança no processo. CMM: O que se espera com sua implantação? Capability Maturity Model - CMM - para Software descreve princípios e práticas que compõem o processo de maturidade de um software e tem como objetivo ajudar as organizações a melhorar a maturidade em seus conjuntos de papéis, começando de um processo caótico para ditar processos maduros e disciplinados (PAULK et al., 1993). É um dos modelos mais antigos com relação à qualidade do processo de desenvolvimento e conta com uma implantação de longo prazo e utilizado por muitas empresas (ROCHA; MALDONADO; WEBER, 2001). A implantação do nível 2 consiste em mecanismos de gerenciamento de projeto e, por existir um sistema de gerenciamento, neste nível tem-se uma expectativa de que as metas serão cumpridas, sejam elas de esforço, prazo, bem como de custo (ROCHA; MALDONADO; WEBER, 2001). No nível 3 o processo de software é visto como o patrimônio da organização, com a necessidade de ser estudado, aperfeiçoado e melhorado. Existe a preocupação com

27 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 24 a garantia de que o processo é disseminado, compreendido e praticado por todos (ROCHA; MALDONADO; WEBER, 2001). No nível 4 tem-se o conceito de gerenciamento quantitativo, ou seja, as decisões devem ser feitas em bases quantitativas, através de consulta ao banco de dados do processo (ROCHA; MALDONADO; WEBER, 2001). Medidas detalhadas são coletadas e, tanto o processo quanto o produto, são quantitativamente entendidos e detalhados. Informações armazenadas sobre comportamento do processo em projetos realizados anteriormente dão subsídios para que o gerente tome decisões mais confiáveis (PAULK et al., 1993). No nível 5 é introduzido o conceito e a prática de melhoria contínua de processo, esta prática de melhoria é realizada através de feedback quantitativo do processo e da condução de novas idéias e tecnologias (PAULK et al., 1993). A implantação do CMM possui resultados de longo prazo, isso se torna uma grande ameaça devido à tendência à acomodação, havendo a protelação das atividades por diversas vezes, podendo chegar à desistência. O sucesso da implantação dependerá da persistência do responsável pelo projeto (PAULK, 1999). A implantação deste modelo deve vir junto com o investimento dos envolvidos para que o processo seja inteligente e não crie burocracia somente para atender aos quesitos descritos no modelo, ou seja, ele deve ser flexível (PAULK, 1999) Integração do Modelo de Maturidade da Capacidade - CMMI Semelhantemente ao modelo CMM descrito na seção 2.4.2, o modelo CMMI (Capability Maturity Model Integration) provê um auxílio no desenvolvimento de processos (TEAM, 2002). Estes modelos não são processos ou descrições de processos, eles servem de guia para processos das organizações, para melhor gerenciamento do desenvolvimento, aquisição e manutenção dos produtos ou serviços. O CMMI, segundo Silva (2005), é inspirado na norma ISO e desenvolvido pelo SEI (Software Engineering Institute. Este modelo se baseia em um conjunto de capacidades de engenharia de software presentes à medida que a organização alcança níveis maiores (PRESSMAN, 2002). O CMMI é um framework que oferece a habilidade de gerar múltiplos modelos, treinamento associado bem como materiais de avaliação. Este modelo pode ser usado para

28 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 25 ajudar na definição de objetivos de melhoria, melhorar processos e fornecer um guia para assegurar estabilidade, capacidade e maturidade (TEAM, 2002). O modelo CMMI é composto de dois tipos de representação (TEAM, 2002): Representação Contínua Este tipo de representação espera que a organização que a escolhe siga alguns requisitos descritos abaixo: Permite que seja selecionada a ordem da melhoria que melhor reconhece os objetivos de negócio da organização e amenizam as áreas de risco da organização; Permite a comparação de resultados através do uso de estágios equivalentes; Dispõe uma comparação fácil entre o processo de melhoria e a norma internacional ISO/IEC 15504, devido à organização das áreas de processos serem similares. Representação em Estágios Esta representação, quando escolhida, precisa de um modelo que deve: Oferecer uma seqüência provada de melhorias, começando com práticas de gerenciamento básico e progredindo através de um caminho pré-definido de níveis sucessivos, cada um servindo de fundamento para o próximo. Permitir a comparações entre as organizações através da seqüência dos níveis de maturidade. Ambas as representações atentam para resultados equivalentes. Mas o presente trabalho foca no esforço de teste e, em um artigo de Crespo et al. (2004), o processo de teste de software foi considerado com o nível 2 da área de processo de verificação da representação contínua CMMI-SE/SW. Essa conclusão foi resultado de uma avaliação feita sobre um trabalho de teste de uma dada empresa gerenciado, também, pelo pacote CMMI. Assim como o CMM, o modelo CMMI pode ser dividido em 5 níveis de maturidade que contém áreas de processo (PA) (AHERN; CLOUSE; TURNER, 2003), estes cinco

29 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 26 níveis são dividos na representação em estágios. Áreas de Processo ou Process Area dão capacidade de focar nas perspectivas e estabelecer bases de referência e resultados de melhoria na medição em cada área individualmente (AHERN; CLOUSE; TURNER, 2003). Dentre as áreas processo é pertinente falar sobre aquelas relativas a teste de software, são elas (AHERN; CLOUSE; TURNER, 2003): Itegração do produto (PI): faz a vistoria da integração das partes do produto analisando progressivamente os módulos e componentes de software desenvolvido; Verificação (VER): considerado um processo incremental, iniciando com a verificação dos componentes e concluindo com o teste do produto final; Validação (VAL): feita de forma gradativa em um ambiente operacional simulado ou não, visa atender às necessidades dos clientes. Na representação em estágios verificou-se que áreas relativas a teste fazem parte do terceiro estágio da representação em estágios. A figura 2.3 representa o modelo definido, mostrando os cinco níveis de maturidade. Figura 2.3: Os cinco níveis do maturidade do modelo CMMI. (AHERN; CLOUSE; TURNER, 2003)

30 2.4 O processo de software e algumas normas que contribuem com a sua qualidade NBR ISO/IEC Processos de ciclo de vida de software Com a globalização da economia, alcançar o patamar de qualidade e produtividade internacional é uma preocupação constante das empresas produtoras e prestadoras de serviços diante do desenvolvimento de software, principalmente quando se trata de grandes sistemas. A norma internacional NBR ISO/IEC Tecnologia da informação - Processos de Ciclo de Vida de Software (NBR-ISO/IEC-12207, 1998), é usada em muitos países para alcançar esse diferencial competitivo (ROCHA; MALDONADO; WEBER, 2001). Esta norma auxilia os envolvidos no software a definir seus papéis, através de processos bem definidos, proporcionando às organizações um melhor entendimento das atividades a serem executadas nas operações que envolvem o software (ROCHA; MALDONADO; WEBER, 2001). Esta norma provê um modelo que pode ser utilizado para definir, controlar e melhorar os processos de ciclo de vida de software. A norma NBR-ISO/IEC possui algumas definições, entre elas estão modelo de ciclo de vida e teste de qualificação (NBR-ISO/IEC-12207, 1998). Modelo de ciclo de vida: estrutura que contém processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até o término de seu uso (NBR-ISO/IEC-12207, 1998). Teste de qualificação: teste conduzido pelo desenvolvedor e testemunhado pelo adquirente (quando apropriado), para demonstrar que o produto atende as suas especificações e está pronto para a utilização no seu ambiente-alvo (NBR-ISO/IEC-12207, 1998). Para que a qualidade tenha a confiança adequada são necessários que os requisitos reflitam inteiramente as necessidades do usuário. Para isso são necessárias, entre outras opções, a testabilidade (extensão em que um teste objetivo e factível pode ser projetado para determinar se um requisito é atendido) e a cobertura de teste (extensão em que os casos de teste dos requisitos de um sistema ou produto de software são testados) (NBR-ISO/IEC-12207, 1998). As atividades que podem ser executadas durante o ciclo de vida do software estão agrupadas em cinco processos fundamentais, oito processos de apoio, quatro orga-

31 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 28 nizacionais e cinco processos de adaptação(rocha; MALDONADO; WEBER, 2001): Processos fundamentais: aquisição, fornecimento, desenvolvimento, operação e manutenção; Processos de apoio: documentação, gerência de configuração, garantia da qualidade, verificação, validação com revisão conjunta, auditoria, resolução de problema; Processos organizacionais: gerência, infra-estrutura, melhoria e treinamento. Processos de adaptação: identificação dos ambientes do projeto, solicitação de informações, seleção de processos, atividades e tarefas, documentação de decisões e motivos da adaptação. A ISO detalha todos os processos acima e ainda define como eles podem ser usados de diferentes maneiras por diferentes organizações, representando diversos pontos de vista para esta utilização. Ou seja, a norma ISO provê uma estrutura comum diante da dificuldade de lidar com a proliferação de normas, procedimentos, métodos, ferramentas e ambientes de desenvolvimento e de gerência de software. A dificuldade advém na hora de integrar os produtos e serviços. Sendo assim, a resposta para isto é a necessidade que a disciplina de software tem de migrar desta proliferação para uma estrutura comum que possa ser usada por profissionais de software para falar a mesma língua na criação e gerência do software. Os processos fundamentais constituem um conjunto de processos que atendem às partes fundamentais durante o ciclo de vida do software, entre eles encontram-se o processo de desenvolvimento e o processo de operação. É no processo de desenvolvimento que são definidas as atividades do desenvolvedor. Trata-se de um meio pelo qual é definido o desenvolvimento do produto de software. É neste processo que se encontram atividades refentes ao teste. Entre elas estão: codificação e testes do software, teste de qualificação do software, e teste de qualificação do sistema. Abaixo encontram-se descritas algumas delas: Codificação e teste do software: o desenvolvedor deve codificar e documentar cada unidade de software, definir a base de dados usando técnicas de implementação que produzam um código eficiente e livre de erros. Como resultado de uma implementação bem-sucedida, as unidades de software devem ser obtidas e critérios de

32 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 29 verificação devem ser definidos para todas elas. A atividade de teste combina várias etapas com uma série de métodos de projeto de casos de teste que ajudam a garantir que erros sejam efetivamente detectados. Assim, nesta atividade devem ser definidas técnicas de teste a serem utilizadas para estabelecer planos de teste e a própria realização dos procedimentos de teste, de modo a verificar se os requisitos especificados para o software foram corretamente implementados (NBR-ISO/IEC-12207, 1998). Teste de qualificação de software: condução de testes de qualidade de software verificando e validando os requisitos estabelecidos previamente. Neste tipo de teste são incluídos testes de cobertura, atendimento aos resultados esperados e a viabilidade de integração e operação. Analogamente, a integração do sistema e o teste de qualidade deste também devem ser realizados (NBR-ISO/IEC-12207, 1998). Existem outras atividades que incluem teste de software, tais como: integração de software, na qual são incluídos requisitos de teste de integração, e o desenvolvedor testa se os componentes desta integração satisfazem os requisitos estabelecidos no documento de especificação. O processo de operação, no qual são abrangidos a operação do produto de software e o suporte operacional aos usuários, também contém tarefas que envolvem teste, por exemplo a tarefa de teste operacional, que é onde o operador executa o teste operacional e libera o produto para uso, caso os critérios especificados sejam satisfeitos (NBR-ISO/IEC-12207, 1998) SPICE (ISO/IEC 15504) O projeto SPICE foi iniciado devido à necessidade de elaboração de um padrão que fosse aplicável à melhoria de processos e à determinação da capacidade de processos de uma organização. A partir deste projeto foi elaborada a norma ISO/IEC 15504, inicialmente publicada como relatório técnico da ISO em 1998 e composta de um conjunto de nove documentos (ISO/IEC , 1998). O objetivo era produzir, inicialmente, um relatório técnico que fosse ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 (ROCHA; MALDONADO; WEBER, 2001). Em 2004 este relatório se torna IS (International Standard), ou seja, uma norma internacional.

33 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 30 A norma ISO/IEC Esta norma trata de um conjunto de padrões para a avaliação de processo de software e, diferentemente do CMM que tem uma abordagem específica para a melhoria, a norma ISO possui uma outra abordagem no que tange à melhoria, além de possuir como um dos objetivos a medição da capacidade do processo. Para a melhoria, a organização pode realizar a avaliação gerando um perfil dos processos que serão usados para a elaboração de um plano de aperfeiçoamento. Para isso há a necessidade de a organização definir os objetivos e o contexto, e também de escolher o método para a avaliação, para então definir os objetivos de aperfeiçoamento (PAULK, 1999). A determinação da capacidade é realizada para avaliar um fornecedor em potencial, obtendo seu perfil de capacidade. Para alcançar esta meta, ela deve definir os objetivos e o contexto da avaliação, os modelos e os métodos de avaliação além dos requisitos esperados (ROCHA; MALDONADO; WEBER, 2001). A norma ISO estabelece um modelo de referência que define um conjunto de processos considerados universais, são eles: a dimensão de processo e a dimensão de capacidade. Na primeira, os processos são agrupados em cinco categorias de acordo com o tipo de atividades que executam. O primeiro passo para a efetivação de um processo é satisfazer o propósito que o descreve, este propósito exprime um único objetivo funcional (ISO/IEC , 1998). No modelo de referência estabelecido, cada processo contém um propósito. Estes processos são agrupados em cinco categorias, como segue (ISO/IEC , 1998): Cliente (Customer/Suplier): processos que se relacionam diretamente com o cliente, com o suporte no desenvolvimento e na transição do software para o cliente, provendo a operação e o uso do software ou serviço de forma correta; Engenharia: na qual é especificado, implementado ou conservado o produto de software, sua relação com o sistema e sua relação com o cliente. Esses processos lidam apenas com a construção e manutenção de cada software, em circunstâncias em que o sistema é composto totalmente de software; Suporte: são processos que podem ser utilizados por outros, estes são também utilizados por outros processos suporte;

34 2.4 O processo de software e algumas normas que contribuem com a sua qualidade 31 Gerenciamento: processos que contêm práticas genéricas que podem ser usadas por qualquer um que gerencia algum projeto ou processo dentro de um ciclo de vida de software; Organização: processos que estabelecem objetivos de negócios da empresa, apóiam a organização no alcance destes objetivos através do desenvolvimento de processos, produtos e recursos a serem utilizados pelos projetos da organização. A categoria de Engenharia é composta pelo processo de desenvolvimento e pelo processo de manutenção do software e do sistema. O processo de desenvolvimento por sua vez contém os seguintes processos: Processo de análise de requisitos e projeto do sistema, Processo de análise dos requisitos de software, Processo de projeto de software, Processo de construção de software, Processo de integração de software, Processo de teste de software, Processo de integração e teste de sistema (ISO/IEC , 1998). Como este Trabalho é referente à construção de uma metodologia de teste, serão abordados apenas os processos que tratam de teste, que fazem parte do processo de desenvolvimento. O processo de Desenvolvimento preocupa-se em desenvolver um produto de software funcional que atenda às nessecidades do cliente, um dos passos para se chegar a esse propósito é a evidência do teste, necessário para verificar se o produto final atende aos requisitos especificados (ISO/IEC , 1998). Segundo (ISO/IEC , 1998) no Processo de teste de software o objetivo é testar o software já integrado, de forma a produzir uma saída que satisfaça seus requisitos. Para que este processo seja executado com qualidade há a necessidade de que os resultados de teste sejam gravados e que as estratégias de regressão sejam desenvolvidas para que o software já integrado seja testado novamente, de forma que alguns itens do software possam ser modificados. Testes de regressão podem ser feitos sempre que necessários. As tarefas, atividades e práticas, bem como as características dos produtos de trabalho indicam se um determinado processo é praticado de forma adequada em um determinado nível de capacidade (PAULK, 1999). A dimensão de capacidade é a definição de um modelo de medição baseado na identificação de um conjunto de atributos que estabelecem a capacidade que um processo tem de atingir seus propósitos, gerando os produtos de trabalho e os resultados

35 2.5 Conclusões sobre qualidade no processo de software 32 estabelecidos (ROCHA; MALDONADO; WEBER, 2001). Essa dimensão define uma escala de seis níveis de capacidade caracterizados por um conjunto de nove atributos de processos (ISO/IEC , 1998): Nível 0 - Imcompleto: no qual o propósito do processo ainda não foi alcançado, não há evidência de que os resultados desejados sejam alcançados. Nível 1 - Executado: nele o propósito geralmente é alcançado, com pouco planejamento e acompanhamento da sua execução. Nível 2 - Gerenciado: produtos de trabalho são gerados de acordo com procedimentos específicos. A execução do processo é planejada e acompanhada, ou seja, gera produtos de trabalho que satisfazem os requisitos de qualidade especificados dentro do cronograma e dos recursos estabelecidos. Nível 3 - Estabelecido: processo estabelecido utilizando conceitos de Engenharia de Software e de um processo padrão da organização capaz de atingir os resultados definidos. Nível 4 - Previsível: onde o processo é definido e executado de modo a atingir as metas definidas, ou seja o processo é executado de maneira coerente dentro dos limites definidos para obter seus resultados. Nível 5 - Em otimização: alteração dos processos definidos e padrão é feita e adaptada para atingir efetivamente os objetivos atuais e futuros de negócio. 2.5 Conclusões sobre qualidade no processo de software Este capítulo iniciou com a definição de conceitos sobre processo de software e elementos fundamentais da Engenharia de Software. E pelo fato de a Qualidade se tratar de uma camada que serve de base a todas as outras, prosseguiu com a definição de seu significado e com a discussão da norma internacional NBR ISO/IEC (na qual são definidos processos de garantia de qualidade e atividades básicos que compõem o desenvolvimento do software) e das iniciativas relacionadas à qualidade do processo de software : projeto SPICE, os modelos CMM e CMMI bem como a norma ISO 9000.

36 2.5 Conclusões sobre qualidade no processo de software 33 A descrição de cada uma dessas iniciativas serviu de apoio para a verificação de que o processo de teste pode ser visto como uma parcela no processo de qualidade de um sistema. Outro fator que pode ser comparado é em que tipos de processos estas iniciativas estão focadas: O CMM, CMMI, ISO e ISO focam em processos de software, já a família de normas ISO 9000 abrange todas as áreas relacionadas a desenvolvimentos de projetos. Um outro aspecto visto com relação ao teste é que, diferentemente da metodologia proposta, os testes não são feitos na fase de definição dos requisitos, ou seja, antes da codificação. Além disso, também comparando com a metodologia, existem diferenças sobre o momento em que se começa a testar, entretanto isto pode ser visto pelo leitor no decorrer do trabalho. O capítulo que segue expõe uma visão genérica de Engenharia de Software, explica o conceito de modelos de processos, visto serem necessários para uma boa fundamentação da Engenharia, define alguns tipos de modelos e mostra o teste sob a perspectiva de participação de todo o processo de desenvolvimento de um software.

37 34 3 Visão genérica da Engenharia de software e Modelos de Processo 3.1 Introdução Todo projeto de engenharia possui um modelo de desenvolvimento, este capítulo é composto pela visão genérica da Engenharia de forma a compará-la com a Engenharia de Software, através da formulação de perguntas que podem ser feitas para todo o tipo de engenharia. Também é explicado o conceito de modelos de processos necessários para uma boa fundamentação da engenharia bem como alguns tipos dos mesmos, terminando com o comentário sobre teste e sua participação em todo processo de desenvolvimento de software. 3.2 Engenharia de Software e sua composição A engenharia é composta de fases como análise, projeto, construção, verificação, e gestão de elementos técnicos (ou sociais). De qualquer forma, é necessário que se façam as seguintes perguntas e se formulem suas respostas através de uma engenharia bem fundamentada, e utilizando modelos de acordo com o projeto a ser desenvolvido. Abaixo encontram-se algumas destas perguntas (PRESSMAN, 2002; NUTT, 1995): Qual o problema a ser resolvido? Que características do elemento são usadas para resolver o problema? Como o elemento (e a solução) serão realizados? Como o elemento será construído? Que abordagem será usada para descobrir erros que foram cometidos no projeto e na construção do elemento?

38 3.3 Modelos de processo 35 Como o elemento será mantido a longo prazo, quando correções, adaptações e aperfeiçoamentos forem solicitados? Na Engenharia de Software podem ser feitas as mesmas perguntas pois, da mesma forma que outra engenharia, ela se ocupa de todos os aspectos da produção de algo, neste caso, da produção de software (SOMMERVILLE, 2003; PRESSMAN, 2002). Adiante serão definidos os modelos de processos e relacionados alguns tipos dos mesmos, inclusive o RUP (Rational Unified Process) e os métodos ágeis. 3.3 Modelos de processo Para a realização de uma Engenharia de Software adequada, é necessária a definição de um processo, além de sua representação simplificada por meio de um modelo de processo (SOMMERVILLE, 2003). Modelos tem sido usados para descrever processos de trabalho decompondo procedimentos em um conjunto de passos discretos, mostrando então como a informação flui entre eles (NUTT, 1995). Modelos de processos de software são abstrações importantes de objetos e atividades envolvidas no processo de software. Neles são representados mais facilmente, e de forma mais genérica, o gerenciamento de processo de software, bem como o seu progresso. Tratam-se de estratégias de desenvolvimento que envolvem as camadas de processo, métodos e ferramentas (PRESSMAN, 2002), definidas na seção 2.2. Segundo Raccoon (1995) todo o desenvolvimento de software constitui um ciclo de solução de problema composto por quatro estágios, cada um com sua função específica. Este modelo proposto por Raccoon é também denominado de Modelo Caótico, nele é utilizado o padrão fractal, no qual cada fase ocorre em todas as outras fases e os quatro estágios encontrados nesse modelo são: definição de problema, desenvolvimento técnico, integração da solução e situação atual. Segundo Pressman (2002), qualquer que seja o modelo de processo escolhido para se projetar um software todos esses estágios, descritos no modelo proposto por Raccoon (1995), encontram-se simultaneamente em algum nível de detalhe e eles possuem a mesma importância na análise completa de uma aplicação. Nesta seção serão apresentados alguns modelos de processos genéricos. Cada

39 3.3 Modelos de processo 36 modelo representa apenas informações parciais sobre o processo, por se tratarem de representações abstratas do mesmo, ou seja, apenas a estrutura do processo é estudada e os detalhes das atividades que o compõem não são vistos (SOMMERVILLE, 2003). Esses modelos preocupam-se apenas com a organização de uma situação inerentemente caótica (PRESSMAN, 2002). Essas abstrações utilizadas para a especificação de diferentes abordagens do desenvolvimento de software são representadas pelos seguintes modelos de processos (SOM- MERVILLE, 2003): Modelo em cascata: denominado de modelo em cascata devido à seqüência em cascata de uma fase para outra; Desenvolvimento evolucionário: no qual sistema inicial é desenvolvido como um protótipo a partir de especificações abstratas refinadas com as informações dos clientes; Desenvolvimento formal de sistemas: baseado na produção de sistemas através de uma especificação formal matemática; Desenvolvimento orientado a reuso: utiliza componentes reutilizáveis para a construção de um sistema. Modelo incremental: variante do modelo em cascata. Essa abordagem permite que as atividades do projeto possam ser subdivididas e ocorram em paralelo. Modelo espiral: sua apresentação é de maneira radial O modelo em cascata Modelo clássico, que serviu durante muitos anos à Engenharia de Software, apesar da má impressão recente que ele transparece. É necessário entendê-lo, pois esse modelo, com seu poder e suas falhas é o ponto de partida para a melhor compreensão de outros modelos baseados no original (FUTRELL; SHAFER; SAFER, 2002). Anos atrás o desenvolvimento de software era diferente, códigos eram escritos e só depois depurados. Era comum o planejamento de tudo ao mesmo tempo, começando com uma idéia geral do produto, projeto, código, depuração e teste informais até que o

40 3.3 Modelos de processo 37 software estivesse pronto para ser lançado. Para uma melhor organização no desenvolvimento de sistemas iniciou-se a idéia de modelos de processos, que representam de forma abstrata o processo de software através da formalização de cada estágio do desenvolvimento do sistema (FUTRELL; SHAFER; SAFER, 2002). O modelo em cascata foi o primeiro modelo identificado, em Ele foi originado de outros processos de engenharia e é assim denominado devido à sua seqüência de uma fase para outra, com seus principais estágios na seguinte seqüência que também pode ser verificada na figura 3.1 (SOMMERVILLE, 2003): Definição de Requisitos Análise de Requisitos Implementação Teste Manutenção Figura 3.1: Modelo em Cascata. (SOMMERVILLE, 2003)

41 3.3 Modelos de processo 38 Análise e definição de requisitos: funções, restrições e objetivos do sistema são estabelecidos com o auxílio dos clientes do sistema. A definição desses aspectos servem como a especificação do sistema. Projeto de sistemas e de software: é estabelecida a arquitetura do sistema geral. Onde são descritas as abstrações fundamentais do sistema de software e a relação entre essas abstrações. Implementação e testes de unidade: o projeto é compreendido como um conjunto de unidades de programas e o teste de unidade verifica se cada unidade atende à sua especificação. Integração e testes de sistema: unidades são integradas e as integrações são testadas. Operação e manutenção: após o teste ter sido entregue ao cliente no estágio anterior, o sistema é operado e a manutenção é feita à medida que se encontram falhas em sua operação. Esse modelo deve ser utilizado apenas quando os requistos forem bem estabelecidos, pois os acordos são feitos em um estágio inicial do processo, sendo difícil responder aos requisitos do cliente (PRESSMAN, 2002) Modelo Incremental O modelo incremental é uma extensão do modelo em cascata com a diferença de ser realizado de forma interativa. Este modelo possui o intuito de apresentar um produto operacional para cada incremento realizado (PRESSMAN, 2002). Trata-se de um modelo útil quando a empresa não possui mão de obra disponível no momento para a implementação completa, dentro do prazo estipulado (PRESSMAN, 2002). Também é importante quando os requisitos não são bem definidos no início, ou seja, requisitos básicos são implementados e os detalhes são suprimidos (ROCHA, 2002) sendo que a cada incremento os requisitos são aperfeiçoados. A figura 3.2 mostra a estrutura e o modo como se desenvolve o desenvolvimento incremental.

42 3.3 Modelos de processo 39 Figura 3.2: Modelo em Incremental. (BEZERRA, 2003) Modelo Espiral Neste modelo as atividades iniciais encontram-se no centro da espiral. Esta espiral é percorrida do centro para fora à medida que o desenvolvimento vai sendo evoluído. Quanto maior a evolução para estágios posteriores, maior a complexidade. Cada iteração, feita na medida em que se avança pelo modelo, está provida das atividades determinadas pelo modelo. Este ciclo de desenvolvimento é o mais utilizado atualmente (PRESSMAN, 2002). O modelo espiral se remete a um desenvolvimento evolucionário do software, estas etapas podem se apresentar na ordem de 0 a 3. Neste exemplo, cada uma delas é composta das seguintes atividades: planejamento, avaliação de alternativas e riscos, avaliação do cliente e engenharia de desenvolvimento de software. Apesar de se ter apresentado três ciclos, este fato é indefinido, dependendo de cada desenvolvimento. A figura 3.3 mostra a estrutura de um modelo em espiral Desenvolvimento evolucionário Nesse tipo de modelo é feito o desenvolvimento de uma implementação inicial e seu aprimoramento por meio de várias versões. Tudo isso até que o sistema tenha sido desenvolvido de forma adequada.

43 3.3 Modelos de processo 40 Figura 3.3: Modelo Espiral. (SILVA, 2005) Apesar de muitas vezes ser mais eficaz que o modelo em cascata, no sentido de atendimento às necessidades imediatas do cliente, essa abordagem possui problemas com relação à engenharia e gerenciamento, alguns desses problemas são definidos a seguir (SOMMERVILLE, 2003): Processo é não visível: como os sistemas são desenvolvidos de forma descartável, não há necessidade de se documentar cada versão do sistema; Sistemas freqüentemente mal estruturados: constante mudança não traz uma boa estrutura ao software; Exigidas ferramentas e técnicas especiais: essas ferramentas podem ser incompatíveis com ferramentas e técnicas. Apesar desses problemas, esse modelo pode ser uma boa opção para sistemas relativamente pequenos (FUTRELL; SHAFER; SAFER, 2002). Na figura 3.4 são mostradas as abstrações das atividades executadas por este tipo de modelo.

44 3.3 Modelos de processo 41 Figura 3.4: Desenvolvimento Evolucionário. (SOMMERVILLE, 2003) Desenvolvimento formal de sistemas Trata-se do desenvolvimento de um sistema através da aplicação de uma notação matemática. Método bem vindo quando se trata de encontrar erros no software que poderiam passar desapercebidos (PRESSMAN, 2002). Não é uma abordagem de uso geral pois seu desenvolvimento é muito lento. Existem poucos desenvolvedores com preparo para aplicar esses métodos, além da dificuldade de utilizar esses modelos como mecanismo de comunicação com clientes despreparados tecnicamente (SOMMERVILLE, 2003). Suas atividades podem ser representadas conforme a figura 3.5. Figura 3.5: Desenvolvimento Formal de Sistemas. (SOMMERVILLE, 2003) Pressman (2002) e Sommerville (2003) também definem, entre outros processos, o Desenvolvimento baseado em componentes, definido na próxima seção.

45 3.3 Modelos de processo Desenvolvimento baseado em componentes Componentes reutilizáveis podem ser sistemas propriamente ditos. O arcabouço técnico para esse modelo de processo é fornecido pelas tecnologias orientadas a objeto (SOM- MERVILLE, 2003; PRESSMAN, 2002). No desenvolvimento orientado a reuso, o estágio inicial da especificação de requisitos e os estágios de validação são comparáveis com outros processos, mas os estágios intermediários são diferentes (PRESSMAN, 2002). Os estágios intermediários são os seguintes (PRESSMAN, 2002): análise de componentes (busca de componentes para implementar a especificação de requisitos considerada), modificação de requisitos (os requisitos são modificados para se adequar aos componentes disponíveis), projeto de sistema com reuso (infra-estrutura do sistema é projetada, ou a já existente é reutilizada. Se os componentes reutilizáveis não estiverem disponíveis, um novo software será projetado). Entre as vantagens deste modelo estão a redução na quantidade de software a ser desenvolvida e a redução de custos e riscos (SOMMERVILLE, 2003; PRESSMAN, 2002). Apesar destas vantagens, pode existir um problema de o sistema não atender às reais necessidades do cliente, além da falta de controle sobre a evolução do sistema (SOM- MERVILLE, 2003). Vários modelos de processos existentes na literatura possuem fases genéricas em comum. O teste é uma etapa que compõe estes modelos. Entretanto, segundo Hetzel (1987), teste não deve ser considerado apenas uma etapa necessária quando toda a codificação do programa tiver sido concluída, como pode ser evidenciado, por exemplo, na figura 3.6, adaptado de (PRESSMAN, 2002; SOMMERVILLE, 2003; HETZEL, 1987). Esta figura representa o modelo em cascata considerando o teste de software como uma atividade ampla e contínua, que deve ser incluída em todo o processo de desenvolvimento (HETZEL, 1987). Sendo assim, usando o modelo em cascata como referência, pode-se refazê-lo colocando o teste conectado a todas as fases deste modelo. É importante frizar que este trabalho trata da construção de uma metodologia de teste e utiliza uma abordagem que visa a independência do modelo utilizado pelo projeto de software. As abstrações das atividades contidas em outros modelos podem estar acompanhadas, também, da atividade de teste como participante de todo o processo

46 3.3 Modelos de processo 43 de desenvolvimento. Figura 3.6: Modelo em Cascata com Teste compondo todas as etapas. As próximas seções irão tratar de dois processos de Engenharia de Software, que descrevem de forma menos abstrata as atividades, responsabilidades e gerenciamento dentro de uma organização de desenvolvimento, cada um destes processos a serem descritos possui seu diferencial Rational Unified Process - RUP RUP é um processo de Engenharia de Software. Este processo provê uma abordagem disciplinada para delimitar as tarefas e responsabilidades dentro de uma organização de desenvolvimento. O seu foco é assegurar uma produção de software de alta qualidade, que conhece as necessidades dos usuários finais dentro de uma agenda e orçamento previsíveis (CORPORATION, 2001). O Rational Unified Process é um produto de processo que melhora a produtividade da equipe, fornecendo a todo membro da mesma fácil acesso ao conhecimento com a utilização de linhas guia, modelos e mentores para todas as atividades de desenvolvimento (CORPORATION, 2001). O RUP possui duas dimensões: O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve;

47 3.3 Modelos de processo 44 Eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. A primeira dimensão pode ser representada como o aspecto dinâmico do processo. Pode ser exemplificada por meio de marcos, iterações e fases. Já a segunda dimensão representa o aspecto estático do processo, é representada pelas disciplinas as quais são dispostas por meio de fluxos de trabalho, ou seja, o conjunto de atividades desempenhadas em cada disciplina (CORPORATION, 2001). É importante notar que o ciclo de vida do gerenciamento do software no RUP é dividido em quatro fases de forma seqüencial, onde cada uma é considerada como um marco principal. A atividade mais impotante é a avaliação realizada a cada final de uma dada fase (CORPORATION, 2001). Um fator importante é que as fases são diferentes em termos de esforço e programação empenhados. A fase de iniciação é a menos onerosa enquanto que a fase de construção é a que requer maior empenho da equipe (CORPORATION, 2001). Isso demonstra a importância de se consertar o máximo de anomalias no início, atentar para esta prática, visto que no final (construção) o trabalho é muito maior. A política do RUP considera a passagem pelas quatro fases como um ciclo de desenvolvimento, sendo assim é viável neste processo que se passe mais de uma vez por estas fases, ou ciclo de desenvolvimento (CORPORATION, 2001). Cada passagem pelas quatro fases produz uma geração do software e esse produto é cada vez mais desenvolvido, sendo que a ênfase é diferente para cada uma das fases dependendo da situação de melhoria em que se encontra (CORPORATION, 2001). Falando resumidamente, o Rational Unified Process é baseado em componentes, os quais são construídos desde o início do processo de desenvolvimento. Cada incremento realizado é acompanhado do acréscimo de mais funcionalidades ao produto bem como da documentação dos resultados parcias para serem usados posteriormente, numa próxima iteração. Um outro assunto importante citado por Corporation (2001) é a descrição das melhores práticas de engenharia de software no âmbito comercial bem como o fornecimento de ferramentas para gerenciamento de requisitos, modelagem visual, teste automatizado, e gerenciamento da mudança. A figura 3.7 mostra a relação entre estas práticas e as ferramentas.

48 3.3 Modelos de processo 45 Figura 3.7: Relacionamento entre as práticas e as ferramentas. (CORPORATION, 2001) O fato deste trabalho estar focado no teste leva a direcionar as atenções para esta atividade. O teste é uma das disciplinas que fazem parte da dimensão vertical no RUP. Um fator importante que é sugerido pelo RUP é a criação de catálogos de teste. Estes catálogos contém idéias de teste que chegam a localizar, cada uma, mais de uma falha. Algumas características de um catálogo de teste são (CORPORATION, 2001): Contém um pequeno conjunto de idéias de teste que pode localizar um conjunto maior de falhas básicas; Pode ser examinado com facilidade; Não deve conter idéias de teste que nunca foram utilizadas. Essas idéias de teste são feitas para que os programadores as utilizem, evitando maiores quantidades de falhas. Quando se trata do ciclo de vida do teste é necessário saber que no ciclo de vida do software do RUP, o software é refinado através de iterações. Desta forma o teste, por se tratar de um dos processos que compõe cada iteração, possui uma abordagem iterativa equivalente. Outro fator importante que o RUP prega é a elaboração do processo de teste assim que os primeiros laçamentos forem feitos de forma a não retardar a descoberta de muitos problemas no ciclo de desenvolvimento (CORPORATION, 2001). Além disso o RUP

49 3.3 Modelos de processo 46 trata a equipe de teste como responsáveis pela área de qualidade (consultora de qualidade) sempre atenta às atividades de requisitos iniciais e projeto (CORPORATION, 2001). Um outro aspecto importante é a detecção de requisitos que, segundo este processo de engenharia de software, é realizado continuamente a cada iteração, isso é de suma importância pois requisitos podem ser modificados e esta detecção é feita pela documentação destes novos requisitos. O quanto que se deve investir em teste dependerá da empresa, do quanto que ela pode gastar no mesmo. Diante desta breve definição sobre RUP e como é realizado o teste neste processo, pode-se chegar, na seção 7 a algumas conclusões com relação à metodologia de teste proposta no presente trabalho e a utilização deste processo de engenharia de software Métodos Ágeis Os métodos ágeis possuem o princípio de desenvolvimento de software com qualidade porém de forma mais rápida e sem excesso de formalidade (FILHO et al., 2005). A utilização do método ágil foca no sucesso pessoal, técnico e organizacional (SHORE; WARDEN, 2008), na intersecção entre estas três vertentes. Como pode ser visto na figura 3.8. Figura 3.8: Intersecção entre três vertentes que gera o método Ágil. (SHORE; WARDEN, 2008) A popularização destes métodos ágeis ocorreu com o Manifesto possue princípios como (FILHO et al., 2005): Ágil, que

50 3.3 Modelos de processo 47 Indivíduos e interações são mais importantes que processos e ferramentas; Software funcionando é mais importante que documentação detalhada; Colaboração dos clientes é mais importante que negociação de contratos; Adaptação às mudanças é mais importante do que seguir um plano. Um exemplo de métodos ágil é o XP (Extreme Programming). Relacionado ao teste, o analista de teste possue um papel proativo, eles ajudam os desenvolvedores e clientes a desenvolverem testes antes mesmo da implementação dos requisitos (TELES, 2008). Também ajudam a automatizar os testes e, se alguns testes não são automatizados, fazem manualmente (TELES, 2008). No Extreme Programming os testes de unidade são feitos continuamente e os clientes fazem os testes para verificar se o desenvolvimento, até então, encontra-se de acordo com o esperado (FILHO et al., 2005). Os métodos ágeis, para uma contrução de forma efitiva do software devem ser ligados a padrões organizacionais e processos. Alguns exemplos de princípios levantados por estes padrões são: o uso de equipes pequenas e médias (defendido por The Size Organization), a colaboração efetiva dos clientes, os clientes devem estar próximos dos desenvolvedores e arquitetos e não apenas da qualidade e marketing (defendido por Engage Customers), desenvolvedores codificam em pares (trabalhando juntos na mesma máquina), número de papéis da organização deve ser de, no máximo, 16, reuniões rápidas de, aproximadamente, 15 minutos diariamente, criação de papéis para proteger os desenvolvedores de interações externas (FILHO et al., 2005). Outros exemplos de princípios levantados por estes padrões são: a existência de um papel que represente o cliente caso o mesmo não possa participar integralmente do processo, o relacionamente entre os membros tem que trazer confiança para todos de forma que estes membos trabalhem transparentemente, colocar apenas um especialista como responsável pelos principiantes, evitar o excesso de comunicação nomeando uma pessoa responsável para este papel. Existem muitos outros princípios levantados por padrões, foram citados apenas os principais. Estes padrões de processos tratam das estruturas organizacionais, sociais e de bem estar dos envolvidos no projeto (FILHO et al., 2005). Segundo Filho et al. (2005) integrar padrões organizacionais a um método ágil é um grande desafio. O que dificulta o estabelecimento de um dsenvolvimento de software ágil, com soluções de sucesso em nível organizacional e de processo.

51 3.4 Resumo do Capítulo 48 Desta forma nota-se que muitos aspectos estão envolvidos na qualidade de um processo de desenvolvimento, além de uma boa metodologia de teste software. Outro fator considerado nos aspectos pessoais é o papel que uma pessoa da equipe de teste representa: considerada membro de primeira classe que, com sua capacidade de influenciar a qualidade em todos os estágios do projeto, diminue a repetição de trabalho (SHORE; WARDEN, 2008). 3.4 Resumo do Capítulo Neste capítulo mostrou-se uma visão geral de engenharia e modelos de processos com o intuito de situar a fase de teste, que está sendo estudada neste trabalho, já que a mesma deve fazer parte de qualquer processo de desenvolvimento de software de qualidade, de forma a compor todas as fases do mesmo. Foram abordadas algumas metodologias de qualidade no processo de software: RUP e Métodos Ágeis (dando ênfase ao XP). Estas metodologias foram citadas de forma a dar maior apoio à metodologia de teste que será explanada e validada nos capítulos 5 e 6. Tendo em mente que uma metodologia teste deve fazer parte de um conjunto maior, que são as metodologias aplicadas para a qualidade do processo como um todo. O próximo capítulo expõe a definição de teste, segundo pontos de vista diferentes além de especificar seus princípios básicos, estratégias e tipos de teste. Também serão introduzidos dois elementos que dão suporte à metodologia construída no presente trabalho, são eles: o método MITs (a idéia que este método passa), a norma IEEE 829 e o princípio de Validação dos Requisitos.

52 49 4 Teste de software 4.1 Introdução Uma das questões levantadas no início do capítulo anterior se identifica com o foco deste Trabalho de Conclusão de Curso. Segundo (PRESSMAN, 2002), a questão sugere que se utilize alguma abordagem para a verificação de erros surgidos na fase de projeto e construção. Partindo do princípio de que software possui um grande número de estados com fórmulas complexas, atividades e algoritmos, é inevitável a presença de falhas. Um dos motivos de falha de um programa é o fato de não estar de acordo com o resultado esperado pelo usuário final. Este capítulo iniciará com definições a partir de diferentes pontos de vista acerca de teste e justificará a sua importância como parte de um processo de qualidade. Também serão abordados tipos de métodos e técnicas que envolvem o teste de software, bem como os princípios básicos sobre os quais estes métodos e técnicas se assentam. 4.2 Princípios básicos Teste é uma palavra derivada do latim (testum) que significa um pote de barro no qual metais eram decompostos para a determinação da presença de diversos elementos ou medição de seu peso (HETZEL, 1987). Existem várias definições de teste, Hetzel define teste como um processo de aquisição de confiança no fato de que um programa ou sistema faz o que se espera dele. Já Myers (2004) o define como sendo um processo de executar um programa ou sistema com a finalidade de encontrar erros. Sendo assim, o teste tem a utilidade de coleta de informações para a avaliação eficiente do software que foi ou está sendo construído (HETZEL, 1987). Esta coleta de informações deve ser feita da maneira mais eficiente possível, procurando responder peguntas como: O software está pronto para ser usado? Quais são os riscos? Quais os recursos? Quais são as limitações? Quais são os problemas? Ele tem o desempenho

53 4.2 Princípios básicos 50 esperado? Outra definição, que se encaixa com a política deste trabalho, também foi dada por Hetzel na qual transparece que teste é a medida da qualidade do software (HETZEL, 1987). O Teste de software é uma atividade muito importante para o desenvolvimento de um sistema e de seu processo de qualidade, além de representar a revisão final da especificação, projeto e geração de código (TIAN, 2005; HETZEL, 1987; MYERS, 2004). Falhas em sistemas podem causar custos tanto de vidas quanto de dinheiro, por isso, testes bem planejados rigorosamente são de grande valia para diminuir as falhas que, por ventura, podem surgir. Existem definições erradas quanto ao teste, considerando que ele deve ser planejado para não encontrar erros, sendo que o objetivo desta atividade é justamente o contrário (PRESSMAN, 2002). Ou seja, seu objetivo não é executar o caminho feliz para cada funcionalidade de um sistema, mas executar caminhos que podem ocasionar falhas no sistema com o intuito de se certificar que a qualidade e adequação aos requisitos do usuário estão presentes. Obviamente, não se deve desconsiderar a afirmação de que o caminho feliz tem 100% de chance de ser realizado visto que o mesmo se trata do requisito estebelecido pelo usuário. Para a realização da atividade de teste é necessário o reconhecimento do objetivo primário do teste. Teste de software têm como objetivo principal encontrar o maior número de falhas possíveis. Através de casos de testes bem planejados a probabilidade de se encontrar erros ainda não descobertos é maior, assim se contrói um teste bem sucedido (SOMMERVILLE, 2003). Existem princípios básicos que regem a atividade de teste, é neles que se assentam os métodos e técnicas que envolvem o teste de software. A compreensão desses princípios é de suma importância para todos os envolvidos no desenvolvimento de uma aplicação. Dentre esses princípios, existe um que defende a idéia de que é impossível se testar tudo, pois devem existir infinitas possibilidades de teste, sendo necessário escolher um subconjunto pequeno que forneça uma medida razoável do desempenho, construindo um nível satisfatório de confiança. Este princípio é considerado em uma das etapas da metodologia do presente trabalho. A ampliação da extensão do teste pode ser mais dispendiosa devido ao acréscimo de outros problemas que tomariam o tempo necessário

54 4.2 Princípios básicos 51 para aplicar as provas e notas às aplicações testadas. Outro princípio que rege a atividade de teste é o conceito de que testar não é uma atividade fácil e requer criatividade de quem a conduz. Argumentos que defendem a dificuldade de se testar são os seguintes (HETZEL, 1987): É necessário o conhecimento a fundo do sistema para se testar com eficiência; Há dificuldade de se entender os sistemas. Os responsáveis pelo teste de software devem ter como pré-requisito o conhecimento do sistema, desta forma é intrínseco que os analistas de teste trabalhem com os casos de uso do sistema. Os casos de uso foram introduzidos como uma parte de uma metodologia de desenvolvimento orientado a objetos por Ivar Jacobson. Mais recentemente, Larry Constatine e outros têm extendido o conceito para uma técnica geral para análise de requisitos e projeto de interface do usuário. Cada caso de uso descreve um cenário no qual o usuário interage com o sistema sendo definido para alcançar um objetivo específico ou realizar uma tarefa particular. Casos de uso são descritos de forma que se remeta ao trabalho do usuário, mas a descrição não é computadorizada (WIEGERS, 1997). Além do conhecimento do sistema, outros atributos são extremamente importantes para a atividade de teste, tais como: criatividade e inteligência, experiência na realização de testes e construção de uma metodologia. Uma outra característica a ser adicionada a esta atividade é a necessidade dos testes de previnir erros, não apenas encontrá-los. Diferentemente do conceito tradicional de teste, hoje este é encarado como participante contínuo, abrangendo todo o ciclo de vida do desenvolvimento (SOMMERVILLE, 2003). Sendo assim, o teste deixa de ser uma fase e passa a produzir resultados que se relacionam com todas as fases de desenvolvimento. Em um processo genérico de testes as atividades como planejamento e preparação, execução dos testes e análise podem ser definidas na ordem cronológica em que podem ser desenvolvidas e representadas conforme a figura 4.1. Um dos princípios básicos do teste é conhecer a dependência desta atividade à atividade de desenvolvimento que inclui o conhecimento dos requisitos especificados pelo cliente. O planejamento dos testes, principalmente quando os requisitos feitos pelos

55 4.2 Princípios básicos 52 Figura 4.1: Processo Genérico de Teste. (TIAN, 2005) clientes ainda estão sendo completados, é extremamente relevante. Outra característica essencial para a execução dos testes é a de que eles devem começar nos componentes individuais para então progredir para as tentativas de alcance de erros em componentes já integrados para, enfim, focar no sistema como um todo. Outro princípio a ser seguido na execução de atividades de teste é levar em conta a importância de que terceiros também conduzam os testes, visto que o engenheiro que constrói o sistema não seria a pessoa mais adequada a realizar testes (CHILLAREGE, 1999). A testabilidade é uma característica que contribui, se for alta, com o processo de localização fácil de defeitos em um sistema. Esta definição não considera falhas causadas pelo ambiente ou por valores de entrada específicos. A testabilidade é também considerada como uma probabilidade de um pedaço de software falhar, sendo limitada no conjunto fechado [0,1] (KHOSHGOFTAAR; VOAS; SZABO, 1995). Existe um conjunto de características que contribuem com a testabilidade. Uma delas é a operabilidade, tendo um sistema com poucos defeitos, pois defeitos aumentam o consumo da análise e de relatos ao processo de teste, isso não significa que não deva possuir defeitos, a falta de defeitos impossibilita que o teste seja executado (PRESSMAN, 2002). O planejamento é uma etapa que deve estar intrínseca à atividade de teste, sendo assim foi incluído na metodologia de teste realizada neste Trabalho de Conclusão de Curso. O propósito do planejamento é descrever o escopo, abordagem, recursos e cronograma para as atividades de teste. Nesta fase são sumarizados os itens de software e as características a serem testadas. As necessidades e históricos de cada item podem

56 4.2 Princípios básicos 53 ser testados. Também podem ser identificadas partes que não precisam ser testadas. Esta etapa de planejamento é utilizada como um guia para não haver esquecimento quanto ao que deve ser feito em um bom teste. Sendo uma das partes fundamentais para a execução de testes, um plano de teste de sucesso é composto de objetivos, critério de completude, cronograma, responsabilidades, bibliotecas e padrões de casos de teste, ferramentas, tempo de computação (MYERS, 2004). Os objetivos estão descritos a seguir (MYERS, 2004): Objetivos: devem ser definidos os objetivos de cada fase de teste; Critérios de completude: devem haver critérios que especificam quando uma determinada fase de teste deve ser completada; Cronograma: são necessários tempos de calendário em cada fase. quando os casos de testes serão projetados, escritos e executados; Especificando Responsabilidades: devem haver pessoas responsáveis por cada atividade desde o projeto, execução e verificação de casos de teste, também necessita de pessoas que irão reparar os erros descobertos; Bibliotecas e padrões de casos de teste: são necessários métodos sistemáticos de identificação, escrita e relatórios de casos de testes; Ferramentas: necessária à identificação das ferramentas de teste, incluindo um planejamento de quem irá desenvolver ou adquirir, como serão usadas, e quando elas serão necessárias; Tempo de computação: quantidade de tempo de computação necessário para cada fase de teste. Para um melhor resultado nas atividades de teste, o projeto de casos de teste deve ser uma etapa que vem em seguida à fase de planejamento. É de fundamental importância a escolha de métodos que forneçam ao desenvolvedor uma abordagem sistemática ao teste. Esses métodos ajudam com uma maior probabilidade de descobrir erros no software (PRESSMAN, 2002). Existem duas abordagens para se efetuar teste, pelas quais qualquer produto de engenharia deve passar, são elas : condução de testes considerando um rigoroso detalhe procedimental (teste baseado em programa) e condução

57 4.2 Princípios básicos 54 de testes considerando a interface e funcionamento do software (teste baseado em especificação) (PRESSMAN, 2002). No teste baseado em programa (ou teste de caixa-branca) são utilizados casos de testes com o intuito de exercitar o código fonte e não sua especificação (MALDONADO et al., 2004). Já o teste baseado em especificação (ou teste da caixa-preta) tem o objetivo de determinar se o programa satisfaz a todos os requisitos, sejam eles funcionais ou nãofuncionais. Este critério de teste é considerado como uma abordagem complementar ao teste da caixa-branca. Exemplos: particionamento em classes de equivalência, métodos de teste baseados em grafos etc (MALDONADO et al., 2004; SOMMERVILLE, 2003). Os métodos de teste caixa-preta e caixa-branca podem ser aplicados em todos os ambientes, arquiteturas e aplicações. Porém, existem abordagens especializadas de testes. Exemplos dessas abordagens são: teste de GUI (Graphics User Interface), teste de arquitetura cliente-servidor, teste da documentação e dispositivos de ajuda, teste de sistemas de tempo real (PRESSMAN, 2002). Myers (2004) sugere a utilização dos dois métodos citados: método da caixapreta e método da caixa-branca. Pois um método pode descobrir erros, enquanto outro método pode fazer uma revisão, por exemplo. O terceiro elemento da configuração de software é a documentação. Erros nesta etapa podem devastar a aceitação do programa, da mesma forma que erros em dados ou código-fonte. Por isso o teste de documentação do software é uma parte significativa de todo o plano de teste de software. Sendo esta documentação um guia para o usuário que não sabe operar o programa. Este teste pode ser separado em duas fases: revisão e inspeção (examina o documento quanto à clareza editorial) e teste ao vivo (utilizando o programa através da documentação). Portanto, a aplicação de projetos de casos de teste auxilia em um teste mais completo e, conseqüentemente, o maior número de erros são descobertos e corrigidos antes de chegar ao usuário final. Nas próximas seções serão definidas as principais estratégias de teste.

58 4.3 Estratégias de Teste Estratégias de Teste Existem métodos de projeto de casos de testes que precisam ser integrados. Essa integração ocorre através do emprego de estratégias de teste, resultando na construção de software de qualidade. Uma estratégia de teste deve acomodar desde testes de baixo nível até testes de alto nível. Dessa forma, os elementos que compõem uma estratégia de teste são representados pelos métodos de testes. O teste pode ser confundido pela denominação de Verificação e Validação (V & V), mas este conceito deve estar claro. V & V abrange um conjunto de muitas atividades, e o teste nada mais é do que uma das atividades que compõem este conjunto (PRESSMAN, 2002; SOMMERVILLE, 2003). Figura 4.2: Estágios de um processo de teste. (SOMMERVILLE, 2003) A figura 4.2 mostra cinco estágios que podem compor o processo de teste juntamente com as etapas específicas deste processo como, por exemplo, os planos de teste. Esses estágios testam os componentes do sistema, o sistema integrado e, finalmente, o sistema com os dados do cliente. À medida que erros são descobertos o programa deve ser depurado podendo envolver a repetição dos estágios (SOMMERVILLE, 2003) Teste de Unidade Para se testar um programa é necessário levar em conta os mecanismos do teste e o tamanho do programa a ser testado. Assim, programas grandes requerem um tratamento especial de teste. Um passo inicial no estruturamento do teste de aplicações amplas é a utilização de teste de unidade (ou teste de módulo)(pressman, 2002; MYERS, 2004).

59 4.3 Estratégias de Teste 56 O teste de unidade é um processo que testa os sub-programas, sub-rotinas ou procedimentos individuais em uma aplicação. Isto é, esta técnica de teste é inicialmente focada nos menores blocos que são construídos do programa. As motivações de se utilizar esta técnica são as seguintes (MYERS, 2004): O gerenciamento das partes combinadas de elementos de teste; A avaliação das unidades do programa o que facilita o mecanismo de depuração; A introdução de paralelismo ao processo de teste, dando a oportunidade de teste de múltiplos módulos simultaneamente. Os testes que compõem os testes de unidade são ilustrados na figura 4.3 Figura 4.3: Testes de unidade. (PRESSMAN, 2002) Os testes de passagem de dados por meio da interface, antes dos outros testes que compõem o teste de módulo, servem para verificar a adequabilidade da entrada dos dados que entram e saem. As estruturas de dados locais são exercitadas, além da necessidade de avaliação do impacto local dos dados globais (MYERS, 2004). Testes de caminho básico e de ciclo também devem ser efetuados através de casos de testes que verificam erros por causa de cálculos errados, comparações incorretas ou fluxo de controle inadequado. Estas técnicas são muito efetivas na descoberta de erros de caminho. Os casos de testes têm o intuito de descobrir erros como comparação de

60 4.3 Estratégias de Teste 57 tipos de dados diferentes, operadores ou precedência lógica incorreta, variáveis de ciclo inadequadamente modificadas, entre outros (PRESSMAN, 2002). A última tarefa a ser executada em teste de unidade é testar se existem falhas nos limites do software. Por isso a necessidade de execução de casos de testes que testem estrutura de dados, fluxo de controle e valores de dados abaixo, entre e acima do máximo e mínimo, devido à grande probabilidade de encontrar erros nesta etapa (MYERS, 2004). Em suma, no projeto de casos de teste para o teste de módulo são necessários dois tipos de informações: a especificação para o módulo e o código-fonte do módulo. Uma característica a ser considerada é a de que, neste teste, os casos de teste são projetados através do método de caixa-branca. Este método é pouco factível para o teste de grandes entidades como programas inteiros. É analisado a lógica dos módulos usando um ou mais dos métodos de caixa-branca, depois são aplicados métodos de caixa-preta para as especificações dos módulos (HETZEL, 1987). Em um teste de unidade, os erros são mais facilmente encontrados se os componentes forem altamente coesos, ou seja, apenas uma função é implementada em cada componente, diminuindo o número de casos de testes (PRESSMAN, 2002) Teste de Integração Após o teste de unidade é provável que seja feita a seguinte pergunta: se todas as unidades foram testadas e funcionam bem sozinhas, será necessário testá-las juntas? Mas a questão é que, quando esses módulos são colocados juntos, dados podem ser perdidos, uma unidade pode não se integrar sem haver erro com a outra, uma função principal desejada com a junção de duas outras pode não ser alcançada, imprecisão aceitável individualmente pode ser amplificada para um nível inceitável quando é agregada a outro módulo, entre outros impasses. Nesta fase de teste de integração é construída a estrutura do programa através dos componentes testados em nível de unidade e conduzidos os testes para a descoberta de erros associados às interfaces. Existem duas abordagens de integração, a incremental e a abordagem big-bang, a última é considerada a combinação dos componentes por antecedência e o programa inteiro é testado sem ter passado pelo teste de módulo. Dessa forma a correção é trabalhosa

61 4.3 Estratégias de Teste 58 e árdua devido à dificuldade de isolamento das causas. À medida que os erros são corrigidos novos erros são descobertos (PRESSMAN, 2002). Na integração incremental, diferentemente da big-bang, o programa é construído e testado em pequenos incrementos, facilitando os isolamento de erros e a correção dos mesmos. Existem duas estratégias incrementais de integração diferentes, são elas: integração descendente (top-down) e integração ascendente (bottom-up). Integração Descendente Neste procedimento de teste as unidades são integradas movendo-se do módulo principal na hierarquia seguido dos seus módulos subordinados. Na figura 4.4 é apresentada a forma como esta estratégia trabalha. Trata-se de um programa com 12 módulos. Considerando que o módulo 10 contém as operações de leitura de entrada e saída, e o módulo 9 contém as operações de escrita. O primeiro passo é o teste do módulo 1. Para realizar essa tarefa os filhos de 1 devem ser escritos. A unidade 1 espera a realização de algum trabalho da unidade 2, este trabalho deve ser algum resultado que 2 retorna a 1. Se o filho retornar simplesmente um comando ou escrever mensagem sem retornar um resultado significativo é provável que o módulo 1 falhe. Este módulo irá falhar não por causa de erro em 1 mas por causa da falha de seu filho ao simular o módulo correspondente. Mas o retorno de uma mensagem de um módulo stub (nó filho) é insuficiente. Figura 4.4: Módulo de programa (MYERS, 2004) Existem dois tipos de integração descendente: integração primeiro-em-profundidade

62 4.3 Estratégias de Teste 59 e integração-primeiro-em-largura. Esta estratégia descendente verifica os principais pontos de controle ou decisão no início do processo de teste. Integração Ascendente Trata-se de uma estratégia de teste que é oposta à estratégia top-down. Esta estratégia é menos vantajosa que a estratégia definida na seção anterior. Ela começa com os módulos terminais no programa, ou seja, módulos que não chamam outros módulos. Após o teste destes módulos não existe uma maneira de se escolher o próximo módulo a ser testado, para que um módulo seja elegível para a próxima unidade é necessário que ele tenha sido testado antes (SOMMERVILLE, 2003; PRESSMAN, 2002). Em ambas as abordagens, descendente e ascendente, são necessários pseudocontroladores (programa de controle para teste que é feito para coordenar a entrada e a saída do caso de teste). Sendo que na abordagem ascendente começa com um número de pseudocontroladores separados, e à medida que a integração sobe esse número diminui (PRESSMAN, 2002). Existem algumas vantagens e desvantagens da utilização dessas técnicas de integração relatadas abaixo: Testes de integração top-down (SOMMERVILLE, 2003; PRESSMAN, 2002; MYERS, 2004): Desvantagens: São testes difíceis de implementar, devido à necessidade de construção de módulos de stubs; A representação de casos de testes em stubs podem ser difíceis de implementar; Condições de testes podem ser muito difíceis de se criar; Observação da saída do teste é mais difícil; Permite que se pense que o projeto e o teste podem ser sobrepostos; Induz ao adiamento do teste de certos módulos.

63 4.3 Estratégias de Teste 60 Vantagens: As maiores falhas ocorrem na direção do topo do programa; Oferecem maiores probabilidade de descoberta de erros na arquitetura e no projeto de alto nível em um estágio inicial do processo de desenvolvimento, acarretando correções que geram custos menos exagerados; Uma vez que as funções de entrada e saída são adicionadas, a representação dos casos de testes se torna mais fácil; Com este tipo de integração, o protótipo do sistema fica disponível em uma fase inicial do desenvolvimento, é um incentivo moral aos desenvolvedores do sistema. Testes de integração bottom-up (MYERS, 2004): Desvantagens: Drivers de teste devem ser produzidos, para que a execução dos componentes de nível inferior possa ser observada; O programa como uma entidade não existe. Vantagens: As maiores falhas ocorrem nos níveis mais baixos; Condições de teste são fáceis de criar; Observação para se testar os resultados é mais fácil Teste de Validação O teste de validação pode ser iniciado quando o teste de integração tiver sido encerrado. O teste de validação opera no sentido de verificar se o software trabalha de forma razoável com relação ao que o cliente espera. A base para este tipo de teste é formada pelas informações chamadas de critérios de validação (SOMMERVILLE, 2003; PRESSMAN, 2002; TIAN, 2005).

64 4.3 Estratégias de Teste 61 Feito os testes de validação, o cliente fica encarregado dos testes finais e cada desvio de especificação encontrado deve ser adicionado a uma lista na qual estão estão descritas todas as deficiências encontradas (TIAN, 2005). As deficiências de um produto de software são previsíveis, pois não é possível que saiba tudo o que o cliente irá usar em um programa. Sendo assim, em muitas organizações de desenvolvimento de software maduro, alguma forma de teste de aceitação é desempenhada como uma sub-fase final do teste para determinar se o produto pode ser usado (TIAN, 2005). Algumas vezes, o teste de aceitação pode fazer parte do teste de sistema, que será abordado adiante, sendo tipicamente a última parte que faz a verificação final do produto. Mas existem diferenças entre estes tipos de testes: no teste de sistema regular os defeitos serão consertados antes de o produto ser entregue, já no teste de aceitação a correção dos erros não pode ser feita devido ao pouco tempo para esta atividade, visto que se trata do último teste (TIAN, 2005). Existem testes de aceitação que são usados para descobrir erros mais visíveis pelo usuário final, são eles teste alfa e teste beta. Teste alfa são conduzidos em um ambiente controlado, no qual o desenvolvedor verifica os erros encontrados pelo usuário e os registra para uma posterior manutenção. Teste beta: neste método, diferentemente do teste alfa, o desenvolvedor não está presente no processo. Este teste é desempenhado pelo cliente que registra todos os problemas que são encontrados, para posteriormente relatá-los ao desenvolvedor. A conseqüencia deste processo é a correção feita pelos engenheiros do produto de software, liberando-o depois para toda a base de clientes Teste de Sistema Este teste faz a verificação do sistema do ponto de vista do cliente, testando suas funções externas, sendo todo o produto tratado como uma caixa-preta. Isso significa dizer que apenas funções de alto nível serão testadas, ou seja, apenas o que for visível aos usuários (PRESSMAN, 2002; TIAN, 2005). A sabedoria sobre as funções do produto como um todo, domínio da aplicação e segmentos de marketing, expectativas do cliente e sua utilização do sistema nesta fase é

65 4.3 Estratégias de Teste 62 mais importante do que detalhes de implementação (PRESSMAN, 2002; TIAN, 2005). Os testes de sistema possuem ferramentas importantes para seu planejamento e organização como o plano global de testes e as pastas de casos de testes. Se as primeiras etapas de testes tiverem sido bem executadas a realização de testes do sistema será feita com relativa facilidade (HETZEL, 1987). O teste do sistema é composto por uma série de diferentes testes com o objetivo de exercitar de forma completa o sistema e verificando se os elementos do sistema foram corretamente integrados e se executam as funções destinadas a eles (PRESSMAN, 2002). Exemplos de testes que compõem os teste do sistema são teste de recuperação, teste de segurança, teste de estresse e teste de desempenho (PRESSMAN, 2002). Nas próximas seções serão definidos O Método dos Testes Mais Importantes e a Norma IEEE 829, visto que podem fazer parte de um processo de teste Método dos Testes Mais Importantes - MITs Este método foi proposto por Hutcheson (2003), no seu livro Software Process Quality: Management and Control, para auxiliar no planejamento do tamanho dos esforços de teste baseados na identificação dos riscos de falhas no sistema. O método é viável para todos os níveis de teste, nele os testadores usam diversas técnicas para identificar as áreas que necessitam ser testadas, para posteriormente serem avaliados os riscos associados aos vários componentes, características e funções do projeto (HUTCHESON, 2003). O MITs possui o princípio de verificar as áreas que podem ser testadas para posteriormente, através de um critério de análise de riscos, fazer a escolha dos testes mais importantes. Esta escolha é feita com os riscos já identificados e traduzidos para um sistema de ranqueamento para, assim, escolher as áreas mais importantes a serem testadas. Como parte deste processo, os testadores e gerentes podem focar o esforço de teste construtivamente (HUTCHESON, 2003). Na metodologia, isto é evidenciado no momento em que os testes se iniciam na fase de definição de requisitos e continuam até o teste de validação, feitos pelos usuários. É importante ressaltar que este princípio básico de foco no esforço de teste de forma construtiva é o principal que rege a metodologia desenvolvida e é esta idéia, oriunda do método MITs, que baseia parte deste trabalho de conclusão de curso.

66 4.3 Estratégias de Teste 63 No método MITs, na fase de planejamento, provê ferramentas para medidas que permitem ao trabalho de teste adequar-se a uma estrutura de tempo especificada, este planejamento, na metodologia, é especificado por meio de um documento de plano de testes cuja estrutura é estabelecida pela Norma IEEE 829. O método permite que os reponsáveis pelos testes e os gerentes do projeto acompanhem o impacto dos conflitos de escolha nos recursos e na cobertura de teste associados com variadas linhas de tempo e estratégias de teste. O método utiliza planilhas de trabalho e enumeração para medir o custo do tempo/economias associadas com várias formas de soluções. As ferramentas MITs, da mesma forma que planilhas de trabalho e inventários de teste, servem como um apoio na negociação de recursos e estruturas de tempo para o esforço de teste real (HUTCHESON, 2003). Entretanto, a metodologia não será composta de nenhuma fase que determine recursos e tempo de esforço de teste, isto pode ser verificado em livros que tratam de Análise de Riscos em projetos de teste de software, como é o caso do livro escrito por Rios (2005). Durante a fase de teste, as ferramentas MITs facilitam na definição do caminho do progresso do teste, e determinam o fim lógico do esforço de teste. O método usa curvas S para opinião, trajetória do teste e relatório de status. Essas curvas mostram o status do teste e o sistema de forma rápida. Curvas S mostram a taxa do progresso a magnitude das questões abertas no sistema. Os gráficos também mostram o provável fim do esforço do teste e indica claramente quando o conjunto de testes já não gera mais resultados (HUTCHESON, 2003). As curvas S são muito utilizadas em programação e controle de projetos, pois sua utilização torna mais visível o progresso do prazo e a perspectiva de ultrapassar ou não o custo total previsto. Um exemplo de Curva S é mostrado na figura 4.5. Estas curvas não serão utilizadas na validação da metodologia, porém sua utilização é muito importante para a determinação do fim lógico das execuções dos testes e pode, posteriormente ser inserida à metodologia em trabalhos futuros. O método MITs mede o desempenho do esforço de teste, então os inventários, suposições e métodos de teste podem ser ajustados e melhorados para esforços futuros. Uma métrica de desempenho baseada na porcentagem do erros descobertos durante o ciclo de teste é usada para avaliar a efetividade da cobertura de teste. Baseados nessa métrica, suposições e inventários de teste podem ser ajustados e melhorados para esforços futuros.

67 4.3 Estratégias de Teste 64 Figura 4.5: Curva S. (ASPELL, 2006) Este método possui uma idéia que é de suma importância para a metodologia proposta neste trabalho de conclusão de curso, no sentido em que os testes mais importantes (ou as funcionalidades mais importantes) a serem executados(as) devem ser escolhidos dentre todos os possíveis a serem trabalhados. Outro aspecto importante é que ele aborda a utilização de um critério de escolha através da análise dos riscos, sendo que na metodologia desenvolvida fica a cargo da equipe de teste escolher a melhor abordagem de análise de risco com relação ao produto a ser testado. De qualquer forma, na validação da metodologia, será utilizada uma abordagem de análise de riscos explanada no próximo capítulo Norma IEEE 829 No capítulo 2, foram descritas algumas iniciativas de qualidade e, dentre estas iniciativas, foi verificado que a ISO exige o estabelecimento de procedimentos de teste devidamente planejados e projetados, entretanto esta norma não dita como estes planejamentos e projetos serão feitos. Desta forma, a solução para este problema foi encontrada utilizando a norma IEEE 829, que serve como uma referência de documentação das atividades de teste. Esta norma (composta por um conjunto de documentos básicos de teste) foi desenvolvida por um conjunto dos comitês de coordenação de padrões do IEEE-SA (The Institute of Electrical and Electronics Engineers Standards Association).

68 4.3 Estratégias de Teste 65 A IEEE 829 foi homologada em 1998 com o propósito de oferecer uma estrutura de referência comum a todos os envolvidos no desenvolvimento do projeto de teste de software. O intuito foi de prover um gerenciamento facilitado do teste (IEEE, 1998). O documento descrito neste padrão cobre o planejamento de teste, a especificação de teste e o relatório de teste. Cada um destes documentos possui sua funcionalidade específica. O plano de teste prescreve o escopo, a abordagem e a programação das atividades de teste. Nele são identificados os itens a serem testados, as tarefas de teste a serem desempenhadas, quem são os responsáveis por cada uma das atividades e os riscos associados com o plano. A estrutura deste documento será explicitada na Metodologia, visto que a formulação do plano trata-se de uma das suas etapas. A especificação dos testes é coberta por três tipos de documentos: Especificação do projeto de testes: refina a abordagem do teste, e identifica as características a serem averigüadas através do projeto, também contém a especificação dos testes associados. Especificação dos casos de testes: documenta os valores reais usados para a entrada juntamente às saídas antecipadas. Um caso também identifica restrições no procedimento de teste resultantes de casos de uso específico. Os casos de uso são separados do projeto de testes para permitir que sejam usados em mais de um projeto e possibilitar também o seu reuso em outras situações. Especificação do procedimento de teste: identifica todos os passos requeridos para a operação do sistema e o exercício dos casos de teste especificados de forma a implementar o projeto de teste associado. Estes procedimentos são separados da especificação do projeto, por possuirem o intuito de seguir passo a passo e não precisarem entrar em muitos detalhes. Dentre estes três documentos, os dois primeiros também compõem a Metodologia construída neste trabalho e serão aprofundados na seção 5.3. O documento Especificação do procedimento de teste possui a seguinte estrutura: Identificador da especificação do procedimento de teste: expõe uma referência para

69 4.3 Estratégias de Teste 66 a especificação do projeto de teste associada; Objetivo: expõe os objetivos deste documento, se por exemplo este procedimento executa alguns casos de teste, são mostradas as referências de cada um deles; Requisitos especiais: requisitos necessários para a execução de um dado procedimento; Etapas do procedimento: composto de algumas etapas necessárias para a execução do procedimento de teste. Estes elementos podem ser ordenados respectivamente e também podem ser incluídos outras unidades a este documento (IEEE, 1998). O relatório de teste é coberto por quatro documentos: Relatório de transmissão de um item de teste: identifica os itens de teste que serão transmitidos para teste além de especificar quais as pessoas responsáveis por cada item de teste, sua localização física e seu status. Log de teste: relata o que ocorre durante a execução dos testes. Relatório de sumário de teste: sumariza as atividades de testes associadas a uma ou mais especificações de projetos de teste. Relatório de incidente de teste: descreve qualquer evento que ocorra durante a execução do teste, o qual requer uma investigação adicional. O relatório de transmissão de um item de teste possui a seguinte estrutura: Identificador; Itens de transmissão: identifica os itens de teste, seu nível de versão/revisão; Localização: identifica por onde os itens são transmitidos; Status: define a situação dos itens de teste que são transmitidos, indica se existe modificações pendentes; Aprovações: especifica os nomes das pessoas que podem aprovar esta transmissão, estabelece espaços para assinaturas e datas.

70 4.3 Estratégias de Teste 67 Log de teste, que estabelece detalhes relevantes sobre a execução dos testes possui uma estrutura conforme abaixo: Identificador: especifica um identificador para um dado log de teste; Descrição: descreve entradas no log de teste; Atividade e eventos de entrada: composto de uma estrutura que contém o relato de datas e tempo de execução, também descreve, entre outros elementos, a execução dos procedimentos de teste. O relatório de sumário de teste também é composto de uma estrutura específica, é composto de 8 partes. Entre seus elementos encontra-se o resumo das atividades, que faz o resumo dos resultados da atividade de teste, também identifica todos os incidentes que não foram resolvidos. Este documento é usado para fazer uma cobertura do processo de teste comparando os incidentes encontrados durante o teste de sistema com os testes de validação (feito pelos clientes). O relatório de incidente de teste contém em sua estrutura: Identificador do incidente de teste; Sumário; Descrição do incidente; Impacto. Como mostra a figura 4.6 esta norma divide as atividades de teste em três etapas: a preparação do teste, execução e o registro do teste. A figura 4.6 também mostra o relacionamentos entre os documentos bem como os documentos resultantes da execução de cada uma das fases. Assim, a utilização da norma auxiliará na descrição de informações necessárias para testes de produtos de software bem como para as fases de planejamento, projeto e realização dos testes. Pois não é pertinente começar a se pensar nos testes apenas quando tiver sido completada a codificação do produto de software (CRESPO et al., 2004). Quando é referida a necessidade de se codificar e testar o software, o desenvolvedor deve além de codificar, realizar a documentação de cada unidade de software, da mesma forma, a

71 4.4 Resumo do Capítulo 68 Figura 4.6: Relacionamento entre os documentos. (CRESPO et al., 2004) atividade de teste deve estar acompanhada de planos de teste, que por sua vez devem estar bem documentados. Desta forma, parte dos documentos descritos pela norma irá participar de algumas das etapas da metodologia desenvolvida neste trabalho de conclusão de curso. 4.4 Resumo do Capítulo A construção deste capítulo teve como objetivo fundamentar a metodologia proposta para este trabalho. Visto que é necessário o conhecimento de alguns atributos para a construção de uma metodologia de teste, foi feita explicação dos princípios básicos que regem as atividades de teste, além da explanação sobre técnicas de testes e suas estratégias. Também foram introduzidos os elementos que deram base teórica e de documentação (MITs e IEEE 829) para a metodologia a ser analisada no próximo capítulo. Um outro elemento essencial e que será explicado nos capítulos 5 e 6 é a Validação dos Requisitos

72 4.4 Resumo do Capítulo 69 tendo como uma de suas técnicas o Teste de Requisitos, uma das etapas validadas da metodologia. Esta etapa é considerada fundamental no processo de teste por ser mais econômica e detectar erros de antes mesmo do software ser desenvolvido.

73 70 5 Metodologia de Teste para a Qualidade no Processo de software: QTest 5.1 Introdução Segundo Kenett e Baker (1999) em um processo de software com qualidade, a utilização de metodologias é um elemento que compõe este processo. Isto incorpora a necessidade de construção de metodologias, como: análise de requisitos, projeto, teste, código, documentação, configuração, gerenciamento, operação, e manutenção, sendo a explicação da metodologia de teste, construída neste trabalho, o foco deste capítulo. Esta metodologia foi construída baseada na idéia de escolha dos testes do método The Most Important Tests (MITs) e no modo padrão de documentação da Norma IEEE 829 bem como no princípio de realização de testes antes da codificação. MITs trata de um método desenvolvido para auxiliar na identificação de riscos de falhas no sistema com o intuito de testar apenas o que for mais importante dentre todas as áreas que podem ser testadas, tendo como princípio básico o foco no esforço de teste de forma construtiva (HUTCHESON, 2003), princípio este utilizado na construção da metodologia, ou seja o acompanhamento de todo o processo de desenvolvimento de software inclusive na parte que antecede a codificação. A norma IEEE 829 descreve um conjunto de documentos de teste de software. Ela especifica a forma e conteúdo padrões de cada documento de teste (IEEE, 1998). Esta norma fornece a base para algumas etapas da metodologia que tratam da documentação da atividade de teste. Neste capítulo, tanto o método quanto a norma serão explanados antes da explicação da Metodologia de Teste para a Qualidade no Processo de Software.

74 5.2 Elementos que deram base à metodologia de teste desenvolvida no trabalho Elementos que deram base à metodologia de teste desenvolvida no trabalho A metodologia de teste deste trabalho de conclusão de curso, visa estruturar atividades de teste desde o início do processo de desenvolvimento do software tornando claro que as atividades de teste e o processo de desenvolvimento, relacionam-se diretamente. O processo de teste desta metodologia foi baseado na norma IEEE STD 829 e no método MITs (The Most Important Tests), dando ênfase ao Teste feito no início do processo de desenvolvimento, ou seja a Validação de Requisitos. Desta forma, as atividades de teste serão orientadas através das regras definidas pela metodologia. A metodologia de teste de software deve ser projetada tendo como base a resposta para as seguintes questões (HUTCHESON, 2003): 1. Qual o conhecimento do projeto cuja implementação será testada? 2. Quão grande será o esforço de teste? 3. O que se deve testar, visto que não é viável se testar tudo? 4. Quanto tempo irá durar o teste? Quando devemos parar? 5. Quanto irá custar? 6. Como serão identificados os testes a serem executados? 7. Estamos dentro do cronograma? Foi testado o bastante? 8. Qual a qualidade do processo de teste, a cobertura foi adequada? Em resposta a essas perguntas deve-se, primeiramente conhecer os requisitos do sistema. Se o modelo sob o qual o sistema foi projetado não possuir requisitos formais é necessário que se elaborem conjecturas e as documente, conjecturas estas sobre os requisitos do sistema que se quer testar. Caso o projeto possua especificações formais também é pertinente a documentação de suposições, caso contrário pode-se perder a oportunidade de corrigir essas hipóteses. Esse sólido entendimento acerca do produto que se deseja testar possibilita que se construam planos, projetos e casos de testes mais completos (DUSTIN, 2002).

75 5.2 Elementos que deram base à metodologia de teste desenvolvida no trabalho 72 Com relação à quantidade de testes a serem feitos, é pertinente enumerar tudo o que se deve testar. Não significando que esses testes estariam compondo o projeto, eles são apenas a conta de todos os testes que foram identificados, sendo eles relevantes ou irrelevantes na hora da execução dos testes (HUTCHESON, 2003). Deve-se testar o que for mais importante, utilizando um critério para priorizar os testes, fazendo também a análise dos riscos para determinar o conjunto de testes mais importantes do inventário (HUTCHESON, 2003). Esse é um dos focos do método dos testes mais importantes (MITs). Identificado o conjunto de testes, também é importante a construção de uma planilha de trabalho para estimar o tamanho do esforço de teste. Uma completa planilha de trabalho forma a base para um acordo de teste (HUTCHESON, 2003). Segundo a metodologia exposta no presente trabalho é nesta planilha que estarão todos os testes encontrados ou as funcionalidades que podem ser testadas. Posteriormente será utilizado um critério de análise de risco para a escolha dos testes prioritários ou das funcionalidades mais importantes, seguindo o princípio do método MITs: testar o que for mais importante. Os testes mais importantes a serem executados em cada área escolhida são adicionados ao projeto e especificação dos casos de teste (documento da norma IEEE 829), a partir daí estes testes são realizados e, no decorrer da realização pode-se desenvolver outros novos testes adicionando-os ao projeto e à especificação. No caso do apanhado estar preenchido por todas as funcionalidades que podem ser testadas e posteriormente ser feita a escolha das funcionalidades mais importantes, as mesmas são inseridas no plano de teste. Diante do conhecimento da necessidade de se escolher os testes mais importantes, chega-se à conclusão de que é difícil responder a uma pergunta: quando o teste deve parar? A construção e utilização de uma metodologia de teste de forma sistemática ameniza este tipo de dificuldade. Neste caso a metodologia atenta em uma de suas etapas para a utilização de testes que, se não forem executados, causam maiores riscos no sucesso do projeto. A norma IEEE 829 e o método MITs foram descritos no capítulo 4. As etapas da metodologia serão explanadas em seguida.

76 5.3 A metodologia proposta A metodologia proposta Como foi dito na seção anterior, a construção de uma metodologia de teste sistemática ameniza a dificuldade de se saber onde e quando o teste deve parar. Ela estrutura as atividades de teste desde o início do processo de desenvolvimento do software. A metodologia deste trabalho de conclusão de curso incorpora etapas extremamente importantes para a realização da atividade de teste, considerando a mesma não apenas uma fase do processo de desenvolvimento, mas uma atividade intrínseca a cada etapa do ciclo de vida. Trata-se de uma metodologia baseada na norma IEEE 829 e no método MITs (em um de seus aspectos) referenciados na seção anterior, dando destaque à fase de Validação dos Requisitos. Este meio organizado de se construir uma atividade de teste foi feito compondo as seguintes etapas: 1. Conhecer os requisitos do sistema desejado e/ou elaboração de conjecturas; 2. Validar os Requisitos; 3. Elaborar um apanhado do que pode ser testado e introduzir em um inventário de teste; 4. Aplicar critério de escolha do que será testado; 5. Formalizar o plano de teste; 6. Especificar o projeto de teste; 7. Especificar os casos de teste; 8. Executar os testes (casos de teste) e Relatar os Incidentes; 9. Avaliar e documentar os resultados (Relatório-Resumo de Testes) Conhecer os Requisitos e/ou elaborar conjecturas O conhecimento do que o cliente deseja que seja feito é importante não apenas para quem está desenvolvendo o sistema mas também para os desenvolvedores dos testes, independentemente de se ter ou não especificações formais sobre estes requisitos. Pois conhecer o

77 5.3 A metodologia proposta 74 sistema depois de pronto é um processo mais complicado do que acompanhar toda a fase de definição de requisitos. Caso não se tenha especificação formal dos requisitos, pode-se elaborar suposições acerca do que se está querendo testar, inserindo em um inventário de teste. O inventário de teste contém a lista de todos os requisitos e especificações do que se sabe e inclui também nossas suposições. Caso contrário, também é importante a elaboração de conjecturas e documentação das mesmas no inventário de teste (HUTCHESON, 2003). Se o projeto possuir um documento de requisitos, começa-se a partir deste documento a elaboração do inventário. Utiliza-se os requisitos pré-definidos e os insere no inventário de teste preliminar. Logo após, são catalogados projetos que possuam essas especificações preliminares. Desses projetos relacionados são verificadas as funções principais, e quais os itens testáveis das mesmas para que também sejam adicionados às funções do projeto que está sendo estudado. Da mesma forma que os analistas que fazem a engenharia dos requisitos, os desenvolvedores dos testes também precisam das mesmas atividades para a elaboração de conjecturas, bem como para o melhor conhecimento do domínio da aplicação. As atividades que facilitam esse processo são (SOMMERVILLE, 2003): Compreensão do domínio : deve-se compreender o domínio da aplicação, ou seja, caso se deseje fazer um sistema para banco, o testador, da mesma forma que o analista, deve descobrir como operam os bancos; coleta de requisitos: processo de interação com os stakeholders do sistema, é nesta fase que se tem a possibilidadede um melhor entendimento do domínio da aplicação; Classificação: considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes; Resolução de conflitos: fase que tem como principal finalidade a resolução de conflitos ocasionados por um alto número de stakeholders, dando enfase aos requisitos mais importantes; Definição das prioridades: necessidade de priorizar os requisitos mais importantes dentro de um conjunto de requisitos encontrados;

78 5.3 A metodologia proposta 75 Veririficação de requisitos: verifica-se se os requisitos são consistentes, completos e se vão ao encontro dos desejos dos usuários (SOMMERVILLE, 2003). Além destas atividades citadas acima existem outros métodos que dão base mais sólida para o levantamento e análise de requisitos, por exemplo, levantamento orientado a pontos de vista, cenários e etnografia. Após o conhecimento dos requisitos do sistema, a próxima etapa é a de Validação dos Requisitos, a mesma será tratada na próxima seção Validar os Requisitos Esta metodologia incorpora, como uma de suas etapas, a validação de requisitos, que compõe a etapa 2. Esta validação pode ser considerada um teste e deriva da necessidade de previnir os defeitos durante a fase de requisitos, através do uso de técnicas que ajudam na detecção destes erros. Essa prevenção é mais viável durante a fase de requisitos, pois o impacto de uma modificação necessário para corrigir um defeito é baixo, sendo que a única modificação será dada na documentação ou, possivelmente, no plano. É importante frisar que o plano também é desenvolvido durante esta fase. Por isso a relevância de se participar desde o início do ciclo de vida do desenvolvimento da aplicação para a realização de testes, para que se tenha facilidade em reconhecer omissões, ambigüidades, discrepâncias, entre outros problemas que afetam a testabilidade, a corretude e outras qualidades do projeto de requisitos. A tabela 5.1 mostra o custo de correção dependendo da fase em que o erro é corrigido, o que comprova a necessidade de detecção de problemas precocemente com o objetivo de se cortar gastos. A tabela de custos evidencia a importância econômica da Validação de Requisitos. Esta fase se preocupa em descobrir problemas nos requisitos. Desta forma, são verificados se existem restrições contraditórias ou diferentes em uma mesma função do sistema, se os requisitos feitos podem realmente ser implementados, entre outras verificações. Essa validação tenta verificar quão corretas estão as declarações dos requisitos, se estão disponíveis as características de qualidade desejadas bem como se as declarações dos requisitos satisfazem às necessidades de negócio. Esta necessidade de validação de requisitos de forma mais detalhada advém de que, muitas vezes, na leitura dos requisitos os mesmos parecem estar bem especificados, entretanto os problemas podem surgir quando os desenvolvedores tentam trabalhar com estes requisitos (WIEGERS, 2003).

79 5.3 A metodologia proposta 76 Fase Custo Relativo de Correção Definição $1 Projeto em alto-nível $2 Projeto em baixo-nível $5 Código $10 Teste de Unidade $15 Teste de Integração $22 Teste de Sistema $50 Pós-entrega $100+ Tabela 5.1: Custo da remoção de erros se multiplica através do ciclo de vida. (DUSTIN, 2002) Existe uma série de técnicas de validação de requisitos que podem ser utilizadas sozinhas ou em conjunto para a prevenção de falhas, são elas: revisões de requisitos, prototipação (é feito um protótipo do sistema para que o usuário final verifique se o mesmo atende às suas necessidades), geração de casos de teste ou, segundo Wiegers (2003), Teste de Requisitos (isso é feito para verificar se os requisitos são testáveis. Se o teste for difícil ou impossível de ser projetado, os requisitos provavelmente serão de difícil implementação sendo necessária a reconsideração dos mesmos), análise automatizada da consistência (utiliza-se ferramentas CASE para verificar a consistência do modelo, caso os requisitos tenham sido expressos como um modelo de sistema em notação estruturada ou formal) (SOMMERVILLE, 2003). Na revisão de requisitos é verificado o documento de requisitos a fim de detectar anomalias ou omissões, entre outros problemas relacionados. Este teste pode ser feito informalmente ou formalmente. O teste informal é feito através da consulta aos clientes para a melhor obtenção de requisitos, sem confirmação de que os requisitos documentados são os que os clientes realmente desejavam. Muitos problemas podem ser detectados dessa forma. No modo formal, quem faz os testes deve verificar a consistência de cada requisito, verificar os requisitos como um todo, tomando como ponto de vista sua completeza. Também deve ser verificado (SOMMERVILLE, 2003): Facilidade de verificação: os requisitos são passíveis de serem testados? Facilidade de compreensão: o requisito testado é adequadamente compreendido

80 5.3 A metodologia proposta 77 pelo usuário final? Facilidade de rastreamento: deve-se ter certeza da origem do requisito, se ela é claramente definida. Deve ser de fácil rastreamento, pois caso hajam mudanças no sistema é preciso saber a origem do erro, ou seja ele deve ser achado facilmente; Adaptabilidade: necessário que caso o requisito seja modificado, não provoque efeitos de grande escala em outros requisitos do sistema. A técnica utilizada para a validação desta etapa foi Teste de Requisitos. Nesta técnica os casos de teste são derivados dos requisitos do usuário para documentar o comportamento esperado do produto sob certas condições. Objetiva-se traçar casos de teste dos requisitos para ter certeza se estão ou não correspondentes com as especificações dos requisitos e a não correspondência implica em problemas encontrados. Os casos de teste são usados para verificar a coerência dos modelos de análise e protótipos (WIEGERS, 2003). Na validação os casos de teste são derivados das especificações dos requisitos, esta idéia veio de Wiegers (2003). As realizações destes casos de teste são feitas da seguinte forma: é analisado cada documento de requisitos e utilizado, para gerar os casos de teste, o conhecimento sobre o que é necessário para os requisitos funcionais bem como a consideração de requisitos não-funcionais em um sistema ideal como, usabilidade, segurança, eficiência, escalabilidade, entre outros. Os casos de teste gerados são semelhantes às especificações avaliadas possuindo a mesma estrutura, sendo adicionadas a elas características ou ações consideradas fundamentais e que podem não se encontrar nos documentos de requisitos originais bem como retiradas informações irrelevantes, ambigüidades ou erros. A estrutura utilizada para a elaboração dos casos de teste é a mostrada na figura 5.1: A figura 5.1 mostra que cada caso de teste gerado possui, obrigatoriamente, o fluxo principal. Os fluxos alternativos e de exceção irão aparecer dependendo dos caminhos que podem ser percorridos pelo usuário e/ou sistema. O Fluxo Principal descreve o caminho que deve acontecer quando o caso de uso é realizado. Seu texto descritivo deve ser claro e conciso (BEZERRA, 2002). O Fluxo Alternativo descreve o que acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal (BEZERRA, 2002). Fluxo de Exceção descreve situações de exceção, que relata o que acontece quando algo inesperado ocorre na interação entre ator e caso de uso. Um exemplo é quando o usuário realiza uma ação inválida (BEZERRA, 2002).

81 5.3 A metodologia proposta 78 Fluxo principal sem alternativas Fluxo principal com alternativas independentes Fluxo principal com alternativas exclusivas entre si A1 A2 A3 A4 Figura 5.1: Fluxos dos Casos de Teste. (BEZERRA, 2002) Teste de Requisitos faz parte da Validação de Requisitos, desta forma vê-se a necessidade de ressaltar o modelo V de software. Este modelo incorpora o princípio de se realizar o plano e o projeto de teste desde cedo. O modelo ressalta que a cada fase de desenvolvimento correspondente sejam feitos casos de teste. Este modelo pode ser apresentado conforme a figura 5.2. Nesta figura pode ser visualizada a primeira fase na qual o teste de aceitação se relaciona com os requisitos do usuário. Não há como executar testes durante o desenvolvimento dos requisitos, mas há como desenvolver casos de teste baseados nos requisitos, os casos de teste irão revelar ambigüidades, erros, omissões em seu documento de especificação de requisitos antes que os desenvolvedores iniciem o trabalho com problemas nos requisitos (WIEGERS, 2003). Requisitos do usuário: planejamento de teste de aceitação Requisitos Funcionais:planejamento de teste de sistema Arquitetura: planejamento de teste de Integração Teste de Aceitação Teste de Sistema Teste de Integração Projeto:planejamento de teste de unidade Teste de Unidade Codificação Figura 5.2: Representação do Modelo V (WIEGERS, 2003)

82 5.3 A metodologia proposta 79 Sendo assim, erros, conflitos, omissões e contradições devem ser destacados durante este teste, ficando a cargo dos usuários, do comprador do sistema, dos desenvolvedores do sistema negociar a solução para os problemas encontrados Apanhar tudo o que pode ser testado A 3 a etapa da metodologia considera a importância de se efetuar um apanhado sobre tudo o que pode ser testado, para ser posteriormente introduzido a um inventário de teste. Esta lista será preenchida com todos os possíveis testes a serem realizados, sem contar com os riscos associados. Além disso este apanhado pode ser feito no sistema como um todo, considerando todas as funcionalidades que podem ser testadas, as mesmas serão adicionadas a um inventário. É deste inventário que serão tirados os itens de teste mais importantes ou as funcionalidades mais importantes na etapa posterior Utilizar um critério de Escolha para Testar o que for mais Importante A 4 a etapa visa a aplicação de algum critério de escolha para classificar os itens mais importantes a serem testados ou as funcionalidades mais importantes a serem testadas, idéia esta provinda do método MITs. Nesta etapa também pode ser considerado o momento em que é preciso parar de testar, ou seja, até chegar no fim da lista composta na planilha. Ainda não existe um padrão único internacionalmente aceito que especifica o tamanho de um teste. Mas existem critérios que podem ser seguidos para determinar qual o momento certo de parar a execução dos testes, ou determinar o que irá conter no projeto e especificação dos casos de teste. Também existem técnicas que auxiliam na cobertura dos testes, esta cobertura serve para se ter noção do tamanho do esforço de teste e, conseqüentemente, apoiar a fase de escolha dos testes mais importantes. Existe uma técnica denominada APF (Análise de Pontos de Função) que pode auxiliar no desenvolvimento de software por meio da estimação de custos e prazos em projetos. É, segundo Lemos (2006), a métrica mais amplamente utilizada atualmente. Esta métrica mede as funcionalidades de um aplicativo baseando-se nas perspectivas do usuário (LEMOS, 2006). Pode-se dizer que a APF auxilia na cobertura de teste de forma tornar possível o conhecimento do tamanho dos testes a serem executados.

83 5.3 A metodologia proposta 80 É importante frizar que o conjunto de testes desenvolvido deve ser efetivo. O RUP, já mencionado no trabalho, utiliza a cobertura de teste baseada em requisitos e em código (CORPORATION, 2001). Na cobertura de testes baseada em requisitos existem cálculos da Cobertura de Teste para a atividade de planejamento de teste, para a Implementação dos Testes e para Executar a Tarefa. A transformação destas relações em porcentagem permite a seguinte declaração sobre a cobertura de testes baseada em Requisitos (CORPORATION, 2001): x% dos casos de teste obtiveram a taxa de êxito de y%. Essa é uma base importante de cobertura de testes que pode ser comparada aos critérios definidos. Essa cobertura pode ser importante no momento em que é feito o Relatório-Resumo de Teste, mas também pode ser usada para acompanhar os testes. A cobertura de testes baseada em código mede a quantidade de códigos executada durante os testes e é mais udada para sistemas críticos. É uma cobertura que pode se basear em fluxos de controle (instrução, ramificação ou caminhos) ou fluxos de dados. Com fluxo de controle objetiva-se testar linhas de código, condições de ramificação, caminhos que percorrem o código ou outros elementos do fluxo de controle do software (CORPORATION, 2001). Na baseada em fluxo de dados testa-se se os estados dos dados permanecem válidos durante a operação do software. Porém a escolha do que deve ser testado será feita através da análise do que for prioritário, ou seja, serão testadas as funcionalidades mais importantes, quando se trata do teste do projeto inteiro da aplicação e os itens mais importantes, quando se trata de testar apenas funcionalidades em específico, sem abranger todo o projeto. Para isso é necessário que sejam feitas as análises de riscos (HUTCHESON, 2003). A análise de riscos surgiu na metodologia pois, apesar de quanto maior o tamanho do esforço de teste os riscos de ocorrência de defeitos serem minimizados, nem sempre é possível testarmos todas as funcionalidades do software ou todos os itens de uma funcionalidade devido aos prazos limitados bem como os riscos associados a cada item ou funcionalidade a ser testada. É importante identificar que esta versão da metodologia não se preocupou com o tamanho do esforço dos testes nem com o acompanhamento mais aprofundado da atividade de teste utilizando RUP ou APF, mas com as escolha dos itens de teste ou funcionalidades mais importantes. Mas isso não impede que a equipe que utilizará a

84 5.3 A metodologia proposta 81 metodologia escolha alguma técnica de cobertura de testes, de forma a aprimorar e ter um maior embasamento durante esta etapa dos Testes Mais Importantes bem como outras etapas desta atividade. Análise de riscos é uma parte do planejamento de esforço de desenvolvimento. Esta análise é crítica em determinar o que deve ser testado, e quanto custa o teste dos itens a serem escolhidos. Riscos em um projeto são eventos que têm alguma probabilidade de acontecer, e quando ocorre podem causar danos. Os tipos de danos mais comuns são a falta de tempo, falta de dinheiro, ou prejuízo, dependendo do tipo do sistema. Análise de riscos tem o objetivo de identificar problemas potenciais que podem vir a se tornar reais. Entre diversas abordagens de análise de riscos há um modelo que identifica o risco que cada caso de uso possui para que o projeto seja finalizado com sucesso. Esta técnica inclui três tarefas segundo McGregor e Sykes (2001): Identificação dos riscos oriundos de cada caso de uso para o esforço de desenvolvimento; Quantificar o risco; Produzir uma lista de prioridades de casos de uso. Este método citado é só mais um, dentre vários existentes. Desta forma, a escolha de um critério de análise de risco dependerá da aplicação que se deseja testar. Entretanto existe um critério que é utilizado para a validação da metodologia, este critério será explicitado logo em seguida. A escolha do que é mais importante para ser testado se inicia com a avaliação da criticidade do item ou da funcionalidade. Uma funcionalidade ou item crítico podem ter alta, baixa ou média criticidade, a avaliação da criticidade irá depender da porcentagem resultante da avaliação feita pelos analistas. A escala utilizada foi de 1 a 3 e cada valor foi identificado da seguinte forma (RIOS, 2005): 1- baixo impacto no sucesso da funcionalidade: falha é trivial; 2- médio impacto no sucesso da funcionalidade; Risco é moderado = trata-se de um caso de teste ou funcionalidade que serão raros de serem efetuados pelo usuário;

85 5.3 A metodologia proposta 82 A falha pode sobreviver = a falha não irá afetar os requisitos principais da funcionalidade. 3- impacto que pode afetar seriamente o sucesso da funcionalidade. Alta prioridade; Trata-se de um requisito essencial para o bom funcionamento da funcionalidade ou do sistema; Falha pode ser crítica ou inaceitável = o cliente precisa que funcione corretamente; Risco pode ser alto ou incerto. A escolha do tipo de impacto para cada caso de teste ou funcionalidade irá depender da pontuação de algumas características como: Requisitado: se foi prometida alguma forma de verificação ou validação e se no projeto de requisitos este item está bem priorizado; Tem que haver = S ; Peso = 17 / Bom ter = N ; Peso = 1 Severidade: caso a saída seja inesperada, esta acarreta algum risco de vida. É um caso de teste crítico? Pode ser prevenido? Mais sério = S; Peso = 17 / Menos sério = S; Peso = 1; Probabilidade de ocorrer a falha: é alta a intensidade que ocorre a falha? Foi previamente testada ou integrada? Tem-se o conhecimento sobre esta funcionalidade ou caso de teste? Mais provável = S; Peso = 3 / Menos provável = N; Peso = 1 Custo: irá custar caro? Existe solução rápida? Mais caro = S; Peso = 3 / Menos caro = N; Peso = 1 Visibilidade: se falhar muitas pessoas irão ver? A falha é intermitente ou constante? Visível = S; Peso = 2 / Pouco visível = N; Peso = 1 Tolerância: qual a tolerância do usuário com relação à falha? O usuário ira esquecer a falha? Pouca tolerância= S; Peso = 2 / Baixa tolerância = N; Peso = 1 Fatores humanos: os usuários conseguem usar a interface? O sistema ou funcionalidade possui instruções? Falha = S; Peso = 2 / Acontece com sucesso = N; Peso = 1

86 5.3 A metodologia proposta 83 Note que os pesos são dados pela equipe que irá utlilizar o cálculo da criticidade, e tudo irá depender das características do sistema a ser testado. Para a escolha de uma criticidade são feitos os cálculos já mencionados e isso pode ser visto na tabela 5.3. Esta tabela mostra o valor da criticidade e conseqüentemente a clacificação do impacto para cada item. Os pesos desta tabela são diferentes dos pesos mencionados anteriormente, como já foi dito, estes pesos depende da equipe avaliadora. Requisitado Severidade Probabilidade de falha Custo Visibilidade Tolerância Fatores Humanos IMPACTO Criticidade PESO Verificar a existência deste campo S S N N S N N 0,86 Alta Ativar o campo S N N N S N N 0,52 Média Editar o campo com uma url válida S S N N N N N 0,83 Alta Editar ocampo deixando-os em branco N N N N N N N 0,17 Baixa Editar o campo com uma url inválida S N N N N N N 0,50 Baixa Criticidade Figura 5.3: Cálculo para definição da criticidade para o apanhado de itens de teste de uma dada funcionalidade Nesta avaliação foi considerado que o impacto é alto quando são marcados com S, no mínimo, os itens Requisitado e Severidade. Se apenas um desses itens for marcado como S o impacto é considerado baixo. Entretanto diversas outras variações podem ser feitas para a verificação do impacto, por exemplo, se existe uma alta probabilidade de ocorrer falha e a correção é custosa, o impacto pode ser considerado baixo, visto que não afeta os requisitos principais, a severidade ou o item Visível. O cálculo para a escolha do valor da criticidade foi feito somando-se todos os valores apontados para a funcionalidade ou caso de teste analisado e dividindo esta soma pela soma dos valores dos pesos maiores para cada característica. O resultado desta operação irá definir se o impacto é alto, baixo ou médio. Impacto alto deve ter um resultado maior ou igual a 0,8, impacto médio deve ter resultado maior ou igual a 0,5 e impacto baixo deve ser menor que 0,5. Entretanto, os valores dos pesos podem ser modificados pela empresa, de acordo com o nível do desenvolvimento. Na pontuação para a escolha dos testes/funcionalidades mais importantes é utilizado o valor da probabilidade de se passar pelo dado item de teste ou funcionalidade. Os valores de probabilidade utilizados estão entre 10% e 90%, os incrementos são múltiplos

87 5.3 A metodologia proposta 84 de 10. Zero porcento não é tratado, visto que o risco não vai ocorrer e 100% é a certeza da ocorrência, logo é um problema (RIOS, 2005). Na pontuação multiplica-se os valores da probabilidade e da criticidade, os números gerados estão entre 0,1 e 0,9. Desta forma serão escolhidos os testes/funcionalidades cuja falta possua alto risco. Foi padronizado a escolha dos testes/funcionalidades que possuem pontuação entre 2,4 e 2,7, ou seja o resultado da multiplicação de probabilidade 0,9 por criticidade 3 e 0,8 por 3. A utilização deste critério é mais adequada quando se tem um prazo limitado para o teste de todos os itens e a opção mais sensata é o teste das partes mais críticas. A garantia para prever que os itens, ou funcionalidades críticas serão testadas dentro do prazo pode ser dada pela utilização de alguma técnica que possa medir o tamanho que o esforço de teste deve possuir. Uma destas técnicas foi citada anteriormente, a APF. A validação irá utilizar este critério para escolher os testes mais importantes utilizando algumas funcionalidades do sistema avaliado Planejar o Teste A 5 a etapa trata da formalização do planejamento do teste. Caso se trate de um plano de teste que abrange todo o projeto de software, este plano é baseado na escolha das principais funcionalidades feita na etapa 4, pois é nesta etapa que se encontram especificadas quais funcionalidades serão testadas. No caso da etapa 4 ter sido aplicada apenas sobre funcionalidades (através da escolha dos principais itens a serem testados e não das funcionalidades principais), não estará detalhado no plano estes itens, serão inseridos no plano apenas as funcionalidades que serão testadas descartando detalhes dos casos de teste a serem executados. Na figura 5.4 adaptado de (IEEE, 1998) é possível ver a disposição das etapas da metodologia. A construção de um plano de teste necessita de uma auto-disciplina para que possa ser realizado de forma adequada. Para que um bom teste seja realizado é necessário a definição do que será testado e dos resultados que se espera obter para cada um dos casos de teste que são escolhidos. O plano de teste é um documento que descreve essas alternativas a serem testadas e os resultados esperados. Os planos podem ser desenvolvidos em todos os níveis de teste, desde o teste de unidade até o teste de validação (HETZEL, 1987). Nesta

88 5.3 A metodologia proposta 85 Figura 5.4: Relacionamento entre as etapas da Metodologia etapa também devem ser descritos os recursos para se efetuar as atividades de teste, o cronograma e a abordagem. Segundo a norma IEEE 829 o documento de um plano de teste deve possuir a seguinte estrutura (IEEE, 1998): Identificador do plano de teste: identificador único; Introdução: faz um resumo dos itens e características do software a serem testadas, além de referenciar alguns documentos como padrões relevantes, plano de projeto, autorização de projeto, entre outros; Itens de teste: identifica itens de teste como seu nível de revisão, sua versão, características do meio em que será transmitido, também referencia documentação de itens de teste como especificação dos requisitos, guia do usuário, guias de operação, guia de instalação, especificação do projeto, faz relatório de incidência e referência aos itens de teste; Características que serão testadas: identifica todas as características do software

89 5.3 A metodologia proposta 86 que podem ser testadas; Características que não serão testadas: características do software que não precisam ser testadas; Abordagem: especifica a abordagem que irá garantir que as carcterísticas serão adequadamente testadas, ou seja qual o tipo de teste será utilizado para o preparo do projeto, casos, e especificações de procedimentos de testes; Critério de avaliação: especifica quando e por que determinado item de teste pode falhar; Entregas de teste: identifica os documentos de entrega, dados de entrada e saída do teste devem ser identificados como entregues bem como as ferramentes que foram ou serão utilizadas; Tarefas de teste: faz a identificação do conjunto de tarefas necessárias para se executar um teste, além de identificar as dependências entre as tarefas e as habilidades requeridas; Responsabilidades: identifica os grupos responsáveis pelo gerenciamento. Projeto, preparação, execução, verificação, etc. Também identifica os grupos responsáveis por prover os itens de testes identificados e as necessidades do ambiente; Necessidade de pessoal e treinamento: especifica as necessidades através dos níveis de habilidade, além de identificar opções de treinamento; Cronograma: composto da demarcação dos testes identificados no projeto de software, define alguma demarcação adicional de teste necessária e para cada recurso de teste especifica seu período de uso; Riscos e contingências: especifica supostos riscos no planejamento de teste e para cada risco suposto também define planos de contingência; Aprovações: especifica os nomes e títulos para todas as pessoas que precisam aprovar o plano especificado, provê espaços para as assinaturas e datas.

90 5.3 A metodologia proposta Especificação do Projeto de Teste A 6 a etapa trata do projeto de teste, neste são especificados, entre outros componentes, as características a serem testadas por este projeto, seus testes associados e os casos de teste. Estes casos de teste podem ser originários dos testes mais importantes selecionados na etapa 4. Outra forma de se obter estes casos de teste é sem a seleção dos testes mais importantes, pois neste caso é considerado todo o projeto e selecionadas as funcionalidades (e não casos de teste) mais importantes. Sua estrutura é composta dos seguintes componentes (IEEE, 1998): Identificador: trata de um identificador único que é atribuído para a especificação do projeto de teste; Características a serem testadas: identifica os itens de teste e descreve as características e combinações das características que são o objeto dessa especificacão de projeto. Abordagem de refinamentos: são especificados refinamentos para a abordagem descrita no plano de teste, incluindo técnicas de teste específicas a serem usadas. Métodos de análise dos resultados dos testes podem ser identificados (programas de comparação, ou inspeção visual) Identificação do teste. projeto. Outros componentes podem ser adicionados de acordo com a necessidade do Especificação dos Casos de Teste A 7 a etapa faz a definição dos casos de teste identificados pela especificação do projeto de teste, os casos de testes são feitos de forma que especifiquem o estado inicial do ambiente, as entradas do teste e seus resultados esperados. A especificação de casos de teste pode possuir a seguinte estrutura (IEEE, 1998): Identificador: especifica a identificação do caso de teste;

91 5.3 A metodologia proposta 88 Itens de teste: possui uma breve definição dos itens e características a serem exercitadas por cada caso de teste; Especificações de entrada: especifica cada entrada necessária para executar o caso de teste, sendo que algumas entradas podem ser especificadas por valor e outras entradas podem ser especificadas por nome, também identifica todas as bases de dados apropriadas, arquivos, valores passados pelo sistema em operação, entre outros; Especificações de saída: especifica todas as características necessárias aos itens de teste, provê valor exato para cada característica ou saída requeridas; Necessidades do ambiente: hardware, software, outros; Requisitos procedimentais: descreve as restrições envolvidas na execução dos casos de teste; Dependência entre os casos: é uma lista de identificadores de casos de teste que devem ser executados previamente a outros, sumariza a natureza ou as dependências; Seções adicionais podem ser incluídas ao final. Se o conteúdo de uma seção tiver todo ou algum conteúdo referente a outro documento será necessário que seja referenciado o material utilizado (IEEE, 1998). Um caso de teste pode ser referenciado por diversas especificações de projeto de teste usado por diferentes grupos, sendo assim qualquer informação específica pode ser incluída no caso de teste para permitir o seu reuso (IEEE, 1998) Execução dos Testes A 8 a etapa faz a execução de casos de teste. Para a realização desta tarefa é necessário que se tenham sido construídos os casos de testes, cuja execução pode ser auxiliada por ferramentas próprias para esta atividade. Nesta fase de execução, os envolvidos devem ter definido o fluxo de trabalho para executar os testes, rastreamento de defeitos, além de providenciar informação, ou métricas, conforme o progresso do esforço. Existem itens que são de grande valia para a execução de testes, dois deles são (HETZEL, 1987): Deve-se ter clara a definição do começo da execução do teste. Por exemplo, quando se trata de executar o teste de sistema, vários critérios devem ser conhecidos como o

92 5.3 A metodologia proposta 89 sucesso na execução dos testes de unidade e de integração, defeitos terem sido reparados e estarem prontos para serem retestados, o código fonte ter sido armazenado em um sistema de controle de versão; Deve-se ter definidos critérios de saída, devido aos recursos, orçamentos e número de engenheiros de teste serem limitados. O escopo do teste deve ter seus limites, esses limites devem ser indicados no plano de teste de forma clara e concreta para que o time de teste determine com facilidade o ponto em que se deve completar a execução. Por exemplo, procedimentos de testes baseados em requisitos foram executados com sucesso sem problemas relevantes, ou seja, todos os defeitos de alta prioridade foram consertados e verificados através de testes de regressão. A técnica de teste (unidade, integração, validação, sistema) a ser utilizada na execução dos casos de teste depende da fase na qual o desenvolvimento do projeto encontra-se situada. Desta forma, as etapas da metodologia devem cobrir todas estas técnicas. Os critérios descritos acima devem estar baseados em critérios provados e utilizados em diferentes projetos. Esta etapa de execução deve ser realizada em paralelo à atividade de documentar o Relatório de Incidentes. Este relatório descreve os problemas encontrados durante a execução dos testes, sugestões de melhoria bem como a descrição dos procedimentos de validação dos resultados além da descrição do que foi testado Relatório-Resumo dos Testes Esta etapa visa a cobertura dos testes, fazendo uma análise de todas as fases do seu processo e verificando a sua evolução com relação ao número de erros encontrados. Entre seus elementos encontra-se o resumo das atividades, que faz o resumo dos resultados da atividade de teste, também identifica todos os incidentes que não foram resolvidos (IEEE, 1998). Este documento pode ser usado para fazer uma cobertura do processo de teste comparando os incidentes encontrados durante o teste de sistema com os testes de validação (feito pelos clientes).

93 5.4 Resumo do Capítulo Resumo do Capítulo A construção de uma metodologia de teste, tem o intuito de compor um processo de software de qualidade de forma que faça uma verificação sistemática de quanto uma determinada aplicação atende aos requisitos dos usuários finais. O princípio da metodologia proposta é auxiliar nas atividades de teste desde o início do processo de desenvolvimento, sempre visando um esforço de teste econômico. Também dá importância a uma documentação padronizada desta atividade, provendo uma estrutura de definição comum, tanto para o cliente, quanto para o fornecedor, facilitando assim, o gerenciamento desta atividade. Sendo assim, a construção de uma metodologia de teste sistemática pode amenizar a dificuldade de se encontrar o momento em que a atividade de teste deve parar, um melhor gerenciamento desta atividade devido à adequada documentação, e provê um diferencial no processo de desenvolvimento de software de qualidade.

94 91 6 Validação da Metodologia 6.1 Introdução Visando provar a eficiência da metodologia proposta, por se tratar de um elemento essencial para a obtenção de qualidade, neste capítulo é feito um estudo de caso focado na metodologia proposta. Como visto no capítulo 5, esta metodologia é composta de algumas etapas que serão realizadas no decorrer do estudo. O foco deste capítulo foi validar a metodologia, e essa validação foi feita em uma empresa que atua na área de desenvolvimento de software. A empresa não possui uma equipe de teste, também não utiliza nenhuma metodologia de qualidade, além disso não possui um modelo de processo definido, isto não impossibilitou o processo de validação, porém dificultou na obtenção da qualidade do produto final. A validação foi realizada sobre algumas funcionalidades do sistema desenvolvido pela mesma e não foi feita sobre sistema inteiro, pois o mesmo é amplo e requer a participação de mais pessoas para a execução da metodologia. Para todas as etapas foram escolhidas algumas funcionalidades e a realização de cada uma delas remete à tentativa de demonstrar como seria realizado em um projeto completo. As etapas validadas são: conhecimento dos requisitos, apanhado de teste, critério de escolha dos testes ou das funcionalidades mais importantes, validação dos requisitos, plano de teste, projeto de teste, especificação dos casos de teste e relatório de incidentes. Para a etapa de Teste de Requisitos, considerada a etapa de fundamental importância para um processo de desenvolvimento de software, foi escolhida uma funcionalidade da qual os casos de uso foram utilizados para o Teste dos Requisitos. A funcionalidade escolhida foi Assinatura Digital, da qual utilizou-se seus casos de uso. Para as outras etapas (plano de teste, projeto de teste, especificação dos casos de teste, relatório de incidentes) utilizou-se as seguintes funcionalidades Alteração de Fluxo, Assinatura Digital, Conceito de Anexo Principal e Cópia Controlada que encontram-se nos apêndices A, B, C e D, respectivamente. Para as fases de apanhado de teste e critério de escolha, foram utilizadas as seguintes funcionalidades: cópia controlada, anexo principal

95 6.2 O sistema utilizado para a Validação 92 e alteração de fluxo principal. Algumas etapas foram realizadas por meio do teste de sistema. Para cada etapa foi explicada a estruturação e, para as etapas de documentação (a maior parte das etapas) são demonstrados se os documentos seguem a padronização imposta pela Norma IEEE 829 bem como o conteúdo dos mesmos. Nas próximas seções serão mostrados os detalhes de como foi utilizada cada etapa da metodologia e, antes disso, é feita uma descrição das características principais do sistema. 6.2 O sistema utilizado para a Validação O sistema, realizado pela empresa na qual foi validada a metodologia, simula executa e otimiza processos de negócios possibilitando fácil interação com as pessoas, documentos, equipamentos e sistemas. No seu módulo BPA/BI (Business Process Analysis/ Business Inteligence)a empresa que possui este sistema pode ter um quadro geral da organização, além disso este módulo tem suas características como: Criação de Datawarehouse, filtros para análises e criação de fórmulas, dashboards entre outros. Um outro módulo deste sistema é o GED (Gerenciador Eletrônico de Documentos). Este módulo dipõe documentos eletronicamente e os mesmos podem ser gerenciados pelos usuários, algumas de suas características são: multi-plataforma, pesquisa avançada por conteúdo, fluxo de criação, editoração, versão e revisão, modelados de acordo com o negócio, assinatura digital padrão ICP-Brasil entre outros. Nas próximas seções as etapas da metodologia são explanadas sob o ângulo da validação de cada uma. 6.3 Conhecer os Requisitos e/ou Elaborar Conjecturas Esta etapa foi realizada por meio do aprofundamento sobre como o sistema a ser testado funciona, de forma a facilitar o conhecimento das novas funcionalidades que foram inseridas no mesmo. Sendo assim, foram utilizados os casos de uso do sistema além do entendimento do mesmo tirando dúvidas com os envolvidos no processo de desenvolvimento do software.

96 6.4 Apanhar tudo o que pode ser testado Apanhar tudo o que pode ser testado O inventário realizado na validação desta etapa utilizou-se da escolha de todos os testes possíveis de algumas funcionalidades, essas funcionalidades são: Alteração de Fluxo de Aplicação (Apêndice A), Cópia Controlada (Apêndice D) e Conceito de Anexo Principal (Apêndice C). Em seguida podem ser vistas as listas de itens de testes para cada delas: 1. Alteração de Fluxo de Aplicação verificar a existência deste campo - saída esperada: existencia do campo; ativar o campo - saída esperada: aparecimento do campo url; editar este campo deixando-o em branco - saída desejada: entrada no sistema apenas com a tela de menu em branco; editar este campo com uma url válida - saída esperada: entrada no sistema e junto à interface do menu o link esperado; editar este campo com uma url inválida - saída esperada: mensagem especificando que url não é válida/ interface do menu com uma página de erro. 2. Cópia Controlada selecionar um documento - saída esperada para este caso: opção do botão impressão de cópias controladas ; Clicar no botão impressão de cópias controladas- saída esperada: histórico das cópias já impressas e opções de manipulação; Usuário seleciona a opção Novo - saída esperada: o sistema apresenta opções para impressão. Cada documento deve possuir os campos de Destinatário, páginas, informações de data e hora; Usuário não seleciona nenhuma opção e executa o processo de cópia - saída esperada: mensagem especificando que o usuário deve escolher algum documento para ser impresso; Usuário seleciona um documento, mas não escolhe um destinatário - saída esperada: mensagem solicitando um destinatário; Usuário seleciona um documento mas coloca os números das páginas em um formato incorreto - saída esperada: mensagem solicitando formato correto das páginas;

97 6.4 Apanhar tudo o que pode ser testado 94 Usuário seleciona um documento e preenche todos os campos corretamente - saída esperada: apresentação de um pdf com a cópia das páginas solicitadas bem como o nome do destinatário no rodapé do documento e a informação de que se trata de uma cópia controlada. Também é necessário que esta cópia seja adicionada ao histórico. 3. Conceito de Anexo Principal Verificar se na tela de manutenção do workflow existe o campo Anexo Principal - saída esperada: existência do campo; Escolher um documento para aquele workflow - saída esperada: documento ser apresentado como Anexo Principal e sua Interface; Participar de uma solicitação que contenha o Anexo - Saída esperada: visualização do anexo principal em formato de livro ou thumbnails; Clicar no formato thumbnails e folhear utilizando os botões Próxima ou Anterior - saída esperada: interface de thumbnails desejada e paginação feita com sucesso sem demora na execução; Clicar no formato livro e folhear utilizando os botões Próxima ou anterior - saída esperada: interface de livro e paginação feita corretamente sem demora na execução; Clicar no formato livro e folhear utilizando os números da páginas- saída esperada: interface de livro e paginação feita corretamente sem demora na execução; Inserir documento no anexo principal de um workflow com o formato.tiff - saída esperada: documento transformado em anexo principal corretamente; Inserir documento no anexo principal de um workflow com o formato.jpg - saída esperada: documento transformado em anexo principal corretamente; Inserir documento no anexo principal de um workflow com o formato BR Office Writer- saída esperada: documento transformado em anexo principal corretamente; Inserir documento no anexo principal de um workflow com o formato Microsoft Office Word- saída esperada: documento transformado em anexo principal corretamente;

98 6.5 Critério de Escolha dos Testes Mais Importantes Critério de Escolha dos Testes Mais Importantes A essência deste critério é a técnica utilizada para sua validação, ou seja, o critério utilizado, já foram demonstrados no capítulo 5. A escolha dos testes mais importantes será dada com base no apanhado feito na seção 6.4. A seguir, para cada funcionalidade, encontra-se a lista dos testes mais importantes detectados com este critério. 1. Alteração de Fluxo de Aplicação verificar a existência deste campo - saída esperada: existencia do campo. Resultado: 2,7. Probabilidade: 0,9 (pois para se testar esta funcionalidade tem que se passar por este procedimento). Criticidade: 3 (pois se a saída for inesperada causa um alto risco no sucesso da funcionalidade); Ativar o campo - saída esperada: aparecimento do campo url. Probabilidade: 0,8 (pois para se testar a funcionalidade tem que se passar por este procedimento a não ser quando o teste é feito com o campo desabilitado). Criticidade: 3 (se a saída for inesperada causa alto risco na funcionalidade pois a mesma não assume seu papel). Resultado: 2,4; Editar este campo com uma url válida - saída esperada: entrada no sistema e junto à interface do menu o link esperado. Probabilidade: 0,8. Criticidade: 3 (pois não atende à necessidades da funcionalidade). Resultado: 2,4; Editar o menu e posteriormente desativá-lo. Probabilidade: 0,8. Criticidade: 3 (visto que a funcionalidade não atende aos requisitos principais); Uma tabela na qual é calculada o valor da criticidade pôde ser vista na seção Esta tabela foi feita utilizando a funcionalidade Alteração de Fluxo de Aplicação. 2. Cópia Controlada selecionar um documento - saída esperada para este caso: opção do botão impressão de cópias controladas. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7; Clicar no botão impressão de cópias controladas- saída esperada: histórico das cópias já impressas e opções de manipulação. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7;

99 6.5 Critério de Escolha dos Testes Mais Importantes 96 Usuário seleciona a opção Novo - saída esperada: o sistema apresenta opções para impressão. Cada documento deve possuir os campos de Destinatário, páginas, informações de data e hora. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7; Usuário seleciona um documento mas coloca os números das páginas em um formato incorreto - saída esperada: mensagem solicitando formato correto das páginas. Probabilidade: 0,8. Criticidade: 3. Resultado: 2,4; Usuário seleciona um documento e preenche todos os campos corretamente - saída esperada: apresentação de um pdf com a cópia das páginas solicitadas bem como o nome do destinatário no rodapé do documento e a informação de que se trata de uma cópia controlada. Também é necessário que esta cópia seja adicionada ao histórico Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. 3. Conceito de Anexo Principal Verificar se na tela de manutenção do workflow existe o campo Anexo Principal - saída esperada: existência do campo. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Escolher um documento para aquele workflow - saída esperada: documento ser apresentado como Anexo Principal e sua Interface. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Participar de uma solicitação que contenha o Anexo - Saída esperada: visualização do anexo principal em formato de livro ou thumbnails. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Clicar no formato thumbnails e folhear utilizando os botões Próxima ou Anterior - saída esperada: interface de thumbnails desejada e paginação feita com sucesso sem demora na execução. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Clicar no formato livro e folhear utilizando os botões Próxima ou anterior - saída esperada: interface de livro e paginação feita corretamente sem demora na execução. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Clicar no formato livro e folhear utilizando os números da páginas- saída esperada: interface de livro e paginação feita corretamente sem demora na execução. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ;

100 6.6 Teste de Requisitos 97 Inserir documento no anexo principal de um workflow com o formato.tiff - saída esperada: documento transformado em anexo principal corretamente. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Inserir documento no anexo principal de um workflow com o formato.jpg - saída esperada: documento transformado em anexo principal corretamente. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Inserir documento no anexo principal de um workflow com o formato BR Office Writer- saída esperada: documento transformado em anexo principal corretamente. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Inserir documento no anexo principal de um workflow com o formato Microsoft Office Word- saída esperada: documento transformado em anexo principal corretamente. Probabilidade: 0,9. Criticidade: 3. Resultado: 2,7. ; Esse resultado não irá atrapalhar o processo de teste no caso de se dispor de tempo para testar os outros itens de teste que não foram considerados os mais importantes. 6.6 Teste de Requisitos O Teste de Requisitos é de suma importância no processo de desenvolvimento de software pois pode detectar falhas nos requisitos no início do projeto, o que diminui a ocorrência de erros na fase de desenvolvimento. Esta técnica trata de um tipo de Validação de Requisitos e é utilizada para evitar experiências frustrantes para muitos desenvolvedores de software que, muitas vezes, começam a implementar requisitos ambíguos ou incompletos. Conforme mostra a figura 6.1 adaptada de Wiegers (2003), o Teste de Requisitos feito no presente trabalho foi realizado logo após a especificação dos requisitos do software sendo que o mesmo pode ser composto pelos requisitos funcionais, atributos de qualidade, interfaces externas e restrições. Segundo Wiegers (2003) um procedimento de teste de requisitos requer que seja iniciado no início do desenvolvimento do processo (WIEGERS, 2003). Entretanto, a autora tem realizado testes de requisitos durante o desenvolvimento do sistema e acredita que, pelos resultados, estes testes podem ajudar mesmo nas fases posteriores. Os requisitos funcionais especificam a funcionalidade do software que os de-

101 6.6 Teste de Requisitos 98 Figura 6.1: Teste de Requisitos procede a fase de Especificação dos Requisitos do Software senvolvedores devem construir dentro do produto, descrevendo informações que os desenvolvedores precisam para implementar (WIEGERS, 2003). Os atributos de qualidade possuem a descrição da funcionalidade do produto, através da descrição das características em várias dimensões que são importantes tanto para os usuários quanto para os desenvolvedores (WIEGERS, 2003). Durante a experiência desenvolvida neste trabalho verificou-se que os casos de testes demonstram os caminhos pelos quais o processo de teste deve percorrer, bem como as saídas esperadas por cada caminho percorrido. Sendo assim, espera-se, com a construção destes casos, maior facilidade em detectar erros através de testes, sejam erros de qualquer natureza. O processo de construção dos casos de teste ocorreu da seguinte forma: Para cada caso de uso foram analisadas as Ações do Ator e as Ações do Sistema, as ações estão divididas em Fluxo Principal e Fluxo Alternativo, podendo haver também Fluxo de Exceção. Para cada ação, foi verificado se poderiam ocorrer erros, omissões e ambigüidades diante da execução delas ou se poderiam haver outros caminhos além destes descritos pelas ações. Este processo sempre tentou enxergar o futuro, ou seja, com a funcionalidade do dado caso de uso pronta. Os casos de uso testados estão dispostos nos seguintes apêndices colocados ao final do trabalho: E, F e G, na mesma ordem dos

102 6.6 Teste de Requisitos 99 testes. O processo de procura por erros nos documentos de requisitos começou derivando casos de testes conforme os casos de uso e outras representações de requisitos de usuários. Para cada caso de teste realizado, caso ele tenha modificado o que há no caso de uso ou tenha incluído um item a mais que até então não existia, será explanado sobre o porque de tal alteração ou adição. Abaixo estão relacionados os casos de uso e seus respectivos casos de teste Caso de uso Verificar assinaturas de documentos Casos de teste Primeiro Caso de teste Fluxo Principal 1. O usuário participa de um workflow no qual a atividade possui um documento com assinaturas digitais. 2. O usuário clica para Visualizar o Documento. 3. Se o documento possuir assinaturas digitais, o sistema mostra um botão de Visualização de Assinaturas Digitais. 4. O usuário clica no botão. 5. O sistema abre uma janela com as assinaturas daquele arquivo e opção para visualização das informações das assinaturas 6. O usuário clica na lupa 7. O sistema mostra as informações da assinatura. 8. O usuário deseja sair das informações e clica no botão SAIR 9. A requisição é processada pelo sistema voltando à tela com a lista de assinaturas (5). Fluxo Alternativo (5) Usuário clica no botão SAIR caso deseje sair da janela.

103 6.6 Teste de Requisitos 100 O sistema processa a requisição voltando à tela do documento. Segundo Caso de Teste Fluxo Principal 1. O usuário clica em Documentos Assinados, que se encontra no item do Menu Documentos. 2. O usuário clica para Visualizar o Documento. 3. Se o documento possuir assinaturas digitais, o sistema mostra um botão de Visualização de Assinaturas Digitais 4. O usuário clica no botão. 5. O sistema abre uma janela com as assinaturas daquele arquivo e opção para visualizaçãodas informações das assinaturas. 6. O usuário clica na lupa 7. O sistema mostra as informações da assinatura. 8. O usuário deseja sair das informações e clica no botão SAIR. 9. A requisição é processada pelo sistema voltando à tela com a lista de assinaturas (5). Fluxo Alternativo (5) Usuário clica no botão SAIR caso deseje sair da janela O sistema processa a requisição voltando à tela do documento Comentários: Os casos de teste exibidos como casos de uso procuraram demonstrar o acontecimento de visualização das assinaturas em dois tipos de contexto. Os casos de teste, estão mais detalhados que o caso de uso, explicitando os passos realizados em um processo de visualização das assinaturas. Foi introduzido nos casos de teste a especificação de que só aparecerá o botão de visualização das assinaturas se existirem assinaturas. Também é mostrada a necessecidade do botão SAIR, o que não acontece no caso de uso, neste caso o desenvolvedor pode implementar a funcionalidade e esqueçer

104 6.6 Teste de Requisitos 101 deste botão de suma importância em termos de usabilidade. Além disso explica que irá voltar à tela com a lista de assinaturas logo após clicar no botão SAIR. Outro aspecto importante e que não foi feito no caso de uso é a adição de um fluxo alternativo, no qual o usuário sai da janela com as assinaturas do arquivo. O item de navegação nos documentos do GED (Gerenciador Eletrônico de Documentos) se remete ao terceiro caso de teste, neste caso é redundante explicá-lo. Além disso não foi definido o significado de GED. O GED trata-se de um gerenciador de documentos eletrônicos Caso de uso Manipular Keystore Casos de teste Primeiro Caso de Teste Fluxo Principal 1. O usuário seleciona a opção Manipular Keystore por meio de um item do menu denominado Configurações. 2. Se não houverem usuários com assinaturas no sistema, o sistema apresenta os usuários. 3. O usuário seleciona um dos usuários para verificar suas assinaturas e manipulá-las, se necessário 4. O sistema exibe a lista de assinaturas e a opção de inclusão e exclusão para cada uma. As assinaturas que não são mais válidas são expostas de forma separada. 5. O usuário clica na lupa de uma dada assinatura para detalhamento da mesma. 6. O sistema processa a requisição e exibe as informações relacionadas a esta assinatura. Fluxo Alternativo (2) O usuário clica no botão SAIR. Para sair da janela com a lista de usuários O sistema processa a requisição voltando ao menu principal. Fluxo Alternativo (4)

105 6.6 Teste de Requisitos 102 O usuário clica no botão SAIR para sair deste contexto. O sistema processa a requisição voltando à tela dos usuários Fluxo Alternativo (6) O usuário clica no botão SAIR O sistema processa a requisição, voltando à tela com a lista de assinaturas. Segundo Caso de Teste Fluxo Principal 1. O usuário seleciona a opção Manipular Keystore por meio de um item do menu denominado Configurações. 2. Caso hajam usuários com assinaturas no sistema, o sistema apresenta os usuários. 3. O usuário seleciona um dos usuários para verificar suas assinaturas e manipulá-las se necessário. 4. O sistema exibe a lista de assinaturas e a opção de inclusão e exclusão para cada uma. 5. O usuário clica no botão para excluir uma dada assinatura. 6. O sistema processa a requisição e exibe uma mensagem perguntando ao usuário se ele relamente deseja excluir a assinatura. 7. O usuário clica na opção SIM. 8. O sistema processa a requisição fornecendo uma mensagem de feedback informando se a requisição foi realizada com sucesso. 9. O usuário clica em OK 10. O sistema dá a ação como concluída. Fluxo Alternativo (6) O usuário clica em NÃO

106 6.6 Teste de Requisitos 103 O sistema processa a requisição e retorna à janela com a lista de assinaturas. As expressões assinaturas e certificado parecem se referir à mesma coisa. Mas pelo que foi descrito no caso de uso só aparece um certificado nas informações, mesmo que o usuário tenha feito diversas assinaturas em documentos. Sendo assim, fica estranho excluir um certificado sendo que o mesmo pode ter sido usado para várias assinaturas e, no passo 4 subentendeu-se que a exclusão seria de uma assinatura em específico e não de um certificado. Terceiro Caso de Teste Fluxo Principal: 1. Usuário clica no botão Manipular Keystore 2. Sistema apresenta uma mensagem avisando que não existem usuários com assinaturas 3. O usuário clica no botão OK para efetivar o processo 4. O sistema completa a operação voltando ao menu principal. Comentários: 1 o caso de teste: Os casos de teste derivados do caso de uso Manipular Keystore, faz uma breve descrição de quando o usuário clica na opção de detalhamento da assinatura, esta descrição não aparece no caso de uso. No fluxo alternativo (2) o usuário pode sair da janela com a lista de usuários. No fluxo alternativo (4) o usuário pode sair daquele contexto com a lista de assinaturas. No fluxo altenativo (6) o usuário pode sair da tela com informações da assinatura. 2 o caso de teste: neste caso é detalhado que o usuário escolhe uma assinatura e clica no botão para a sua exclusão. O sistema processa a requisição e exibe uma mensagem perguntando ao usuário se o mesmo tem certeza que deseja excluir a assinatura. Se o usuário clicar em SIM, o sistema fornece uma mensagem de feedback e o usuário clica em OK dando a ação como concluída. Se o usuário clicar NÃO o sistema processa a requisição e retorna à janela com a lista de assinaturas. Note que faltou detalhamento com relação ao funcionamento da funcionalidade, se o programador

107 6.6 Teste de Requisitos 104 fizer semelhante ao que estiver escrito no documento de requisitos, ocorrerão maiores problemas e retrabalhos. 3 o caso de teste: neste caso de teste é vista a possibilidade de não existirem usuários com assinaturas. Então o sistema exibe uma mensagem notificando o usuário deste imprevisto. No caso de uso esta possibilidade é omitida, o que pode ocorrer de aparecer uma janela com uma lista vazia, o que, visualmente, não é ideal. As expressões assinaturas e certificado parecem se referir à mesma coisa, ficou confuso sobre o que será excluído, o certificado, ou a assinatura. Mas pelo que foi descrito no caso de uso só aparece um certificado nas informações, mesmo que o usuário tenha feito diversas assinaturas em documentos. Sendo assim fica estranho excluir um certificado sendo que o mesmo pode ter sido usado para várias assinaturas e no passo 4 subentendeuse que a exclusão seria de uma assinatura em específico e não de um certificado Caso de uso Manipular Assinaturas Digitais Documento Casos de teste Primeiro Caso de Teste Fluxo Principal 1. O usuário participa de qualquer contexto que contenham campos do tipo arquivo. 2. O sistema oferece, junto ao campo, a opção para assinar o arquivo do documento. 3. O usuário clica na opção Assinatura Digital. 4. O sistema abre uma janela com duas opções para assinatura: repositório e hardware externo. 5. O usuário escolhe a opção Repositório 6. O sistema abre uma janela com a visualização das chaves existentes 7. O usuário seleciona a chave a ser utilizada e reponde se deseja armazenar a chave pública do repositório 8. O usuário opta por armazenar

108 6.6 Teste de Requisitos O sistema retira a chave da lista 10. O usuário clica em OK 11. O sistema realiza a assinatura do documento e processa uma mensagem de feedback avisando ao usuário que a assinatura foi realizada com sucesso retornando à tela inicial, na qual irá haver as assinaturas realizadas naquele documento juntamente com outras informações e validade Fluxo Alternativo (4) O usuário clica no botão SAIR O sistema retorna à janela que contém o campo arquivo. Fluxo Alternativo (5) Não existem chaves do usuário. O sistema exibe uma mensagem indicando que o usuário não pode assinar documentos por este meio. O usuário clica no botão OK O sistema retorna à tela com opções de assinatura. Fluxo Alternativo (7) O usuário opta por não armazenar O usuário clica em OK O sistema realiza a assinatura do documento e processa uma mensagem de feedback avisando ao usuário que a assinatura foi realizada com sucesso retornando à tela inicial, na qual irá haver as assinaturas realizadas naquele documento juntamente com outras informações e validade Segundo Caso de Teste Fluxo Principal 1. O usuário participa de qualquer contexto que contenham campos do tipo arquivo.

109 6.6 Teste de Requisitos O sistema oferece, junto ao campo, a opção para assinar o arquivo do documento. 3. O usuário clica na opção Assinatura Digital. 4. O sistema abre uma janela com duas opções para assinatura: repositório e hardware externo. 5. O usuário escolhe a opção hardware externo 6. O sistema exibe uma mensagem solicitanto que o cartão seja inserido na leitora. 7. O usuário insere o cartão adequadamente na leitora. 8. O sistema exibe uma mensagem solicitando a senha 9. O usuário digita a senha correta. 10. O sistema efetiva a assinatura e exibe uma mensagem explicando que a assinatura foi realizada com sucesso. 11. O sistema abre uma janela questionando se o usuário deseja inserir uma imagem à assinatura. 12. O usuário opta por SIM 13. O sistema insere a imagem ao final do documento representando sua assinatura e exibe uma mensagem avisando que a imagem foi adicionada com sucesso. 14. O usuário clica em OK 15. O sistema retorna à tela inicial com as assinaturas realizadas naquele momento. Fluxo Alternativo (5) O sistema detecta que o leitor não está configurado e exibe uma mensagem explicando que não há um leitor de cartão configurado. O usuário clica em OK Fluxo Alternativo (5) O sistema detecta que o leitor não está conectado e exibe uma mensagem explicando que não há um leitor disponível.

110 6.6 Teste de Requisitos 107 O usuário clica em OK. Fluxo Alternativo (8) O usuário digita a senha incorreta O sistema exibe uma mensagem avisando que a senha digitada está incorreta. O usuário clica em OK O sistema volta a pedir a senha. Fluxo de exceção (5) Se o cartão já está inserido corretamente na leitora o sistema continua a partir do passo 8. Comentários: 1 o caso de teste: neste caso de teste pode ser visto um maior detalhamento entre os itens 6 e 11 do fluxo principal, além disso os fluxos alternativos também não estão contidos no caso de uso. 2 o caso de teste: do item 6 em diante, no fluxo principal, não estão contidos no caso de uso bem como os fluxos alternativos e o fluxo de exceção. Neste caso, se o desenvolvedor for inexperiente, ele, provavelmente, não saberá o que é um e-form, teria que estar bem explicado na documentação descrita no apêndice C. Outra observação é de que no caso de uso a ação da assinatura é feita apenas por meio do repositório, sendo que deveria ser descrito como aconteceria utilizando um hardware externo. Verificando estes casos de uso e realizando os testes de requisitos notou-se uma grande quantidade de características que foram omitidas e que eram intrínsecas à implementação Por exemplo, botões para sair de uma janela, mensagens para avisar sobre o sucesso de uma operação, entre outros.

111 6.7 Plano de Teste Plano de Teste O plano de teste é o primeiro documento definido pela Norma IEEE 829 do processo de teste de software e serve como um guia para o restante da documentação. O Plano mostra atributos do teste bem como datas de duração dos testes para cada funcionalidade. Esta descrição pode ser vista no capítulo 5. Para se construir o documento de Plano de Teste do presente trabalho, estiveram disponíveis o Cronograma de projeto do software, os recursos de teste e os documentos de especificação dos requisitos. Pôde-se notar no decorrer do trabalho que, conforme mostra a figura 6.2, existem outros documentos que podem ser utilizados como ferramentas para a construção do plano e quanto maior o número de documentos disponíveis mais completo se apresenta o mesmo. Figura 6.2: Documentação utilizada para a construção do Plano de Teste (CRESPO et al., 2000) O trabalho teve o intuito de construir um plano que seguisse o padrão internacional de documentação de teste, a Norma IEEE Std 829, já apresentada e explicada no capítulo 5. O plano realizado neste trabalho é composto da estrutura especificada pela Norma. Este documento possui sua identificação, uma introdução citando quais as funcionalidades serão testadas, quais as ferramentas disponíveis para a tarefa de teste e descrição do que será testado (código fonte, código executável). Também são demonstra-

112 6.8 Projeto de Teste 109 das quais as funcionalidades e características do software foram testadas e quais as que não serão testadas. Foi explanada qual a abordagem de teste utlizada para a realização dos testes além das medidas utilizadas ao serem encontrados erros. Definiu-se no plano qual estratégia de teste seria usada, quando o teste irá parar, quais os produtos de teste que devem ser utilizados, o cronograma, entre outros. O Plano de teste é de fundamental importância para a construção do projeto de teste pois o mesmo requer algumas informações sobre quais funcionalidades serão testadas, quais não serão testadas, a abordagem de teste utilizada, a estratégia de teste utilizada, bem como o ambiente no qual o teste será realizado. Todos estes itens relatados acima são vistos no apêndice E e somam um total de 14 itens. No item 4 do apêndice podem ser vistas as funcionalidades que serão testadas e que as mesmas representam casos de uso. Além disso, é descrita a abordagem utilizada para a construção das especificações de projeto de teste e casos de teste é a especificação Funcional, ou seja, o modo como funciona a implementação como uma caixa-preta, o que implicou na realização do teste de sistema. Note que no apêndice o item 9 identifica quais são os produtos de teste, é importante perceber que estes itens são os mesmos requisitados pela metodologia. Outro fato importante é que nos itens que tratam de Adequação e Acurácia, o testador tem que adequar as especificações destes itens às funcionalidades a serem testadas, baseando-se em suas características para testá-las. A elaboração do plano de teste não é específica, pode abranger qualquer tipo de funcionalidade. 6.8 Projeto de Teste Esta etapa compreende uma fase na qual a abordagem apresentada no Plano de Teste é refinada como pode ser visto na figura 6.3. Sua estrutura compõe a especificação das funcionalidades a serem testadas e, se existirem, suas subfuncionalidades. As características são retiradas do Plano de Teste e para cada subfuncionalidade existe uma breve descrição de como a mesma deve ser testada, também são identificados os casos de teste de forma sucinta e os procedimentos de teste associados. Por final há uma descrição sobre os critérios de aprovação e reprovação utilizados. São quatro apêndices existentes de projeto de teste: I, J, L e M. Um exemplo de funcionalidade da qual foi feito o Projeto de Teste é a Assinatura Digital. Como

113 6.9 Projeto de Especificação dos Casos de Teste 110 Figura 6.3: Documentação utilizada para a construção do Projeto de Teste (CRESPO et al., 2000) pode ser visto neste documento, cada funcionalidade é composta de outras subfuncionalidades, estas últimas são retiradas por meio do conhecimento dos casos de uso e de seu funcionamento, logo após as subfuncionalidades são explicadas de forma sucinta no item 3. Como se trata de um projeto, os casos de teste são apenas definidos no item 4, porém detalhes de entrada e saída para a realização dos testes são demonstrados no documento de especificação dos casos de teste. O item 4 é o principal do projeto de teste e dá base para a documentação de Especificação dos Casos de Teste, que se remete à próxima etapa da metodologia de Teste. Exemplos de projetos de teste podem ser vistos nos já citados anteriormente. 6.9 Projeto de Especificação dos Casos de Teste A etapa de especificação de casos de teste trata da elaboração de um documento que serve como guia para quem irá testar. Esta documentação tem como base a Especificação do Projeto de Testes, um documento que foi detalhado na seção anterior e que possui atributos utilizados na especificação dos casos de teste que são as funcionalidades e subfuncionalidades da aplicação a ser testada e da qual serão documentados os casos de teste. A afirmação evidenciada nas etapas da Metodologia, de que a especificação dos casos de teste deve vir após o projeto dos casos de teste, pode ser visualizada na figura 6.4 visto que irá utilizar informações deste documento para ser efetuado. Nesta figura também po-

114 6.10 Execução dos Casos de Teste e Relatório de Incidentes 111 dem ser vistos outros documentos importantes na elaboração da especificação dos casos de teste, as especificações feitas neste trabalho tiveram acesso, dentre os documentos de software, o documento de requisitos de cada funcionalidade. Figura 6.4: Documentação utilizada para a construção da Especificação dos Casos de Teste (CRESPO et al., 2000) Este documento apóia o testador no processo de execução dos testes pois o mesmo segue esta documentação padrão para a execução dos mesmos. Durante a validação da metodologia verificou-se a real necessidade de uma boa especificação dos casos de teste. Pois, desta forma o testador tem um maior embasamento para efetuar os seus testes. A utilização desta documentação supriu a maior parte das necessidades do processo de teste e facilitou o desempenho do testador nos testes. Exemplos de especificação de casos de teste são encontrados nos apêndiceas: N, O, P e Q Execução dos Casos de Teste e Relatório de Incidentes A validação desta etapa se deu devido à utilização da especificação dos casos de teste bem como uma possível adição de novos casos de teste na medida do necessário. Estes casos de teste foram executados sobre algumas funcionalidades do sistema especificado. Para cada problema encontrado, ou sugestão de melhoria, são inseridos em um documento de Relatório de Incidentes. Este relatório contém a descrição da atividade de execução dos testes e os incidentes identificados (no qual contém a ação executada, a identificação do

115 6.11 Relatório-Resumo Teste 112 usuário que testou, a data dos testes, o ambiente em que foi testado, seu status e o grau da ocorrência). Logo abaixo destas informações, para cada erro ou item encontrado é dado o número do mesmo bem como sua descrição. Essas informações podem ser visualizadas nos relatórios de incidentes que encontram-se nos apêndices R e S. A execução dos casos de teste, feita de forma padronizada, foi muito mais eficiente e menos custosa visto que o testador poderia se esquecer dos testes já executados e refazê-los novamente sem a utilização da documentação. Desta forma, todos os passos da especificação dos casos de teste são seguidos, e novos passos podem ser inseridos no mesmo pelo próprio testador. É importante frisar que esta documentação pode servir para projetos posteriores semelhantes ao atual, mais uma motivação para a utilização da mesma na execução dos testes. Olhando o Relatório de Incidentes de Assinatura Digital e verificando o teste de requisitos de um de seus casos de uso, verifica-se que alguns problemas encontrados no relatório também foram vistos no Teste dos Requisitos. Se a correção do documento de requisitos fosse feita antes da codificação não haveriam alguns destes problemas relatados no relatório de incidentes Relatório-Resumo Teste Este relatório contém itens como: identificador, resumo dos itens de teste, no qual é mostrado o que foi utilizado para a execução dos testes bem como a descrição do ambiente. Também existem outros itens como: desvios das especificações (no qual são descritas as alterações dadas nos documentos de requisitos), avaliação da abrangência do teste, resumo dos resultados, definições e respectivas soluções para os erros encontrados. Este relatório serve como um documento no qual é feita a cobertura dos testes, verificando se o processo de teste foi realmente efetivo, juntamente com o processo de correção. Isto ajuda a identificar algumas falhas no processo que podem ser melhoradas em projetos futuros. Na validação desta etapa não foi possível comparar os resultados dos testes feitos com os clientes pois ainda não havia chegado a este estágio de teste. Entretanto, os demais atributos foram preenchidos. Um modelo deste relatório encontra-se no apêndice S.

116 113 7 Considerações Finais A universalização dos sistemas de software tem mostrado quão grande é a necessidade de maior qualidade nestes produtos. A qualidade é uma base importante para a construção de projetos que satisfazem os clientes e ela necessita de alguns elementos para que seja adquirida. Dentre estes elementos, a construção e utilização de uma metodologia de teste é importante para realização de uma atividade de teste de forma sistemática, visto que o teste, como foi dito no capítulo 4, pode ser considerado como meio para se chegar a um grau maior de qualidade. Sendo assim, foi proposta deste trabalho a construção de uma Metodologia de Teste para a Qualidade no Processo de Software e sua posterior validação. Para tanto, foi necessário o estudo de qualidade com o intuito de se obter um conceito menos abstrato. Os elementos do processo de desenvolvimento gerenciado pela qualidade que foram apontados tiveram como objetivo se chegar à conclusão da necessidade de metodologias. No trabalho foram descritos conceitos básicos de Engenharia de Software, teste de software e seus princípios, bem como as estratégias, técnicas e métodos de teste existentes. No capítulo 5 do trabalho foram elucidadas todas as etapas da Metodologia construída que foi baseada na idéia do método dos testes mais importantes (MITs) e no modo de documentação especificado pela norma IEEE 829. Esta Metodologia tem como uma de suas etapas a Validação de Resquisitos, de fundamental importância por possuir a meta de diminuir os altos custos provenientes pela detecção tardia de defeitos no software. A validação da metodologia foi feita em todas as suas etapas. Por meio do estudo de caso realizado para a validação teve-se a visão da necessidade de um Processo de Teste bem fundamentado e essa fundamentação é encontrada com o uso da Metodologia principalmente no que diz respeito à fase de requisitos. É nesta fase que podem ser realizados os maiores erros de um processo de desenvolvimento. No estudo e aplicação do Teste de Requisitos verificou-se a sua necessidade diante de erros, omissões e ambigüidades que foram encontrados durante os testes. Este teste foi feito utilizando casos de uso da empresa onde foi aplicada a metodologia e, como não foi aplicado na fase inicial e sim durante o desenvolvimento, pode-se notar que o teste resolveria boa parte dos problemas

117 7 Considerações Finais 114 com os requisitos a serem implementados, visto que o teste de requisitos, mesmo após a codificação, encontrou várias anomalias. Estas falhas foram encontradas nas funcionalidades já construídas. Conclusão, houve retrabalho! A etapa que faz o apanhado de tudo o que pode ser testado é de suma importância devido à necessidade de se ter uma lista da qual possam ser selecionados os testes ou as funcionalidades mais importantes na etapa de critério de escolha. Este critério foi de muita utilidade no sentido em que nem sempre existe tempo disponível para se testar tudo, o que resultou na criação desta etapa para a metodologia, visando dar uma maior eficiência para a atividade de teste. Entretanto a Metodologia não cobriu atividades de cobertura de testes utilizando técnicas para esta cobertuta de forma a se ter idéia do tamanho do esfoço do teste. A parte que trata da documentação dos testes foi de suma importância para a aplicação dos testes de forma sistemática. Os testes passam a possuir uma forma padronizada de documentação e causa uma maior ordem no processo de sua execução. Para o testador é um modo mais fácil de testar, sendo necessário que os desenvolvedores dos documentos tenham conhecimento das funcionalidades das quais são feitas as documentações de teste. Dessa forma, se o testador não tem muito conhecimento sobre o funcionamento do que irá testar, a documentação dará base para a atividade de teste, principalmente a Especificação dos casos de teste, esta serve como um guia para o testador se construída por pessoas especializadas. Já o Relatório de Incidentes é um documento que auxiliou o desenvolvedor na correção das falhas encontradas ou das sugestões de melhoria estabelecidas, estes documentos podem ser reaproveitados para projetos futuros e que trabalham de forma semelhante. Além de todas as etapas da metodologia existem outros atributos que devem ser considerados em um processo de teste. Visto que ele não se resume apenas aos casos de teste, sua execução e posterior elaboração de relatório de incidentes. A falta destes atributos ocasionam riscos ao processo de teste. Os atributos são os seguintes (BEZERRA, 2002): Orçamento: o orçamento pode ser insuficiente para a execução do serviço completo de teste; Qualificação da equipe técnica de testes: a equipe está preparada para participar do processo, ela consegue lidar com novas tecnologias introduzidas?

118 7 Considerações Finais 115 Ambiente de testes: deve ser compatível ao ambiente do cliente; Ferramentas: para testes de carga, por exemplo, são necessárias ferramentas de automação de testes. Aplicações com altos níveis de alterações também necessitam de ferramentas devido aos altos índices de testes de regressão. Importante saber que a escolha de ferramentas pode ser um projeto, que contém seus próprios riscos; Metodologias: necessário de uma metodologia adequada e aderente ao processo de desenvolvimento. Cronograma de recebimento de programas para teste e cronograma para devolução: necessário negociar prazos que atendam o padrão mínimo de qualidade estabelecido pelo negócio; Testware: metodologia de teste que guarde a documentação para uso futuro. Aplicações com alto índice de allterações, na maior parte das vezes, utilizam grande parte do Testware; Novas tecnologias: é um fator de risco importante. Mas pode ser contornado com treinamento adequado. Necessário elaboração de Plano de Teste que preveja esta situação. Não se pode negar a grande contribuição que esta metodologia proporciona à qualidade do produto de software final. Entretanto atenta-se para a inexistência, na metodologia, da preocupação com o processo de teste como um todo, ou seja, não há a preparação dos testes com a visão de alguns dos atributos citados acima. Dentre estes atributos encontra-se a preocupação com a obtenção de um processo de teste sistemático que esteja alinhado com um ciclo de desenvolvimento organizado e que utilize algum modelo de melhoria do processo. Um aspecto de suma importância é que, no final de cada processo de teste, seja feito um relatório no qual está contido o resultado da medição do esforço de teste. Desta forma, inventários, suposições e métodos de teste podem ser ajustados para esforços futuros. Esses detalhes que não são encontrados na metodologia podem ser adicionados em trabalhos futuros e não tira o seu mérito, visto que seu principal foco é na diminuição de erros com os testes realizados sobre os requisitos. O modelo de processo de engenharia de software RUP visto na seção pode ser retomado na conclusão pois sua utilização traz facilidade a todos os membros

119 7 Considerações Finais 116 da equipe do processo de desenvolvimento, inclusive a equipe de teste. É possível aliar esta facilidade à documentação de teste baseada na Norma IEEE 829, utilizada pela metodologia de teste criada neste trabalho. Fazendo essa junção pode-se chegar a um grau de qualidade maior do que aquele que seria alcançado usando apenas o RUP. Mas o RUP é mais uma das várias metodologias que podem ser utilizadas em um processo de desenvolvimento de software com qualidade. Um outro método bastante conhecido é o Agile, que foi representado neste trabalho pelo XP. Neste método verificou-se a falta da utilização de uma metodologia de teste que abrangesse todo o processo de desenvolvimento. Este método contém muitas vantagens quando se trata da motivação dada às pessoas envolvidas no processo de desenvolvimento, o que pode trazer benefícios em termos de qualidade de software. Neste método a documentação deve ser pouco detalhada, mas é bom tomar cuidado com o pouco detalhamento visto que podem ocorrer omissões de requisitos importantes, ou testes importantes. Diante disso, vê-se a importância que a metodologia de teste proposta oferece. Com esta metodologia os envolvidos no teste pode fazer o teste dos requisitos visando o balanceamento da documentação de requisitos (sem ambigüidades, omissões, falta de usabilidade etc). Além disso a Norma IEEE 829 possui uma documentação que não leva ao exagero, apenas ao que for essencial ao processo de testes e que possa ser lida pelos outros envolvidos que não seja a equipe de teste. Finalmente será relatado quais hipóteses estabelecidas no início do trabalho foram alcançadas. Elas serviram como um guia na atividade de teste, logicamente esses guias foram modificados algumas vezes no momento de se executar os testes devido a mudanças nos requisitos não-documentados. Facilitou a atividade de teste através da verificação de erros na definição dos requisitos, deu a opção para a utilização de algum critério de escolha que foi implantado com sucesso. Por mais que a empresa não possua um modelo de processo efetivo foi possível a validação da metodologia o que prova que, a metodologia é flexível com relação ao método de desenvolvimento utilizado pela empresa, uns dão maior facilidade, outros menor, mas em todos eles a metodologia tenta se encaixar de forma a alcançar um bom resultado. Outro fator importante apontado nas hipóteses foi a afirmação de que o processo de teste é melhor organizado utilizando uma documentação padronizada, isso é verdade, porque facilita o entendimento dos envolvidos nas atividades de teste no sentido em que eles podem se basear na Norma IEEE 829 para melhor entender as documentações baseadas nesta norma, o que torna possível a participação de todos os

120 7 Considerações Finais 117 envolvidos no processo de desenvolvimento nas atividades de teste. Desta forma, a metodologia foi validada com sucesso e poderá servir para parte do processo de teste de muitas empresas de software contribuindo, assim, com o alcance de uma qualidade tão almejada. Todo este trabalho leva a crer que a qualidade não é uma utopia, ela pode se concretizar. Pois qualidade em um sistema não é ter ausência de defeitos, mas possuir a parte ideal dos requisitos funcionais e não-funcionais, atendendo de forma balanceada aos desejos de todos os usuários.

121 APÊNDICE A 118

122 PGM Fusion 2.0 Sumário 1.INFORMAÇÕES DO DOCUMENTO... 2 HISTÓRICO DE VERSÕES INTRODUÇÃO DEFINIÇÃO DE ATORES MÓDULOS (OPCIONAL) DIAGRAMA DE CASO DE USO LISTA DOS CASOS DE USO... 3 ESPECIFICAÇÃO DO CASO DE USO UC00019 MANTER USUÁRIOS... 3 ESPECIFICAÇÃO DO CASO DE USO UC00015 EFETUAR LOGIN ANÁLISE E PROJETO... 4 ESBOÇO DE TELA... 4 REGRAS DE INTERFACE... 5 DIAGRAMA DE AÇÃO... 5 DIAGRAMA DE CLASSES... 6 DIAGRAMA DE ATIVIDADE (FLUXO DE TRABALHO DO USUÁRIO)... 7 DIAGRAMA DE SEQÜÊNCIA... 8 DIAGRAMA DE COMPONENTES... 9 ESTUDOS PRELIMINARES... 9 PROTÓTIPO... 9 ATIVIDADES ARQUITETURAIS... 9 DICIONÁRIO ESTIMATIVA DE ESFORÇO PROJETO DE TESTES Rua Expedicionário Holz, 351 América Joinville SC Brasil

123 1. Informações do Documento Projeto PGM SIGLA Versão 2.0 Fusion ECM Histórico de Versões 1.0 Primeira Versão. 1.1 Realizada fase de análise e projeto 2. Introdução O presente documento apresenta os Casos de Uso referentes à funcionalidade Alteração Fluxo da aplicação, e quais são suas relações e regras de negócio envolvidas. O principal foco desta funcionalidade é prover a possibilidade de configurar para cada usuário do Fusion, a obrigatoriedade ou não da visualização de suas pendências antes da efetiva entrada no sistema, bem como possibilitar ao administrador especificar uma página como sendo a Página inicial do Fusion para cada usuário. Esta funcionalidade será desenvolvida com o objetivo de atender ao item 71 do edital de licitação. 3. Definição de Atores Ator Administrador Usuário Comum Descrição Ator responsável por realizar as atividades administrativas do sistema, como manutenção de usuários, grupos e papéis. Qualquer tipo de usuário que realizar o login 4. Módulos (opcional) A função Alteração Fluxo da aplicação está basicamente associada aos seguintes módulos: 01 BPM: Consulta das tarefas e pendências do usuário antes da entrada efetiva no menu principal do sistema. Rua Expedicionário Holz, 351 América Joinville SC Brasil

124 5. Diagrama de Caso de Uso A configuração para alteração do fluxo da aplicação para destacar as tarefas será realizada na manutenção de usuários, e sua verificação será realizada no processo de login 6. Lista dos Casos de Uso UC Manter Usuários Versão 1 UC Efetuar Login Versão 2 Especificação do Caso de Uso UC00019 Manter Usuários Descrição alteração: breve Opção para destacar tarefas do usuário, e ainda criação de uma URL com a opção de informar um pequeno Dash de tarefas do usuário, se aplicável Especificação do Caso de Uso UC00015 Efetuar Login Descrição alteração: breve da Verificar a existência da configuração para destacar as tarefas no usuário, e então redirecionar para a interface adequada. Rua Expedicionário Holz, 351 América Joinville SC Brasil

125 7. Análise e Projeto Esboço de Tela Regra de Interface 1 (RI001): Na tela de configuração de usuário, deverá haver uma opção previamente selecionada para o administrador escolher a tela inicial para esse usuário. Tela edição/criação de usuários. Rua Expedicionário Holz, 351 América Joinville SC Brasil

126 Regra de Interface 1 (RI002): Na Página inicial específica, o Menu do Fusion deve permanecer visível para o usuário. Tela inicial de exemplo Regras de Interface [RI001] Tela de configuração de usuário: o Criar um novo atributo chamado Definir página inicial que, ao ser selecionado, exibirá um campo com o nome URL permitindo ao usuário informar uma URL específica. o Por padrão essa URL deverá vir com o endereço padrão do Dashboard. [RI002] Página inicial: o É obrigatório que o menu do Fusion permaneça disponível para o usuário, portanto a página específica definida pelo administrador deverá ser carregada no Container principal do Fusion. o Caso não seja especificada qualquer página inicial, nenhuma ação deve ser executada e a tela padrão do Fusion (Em branco) deverá ser carregada. Diagrama de Ação com.neomind.fusion.security.defaultdesktop o Criar classe conforme diagrama de classes. o Na implementação do método created da interface CreateCallBack, atribuir ao atributo defaulturl o endereço para o DashBoard, utilizando o endereço base do fusion. Assim, esse objeto, ao ser criado, virá com o valor padrão definido como o DashBoard o Adicionar na classe, para que a mesma não seja criada como tabela, mas como campo de uma. Por isso, faz-se desnecessária a adição da com.neomind.fusion.security.neouser Rua Expedicionário Holz, 351 América Joinville SC Brasil

127 o o o o Alterar classe conforme diagrama de classes. Na implementação do método created da interface CreateCallBack, atribuir ao atributo defaultdesktop uma nova instância desse objeto, e com essa instância, chamar logo após o método created manualmente. Assim, ao criar um novo usuário, uma URL padrão já estará definida e o Administrador poderá optar por deixar em branco. O método created do defaultdesktop será chamado para que o mesmo também seja iniciado com a URL padrão. Adicionar no atributo defaultdesktop com os parâmetros selectable=false e mandatory=false para que o fusion crie esse campo com a opção de deixá-lo em branco (Null). Adicionar no atributo defaultdesktop. com.neomind.fusion.engine.persistencereloader o No método cleansystemclasses, adicionar uma linha efetuando manualmente o registro da classe DefaultDesktop, pois o método normal de registro não Enxerga classes que não possuem a /core/portal/layout.jsp o Criar engine para verificar se o atributo defaultdesktop do usuário logado, possui uma URL válida. Se possuir, direcionar para a URL especificada utilizando o método padrão em javascript layoutone(url). Diagrama de Classes Segue o diagrama de classes Rua Expedicionário Holz, 351 América Joinville SC Brasil

128 Diagrama de Atividade (fluxo de trabalho do usuário) Segue o diagrama: Definir página inicial: Logar no sistema: Rua Expedicionário Holz, 351 América Joinville SC Brasil

129 Diagrama de Seqüência Seguem os diagramas: Definindo página inicial: Logando no sistema: Rua Expedicionário Holz, 351 América Joinville SC Brasil

130 Diagrama de Componentes Não se aplica. Nesta função não foram envolvidos componentes externos ao Fusion. Estudos Preliminares Não se aplica. Não foram realizados estudos preliminares para esta funcionalidade, pois ela não necessita de componentes externos, somente as entidades já existentes no Fusion. Então foi feito o estudo dessas entidades e diretamente a análise e especificação das alterações. Protótipo Foi desenvolvido o seguinte public class DefaultDesktop extends NeoObject implements CreateCallback { } private String defaulturl; public String getdefaulturl() { return defaulturl; } public void setdefaulturl(string text) { this.defaulturl = text; } public void created() { defaulturl = PortalUtil.getBaseURL()+"dash"; } Atividades arquiteturais Não se aplica pois não foi utilizada nenhuma arquitetura diferente da já utilizada pelo fusion. Rua Expedicionário Holz, 351 América Joinville SC Brasil

131 Dicionário As alterações de dicionário estão representadas no diagrama de classes, onde as classes do estereótipo entity são entidades (tabelas) do Fusion e os atributos são os campos que foram criados ou alterados. Sendo assim, não é necessário a criação de scripts de atualização, pois o Hibernate altera o banco conforme as alterações nas classes. Estimativa de Esforço # Objeto Constr Teste 1 com.neomind.fusion.security.neouser com.neomind.fusion.security.defaultdesktop /core/portal/layout.jsp com.neomind.fusion.engine.persistencereloader 2 1 TOTAL 11 7 Projeto de Testes Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Cenário 1: Definir página inicial padrão. Criar/Editar um usuário com a opção Definir página inicial selecionada. O usuário criado/editado, ao efetuar login será automaticamente direcionado para a URL especificada. Não se aplica. Selecionar no menu principal Configurações e a opção Usuários. Após, criar/editar um usuário e, além de informar os outros campos, selecionar a opção Definir página inicial informando uma URL específica ou mantendo a URL padrão (Que aponta para o DashBoard). Logar com o usuário editado/criado na tela inicial do sistema. Manual Requisitos validados Caso de uso 0015: Efetuar login e Caso de uso 0019: Manter usuários PT* Categoria** Tipo de Teste *** Cenário **** Roteiro 1 Sistema Funcional 1 * PT = Procedimento de Teste ** Categoria = Unidade; Integração ou Sistema *** Tipo de Teste = Estrutural; Funcional; Interface ou Configuração **** Cenário: Informar o número do cenário descrito no projeto de teste relacionado. Rua Expedicionário Holz, 351 América Joinville SC Brasil

132 APÊNDICE B 119

133 PGM Fusion 2.0 Sumário PGM Fusion Sumário INFORMAÇÕES DO DOCUMENTO INTRODUÇÃO DEFINIÇÃO DE ATORES MÓDULOS (OPCIONAL) DIAGRAMA DE CASO DE USO LISTA DOS CASOS DE USO...7 ESPECIFICAÇÃO DO CASO DE USO UC0017 DEFINIR E-FORM... 7 ESPECIFICAÇÃO DO CASO DE USO UC0011 DEFINIR TIPOS DE DOCUMENTOS... 7 ESPECIFICAÇÃO DO CASO DE USO UC0034 MANIPULAR ASSINATURAS DIGITAIS DOCUMENTO.. 7 ESPECIFICAÇÃO DO CASO DE USO UC0035 VERIFICAR ASSINATURAS DO DOCUMENTO... 8 ESPECIFICAÇÃO DO CASO DE USO UC0004 MODELAR ATIVIDADES... 8 ESPECIFICAÇÃO DO CASO DE USO UC0036 MANIPULAR KEYSTORE ANÁLISE E PROJETO... 8 Estudos Preliminares...8 Protótipo...9 Esboço de Tela...10 Regras de Interface...10 Diagrama de Ação...11 Diagrama de Classe...12 Diagrama de Atividade (fluxo de trabalho do usuário) Diagrama de Seqüência...14 Atividades arquiteturais...15 Projeto de Testes...16 Script de Testes...21 Rua Expedicionário Holz, 351 América Joinville SC Brasil

134 Rua Expedicionário Holz, 351 América Joinville SC Brasil

135 1. Informações do Documento Projeto PGM SIGLA Versão 2.0 Fusion ECM Histórico de Versões 1.0 Primeira Versão. 2. Introdução Rua Expedicionário Holz, 351 América Joinville SC Brasil

136 1. Informações do Documento Projeto PGM SIGLA Versão 2.0 Fusion ECM Histórico de Versões 1.0 Primeira Versão. O documento de Especificação de Casos de Uso tem por objetivo descrever as funcionalidades do sistema a ser desenvolvido sob o ponto de vista dos usuários finais ou atores externos. O presente documento apresenta os Casos de Uso referentes a funcionalidade de assinatura digital. O objetivo desta funcionalidade é atender ao item 6.3 do edital, que comenta sobre a utilização de certificação digital nos documentos gerados pela procuradoria. Conforme edital, o padrão de certificado a ser utilizado é o AC-JUS, mas este item não impacta em nada a implementação de tecnologia que será realizada, visto que esta irá suportar qualquer certificado digital de mercado e compatível com ICP- Brasil. No contexto desta funcionalidade, um certificado digital servirá para 3 objetivos: Autenticação: Identifica o usuário no mundo digital. Neste caso, será utilizada para garantir que foi aquele usuário quem assinou aquele documento da PGM Cifragem: Proporcionar sigilo da informação. No contexto da procuradoria ou do próprio Fusion GED, será utilizado para garantir que aquela assinatura é válida, e que foi a assinatura correta que foi atribuída ao documento Assinatura Digital: Permitir assinar propriamente dito, um documento digital Alguns cuidados devem ser tomados para esta medida: Uma vez que o documento surgiu digital, ele deve permanecer assim até o final de seu ciclo de vida, sendo que qualquer impressão deste, é considerado cópia e não o original Procurar utilizar certificados do tipo A3, visto sua segurança. O próprio AC- JUS apenas regula a utilização de certificados deste tipo Todo e qualquer documento poderá sofrer assinatura digital. Sendo que as chaves públicas dos documentos poderão ser mantidas no sistema Rua Expedicionário Holz, 351 América Joinville SC Brasil

137 1. Informações do Documento Projeto PGM SIGLA Versão 2.0 Fusion ECM Histórico de Versões 1.0 Primeira Versão. 3. Definição de Atores Ator Descrição Administrador Ator responsável por informar se um campo do tipo arquivo em um GED documento pode ser assinado Usuário GED Usuário que irá assinar um documento Modelador BPM Ator responsável por informar se um campo do tipo arquivo em um f- form pode ser assinado 4. Módulos (opcional) A função Assinatura Digital, está associada ao seguinte módulo: o GED: Criação, modelagem e disponibilização de documentos o BPM: Relacionado aos arquivos dos E-forms sendo assinados Rua Expedicionário Holz, 351 América Joinville SC Brasil

138 5. Diagrama de Caso de Uso Rua Expedicionário Holz, 351 América Joinville SC Brasil

139 6. Lista dos Casos de Uso UC017 - Definir E-form - Versão 2 UC011 - Definir tipos de documentos - Versão 3 UC002 - Participar Processo - Apenas criado ponto de extensão UC034 - Manipular assinaturas digitais documento - Criação UC009 - Publicar documento - Apenas criado ponto de extensão UC035 - Verificar assinaturas do documento - Criação UC004 - Modelar Atividades - Versão 4 UC036 Manipular Keystore Criação Descrição alteração: Especificação do Caso de Uso UC0017 Definir E-form breve da Modelar um tipo de campo arquivo que demande assinatura digital. Descrição alteração: Especificação do Caso de Uso UC0011 Definir tipos de documentos breve da Idem ao Definir E-form. Descrição alteração: Especificação do Caso de Uso UC0034 Manipular Assinaturas digitais documento breve da A partir de um processo ou de uma publicação, realizar a assinatura de um documento a partir de sua chave pública ou privada. Caso seja chave pública, esta será guardada no repositório do Fusion. Rua Expedicionário Holz, 351 América Joinville SC Brasil

140 Descrição alteração: Especificação do Caso de Uso UC0035 Verificar assinaturas do documento breve da A partir da existência de um campo tipo arquivo que esteja assinado digitalmente (GED quando Workflow), conseguir visualizar quem já assinou o documento em questão Descrição alteração: Especificação do Caso de Uso UC0004 Modelar Atividades breve da Permitir que uma determinada atividade seja configurada como obrigatória a assinatura de determinados documentos no Workflow, antes da tarefa ser considerada concluída. Descrição alteração: Especificação do Caso de Uso UC0036 Manipular keystore breve da Verificar as chaves públicas existentes e seu status. 7. Análise e Projeto Estudos Preliminares Para se assinar documentos digitalmente são utilizadas técnicas de criptografia, nas quais são utilizadas uma chave privada e outra pública, sendo que a primeira é utilizada para se assinar e é de conhecimento somente do proprietário e a última para se validar a assinatura, sendo de conhecimento público. Todo esse processo envolve métodos matemáticos que garantem a segurança do processo, sendo que não está no escopo desse documento explicá-lo em mais detalhes. No caso do Fusion devem ser utilizados certificados A3, que são armazenados em um dispositivo (smart card ou token) para uma maior segurança, pois todo o processo de criptografia citado acima é realizado pelo próprio processador do dispositivo, sendo que não há como acessar a sua chave privada, evitando que ela seja copiada. Rua Expedicionário Holz, 351 América Joinville SC Brasil

141 Como forma de acesso a esses dispositivos é utilizado o protocolo PKCS#11, já implementado no JCA (Java Cryptography Architecture), componente contido na plataforma Java, conforme será demonstrado pelo protótipo abaixo. Outro fato importante é que a funcionalidade de assinatura deve ser disponibilizada de forma online, através do navegador do usuário, e isso é feito se utilizando uma applet Java. Protótipo Segue abaixo um programa exemplo de como se utilizar um dispositivo para assinar um conjunto de dados public static void main(string[] args) throws Exception { // Configuração da dll String pkcs11config = "name = SmartCard\nlibrary = c:\\windows\\system32\\aetpkss1.dll"; byte[] pkcs11configbytes = pkcs11config.getbytes(); ByteArrayInputStream configstream = new ByteArrayInputStream(pkcs11configBytes); // Registra o provider na arquitetura JCA Provider pkcs11provider = new SunPKCS11(configStream); Security.addProvider(pkcs11Provider); KeyStore smartcardkeystore = null; boolean asked = false; do { try { smartcardkeystore = KeyStore.getInstance("PKCS11"); } catch (KeyStoreException e) { // Aguarda o usuário a colocar o cartão na leitora ou conectar o token if (!asked) { System.out.println("Favor inserir o cartão na leitora"); asked = true; } Thread.sleep(500); } } while (smartcardkeystore == null); Rua Expedicionário Holz, 351 América Joinville SC Brasil

142 char[] pin = { '1', '2', '3', '4' }; smartcardkeystore.load(null, pin); Enumeration aliasesenum = smartcardkeystore.aliases(); while (aliasesenum.hasmoreelements()) { String alias = (String) aliasesenum.nextelement(); System.out.println("Alias: " + alias); X509Certificate cert = (X509Certificate) smartcardkeystore.getcertificate(alias); PrivateKey privatekey = (PrivateKey) smartcardkeystore.getkey(alias, null); String data = "Documento Teste"; byte[] signed = signdocument(data.getbytes(), privatekey); System.out.println("Signed data: " + new String(signed)); } String pkcs11providername = pkcs11provider.getname(); } Security.removeProvider(pkcs11ProviderName); private static byte[] signdocument(byte[] adocument, PrivateKey aprivatekey) throws GeneralSecurityException { Signature signaturealgorithm = Signature.getInstance("SHA1withRSA"); signaturealgorithm.initsign(aprivatekey); signaturealgorithm.update(adocument); byte[] digitalsignature = signaturealgorithm.sign(); return digitalsignature; } Como pode ser observado no código, o método signdocument é utilizado para se assinar digitalmente um conjunto de bytes, no caso de documentos deve ser passado os bytes do documento. Esboço de Tela Os esboços da interface se encontram nos casos de usos relacionados a esse documento. Regras de Interface Exibir a propriedade que especifica se um campo do tipo arquivo possui suporte a assinatura digital conforme informado abaixo no Diagrama de Ação. (A interface desse atributo é gerado automaticamente pelo Fusion) Rua Expedicionário Holz, 351 América Joinville SC Brasil

143 Alterar o componente de exibição do campo arquivo para exibir as funções de assinatura digital quando o mesmo a possuir, sendo elas: Assinar o arquivo Co-assinar o arquivo Verificar a assinatura do documento Criar a interface de gerenciamento dos certificados do usuário, com as seguintes funcionalidades: Exibir os detalhes dos certificados, tais como: tipo, entidade certificadora, etc Exibir a validade dos certificados, isto é, se ele já expirou ou não Permitir a remoção de certificados do sistema. Diagrama de Ação Incluir uma propriedade nos campos do tipo arquivo, para que se especifique se o campo pode ou não ser assinado digitalmente, sendo que haverá 3 possíveis valores: a. Não sem suporte a assinatura b. Sim com suporte a assinatura c. Obrigatório o usuário deve obrigatoriamente assinar o arquivo Alterar o componente de exibição do campo arquivo para exibir os controles de assinatura digital, conforme as regras de interface a. Para o processo de assinatura e validação, deve ser utilizada uma applet Java b. No processo de assinatura, a chave pública do usuário deve ser copiada para o servidor automaticamente para que se possa ser utilizada no processo de validação da assinatura, essa chave será armazenada nos dados do usuário, conforme detalhado no Diagrama de Classe abaixo c. Na função de validar a assinatura do documento, o Fusion irá utilizar a chave pública citada no item b para verificar a autenticidade da assinatura Rua Expedicionário Holz, 351 América Joinville SC Brasil

144 Para todo processo envolvendo o uso de um certificado, somente os válidos devem ser disponibilizados para seleção, isto é, o sistema não deve permitir que o usuário escolha um certificado já expirado. Criar as funcionalidades de gerenciamento de certificados, conforme detalhado na regra de interface e caso de uso. a. Por questões técnicas, um certificado já utilizado para assinar um documento não pode ser removido do sistema, pois a sua chave pública deve permanecer salva para validação da assinatura. Diagrama de Classe Conforme o diagrama acima, as alterações para a implementação da funcionalidade de assinatura digital são: Criação das classes responsáveis por armazenar os dados dos certificados do usuário: a. Certificate: contém as informações do certificado, bem como a sua chave pública b. PublicKey: dados da chave pública do certificado Criação de um campo do tipo lista no usuário (NeoUser) para armazenar os seus certificados digitais Rua Expedicionário Holz, 351 América Joinville SC Brasil

145 Criação da classe Signature para armazenar as informações da assinatura digital de um arquivo Inclusão de um campo do tipo lista no arquivo (NeoFile) que referencia as assinaturas presentes naquele arquivo Diagrama de Atividade (fluxo de trabalho do usuário) Assinar Documento O fluxo de execução pelo usuário pode ser observado no diagrama abaixo: Rua Expedicionário Holz, 351 América Joinville SC Brasil

146 Diagrama de Seqüência O diagrama de sequência da assinatura do arquivo se encontra abaixo: Rua Expedicionário Holz, 351 América Joinville SC Brasil

147 Atividades arquiteturais Não há necessidade de realizaçao de atividades arquiteturais pois é utilizada a arquitetura de documentos e arquivos já existente no Fusion. Rua Expedicionário Holz, 351 América Joinville SC Brasil

148 Projeto de Testes Rua Expedicionário Holz, 351 América Joinville SC Brasil

149 Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Cenário 1 : Assinar um arquivo Configurar um campo arquivo para suportar assinaura digital e com um usuário GED assinar um arquivo O documento deve ser assinado corretamente Ambiente Fusion com no mínimo um usuário GED cadastrado Dispositivo com um certificado A3 válido Arquivo / Certificado Manual Rua Expedicionário Holz, 351 América Joinville SC Brasil

150 Requisitos validados UC 2, 9, 4, 11, 17, 34 Rua Expedicionário Holz, 351 América Joinville SC Brasil

151 Rua Expedicionário Holz, 351 América Joinville SC Brasil

152 Cenário 2 : Co-assinar um arquivo Descrição Com um usuário GED co-assinar um arquivo Resultados Esperados O documento deve gerar outra assinatura para o arquivo sem interferir ná já existente Conf. Inicial do ambiente Ambiente Fusion com no mínimo um usuário GED cadastrado Dispositivo com um certificado A3 válido Documento já assinado conforme cenário 1 Entradas Arquivo assinado digitalmene (cenário 1) Automático / Manual Manual Rua Expedicionário Holz, 351 América Joinville SC Brasil

153 Requisitos validados UC 34 Cenário 3 : Validar a assinatura Descrição Com um usuário GED verificar a assinatura de um arquivo Resultados Esperados Informar os dados da assinatura digital de um arquivo Conf. Inicial do ambiente Ambiente Fusion com no mínimo um usuário GED cadastrado Entradas Arquivo assinado digitalmene (cenário 1 e 2) Automático / Manual Manual Requisitos validados UC 35 Cenário 4 : Remover um certificado Descrição Remover um certificado do sistema através da interface de gerenciamento de certificados digitais (Gerenciamento de Keystore) Resultados Esperados O certificado deve ser removido do sistema Conf. Inicial do ambiente Ambiente Fusion com no mínimo um usuário adminitrador cadastrado Entradas Automático / Manual Manual Requisitos validados UC 36 Script de Testes PT* Categoria** Tipo de Teste *** Cenário **** Roteiro 1 Sistema Funcional 1 3 * PT = Procedimento de Teste ** Categoria = Unidade; Integração ou Sistema *** Tipo de Teste = Estrutural; Funcional; Interface ou Configuração **** Cenário: Informar o número do cenário descrito no projeto de teste relacionado. Rua Expedicionário Holz, 351 América Joinville SC Brasil

154 APÊNDICE C 120

155 PGM Fusion 2.0 Sumário 1.INFORMAÇÕES DO DOCUMENTO... 2 HISTÓRICO DE VERSÕES INTRODUÇÃO DEFINIÇÃO DE ATORES MÓDULOS (OPCIONAL) DIAGRAMA DE CASO DE USO LISTA DOS CASOS DE USO... 4 ESPECIFICAÇÃO DO CASO DE USO UC0001 MODELAR PROCESSO... 4 ESPECIFICAÇÃO DO CASO DE USO UC0002 PARTICIPAR PROCESSO... 4 ESPECIFICAÇÃO DO CASO DE USO UC0003 VISUALIZAR DOCUMENTO ANEXO PRINCIPAL ANÁLISE E PROJETO... 5 ESBOÇO DE TELA... 5 REGRAS DE INTERFACE... 9 DIAGRAMA DE AÇÃO DIAGRAMA DE CLASSE DIAGRAMA DE ATIVIDADE DIAGRAMA DE SEQÜÊNCIA DIAGRAMA DE COMPONENTES ESTUDOS PRELIMINARES PROTÓTIPO ATIVIDADES ARQUITETURAIS DICIONÁRIO ESTIMATIVA DE ESFORÇO PROJETO DE TESTES Rua Expedicionário Holz, 351 América Joinville SC Brasil

156 1. Informações do Documento Projeto PGM SIGLA Versão 2.0 Fusion ECM Histórico de Versões 1.0 Primeira Versão. 2. Introdução O documento de Especificação de Casos de Uso tem por objetivo descrever as funcionalidades do sistema a ser desenvolvido sob o ponto de vista dos usuários finais ou atores externos. O presente documento apresenta os Casos de Uso referentes a funcionalidade Conceito de anexo principal e os modelos de visualização destes documentos do processo, e quais são suas relações e regras de negócio envolvidas. O principal foco desta funcionalidade é prover a possibilidade ao usuário do Fusion ECM, de no momento dele abrir uma solicitação ou participar de uma solicitação, o documento anexo principal já seja devidamente aberto para navegação por parte do usuário. Ao realizar uma analogia com a aplicação desta funcionalidade para a realidade da PGM-Rio, vê-se que é primordial, no momento da execução de uma determinada tarefa no dia-a-dia da procuradoria, a existência do documento de processo judicial, para que os usuários possam realizar atividades sobre este documento, realizar tramitações, consultas etc. Neste caso, utilizando o conceito de anexo principal na PGM, o documento de processo judicial será considerado como o principal, e no momento da abertura da atividade pelo sistema Fusion ECM, este documento de processo judicial será devidamente aberto com destaque na interface, possibilitando fácil acesso ao objeto daquele processo. 3. Definição de Atores Ator Modelador BPM Usuário BPM Usuário GED Descrição Ator responsável por realizar, na configuração do processo de negócio no Fusion ECM, as atribuições de que documento será considerado o anexo principal daquele processo. Ator com capacidade para utilizar e participar dos processos definidos no Fusion ECM Ator com capacidade para utilizar as funções do módulo de gerenciamento eletrônico de documentos. Ex: Publicar documentos, navegar pelas pastas e pelos tipos de documentos Rua Expedicionário Holz, 351 América Joinville SC Brasil

157 Observações: O nome processo no contexto deste documento está relacionado com o Fusion ECM, e não com o processo judicial na PGM. O processo judicial, neste caso, pode ser considerado o documento anexo principal do processo, que seguirá durante toda a execução das atividades que o compõem. 4. Módulos (opcional) A função Conceito anexo principal, está basicamente associado aos seguintes módulos: 01 BPM: Para modelagem e definição anexo principal 02 GED: Publicação dos documentos gerados nos processos. 5. Diagrama de Caso de Uso Rua Expedicionário Holz, 351 América Joinville SC Brasil

158 6. Lista dos Casos de Uso UC Modelar Processo UC Participar Processo UC Visualizar documento anexo principal Especificação do Caso de Uso UC0001 Modelar Processo Descrição impacto: Criação da configuração do anexo principal Especificação do Caso de Uso UC0002 Participar Processo Descrição Impacto: Visualização do documento anexo principal no processo. Especificação do Caso de Uso UC0003 Visualizar Documento anexo Principal Descrição impacto: Realizar a visualização do anexo principal do processo, quando este estiver configurado. Rua Expedicionário Holz, 351 América Joinville SC Brasil

159 7. Análise e Projeto Esboço de Tela Regra de Interface 1 (RI001): Novo campo Anexo principal. Tela de manutenção do workflow. Rua Expedicionário Holz, 351 América Joinville SC Brasil

160 Regra de Interface 3 (RI003): Barra de ferramentas e navegação no anexo principal. Regra de Interface 2 (RI002): Novo botão do Anexo Principal. Regra de Interface 4 (RI004): Visualização do anexo principal no modo Miniaturas. Tela de visualização do anexo principal da tarefa no modo Miniaturas. Rua Expedicionário Holz, 351 América Joinville SC Brasil

161 Regra de Interface 5 (RI005): Visualização do anexo principal no modo Livro. Tela de visualização do anexo principal da tarefa no modo Livro. Rua Expedicionário Holz, 351 América Joinville SC Brasil

162 Regra de Interface 6 (RI006): Histórico das impressões em PDF (não controladas). Tela da impressão para PDF mostrando um histórico das cópias não controladas. Rua Expedicionário Holz, 351 América Joinville SC Brasil

163 Regra de Interface 7 (RI007): Hits do anexo principal. Regras de Interface Tela de visualização dos hits do anexo principal. [RI001] Tela de manutenção do workflow: o Inserir um novo campo chamado Anexo Principal. o Neste campo poderão ser selecionados apenas os campos do E-form do workflow do tipo arquivo físico. [RI002] Tela de visualização do Anexo Principal da tarefa: o Incluir na barra de ferramentas principal da tela da tarefa do usuário um botão: Título: Anexo Principal Ícone: annex_main_16x16-trans.png Quando aparecer: Quando o workflow tiver anexo principal configurado. Ação: Deve mostrar uma barra de ferramentas na parte superior e a visualização do documento anexo principal no centro da tela. [RI003] Barra de ferramentas e navegação no anexo principal: o Validar se o anexo principal está no formato Microsoft Word (Office 97 a Office XP) ou PDF. Se não estiver nesse formato abrir o documento apenas para visualização normal. Se o formato do documento for algum dos citados acima, criar uma barra de ferramentas na tela do anexo principal com quatro botões: Título: Livro Ícone: view_book_16x16-trans.png Rua Expedicionário Holz, 351 América Joinville SC Brasil

164 Quando mostrar: Quando o documento anexo principal do workflow estiver no formato Microsoft Word (Office 97 a Office XP) ou PDF. Ação: Deve mostrar a visualização no anexo principal em forma de livro. Título: Miniaturas Ícone: view_miniatures_16x16-trans.png Quando mostrar: Quando mostrar: Quando o documento anexo principal do workflow estiver no formato Microsoft Word (Office 97 a Office XP) ou PDF. Ação: Deve mostrar a visualização no anexo principal em forma de miniaturas. Título: Imprimir em PDF Ícone: document_pdf_16x16-trans.png Quando mostrar: Quando o usuário que estiver vendo o documento tiver permissão de impressão naquele documento. Ação: Faz a exportação dos dados do eform do workflow e do anexo principal para o formato PDF, abre este PDF gerado em outra janela do navegador e criar um registro da exportação dos dados (este registro não é uma cópia controlada). o o Título: Hits Ícone: Quando mostrar: Quando o usuário do sistema for gestor do workflow ou responsável pelo processo. Ação: Mostrar uma tela com o histórico de hits do anexo principal. Na parte inferior da tela deve ser mostrado um painel de navegação do anexo principal, onde: Botão Anterior mostra a página anterior Mostra a página atual do anexo e o número total de páginas, separados por uma barra / Botão Próxima mostra a página posterior. Por padrão o anexo principal deve ser aberto no modo miniaturas. [RI004] Visualização do anexo principal no modo Miniaturas: o A página do anexo principal que o usuário está lendo deve ser mostrada no meio da tela em um tamanho maior. o Nesta página poderá ser feito zoom para ver possíveis detalhes. o As três páginas anteriores e três posteriores, a página que o usuário está lendo, devem ser mostradas em miniatura. [RI005] Visualização do anexo principal no modo Livro: o No centro da tela devem ser mostradas duas páginas do documento. o Quando o usuário vira a página para frente ou para trás, mostrar as duas páginas seguintes ou anteriores, respectivamente. o Nestas páginas poderão ser feitos zooms para ver possíveis detalhes. Rua Expedicionário Holz, 351 América Joinville SC Brasil

165 [RI006] Visualização do histórico das impressões em PDF (não controladas): o Exibe a lista das cópias não controladas impressas do anexo principal. Os campos a exibir são os seguintes: Usuário: Nome do usuário que imprimiu o anexo principal. Data: Data da impressão. [RI007] Visualização dos Hits do anexo principal: o Mostrar a lista dos hits com os seguintes campos: Nome: Nome do usuário que viu o anexo principal. Página: Página visualizada pelo usuário. Hits: Quantas vezes a página foi vista pelo usuário. Data: Data da visualização. Hora: Hora da visualização. Diagrama de Ação Páginas de um Processo podem ser retiradas a qualquer momento mas apenas pela pessoa que as inseriu. Caso as últimas páginas sejam retiradas, não é necessário Despacho para registrar a ação mas é obrigatório que o usuário, data e informações retiradas fiquem registrados (isto é coberto pela Auditoria do PA Virtual). Para retirar páginas anteriores as últimas, será obrigatório um Despacho para registrar o que foi feito. Deve ser apresentado ao usuário que retirou as páginas quais foram os outros usuários que visualizaram ou imprimiram o processo antes da alteração para que os mesmos possam ser avisados. Será possível utilizar o botão direito para executar sub processos? Exemplo: despacho, tramitar. Sub-ordenação de tabela: exemplo: data e assunto. Somente se a última folha for 1 despacho, então adicionar na mesma página o mesmo despacho. Pode haver mais de 1 despacho por página, e será necessário gerenciar paginação. Qualquer informação que altere o Processo Digital (despachos, inserir peças dos autos, novas peças) deverão exigir Assinatura Digital. Prever o carimbo de autuação. com.neomind.fusion.engine.fusionsettings o Alterar classe conforme diagrama de classes. com.neomind.fusion.image.cache.processimagecache o Criar classe conforme diagrama de classes. o Singleton com um HashMap com o caminho das imagens em cache. com.neomind.fusion.image.converterfactory o Criar classe conforme diagrama de classes. Rua Expedicionário Holz, 351 América Joinville SC Brasil

166 o Instancia algum objeto que implementa a interface ConverterInterface e retorna para o ProcessImageConverter que chama o método que faz a conversão. com.neomind.fusion.image.converterinterface o Criar classe conforme diagrama de classes. o Interface padrão para conversão de documentos em imagens no formato PNG (que é o formato que serão mostradas as páginas do modo Livro e Miniaturas do anexo principal). com.neomind.fusion.image.pdfconverter o Criar classe conforme diagrama de classes. o Converte todas as páginas de um documento PDF para imagens PNG utilizando o GhostScript. com.neomind.fusion.image.officeconverter o Criar classe conforme diagrama de classes. o Deve imprimir o documento através de JDIC para PostScript (utilizar impressora da Adobe). Após este procedimento utilizar o GhostScript para transformar do formato PS gerado para imagens PNG. com.neomind.fusion.image.openofficeconverter o Criar classe conforme diagrama de classes. o Deve imprimir o documento através de JDIC para PostScript (utilizar impressora da Adobe). Após este procedimento utilizar o GhostScript para transformar do formato PS gerado para imagens PNG. com.neomind.fusion.image.imageconverver o Criar classe conforme diagrama de classes. o Converte a imagem para PNG utilizando o GhostScript. com.neomind.fusion.image.htmlconverter o Criar classe conforme diagrama de classes. o Converte o HTML para PNG utilizando o GhostScript. GhostScript o Criar classe conforme diagrama de classes. o Esta classe fará a interface entre o Fusion e o GhostScript. o O GhostScript é um programa que converte arquivos de alguns formatos (PS, HTML, Tiff e JPG) para PNG (formato que será utilizado nas páginas do anexo principal). com.neomind.fusion.image.imageengine o Criar classe conforme diagrama de classes. Rua Expedicionário Holz, 351 América Joinville SC Brasil

167 o Valida se a imagem da página do documento anexo principal está em cache, se estiver retorna esta imagem para o ImageServlet; se não, gera através do conversor a imagem daquela página. com.neomind.fusion.image.imageservlet o Criar classe conforme diagrama de classes. o Esta classe será responsável por gerar a url da imagem da página do anexo principal. Sendo assim ela delegará para o ImageEngine a função de buscar a imagem da página do anexo principal. com.neomind.fusion.image.processimageconverter o Criar classe conforme diagrama de classes. o Responsável por converter as páginas do anexo principal em imagens, quando estas não estiverem no cache. com.neomind.fusion.workflow.relationableprocessmodel o Alterar classe conforme diagrama de classes. com.neomind.fusion.workflow.mainattachdataexportlog o Criar classe conforme diagrama de classes. com.neomind.fusion.workflow.mainattachhits o Criar classe conforme diagrama de classes. com.neomind.fusion.workflow.processstructure o Criar classe conforme diagrama de classes. o O método getmainattachstructure deverá gerar um XML com a estrutura do documento Anexo Principal do processo e retornar para o componente Flex. Este XML deve seguir o padrão abaixo: <?xml version="1.0" encoding="iso "?> <MainAttachment> <Structure name="mandado de Citação"> <Document type="xxxxx" name="mandado de citação" initialpage="1" endpage="3" contenturl="http://localhost:8080/fusion/imgservlet?wfprocess=12312&page=x" /> </Structure> <Structure name="folder"> <Document type="xxxxx" name="mandado de citação" initialpage="4" endpage="10" contenturl="http://localhost:8080/fusion/imgservlet?wfprocess=12312&page=x" /> <Document type="xxxxx" name="mandado de citação" initialpage="11" endpage="15" contenturl="http://localhost:8080/fusion/imgservlet?wfprocess=12312&page=x" /> <Document type="xxxxx" name="mandado de citação" initialpage="16" endpage="20" contenturl="http://localhost:8080/fusion/imgservlet?wfprocess=12312&page=x" /> </Structure> <Structure name="folder"> <Document type="xxxxx" name="mandado de citação" /> </Structure> <Structure name="folder"> <Document type="xxxxx" name="mandado de citação" /> </Structure> </MainAttachment> Rua Expedicionário Holz, 351 América Joinville SC Brasil

168 com.neomind.util.psutils o Criar classe conforme diagrama de classes. o Esta classe através do JDIC (JDesktop Integration Components) imprime o documento (Office ou OpenOffice) em uma impressora PostScript no servidor que aponta para uma porta TCP. Nesta porta TCP haverá um serviço que ficará esperando terminar a impressão e então, através do GhostScript, criará uma imagem PNG a partir do arquivo PostScript gerado. task.jsp o Validar se o ProcessModel da Task tem algum anexo principal configurado. Se tiver, incluir o botão de anexo principal no buttonlist. o Quando clicado neste botão chamar o portlet MainAttach. bpm/mainattach.jsp o Criar novo JSP que irá mostrar o anexo principal do workflow. o Este deverá ter uma barra de ferramentas (utilizar o exemplo do task.jsp) com os seguintes botões (estes detalhados nas Regras de Interface): Livro e Miniaturas: Carregar o portlet MainAttachViewer. Imprimir em PDF: Carregar o portlet MainAttachPrintToPdf. Hits: Carregar o portlet MainAttachHits. /bpm/mainattachviewer.jsp o Criar novo JSP que irá mostrar o componente flex no modo escolhido pelo usuário para visualizar anexo principal do workflow. o O modo escolhido deverá ser passado por parâmetro para o componente flex. /bpm/mainattachprinttopdf.jsp o Listar os objetos da classe MainAttachDataExportLog (que são os registros de histórico das cópias não controladas). Utilizar como exemplo relatedprocess.jsp. /bpm/mainattachhits.jsp o Listar os objetos da classe MainAttachHits (que são os registros dos hits de cada página do anexo principal). Utilizar como exemplo relatedprocess.jsp. portlet.xml o Mapear o novo portlet a seguir: <portlet> <portlet-name>mainattach</portlet-name> <display-name></display-name> <portlet-class>com.neomind.fusion.portal.portlets.jspportlet</portlet-class> <init-param> <name>view-page</name> <value>/bpm/mainattach.jsp</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> </supports> <resource-bundle></resource-bundle> <security-role-ref> <role-name>user</role-name> Rua Expedicionário Holz, 351 América Joinville SC Brasil

169 </security-role-ref> </portlet> <portlet> <portlet-name>mainattachviewer</portlet-name> <display-name></display-name> <portlet-class>com.neomind.fusion.portal.portlets.jspportlet</portlet-class> <init-param> <name>view-page</name> <value>/bpm/mainattachviewer.jsp</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> </supports> <resource-bundle></resource-bundle> <security-role-ref> <role-name>user</role-name> </security-role-ref> </portlet> <portlet> <portlet-name>mainattachprinttopdf</portlet-name> <display-name></display-name> <portlet-class>com.neomind.fusion.portal.portlets.jspportlet</portlet-class> <init-param> <name>view-page</name> <value>/bpm/mainattachprinttopdf.jsp</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> </supports> <resource-bundle></resource-bundle> <security-role-ref> <role-name>user</role-name> </security-role-ref> </portlet> <portlet> <portlet-name>mainattachhits</portlet-name> <display-name></display-name> <portlet-class>com.neomind.fusion.portal.portlets.jspportlet</portlet-class> <init-param> <name>view-page</name> <value>/bpm/mainattachhits.jsp</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> </supports> <resource-bundle></resource-bundle> <security-role-ref> <role-name>user</role-name> </security-role-ref> </portlet> Objetos Flex: o com.neomind.fusion.viewer.canvas Classe do Flex que é um container (agrupa objetos dentro dela). o o com.neomind.fusion.viewer.flexviewer Criar classe flex conforme diagrama de classes. Esta classe mostra a classe ZoomPage para cada página do anexo principal. com.neomind.fusion.zoom.imagezoom Criar classe flex conforme diagrama de classes. Rua Expedicionário Holz, 351 América Joinville SC Brasil

170 Esta classe aumenta/diminui a página que está sendo lida conforme comando e necessidade do usuário. o com.neomind.fusion.zoom.zoompage Criar classe flex conforme diagrama de classes. Esta classe é filha da classe canvas, e dentro dela estará a classe ImageZoom que justamente faz o zoom na página corrente do anexo principal, esta será a opção quando o usuário não conseguir lê-la diretamente na tela. Diagrama de Classe Rua Expedicionário Holz, 351 América Joinville SC Brasil

171 Rua Expedicionário Holz, 351 América Joinville SC Brasil

172 Diagrama de Atividade Diagrama de Seqüência Visualizar Anexo Principal Carrega o Anexo Principal do Processo Rua Expedicionário Holz, 351 América Joinville SC Brasil

173 Busca imagem do cache Salvando hits das páginas do Anexo Principal Rua Expedicionário Holz, 351 América Joinville SC Brasil

174 Salvando histórico de exportação dos dados do processo Rua Expedicionário Holz, 351 América Joinville SC Brasil

175 Diagrama de Componentes Estudos Preliminares Para esta funcionalidade foi necessário validar vários componentes, pois era necessário fazer com que o Fusion: Mostrasse o Anexo Principal nos formatos Livro e Miniaturas. Gerasse imagens separadas para cada folha do Anexo Principal. Sendo assim, foram definidos os seguintes componentes: Flex Solução RIA (Rich Internet Application) para Web. Utilizado para mostrar o anexo principal nos formatos livro e miniaturas (http://www.adobe.com/br/products/flex/). JDIC JDesktop Integration Components. Utilizado para imprimir documentos Office e OpenOffice no formato PostScript. GhostScript Utilizado para converter documentos HTML, imagens JPEG e Tiff, e arquivos PostScript para imagens PNG (http://pages.cs.wisc.edu/~ghost/). Protótipo Componente de visualização do anexo principal (FlexViewer): <?xml version="1.0" encoding="utf-8"?> <mx:application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns="http://www.adobe.com/2006/mxml" xmlns:cynergy="com.cynergysystems.*" xmlns:controls="qs.controls.*" xmlns:containers="qs.containers.*" layout="absolute"> <mx:script> <![CDATA[ import mx.controls.alert; private function next():void { if(book.currentpageindex+2 < book.pagecount) book.turntopage(book.currentpageindex + 2); } private function previous():void { if(book.currentpageindex > 1) book.turntopage(book.currentpageindex - 2); } private function inittimer():void Rua Expedicionário Holz, 351 América Joinville SC Brasil

176 { } target) public function focuson(target:*):void { if(landscape.selection.length == 1 && landscape.selection[0] == } else landscape.selection = []; landscape.selection = [target]; // Código do controle TreeView [Bindable] private var dp:array = [1, 2, 3, 4, 5, 6, 7, 8]; [Bindable] public var selectednode:xml; // Event handler for the Tree control change event. public function treechanged(event:event):void { selectednode=tree(event.target).selecteditem as XML; } // Realizar o load dinamico das informações a serem geradas para o FlexBook ou qualquer outro componente public function loadbookcontrol():void { var urlstr:string; var content:array = book.content; for(var i:uint; i < dp.length; i++) { urlstr = "assets/pgm/ x846." + String(i) + ".png"; if (i == 0) { var cover:zoompage = new ZoomPage(); cover.imagem = urlstr; book.cover = cover; continue; } } var zn:zoompage = new ZoomPage(); zn.imagem = urlstr; content.push(zn); } book.content = content; // book.initialize(); // book.turntopage(book.contenttopageindex(content.length-1)); book.turntopage(0); ]]> </mx:script> <XMLList id="treedata"> <node label="processojudicial"> <node label="001 - Mandado de Citação (fl02)"> <node label="mandado1"/> <node label="mandado2"/> <node label="mandado3"/> </node> <node label="002 - Petição Inicial"> <node label="professional"/> <node label="personal"/> </node> <node label="003 - Ofício"/> Rua Expedicionário Holz, 351 América Joinville SC Brasil

177 <node label="004 - Documentos de Instrução"/> </node> </XMLList> <HDividedBox width="100%" height="100%" bordercolor="#e0e0e0" backgroundcolor="#c0c0c0"> <Panel width="20%" height="100%" title="processo" borderstyle="none" color="#000000"> <Tree id="mytree" width="100%" height="100%" backgroundcolor="#ffffff" showroot="false" dataprovider="{treedata}" change="treechanged(event)" backgroundalpha="0.45" color="#400000" fontsize="12"/> </Panel> <Panel width="80%" height="100%" layout="absolute" title="pgm - PAVirtual" backgroundcolor="#ffffff" themecolor="#c0c0c0" borderstyle="none" color="#000000"> <Button label="anterior" click="previous()" fillcolors="[#c0c0c0, #b4b4b4]" fillalphas="[1.0, 1.0]" color="#ffffff" fontweight="bold" fontsize="14" horizontalcenter="-130" bottom="1"/> <Button label="posterior" click="next()" fillcolors="[#d2d2d2, #c0c0c0]" fillalphas="[1.0, 1.0]" color="#ffffff" fontweight="bold" fontsize="14" horizontalcenter="130" bottom="1"/> <Label text="páginas" bottom="15" horizontalcenter="0" /> <HSlider id="pagina" bottom="0" horizontalcenter="0" width="144"/> <!-- <VSlider id="zoom" minimum=".01" maximum="5" value="1" change="{far.imagezoom.zoom( zoom.value )}" right="3" top="3" /> --> <containers:landscape width="100%" height="95%" paddingleft="30" paddingtop="30" paddingbottom="30" paddingright="30" id="landscape" zoomlimit="none" clipcontent="false" cachepolicy="off" top="0" right="0" x="0" y="56"> <!-- top="30" bottom="50" --> <Canvas width="100%" height="100%" borderstyle="solid" borderthickness="1" bordercolor="#000000" themecolor="#c0c0c0" backgroundcolor="#e1e1e1"> <!-- Permite que apenas as bordas sejam usadas para paginação activegrabarea="corner" --> <controls:flexbook id="book" width="100%" top="0" height="100%" animatecurrentpageindex="true" showcornertease="true" activegrabarea="corners" edgeandcornersize="50" itemsize="halfpage" transparencydepth="50" creationcomplete="loadbookcontrol()" borderstyle="solid" bordercolor="#000000" right="0" shadowdirection="left" borderthickness="1" cornerradius="1"> </controls:flexbook> </Canvas> </containers:landscape> </Panel> </HDividedBox> </mx:application> Componente ZoomPage: <?xml version="1.0"?> <!-- Simple example to demonstrate the List Control --> <mx:canvas xmlns:mx="http://www.adobe.com/2006/mxml" xmlns="http://www.adobe.com/2006/mxml" xmlns:cynergy="com.cynergysystems.*" Rua Expedicionário Holz, 351 América Joinville SC Brasil

178 xmlns:controls="com.qs.controls.*" creationcomplete="assignid()" width="100%" height="100%"> <mx:script> <![CDATA[ import mx.controls.alert; import mx.controls.alert; import com.cynergysystems.imagezoom; [Bindable] public var selecteditem:object; } ]]> </mx:script> [Bindable] public var imagem:string = new String(""); [Bindable] public var zoomid:string = new String(""); [Bindable] public var imagezoom:imagezoom; private function assignid() :void { imagezoom = initial; initial.id = zoomid; <!-- <mx:panel width="100%" height="100%" layout="absolute" left="0" top="0" id="panel"> --> <cynergy:imagezoom id="initial" includeinlayout="true" left="0" letterspacing="0" source="{ imagem }" bottom="0" top="0" right="0" autolayout="true" fadeduration="1000" zoomincrement="0.09" /> <!-- zoomincrement="{ options.zoomincrement }" imagedoubleclickenabled="{ options.imagedoubleclickenabled }" mousewheelenabled="{ options.mousewheelenabled }" mousefollow="{ options.mousefollowenabled }" --> <!-- </mx:panel> --> <!-- <mx:panel id="far" right="5" width="388"> <VSlider id="zoom" minimum=".1" maximum="5" value="1" change="zoomcomponent.zoom( zoom.value )" right="3" top="3" /> <cynergy:optionspanel id="options" width="360" height="10%"/> <ControlBar verticalalign="middle" paddingtop="0" paddingbottom="0"> </ControlBar> </mx:panel>--> </mx:canvas> Atividades arquiteturais Esta funcionalidade terá várias integrações com componentes externos. Um esboço das atribuições de cada componente pode ser vista no diagrama de atividades. Segue uma descrição dos componentes e suas atribuições: FlexViewer: Solicita ao Fusion a estrutura de pastas do Anexo Principal. O Fusion retorna um XML com estas informações. Então, o FlexViewer a partir deste XML gera uma árvore com as pastas e documentos do Anexo Principal. Rua Expedicionário Holz, 351 América Joinville SC Brasil

179 JDIC: Imprime um documento em alguma impressora do sistema. Será utilizada para imprimir um documento Office ou OpenOffice no formato PostScript. Para isto será necessário: o Instalar o Adobe PostScript na máquina. o Configurar a impressora PostScript para imprimir para a porta TCP informada no Fusion. GhostScript: Conversor de documentos para imagens. o Configurar um serviço na máquina que fica ouvindo a porta TCP configurada na impressora PostScript. o Quando o documento terminar de ser impresso, deve chamar o GhostScript através de uma linha de comando passando o arquivo PostScript, e este gerará a imagem do documento. o Para documentos que não precisam estar no formato PostScript somente o segundo passo será executado, neste caso passando o nome arquivo do documento como parâmetro. Dicionário As alterações de dicionário estão representadas no diagrama de classes, onde as classes do estereótipo entity são entidades (tabelas) do Fusion e os atributos são os campos que foram criados ou alterados. Sendo assim, não é necessário a criação de scripts de atualização, pois o Hibernate altera o banco conforme as alterações nas classes. Estimativa de Esforço # Objeto Constr Teste 1 com.neomind.fusion.engine.fusionsettings 1,5 3 2 com.neomind.fusion.image.cache.processimagecache com.neomind.fusion.image.converterfactory com.neomind.fusion.image.converterinterface com.neomind.fusion.image.pdfconverter 2,5 1 6 com.neomind.fusion.image.officeconverter 2,5 1 7 com.neomind.fusion.image.openofficeconverter 2,5 1 8 com.neomind.fusion.image.imageconverver 2,5 1 9 com.neomind.fusion.image.htmlconverter 2, GhostScript com.neomind.fusion.image.imageengine com.neomind.fusion.image.imageservlet com.neomind.fusion.image.processimageconverter com.neomind.fusion.workflow.relationableprocessmodel 1,5 15 com.neomind.fusion.workflow.mainattachdataexportlog 2 16 com.neomind.fusion.workflow.mainattachhits com.neomind.fusion.workflow.processstructure com.neomind.util.psutils task.jsp bpm/mainattach.jsp /bpm/mainattachviewer.jsp 3 3 Rua Expedicionário Holz, 351 América Joinville SC Brasil

180 22 /bpm/mainattachprinttopdf.jsp /bpm/mainattachhits.jsp 3 24 portlet.xml com.neomind.fusion.viewer.canvas com.neomind.fusion.viewer.flexviewer com.neomind.fusion.zoom.imagezoom com.neomind.fusion.zoom.zoompage 5,5 3 TOTAL Projeto de Testes Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Requisitos validados Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Requisitos validados Cenário 1: Visualizar Anexo Principal: Modo Livro Visualizar o Anexo Principal do processo no modo livro. O documento anexo principal do processo seja mostrado na tela no formato livro e que o usuário possa visualizar suas página anteriores e posteriores. Ter uma solicitação com documento anexo principal configurado e este com algumas páginas. Selecionar a tarefa e clicar no botão Anexo Principal e depois no botão Livro. Manual Caso de Uso 3 Visualizar Documento Anexo Principal Cenário 2: Visualizar Anexo Principal: Modo Miniaturas Visualizar o Anexo Principal do processo no modo miniaturas. O documento anexo principal do processo seja mostrado na tela no formato miniaturas e que o usuário possa visualizar suas página anteriores e posteriores. Ter uma solicitação com documento anexo principal configurado e este com algumas páginas. Selecionar a tarefa e clicar no botão Anexo Principal e depois no botão Miniaturas. Manual Caso de Uso 3 Visualizar Documento Anexo Principal Rua Expedicionário Holz, 351 América Joinville SC Brasil

181 Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Requisitos validados Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Requisitos validados Cenário 3: Visualizar Hits do Anexo Principal Visualizar os hits do documento anexo principal do processo. Uma lista com os hits (visualizações) de cada página do documento anexo principal, a data, hora e usuário. Ter uma solicitação com documento anexo principal configurado e este com algumas páginas que já tenham sido visualizadas por um ou vários usuários. Selecionar a tarefa e clicar no botão Anexo Principal e depois no botão Hits. Manual Caso de Uso 3 Visualizar Documento Anexo Principal Cenário 4: Exportar dados do Processo Exportar o documento anexo principal e os dados do processo (e-form do workflow do processo judiciário) para um arquivo PDF. Arquivo PDF com conteúdo do documento anexo principal e os dados do processo. Ter uma solicitação com documento anexo principal configurado e este com algumas páginas. Selecionar a tarefa e clicar no botão Anexo Principal e depois no botão Imprimir em PDF. Manual Caso de Uso 3 Visualizar Documento Anexo Principal Rua Expedicionário Holz, 351 América Joinville SC Brasil

182 Descrição Resultados Esperados Conf. Inicial do ambiente Entradas Automático / Manual Requisitos validados Cenário 5: Virar página do Anexo Principal Ir para a página anterior/posterior do anexo principal. Mostrar a página anterior/posterior e gravar hit desta visualização. Ter uma solicitação com documento anexo principal configurado e este com algumas páginas. Selecionar a tarefa e clicar no botão Anexo Principal, depois no botão Miniaturas ou Livro e então nos botões Anterior ou Próxima. Manual Caso de Uso 3 Visualizar Documento Anexo Principal PT* Categoria** Tipo de Teste *** Cenário **** Roteiro 1 Integração Interface 1,2,5 2 Sistema Funcional 3,4 * PT = Procedimento de Teste ** Categoria = Unidade; Integração ou Sistema *** Tipo de Teste = Estrutural; Funcional; Interface ou Configuração **** Cenário: Informar o número do cenário descrito no projeto de teste relacionado. Rua Expedicionário Holz, 351 América Joinville SC Brasil

183 APÊNDICE D 121

184 Sumário HISTÓRICO DE VERSÕES... 2 ESPECIFICAÇÃO DO CASO DE USO UC0012 IMPRIMIR CÓPIA CONTROLADA ESBOÇO DE TELA... 4 Rua Expedicionário Holz, 351 América Joinville SC Brasil

185 Histórico de Versões 1.0 Primeira Versão. Cópia controlada, histórico de impressões e impressão de documentos a partir do Fusion Especificação do Caso de Uso UC0012 Imprimir cópia controlada Criado por: Farley Data de Criação: 27/06/2007 Última Atualização: 11/07/2007 Data da Atualização: Criação Atores: Descrição: Pré-condições: Pós-condições: Usuário GED Realizar a impressão de cópias controladas e a visualização do histórico de cópias emitidas N/A N/A Ações do Ator Passo 1.No menu principal DOCUMENTOS, o usuário seleciona a opção Documentos. Neste menu ainda consta Gestão de Documentos e Documentos em Edição Passo 3.Usuário seleciona uma pasta ou tipo de documento Passo 5.Usuário seleciona a opção de impressão de cópias controladas Passo 7.Usuário seleciona a opção de inclusão (novo) Fluxo Básico de Eventos Ações do Sistema Passo 2.Sistema abre as opções de navegação por pasta e por tipo de documento Passo 4.Sistema apresenta a lista de documentos relacionados Passo 6.Sistema exibe o histórico das cópias já impressas e opções para manipulação (Apenas inclusão e visualização) Passo 8.Sistema apresenta as opções para impressão: - Documentos com permissão de impressão para seleção e opções para faixa de páginas por documento - Destinatários: Usuários/Papéis ou ainda pessoas externas para quem a cópia está sendo impressa - Informações de data/hora e remetente (Desabilitadas) Rua Expedicionário Holz, 351 América Joinville SC Brasil

186 Passo 9.Usuário realiza as configurações desejadas e envia para impressão Passo 10.Impressão é processada na máquina do usuário adicionando-se ao rodapé do documento que aquela é uma cópia controlada, e apresentando uma numeração. Importante: Apenas arquivos Word e PDF terão suporte a esta funcionalidade Rua Expedicionário Holz, 351 América Joinville SC Brasil

187 1. Esboço de Tela No menu principal DOCUMENTOS Usuário seleciona a opção documentos. Rua Expedicionário Holz, 351 América Joinville SC Brasil

188 Impressão cópia controlada Após clicar em alguma pasta, sistema carrega a lista de documentos da pasta. Usuário seleciona Impressão cópia controlada. Rua Expedicionário Holz, 351 América Joinville SC Brasil

189 Impressão cópia controlada Sistema exibe histórico de cópia controlada e opção para Novo. Rua Expedicionário Holz, 351 América Joinville SC Brasil

190 Impressão cópia controlada Usuário seleciona os documentos disponíveis que deseja imprimir e faz as configurações desejadas. Intervalo de páginas Campo utilizado para informar o intervalo de páginas. Separa-se por ponto-e-vírgula os números das páginas e/ou intervalos. Ex: 1-10; 15-18; 22;27 Rua Expedicionário Holz, 351 América Joinville SC Brasil

191 Destinatário Usuário escolhe as opções de destinatário. Rua Expedicionário Holz, 351 América Joinville SC Brasil

192 Finalização Ao clicar em OK, sistema realiza impressão na máquina do usuário. Sistema exibe o histórico novamente(passo 6). Rua Expedicionário Holz, 351 América Joinville SC Brasil

193 APÊNDICE E 122

194 Plano de teste 1. Identificador do Plano de Teste PT_01 02 de Abril de Introdução O objetivo é testar quatro funcionalidades do sistema que são: Assinatura Digital, Alteração de Fluxo, Cópia Controlada e Conceito de Anexo Principal. Para as tarefas de teste estarão disponíveis o programa executável do sistema, o caso de uso e suas descrições, a especificação do projeto de teste bem como a especificação dos casos de teste. No final dos testes será feito um Relatório de Testes para cada uma das funcionalidades. 3. Itens de teste Código executável do sistema. 4. Funcionalidades e características do Software que devem ser testadas Serão testadas as seguintes funcionalidades: Identificador da especificação do projeto de teste EPT_01 EPT_02 EPT_03 EPT_04 EPT_05 EPT_06 Descrição da funcionalidade Manipular Assinaturas Digitais Documento Verificar Assinaturas Documento Manipular KeyStore Manter Usuários Imprimir cópia controlada Visualizar Documento Anexo Principal Serão testadas as seguintes características do software: Adequação da funcionalidade Acurácia da funcionalidade 5. Funcionalidades e características do software que não serão testadas Não serão testadas as seguintes funcionalidades: Modelar Processo Participar Processo Efetuar login Não serão testadas as seguintes características do software Eficiência Portabilidade Rua Expedicionário Holz, 351 América Joinville SC Brasil

195 Confiabilidade 6. Abordagem A equipe de teste utilizará a Especificação Funcional para preparar as Especificações do Projeto de teste e Casos de Teste. Deverão ser verificadas a exatidão e abrangência das informações relativas às características e funcionalidade do software. À medida que são encontrados erros os mesmos são inseridos em um relatório de incidentes de teste para que o responsável pelo desenvolvimento desta funcionalidade realize os procedimentos de correção. Não está prevista a utilização de nenhum tipo de ferramenta para a automação do processo de teste Estratégia do teste O fato de o sistema já estar completamente desenvolvido leva à aplicação do Teste de Sistema, ou seja, não serão realizados Teste de Unidade, Teste de Integração, Teste de Validação, nem Teste de Regressão. Será aplicada a técnica de Teste Funcional Teste das Funcionalidades Verificar Assinaturas Documentos Manipular Assinaturas Digitais Documentos Manipular KeyStore Manter usuários Imprimir cópia controlada Visualizar Documento de Anexo Principal Adequação Verificar para as funcionalidades Assinatura Digital, Alteração de Fluxo, Cópia Controlada e Conceito de Anexo Principal a existência das funções previstas e se o conjunto delas atende a cada funcionalidade Acurácia Verifica se as funções geram resultados corretos ou conforme o esperado, para cada uma das funcionalidades, será aplicado o Teste de Sistema, utilizando-se a técnica de Teste Funcional. 6.3.Critério de parada de testes O teste irá parar quando a funcionalidade tiver sido testada. 7. Critério de Aprovação/Reprovação de itens Uma funcionalidade deverá ser reprovada se: Alguma função prevista considerada essencial para a aplicação não estiver presente. Qualquer uma de suas funções gerar resultados incorretos. 8. Critérios de Suspensão e Requisitos para retomada de teste Critérios de Suspensão: Perda de dados na base de dados; Rua Expedicionário Holz, 351 América Joinville SC Brasil

196 Comportamento inesperado no sistema operacional. Requisitos para a Retomada do Teste: Restauração da base dados; Resolver as pendências do sistema operacional; Deverá ser retestada a funcionalidade. 9. Produtos de teste Plano de Teste; Especificação do Projeto de Teste; Especificações dos Casos de Teste; Relatórios de Incidente de Teste; 10. Requisitos de Ambiente Hardware/Software Computador para a realização do teste: Sistema Microsoft Windows XP, Professional, Versão 2002, service Pack 2, registrado para a Neomind Computador Intel (R), Celeron (R) D CPU (3.06 GHz, 448 MB de RAM), Extensão de endereço físico. Internet Explorer. Versão Responsabilidades Todas as tarefas serão de responsabilidade do Grupo de teste. 12. Equipe e treinamento necessários Equipe: Rachel Santana Oliveira 13. Cronograma Hardware e Software serão utilizados no período de até 20/04/2008 para a funcionalidade Assinatura Digital, 22/04/2008 para a funcionalidade Cópia Controlada, 24/04/2008 para a funcionalidade Alteração de Fluxo da Aplicação, 26/04/2008 para a funcionalidade Conceito de Anexo Principal 14. Riscos e Contingências O cronograma deverá ser revisto, caso os recursos e o software em teste não estejam disponíveis até 20/04 para a funcionalidade Assinatura Digital, até 22/04 para a funcionalidade Cópia Controlada, até 24/04 para a funcionalidade Alteração de fluxo da Aplicação, até 26/04 para a funcionalidade Conceito de Anexo Principal. Rua Expedicionário Holz, 351 América Joinville SC Brasil

197 15. Aprovações Coordenador do grupo de teste Data Rua Expedicionário Holz, 351 América Joinville SC Brasil

198 APÊNDICE F 123

199 Sumário ESPECIFICAÇÃO DO CASO DE USO UC035 VERIFICAR ASSINATURAS DOCUMENTO NOTAS 3 2.ESBOÇO DE TELA... 4 Rua Expedicionário Holz, 351 América Joinville SC Brasil

200 (Preencher a especificação para cada caso de uso identificado na lista dos casos de uso) Especificação do Caso de Uso UC035 Verificar assinaturas Documento Criado por: Farley Niehues Data de Criação: 25/09/2007 Última Atualização: Criação Data da Atualização: Criação Atores: Descrição: Pré-condições: Pós-condições: Usuário GED e Usuário BPM Realizar a verificação das assinaturas digitais em documentos Documento assinado digitalmente Fluxo Básico de Eventos Ações do Ator Passo 1.Usuário se posiciona em um contexto onde exista um documento assinado digitalmente. Este contexto atualmente no sistema podem ser os seguintes: Participação Workflow Visualizar documentos Navegar nos documentos do GED Ações do Sistema Passo 2.Sistema identifica que está mostrando um campo do tipo arquivo que tem assinatura digital, e então mostra opção para visualização das assinaturas do documento e suas informações relacionadas (Informações da própria assinatura). Rua Expedicionário Holz, 351 América Joinville SC Brasil

201 1. Notas - Pré-condições: As pré-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. Uma précondição corresponde ao estado no qual o sistema deve estar antes que o caso de uso seja executado/iniciado. - Pós-condições As pós-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. As póscondições correspondem aos estados nos quais o sistema pode se encontrar imediatamente após o término da execução de um caso de uso. - Fluxo Básico de Eventos O fluxo básico de eventos provê uma descrição detalhada das ações/estímulos do usuário e das respostas do sistema que irão ocorrer durante a execução do caso de uso, sob condições normais e esperadas. A finalização dessa seqüência de passos ou interações faz com que o objetivo estabelecido pelo nome e pela descrição do caso de uso seja atingido. Sendo assim, essa seqüência deve ser escrita de forma a explicitar quais interações entre o ator e o sistema, são necessárias para se atingir o propósito do caso de uso. Isso é apresentado na forma de uma lista enumerada de ações executadas pelo ator, alternadas por respostas providas pelo sistema. Ações ou fluxos alternativos simples podem ser incluídos na seqüência de eventos do fluxo básico.porém, se o fluxo alternativo for mais complexo e não puder ser descrito com poucas sentenças, então, deve ser utilizado uma seqüência separada para descrevê-lo. Utilize a seção de Fluxos Alternativos para isso. Um fluxo básico de eventos pode ser identificado pelo rótulo UC <modulo, caso exista>.<seqüencial>, exemplo: UC caso de uso 1 do Módulo Fluxos Alternativos Fluxos alternativos mais complexos devem ser descritos separadamente, porém mantendo a referência para o fluxo básico associado. Inicie cada fluxo alternativo indicando explicitamente em que ponto do fluxo básico ele pode ocorrer e as condições sob as quais ele é executado. Eventualmente, parte do fluxo básico pode ser retomado após o término de um fluxo alternativo e, nesse caso, o ponto de retorno deve ser explicitado. O uso de fluxos alternativos aumentam a legibilidade do caso de uso. Tenha em mente que casos de uso são somente descrições textuais e seu propósito principal é documentar o comportamento do sistema sob o ponto de vista do usuário de maneira clara, concisa e compreensível. Rua Expedicionário Holz, 351 América Joinville SC Brasil

202 2. Esboço de Tela Sistema lista os arquivos com opção de assinar digitalmente ou apenas visualizar informações das assinaturas. Rua Expedicionário Holz, 351 América Joinville SC Brasil

203 Após selecionar a opção para visualizar as assinaturas de um respectivo documento, sistema mostra a tela de listagem de assinaturas. Usuário clica no botão de visualização de informações da assinatura. Rua Expedicionário Holz, 351 América Joinville SC Brasil

204 Sistema exibe as informações da assinatura. Rua Expedicionário Holz, 351 América Joinville SC Brasil

205 APÊNDICE G 124

206 Sumário ESPECIFICAÇÃO DO CASO DE USO UC036 MANIPULAR KEYSTORE NOTAS 3 2.ESBOÇO DE TELA... 4 Rua Expedicionário Holz, 351 América Joinville SC Brasil

207 (Preencher a especificação para cada caso de uso identificado na lista dos casos de uso) Especificação do Caso de Uso UC036 Manipular KeyStore Criado por: Farley Niehues Data de Criação: 25/09/2007 Última Atualização: Criação Data da Atualização: Criação Atores: Descrição: Pré-condições: Pós-condições: Administrador Realizar a visulização e manipulação das chaves públicas existentes para cada um dos usuários. N/A Ações do Ator Passo 1.Usuário seleciona a opção de Manipular Keystore, a partir do menu de Configurações do produto Passo 3.Usuário navega entre os usuários e seleciona 1 deles para manipulação Passo 5.Usuário seleciona uma opção para detalhamento do certificado ou ainda excluir um certificado. A exclusão irá retirar aquele certificado daquele usuário da base do sistema Fluxo Básico de Eventos Ações do Sistema Passo 2.Sistema apresenta os usuários que possuem assinaturas digitais cadastradas no sistema Passo 4.Sistema apresenta o usuário e todas as assinaturas relacionadas ao usuário (Note que neste momento a inclusão não poderá estar disponível, e sim, apenas exclusão e visualização do que está disponível). As assinaturas que não são mais válidas (fora da data de expiração) estarão sendo apresentadas de forma separada Cada usuário poderá ter mais de uma assinatura disponível. Ex: e-cpf, e-cnpj, A3 AC-Jus etc. Sistema apresenta a lista e o status de validade de cada um deles Passo 6.Sistema processa a requisição do usuário. Rua Expedicionário Holz, 351 América Joinville SC Brasil

208 1. Notas - Pré-condições: As pré-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. Uma précondição corresponde ao estado no qual o sistema deve estar antes que o caso de uso seja executado/iniciado. - Pós-condições As pós-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. As póscondições correspondem aos estados nos quais o sistema pode se encontrar imediatamente após o término da execução de um caso de uso. - Fluxo Básico de Eventos O fluxo básico de eventos provê uma descrição detalhada das ações/estímulos do usuário e das respostas do sistema que irão ocorrer durante a execução do caso de uso, sob condições normais e esperadas. A finalização dessa seqüência de passos ou interações faz com que o objetivo estabelecido pelo nome e pela descrição do caso de uso seja atingido. Sendo assim, essa seqüência deve ser escrita de forma a explicitar quais interações entre o ator e o sistema, são necessárias para se atingir o propósito do caso de uso. Isso é apresentado na forma de uma lista enumerada de ações executadas pelo ator, alternadas por respostas providas pelo sistema. Ações ou fluxos alternativos simples podem ser incluídos na seqüência de eventos do fluxo básico.porém, se o fluxo alternativo for mais complexo e não puder ser descrito com poucas sentenças, então, deve ser utilizado uma seqüência separada para descrevê-lo. Utilize a seção de Fluxos Alternativos para isso. Um fluxo básico de eventos pode ser identificado pelo rótulo UC <modulo, caso exista>.<seqüencial>, exemplo: UC caso de uso 1 do Módulo Fluxos Alternativos Fluxos alternativos mais complexos devem ser descritos separadamente, porém mantendo a referência para o fluxo básico associado. Inicie cada fluxo alternativo indicando explicitamente em que ponto do fluxo básico ele pode ocorrer e as condições sob as quais ele é executado. Eventualmente, parte do fluxo básico pode ser retomado após o término de um fluxo alternativo e, nesse caso, o ponto de retorno deve ser explicitado. O uso de fluxos alternativos aumentam a legibilidade do caso de uso. Tenha em mente que casos de uso são somente descrições textuais e seu propósito principal é documentar o comportamento do sistema sob o ponto de vista do usuário de maneira clara, concisa e compreensível. Rua Expedicionário Holz, 351 América Joinville SC Brasil

209 2. Esboço de Tela Usuário acessa a opção Manipular Keystore no menu principal Configurações Rua Expedicionário Holz, 351 América Joinville SC Brasil

210 Sistema exibe os usuários que possuem assinaturas digitais. Usuário seleciona um usuário para edição. Rua Expedicionário Holz, 351 América Joinville SC Brasil

211 Sistema exibe as informações das assinaturas que o usuário possui, e também mostra as assinaturas vencidas. As opções apresentadas aqui são de visualização e exclusão da assinatura, desvinculando ela do usuário na base do sistema. Sistema exibe informações da assinatura. Rua Expedicionário Holz, 351 América Joinville SC Brasil

212 APÊNDICE H 125

213 Sumário ESPECIFICAÇÃO DO CASO DE USO UC034 MANIPULAR ASSINATURAS DIGITAIS DOCUMENTO NOTAS 4 2.ESBOÇO DE TELA... 5 Rua Expedicionário Holz, 351 América Joinville SC Brasil

214 (Preencher a especificação para cada caso de uso identificado na lista dos casos de uso) Especificação do Caso de Uso UC034 Manipular assinaturas digitais documento Criado por: Farley Niehues Data de Criação: 25/09/2007 Última Atualização: Criação Data da Atualização: Criação Atores: Descrição: Pré-condições: Pós-condições: Usuário BPM e Usuário GED Realizar a assinatura e verificação das assinaturas em documentos do sistema E-form ou tipo de documento configurado para receber assinatura digital Fluxo Básico de Eventos Ações do Ator Passo 1.Usuário se localiza em um contexto do sistema que contenha interação com E-forms ou documentos que tenham campos do tipo arquivo. Atualmente, estes contextos são os seguintes: Workflow quando da existência de E-form relacionado com tipo de campo arquivo Publicação documentos: Quando este tipo tiver um campo arquivo associado Passo 3.Usuário seleciona a assinatura digital a ser utilizada Passo 5.Usuário seleciona que sim Ações do Sistema Passo 2.Sistema apresenta opção para realizar a assinatura do arquivo do documento, podendo o usuário selecionar uma chave já existente no repositório (Esta deverá estar associada com seu usuário), ou ainda utilização de um hardware externo (token ou smart card) Passo 4.Sistema questiona se o usuário deseja armazenar a chave pública no repositório Passo 6.Sistema realiza a assinatura do documento, armazena o documento assinado e a chave pública da assinatura. Sistema disponibiliza opção para visualização das assinaturas presentes no documento, suas informações e validade. Importante: No momento da assinatura, será verificado se existe para o usuário uma imagem de assinatura disponível, se não tiver também irá questionar se deseja fazer uso desta funcionalidade. Rua Expedicionário Holz, 351 América Joinville SC Brasil

215 Caso sim, o sistema irá adicionar ao documento, antes da assinatura, a imagem da mesma para fins de ilustração. Rua Expedicionário Holz, 351 América Joinville SC Brasil

216 1. Notas - Pré-condições: As pré-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. Uma précondição corresponde ao estado no qual o sistema deve estar antes que o caso de uso seja executado/iniciado. - Pós-condições As pós-condições de um caso de uso podem ser apresentadas na forma de uma lista enumerada. As póscondições correspondem aos estados nos quais o sistema pode se encontrar imediatamente após o término da execução de um caso de uso. - Fluxo Básico de Eventos O fluxo básico de eventos provê uma descrição detalhada das ações/estímulos do usuário e das respostas do sistema que irão ocorrer durante a execução do caso de uso, sob condições normais e esperadas. A finalização dessa seqüência de passos ou interações faz com que o objetivo estabelecido pelo nome e pela descrição do caso de uso seja atingido. Sendo assim, essa seqüência deve ser escrita de forma a explicitar quais interações entre o ator e o sistema, são necessárias para se atingir o propósito do caso de uso. Isso é apresentado na forma de uma lista enumerada de ações executadas pelo ator, alternadas por respostas providas pelo sistema. Ações ou fluxos alternativos simples podem ser incluídos na seqüência de eventos do fluxo básico.porém, se o fluxo alternativo for mais complexo e não puder ser descrito com poucas sentenças, então, deve ser utilizado uma seqüência separada para descrevê-lo. Utilize a seção de Fluxos Alternativos para isso. Um fluxo básico de eventos pode ser identificado pelo rótulo UC <modulo, caso exista>.<seqüencial>, exemplo: UC caso de uso 1 do Módulo Fluxos Alternativos Fluxos alternativos mais complexos devem ser descritos separadamente, porém mantendo a referência para o fluxo básico associado. Inicie cada fluxo alternativo indicando explicitamente em que ponto do fluxo básico ele pode ocorrer e as condições sob as quais ele é executado. Eventualmente, parte do fluxo básico pode ser retomado após o término de um fluxo alternativo e, nesse caso, o ponto de retorno deve ser explicitado. O uso de fluxos alternativos aumentam a legibilidade do caso de uso. Tenha em mente que casos de uso são somente descrições textuais e seu propósito principal é documentar o comportamento do sistema sob o ponto de vista do usuário de maneira clara, concisa e compreensível. Rua Expedicionário Holz, 351 América Joinville SC Brasil

217 2. Esboço de Tela Usuário clica em Assinar. Rua Expedicionário Holz, 351 América Joinville SC Brasil

218 Usuário seleciona a chave no repositório ou de um Hardware externo. Rua Expedicionário Holz, 351 América Joinville SC Brasil

219 Caso não exista nenhuma imagem de assinatura disponível para este usuário, sistema pergunta se o mesmo deseja disponibilizar uma imagem de assinatura. Rua Expedicionário Holz, 351 América Joinville SC Brasil

220 Neste exemplo o usuário opta por fazer upload de uma imagem de assinatura. Rua Expedicionário Holz, 351 América Joinville SC Brasil

221 Após conclusão da assinatura, sistema retorna a tela inicial com a lista de assinaturas. Detalhe: Neste exemplo, o documento ainda não foi criado, somente após clicar em OK, o documento será criado e as assinaturas inseridas no mesmo. Rua Expedicionário Holz, 351 América Joinville SC Brasil

222 APÊNDICE I 126

223 Especificação do Projeto de Teste Alteração de Fluxo da Aplicação 1. Identificador da Especificação de Projeto de Teste EPT_02 04 de Abril de Funcionalidades e Características Tratadas 2.1 Características Adequação da Funcionalidade; Acurácia da fucionalidade. 2.2 Funcionalidades Administrador: Criação da URL redirecionando para uma interface adequada através do login feito pelo usuário. 3. Refinamentos da Abordagem de Teste Será utilizada a técnica de teste Funcional. A cada erro encontrado devido à entrada de dados inválidos será anotado em um documento de relatório de incidente de teste. Também serão avaliados casos onde não contém entradas de dados, mas apenas o funcionamento das funcionalidades e de alguns itens citados na seção Identificação dos casos de teste e procedimentos de teste associados. 4. Identificação dos casos de teste e procedimentos de teste associados Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL. Nº Nome do caso de teste Identificação 01 Abrir o campo URL EPT_ECU_01 02 Preencher o campo URL com dados válidos EPT_ECU_02 03 Preencher o campo URL com dados EPT_ECU_03 Rua Expedicionário Holz, 351 América Joinville SC Brasil

224 inválidos 04 Preencher o campo URL em branco EPT_ECU_04 05 Fechar o campo URL EPT_ECU_05 Acima foram verificadas as ações que podem ser feitas pelo administrador em cima da configuração da página de um dado usuário. Efetuar o login por meio do usuário que foi configurado: verificando a configuração para a interface adequada - verificar se na página inicial específica, o menu do fusion permanece visível ao usuário - verificar se a página é carregada em branco caso não seja especificada uma página inicial. - verificar se abre apenas uma tela - verificar se aceitou URL externa, caso o administrador tenha configurado com este tipo de URL - verificar se usuário pode editar sua própria URL. - Verificar nas configurações daquele usuário, se o mesmo pode modificar a URL da página, pela especificação isto não pode acontecer 5. Critério de Aprovação/Reprovação Uma funcionalidade será considerada como reprovada no teste se: Alguma função prevista ou essencial estiver ausente; Geração de resultados incorretos por qualquer uma das funções. Rua Expedicionário Holz, 351 América Joinville SC Brasil

225 APÊNDICE J 127

226 Especificação do Projeto de Teste Assinatura Digital 1. Identificador da Especificação de Projeto de Teste EPT_06 29 de novembro de Funcionalidades e Características Tratadas 2.1 Funcionalidades Modelar um tipo de arquivo que demande a assinatura digital o Obs.: este teste será feito pelo modelador do processo, não será permitido para os testadores. Manipular Assinaturas Digitais Documento Subfuncionalidades: Assinar Documento Escolher uma das opções de Assinatura Armazenar ou não armazenar a chave pública no repositório Cancelar a efetivação da assinatura Efetivar a assinatura Adicionar imagem da assinatura no documento Verificar Assinaturas Documentos Subfuncionalidades: - Visualização das assinaturas do documento - Cancelamento da visualização desta janela - Visualização das informações de uma dada assinatura - Cancelamento da visualização das informações da assinatura Manipular KeyStore Subfuncionalidades: - Manipular KeyStore. Obs.: só irá abrir caso existam usuários - O usuário tem a opção de SAIR - Se o usuário não sair, seleciona Usuário - Para sair do contexto acima o usuário clica em SAIR ou CANCELAR - Se o usuário não CANCELAR clica na opção de Detalhamento de uma assinatura Rua Expedicionário Holz, 351 América Joinville SC Brasil

227 - Caso o usuário não escolha a opção de detalhamento de uma assinatura ele pode optar por Exclusão de alguma assinatura. 2.2 Características Adequação da Funcionalidade; Acurácia da funcionalidade. 3. Refinamentos da Abordagem de Teste Será utilizada a técnica de teste Funcional. Cada erro encontrado devido a entrada de dados inválidas será anotado em um documento de relatório de incidente de teste. Manipular Assinaturas Digitais Documentos Obs.: Serão testados os campos que requeiram consistência nos dados bem como botões que levam à visualização de uma determinada janela. Subfuncionalidade Assinar Documento Escolher um documento válido para que seja assinado - Subfuncionalidade Opções de assinatura com chave Escolher uma das opções e efetivar a ação - Subfuncionalidade Assinatura através do Cartão assinatura O usuário insere cartão em um leitor e digita a senha do mesmo para que ocorra a - Subfuncionalidade Adicionar imagem da assinatura no documento O usuário faz upload da imagem e adiciona à assinatura - Subfuncionalidade Cancelar a adição da assinatura no documento O usuário, após passar por todos os passos para a assinatura recebe uma mensagem questionando se o mesmo deseja continuar com a assinatura do documento e responde que NÃO. Verificar Assinaturas Documentos - Subfuncionalidade Visualização das assinaturas presentes Apenas a vizualização, sem nenhuma entrada a ser adicionada Rua Expedicionário Holz, 351 América Joinville SC Brasil

228 - Subfuncionalidade Cancelar a vizualização Apenas o cancelamento, sem nenhuma entrada a ser adicionada. - Subfuncionalidade Visualização das informações de uma dada assinatura O usuário clica na lupa de uma dada assinatura para verificar suas informações - Subfuncionalidade Cancelamento da Visualização de uma dada assinatura O usuário clica no botão SAIR ou CANCELAR para sair do contexto no qual se encontra Manipular KeyStore - Subfuncionalidade Manipular KeyStore Não há nenhuma entrada a ser processada. - Subfuncionalidade O usuário tem a opção de sair O usuário sai da janela voltando ao menu principal - Subfuncionalidade Selecionar um usuário assinatura. O usuário seleciona um usuário desejado para visualizar suas informações de - Subfuncionalidade Sair da janela do usuário selecionado O usuário clica no botão SAIR ou CANCELAR e retorna à janela na qual contém toda a lista de usuários. - Subfuncionalidade Visualização das assinaturas do usuário Nome do usuário, de forma que encontre a visualização das assinaturas no banco de dados. - Subfuncionalidade Detalhamento da assinatura O usuário clica na lupa de uma das assinaturas do usuário para verificar detalhes sobre a assinatura. - Subfuncionalidade exclusão da assinatura selecionada pelo usuário O usuário poderá excluir a assinatura da base de dados do sistema. Rua Expedicionário Holz, 351 América Joinville SC Brasil

229 Obs.: Serão testados os campos que requeiram consistência nos dados bem como botões que levam à visualização de uma determinada janela Identificação dos casos de teste e procedimentos de teste associados Funcionalidade Manipular Assinaturas Digitais Documento Subfuncionalidade Assinar Documento Nº Nome do caso de teste Identificação 01 Clicar no botão de Assinaturas de documentos EPT_AN_01 Subfuncionalidade Opções de assinatura com chave Nº Nome do caso de teste Identificação 02 Clicar no botão repositório EPT_AN_02 03 Escolher uma chave e responder que EPT_AN_03 deseja armazenar no repositório 04 Escolher uma chave e responder que não EPT_AN_04 deseja armazenar no repositório 05 Efetivar a ação de assinatura EPT_AN_05 06 Cancelar a ação para assinatura EPT_AN_06 Subfuncionalidade Adicionar imagem da assinatura no documento Nº Nome do caso de teste Identificação 07 Concordar com a inserção de uma imagem na assinatura 08 Discordar com a inserção de uma imagem na assinatura 09 Se concordar com a inserção fazer upload de um arquivo válido 10 Se não concordar com a inserção fazer upload de um arquivo inválido EPT_AN_07 EPT_AN_08 EPT_AN_09 EPT_AN_10 Subfuncionalidade Assinatura através do Cartão Nº Nome do caso de teste Identificação Rua Expedicionário Holz, 351 América Joinville SC Brasil

230 11 O usuário insere o cartão na leitora quando o sistema o solicita 12 A leitora está desconectada e o sistema informa sobre isto 13 A leitora está desconfigurada da máquina, o sistema informa sobre isto EPT_AN_11 EPT_AN_12 EPT_AN_13 14 O usuário digita a senha correta EPT_AN_14 15 O usuário digita a senha incorreta EPT_AN_15 Subfuncionalidade Cancela a adição da assinatura no documento Nº Nome do caso de teste Identificação 16 Diante da mensagem exibida pelo sistema o usuário responde que NÃO EPT_AN_16 Funcionalidade Verificar Assinaturas Documentos Subfuncionalidade Visualização das Assinaturas presentes Nº Nome do caso de teste Identificação 17 Clicar no botão Visualização das Assinaturas EPT_VAD_17 Subfuncionalidade Cancelamento da Visualização Nº Nome do caso de teste Identificação 18 Na janela de assinaturas do documento, clicar no botão SAIR ou CANCELAR para sair do contexto daquela visualização EPT_VAD_18 Subfuncionalidade Visualização das informações de uma dada assinatura Nº Nome do caso de teste Identificação 19 Na janela de assinaturas do documento clicar na lupa de alguma assinatura e visualizar informações da mesma EPT_AN_19 Subfuncionalidade Cancelamento de visualização de uma dada assinatura Nº Nome do caso de teste Identificação Rua Expedicionário Holz, 351 América Joinville SC Brasil

231 20 Na janela de visualização de uma dada assinatura clicar na opção SAIR ou CANCELAR para deixar de participar daquele contexto de visualização EPT_AN_20 Funcionalidade Manipular KeyStore Subfuncionalidade Manipular KeyStore Nº Nome do caso de teste Identificação 21 Clicar na opção de menu Manipular Keystore EPT_VAD_21 Subfuncionalidade Sair da janela de Manipular Keystore Nº Nome do caso de teste Identificação 22 O usuário pode sair da janela com os usuários que possuem assinaturas por meio do botão CANCELAR ou SAIR EPT_AN_22 Subfuncionalidade Seleciona Usuário Nº Nome do caso de teste Identificação 23 O usuário seleciona um usuário por meio da lupa EPT_VAD_23 Subfuncionalidade Sair da janela do usuário selecionado Nº Nome do caso de teste Identificação 24 O usuário sai da janela do usuário selecionado. EPT_AN_24 Subfuncionalidade Visualização de uma assinatura do usuário Nº Nome do caso de teste Identificação 25 O usuário seleciona uma assinatura através da lupa para visualização EPT_VAD_25 Subfuncionalidade Exclusão de uma assinatura do usuário Nº Nome do caso de teste Identificação Rua Expedicionário Holz, 351 América Joinville SC Brasil

232 26 O usuário seleciona uma assinatura e a exclui da base de dados do sistema EPT_VAD_26 5. Critério de Aprovação/Reprovação Uma funcionalidade será considerada como reprovada no teste se: Alguma função prevista ou essencial estiver ausente; Geração de resultados incorretos por qualquer uma das funções. Rua Expedicionário Holz, 351 América Joinville SC Brasil

233 APÊNDICE L 128

234 Especificação do Projeto de Teste Conceito de Anexo Principal 1. Identificador da Especificação de Projeto de Teste EPT_09 07 de janeiro de Funcionalidades e Características Tratadas 2.1 Características Adequação da Funcionalidade; Acurácia da fucionalidade. 2.2 Funcionalidades Modelar Processo Participar Processo Visualizar Processo Subfuncionalidades - da parte do modelador: configurar o anexo principal. Obs.: isso será feito apenas pelo modelador, o testador não irá ver isso. - da parte do usuário cujo documento está configurado como anexo principal, quando participa de uma solicitação: visualização do anexo principal - incluir arquivos: digitalizar documentos, fazer upload de um arquivo, criação a partir de um tipo de documento pré existente no GED. - impressão via Adobe Reader para PDF - visualizar a atualização dos documentos do Anexo Principal no GED - caso seja o gestor ou responsável pelo processo: visualizar hits daquele processo judicial, ou hits das páginas do documento principal do wokflow - Visualização de Thumbnails - Visualização de livro 3. Refinamentos da Abordagem de Teste Será utilizada a técnica de teste Funcional. A cada erro encontrado devido à entrada de dados inválidos será anotado em um documento de relatório de incidente de teste. Também serão avaliados casos onde não contém entradas de dados, mas apenas o funcionamentos das funcionalidades e de alguns itens citados na seção Identificação dos casos de teste e procedimentos de teste associados. Rua Expedicionário Holz, 351 América Joinville SC Brasil

235 4. - Identificação dos casos de teste e procedimentos de teste associados Participar Processo Subfuncionalidade (da parte do usuário que participa de uma solicitação): Visualização de anexo principal N Nome do caso de teste Identificação 01 Vizualizar Anexo Principal EPT_VAP_05 Subfuncionalidade da parte do usuário que participa de uma solicitação: Escolher modo de visualização Nº Nome do caso de teste Identificação 02 Escolher o modo Livro EPT_EMV_02 03 Folhear as páginas do livro de diferentes maneiras EPT_EMV_03 04 Escolher o modo thumbnails EPT_EMV_04 05 Folhear as páginas do thumbnails de diferentes maneiras EPT_EMV_05 Subfuncionalidade: Fazer Upload de documentos Nº Nome do caso de teste Identificação 06 Fazer Upload com os formatos: tiff, jpg, html, pdf e documentos do Microsoft Office e Open Office EPT_FUD_06 Subfuncionalidade: Fazer digitalização de documentos Nº Nome do caso de teste Identificação Rua Expedicionário Holz, 351 América Joinville SC Brasil

236 07 Fazer Digitalização com os formatos: tiff, jpg, html, pdf e documentos do Microsoft Office e Open Office EPT_FDD_07 5. Critério de Aprovação/Reprovação Uma funcionalidade será considerada como reprovada no teste se: Alguma função prevista ou essencial estiver ausente; Geração de resultados incorretos por qualquer uma das funções. Rua Expedicionário Holz, 351 América Joinville SC Brasil

237 APÊNDICE M 129

238 Especificação do Projeto de Teste Cópia Controlada 1. Identificador da Especificação de Projeto de Teste EPT_04 04 de abril de Funcionalidades e Características Tratadas 2.1 Funcionalidades 2.2 Características Cópia controlada Subfuncionalidades: - Impressão de cópia controlada; - Nova impressão; - Efetivar a impressão; - Cancelar a impressão; - Nome destinatário; Adequação da Funcionalidade; Acurácia da fucionalidade. - Efetivar escolha do destinatário; - Cancelar escolha do destinatário. 3. Refinamentos da Abordagem de Teste Será utilizada a técnica de teste Funcional. A cada erro encontrados devido à entrada de dados inválidas será anotado em um documento de relatório de incidente de teste. Funcionalidade Cópia Controlada Obs.: Serão testados os campos que requeiram consistência nos dados bem como botões que levam à visualização de uma determinada janela. - Subfuncionalidade Impressão de Cópia Controlada Clicar no botão Impressão de Cópia Controlada - Subfuncionalidade Nova Impressão Rua Expedicionário Holz, 351 América Joinville SC Brasil

239 Clicar no botão Novo, que serve para ir para uma janela contendo o documentos que podem ser escolhidos para impressão Controlada. - Subfuncionalidade Efetivar Impressão Escolher uma opção Não escolher nenhuma opção Escolher um destinatário válido Não escolher destinatário Não escolher um destinatário válido Escolher as páginas a serem impressas com o formato de escolha certa. Escolher as páginas a serem impressas com o formato de escolha errado. - Subfuncionalidade Cancelar Impressão Entrar com quaisquer tipos de dados, válidos ou inválidos e cancelar o processo. - Subfuncionalidade Nome do Destinatário Clicar em Nome do destinatário e verificar se abre uma página com as opções para nome do destinatário. - Subfuncionalidade Efetivar escolha do destinatário Selecionar usuário e escolher. Selecionar usuário e não escolher um usuário. Selecionar Papel e escolher um papel. Selecionar Papel e não escolher um papel. Selecionar Outro e preencher seu campo. Selecionar Outro e não preencher o campo. - Subfuncionalidade Cancelar escolha do destinatário Selecionar usuário e escolher algum usuário. Selecionar usuário e não escolher um usuário. Selecionar Papel e escolher um papel. Selecionar Papel e não escolher um papel. Selecionar Outro e preencher seu campo. Selecionar Outro e não preencher o campo. Rua Expedicionário Holz, 351 América Joinville SC Brasil

240 4. - Identificação dos casos de teste e procedimentos de teste associados Funcionalidade Cópia Controlada Subfuncionalidade Impressão de Cópia Controlada Nº Nome do caso de teste Identificação 01 Clique no botão Impressão de Cópia Controlada EPT_ICC_01 Subfuncionalidade Nova Impressão Nº Nome do caso de teste Identificação 02 Clicar no botão Novo EPT_NI_02 Subfuncionalidade Efetivar Impressão Nº Nome do caso de teste Identificação 03 Escolher uma opção EPT_EI_03 04 Não escolher uma opção EPT_EI_04 05 Escolher um destinatário válido EPT_EI_05 06 Não escolher destinatário EPT_EI_06 07 Escolher as páginas a serem impressas com o fomato de escolha certo 08 Escolher as páginas a serem impressas com o formato de escolha errado EPT_EI_07 EPT_EI_08 Subfuncionalidade Cancelar Impressão Nº Nome do caso de teste Identificação 09 Entrar com quaisquer tipos de dados válidos ou inválidos. EPT_SPR_09 Subfuncionalidade Nome do destinatário Nº Nome do caso de teste Identificação 10 Clicar em nome do destinatário EPT_ND_10 Rua Expedicionário Holz, 351 América Joinville SC Brasil

241 Subfuncionalidade Efetivar escolha do destinatário Nº Nome do caso de teste Identificação 11 Selecionar usuário, sem escolher um devido usuário EPT_EED_11 12 Selecionar usuário e escolher algum usuário EPT_EED_12 13 Selecionar Papel e escolher um papel. EPT_EED_13 14 Selecionar Papel e não escolher um papel EPT_EED_14 15 Selecionar Outro e preencher seu campo EPT_EED_15 16 Selecionar Outro e não preencher seu campo EPT_EED_16 Subfuncionalidade Cancelar escolha de um destinatário Nº Nome do caso de teste Identificação 17 Selecionar usuário, sem escolher um devido usuário EPT_CED_17 18 Selecionar usuário e escolher algum usuário EPT_CED_18 19 Selecionar Papel e escolher um papel. EPT_CED_19 20 Selecionar Papel e não escolher um papel EPT_CED_20 21 Selecionar Outro e preencher seu campo EPT_CED_21 5. Critério de Aprovação/Reprovação Uma funcionalidade será considerada como reprovada no teste se: Alguma função prevista ou essencial estiver ausente; Geração de resultados incorretos por qualquer uma das funções. Rua Expedicionário Holz, 351 América Joinville SC Brasil

242 APÊNDICE N 130

243 Especificação dos casos de teste Customização de Interfaces 1. Identificador da Especificação do Caso de Teste ECT_08 31de dezembro de 2007 Especificação dos casos de teste número Itens de teste Código executável do sistema. 3. Casos de Teste Do ponto de vista do Administrador 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 01 Identificação: ECT_CNA_ECU_01 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída portal/render/formlist?type=docu URL Tela de Gestão de Documentos mententityinfo 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 02 Identificação: ECT_CNA_ECU_02 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída portal/render/formlist?type=dash URL Tela de Dashboards BoardQuery 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 03 Identificação: ECT_CNA_ECU_03 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída portal/render/formlist?type=xpd URL Tela de Gestão de Workflows LProcessModel 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Rua Expedicionário Holz, 351 América Joinville SC Brasil

244 Nº 04 Identificação: ECT_CNA_ECU_04 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída portal/render/formlist?type=dyna URL Tela de E-forms Dinâmicos micentityinfo 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 05 Identificação: ECT_CNA_ECU_05 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída URL Tela com a página do Gmail 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 06 Identificação: Nome: Dados vazios ECT_CNA_ECU_06 Nome do campo Entrada Saída URL Vazia Tela Vazia 1. Funcionalidade: Efetuar a ação de edição do usuário enfatizando a criação da URL Nº 07 Identificação: ECT_CNA_ECU_07 Nome: Dados inválidos para todos os campos. Nome do campo Entrada Saída portal/render/formlist?type=dyna URL Mensagem especificando erro micntityinfo de conexão Do ponto de vista do usuário 1. Funcionalidade: Efetuar o login: verificando a configuração para a interface adequada 8 De acordo com o primeiro caso de teste verificar se o sistema inicia com a tela de gestão de documentos 9 De acordo com o segundo caso de teste verificar se o sistema inicia com a tela de Dashboards 10 - De acordo com o terceiro caso de teste verificar se o sistema inicia com a tela de gestão de workflows. Rua Expedicionário Holz, 351 América Joinville SC Brasil

245 11 - De acordo com o quarto caso de teste verificar se o sistema inicia com a tela e-forms dinâmicos 12 - De acordo com o quinto caso de teste verificar se o sistema inicia com a tela com a página do gmail De acordo com o sexto caso de teste verificar se o sistema inicia com a tela vazia 14 - De acordo com o sétimo caso de teste verificar se o sistema inicia com a tela de erro. 4. Requisitos de Ambiente de Teste Todos os casos de teste especificados na seção 3 serão executados no mesmo ambiente, conforme especificado abaixo: Hardware/Software - computador para realização e geração dos relatórios de teste: Sistema Microsoft Windows XP, Professional, Versão 2002, service Pack 2, registrado para a Neomind Computador Intel (R), Celeron (R) D CPU (3.06 GHz, 448 MB de RAM), Extensão de endereço físico. Internet Explorer. Versão Requisitos e Procedimentos Especiais Não existe nada relevante. 6. Dependências entre casos de Teste Nº do caso de teste Dependências Rua Expedicionário Holz, 351 América Joinville SC Brasil

246 11 12 Rua Expedicionário Holz, 351 América Joinville SC Brasil

247 APÊNDICE O 131

248 Especificação dos casos de teste Assinatura Digital 1. Identificador da Especificação do Caso de Teste ECT_01 04 de abril de 2008 Especificação dos casos de teste número Itens de teste Código executável do sistema. 3. Casos de Teste 1. Funcionalidade: Manipular Assinaturas Digitais Documento 1.1. Subfuncionalidade: Assinar Documento Nº 01 Identificação: ECT_VP_AD_01 Nome do campo/botão Entrada Saída Nome: Clique em botão sem entrada de dados Assinaturas de Documentos Clicar neste botão Janela com a solicitação de inserção do cartão Nº 02 Identificação: ECT_VP_AD_02 Nome do campo/botão Entrada Saída Assinaturas de Documentos Clicar neste botão com o cartão já inserido Nome: Clique em botão sem entrada de dados Janela com a solicitação da senha do cartão Senha 123 Janela questionando se o 1.2. Subfuncionalidade: Adicionar Imagem da Assinatura no Documento Nome do campo/botão Entrada Saída Adicionar Imagem na Assinatura Adicionar Imagem na Assinatura Arquivo de teste 01 Arquivo de teste 02 usuário deseja armazenar uma imagem na assinatura Documento com imagem adicionada ao seu final Documento com sua imagem adicionada ao seu final Obs.: 1- Não existe implementada a opção de cancelamento da assinatura, por este motivo não será incluída no caso de teste. Rua Expedicionário Holz, 351 América Joinville SC Brasil

249 2- Abaixo encontram-se casos de teste nos quais podem-se fazer a escolha entre duas opções de assinatura, atributo que não existe mais no sistema. Sendo assim não é possível a realização deste teste. Os casos de teste estão representados de forma ilustrativa. E isto mostra que os requisitos não foram bem fundamentados. 1. Funcionalidade: Versionamento de processos 1.1. Subfuncionalidade: Adicionar uma nova versão de um processo Nº 03 Identificação: ECT_VP_ANV_03 Nome do campo/botão Entrada Saída Nome: Dados inválidos para E- form E-form Vazio Mensagem solicitando a escolha de um E-form Liberado Não Não Descrição Versão Nova Versão Nova Data da versão 26/11/07 26/11/07 Modelo do processo Processo editado Processo editado 1. Funcionalidade: Versionamento de processos 1.1. Subfuncionalidade: Adicionar uma nova versão de um processo Nº 04 Identificação: ECT_VP_ANV_04 Nome do campo/botão Entrada Saída Nome: Dados inválidos para data da versão, data será anterior à data atual. E-form Atribuição Temporária Atribuição Temporária Liberado Sim Sim Descrição Versão Nova Versão Nova Data da versão 25/11/07 Mensagem solicitando a data atual. 1. Funcionalidade: Versionamento de processos 1.1. Subfuncionalidade: Adicionar uma nova versão de um processo Nº 05 Identificação: ECT_VP_ANV_05 Nome do campo/botão Entrada Saída Nome: Dados inválidos para formato da data - dia E-form Atribuição Temporária Atribuição Temporária Rua Expedicionário Holz, 351 América Joinville SC Brasil

250 Liberado Sim Sim Descrição Versão Nova Versão Nova Data da versão 5/12/07 Mensagem solicitando o formato correto, ou o conserto automático da data. 1. Funcionalidade: Versionamento de processos 1.1. Subfuncionalidade: Adicionar uma nova versão de um processo Nº 06 Identificação: ECT_VP_ANV_06 Nome do campo/botão Entrada Saída Nome: Dados inválidos para formato da data - mês E-form Atribuição Temporária Atribuição Temporária Liberado Sim Sim Descrição Versão Nova Versão Nova Data da versão 05/1/08 Mensagem solicitando o formato correto, ou o conserto automático da data. 1. Funcionalidade: Versionamento de processos 1.1. Subfuncionalidade: Adicionar uma nova versão de um processo Nº 07 Identificação: ECT_DA_EAD_06 Nome do campo/botão Entrada Saída Nome: Dados inválidos data - E-form Atribuição Temporária Atribuição Temporária ano Liberado Sim Sim Descrição Versão Nova Versão Nova Data da versão 05/12/8 Mensagem solicitando o formato correto, ou o conserto automático da data. 4. Requisitos de Ambiente de Teste Todos os casos de teste especificados na seção 3 serão executados no mesmo ambiente, conforme especificado abaixo: Rua Expedicionário Holz, 351 América Joinville SC Brasil

251 Hardware/Software - computador para realização e geração dos relatórios de teste: Sistema Microsoft Windows XP, Professional, Versão 2002, service Pack 2, registrado para a Neomind Computador Intel (R), Celeron (R) D CPU (3.06 GHz, 448 MB de RAM), Extensão de endereço físico. Internet Explorer. Versão Requisitos e Procedimentos Especiais Não existe nada relevante. 6. Dependências entre casos de Teste Nº do caso de teste Dependências Rua Expedicionário Holz, 351 América Joinville SC Brasil

252 APÊNDICE P 132

253 Especificação dos casos de teste Conceito de Anexo Principal 1. Identificador da Especificação do Caso de Teste ECT_09 08 de janeiro de 2008 Especificação dos casos de teste número Itens de teste Código executável do sistema. 3. Casos de Teste Do ponto de vista do Administrador 1. Funcionalidade: Participar Processo 1.1 Subfuncionalidade: Anexo principal Nº 01 Identificação: ECT_PP_AP_01 Nome: Dados válidos para todos os campos. Processo a ser utilizado: Ações Judiciais Novas Nome do campo Entrada Saída Botão: Anexo Principal Clique no botão Visualização do Anexo Principal 2. Funcionalidade: Visualizar Documento Anexo Principal 2.1 Subfuncionalidade: Escolher modo de visualização Livro Nº 02 Identificação: ECT_VDA_EVL_02 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída Botão Livro Clique no Botão Livro Interface na qual será visualizado o documento do anexo principal no formato de livro 03 - Na interface no formato de livro será manipulada clicando nas páginas pra que elas virem para o lado inverso ao qual está sendo clicado, a barra de paginação será manipulada Rua Expedicionário Holz, 351 América Joinville SC Brasil

254 usando as setas bem como a área em que pode ser enumerada a página que se deseja chegar. A área também será preenchida com dados inválidos como letras. Também será verificado se o usuário poderá arrastar as páginas. 3. Funcionalidade: Visualizar Documento Anexo Principal 3.1 Subfuncionalidade: Escolher modo de visualização em Thubnails Nº 04 Identificação: ECT_VDA_EVT_04 Nome: Dados válidos para todos os campos. Nome do campo Entrada Saída Botão Thubnails Clique no Botão Thubnails Interface na qual será visualizado o documento do anexo principal no formato de thubnails 05 - Na interface no formato de thubnails será manipulada clicando nas páginas que se encontram na lateral da página principal, a barra de paginação será manipulada usando as setas bem como a área em que pode ser enumerada a página que se deseja chegar. A área também será preenchida com dados inválidos como letras. Também será verificado se o usuário poderá arrastar as páginas. 06 Verificar se os documentos de anexo principal estão atualizados no GED. 4. Requisitos de Ambiente de Teste Todos os casos de teste especificados na seção 3 serão executados no mesmo ambiente, conforme especificado abaixo: Hardware/Software - computador para realização e geração dos relatórios de teste: Sistema Microsoft Windows XP, Professional, Versão 2002, service Pack 2, registrado para a Neomind Computador Intel (R), Celeron (R) D CPU (3.06 GHz, 448 MB de RAM), Extensão de endereço físico. Internet Explorer. Versão Requisitos e Procedimentos Especiais Rua Expedicionário Holz, 351 América Joinville SC Brasil

255 Não existe nada relevante. 6. Dependências entre casos de Teste Nº do caso de teste Dependências Rua Expedicionário Holz, 351 América Joinville SC Brasil

256 APÊNDICE Q 133

257 Especificação dos casos de teste Cópia Controlada 1. Identificador da Especificação do Caso de Teste ECT_02 09 de abril de 2008 Especificação dos casos de teste número Itens de teste Código executável do sistema. 3. Casos de Teste 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Impressão de Cópia Controlada Nº 01 Identificação: ECT_CC_IC_01 Nome: Dados válidos para todos os campos ou clique em botão que leva à abertura de outra janela Nome do campo/botão Entrada Saída Impressão Cópia Controlada Clique no botão Abertura da janela com o histórico das impressões que foram feitas e um botão Novo para fazer uma nova impressão. 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nova Impressão Nº 02 Identificação: ECT_CC_NI_01 Nome: Dados válidos para todos os campos ou clique em Nome do campo/botão Entrada Saída botão que leva à abertura de outra janela Novo Clique no botão Abertura da janela com opções para impressão de cópia controlada Rua Expedicionário Holz, 351 América Joinville SC Brasil

258 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 03 Identificação: ECT_CC_EI_03 Nome: Dados válidos para todos os campos ou clique em botão que leva à abertura de outra janela Nome do campo/botão Entrada Saída Opção Seleção da opção Opção selecionada Destinatário Usuário: Rachel Santana Rachel Santana Oliveira Oliveira Páginas 15-17;17-20 Cópia das páginas especificadas. 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 04 Identificação: ECT_CC_EI_04 Nome: Dados válidos para todos os campos Nome do campo/botão Entrada Saída Opção Seleção da opção Opção selecionada Destinatário Usuário: Eduardo Eduardo Páginas 2 Cópia das páginas especificadas. 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 05 Identificação: ECT_CC_EI_05 Nome: Dados inválidos para Páginas formato errado da especificação das páginas Nome do campo/botão Entrada Saída Opção Seleciona uma opção Opção selecionada Destinatário Papel: Teste Teste Rua Expedicionário Holz, 351 América Joinville SC Brasil

259 Páginas 9,14 Mensagem de erro sobre o formato de Páginas 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 06 Identificação: ECT_CC_EI_06 Nome: Dados inválidos para Nome do campo/botão Entrada Saída Nome destinatário Entrar com nome vazio Opção Seleciona uma opção Opção selecionada Destinatário Papel:vazio Mensagem solicitando um nome do destinatário Páginas 12;14;18 Cópia das páginas especificadas 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 07 Identificação: ECT_CC_EI_07 Nome: Dados inválidos para Páginas formato errado da Nome do campo/botão Entrada Saída especificação das páginas Opção Seleciona uma opção Opção selecionada Destinatário Outro: Vazio Mensagem solicitando nome do destinatário Páginas 11;15;17 Cópia das páginas especificadas Rua Expedicionário Holz, 351 América Joinville SC Brasil

260 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Efetivar Impressão Nº 08 Identificação: ECT_CC_EI_08 Nome: Dados inválidos para Páginas formato errado da Nome do campo/botão Entrada Saída especificação das páginas Opção Seleciona uma opção Opção selecionada Destinatário Usuário: Rachel Santana Oliveira Rachel Santana Oliveira Páginas Vazio Mensagem de erro sobre o formato de Páginas 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 09 Identificação: ECT_CC_ND_09 Nome: Dados válidos para todos os campos Nome do campo/botão Entrada Saída Opção Seleciona Opção Opção selecionada Usuário Rachel Santana Oliveira Rachel Santana Oliveira Papel Vazio Vazio Outros Vazio Vazio 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 10 Identificação: ECT_CC_ND_10 Nome do campo/botão Entrada Saída Nome: Dados válidos para todos os campos Opção Seleciona Papel Papel selecionado Usuário Vazio Vazio Rua Expedicionário Holz, 351 América Joinville SC Brasil

261 Papel Teste Teste Outros Vazio Vazio 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 11 Identificação: ECT_CC_ND_11 Nome: Dados válidos para todos os campos Nome do campo/botão Entrada Saída Opção Seleciona Usuário Usuário selecionado Usuário Vazio Vazio Papel Vazio Vazio Outros Joaquim C. Manzini Jr Joaquim C. Manzini Jr 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 12 Identificação: ECT_CC_ND_12 Nome do campo/botão Entrada Saída Nome: Dados inválidos para o campo Usuário Opção Seleciona Usuário Usuário selecionado Usuário Vazio Mensagem solicitando a escolha de um usuário Papel Vazio Vazio Outros Vazio Vazio 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 13 Identificação: ECT_CC_ND_13 Nome do campo/botão Entrada Saída Nome: Dados inválidos para o campo Papel Rua Expedicionário Holz, 351 América Joinville SC Brasil

262 Opção Seleciona Usuário Usuário selecionado Usuário Vazio Vazio Papel Vazio Mensagem solicitando a escolha de um usuário Outros Vazio Vazio 1. Funcionalidade: Cópia Controlada 1.1. Subfuncionalidade: Nome do Destinatário Nº 14 Identificação: ECT_CC_ND_14 Nome do campo/botão Entrada Saída Nome: Dados inválidos para o campo Outros Opção Seleciona Usuário Usuário selecionado Usuário Vazio Vazio Papel Vazio Vazio Outros Vazio Mensagem solicitando a escolha de um usuário 4. Requisitos de Ambiente de Teste Todos os casos de teste especificados na seção 3 serão executados no mesmo ambiente, conforme especificado abaixo: Hardware/Software - computador para realização e geração dos relatórios de teste: Sistema Microsoft Windows XP, Professional, Versão 2002, service Pack 2, registrado para a Neomind Computador Intel (R), Celeron (R) D CPU (3.06 GHz, 448 MB de RAM), Extensão de endereço físico. Internet Explorer. Versão Requisitos e Procedimentos Especiais Rua Expedicionário Holz, 351 América Joinville SC Brasil

263 Não existe nada relevante. 6. Dependências entre casos de Teste Nº do caso de teste Dependências Rua Expedicionário Holz, 351 América Joinville SC Brasil

264 APÊNDICE R 134

265 Relatório de Incidentes Alteração de Fluxo da Aplicação Versão do Documento: 1.0 Sumário 1. Módulo Identificação da função Descrição da atividade Incidentes identificados Descrição dos incidentes Observações e comentários Módulo BPM 2. Identificação da função Função Descrição da atividade A atividade de teste realizada sobre a função de consulta teve o intuito de testar a atividade executada pelo administrador de configurar a página inicial a ser visualizada por um dado usuário. Também foi verificado se a URL escolhida pelo administrador condiz com o que aparece como página inicial para o usuário. Outros detalhes de funcionalidade também foram testados. Rua Expedicionário Holz, 351 América Joinville SC Brasil

266 4. Incidentes identificados Ação Executada Erro Tester Data Ambiente Status Grau da Ocorrência Entrada inválida de URL 01 Rachel 03/05/08 Base China Testes Avaliar Ocorrência Prioritário Edição das URLs pelos usuários 02 Rachel 03/05/08 Base China Avaliar Ocorrência Nãoprioritário Testes 5. Descrição dos incidentes Erro Descrição Tester Descrição do Acerto Desenvolvimento 01 Quando o administrador digita de forma errada a URL e efetua o processo de edição, vê-se necessário que isto seja informado ao administrador, pois quando o usuário, cujos dados foram editados, fizer login irá abrir uma página de erro http status Tirar o poder de o usuário escolher a URL para sua página de entrada, pois este poder que o usuário teria não está especificado no documento de requisitos. Rachel Rachel 6. Observações e comentários Grau de Ocorrência : Prioritário e Não Prioritário Rua Expedicionário Holz, 351 América Joinville SC Brasil

267 2 incidentes 2 ocorrências Rua Expedicionário Holz, 351 América Joinville SC Brasil

268 APÊNDICE S 135

269 Relatório de Incidentes Final - Cópia Controlada Versão do Documento: 1.0 Sumário 1. Módulo Identificação da função Descrição da atividade Incidentes identificados Descrição dos incidentes Observações e comentários Módulo GED 2. Identificação da função Função Descrição da atividade A atividade de teste realizada sobre a função de Cópia controlada teve o intuito de testar a realização das cópias controladas para serem impressas, verificando e o arquivo é convertivo para pdf corretamente e se no final das páginas aparecem dados como o nome do destinatário data da cópia,etc. 4. Incidentes identificados Rua Expedicionário Holz, 351 América Joinville SC Brasil

270 Ação Executada Erro Tester Data Ambiente Status Grau da Ocorrência Adcionar o botão Lista de Cópias verificar figura 1 Na lista de documentos a serem copiados botões OK e VOLTAR ver figura 2 01 Rachel 31/01/08 William Avaliar Sugestão 02 Rachel 31/01/08 William Avaliar Sugestão Data da cópia ver figura 3 03 Rachel 31/01/08 William Avaliar Ocorrência Impossibilidade de conversão de arquivos.tiff,.doc, html Botão Imprimir Cópias Controladas, ir direto para a lista de documentos a serem copiados Imformações fora de formatação 04 Rachel 31/01/08 William Avaliar Ocorrência 05 Rachel 31/01/08 William Avaliar Sugestão 06 Rachel 31/01/08 William Avaliar Ocorrência Botão default OK 07 Rachel 31/01/08 William Avaliar Sugestão Escolha de um destinatário errado - mensagem de erro (aviso) antes de fechar a janela de destinatário Feedback do porquê de não ter sido copiado 08 Rachel 31/01/08 William Avaliar Sugestão 09 Rachel 31/01/08 William Avaliar Sugestão Rua Expedicionário Holz, 351 América Joinville SC Brasil

271 5. Descrição dos incidentes Erro Descrição Tester Descrição do Acerto - Desenvolvimento 01 Para que a lista de cópias controladas não apareça ao clicar em Impressão de cópias controladas, poderia ser inserido um botão Lista de cópias de forma que a lista da cópia só seja vista clicando no mesmo e fazendo com que o botão Impressão de cópia controlada sirva apenas para chegar aos documentos escolhidos para serem copiados. Isto pode ser verificado na figura Na lista de documentos a serem copiados os botões OK e VOLTAR encontram-se muito abaixo com baixa visualização. Figura A data da cópia é um dos dados essenciais para a cópia controlada. Sendo assim é necessário que a mesma esteja em Português. Figura A conversão de arquivos.tiff,.doc, html não foram efetivadas. Dúvidas: o problema seria demora para converter ou realmente a tentativa de conversão não foi efetivada? 05 Sugere-se que ao clicar em Imprimir copia controlada, o usuário chegue à tela com a lista dos arquivos que podem ser impressos. Rachel Rachel Rachel Rachel Rachel 06 Os dados da cópia estão fora de formatação Rachel 07 Sugere-se que o botão OK esteja Default Rachel Rua Expedicionário Holz, 351 América Joinville SC Brasil

272 Erro Descrição Tester Descrição do Acerto - Desenvolvimento 08 Sugere-se que ao se escolher um destinatário errado, apareça uma mensagem de erro antes que a janela de Destinatário seja fechada. 09 Caso o problema na conversão seja de lentidão, vê-se necessário manter o usuário informado mostrando uma mensagem na qual é informada o porquê de não estar sendo copiado o arquivo para pdf. O problema que acontece quando está sendo convertido um arquivo que não seja pdf ou jgp é mostrado na figura 5 e na figura 6. Rachel Rachel Figura 1: Novo Botão para a lista de Cópias controladas já realizadas Rua Expedicionário Holz, 351 América Joinville SC Brasil

273 Figura 2: Botões muito abaixo da visualização Figura 3: Data escrita em Inglês. Rua Expedicionário Holz, 351 América Joinville SC Brasil

274 Figura 4: Dados cortados, incompletos. Figura 5: Conversão de arquivo.doc. Rua Expedicionário Holz, 351 América Joinville SC Brasil

275 Figura 6: Demora na conversão ou não efetivação desta ação. 6. Observações e comentários Grau de Ocorrência : Prioritário e Não Prioritário 09 incidentes 03 ocorrências 06 sugestões Rua Expedicionário Holz, 351 América Joinville SC Brasil

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

Padrões de Qualidade de Software e Métricas de Software

Padrões de Qualidade de Software e Métricas de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

QUALIDADE DE SOFTWARE AULA N.7

QUALIDADE DE SOFTWARE AULA N.7 QUALIDADE DE SOFTWARE AULA N.7 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 CMM: DEFINIÇÃO Capability Maturity Model Um modelo que descreve como as práticas

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

Estudo do CMM e do CMMI

Estudo do CMM e do CMMI Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos

Leia mais

Qualidade de Software

Qualidade de Software Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br A expressão ISO 9000 (International Organization for Standardization) designa um grupo de normas técnicas que estabelecem

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Qualidade de Software. Anderson Belgamo

Qualidade de Software. Anderson Belgamo Qualidade de Software Anderson Belgamo Qualidade de Software Software Processo Produto Processo de Software Pessoas com habilidades, treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

Fatores humanos de qualidade CMM E CMMI

Fatores humanos de qualidade CMM E CMMI Fatores humanos de qualidade CMM E CMMI Eneida Rios¹ ¹http://www.ifbaiano.edu.br eneidarios@eafcatu.gov.br Campus Catu 1 Curso de Análise e Desenvolvimento de Sistemas Conteúdos Fatores humanos de qualidade

Leia mais

CAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi

CAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi CAPABILITY MATURITY MODEL INTEGRATION Prof. Késsia R. C. Marchi Modelos de maturidade Um modelo de maturidade é um conjunto estruturado de elementos que descrevem características de processos efetivos.

Leia mais

Qualidade do Processo de Software

Qualidade do Processo de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Qualidade do Processo de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Tópicos Especiais

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE 1 VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE Elvis Ferreira da Silva* Msc. Marta Alves de Souza** Msc. Helder

Leia mais

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

Leia mais

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

Leia mais

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto Gerais Processo Produto Propostas NBR ISO 9000:2005 define principios e vocabulário NBR ISO 9001:2000 define exigências para sistema de gerência de qualidade NBR ISO 9004:2000 apresenta linha diretivas

Leia mais

Introdução CMMI. Qualidade e Teste de Software CMMI 1

Introdução CMMI. Qualidade e Teste de Software CMMI 1 Introdução CMMI O propósito da qualidade é estabelecer um diferencial competitivo, através de contribuições como redução de defeitos, redução de custos, redução de retrabalho e aumento da produtividade,

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Delfraro Rodrigues Douglas M Gandini José Luiz CMM. Capability Maturity Model

Delfraro Rodrigues Douglas M Gandini José Luiz CMM. Capability Maturity Model Delfraro Rodrigues Douglas M Gandini José Luiz CMM Capability Maturity Model O que é o CMM? Modelo para avaliação da maturidade dos processos de software de uma organização Identificação das práticas chave

Leia mais

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1 Qualidade Plácido A. S. Neto 1 1 Gerência Educacional de Tecnologia da Informação Centro Federal de Educação Tecnologia do Rio Grande do Norte 2006.1 - Planejamento e Gerência de Projetos Agenda Introdução

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

MODELO CMM MATURIDADE DE SOFTWARE MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software Introdução Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. Tem-se

Leia mais

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI)

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) 1 MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) Teresinha Moreira de Magalhães 1 Lúcia Helena de Magalhães 2 Fernando Machado da Rocha 3 Resumo Este trabalho visa apresentar uma

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e

MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e fortes, que serão utilizados para a criação de um plano

Leia mais

Introdução a CMMI. Paulo Ricardo Motta Gomes Renato Miceli Costa Ribeiro

Introdução a CMMI. Paulo Ricardo Motta Gomes Renato Miceli Costa Ribeiro Introdução a CMMI Paulo Ricardo Motta Gomes Renato Miceli Costa Ribeiro Campina Grande, 29 de setembro de 2008 Agenda Processos Motivação Sintomas de falha de processo Aprimoramento de Processos O Framework

Leia mais

Normas e Padrões de Qualidade em Software - I

Normas e Padrões de Qualidade em Software - I Tema da Aula Normas e Padrões de Qualidade em - I Prof. Cristiano R R Portella portella@widesoft.com.br Certificação da Qualidade Certificações emitidas por entidades públicas conceituadas: 9 ABIC Selo

Leia mais

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade IV QUALIDADE DE SOFTWARE introdução As mudanças que estão ocorrendo nos clientes e nos ambientes de negócios altamente competitivos têm motivado as empresas a modificarem

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Roteiro Qualidade de Software Produto de Software Processo de Software Modelo de Qualidade CMM Qualidade Qualidade de Software Na visão popular: Luxo Mais caro, complexo = maior

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE MODULO 3 SISTEMA DE GARANTIA DA QUALIDADE CONTEÚDO 3.1 A ABORDAGEM NBR ISO 9000 3.2 MODELOS DE QUALIDADE DE PRODUTO DE SOFTWARE 3.2.1 NBR ISO/IEC 9126 (SOFTWARE) 3.2.2 NBR ISO/IEC

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

Qualidade de Software. Aécio Costa

Qualidade de Software. Aécio Costa de Software Aécio Costa A Engenharia pode ser vista como uma confluência de práticas artesanais, comerciais e científicas [SHA90]. Software sem qualidade Projetos de software difíceis de planejar e controlar;

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Engenharia de Software

Engenharia de Software UFES - Universidade Federal do Espírito Santo Engenharia de Software Notas de Aula E-mail: falbo@inf.ufes.br 2005 Capítulo 1 - Introdução UFES - Universidade Federal do Espírito Santo 1 Capítulo 1 Introdução

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC 12207 PROCESSOS DO CICLO DE VIDA DO SOFTWARE.

SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC 12207 PROCESSOS DO CICLO DE VIDA DO SOFTWARE. UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CUROS DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC 12207 PROCESSOS DO CICLO DE VIDA DO

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Análise da Maturidade de um Processo de Teste Orientado a Artefatos

Análise da Maturidade de um Processo de Teste Orientado a Artefatos Análise da Maturidade de um Processo de Teste Orientado a Artefatos Paulo M. S. Bueno 1*, Adalberto N. Crespo 1, Mario Jino 2 1 Divisão de Melhoria de Processo - CenPRA Rodovia Dom Pedro I, km 143,6 -

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC 15504

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC 15504 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC 15504 MARCELO NORTE DE OLIVEIRA 1 marcelonorte.ti@gmail.com IREMAR NUNES DE LIMA 2 iremar.prof@uol.com.br RESUMO: Este artigo trata

Leia mais

AS CARACTERÍSTICAS DO CMM E O DESENVOLVIMENTO DE SOFTWARE COM QUALIDADE

AS CARACTERÍSTICAS DO CMM E O DESENVOLVIMENTO DE SOFTWARE COM QUALIDADE REVISTA ELETRÔNICA DE ADMINISTRAÇÃO ISSN 1676-6822 PERIODICIDADE SEMESTRAL EDIÇÃO NÚMERO 8 JUNHO DE 2005 AS CARACTERÍSTICAS DO CMM E O DESENVOLVIMENTO DE SOFTWARE COM QUALIDADE Kleber ALMEIDA Docente da

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo QUALIDADE DE SOFTWARE - PROCESSO Introdução: desenvolvimento

Leia mais

Qualidade de software

Qualidade de software Qualidade de software É cada dia maior o número de empresas que buscam melhorias em seus processos de desenvolvimento de software. Além do aumento da produtividade e da diminuição do retrabalho, elas buscam

Leia mais

C.M.M. Capability Maturity Model Modelo de Maturidade da Capacidade

C.M.M. Capability Maturity Model Modelo de Maturidade da Capacidade UNISUL Universidade do Sul de Santa Catarina. Campus da Grande Florianópolis Pedra Branca. CIÊNCIA DA COMPUTAÇÃO ENGENHARIA DE SOFTWARE ALUNO: Volnei A. Caetano Palhoça 02 de Junho de 2000 C.M.M. Capability

Leia mais

Engenharia de Software Processo de Desenvolvimento de Software

Engenharia de Software Processo de Desenvolvimento de Software Engenharia de Software Processo de Desenvolvimento de Software Prof. Edison A. M. Morais prof@edison.eti.br http://www.edison.eti.br Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

Introdução à Qualidade de Software

Introdução à Qualidade de Software FACULDADE DOS GUARARAPES Introdução à Qualidade de Software www.romulocesar.com.br Prof. Rômulo César (romulodandrade@gmail.com) 1/41 Objetivo do Curso Apresentar os conceitos básicos sobre Qualidade de

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

Leia mais

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT Exercícios: Governança de TI Walter Cunha PRIMEIRA ATERIA (C) A-C-E-F-H (D) A-G-F-H (E) A-G-I PMoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

Melhorias de Processos de Engenharia de Software

Melhorias de Processos de Engenharia de Software Melhorias de Processos de Engenharia de Software CMMI 1 Profa. Reane Franco Goulart O que é CMMI? O Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processos que fornece às

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 04 ISOs / IEC 12207 15504 9001 9126 25000 Agenda Descrição sumária da ISOs afetas ao nosso curso de qualidade ISO/IEC 12207 ISO/IEC

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Capability Maturity Model Integration - CMMI

Capability Maturity Model Integration - CMMI Capability Maturity Model Integration - CMMI Para Desenvolvimento Versão 1.2 M.Sc. Roberto Couto Lima ÍNDICE 1. Definição ------------------------------------------------------------------------------------------------------------

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Gerência de Projetos CMMI & PMBOK

Gerência de Projetos CMMI & PMBOK Gerência de Projetos CMMI & PMBOK Uma abordagem voltada para a qualidade de processos e produtos Prof. Paulo Ricardo B. Betencourt pbetencourt@urisan.tche.br Adaptação do Original de: José Ignácio Jaeger

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3

Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3 Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3 Carlo Giovano Pires, Fabiana Marinho, Gabriela Telles, Márcia Sampaio Instituto Atlântico, Rua Chico Lemos, 946, 60822-780, Fortaleza -

Leia mais

Sistemas de Informação Empresarial

Sistemas de Informação Empresarial Sistemas de Informação Empresarial Governança de Tecnologia da Informação parte 2 Fonte: Mônica C. Rodrigues Padrões e Gestão de TI ISO,COBIT, ITIL 3 International Organization for Standardization d -

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais

Qualidade de Software

Qualidade de Software Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Qualidade de Software Desvendando um requisito essencial no processo de desenvolvimento

Leia mais

1.264 Aula 4. Processo do Software: CMM Linguagem de Modelagem Unificada (UML)

1.264 Aula 4. Processo do Software: CMM Linguagem de Modelagem Unificada (UML) 1.264 Aula 4 Processo do Software: CMM Linguagem de Modelagem Unificada (UML) Modelo de Maturidade de Capacidade para Software Desenvolvido pelo (SEI) Instituto de Engenharia de Software, Universidade

Leia mais

Unidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini

Unidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini Unidade VI GOVERNANÇA DE TI Profa. Gislaine Stachissini Capability Maturity Model Integration CMMI SW-CMM (Software Capability Maturity Model): prove informações para o aprimoramento de processos de desenvolvimento

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

Leia mais

21. Qualidade de Produto ou Qualidade de Processo de Software?

21. Qualidade de Produto ou Qualidade de Processo de Software? 21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento

Leia mais

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação

CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;

Leia mais

Visão Geral da Qualidade de Software

Visão Geral da Qualidade de Software Visão Geral da Qualidade de Software Glauber da Rocha Balthazar Faculdade Metodista Granbery (FMG) Bacharel em Sistemas de Informação Rua Batista de Oliveira, 1145-36010-532 - Juiz de Fora - MG glauber_rochab@yahoo.com.br

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software André Mesquita Rincon Instituto de Informática/Universidade Federal de Goiás (UFG) Goiânia GO Brasil Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas/Fundação

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software. As

Leia mais

NORMAS E PADRÕES DE QUALIDADE DE SOFTWARE NO SISTEMA DE INFORMAÇÃO

NORMAS E PADRÕES DE QUALIDADE DE SOFTWARE NO SISTEMA DE INFORMAÇÃO Tatiany Cristina Ferreira Soares NORMAS E PADRÕES DE QUALIDADE DE SOFTWARE NO SISTEMA DE INFORMAÇÃO Monografia apresentada à Universidade Presidente Antônio Carlos UNIPAC- Barbacena, como requisito para

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

ISO - 9126. Aécio Costa

ISO - 9126. Aécio Costa ISO - 9126 Aécio Costa A evolução da Qualidade do Produto Qualidade = funcionalidade Confiabilidade Realização de funções críticas Produto de qualidade = sem bugs Controle de qualidade Teste do produto

Leia mais

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE - 02 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software.

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais