PROJETO, IMPLEMENTAÇÃO E TESTE DE SOFTWARE

Transcrição

1 PROJETO, IMPLEMENTAÇÃO E TESTE DE SOFTWARE Professora Esp. Janaína Aparecida de Freitas GRADUAÇÃO Unicesumar

2 Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor de EAD Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância; FREITAS, Janaína Aparecida de. Projeto, Implementação e Teste de Software. Janaína Aparecida de Freitas. Maringá-Pr.: UniCesumar, p. Graduação - EaD. 1. Projeto. 2. Implementação. 3. Software 4. EaD. I. Título. Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB CDD - 22 ed CIP - NBR AACR/2 NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho Direção de Planejamento de Ensino Fabrício Lazilha Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira Direção de Polos Próprios James Prestes Direção de Desenvolvimento Dayane Almeida Direção de Relacionamento Alessandra Baron Head de Produção de Conteúdos Rodolfo Encinas de Encarnação Pinelli Gerência de Produção de Conteúdos Gabriel Araújo Supervisão do Núcleo de Produção de Materiais Nádila de Almeida Toledo Supervisão de Projetos Especiais Daniel F. Hey Coordenador de Conteúdo Fabiana De Lima Design Educacional Ana Salvadego Iconografia Amanda Peçanha dos Santos, Ana Carolina Martins Prado Projeto Gráfico Jaime de Marchi Junior, José Jhonny Coelho Arte Capa André Morais de Freitas Editoração Matheus Felipe Davi Qualidade Textual Hellyery Agda G. Silva Naiara Valenciano Pedro Barth Ilustração Marta Sayuri Kakitani

3 Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para liderança e solução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho. Cada um de nós tem uma grande responsabilidade: as escolhas que fizermos por nós e pelos nossos farão grande diferença no futuro. Com essa visão, o Centro Universitário Cesumar assume o compromisso de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros. No cumprimento de sua missão promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária, o Centro Universitário Cesumar busca a integração do ensino-pesquisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consciência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade. Diante disso, o Centro Universitário Cesumar almeja ser reconhecido como uma instituição universitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; consolidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação da comunidade interna; qualidade da gestão acadêmica e administrativa; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relacionamento permanente com os egressos, incentivando a educação continuada.

4

5 Diretoria de Planejamento de Ensino Diretoria Operacional de Ensino Seja bem-vindo(a), caro(a) acadêmico(a)! Você está iniciando um processo de transformação, pois quando investimos em nossa formação, seja ela pessoal ou profissional, nos transformamos e, consequentemente, transformamos também a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportunidades e/ou estabelecendo mudanças capazes de alcançar um nível de desenvolvimento compatível com os desafios que surgem no mundo contemporâneo. O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): Os homens se educam juntos, na transformação do mundo. Os materiais produzidos oferecem linguagem dialógica e encontram-se integrados à proposta pedagógica, contribuindo no processo educacional, complementando sua formação profissional, desenvolvendo competências e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inseri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo provocar uma aproximação entre você e o conteúdo, desta forma possibilita o desenvolvimento da autonomia em busca dos conhecimentos necessários para a sua formação pessoal e profissional. Portanto, nossa distância nesse processo de crescimento e construção do conhecimento deve ser apenas geográfica. Utilize os diversos recursos pedagógicos que o Centro Universitário Cesumar lhe possibilita. Ou seja, acesse regularmente o AVA Ambiente Virtual de Aprendizagem, interaja nos fóruns e enquetes, assista às aulas ao vivo e participe das discussões. Além disso, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendizagem, possibilitando-lhe trilhar com tranquilidade e segurança sua trajetória acadêmica.

6 AUTORA Professora Esp. Janaína Aparecida de Freitas Bacharel em Informática pela Universidade Estadual de Maringá (2010). Especialização em MBA em Teste de Software pela Universidade UNICEUMA, Brasil. (2012). Trabalhou na iniciativa privada, na área de Analise de Sistemas e Testes de Software. Têm experiência na área de Engenharia de Software com ênfase em Análise de Requisitos, Gestão de Projetos de Software, Métricas e Estimativas, Qualidade e Teste de Software. Atualmente cursando o Técnico em Qualidade no Senac-PR e Licenciatura em Letras - Português/Inglês na UniCesumar. Atualmente é Professora Mediadora dos cursos de graduação ADS Analise e Desenvolvimento de Sistemas e SI Sistemas para Internet na modalidade de ensino EAD pela UniCesumar (2015).

7 APRESENTAÇÃO PROJETO, IMPLEMENTAÇÃO E TESTE DE SOFTWARE SEJA BEM-VINDO(A)! Prezado(a) acadêmico(a)! Seja bem-vindo(a) à disciplina Projeto, Implementação e Teste de Software. Neste curso, iremos abordar as atividades existentes no processo de desenvolvimento de software, que são as atividades que envolvem o projeto, a implementação e o teste de software. As unidades do livro foram organizadas de forma contínua, ou seja, a unidade seguinte sempre está vinculada com a unidade anterior, portanto, é bom que você leia e entenda todo o conteúdo de uma unidade para passar para a próxima. Vamos iniciar na unidade I conhecendo os conceitos sobre as fases Projeto, Implementação e Teste de Software, com o objetivo de compreender a importância destes conceitos como partes do processo de desenvolvimento do software. Seguindo para a unidade II, vamos conhecer mais a fundo os conceitos que envolvem a fase do Projeto e compreender a sua importância e com isso entender como ele pode minimizar a distância entre o sistema e o mundo real. Vamos representar o software, fornecendo detalhes sobre o seu funcionamento, estruturas, interface e todos os componentes necessários para desenvolver um sistema. Fase em que deve ser conferido e verificado se os requisitos do cliente poderão ser atendidos. No projeto é onde geramos uma descrição detalhada informando tudo o que o software deverá fazer e como este irá se comportar, sempre levando em conta o que foi levantado na análise de requisitos junto ao cliente. Depois, na unidade II, na fase de implementação, que é o momento em que desenvolvemos o código, vamos ver que além de ser escrito, precisamos testá-lo e depurá-lo, assim como compilá-lo e, por fim, ter um produto executável por completo. Durante este processo, o ideal é que se utilize um controle de versões para acompanhar as diferentes mudanças do código durante o desenvolvimento. Na fase de Implementação, vamos detalhar os componentes previstos no projeto, descrevendo todos os componentes de código fonte e código binário, em nível de linguagem de programação ou de acordo com as tecnologias escolhidas no levantamento de requisitos. E por fim, nas unidades IV e V, vamos aprender que quando a empresa desenvolvedora de software busca por qualidade, ela percebe que é necessário investir pesado em testes de software e que existem vários tipos de testes no mercado para atender as suas necessidades, e que pode ser preciso implantar mais de um tipo ou investir em métricas de software para garantia da qualidade destes testes. Ganhando espaço na comunidade de software, as métricas de teste de software veem conquistando e sendo de grande importância para as empresas que buscam qualidade e eficiência em seus projetos. Espero que sua leitura seja agradável e que esse conteúdo possa contribuir para seu crescimento pessoal e profissional. Vamos começar nossos estudos? Boa leitura!

8

9 SUMÁRIO 09 UNIDADE I INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE 15 Introdução 16 Introdução ao Projeto, Implementação e Teste de Software 21 Projeto de Software 26 Implementação de Software 28 Teste de Software 32 Considerações Finais 40 Referências 41 Gabarito UNIDADE II PROJETO DE SOFTWARE 45 Introdução 46 A Fase de Projeto de Software 49 Conceitos Básicos de Projeto de Software 52 Qualidade do Projeto 54 Modelo do Projeto 55 Projeto da Arquitetura do Software 63 Projeto de Componentes 68 Projeto de Interface do Usuário 71 Modelos de Análise e Projeto de Interfaces

10 SUMÁRIO Projeto de Dados 80 Considerações Finais 88 Referências 89 Gabarito UNIDADE III IMPLEMENTAÇÃO DE SOFTWARE 93 Introdução 94 Implementação de Software 97 Atividades da Implementação de Software 100 Características da Implementação de Software 101 Estilo de Programação e Codificação 103 Comentários 106 Depuração 109 Asserções e Programação Defensiva 110 Otimização de Desempenho 112 Refatoração 114 Considerações Finais 123 Referências 124 Gabarito

11 SUMÁRIO 11 UNIDADE IV TESTE DE SOFTWARE 127 Introdução 128 Introdução ao Teste de Software 132 Conceitos Básicos de Teste de Software 135 Ciclo de Vida do Teste de Software 139 Técnicas de Teste de Software 145 Papéis e Cargos de Teste de Software 148 Ambiente de Teste 153 Considerações Finais 162 Referências 163 Gabarito UNIDADE V PROCESSO DE TESTE DE SOFTWARE 167 Introdução 168 Documentação de Teste de Software 178 Relatórios de Teste de Software 184 Validação e Verificação em Testes de Software 188 Ferramentas de Teste de Software

12 SUMÁRIO Métricas e Medição 204 Gerência de Risco em Teste de Software 213 Considerações Finais 221 Referências 222 Gabarito 223 Conclusão

13 Professora Esp. Janaína Aparecida de Freitas INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE UNIDADE I Objetivos de Aprendizagem Conceituar Projeto, Implementação e Teste de Software. Compreender a importância desses conceitos como áreas da Engenharia de Software. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: Introdução ao Projeto, Implementação e Teste de Software Projeto de Software Implementação de Software Teste de Software

14

15 15 INTRODUÇÃO Olá, aluno(a)! Começamos nossos estudos apresentando alguns conceitos já estudados e que fazem parte do processo de software. Mostrarei a você como ele é composto de atividades que são necessárias para o desenvolvimento de um sistema. No processo de software, existem vários modelos e com algumas atividades básicas, por exemplo: a análise de requisitos, o projeto, a implementação, os testes, a implantação e a manutenção. No nosso livro, vamos estudar apenas as atividades que envolvem o projeto, a implementação e o teste de software. Nesta primeira unidade, serão apresentados os conceitos sobre as fases (atividades ou etapas): Projeto, Implementação e Teste de Software, com o objetivo de compreender a importância desses conceitos como partes do processo de desenvolvimento do software. Na fase de Projeto é onde vamos representar o software, fornecendo detalhes sobre o seu funcionamento, estruturas, interface e todos os componentes necessários para desenvolver um sistema. Fase onde deve ser conferido e verificado se os requisitos do cliente poderão ser atendidos. No projeto é onde geramos uma descrição detalhada informando tudo o que o software deverá fazer e como este irá se comportar, sempre levando em conta o que foi levantado na análise de requisitos junto ao cliente. Após a fase de Projeto, passamos a fase de implementação, ou seja, a programação, a codificação do código e onde determinamos a linguagem que será usada para o desenvolvimento do sistema. Nesta fase, construímos o software baseado nas definições técnicas da fase de projeto e entramos na prática do desenvolvimento do sistema. Na fase de testes, passamos a validar o sistema que foi implementado. Nesta fase são testados os códigos à procura de defeitos, problemas que podem ocorrer na interface e outros que possam surgir quando o sistema é integrado. Assim, nosso objetivo nesta unidade é entender os conceitos das etapas que envolvem o processo de software e como são relacionadas. Vamos, portanto, aos conceitos! Boa leitura! Introdução

16 16 UNIDADE I shutterstock INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTE DE SOFTWARE Para compreendemos os conceitos de Projeto, Implementação e Teste de Software, é necessário que revisemos alguns conceitos do processo de software que já foram estudados. Vamos lá? Conforme Sommerville (2011, p. 42), um processo de software é considerado um conjunto de atividades, que pode levar a construção de um software, e embora existam processos diferentes, algumas atividades fundamentais são comuns a todos, como: Especificação de software: define a funcionalidade do software e as restrições sobre sua operação devem ser definidas. Projeto e Implementação de software: definem as funcionalidades para que o software atenda à especificação dada pelo cliente. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

17 17 Validação de software: o software deve ser validado para garantir que faça o que o cliente deseja. Evolução de software: o software deve evoluir para atender as necessidades mutáveis do cliente. No nosso livro vamos estudar apenas as atividades que envolvem o projeto, a implementação e o teste de software, momento em que o software é validado. Após os Requisitos de Software terem sido especificados e modelados, é iniciada a primeira fase, o Projeto, em que é definido como o software será construído, sua arquitetura, interfaces, componentes que poderão ser utilizados e outras características que podem ser determinantes para se gerar um software. Conforme Pressman (2011, p. 206), é na fase de requisitos que é convertido o que é para ser feito e detalhado e na fase de projeto é indicado o como deverá ser o desenvolvimento, fornecendo detalhes da arquitetura e os componentes essenciais para a implementação do sistema. O profissional responsável por essa fase é conhecido como o Arquiteto de Software, que possui experiência como programador e possui amplos conhecimentos sobre a Gerência de Projetos. Na segunda etapa, codificamos o sistema conforme o que foi definido na etapa de Projeto. Nesta fase, definimos a linguagem que será usada, ferramentas que poderão auxiliar, bibliotecas de classes para acelerar as tarefas, e ferramentas CASE, que podem ser usadas para agilizar a compreensão na hora de gerar os códigos e a documentação do software. O profissional responsável por essa etapa é o Programador ou Desenvolvedor, que precisa ter um bom raciocínio lógico e gostar de resolver problemas. Depois na terceira etapa, é o momento em que os Testes são executados. Nessa fase, fazemos a validação do comportamento de cada funcionalidade dos módulos do sistema. É nessa fase que verificamos o que foi definido na Análise de Requisitos e rastreamos os possíveis erros e falhas que possam ter ficado em alguma fase. Neste momento, os resultados dos testes executados são mostrados em relatórios, que mostram as informações sobre os erros encontrados e como o software está se comportando até o momento. O profissional responsável por essa fase é o Testador, que pode ser conhecido por outras denominações como: Gerente de Testes, Projetista de Testes, Analista de Testes, entre outros nomes. Introdução ao Projeto, Implementação e Teste de Software

18 18 UNIDADE I Assim, ao final da etapa de Testes, todos os módulos do sistema são relacionados e integrados dando origem ao produto de software, que deve ser mostrado ao usuário para que ele verifique se o sistema desenvolvido atende as suas necessidades. Na visão de Pressman, as atividades do processo de software: Para muitos projetos de software, as atividades metodológicas são aplicadas iterativamente conforme o projeto se desenvolve. Ou seja, comunicação, planejamento, modelagem, construção e emprego são aplicados repetidamente quantas forem as iterações do projeto, sendo que cada iteração produzirá um incremento de software. Este disponibilizará uma parte dos recursos e funcionalidades do software. A cada incremento, o software torna-se mais e mais completo. (PRESSMAN, 2011, p. 41). Para Sommerville (2011, p.124) o Projeto e Implementação de software é um estágio do processo no qual um sistema de software executável é desenvolvido. O Projeto de software é uma atividade criativa em que você identifica os componentes de software e seus relacionamentos com base nos requisitos do cliente. A Implementação é o processo de concretização do projeto como um programa. O Projeto e a Implementação estão intimamente ligados e, ao elaborar um projeto, você deve levar em consideração os problemas de implementação. E os testes de software? O teste mostra o que um programa faz e o que ele foi proposto a fazer e assim descobrir as falhas que o sistema tem antes do uso do cliente. Isso porque nessa fase testamos o que foi projetado e o que foi implementado. Vamos resumir as fases para que fique mais claro o que veremos nesta disciplina: Projeto: é esclarecido como o software será desenvolvido. Implementação: é definida a linguagem que será usada para programar (codificar) o sistema. Teste: o software é testado, levando em consideração o que foi levantado nos requisitos. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

19 19 Figura 1- Modelo Cascata Definição de requisitos Projeto de sistema e software Fonte: Sommerville, (2011). Implementação e teste de unidade Integração e teste de sistema Operação e manutenção Conforme Pressman (2011, p. 207), o Projeto de Software reside no núcleo técnico da engenharia de software sendo aplicado independentemente do modelo de processos de software utilizado, iniciando-se assim que os requisitos de software forem analisados e modelados sendo assim, o projeto é a última ação da engenharia de software da atividade de modelagem e prepara a cena para a fase de implementação (geração de código) e depois para os testes (validação). Introdução ao Projeto, Implementação e Teste de Software

20 20 UNIDADE I O Processo de Software Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho (work product). Uma atividade esforça-se para atingir um objetivo amplo (por exemplo, comunicação com os interessados) e é utilizada independentemente do campo de aplicação, do tamanho do projeto, da complexidade de esforços ou do grau de rigor com que a engenharia de software será aplicada. Uma ação envolve um conjunto de tarefas que resultam num artefato de software fundamental. Uma tarefa se concentra em um objetivo pequeno, porém, bem definido (por exemplo, realizar um teste de unidades) e produz um resultado tangível. No contexto da engenharia de software, um processo não é uma prescrição rígida de como desenvolver um software. A intenção é a de sempre entregar software dentro do prazo e com qualidade suficiente para satisfazer àqueles que patrocinaram sua criação e àqueles que irão utilizá-lo. Fonte: Pressman (2011). Todo engenheiro de software deve reconhecer que modificações são naturais. Não tente combatê-las. (Pressman). Agora, aluno(a), vamos entender um pouco mais sobre cada fase nesta unidade, e, depois, com mais detalhes nas unidades posteriores do livro. Começaremos conhecendo um pouco mais sobre a fase de Projeto de Software. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

21 21 shutterstock PROJETO DE SOFTWARE O conceito de Projeto de Software, conforme Pressman, é definido como: A atividade de projeto de software engloba o conjunto de princípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto com alta qualidade. Os princípios de projeto estabelecem uma filosofia que prevalece sobre as atitudes e ações do desenvolvimento, orientando as atividades para realizar o projeto. Os conceitos de projeto devem ser estabelecidos e entendidos antes de aplicar a prática de projeto, que deve levar à criação de várias representações do software que servem como um guia para a atividade de construção que se segue. (2011, p. 206). Por sua vez, Sommerville define Projeto de Software como: Um projeto de software é a descrição da estrutura de software a ser implementada, dos dados que são partes do sistema, das interfaces entre os componentes do sistema, e às vezes dos algoritmos usados. (2011, p. 50). Podemos citar outros conceitos de Projeto. Conforme a ABNT (Norma técnica NBR 10006), projeto é considerado um Processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos. O Projeto de Software faz parte dos processos da Engenharia de software, ele inicia logo após a Análise de Requisitos ter sido levantada, analisada e modelada. O projeto tem como objetivo definir uma estrutura que possa ser implementada em um produto de software e que atenda aos requisitos especificados para ele na análise. Na Análise de Requisitos é levantado o que será implementado, no Projeto de Software é definido como será construído. Projeto de Software

22 22 UNIDADE I O projeto de software é um processo que possui as seguintes atividades: estrutura de dados, arquitetural, componentes e interface. Cada um dos projetos citados acima, será detalhado na unidade II do livro. Conforme Pressman (2011, p. 206), o Projeto de Software cria uma representação fornecendo detalhes sobre a arquitetura do software, as estruturas de dados, interfaces e componentes fundamentais para implementar um sistema. Quando pensamos em projeto, devemos sempre ter em mente que quanto mais detalhado e refinado ele for, mas fácil e tranquila será a próxima fase de implementação. Portanto, é importante conhecer todas as tecnologias envolvidas em que o software será implantado e suas soluções, caso ocorram imprevistos. A qualidade do software pode ser avaliada nesta fase, pois o projeto serve de base para as demais fases no desenvolvimento de um sistema. Conforme Pressman (2011, p.116), os modelos de requisitos representam os requisitos dos clientes. Os modelos de projeto oferecem uma especificação concreta para a construção do software. Figura 2 - Transformando o modelo de requisitos no modelo de projeto. Elementos baseados em cenários Casos de uso - texto Diagramas de casos de uso Diagramas de atividades Diagramas de Raias Elementos baseados em classes Diagrama de classes Pacotes de análise Modelos CRC Diagramas de colaboração Diagramas de fluxo de dados Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento Modelos de análise Elementos comportamentais Diagramas de estados Diagramas de sequência Projeto de interface Projeto arquitetural Projeto de componentes Projeto de dados/classes Modelos de projeto Fonte: Pressman, (2011). INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

23 23 Segundo Pressman (2011, p. 178) o modelo de requisitos é usado para preencher a lacuna entre uma representação sistêmica que descreve o sistema (como o usuário imagina) como um todo ou a funcionalidade de negócio, e o modelo de projeto de software é usado para descrever a arquitetura da aplicação de software, a interface do usuário e a estrutura no nível de componentes. Figura 3 - A Fase do Projeto Domínio do problema Domínio da solução Mundo Real Mundo Computacional Análise e Especificação de Requisitos (o quê) Projeto (como) Implementação Fonte: Falbo, (2012). Seguindo a visão de Pressman sobre a fase de projeto, temos: O processo de projeto passa de uma visão macro do software para uma visão mais estreita que define os detalhes necessários para implementar um sistema. O processo começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos mecanismos de comunicação entre os subsistemas; são identificados componentes; e é desenvolvida uma descrição detalhada de cada componente. Além disso, são projetadas interfaces externas, internas e para o usuário. (PRESSMAN, 2011, p. 226). Projeto de Software

24 24 UNIDADE I Conforme Falbo (2012), o objetivo da fase de projeto é definir e especificar uma solução a ser implementada para um problema. Assim, podemos dizer que é uma fase em que tomamos muitas decisões, pois temos ao nosso alcance muitas soluções que podem ser possíveis. Ainda, segundo Falbo (2012), o projeto é um processo de refinamento. Assim, de maneira geral, Falbo (2012, p. 10) descreve que um projeto deve: Considerar abordagens alternativas com base nos requisitos do problema. Restrições e conceitos de projeto. Ser rastreável a sua especificação. Não reinventar a roda, isto é, reutilizar soluções. Exibir uniformidade (estilo) e integração (interfaces bem definidas entrecomponentes da coisa a ser construída). Ser estruturado para acomodar mudanças. Ser passível de avaliação da qualidade. Ser revisado para minimizar erros. Também, segundo Falbo (2012, p. 10) em geral, um modelo de projeto deve: Prover uma visão da totalidade do que deve ser construído. Decompor o todo em partes e prover diferentes visões. Refinar e descrever com mais detalhes cada parte ou visão do que deve ser construído, de modo a prover orientação para a construção de cada detalhe. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

25 25 Planejamento de projetos Uma coisa é exigir dos engenheiros de software estimativas de prazos, e cobrar o cumprimento dos prazos prometidos. Clientes e gerentes podem e devem fazê-lo. Outra coisa é pressioná-los para que façam promessas que não podem ser cumpridas. Uma frase comum desta cultura é: Não me interessa como você vai fazer, desde que entregue no prazo!. Na realidade, o cliente ou gerente deve, no seu próprio interesse, ter algum meio de checar se o cronograma e orçamento propostos são realistas; se preciso, recorrendo aos serviços uma terceira parte. A cultura do prazo político é ruim para todos. Para os desenvolvedores, ela significa estresse e má qualidade de vida. Para os gerentes, perda de credibilidade e prejuízos. E para os clientes, produtos de má qualidade e mais caros do que deveriam. Ainda por cima, entregues fora do prazo. Fonte: Paula Filho, (2009). Os princípios de projeto estabelecem uma filosofia que prevalece sobre as atitudes e ações do desenvolvimento, orientando as atividades para realizar o projeto. (Pressman). Projeto de Software

26 26 UNIDADE I shutterstock IMPLEMENTAÇÃO DE SOFTWARE Conforme Sommerville (2011, p. 25), a implementação de software é o processo de conversão de uma especificação do sistema em um sistema executável. A fase de implementação sempre começa quando a fase de projeto tiver sido encerrada. Na Implementação de Software serão detalhados os componentes que foram descritos na fase de projeto, como os códigos-fonte usados na linguagem de programação, lembrando que devem ser conforme as tecnologias que foram informadas. Na implementação é definida a linguagem de programação, que pode ser Java, C#, PHP, C++ ou qualquer outra, que possa desenvolver o que foi modelado na fase de projeto. O código é escrito por programadores e é importante que haja uma organização na escrita das instruções. Essa organização pode ser definida com a criação de padrões a serem seguidos pela equipe de programação. Exemplo de padrões que podem ser definidos: declaração de nomes de variáveis, formato de cabeçalhos, comentários dos códigos e como documentar o código. Nessa fase, construímos e codificamos os programas e os módulos que envolvem o software são integrados. Pressman (2011, p. 395) afirma que os problemas de confiabilidade de software podem quase sempre ser associados a defeitos de projeto ou de implementação. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

27 27 Ele afirma que todas as falhas que um software possui estão associadas aos problemas na fase de projeto e de implementação. Segundo o autor, as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o software. A fase de implementação é uma maneira de formalizar ou mostrar, utilizando uma linguagem de programação, das análises e os modelos levantados nas fases de requisito e de projeto, e gerando assim um sistema que possa executar as tarefas que foram descritas pelo usuário. Pressman afirma que podemos definir a implementação como sendo a fase de programação que transformará o projeto em um sistema com forma computacional mais palpável pelo usuário. Na fase de implementação, também podem ser iniciados alguns testes (fase que será vista posteriormente), por exemplo, os testes de depuração de erros que são executados durante a programação e podem ser executados pelos próprios programadores. É importante que nessa fase as versões do sistema que estão sendo implementadas sejam controladas e gerenciadas, para que se tenha um controle de tudo o que está sendo codificado e alterado. Questões importantes na implementação de software A implementação demanda grande parte do tempo no processo de desenvolvimento de um software, por ser uma das atividades mais trabalhosas e exigir grandes habilidades do profissional da área de informática. Assim, antes de se iniciar a etapa de implementação de um software, é necessário escolher o ambiente de programação e tratar outras questões que possam influenciar direta ou indiretamente no bom desempenho dessa atividade. Além da escolha do ambiente de programação, existem boas práticas a serem seguidas para facilitar, principalmente, a manutenção do software e, ainda, alguns problemas a serem solucionados relativos à documentação, às rotinas de teste, à integração da equipe de desenvolvimento e à composição de arquivos de configuração da aplicação. No caso de um ambiente orientado a objetos, outros problemas surgem, como, por exemplo, controle de instâncias e relacionamentos entre objetos e persistência de objetos. Fonte: Valentim, Dias e Pacheco (2008). Implementação de Software

28 28 UNIDADE I Quando seu cliente tiver uma necessidade legítima, mas sem a mínima ideia em relação a detalhes, faça um protótipo para uma primeira etapa. (Pressman). TESTE DE SOFTWARE Segundo Weber et al. (2001), a qualidade de software é determinada pela qualidade dos processos que são usados durante a fase de desenvolvimento do software. A qualidade de software é o resultado de atividades que foram realizadas no processo de desenvolvimento desse software. Quando se fala em qualidade de software, é necessário lembrar que o projeto do software, o processo de desenvolvimento e o produto final têm que ter qualidade também (REZENDE, 2005). O software tornou-se um componente importante e de sucesso para várias empresas desenvolvedoras, fazendo que haja uma crescente busca pela qualidade do seu produto final, o software (WEBER et al., 2001). Conforme Pressman (2011), a atividade de teste de software é uma garantia de qualidade de software e ela é a última fase que representa a revisão do que foi especificado nas fases de projeto e implementação. Conforme Sommerville (2011), os objetivos da fase de teste de software podem ser expressos, de forma mais clara por: Atividade de Teste: processo de executar um programa com a intenção de localizar um defeito/ erro. shutterstock Caso de teste bom: apresenta uma elevada probabilidade de revelar um defeito/erro ainda não descoberto. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

29 29 O objetivo de qualquer empresa de software é produzir software com qualidade, nos prazos estabelecidos e que obtenha a satisfação do cliente. Para isso, devemos produzir o software conforme os requisitos que foram levantados e implementá-los nos prazos estabelecidos e com um nível de defeitos aceitável, para a satisfação do cliente (PRESSMAN, 2011). Conforme Molinari (2003), o teste é uma atividade que deve ocorrer paralela ao desenvolvimento e conduzida nas diversas fases do processo de desenvolvimento de software. E, para isso, o teste deve ser planejado, controlado e supervisionado por profissionais experientes. A equipe de teste deve identificar e minimizar os erros no software e executar atividades em paralelo ao teste, como documentação e relatórios. Bastos (2006) aponta que quanto menos defeitos forem deixados no software nas fases iniciais, menos custos terá a sua manutenção depois do software estiver pronto. Sobre o teste, Pressman (2000, p. 78) afirma: O teste muitas vezes requer mais trabalho de projeto do que qualquer outra ação da engenharia de software. Se for feito casualmente, perde- -se tempo, fazem-se esforços desnecessários, e, ainda pior, erros passam sem ser detectados. Portanto, é razoável estabelecer uma estratégia sistemática para teste de software. De acordo com Molinari (2003), todo software que se destina ao público e/ou ao mercado deve sofrer um nível mínimo de teste. Assim, quanto maior o nível de complexidade do software, mais testes e técnicas de testes se tornam necessários para a obtenção da sua qualidade. Sem os testes, não se consegue garantir que o software irá se comportar conforme o esperado ou conforme as solicitações do cliente, e isso pode ser negativo para a empresa que o desenvolveu. Mas caso na empresa não se tenha uma análise de requisitos ou uma documentação do software detalhada, a equipe de desenvolvimento e a equipe de teste não saberão se o que está sendo construído é o que o cliente espera. Pensando nisso, Molinari (2003) destacou axiomas e conceitos que podem ser usados no processo de teste, e que em muitos casos são considerados como verdades no mundo dos testes. Podem ser listados como: Teste de Software

30 30 UNIDADE I Não é possível testar um programa completamente. Teste de software é um exercício baseado em risco. Teste não mostra que bugs não existem, mas sim, o contrário. Quanto mais bugs são encontrados, mais bugs poderão aparecer. Rios (2008, p.13) denuncia que os testadores querem destruir o software, nocauteando através da busca de falhas e indicando seus erros, pois conforme o autor, uma vez que se indicam os defeitos de um software, ele pode ser corrigido e com isso, se torna muito melhor. Conforme Rios e Moreira (2013, p.10), se não se podem descobrir todos os defeitos de um programa e em decorrência disso nunca se pode afirmar que ele está 100% correto, por que testar? Porque o propósito dos testes é descobrir e corrigir os problemas e, com isso melhorar a sua qualidade. O quanto se quer melhorar dependerá de quanto se deseja investir. O autor ainda acrescenta, que na prática, não se pode testar um programa por completo e garantir que ele ficará livre de bugs. É quase impossível testar todas as possibilidades de formas e alternativas de entrada de dados, bem como testar as diversas possibilidades e condições criadas pela lógica do programador (RIOS; MOREIRA, 2013, p. 10). Conforme Pressman (2011, p. 402), muitas estratégias de teste de software já foram propostas na literatura. Todas elas fornecem um modelo para o teste e todas têm [...] características genéricas, e elas são: Executar um teste eficaz, proceder revisões técnicas eficazes. Teste começa no nível de componente e progride em direção à integração do sistema. Diferentes técnicas de teste são apropriadas para diferentes abordagens. O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um grupo independente de teste. O teste e a depuração são atividades diferentes, mas a depuração deve ser associada com alguma estratégia de teste. INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

31 31 Para Pressman (2011), o teste dificilmente chega ao fim. O que acontece é uma transferência do desenvolvedor para o seu cliente, ou seja, toda vez que um cliente usa o sistema, um teste está sendo realizado. Os problemas de confiabilidade de software podem quase sempre ser associados a defeitos de projeto ou de implementação. (Pressman). O testador deve saber exatamente o seu nível de competência que é medido pela sua experiência e pelos cursos que fez. Não tente testar um software para o qual você não tenha o conhecimento técnico suficiente. Testar softwares embarcados não é a mesma coisa que testar softwares comerciais. A sua graduação como testador deve sempre dizer até onde você poderá chegar com o seu trabalho, logo não ultrapasse limites, pois nessas faixas é que poderão aparecer os seus maiores defeitos. Aquele testador que registra um defeito dando palpites técnicos sobre como o software deveria ser desenvolvido, com toda a certeza está ultrapassando os seus limites. Conheça a sua área de atuação e os limites que demarcam os seus conhecimentos daqueles inerentes aos do desenvolvedor. Fonte: Rios (2008). Teste de Software

32 32 UNIDADE I CONSIDERAÇÕES FINAIS Chegamos ao fim da nossa primeira unidade do livro. Nela discorremos sobre as fases que envolvem o processo de desenvolvimento do software e vimos também os conceitos voltados ao projeto, à implementação e o teste de software. Foram apresentados aspectos relativos ao projeto, mostrando a importância dela e como essa fase é fundamental para o desenvolvimento de um software. Um dos principais objetivos visto da fase de projeto, e que ela define como vai ser a arquitetura do software, tendo como base o que foi levantado na análise de requisitos. Ao longo da unidade, foram relacionados os conceitos de implementação, pois é nesta fase que o projeto se transformará em um sistema, em que os códigos de programação serão codificados baseados nas definições descritas na fase de projeto. A implementação faz uso de linguagens de programação, podendo ser visuais e orientadas a objeto, do que foi analisado na análise de requisitos e o que foi determinado na fase de projeto. Vimos os conceitos iniciais sobre qualidade, que está intimamente relacionada às atividades de teste. Também verificamos que sem os testes o software pode se comportar de maneira inesperada ou ainda não seguir o foi esperado ou analisado. Isso pode fazer com que o cliente ache que pagou por um produto que ele não solicitou, e tal fato pode ser negativo para a empresa que está desenvolvendo o sistema. Espero que, até aqui, já tenho colaborado com o seu entendimento do que é projeto, implementação e teste de software, já que estes são os nossos principais assuntos que serão discutidos durante o nosso estudo durante a disciplina. Nas próximas unidades do livro há informações mais detalhadas sobre cada uma das fases. Preparado(a)? Então, vamos continuar com a leitura! INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

33 33 1. Após os Requisitos de Software terem sido especificados e modelados, é iniciada a primeira fase, em que é definido como o software será construído, sua arquitetura, interfaces, componentes que poderão ser utilizados e outras características que podem ser determinante para se gerar um software. Qual o nome desta fase? 2. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F) a assertiva falsa sobre os processos de software. ( ) Projeto e Implementação de software: definem as funcionalidades para que o software atenda à especificação dada pelo cliente. ( ) É nesta fase que são testados os códigos à procura de mais requisitos, que possam causar problemas que podem ocorrer na interface e outros que possam surgir quando o sistema é integrado. ( ) A implementação de software é o processo de conversão de uma especificação do sistema em um sistema executável. ( ) O projeto de software é a última ação da engenharia de software da atividade de modelagem e prepara a cena para a fase de implementação (geração de código) e, depois, para os testes (validação). Assinale a opção com a sequência CORRETA. a. V, F, V, V. b. F, V, V, F. c. V, V, V, F. d. F, V, F, F. 3. Descreva os conceitos de projeto, implementação e testes de software. 4. A afirmação que diz que: todas as falhas que um software possui estão associadas aos problemas na fase de projeto e de implementação está correta? 5. O objetivo de qualquer empresa de software é produzir software com qualidade, nos prazos estabelecidos e que obtenha a satisfação do cliente. Estamos falando de: ( ) Projeto. ( ) Implementação. ( ) Programação. ( ) Teste. ( )Requisitos.

34 34 6. Assinale a alternativa correta que preenche sequencialmente as lacunas do texto. Na é esclarecido como o software será desenvolvido. Por sua vez, no é definida a linguagem que será usada para programar (codificar) o sistema. E no o software é testado, levando em consideração o que foi levantado nos requisitos. a. Implementação, teste, projeto. b. Teste, implementação, projeto. c. Projeto, teste, implementação. d. Projeto, implementação, teste. 7. Quais os profissionais responsáveis pelas fases: Projeto, Programação e Implementação de Software? 8. Qual das fases do processo de desenvolvimento de software, cria-se uma representação fornecendo detalhes sobre a arquitetura do software, as estruturas de dados, interfaces e componentes fundamentais para implementar um sistema?

35 35 SUPORTE A PADRÕES NO PROJETO DE SOFTWARE Alexandre Dantas, Gustavo Veronese Alexandre Correa, José Ricardo Xavier, Cláudia Werner 1 Introdução Fundamentalmente, o projeto de software envolve uma sistemática de decomposição da solução, a começar pela descrição em mais alto nível dos principais elementos do sistema e, em seguida, criando uma visão mais detalhada de como as características e funções deste sistema deverão estar integradas. Projetar software orientado a objetos é uma tarefa difícil, e projetar software orientado a objetos reutilizável e flexível é ainda mais difícil. Este trabalho apresenta mecanismos de suporte à representação, sugestão e identificação de conhecimentos obtidos a nível de projeto, no ambiente de desenvolvimento de software [...] 2 Representação do Conhecimento de Projeto Projetistas de sistemas de software vêm, ao longo dos anos, reconhecendo a importância de se representar e explorar o conhecimento obtido durante a construção de sistemas. Uma das formas consiste no reconhecimento e utilização de boas práticas, idéias e soluções já aplicadas em situações de sucesso e fracasso em projetos de software, como heurísticas de projeto, padrões e anti-padrões. 2.1 Heurísticas de Projeto Uma heurística de projeto é uma diretriz resultante de conhecimento e experiência que serve como um conselho para tomada de decisões de projeto, sendo de grande importância no sentido de guiar o projetista na elaboração de boas soluções ao longo do desenvolvimento. É importante notar que uma heurística não deve ser vista como uma regra inviolável que deva ser seguida em todas as circunstâncias. Possíveis violações a estas heurísticas devem ser consideradas como avisos ou indicadores de que alguma decisão de projeto pode ter sido tomada incorretamente. [...]

36 Padrões Podemos pensar em um padrão como a reutilização da essência de uma solução para determinados problemas similares. Sintetizando as definições encontradas na literatura, podemos dizer que um padrão resolve um problema recorrente, em um determinado contexto, fornecendo uma solução que comprovadamente funcione, além de informar os resultados e compromissos da sua aplicação, e subsídios para que seja possível adaptar esta solução a uma variante do problema. Ao contrário das heurísticas, os padrões disponíveis na literatura estão descritos de forma explícita e organizada. Embora existam várias formas de descrição de um padrão, de modo geral, a descrição de um padrão deve conter as seguintes informações: Nome do padrão, o problema, o contexto, a solução, as consequências, o uso conhecido e os padrões que são relacionados. Segundo Buschmann, quanto maior o número de padrões em um sistema de padrões, maior é a dificuldade de entendê-los e utilizá-los. [...] 2.3 Anti-Padrões Um anti-padrão pode resultar da falta de conhecimento de uma solução mais adequada, ou ainda da aplicação de um padrão (teoricamente, uma boa solução) no contexto incorreto. Os anti-padrões descrevem soluções Inadequadas para um problema que resulta em uma situação ruim, ou então descrevem como sair de uma situação ruim e chegar a uma boa solução. A presença de bons padrões em um sistema bem sucedido pode não ser suficiente. É preciso mostrar que estes padrões geralmente não ocorrem em sistemas mal sucedidos, e que determinadas construções inadequadas (anti-padrões) encontradas em sistemas mal sucedidos geralmente não estão presentes em sistemas bem sucedidos. [...] 3 Suporte a Padrões no Ambiente Odyssey A partir da representação do conhecimento de projeto através dos conceitos descritos na seção anterior, foi implementado um conjunto de mecanismos em um ambiente de desenvolvimento de software visando apoiar a utilização deste conhecimento durante o projeto de software orientado a objetos. Nesta seção, apresentamos detalhes sobre a implementação e funcionamento destes mecanismos. [...]

37 37 Instanciação de Padrões de Projeto O mecanismo de instanciação de padrões de projeto procura oferecer ao usuário projetista uma forma de replicar uma solução com base em um padrão identificado para uma situação adequada ao seu projeto em desenvolvimento. Para isso, o padrão, conforme representado no catálogo, é transportado para o diagrama de classes do projetista. Este transporte é caracterizado pela cópia da estrutura de classes e relacionamentos que correspondem ao padrão. [...] 3.3 Seleção de padrões arquiteturais Um dos aspectos críticos de se desenvolver software com ênfase arquitetural é a seleção de um estilo, ou padrão arquitetural [9]. Neste sentido, identificamos a oportunidade de apoiar a seleção de padrões arquiteturais utilizando uma abordagem orientada pela necessidade de se obter determinadas características de qualidade para o software a ser produzido. Estas características são baseadas na norma ISO/IEC O suporte a padrões do ambiente Odyssey oferece um mecanismo para realização de uma comparação entre os requisitos de qualidade arquiteturais identificados para a aplicação e os obtidos pela utilização de cada padrão catalogado, com a intenção de se chegar a um indicador de padrão que melhor represente uma solução para o atendimento aos requisitos esperados. [...] 3.4 Deteção de Padrões e Anti-Padrões O suporte a padrões do ambiente Odyssey fornece um mecanismo de detecção de construções boas, assim como ruins. O principal objetivo desta detecção é fornecer suporte para a reestruturação de sistemas orientados a objetos legados, e também para a avaliação de sistemas ainda em desenvolvimento. A detecção de construções típicas (padrões) permite que o projeto do sistema seja entendido em um nível maior de abstração, além de permitir uma avaliação sobre a utilização destes padrões no projeto. Fonte: Dantas et al., (2002).

38 MATERIAL COMPLEMENTAR Análise e Projeto de Sistemas Como analisar, planejar, desenvolver e implementar sistemas de informação Lucas Nogueira Padrão Editora: Viena Sinopse: Para que um software atinja seu objetivo final, são necessárias diversas etapas que são analisadas e discutidas neste livro. A análise e projeto de sistemas consiste em um extremo cuidado e infinito esmero para chegar a um sistema de qualidade. O livro Análise e Projeto de Sistemas Como analisar, planejar, desenvolver e implementar sistemas de informação foi escrito de forma clara e objetiva. Entre os tópicos abordados estão: a análise de sistemas, ciclo de vida, metodologia de desenvolvimento, diagramas, projeto e implementação, análise de requisitos do sistema, tipos de objetos e métodos, herança e polimorfismo, administração de banco de dados, modelagem de processamento de dados, redes e tecnologias de transmissão, sistemas distribuídos, engenharia de software e seus princípios, metodologias ágeis de desenvolvimento de softwares, testes de software e de validação, gerência de projetos PMBOK, gerência de projetos de TI. No final do livro ainda temos um capítulo com exercícios para treinar os conhecimentos adquiridos. Apresentação: Processo de Comunicação. Para saber mais sobre Processo de Comunicação, acesse o vídeo produzido pela prof a. Daniela Karine Ramos. Dicas valiosas sobre comunicação. Não perca! Em: < Acesso em: 20 de out

39 MATERIAL COMPLEMENTAR Apresentação: Atividades básicas ao processo de desenvolvimento de Software. Esse artigo demonstra as principais atividades básicas, comuns aos processos de desenvolvimento de software, seus conceitos relevantes, utilizados em organizações que buscam um padrão de qualidade no desenvolvimento de suas aplicações. Recomendo que tire um tempinho e leia as informações contidas neste link para complementar seus estudos. Acesse o site e leia o artigo na íntegra. Em: < Acesso em: 17 de maio 2016 Apresentação: Como trabalhar com testes de software? Nesse vídeo é dado algumas dicas do por que escolher a área de teste de software que pode ser uma boa escolha para começar a trabalhar na área de TI, ou mesmo como uma opção para buscar um nova oportunidade do mercado de trabalho, visando crescimento na carreira profissional. Em: < Acesso em: 20 de out Material Complementar

40 REFERÊNCIAS BASTOS, A. Base de Conhecimento em Teste de Software. Niterói: Traço & Photo, DANTAS, A. R., VERONESE, G.; CORREA, A.; XAVIER, J. R.; WERNER, C. Suporte a Padrões no Projeto de Software. Caderno de Ferramentas do XVI Simpósio Brasileiro de Engenharia de Software. Gramado, FALBO, R. de A. Projeto de Sistemas de Software: Notas de aula. Vitória: - Universidade Federal do Espírito Santo, 2012 MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São Paulo: Érica, PAULA FILHO, W. de P. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: Editora LTC, 2009 PRESSMAN, R. Engenharia de Software. 7. Ed. Porto Alegre: AMGH, REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de Janeiro: Editora Brasport, RIOS, E. Caratê Aplicado ao Teste de Software. Niterói: Imagem art Studio, RIOS, E.; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013 SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software Teoria e Prática. São Paulo: Prentice Hall, VALENTIM, Lucio Gerônimo; DIAS, M. M.; SANTOS, R. C. S. P. Questões importantes na implementação de software. Revista Tecnológica. v. 17. Maringá: 2008, p Disponível em: < /ojs/index.php/ RevTecnol/article/download /7985/5161>. Acesso em: 25 mar

41 GABARITO Após o levantamento dos requisitos de software, é iniciada a fase de Projeto de software. 2. Alternativa A - V, F, V, V. 3. Projeto: a fase de Projeto de Software faz parte dos processos da Engenharia de software, tendo início após a Análise de Requisitos ter sido levantada e seu objetivo é definir uma estrutura que possa ser implementada em um produto de software e que atenda os requisitos especificados para ele na análise. Implementação: na fase de Implementação de Software são detalhados os componentes que foram descritos na fase de projeto, como os códigos fonte que serão usados na linguagem de programação. Teste: a fase de Teste de Software é uma atividade que deve ocorrer paralela ao desenvolvimento e conduzida nas diversas fases do processo de desenvolvimento de software. 4. Os grandes problemas de confiabilidade de software podem quase sempre ser associados a defeitos encontrados na fase de projeto ou de implementação, onde as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o software. 5. Teste. 6. D - Projeto, implementação, teste 7. Projeto: o profissional responsável é conhecido como o Arquiteto de Software, que possui experiência como programador e possui amplos conhecimentos sobre a Gerência de Projetos. Implementação: o profissional responsável por esta etapa é o Programador ou Desenvolvedor, com um bom raciocínio lógico, gosta de resolver problemas. Teste: o profissional responsável por esta fase é o Testador, que pode ser conhecido por outras variações como: Gerente de Testes, Projetista de Testes, Analista de Testes entre outros nomes. 8. Projeto de software.

42

43 Professora Esp. Janaína Aparecida de Freitas PROJETO DE SOFTWARE UNIDADE II Objetivos de Aprendizagem Compreender a importância do projeto de software, mostrando os artefatos que serão criados durante o seu desenvolvimento. Entender a importância do projeto e como ele pode minimizar a distância entre o sistema e o mundo real. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: A fase de Projeto de Software Conceitos básicos de Projeto Software Qualidade do Projeto Modelo do Projeto Projeto da Arquitetura do Software Projeto de Componentes Projeto de Interface de usuário Modelos de Análise e Projeto de Interfaces Projeto de Dados

44

45 45 INTRODUÇÃO Caro(a) aluno(a), na unidade anterior, foi introduzido o objetivo do nosso livro e as etapas que envolvem o processo de software e a forma com que se relacionam entre si. Descrevemos as etapas que vamos ver: o Projeto, a implementação e o teste de software. Nesta unidade, convido você a dar continuidade ao estudo destas etapas que envolvem o processo de software, nos aprofundando mais na etapa de Projeto. Vamos, portanto, conhecer mais a fundo os conceitos que envolvem o Projeto e compreender a sua importância e com isso entender como ele pode minimizar a distância entre o sistema e o mundo real. Você já parou para pensar como é importante a interface de qualquer sistema, pois são desenvolvidos para serem manuseados por pessoas? Na fase de Projeto, definimos como vai ser esta interface com o usuário, como serão dispostos os menus, as janelas, os ícones e todos os componentes que irão fazer parte do sistema a ser desenvolvido e suas funcionalidades. Também fazem parte desta fase, como será o comportamento do sistema, como serão apresentadas as informações de relatórios, comprovantes e tudo que envolve a impressão de informações ao usuário. Essa fase inicia após ter sido finalizado o levantamento de requisitos de software junto ao cliente. No Projeto definimos como o software será construído, como será desenvolvida a sua arquitetura, a interface com o usuário, componentes que poderão ser utilizados e outras características que podem ser determinante para se gerar um sistema. Esta fase de Projeto possui como objetivo essencial mostrar e definir uma solução possível a ser implementada com base no que foi levantado na análise de requisitos. Também nesta unidade, serão apresentados os principais aspectos relativos ao Projeto de software, algumas técnicas, modelos e tipos de projetos para que possamos chegar ao final das fases que envolvem um processo de software e com um sistema de qualidade. Vamos a fase de Projetos! Boa leitura! Introdução

46 46 UNIDADE II A FASE DE PROJETO DE SOFTWARE Conforme Pressman (2011), Projeto é lugar onde a criatividade está em alta, em que os requisitos do cliente e a sua necessidade de sistema se juntam para o desenvolvimento de um produto ou sistema. Ele afirma que o Projeto cria um modelo ou uma representação em que é definido o como fazer, fornecendo todos os detalhes sobre a arquitetura, a estrutura, a interface e os componentes essenciais para implementar o sistema. Na fase de Projeto, o principal objetivo é definir uma estrutura que possa ser implementada baseada no que foi descrito nos requisitos que foram levantados para o sistema junto ao cliente. Você saberia disser qual a diferença entre a análise e o Projeto? Na análise de requisitos, é modelado o domínio do problema e no Projeto é modelada a solução para o problema, mas ambos devem estar em sintonia, alinhados em um único fluxo, pois o objetivo dos dois é a solução final do problema, neste caso, como software que será desenvolvido. Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: software, hardware, infraestrutura de rede, a interface de usuário, formulários que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros programas específicos que possa vir a usar, quais bancos de dados e arquivos que serão necessários. Como vimos, na primeira unidade, quem realiza esta etapa é conhecido como o Arquiteto de Software, que possui experiência como programador e possui amplos conhecimentos sobre a Gerência de Projetos. Tal profissional deve compreender e dominar as tecnologias pertinentes, conhecer técnicas de modelagem e metodologias de desenvolvimento, entender as estratégias de negócios da instituição onde atua, além de conhecer produtos, processos e estratégias de concorrentes. shutterstock PROJETO DE SOFTWARE

47 47 Pressman (2011) afirma que o projeto é importante, pois ele permite que o sistema seja modelado ou o produto construído. Quando o sistema é modelado, ele pode ser avaliado para verificar a qualidade e com isso ser aperfeiçoado antes de passar para a fase de implementação, ou de testes a serem realizado, ou ainda, que os usuários finais apontam os erros. Conforme o autor, o projeto de software pode mudar ao longo de seu desenvolvimento, à medida que novos métodos, uma melhor análise e entendimento do problema ou ainda, surja uma nova solicitação do cliente. O projeto é considerado o núcleo técnico da Engenharia de Software e, com isso ele pode ser aplicado em qualquer modelo de processo que seja adotado pela empresa. Por ser iniciado após a análise de requisitos, o projeto é visto como a última atividade de modelagem, antes da geração do código, ou seja, ele deve ser bem modelado, para que a etapa de construção ocorra sem alterações (PRESMANN, 2011, p. 207). Na etapa de projeto, deve ser considerado como o sistema funcionará internamente, para que os requisitos do cliente possam ser atendidos. Para isso, esta etapa também é dividida em fases, ou melhor, caracterizada por um conjunto de projetos, que ocorrem paralelamente. Conforme Sommerville (2011, p. 110), a fase de projeto deve ter: Projeto da Arquitetura do Software: é a parte em que definimos os componentes estruturais e seus relacionamentos. Projeto de Dados: projeto que tem como objetivo definir a estrutura de dados para implementar o software. Projeto de Interfaces: nesta parte é descrito como será a comunicação dentro do sistema, com outros sistemas e com os usuários que iram utiliza-los. Projeto de Componentes: detalhamos os procedimentos dos componentes estruturais da arquitetura do software. A Fase de Projeto de Software

48 48 UNIDADE II Figura 1 - Modelo Geral do Projeto de Software. Especificação de requisitos Atividades de projeto Projeto de arquitetura Especificação abstrata Projeto de interface Projeto de componente Projeto de estrutura de dados Projeto de algoritmo Arquitetura de sistema Especificação de software Fonte: Sommerville (2011). Especificação de interface Produtos de projeto Especificação de componente Especificação de estrutura de dados Especificação de algoritmo Agora, aluno(a) vamos conhecer os importantes conceitos de projeto de software que envolve o desenvolvimento de sistemas. Ótima leitura. A importância do projeto de software pode ser definida em uma única palavra qualidade. Projeto é a etapa em que a qualidade é incorporada na engenharia de software. O projeto nos fornece representações de software que podem ser avaliadas em termos de qualidade. Projeto é a única maneira em que podemos traduzir precisamente os requisitos dos interessados em um produto ou sistema de software finalizado. O projeto de software serve como base para todas as atividades de apoio e da engenharia de software que seguem. Sem um projeto, corremos o risco de construir um sistema instável um sistema que falhará quando forem feitas pequenas alterações; um sistema que talvez seja difícil de ser testado; um sistema cuja qualidade não pode ser avaliada até uma fase avançada do processo de software, quando o tempo está se esgotando e muito dinheiro já foi gasto. Fonte: Pressman (2011). PROJETO DE SOFTWARE

49 49 O projeto de software sempre deve começar levando em consideração os dados a base para todos os demais elementos do projeto. (Pressman). CONCEITOS BÁSICOS DE PROJETO DE SOFTWARE Conhecer os conceitos básicos e fundamentais do projeto de software é essencial, para passar ao arquiteto de software uma base para ele saber qual o método de projeto pode ser aplicado no sistema. Nessa fase é importante que os conceitos sejam assimilados e entendidos, para que se possa projetar um projeto de software com características desejáveis. Conforme Pressman (2011, p. 212), os principais conceitos relacionados ao projeto de software são: Abstração: o projeto deve considerar uma solução para qualquer problema com vários níveis de abstração, começando com um nível de abstração mais alto (solução mais abrangente) e depois para níveis de abstração mais baixos (solução mais detalhada). E que os elementos de projeto sejam representados por suas características essenciais, e os detalhes desnecessários sejam descartados. shutterstock Refinamento: processo de elaboração definida em alto nível de abstração e depois vai descendo a níveis de abstração mais baixos. Abstração e refinamento se complementam, pois a abstração especifica os níveis mais altos e mais baixos e o refinamento ajuda a revelar os detalhes menores, conforme o projeto vai evoluindo. Modularidade: o projeto é dividido em módulos/componentes que são integrados para corresponder aos requisitos levantados. Possui algumas vantagens como a facilidade de entendimento, pois cada módulo pode ser estudado separadamente e com isso facilitar o desenvolvimento, uma vez que cada módulo pode ser projetado, implementado e testado separadamente, diminuindo os erros e facilitando a manutenção. Conceitos Básicos de Projeto de Software

50 50 UNIDADE II Padrões: fornece uma descrição ao arquiteto de software permitindo determinar qual o padrão a ser aplicado e quais podem ser reutilizados no sistema. Arquitetura: estrutura ou organização dos módulos/componentes do programa e como eles interagem. O conceito de arquitetura está amplamente ligado aos aspectos da estrutura hierárquica dos módulos e as estruturas de dados de um software. Hierarquia de Controle: é a representação da estrutura do software relacionando aos componentes. Aqui o objetivo não é apresentar os detalhes dos procedimentos e sim de estabelecer os relacionamentos entre os componentes de software, seus níveis de abstração e refinamentos. Encapsulamento: define e impõe restrições de acesso tanto a detalhes procedurais em um módulo quanto em qualquer estrutura de dados local usada pelo módulo. A interface que foi definida deve revelar o mínimo da sua estrutura interna e com isso reduzir os efeitos colaterais que possam vir a ocorrer. Estrutura de Dados: representam os relacionamentos lógicos, como estão organizados os métodos de acesso, as associações e as alternativas de processamento de informações, pois, à medida que o Projeto vai se aproximando da fase de Implementação, as representações vão se tornando cada vez mais importantes, já que as estruturas de dados exercem um grande impacto no projeto final. Procedimentos de Software: expressam os detalhes da operação de cada módulo/componente do software individualmente. Estes detalhes são: como a informação é processada, pontos de decisão, quais as sequências de evento, e que operações serão repetitivas. Ocultação de Informação: seu objetivo é propor uma maneira de decompor o problema, assim, obter módulos menores do software no desenvolvimento. Com isso, o Arquiteto de Software ganha um alto grau de independência entre os módulos, facilitando a sua modificação, quando necessário, e em consequência, a fase de testes. PROJETO DE SOFTWARE

51 51 No próximo tópico vamos conhecer a qualidade do Projeto de software e entender porque a qualidade é tão importante e porque começamos a introduzi-la nessa fase. Boa leitura. Um conjunto de conceitos fundamentais de projeto de software evoluiu ao longo da história da engenharia de software. Embora o grau de interesse em cada conceito tenha variado ao longo dos anos, cada um resistiu ao tempo. Esses conceitos fornecem ao projetista de software uma base a partir de qual métodos de projeto mais sofisticados podem ser aplicados. Ajudam- -nos a responder as seguintes questões: Quais critérios podem ser usados para particionar o software em componentes individuais? Como os detalhes de função ou estrutura de dados são separados de uma representação conceitual do software? Quais critérios uniformes definem a qualidade técnica de um projeto de software? Os conceitos fundamentais de projeto de software fornecem a organização necessária para estruturá-la e para fazer com que ele funcione corretamente. Fonte: Pressman (2011). Existe uma tendência de ir imediatamente até o último detalhe, pulando as etapas de refinamento. Isso induz a erros e omissões e torna o projeto muito mais difícil de ser revisado. Realize o refinamento gradual. (Pressman). Conceitos Básicos de Projeto de Software

52 52 UNIDADE II QUALIDADE DO PROJETO Você deve estar se perguntando por que o Projeto de Software é considerado uma das fases mais importantes do desenvolvimento de um software? Ele é considerado importante, porque é nele que iniciamos a etapa de qualidade e ele serve como base para as outras fases do processo. shutterstock Segundo Pressman (2011, p 358), a qualidade de software pode ser dividida em duas partes: Qualidade do Processo e Qualidade do Produto. Quando nos referimos à qualidade do produto, o foco maior está na qualidade dada ao produto final, que é feita por meio de avaliações no software acabado. Já a qualidade do processo do software concentra-se no modo como o software foi produzido ao longo do seu desenvolvimento e como é feita a sua manutenção. Segundo Weber et al. (2001), a qualidade de software é determinada pela qualidade dos processos que são usados durante a fase de desenvolvimento do software. Para Rezende (2005), a preocupação com a qualidade deve estar voltada para a melhoria do Processo que envolve o desenvolvimento do software. Se garantirmos, pois, a Qualidade do Processo, podemos também garantir a Qualidade do Software. Segundo Gimenes (1994), o processo de software pode ser definido como um conjunto de todas as atividades relacionadas ao desenvolvimento, controle, validação e manutenção de um software. Segundo Sommerville (2011), o resultado do processo é um produto que mostra a forma como o processo de desenvolvimento foi conduzido e ele define o processo de software como sendo um conjunto de atividades e resultados associados que produzem um produto de software. O termo Qualidade possui várias definições as quais variam de acordo com a abordagem utilizada. A seguir uma que é bastante utilizada na literatura: Conformidade com as especificações (CROSBY, 1990): Crosby sugere que o gerenciamento da qualidade deve ser feito desde o início do desenvolvimento, para tentar evitar defeitos e diminuir o retrabalho. No desenvolvimento de software, este conceito significa que devemos nos preocupar com a qualidade desde PROJETO DE SOFTWARE

53 53 o início do processo (levantamento de requisitos e a parte de modelagem), para reduzir os problemas nas fases finais (codificação e testes). Falamos muito em qualidade, mas o que é um software com qualidade? Como avaliamos a qualidade de um projeto? Conforme Pressman (2011, p. 209), para que o nosso Projeto obtenha qualidade, ele sugere características que nos ajudam na avaliação de um bom Projeto: O projeto deve implementar todas as especificações definidas nos requisitos. O projeto deve ser um guia legível para as próximas etapas do processo de software (implementação e teste). O projeto deve fornecer uma visão geral do software, como dados, possíveis funções e como ele deve se comportar. Essas características ajudam na avaliação e na obtenção de um projeto com qualidade. Mas o que é Qualidade de Projeto? Para Pressman (2011, p. 359), refere-se às características que os projetistas especificam para um produto. A qualidade dos materiais, as tolerâncias e as especificações de desempenho, todos são fatores que contribuem para a qualidade de um projeto. Quanto mais materiais de alta qualidade forem usados, tolerâncias mais rígidas e níveis de desempenho maiores forem especificados, a qualidade de projeto de um produto aumentará se o produto for fabricado de acordo com essas especificações. Quando se desenvolve um software, a qualidade de um projeto reúne tudo o que foi especificado no modelo de requisitos, suas funções e suas características e se o sistema resultante atende às necessidades e às metas especificadas. Nos próximos tópicos você vai conhecer os modelos de projeto, como se dividem e como funcionam. Continue a sua leitura! O clamor por maior qualidade de software começou realmente quando o software passou a se tornar cada vez mais integrado em todas as atividades de nossas vidas. (Pressman). Qualidade do Projeto

54 54 UNIDADE II PREMISSAS DA QUALIDADE Fazer acontecer: Qualidade requer comprometimento, particularmente vindo do topo do gerenciamento. Cooperação entre a equipe e o gerente deve ser fundamental para fazer acontecer. Zero-defeito: Muitas pessoas acreditam que existe o zero-defeito para serviços e produtos. Isso é irreal. O sensato é definir níveis aceitáveis de defeitos. Qualidade = alto custo: Qualidade é frequentemente associada a custo, significado de alta qualidade = alto custo. Falso. Isso causa uma confusão entre a qualidade do projeto e a qualidade de conformidade. Não posso testar o produto por que não tenho infraestrutura, e a infra-estrutura não permite o teste do produto. O que fazer?. Qualidade demanda especificação de requerimento e suficiente detalhamento deles. Padrões inibem a criatividade: O pessoal técnico acredita, em geral, que padrões inibem sua criatividade, e com isso padrões não são seguidos, entretanto, para a qualidade acontecer, padrões e procedimentos deve ser seguido. Fonte: Costa (2010). MODELO DO PROJETO Conforme Pressman (2011, p. 221), o Modelo de Projeto possui quatro elementos que são considerados os principais e mais importantes: arquitetura, dados, interfaces e componentes. Esse modelo pode ser dividido em duas dimensões: processo e abstração. A dimensão de processo vai mostrando uma evolução do projeto conforme as tarefas vão sendo executadas, e a dimensão de abstração, mostra o nível de detalhamento de cada elemento do modelo de análise e que vão sendo transformados e refinados no modelo de projeto, conforme ilustrado na figura 2: shutterstock PROJETO DE SOFTWARE

55 55 Figura 2- Dimensões do Modelo de Projeto Alto Modelo de análise Diagramas de classes Pacotes de análise Modelos CRC Diagramas de colaboração Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento Realização das classes de projeto Subsistemas Diagrama de colaboração Modelo de projeto Baixo Refinamentos para: Realizações das classes de projetos Subsistemas Diagramas de colaboração Elementros da arquitetura Fonte: Pressman (2011, p. 221). Casos de uso - texto Diagramas de casos de uso Diagramas de atividade Diagramas de raias Diagramas de colaboração Diagramas de estados Diagramas de sequência Projeto técnico da interface Projeto de navegação Projeto da interface gráfica do usuário Elementros da interface Diagramas de classes Pacotes de análise Modelos CRC Diagramas de colaboração Diagramas de fluxo de dados Diagramas de fluxo de controle Narrativas de processamento Diagramas de estados Diagramas de sequência Diagramas de componentes Classes de projeto Diagramas de atividade Diagramas de sequência Refinamentos para: Diagramas de componentes Classes de projetos Diagramas de atividades Diagramas de sequência Elementros de componentes Dimensão de Processo Requisitos: Restrições Interoperabilidade Metas e configurações Realizações das classes de projeto Subsistemas Diagramas de colaboração Diagramas de componentes Classes de projeto Diagramas de atividade Diagramas de sequência Diagramas de implantação Elementros de implantação Agora, vamos conhecer um pouco de alguns desses elementos que fazem parte do Modelo de Projeto. Aproveite(m) ao máximo cada informação sobre esses projetos. Boa leitura. PROJETO DA ARQUITETURA DO SOFTWARE Conforme Pressman (2011, p. 229), o projeto de arquitetura representa a estrutura de dados e os componentes de programa necessários para construir um sistema computacional. Quem realiza essa atividade é o arquiteto de sistemas, ele escolhe os estilos de arquitetura com base na análise de requisitos. Você deve estar ser perguntando, porque é importante fazer um projeto de arquitetura? Já pensou em construir uma casa sem uma planta dela? Você saberia por onde começar? Mas ao ver a planta de uma casa, você saberia, pois ela mostra a casa de um contexto geral, mais ampla, e com isso você pode imaginar Projeto da Arquitetura do Software

56 56 UNIDADE II como ela será. O projeto de arquitetura é isso, ele dá uma visão geral do sistema e lhe mostra se você entendeu o contexto do sistema e o que é para desenvolver, ou seja, você pode imaginar como ele será. O projeto arquitetural antecede a etapa de construção do software, ele determina as partes da implementação e como estas devem interagir e se relacionar. A arquitetura garante a unidade e a consistência entre as partes e a sua representação serve como guia para o projeto da implementação, teste e implantação do sistema. A arquitetura de software serve para modelar a estrutura de um sistema, por meio de dados e componentes que se relacionam entre si. Pressman (2011, p. 230) define que quando se considera a arquitetura, por exemplo, de um edifício, pensamos em vários atributos diferentes, desses os mais simples até os mais complexos. Mas a arquitetura envolve mais que isso, são vários componentes integrados para formar um todo, que satisfaça as necessidades expressas do cliente. A arquitetura é constituída por decisões, algumas grandes e outras pequenas, e a maioria precisa ser tomada no início do Projeto e podem ter impacto em outras fases do projeto que estão por vir. Conforme Sommerville (2011, p. 106), a arquitetura de software pode trabalhar com dois níveis de abstração que são: 1. Arquitetura em pequena escala em que a preocupação é com a maneira como um programa individual é decomposto em componentes. 2. Arquitetura em grande escala em que a preocupação é com a arquitetura de sistemas distribuídos complexos que incluem outros sistemas, programas e componentes. PROJETO DE SOFTWARE

57 57 Cada um de nós possui uma imagem mental daquilo que a palavra arquitetura significa. A implicação é que os diferentes interessados verão uma arquitetura sob diversos pontos de vista orientados por conjuntos de interesses distintos. Isso implica que uma descrição de arquitetura é, na verdade, um conjunto de artefatos que refletem diferentes visões do sistema. Por exemplo, o arquiteto de um importante conjunto comercial tem de trabalhar com uma série de interessados diferentes. O principal interesse do proprietário do conjunto comercial (um dos interessados) é garantir que ele seja esteticamente agradável e que forneça espaço e infraestrutura suficientes para garantir sua lucratividade. Consequentemente, o arquiteto tem de criar uma descrição usando visões de edifício que atendam os interesses do proprietário. A descrição de arquitetura de um sistema baseado em software deve apresentar características análogas àquelas citadas para o conjunto comercial. Fonte: Pressman (2011). VISÕES DE ARQUITETURA A arquitetura de software pode ser representada por visões de arquitetura, em que cada visão aborda um determinado conjunto de questões específicas dos que estão envolvidos no processo de desenvolvimento do sistema, como os usuários finais, os designers do projeto, gerentes de projeto, engenheiros de sistema etc. As visões de arquitetura são usadas para a tomada das principais decisões de design estrutural, pois mostram como a arquitetura de software é decomposta em componentes. Conforme Pressman (2011, p. 232) cada visão desenvolvida como parte da descrição arquitetural trata uma necessidade específica do interessado. Assim, as decisões que foram tomadas, podem mostrar uma visão sobre a estrutura do sistema e como ele foi adequado às necessidades dos interessados. Sommerville (2011, p. 109) define as principais visões de arquitetura: Projeto da Arquitetura do Software

58 58 UNIDADE II Visão de Casos de Uso: mostra os casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes ou riscos técnicos. É um subconjunto do modelo de casos de uso. Visão Lógica: mostra as classes de design mais importantes e sua organização em pacotes e subsistemas, e a organização desses pacotes e subsistemas em camadas. É um subconjunto do modelo de design. Visão de Implementação: mostra uma visão geral do modelo de implementação e sua organização em termos de módulos em pacotes e camadas. É um subconjunto do modelo de implementação. Além dessas visões, você pode incluir outras adicionais como: visão da interface do usuário, visão de segurança, visão de dados, e assim por diante. Para documentar estas visões de arquitetura, você pode usar o documento de arquitetura de software. O documento de arquitetura de software é usado para fornecer uma visão geral de arquitetura do sistema, podendo usar diversas visões de arquitetura para descrever diferentes aspectos do sistema. No próximo tópico vamos conhecer os padrões de arquitetura que são mais usados. Boa leitura! Os modelos de arquitetura de um sistema de software podem ser usados para focar a discussão sobre os requisitos de software ou de projeto. Como alternativa, podem ser usados para documentar um projeto para que este possa ser usado como base para um projeto e uma implementação mais detalhados e para a futura evolução do sistema. É impossível representar todas as informações relevantes sobre a arquitetura de um sistema em um único modelo de arquitetura, pois cada modelo mostra apenas uma visão ou perspectiva do sistema. Pode mostrar como um sistema é decomposto em módulos, como os processos de run-time interagem, ou as diferentes formas como são distribuídos os componentes do sistema através de uma rede. Tudo isso é útil em momentos diferentes. Portanto, para ambos, projeto e documentação, geralmente você precisa apresentar múltiplas visões da arquitetura de software. Fonte: Sommerville (2011). PROJETO DE SOFTWARE

59 59 A arquitetura de software deve modelar a estrutura de um sistema, bem como a maneira por meio da qual dados e componentes procedurais colaboram entre si. (Pressman). PADRÕES DE ARQUITETURA DO SOFTWARE Coloque em foco a representação de arquitetura que irão orientar todos os demais aspectos do projeto. Procure investir o tempo necessário para revisar cuidadosamente as documentações de arquitetura. Nesta fase, um erro poderá gerar um grande impacto negativo nas próximas fases do desenvolvimento do sistema. Quando descrevemos a arquitetura de um software precisamos apresentar as características desejadas pelo cliente. Com isso, os desenvolvedores querem uma orientação clara e precisa sobre shutterstock o projeto, e os clientes querem garantias de que esta arquitetura atenderá suas necessidades de negócios. Para Sommerville (2011, p. 108) cada sistema é único, quando o domínio da aplicação é o mesmo, frequentemente possuem arquiteturas semelhantes, pois refletem os conceitos principais. Assim, é interessante ao projetar uma arquitetura de sistema, decidir se o seu sistema vai ser uma aplicação com classes mais gerais e verificar o que tem em comum, e quais dessas você pode reusar. Mas você deve estar se perguntando: porque seria interessante reusar? A reutilização é um aspecto fundamental para o desenvolvimento de um sistema, principalmente na fase de projeto. Muitos sistemas que já foram desenvolvidos e estão em uso, são similares a sistema que estão sendo desenvolvidos e muita das informações já usadas podem ser reutilizadas para solucionar problemas recorrentes no projeto. Projeto da Arquitetura do Software

60 60 UNIDADE II A arquitetura de um software pode se basear em padrões ou estilos de arquitetura. Conforme Sommerville, (2011, p. 108) os padrões de arquitetura capturam a essência de uma arquitetura que tem sido usada em diferentes sistemas de software. Assim, ao definir uma arquitetura de um sistema, você deve analisar os padrões mais comuns, quais os seus pontos fortes e fracos e como eles podem ser usados, pois um padrão é uma solução que já foi testada e aprovada para um problema em comum. Pressman (2011, p. 235) define que o padrão de arquitetura ou estilo impõe muita transformação a um projeto de arquitetura de um sistema. Por sua vez, Sommerville (2011, p. 108) afirma que a ideia de padrões como uma forma de apresentar, compartilhar e reusar o conhecimento sobre sistemas de software é hoje amplamente usada. Contudo vamos pensar em um padrão de arquitetura somente em sistemas bem-sucedidos de sistemas desenvolvidos anteriormente. Afinal o que é um padrão? Um padrão é usado para descrever um problema que ocorreram repetidas vezes, e é usada uma solução para esse problema de forma que possamos reutilizar esta solução encontrada. Em outras palavras, eles são soluções para problemas que alguém algum dia teve, achou a solução aplicando um modelo que foi documentado e que agora você pode usar integralmente ou de acordo com a sua necessidade. O padrão mostra uma solução de arquitetura que ajuda a servir como base para o projeto da arquitetura. Conforme Sommerville (2011, p. 108) devemos pensar em padrão de arquitetura como uma descrição abstrata, que seja estilizada, com boas práticas experimentadas e que tenham sido testadas em diferentes sistemas e ambientes e, com isso, incluir informações de uso desse padrão, para saber se ele é adequado e quais os seus pontos fortes e fracos. A escolha do padrão arquitetural a ser usado deve estar associado ao tipo de sistema e seus requisitos não funcionais. Para ajudar na escolha podemos pensar em algumas perguntas: O sistema a ser desenvolvido é interativo? Ele vai possui muitas variações? Quais os requisitos não funcionais que podemos considerar importantes? E quanto a sua confiabilidade? E a sua adaptabilidade? Quando respondemos a estas perguntas, podemos perceber que na composição de padrões, temos padrões diferentes que levam o projeto a consequências diferentes, mesmo quando os padrões abordam problemas semelhantes que são PROJETO DE SOFTWARE

61 61 encontrados e em alguns padrões de projeto, sistemas complexos podem vir a possuir mais de um padrão arquitetural. Nos próximos tópicos, vamos conhecer brevemente alguns padrões comumente que são usados em diferentes tipos de sistemas. Entre os padrões de arquitetura comumente usados estão: modelo-visão-controlador, arquitetura em camadas, repositório, cliente-servidor e duto e filtro. Vamos aos padrões de arquitetura mais conhecidos: MVC (Modelo-Visão-Controlador): esse padrão é considerado a base do gerenciamento de interações para muitos dos sistemas que são baseados em Web. Na descrição deste padrão você pode incluir o nome do padrão, uma descrição breve, podendo ser um modelo gráfico associado, exemplos de tipos de sistema em que este padrão pode ser usado novamente, suas vantagens e desvantagens. Arquitetura em Camadas: este padrão de arquitetura é organizado em camadas separadas e em cada camada só depende dos recursos e serviços oferecidos pela camada que se encontra imediatamente abaixo dela. Esta arquitetura é considerada mutável e portável, pois enquanto ela não for alterada, a camada pode ser substituída por outra equivalente. Mas quando ela muda ou tem novos recursos adicionados, apenas a camada adjacente é afetada. Arquitetura de Repositório: esse padrão de arquitetura descreve como um conjunto de componentes que estão interagindo podem compartilhar seus dados. Normalmente, os sistemas organizam os seus dados em torno de um banco de dados ou repositório compartilhado. Assim, este padrão é adequado para as aplicações nas quais os dados são gerados por um componente e usados por outro. Um exemplo, um ambiente controlado por versões, que mantém o controle de todas as alterações do sistema e permite que seja feita a reversão para versões anteriores. Arquitetura Cliente-Servidor: esse padrão de arquitetura é organizado em um conjunto de serviços e servidores associados e clientes que acessam e usam os serviços. Normalmente este padrão é utilizado em arquiteturas de sistemas distribuídos. Arquitetura de Duto e filtro: esse padrão de arquitetura é um modelo de organização em tempo de execução de um sistema, com entradas e saídas de informações. Conforme Sommerville (2011, p. 114) os dados fluem de um para Projeto da Arquitetura do Software

62 62 UNIDADE II o outro e transformam-se enquanto se movem por meio da sequência. Assim, cada etapa desta transformação, é implementada como uma transformação. Caro(a)Aluno(a) foram apresentados alguns dos padrões de arquitetura e descritos brevemente alguns que são comumente usados, mas existem outros. Para obterem mais informações sobre os padrões de arquitetura recomendo que leiam o Saiba Mais. Boa leitura! Um padrão de arquitetura, assim como um estilo arquitetural, impõe transformação no projeto de arquitetura. Entretanto, padrão difere de estilo em alguns modos fundamentais: (1) o escopo de um padrão é menos abrangente, concentrando-se em um aspecto da arquitetura e não na arquitetura em sua totalidade; (2) um padrão impõe uma regra sobre a arquitetura, descrevendo como o software irá tratar algum aspecto de sua funcionalidade em termos de infraestrutura os padrões de arquitetura tendem a tratar questões comportamentais específicas no contexto da arquitetura (por exemplo, como as aplicações em tempo real tratam a sincronização ou as interrupções). Os padrões podem ser usados com um estilo de arquitetura para dar forma à estrutura global de um sistema. Um estilo arquitetural é uma transformação imposta no projeto do sistema inteiro. O objetivo é estabelecer uma estrutura para todos os componentes do sistema. Fonte: Pressman (2011). Depois do aprofundamento no Saiba Mais, vamos para o próximo tópico onde vamos conhecer o Projeto de componentes e seus conceitos. Bons estudos! Como projetista, trabalhe arduamente para derivar tanto as abstrações procedurais quanto a de dados que atendam ao problema em questão. Se elas puderem atender um domínio inteiro dos problemas, tanto melhor. (Pressman). PROJETO DE SOFTWARE

63 63 shutterstock PROJETO DE COMPONENTES Conforme Pressman (2011, p. 257) o projeto de componentes ocorre depois da primeira iteração do projeto de arquitetura tiver sido completa. Para ele, o conjunto completo de componentes de software é definido durante o projeto de arquitetura. O projeto de componentes procura detalhar as estruturas de dados, definir os algoritmos, as características da interface que serão usadas, os mecanismos de comunicação que serão alocados para cada um dos componentes do software. Quem realiza as atividades do projeto de componentes é o Engenheiro de Software. Você deve estar se perguntando: Qual a importância do projeto de componentes no desenvolvimento do software? Bem, nesta fase, ao analisar o projeto até aqui você já deve ser capaz de determinar se o software irá funcionar ou não, antes que ele seja implementado. Certo? Pois o projeto de componentes é usado para representar o software de uma forma que possamos revisar os detalhes, como as estruturas de dados definidas, as interfaces e se os algoritmos irão funcionar. A base do projeto de componentes é formada pelas representações de projeto de dados, de arquitetura e de interface. Uma dica interessante, é que normalmente é possível fazer uso de componentes de software reutilizáveis, ao invés Projeto de Componentes

64 64 UNIDADE II de implementar novos. O principal artefato utilizado durante o projeto de componentes são que cada componente, pode ser representado em notação gráfica, tabular ou baseado em texto. Para Pressman (2011, p. 258) não importa o tipo de mecanismo que será utilizado para representar o projeto de componentes, as estruturas de dados, as interfaces e os algoritmos definidos, pois eles devem atender a uma série de metas de projeto bem fundamentadas que vão auxiliam a evitar erros à medida que o projeto evolui. Mas o que é um componente de software? Conforme Gimenes e Huzita (2005) é uma unidade de software independente que encapsula, seu projeto e a implementação, oferecendo serviços, por meio de interfaces definidas, que serão usadas para o meio externo. Pressman (2011) define que um componente é um bloco construtivo modular para ser usado em software de computador e com relação à orientação a objetos, um componente é um conjunto de classes colaborativas. Um componente é considerado uma unidade independente que pode ser utilizado junto com outros componentes, formando um sistema mais complexo. No entanto o significado de componente vai depender do ponto de vista do responsável pelo projeto de componentes, o engenheiro de software. Mas qual seria este ponto de vista? Conforme Pressman (2011) temos três pontos de vistas que são utilizados. São eles: Visão Orientada a objetos: um componente é um conjunto de classes colaborativas ou podem ter um componente com uma única classe. Visão Tradicional: para essa visão, um componente é o elemento funcional de um programa que incorpora a lógica de processamento, as estruturas de dados e uma interface que habilita o componente para que os dados sejam fornecidos a ele. Visão relacionada com processos: um componente é utilizado a partir da reusabilidade, ou seja, que façamos o uso de componentes de software ou de padrões de projeto já existentes. PROJETO DE SOFTWARE

65 65 PROJETO DE COMPONENTES BASEADOS EM CLASSES Conforme Pressman (2011, p. 262) o projeto de componentes apoia-se nas informações desenvolvidas como parte do modelo de requisitos e representadas como parte do modelo de arquitetura. Assim, quando se desenvolve um projeto orientado a objetos, o projeto de componentes define a elaboração de classes específicas contidas no modelo de requisitos. Na atividade de construção do projeto, a descrição detalhada de atributos, operações e interfaces é um dos detalhes mais importantes. Para Pressman (2011, p. 262) temos alguns princípios básicos de projeto que são utilizados pelo projeto de componentes. São eles: Princípios do aberto-fechado (OCP): um componente deve permitir que ele seja estendido sem a necessidade de modificações internas no próprio componente. Princípio da substituição (LSP): este princípio exige que qualquer classe derivada de uma classe-base honre o contrato entre a classe-base e os componentes que a usam. Princípio da inversão de dependência (DIP): este princípio define que quanto mais um componente depender de outros componentes concretos, mais difícil será de estendê-lo depois. Princípio da segregação de interfaces (ISP): este princípio sugere que se crie uma interface específica para cada categoria de clientes. Princípio da equivalência de reuso de versões (REP): esse princípio sugere que quando se usa classes ou componentes tendo usado o reuso, existe um contrato estabelecido entre o desenvolvedor da entidade reutilizável e quem irá fazer uso dela. Princípio do fechamento comum (CCP): esse princípio sugere que as classes que são alteradas juntas, devem permanecer juntas. Princípio comum da reutilização (CRP): esse princípio sugere que as classes que não são reutilizadas juntas não devem ser incluídas em um pacote. Projeto de Componentes

66 66 UNIDADE II CONDUÇÃO DE PROJETO DE COMPONENTES As etapas que veremos a seguir representam um conjunto de tarefas para um projeto de componentes orientado a objetos. Etapa 1 Identificar todas as classes de projeto correspondentes ao domínio do problema. Etapa 2 Identificar todas as classes de projeto correspondentes ao domínio de infraestrutura. Etapa 3 Elaborar todas as classes de projeto que não são obtidas como componentes reutilizáveis. Devemos especificar detalhes de mensagens e componentes que colaboram entre si, interfaces para cada componente, atributos e tipos de dados e o fluxo de processamento contido em cada operação. Etapa 4 Descrever fontes de dados persistentes (bancos de dados e arquivos) e identificar as classes necessárias para gerenciá-los. Etapa 5 Desenvolver e elaborar representações comportamentais para uma classe ou componente. Etapa 6 Elaborar diagramas de implantação para fornecer detalhes de implementação adicionais. Etapa 7 Refatorar toda representação de projetos de componentes e sempre considerar alternativas. Conforme Pressman (2011, p. 274), não se deve ter uma visão restrita. Sempre há soluções alternativas de projeto, e os melhores projetistas consideram (ou quase todas) elas antes de se decidirem pelo modelo de projeto final. Assim, procure desenvolver alternativas e analise cuidadosamente cada uma delas, usando os princípios e as etapas para o desenvolvimento do seu projeto. No próximo tópico conheceremos o Projeto de Interface do usuário e seus conceitos. Boa leitura! Vamos seguir em frente? PROJETO DE SOFTWARE

67 67 Projetar componentes para reutilização requer mais que um bom projeto técnico. Essa atividade também requer mecanismos de controle de configuração efetivos. (Pressman). O projeto de componentes ocorre depois da primeira iteração do projeto de arquitetura tiver sido completa. Neste estágio, a estrutura geral dos dados e programas do software já foi estabelecida. O intuito é traduzir o modelo de projeto em software operacional. Porém, o nível de abstração do modelo de projetos existente é relativamente alto e o nível de abstração do programa operacional é baixo. A tradução pode ser desafiadora, é uma porta aberta para a introdução de erros sutis difíceis de detectar e corrigir em estágios posteriores do processo de software. Os componentes preenchem a arquitetura de software e, como consequência, desempenham um papel para alcançar os objetivos e requisitos do sistema a ser construído. Pelo fato de os componentes residirem na arquitetura de software, devem se comunicar e colaborar com outros componentes e entidades (por exemplo, outros sistemas, dispositivos, pessoas) existentes fora dos limites do software. Fonte: Pressman (2011). Projeto de Interface do Usuário

68 68 UNIDADE II shutterstock PROJETO DE INTERFACE DO USUÁRIO O projeto de interfaces é usado para descrever como um software se comunica com outros sistemas e como as pessoas o utilizam. Conforme Pressman (2011, p. 287) o projeto de interface do usuário cria um meio de comunicação efetiva entre o ser humano e o computador. Quem realiza o projeto de interface com o usuário é o Engenheiro de Software. Mas porque ele é importante? Imagine um software que seja difícil de ser utilizado, com erros aparecendo a todo o momento, lento e Você não vai gostar certo? Independente de ele ser complexo e possuir um poder computacional grande. Por isso o projeto de interface do usuário precisa ser de fácil percepção e correto, sem erros que possam deixar o usuário inseguro. O projeto de interface deve iniciar pela identificação do usuário, das tarefas e do ambiente que são informações levantadas na análise de requisitos. Devemos nos perguntar: quem é o usuário? Como ele aprende a interagir com um novo sistema? Como ele interpreta uma informação produzida pelo sistema? O que ele espera do sistema? A partir dessas informações, os cenários são criados e passam a ser analisados para definir como serão os objetos e as ações que a interface irá desempenhar. Portanto, é muito importante que você conheça os usuários e as suas tarefas. PROJETO DE SOFTWARE

69 69 Os cenários tem papel fundamental no projeto de interface do usuário, pois eles são a base para a criação do layout da tela que irá representar graficamente o projeto, como ícones a serem utilizados, botões, textos descritivos, títulos de janelas e menus. Os artefatos usados nesta fase são: a criação dos cenários de usuários, são gerados layouts de tela e desenvolvidos protótipos de interface de forma interativa. Os mecanismos que são utilizados para as interações são chamados de interface gráfica do usuário (graphical user interface GUI). Pressman cita as regras de ouro que foram publicadas sobre projeto de interfaces de Theo Mandel (apud Pressman 2011, p. 288), em que: 1. O usuário deve estar no comando. 2. Procure reduzir a carga de memória do usuário. 3. Procure tornar a interface do sistema mais consistente. Para o autor, as regras descritas acima são a base que formam o conjunto de princípios que devem ser usados para orientar o projeto de interface de usuário durante o desenvolvimento do sistema na fase de projeto do software. Agora vamos entender um pouquinho cada uma dessas regras de ouro: Deixar o usuário no comando: procure escutar o que o cliente deseja como ele quer que o sistema reaja as suas necessidades e concretize as suas tarefas. Pense que o cliente quer controlar o sistema. Reduzir a carga de memória do usuário: procure criar uma interface ao usuário bem desenhada e que não cause esgotamento à memória do usuário, pois quanto mais o usuário lembrar, mas sujeito a erros será a interação com o sistema. Tornar a interface consistente: procure apresentar uma interface com informações de forma consistente, como: informações visuais organizadas de acordo com regras de projeto, mecanismos de entrada restritos, mecanismos de navegação bem definidos e padronizados, entre outros. Normalmente, os usuários julgam um sistema pela sua interface ao invés de suas funcionalidades e um projeto de interface pobre é uma das razões que podem levam muitos sistemas de software a nunca serem utilizados. Perceberam como é importante a interface do sistema com o usuário? É a parte fundamental de um software, pois ela fica visível para o usuário e com ela, Projeto de Interface do Usuário

70 70 UNIDADE II se comunica para realizar suas tarefas. Muitos de vocês, usuários de computador já encontraram muitas interfaces difíceis de usar, de entender e assimilar? No entanto em muitas situações, fomos obrigados a usá-las porque não temos outras opções. Por isso, quando for planejar uma interface de boa qualidade, lembre-se: considere o fator humano, procure entender o usuário e, seu comportamento e seu nível de habilidade. Os usuários podem ser classificados como: Novatos: nenhum conhecimento sintático do sistema e pouco conhecimento semântico da aplicação ou uso do computador em geral. Usuários intermitentes e com conhecimento: razoável conhecimento semântico da aplicação, mas lembrança relativamente baixa das informações sintáticas necessárias para usar a interface. Usuários frequentes e com conhecimento: bom conhecimento semântico e sintático que muitas vezes levam à síndrome do usuário poderoso. Por exemplo, se fosse perguntado ao usuário de determinado processador de texto para descrever sua operação, a percepção do sistema orientaria a resposta. A precisão da descrição irá depender do perfil do usuário (por exemplo, novatos dariam no máximo uma resposta muito superficial). Um usuário que entenda completamente de processadores de texto é capaz de dar uma descrição mais completa de sua função do que o novato que investiu semanas tentando aprender o sistema. (Pressman). PROJETO DE SOFTWARE

71 71 Até mesmo um usuário novato quer atalhos; mesmo usuários frequentes e com conhecimentos algumas vezes precisam de orientação. Dê a eles aquilo de que precisam. (Pressman). MODELOS DE ANÁLISE E PROJETO DE INTERFACES Conforme Pressman (2011, p. 291), temos quatro modelos distintos ao se analisar e projetar uma interface do usuário, os quais são: Modelo de Usuário: é estabelecido o perfil dos usuários do sistema. Aqui devemos classificar os usuários em: novatos (nenhum conhecimento do sistema), usuários intermitentes (razoável conhecimento) e usuários frequentes (bom conhecimento e são indivíduos que procuram atalhos e modos de interação abreviados). Modelo de Projeto: um modelo do projeto de interface é criado. Modelo Mental: nesse modelo se molda como o usuário percebe a interface e se ela atende às suas necessidades. Modelo de Implementação: onde a aparência e a percepção da interface, juntamente com todas as informações de apoio, descrevem como será a sintaxe e a semântica da interface do usuário. Modelos de Análise e Projeto de Interfaces

72 72 UNIDADE II O PROCESSO Para Pressman (2011, p. 292), o processo de análise e projeto de interfaces do usuário é interativo e pode ser representado usando-se um modelo espiral. Começamos no interior na espiral e vamos englobando as atividades: análise e modelagem de interface, projeto da interface, construção da interface e a validação da interface. Como as atividades são em espiral, isto implica que cada uma das atividades ocorrerá mais de uma vez. Figura 3: O processo de projeto de interface do usuário Validação da interface Construção da interface Fonte: Pressman (2011, p. 293). Análise e modelagem da interface Projeto da interface Conforme Pressman (2011, p. 293) a análise de interfaces possui o foco no perfil dos usuários que irão usar o sistema, seus níveis de habilidades, área de conhecimento e sua receptividade. O projeto de interface define as representações da tela do sistema e sua usabilidade. Na construção da interface desenvolvemos o protótipo que permite avaliar os cenários em geral. Na validação da interface verificamos se a interface foi implementada corretamente, incluindo todas as tarefas de usuário, e também, se atende os requisitos gerais definidos aos usuários, grau de facilidade, aprendizado e aceitação por parte dos usuários. PROJETO DE SOFTWARE

73 73 Entrevistas com os usuários: na abordagem mais direta, membros da equipe de software se encontram com os usuários finais para entender melhor suas necessidades, motivações, cultura de trabalho e uma miríade de outras questões. Informações do pessoal de vendas: o pessoal de vendas se encontra regularmente com usuários e pode reunir informações que ajudarão a equipe de software a classificar os usuários e compreender melhor seus requisitos. Informações do pessoal de marketing: a análise de mercado pode ser inestimável na definição de segmentos de mercado e no entendimento de como cada segmento poderia usar o software de modos sutilmente diferentes. Informações do pessoal de suporte: a equipe de suporte conversa diariamente com os usuários. Eles são, provavelmente, a fonte mais provável de informações sobre o que funciona e o que não funciona, o que os usuários gostam e o que não gostam, quais recursos geram questionamentos e quais são fáceis de ser usados. Fonte: Pressman (2011). ANÁLISE DE INTERFACE Pressman (2011, p. 294) afirma que um princípio fundamental de todos os modelos de processos de engenharia de software é o seguinte: entender o problema antes de tentar desenvolver uma solução. Quando fazemos a análise de interfaces do usuário, entender o problema significa: entender os usuários, as tarefas que os usuários devem realizar o conteúdo que será apresentado e o ambiente onde essas tarefas serão conduzidas. A seguir, os elementos da análise de interfaces: Análise de Usuários: devemos entender os usuários, para isso invista um tempo conversando com eles, entrevistando e colha o maior número de informações possíveis. Análise e Modelagem de tarefas: devemos identificar as tarefas que os usuários irão desempenhar via interface do usuário. Modelos de Análise e Projeto de Interfaces

74 74 UNIDADE II Análise do Conteúdo exibido: devemos considerar o formato e a estética do conteúdo que será exibido aos usuários. Análise do Ambiente de trabalho: devemos analisar o ambiente de trabalho dos usuários, como ambientes físicos e a cultura do local. ETAPAS DO PROJETO DE INTERFACE Depois que a análise de interface estiver pronta, todos os objetos e ações que foram solicitados pelo usuário foram detalhados, a atividade de projeto de interface se inicia. Conforme menciona Pressman (2011, p. 300) o projeto de interface, assim como todo projeto de engenharia de software, é um processo iterativo. Cada etapa de um projeto de interface do usuário ocorre uma série de vezes, elaborando e refinando informações desenvolvidas na etapa anterior. Existem diversos modelos diferentes de projeto de interfaces do usuário, mas Pressman sugere a seguinte combinação de etapas: 1. Fazer o uso das informações que foram desenvolvidas durante a análise de interfaces. 2. Modelar as ações dos usuários (eventos). 3. Mostrar cada estado da interface como irá aparecer ao usuário. 4. Mostrar como o usuário interpreta o estado do sistema. Independente de como se dará o início das tarefas do projeto, por onde vamos iniciar, seja por esboço ou definindo objetos e ações, o importante é sempre seguir as regras de ouro mencionadas anteriormente, não esquecer de modelar como a interface será implementada e considerar como será o ambiente a ser usado pelo usuário. Aplicação das etapas para projeto de interfaces: devemos definir os objetos e quais as ações aplicadas a eles. Para isso, os cenários devem ser minunciosamente analisados e descrito um caso de uso para exemplificar as etapas do projeto de interface do usuário. PROJETO DE SOFTWARE

75 75 Padrões de projeto de interface do usuário: devemos definir os padrões de projeto para as interfaces de usuário, já que muitos podem desenvolver ações em comum. Questões de projeto: devemos definir algumas questões de projeto como: qual o tempo de resposta do sistema? quais recursos de ajuda serão disponibilizados ao usuário? como serão tratadas as informações de erro que pode aparecer aos usuários? como será a atribuição de nomes a comandos e menus? Acessibilidade às aplicações: devemos definir que o projeto de interfaces tenha mecanismos que permitam fácil acesso para quem é portador de necessidades especiais. Internacionalização: devemos definir que o projeto de interfaces leve em conta as necessidades de diferentes localidades e idiomas. Sobre a interface do usuário, Pressman (2011) afirma que A interface do usuário é a janela para o software. Em muitos casos, ele molda a percepção do usuário quanto à qualidade de um sistema. Se a janela for embaçada, ondulada e quebrada, o usuário poderá rejeitar um sistema computacional que de outra forma seria poderoso (PRES- SMAN, 2011, p. 313). Com isso, podemos perceber que a interface do usuário é a parte mais importante de um projeto de software. Se ela for mal projetada, o usuário terá dificuldades e com isso a aplicação pode falhar. Vamos seguir em frente nos estudos? No próximo tópico vamos conhecer o Projeto de Estrutura de dados e seus conceitos. Continue a sua leitura! Acima de tudo, invista tempo conversando com os usuários de fato, mas seja cauteloso. Uma opinião firme não significa necessariamente que a maioria dos usuários irá concordar. (Pressman). Modelos de Análise e Projeto de Interfaces

76 76 UNIDADE II Durante essa etapa de análise de interface, são considerados o formato e como ele é exibido pela interface. Entre as perguntas feitas e respondidas, temos: Os diferentes tipos de dados são alocados em posições geográficas consistentes na tela? O usuário pode personalizar a localização do conteúdo na tela? Foi atribuída identificação apropriada na tela para todos os conteúdos? Se for preciso apresentar um relatório grande, como seria subdividido para facilitar sua compreensão? Haverá mecanismos disponíveis para ir diretamente a informações resumidas em conjuntos de dados volumosos? A saída gráfica será apresentada em escala para caber nos limites do dispositivo de exibição utilizado? Como serão usadas cores para melhorar o entendimento? Como serão apresentadas ao usuário mensagens de erro e alertas? As respostas a essas (e outras) questões nos ajudarão a estabelecer os requisitos para apresentação de conteúdo. Fonte: Pressman (2011). PROJETO DE SOFTWARE

77 77 Questões de projeto À medida que o projeto de uma interface do usuário evolui, quatro questões de projeto comuns quase sempre vêm à tona: tempo de resposta do sistema, recursos de ajuda ao usuário, informações de tratamento de erros e atribuição de nomes a comandos. Infelizmente, muitos projetistas não tratam desses problemas até um ponto relativamente avançado do processo de projeto (algumas vezes a primeira vaga ideia de um problema não ocorre até que um protótipo operacional esteja disponível). Em geral, decorrem iterações desnecessárias, atrasos de projeto e frustração por parte do usuário final. É muito melhor estabelecer cada um desses como um problema de projeto a ser considerado no início do projeto de software, quando as mudanças são fáceis e custam pouco. Fonte: Pressman (2011). PROJETO DE DADOS À medida que nos aproximamos da fase de implementação, o projeto de estrutura de dados assume uma importância significantiva, já que a estrutura dos dados representa os relacionamentos lógicos entre os diferentes elementos de dados individuais e uma vez que estas vão definir a complexidade procedimental do software (ou de seus componentes). O projeto de dados define como são organizados, como será os métodos de acesso, o processamento das informações, entre outros. O modelo de domínio da informação é transformado nas estruturas de dados que serão exigidas para implementar o software. A escolha da estrutura que será usada no projeto de dados vai depender muito da experiência anterior do projetista. O tipo de aplicação a ser desenvolvida e o nível de criatividade do projetista, vão definir a forma como são organizados os elementos de dados e a sua complexidade em cada estrutura. É muito importante que seja estabelecido de que forma serão armazenados os dados do sistema. shutterstock Projeto de Dados

78 78 UNIDADE II O projeto dos dados é composto pela seleção das representações lógicas dos objetos de dados identificados na etapa de levantamento dos requisitos. Alguns princípios devem ser seguidos para obter resultados satisfatórios no andamento do projeto de dados. São eles: Realizar uma análise sistemática no que diz respeito aos dados, a exemplo do que é feito com os aspectos funcionais e comportamentais do software. Realizar a identificação das estruturas de dados e das operações a serem realizadas por elas. Realizar a criação de um dicionário da estrutura de dados. Procurar adiar decisões de baixa prioridade no que diz respeito ao projeto de dados. Procurar limitar a representação das estruturas de dados aos módulos que as utilizarão. Realizar a criação de uma biblioteca de estruturas de dados úteis e das operações a serem aplicadas a elas, em caso de reusabilidade. Procurar usar uma linguagem de programação e projeto que suporte tipos abstratos de dados. Mas porque o projeto de dados é importante? Será que ele influencia a qualidade do projeto? O Projeto de Dados possui uma importante influência sobre a qualidade do software que está sendo desenvolvido, seus conceitos de ocultação de informação, abstração de dados que são oferecidos como a base para o projeto. Nessa fase do projeto todos os detalhes dos dados que serão manipulados pelo sistema devem ser analisados com cuidado, sejam dados de entrada, de saída ou dados internos. O que seria uma estrutura de dados? É uma representação das relações lógicas existentes entre cada elemento individual de um dado. Ela é considerada tão importante quanto à estrutura do programa definida para a arquitetura do software. Por qual motivo? Ela afeta o projeto procedural final. É importante observar que as estruturas de dados podem ser representadas em diferentes níveis de abstração. Vamos usar como exemplo a PILHA, que é um PROJETO DE SOFTWARE

79 79 modelo conceitual de estrutura de dados que pode ser implementado por uma lista ligada ou utilizando um vetor. Dependendo do nível de detalhe do projeto em que se está, o funcionamento da pilha pode ou não ser especificado. Vamos conhecer agora algumas das possíveis estruturas de dados que podem ser utilizadas: Listas: é uma estrutura de dados que funciona como um array. Com a diferença que para cada posição, podem ser armazenados vários dados. O conjunto de dados armazenado em cada posição é chamado de nó. A lista é formada, é um conjunto de dados. Vetor sequencial: representam um conjunto de itens escalares organizados como um grupo ou uma lista. Exemplo: Text: array[1..200] of string; A: array[1..30] of integer; Item escalar: representa um único elemento de informação endereçado por um identificador. Exemplos: var i: integer; var c: char; Podem ser usadas outras estruturas de dados mais complexas, mas a escolha da estrutura que será usada no projeto de dados vai depender muito da experiência anterior do projetista. Com isso, concluímos o conteúdo desta unidade. Desejo que você aproveite o máximo tudo o que vimos até aqui. Continue com os estudos, pois ainda temos muito pela frente. Bons estudos! O projeto de dados se concentra em arquivos ou bancos de dados; no nível dos componentes, o projeto de dados considera as estruturas de dados para implementar os objetos de dados locais. (Pressman). Projeto de Dados

80 80 UNIDADE II Um programa com uma arquitetura de dados fraca será difícil de adaptar e melhorar. Na verdade, para muitas aplicações, a arquitetura das informações tem mais a ver com a viabilidade de longo prazo de um programa do que o próprio código-fonte. Em muitos casos, a reestruturação dos dados começa com uma atividade de engenharia reversa. A arquitetura de dados atual é dissecada e os modelos de dados necessários são definidos. Identificam-se os objetos de dados e atributos, e as estruturas de dados existentes são revisadas quanto à qualidade. Quando a estrutura de dados é fraca (por exemplo, estão implementados em arquivos de texto, quando uma abordagem relacional simplificaria muito o processamento), os dados passam por uma reengenharia. Devido à arquitetura de dados ter uma forte influência sobre a arquitetura do programa e os algoritmos que a constituem, mudanças nos dados resultarão invariavelmente em mudanças de arquitetura ou de nível de código. Fonte: Pressman (2011). CONSIDERAÇÕES FINAIS Nesta unidade, analisamos a importância da fase de Projetos dentro do processo de desenvolvimento de software. Foram apresentados aspectos importantes relativos ao projeto e como essa fase é fundamental para o desenvolvimento de um software. Aprendemos que na fase de projeto é onde definimos a arquitetura do software, a interface com o usuário, os componentes que fazem parte dele e como será a estrutura de dados do software, tendo como base o que foi levantado na análise de requisitos. Esta fase de projeto de software se caracteriza por ser a definição física do sistema, onde podemos definir como vai ser as interfaces do nosso sistema, em que especificamos mais os casos de usos, pois eles vão ajudar os programadores a escrever o código fonte deste sistema, que é a próxima fase, ou seja, a implementação do software. PROJETO DE SOFTWARE

81 81 Também aprendemos que quanto mais detalhado for o projeto de software, melhor para as próximas fases, principalmente a implementação, que veremos no próximo capítulo. Apesar que se todas as fases do processo de software forem bem detalhadas, chegamos ao final com um sistema com menos falhas e erros de desenvolvimento, pois todas as fases se complementam e se relacionam entre si. Ao longo da unidade, nos aprofundamos nos conceitos de projeto, os principais aspectos, técnicas, modelos e tipos de projetos. Com esse conhecimento adquirido e com os próximos, possamos chegar ao final das fases que envolvem um processo de software, obtendo um sistema eficiente e com qualidade. Com isso, chegamos ao final da unidade II do livro e ao final de uma das fases do processo de desenvolvimento do software. Espero que você tenha conseguido entender os conceitos relacionados à fase de projeto. Se entendeu, conseguirá entender as próximas fases do processo de software que estão por vir nas próximas unidades. Continue sua leitura! Considerações Finais

82 82 1. Na fase de Projeto o principal objetivo é definir uma estrutura que possa ser implementada baseada no que foi descrito nos requisitos que foram levantados para o sistema junto ao cliente. Você saberia dizer qual a diferença entre a análise e o Projeto? 2. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F) a assertiva falsa, sobre o processo de software: ( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: software, hardware, internet, tipo de telefone, a interface de usuário, formulários que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros programas específicos que possa vir a usar, quais bancos de dados e arquivos que serão necessários. ( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: software, hardware, infraestrutura de rede, a interface de usuário, formulários que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros programas específicos que possa vir a usar, quais bancos de dados e arquivos que serão necessários. ( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: estrutura de cabos, hardware, infraestrutura de telefonia, a interface de usuário, formulários que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros programas específicos que possa vir a usar, quais bancos de dados e arquivos que serão necessários. Assinale a opção com a sequência CORRETA. a. V, F, V. b. F, V, V. c. V, V, V. d. F, V, F. 3. Os principais conceitos relacionados ao projeto de software são: I. Abstração, refinamento, padrões, desenho, hierarquia de controle, encapsulamento, estrutura de dados, procedimentos de software, ocultação de informação. II. Abstração, refinamento, modularidade, padrões, arquitetura, hierarquia de controle, encapsulamento, estrutura de dados, procedimentos de software, ocultação de informação. III. Abstração, refinamento, modularidade, padrões, arquitetura, hierarquia de funções, encapsulamento, estrutura de dados, procedimentos de software, ocultação de informação.

83 83 Assinale a opção com a sequência CORRETA. a. Somente a questão III está correta. b. Somente as questões I e II estão corretas. c. Somente a questão II está correta. d. Todas estão corretas. 4. Por que o Projeto de Software é considerado uma das fases mais importantes do desenvolvimento de um software? 5. O significado de componente vai depender do ponto de vista do responsável pelo projeto de componentes, o Engenheiro de Software. Mas qual seria este ponto de vista? 6. Vimos que existem diversos modelos diferentes de projeto de interfaces do usuário, mas sugerimos algumas combinações de etapas, que são: I. Fazer o uso das informações que foram desenvolvidas durante a análise de interfaces. II. Modelar as ações dos engenheiros. III. Mostrar cada estado da interface como não irá aparecer ao usuário. IV. Mostrar como o usuário interpreta o estado do sistema. Assinale a opção com a sequência CORRETA. a. Somente a questão III está correta. b. Somente as questões I e IV estão corretas. c. Somente a questão II está correta. d. Todas estão corretas.

84 84 O CONCEITO DE INTERFACE NO CONTEXTO DO DESIGN Tatiana Silva Bevilacqua Introdução O design é uma área que vem se desenvolvendo muito nas últimas décadas e cuja importância tem sido cada vez mais reconhecida. O trabalho de um designer muitas vezes é visto como algo meramente visual, ou seja, como se fosse a finalização meramente estética para determinados trabalhos serem visualmente atraentes. É certo que o design tem seu lado plástico, mas isso é apenas uma pequena parte de um processo complexo e abrangente. O designer trabalha diretamente na interface, no trânsito entre usuário e objeto. No entanto, mesmo os próprios designers muitas vezes não questionam efetivamente o que é a interface, não compreendendo como pode ser possível seu projeto não ser tão eficiente quanto planejado. Os conceitos de interface já foram pontuados por diferentes profissionais e teóricos, não apenas da área do design. O próprio termo interface traz consigo sua significação de um modo amplo: é algo que se interpõe entre duas coisas distintas entre si. No entanto, esta definição não basta. É preciso, primeiramente, entender a ideia de interface, para depois compreender onde ela é encontrada no design, identificar no contexto do design é o primeiro passo para sua conceituação. A Grande Questão do Design Antes de maiores aprofundamentos, é importantíssimo pontuar qual o conceito de design considerado nesta pesquisa. No escopo deste trabalho, considera-se que o design é projeto e é feito para servir a alguém, ao usuário. Da mesma forma que um médico existe em função do paciente, o designer existe em função do usuário. No senso comum o design possui uma função meramente cosmética, de finalização, para deixar os produtos mais elegantes, mais agradáveis esteticamente. Na verdade, neste senso mora um dos maiores problemas do design, conferindo ao designer um papel menor. O designer não deveria participar do projeto apenas em sua etapa final ou estética, quando outras decisões importantes já foram tomadas, mas este deve, participar ativamente de todas as etapas de desenvolvimento de um projeto. Esta é a idéia fundamental que o designer Gui Bonsiepe defende. Para Bonsiepe, o design é o elo entre as ciências de desenvolvimento de produtos e as ciências humanas que tratam o usuário. À engenharia, por exemplo, cabe desenvolver tecnologias, trabalhar sobre o maquinário. Ao marketing cabe inserir estas tecnologias na sociedade. Pode-se até considerar que à sociologia cabe estudar os efeitos em grande escala destas novas tecnologias, ou seja, seus reflexos na sociedade. Enfim, cada área atua em uma parte deste complexo sistema de consumo. O design tem sua ação bem definida, bem como as outras áreas, mas nem sempre lhe é concebida a verdadeira função. Ao design cabe estudar o objeto e o usuário, para adaptar aquele às características físicas e cognitivas deste.

85 85 Da Interface Temos que levar em conta que interface não é uma coisa, mas o espaço no qual se estrutura a interação entre corpo, ferramenta (objeto ou signo) e objetivo da ação. (...) a interface revela o caráter da ferramenta dos objetos e o conteúdo comunicativo das informações. A interface transforma objetos em produtos. A interface transforma sinais em informação interpretável. A interface transforma simples presença física (Vorhandenheit) em disponibilidade (Zuhandenheit). A ferramenta é o que possibilita a interação, é um objeto, algo fisicamente presente e projetado para se adequar às diferentes partes da interação, ou então um signo, um código, imagens ou mensagens. Há então, neste pensamento, uma diferenciação entre interface e ferramenta. A interface, justamente por não ser algo moldável, ou palpável, não é a coisa em si, mas o espaço. O termo espaço não como sinônimo de lugar, algo definido por Brenda Laurel e que veremos a seguir. No pensamento de Bonsiepe o usuário é o foco do projeto, é a ele que o designer serve, e é ele quem deve se satisfazer. Sua satisfação é a realização de determinada tarefa, ou seja, o usuário deseja realizar uma tarefa e esta deve ser realizada de maneira fácil. Esses são os elementos básicos de estudo do design, são os elementos caracterizadores da interface. Em cada domínio do design a interface possui suas características mais específicas. Conclusão A interface, no design, é uma realidade criada para simplificar a vida do usuário, ou seja, para tornar real uma tarefa que o usuário deseja realizar, da maneira mais natural possível. Esta realidade é o meio em que ocorre uma interação. As características do usuário e suas necessidades caracterizam a interface. As ferramentas, ou seja, os objetos a serem projetados pelos designers devem refletir estes conceitos de forma imperceptível ao usuário, como sugerido por Norman. Para Laurel, a interface é um lugar onde ocorre a interação enquanto Bonsiepe entende a interface como o meio em que o sistema de interação está imerso. Ao tirarmos do objeto em si a responsabilidade de ser a interface, é muito mais fácil compreender em cima de quê o design deve trabalhar para desenvolver produtos cada vez mais eficientes. Como dito no início do artigo, o visualmente agradável é apenas uma pequena parte, é uma consequência, de algo muito mais complexo. Quanto mais agradável ao olhar, maior é a tendência de ser passivo a esta informação visual. Quanto mais confortável é um objeto, maior a tendência de sentir-se bem em um sofá. É esta ideia que deve ser desenvolvida no design, entender as necessidades do usuário. O design não pode ter a pretensão de querer evidenciar seus benefícios para o usuário, ele deve simplesmente resolver seus problemas. Atualmente, o grande foco da ergonomia é estudar as necessidades humanas, físicas e psicológicas, para adaptar o objeto ao usuário. Mais uma vez, o design caminhando para adequar os objetos aos seres humanos e não o caminho contrário. Sendo assim, é nítida a relação deste objetivo ao conceito de interface invisível de Don Norman. Fonte: Bevilacqua (2007).

86 MATERIAL COMPLEMENTAR Projeto de Software: Da programação à arquitetura: Uma abordagem baseada em Java Eric Braude Editora: Bookman (edição digital) Sinopse: Projeto de software é um guia completo sobre teoria e prática de projetos da programação à arquitetura, tratando desde o nível de código, com questões de programação, até abstração e escopo. Na obra, o autor analisa as questões de projeto de nível. A queda Hitler projeto software gestão Divertido vídeo sobre a sátira utilizando parte do filme A queda as ultimas horas de Hitler para descrever como funcionaria uma reunião do gerenciamento de um projeto de software. < Interface de Aplicação em Projetos de Software Vídeo muito interessante sobre a interface de aplicação. A implementação da interface da aplicação é sempre um grande desafio para o desenvolvedor de software. Pensando nisso Ramon Durães está promovendo um bate-papo nesse vídeo para discutir a importância de se pensar na experiência do usuário e o quanto essa questão é importante para o desenvolvedor de software. Aproveite e aprofunde seus conhecimentos. <

87 MATERIAL COMPLEMENTAR Desafios do Projeto de Software Um artigo com metáforas muito interessante sobre os desafios de um projeto de software. Este artigo é baseado em uma parte do quinto capítulo do livro Code Complete, por McConnell, 2ª edição. Um livro excelente sobre a criação de software, onde os princípios não entram em obsolescência com o passar do tempo, ao contrário das implementações das linguagens de programação. McConnell sabe o valor da metáfora no mundo abstrato da programação de computadores. Ele inclusive trata disso em seu livro. Não perca, vale a pena ler. Acesse o link em: < Definindo a Arquitetura de um Projeto de Software Vamos saber mais sobre a Arquitetura de um Projeto de Software? Leia este artigo. Ele mostra como como definir uma boa arquitetura, como começar, quais ferramentas podem ser usadas, como aplicar a separação de responsabilidades ao seu projeto de software, como utilizar os padrões de projeto e como determinar um processo bem definido de desenvolvimento de software. Disponível em: < gle>. PROTOTIPAGEM DE INTERFACES NA PRÁTICA Otimizando a identificação e especificação de requisito Este artigo mostra como a prototipagem vem ganhando cada vez mais valor no mercado e já é utilizada em muitas empresas. Entretanto, ainda é vista muitas vezes apenas como uma forma de comunicação entre o requisito e o desenvolvimento, representando somente a disposição da tela. Na verdade, a prototipagem permite a validação e melhor entendimento dos requisitos levantados com o usuário, além de lhe proporcionar uma visão prévia do produto que será construído. As técnicas aqui apresentadas no artigo permitem otimizar a produtividade da equipe e minimizar o retrabalho. Excelente leitura, aproveite! < Material Complementar

88 REFERÊNCIAS BEVILÁCQUA, T. S. O conceito de interface no contexto do design. Anais do 3º Congresso Internacional de design da informação, COSTA, C. de F. Qualidade do Produto e Processo de Software. Brasília: CROSBY, P. B. Qualidade, falando sério. São Paulo: McGraw-Hill, GIMENES, I. M. S. Uma Introdução ao Processo de Engenharia de Software. XIII Jornada de atualização em Informática. Caxambu MG, GIMENES, I.; HUZITA, E. Desenvolvimento Baseado em Componentes: Conceitos e Técnicas. São Paulo: Editora Ciência Moderna, PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 3. ed. Rio de Janeiro: Editora Brasport, SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software Teoria e Prática. São Paulo: Prentice Hall, 2001.

89 GABARITO Na análise de requisitos é modelado o domínio do problema e no Projeto é modelada a solução para o problema. 2. D - F, V, F. 3. C - Somente a questão II está correta. 4. Ele é considerado importante, porque é nele que iniciamos a etapa de qualidade e ele serve como base para as outras fases do processo de software. 5. Conforme Pressman (2011) são três pontos de vistas que são utilizados. São eles: Visão Orientada a objetos: para esta visão, um componente é um conjunto de classes colaborativas ou podem ter um componente com uma única classe. Visão Tradicional: para esta visão, um componente é o elemento funcional de um programa que incorpora a lógica de processamento, as estruturas de dados e uma interface que habilita o componente para que os dados sejam fornecidos a ele. Visão relacionada com processos: para esta visão, um componente é utilizado a partir da reusabilidade, ou seja, que façamos o uso de componentes de software ou de padrões de projeto já existentes. 6. B. Somente as questões I e IV estão corretas.

90

91 Professora Esp. Janaína Aparecida de Freitas IMPLEMENTAÇÃO DE SOFTWARE UNIDADE III Objetivos de Aprendizagem Compreender a importância da implementação de software. Entender as questões fundamentais que precisam ser consideradas durante a implementação do software. Apresentar os conceitos e técnicas que envolvem a implementação e a depuração. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: Implementação de Software Atividades da Implementação de Software Características da Implementação de Software Estilo de programação e codificação Comentário Depuração Asserções e Programação Defensiva Otimização de Desempenho Refatoração

92

93 93 INTRODUÇÃO Caro(a) Aluno(a), na unidade anterior aprendemos sobre a fase de projeto e a sua importância no processo de desenvolvimento do software. Nesta unidade do livro, vamos aprender todos os aspectos da fase da Implementação, com exceção da fase dos testes que será vista nas próximas unidades. Nesta unidade, vamos conhecer mais a fundo os conceitos que envolvem a fase de Implementação, compreender a sua importância, entender as questões fundamentais que são consideradas durante esta fase. Na fase de projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, e deve ser coerente com a descrição realizada no levantamento de requisitos. Na fase de Implementação, o projeto é traduzido para uma forma passível de execução pela máquina. A fase de Implementação realiza esta tarefa, isto é, cada unidade de software do projeto detalhado é escrita. Nesta fase ocorre a codificação/programação dos requisitos de software, baseado nas definições técnicas analisadas na fase de projeto. A Implementação atualmente pode utilizar linguagens de programação visuais e orientadas a objeto, com ambientes de desenvolvimento fáceis e amigáveis para o desenvolvimento dos códigos. Na fase de Implementação detalhamos os componentes previstos no projeto, descrevendo todos os componentes de código fonte e código binário, em nível de linguagem de programação ou de acordo com as tecnologias escolhidas no levantamento de requisitos. Na fase de Implementação, o resultado da escolha correta do ambiente de programação e demais ferramentas, no final é com certeza um software de boa qualidade, pois não basta saber programar em uma linguagem de programação para implementar um software, é necessário, também, conhecer e aplicar boas práticas de programação e usar ferramentas disponíveis para tornar esta fase mais eficiente e eficaz. Vamos, a fase de Implementação! Boa leitura e bons estudos! Introdução

94 94 UNIDADE III shutterstock IMPLEMENTAÇÃO DE SOFTWARE Conforme Tsui e Karam (2013, p. 135), o objetivo final da maioria dos projetos de engenharia de software é produzir um programa funcional. O ato de transformar o projeto detalhado em um programa válido em alguma linguagem de programação, juntamente com todas as suas atividades de apoio é aludido como implementação. Nessa fase, ocorre a codificação/programação dos requisitos de software, baseado nas definições técnicas da fase de projeto. Na fase de implementação desenvolvemos o código, mas ela vai além disso. Nessa fase, vamos ver que além de ser escrito o código, precisamos testá-lo e depurá-lo, assim como compilá-lo e, por fim, ter um produto executável completo. Durante este processo, o ideal é que se utilize um controle de versões para acompanhar as diferentes versões do código durante o desenvolvimento. O profissional responsável por desenvolver esta etapa é conhecido por Programador ou Desenvolvedor, cujo perfil apresenta excelentes capacidades lógicas e analíticas. A fase de Implementação detalha os componentes previstos no projeto, descrevendo todos os componentes de código fonte e código binário, em nível de linguagem de programação ou de acordo com as tecnologias escolhidas. IMPLEMENTAÇÃO DE SOFTWARE

95 95 A fase de implementação envolve as seguintes atividades: codificação, depuração, compilação, integração e testes. A atividade de codificação mostra a estrutura e o comportamento que foram descritos na fase de projeto. Os testes podem ser iniciados durante a fase de implementação e a depuração de erros pode ocorrer durante a codificação, podendo ser utilizada algumas ferramentas e técnicas. Ao se iniciar a fase de implementação, é necessário escolher o ambiente que vai ser programado, boas práticas para facilitar a manutenção depois, rotinas de testes que devem ser executados, documentações pertinentes a esta fase, arquivos de configuração e outras questões que possam influenciar direta ou indiretamente no bom desempenho desta fase. Em caso do ambiente de implementação escolhido for orientado a objetos, outras questões devem ser analisadas, como relacionamentos entre objetos, métodos, controle de instâncias e persistência de objetos. Para Beck (2013, p. 13), melhorar a comunicabilidade do software também aumenta a flexibilidade. Quando mais pessoas puderem ler, entender e modificar o código rapidamente, mais opções se tem para mudanças futuras. Na fase de implementação, o programador procura mapear corretamente as representações (ou modelos) obtidas no projeto para uma dada linguagem de programação. As características de uma linguagem de programação podem exercer um impacto significativo no desenvolvimento da codificação, segundo diferentes ângulos. A fase de implementação demanda grande parte do tempo no processo do desenvolvimento de um software, considerada uma atividade trabalhosa e que exige profissionais que tenham habilidades e experiência na área. A fase de implementação inclui algumas tarefas, como por exemplo: Planejamento detalhado da implementação das unidades de cada iteração. Implementação das classes e outros elementos do modelo de projeto, geralmente arquivos de código fonte. Verificação das unidades, por meio de revisões, inspeções e testes de unidade. Compilação, ligação das unidades e integração das unidades entre si. Integração das unidades com componentes reutilizados. Implementação de Software

96 96 UNIDADE III Quando falamos de integração, nos referimos à ligação de um componente desenvolvido com outro que necessite dos seus serviços. Conforme Sommerville (2013, p. 135), o estágio mais crítico desse processo é, naturalmente, a implementação do sistema, estágio em que você cria uma versão executável do software. A fase de implementação pode envolver o desenvolvimento de programas em alto e baixo nível de linguagens de programação. Para Sommerville (2013, p. 136), existem alguns aspectos de implementação que são importantes, como: 1. Reuso: quando se está desenvolvendo um sistema, devemos fazer o maior uso possível de códigos já existentes. 2. Gerenciamento de configuração: quando se está desenvolvendo um sistema, são geradas muitas versões diferentes, sendo interessante usar um gerenciamento de configuração para o controle. 3. Desenvolvimento host-target: o desenvolvimento de um sistema ocorre em um computador (sistema host) e é executado em outro (sistema target), podendo ser do mesmo tipo ou muitas vezes diferentes. Para Beck (2013, p. 5), muitas decisões na programação são únicas e a codificação seria mais eficaz se programadores gastassem menos tempo nas partes mundanas e repetitivas do trabalho e tivessem mais tempo para resolver problemas verdadeiramente únicos. Caso não consiga encontrar uma linguagem de padrões que trate do domínio de seu problema, procure analogias em um outro conjunto de padrões. (Pressman). IMPLEMENTAÇÃO DE SOFTWARE

97 97 Conforme aumenta a importância do software, a comunidade da área tenta desenvolver tecnologias que tornem mais fácil, mais rápido e mais barato desenvolver e manter programas de computador de alta qualidade. Algumas dessas tecnologias são direcionadas a um campo de aplicação específico (por exemplo, projeto e implementação de sites); outras são focadas em um campo de tecnologia (por exemplo, sistemas orientados a objetos ou programação orientada a aspectos); e ainda outras são de bases amplas (por exemplo, sistemas operacionais como o Linux). Entretanto, nós ainda temos de desenvolver uma tecnologia de software que faça tudo isso, sendo que a probabilidade de surgir tal tecnologia no futuro é pequena. Ainda assim, as pessoas apostam seus empregos, seu conforto, sua segurança, seu entretenimento, suas decisões e suas próprias vidas em software. Tomara que estejam certas. Fonte: Pressman (2011). ATIVIDADES DA IMPLEMENTAÇÃO DE SOFTWARE Durante a fase de implementação é gerado algumas documentações que são importantes para o uso do software que está sendo desenvolvido. As documentações envolvidas são: manuais de usuários, ajuda on-line, material de treinamento, demonstrações e outros recursos que podem produzir uma documentação que auxilie o uso do sistema por parte dos usuários. A documentação constitui um elemento essencial tanto para atividades de validação do software como (e principalmente) para as tarefas de manutenção. Atividades da Implementação de Software

98 98 UNIDADE III Desenho detalhado Projeto de arquitetura Inspeção de implementação Unidades verificadas Implementação completa Codificação Integração Testes de unidade Defeitos encontrados Implementação incompleta Figura 1: Fluxo da Implementação Fonte: Santos Neto, (2007). O Fluxo de Implementação inicia-se com o desenho detalhado, que segue para a codificação, em que é feita a tradução do desenho detalhado no código de uma ou mais linguagens de programação. Na codificação, podemos utilizar as IDE (Integrated Development Enviroment), que são ferramentas para desenvolvimento que possuem bibliotecas, atalhos, wizards e outras funcionalidades integradas, que facilitam a vida do programador. IMPLEMENTAÇÃO DE SOFTWARE

99 99 Depois as unidades de código fonte produzidas são passadas por uma revisão de código, em que são eliminados os defeitos primários, como erros de digitação ou de uso da linguagem mesmo. Essa revisão também deve ser feita pelos programadores. Na sequência, vem a atividade de Inspeção de implementação em que é verificado de forma mais rigorosa o código por meio de um grupo de revisores. Na atividade de testes de unidade são feitos testes usando componentes de teste que devem também ter sido desenhados, revistos, codificados e compilados nas atividades anteriores. Um teste de unidade é aquele que testa uma única unidade do sistema. O teste de unidade testa de maneira isolada as prováveis dependências que aquela unidade tem. Quando o sistema é orientado a objeto, a unidade pode ser uma classe. Por exemplo: ao executar o teste de unidade para a classe Vendedor, essa lista de testes testará o funcionamento da classe Vendedor, de forma isolada, sem interações com outras classes do sistema. Os testes de unidades devem ser feitos usando componentes de teste que devem também ter sido projetados, revistos, codificados e compilados nas atividades anteriores. A atividade Integração liga as unidades implementadas com os componentes construídos em liberações anteriores, reutilizados de projetos anteriores ou adquiridos comercialmente. O código executável resultante passa para a fase de testes para realização dos testes de integração. O estágio de implementação do desenvolvimento de software é o processo de conversão de uma especificação do sistema em um sistema executável. (Sommerville). Atividades da Implementação de Software

100 100 UNIDADE III O engenheiro de software, com frequência, assume compromissos de implementação para conseguir que o protótipo entre em operação rapidamente. Um sistema operacional ou linguagem de programação inapropriados podem ser utilizados simplesmente porque se encontram à disposição e são conhecidos; um algoritmo ineficiente pode ser implementado simplesmente para demonstrar capacidade. Após um tempo, pode-se acomodar com tais escolhas e esquecer todas as razões pelas quais eram inapropriadas. Uma escolha longe da ideal acaba se tornando parte integrante do sistema. Embora possam ocorrer problemas, a prototipação pode ser um paradigma efetivo para a engenharia de software. O segredo é definir as regras do jogo logo no início, isso significa que todos os envolvidos devem concordar que o protótipo é construído para servir como um mecanismo para definição de requisitos. Portanto, será descartado (pelo menos em parte) e o software final é arquitetado visando qualidade. Fonte: Pressman (2011). CARACTERÍSTICAS DA IMPLEMENTAÇÃO DE SOFTWARE Para Tsui e Karam (2013, p. 135) sempre é bom ter em mente algumas características que devem ser encontradas em uma boa implementação: Legibilidade: o código deve ser facilmente lido e entendido. Mantenabilidade: o código deve ser facilmente modificado e mantido. Desempenho: códigos em que a execução seja a mais rápida possível. Rastreabilidade: todos os elementos do código devem corresponder a um elemento do projeto. Exatidão: a implementação deve fazer aquilo que foi definido no levantamento de requisitos e no projeto. Integridade: todos os requisitos levantados devem ser atendidos. shutterstock IMPLEMENTAÇÃO DE SOFTWARE

101 101 Para a obtenção dessas características, é necessário um esforço e que exista um relacionamento entre elas, uma influencia na outra. Por exemplo: as otimizações de desempenho frequentemente reduzem a legibilidade e a mantenabilidade. Na fase de implementação, a preocupação é com a correção, a eficiência, a flexibilidade dos aspectos executáveis para o modelo que está sendo desenvolvido. Podemos utilizar algumas ferramentas nesta fase, por exemplo: compiladores, interpretadores, editores, depuradores, geradores de código, geradores de testes, formuladores de código, analisadores etc. ESTILO DE PROGRAMAÇÃO E CODIFICAÇÃO Um fator que é essencial para a obtenção de um código claro e que ofereça facilidade de manutenção é a boa utilização dos mecanismos presentes na linguagem adotada que são os estilos de programação e codificação. É importante para a empresa adotar estilos ou padrões de codificação. Estes estilos fornecem e especificam algumas regras de: atribuição de nomes de variáveis, endentações e estilos de comentários entre outros. Isto é importante quando se trabalha em equipe e quando outros programadores estiverem realizando a depuração ou a manutenção de seu código posteriormente. Muitos programadores, geralmente, trabalham em equipe, necessitando se integrar, testar e muitas vezes alterar os códigos que são produzidos por outros programadores. Por isso, é importante que haja padrões de codificação para a fase de implementação. Tais padrões devem ser seguidos por todos os programadores, de modo que o código e a documentação sejam claros para quaisquer membros da equipe. A seguir vamos ver algumas questões importantes que devem ser utilizadas e que podem afetar o estilo das codificações, conforme Tsui e Karam (2013, p. 136): Estilo de Programação e Codificação

102 102 UNIDADE III Atribuição de nomes: essa questão refere-se à escolha de nomes que serão usados em variáveis, classes, métodos e outros elementos de programação. Outro ponto importante é a consistência, assim, procure utilizar sempre nomes com a mesma palavra ou abreviação para um dado conceito e evite usar o mesmo nome ou abreviação para conceitos diferentes. Separação de palavras e utilização de maiúsculas/minúsculas: em muitos casos, um nome poderá ser composto por mais de uma palavra e em algumas linguagens de programação possuem diferentes convenções para combinar as palavras para um identificador. Assim, seria recomendado que se utilizasse as convenções-padrões para a sua linguagem. Endentação e espaçamento: se refere ao acréscimo de espaços horizontais antes de algumas linhas para melhorar a estrutura do código. Para muitos, é um erro do programador iniciante não endentar o código de forma apropriada. A endentação afeta a legibilidade e a mantenabilidade do código. Tamanho da função/método: códigos com grandes funções ou métodos são mais propensos a erros do que os menores até certo ponto, pois, às vezes, métodos muitos pequenos podem gerar muitos erros também. Questões de atribuição de nomes de arquivo: uma das grandes vantagens quando se adota um padrão é especificar como devem ser atribuídos os nomes de arquivos, assim a localização de todos os elementos é facilitada. Elementos particulares de programação: temos várias linguagens de programação diferentes e que suportam recursos diferentes e muitos destes recursos são considerados perigosos. Um abordagem de bom senso para a implementação: mantenha simples, ajuste para satisfazer as necessidades locais, e certifique-se de que tudo agregue valor. (Pressman). IMPLEMENTAÇÃO DE SOFTWARE

103 103 Os textos das mensagens são mais voláteis que o código da aplicação. Durante o período de implantação, as mensagens tendem a ser alteradas para serem mais bem compreendidas pelo usuário. Uma boa prática é armazenar estas mensagens fora do código fonte da aplicação. Isto permite que os textos sejam alterados sem que a aplicação seja compilada novamente. Além disso, os erros de negócio mostrados para o usuário devem estar na linguagem utilizada pelo usuário. Isto implica que o mecanismo de mensagem precisa armazenar os textos das mensagens em diversas linguagens, o que contribui para a utilização de um repositório que armazena essas mensagens. Fonte: Valentin, Dias e Pacheco (2008). COMENTÁRIOS Conforme Tsui e Karam (2013, p. shutterstock 136), os comentários são muito importantes e podem ajudar ou prejudicar significativamente a legibilidade e a mantenabilidade. Neste caso, quando usamos os comentários durante o desenvolvimento, podem surgir alguns problemas, por exemplo: Eles podem desviar a atenção do código e tornar o código mais difícil de ler. Eles podem estar errados, aumentando a incidência de erros. Outro caso que pode ocorrer, os comentários podem ficar desatualizados conforme os códigos vão mudando e com isso, criando novos erros. Isso porque, eles podem estar errados desde a primeira vez e como não são testados e atualizados, a funcionalidade pode ter mudado. Comentários

104 104 UNIDADE III Apesar de alguns problemas, os comentários podem ajudar a esclarecer o código, assim como outras fontes relacionadas a ele. Entretanto, é preciso destacar que eles representarem algum nível de duplicação do código, em certos momentos. Um comentário que não possui relação ao código o qual ele foi inserido pode causar muitos erros que se tornam difíceis de encontrar e corrigir. Para Tsui e Karam (2013, p. 136), os comentários podem ser definidos nos seguintes tipos: Repetição do código: comentários que normalmente são feitos por programadores novatos. Para não gerar confusão, devem ser evitados, pois são um desperdício de esforço e irão distrair os leitores. Explicação do código: alguns programadores costumam explicar na linguagem o que o código faz, em casos de códigos complexos. Mas em quase toda situação, se o código é muito complexo que exija uma explicação, ele deve ser revisado. Marcador no código: muitos programadores utilizam marcadores para indicar que está com itens incompletos, para indicar mudanças ou quem fez as alterações. Neste caso, é recomendado que seja usado um gerenciador de versão para controle. Resumo de código: são muito úteis para que os programadores entenderem o código, desde que estejam sempre atualizados. Esse resumo, sempre atualizado, eliminará a necessidade de comentários ao longo do código, o que dificulta a manutenção. Descrição do objetivo do código: são os comentários mais úteis, pois ele descreve o que o código deve fazer e não o que ele faz. Neste caso, se o código não fizer o que foi descrito, ele estará errado. Referências externas: usados para vincular comentários a entidades externas, como por exemplo, livro, outros programas ou a existência de dados de inicialização nas tabelas do banco de dados. IMPLEMENTAÇÃO DE SOFTWARE

105 105 Os comentários podem mostrar outro problema sério, podem ser utilizados para justificar as práticas de codificação inadequada. Muitos programadores podem produzir códigos excessivamente complexos e difíceis de dar manutenção, com isso vão acrescentando comentários em vez de revisá-lo e reescreve-lo usando um bom padrão. Conforme Tsui e Karam (2013, p. 136), muitos especialistas recomendam que se evitem os comentários em excesso e que os programadores devem buscar incluir os comentários em seu lugar e, especialmente, na forma da descrição da intenção do programador. Para isso, encoraje os programadores a utilizar bons nomes e boas práticas de programação, reservem os comentários para referências externas e declarações de intenções e no caso de códigos mais complexos, que não podem ser revisados, recomendar a utilização de comentários de resumos, que são mais fáceis de fazer a manutenção. Durante a execução de uma atividade, alguns erros podem ocorrer. O usuário que iniciou a atividade precisa ser informado sobre o que deu errado. O recurso de tratamento de exceções das linguagens é um avançado mecanismo que auxilia neste controle de erros e de mensagens. É necessário estendê-lo para criar um mecanismo capaz de controlar exceções de negócio. Erros de variáveis não inicializadas, de tipos incompatíveis de dados, de índice inválido de vetor, entre outros, são erros da linguagem que devem ser separados dos erros de negócio, que seriam: erro ao iniciar um processo; erro ao executar um serviço; erro ao registrar a movimentação na conta; erro de saldo insuficiente para a operação. Geralmente, erros de linguagem revelam bugs da aplicação, enquanto que erros de negócio revelam inconsistência nos dados da aplicação ou dos parâmetros fornecidos para algum processo. Fonte: Valentin, Dias e Pacheco (2008). Comentários

106 106 UNIDADE III DEPURAÇÃO shutterstock Conforme Tsui e Karam (2013, p. 139), depuração é o ato de localizar e corrigir erros no código. Os erros geralmente são descobertos através de testes, mas podem ser encontrados por outros meios, incluindo as inspeções de códigos e por meio do uso normal do programa. Depurar é considerado um processo usado para reduzir ou encontrar bugs no seu sistema. De uma forma geral, depurar o código não é uma tarefa fácil de ser executada. Um dos motivos, é que podem ocorrer muitas variações que podem vir a atrapalhar esse processo, um exemplo é a linguagem que está sendo utiliza e ferramentas disponíveis para fazermos a depuração de um código. Mas devemos tomar cuidado, pois depurar é um processo iterativo. Você estará criando possíveis hipóteses em cima do erro, criando possíveis testes para provar estas hipóteses, podendo alterar o código para corrigir os erros encontrados. Mas caso essas hipóteses sejam falsas pode ser necessário voltar atrás e iniciar o processo com novas hipóteses. Tsui e Karam (2013, p. 139) identificam quatro fases no processo de depuração e elas podem ser resumidos da seguinte maneira: Estabilização (reprodução): nessa fase reproduzimos o erro em uma configuração particular, no caso, a máquina do programador e assim verificar os erros que estão ocorrendo. O mais importante desta fase é a identificação do erro e das condições em que ele ocorre. Os resultados dessa fase são um conjunto de testes que reproduzem o erro várias vezes, desde situações mais simples. A fase de estabilização pode ser considerada muito difícil às vezes, pois podem ocorrer erros aleatórios, que ao serem testados mais de uma vez, produzem resultados diferentes. IMPLEMENTAÇÃO DE SOFTWARE

107 107 Localização: nessa fase ocorrem as descobertas de seções do código que podem levar aos erros. Esta fase é a que envolve a parte mais difícil de ser verificada. Mas se a fase de estabilização encontrar situações de testes, a fase de localização se torna mais fácil e mais óbvia. Correção: nessa fase o processo de correção envolve possíveis alterações do código para a correção dos erros, desde que tenha ocorrido antes a estabilização e a localização do que causou os erros, melhorando as chances de corrigi-lo. Caso tente corrigir os erros de forma aleatória pode ser que sejam introduzidos novos erros. Verificação: nessa fase é feita as verificações e certificações de que o erro realmente foi corrigido. Também é verificado que não há outros erros que possam ter sido introduzidos no código durante a alteração. Pois, uma alteração no código não corrigirá o erro e ainda poderá introduzir novos erros. Segundo Tsui e Karam (2013, p. 139) erros em um programa podem ser categorizados em erros de sintaxe e erros lógicos. Em linguagens compiladas os erros de sintaxe tendem a ser fáceis de encontrar, pois o compilador irá detectar e ele irá fornecer informações sobre a sua localização, apesar de os compiladores não possuírem uma linguagem clara. Mas para facilitar a depuração, já que ela possa ser considerada uma tarefa muito complicada, existem algumas ferramentas que podem te ajudar no processo de depuração. Conforme Tsui e Karam (2013, p. 139) são elas: Comparadores de código-fonte: ajudam a encontrar as alterações no código. Verificadores Ampliados: usados para encontrar problemas com sintaxe, lógica e estilo. Depuradores Interativos: permite que sejam verificadas as variáveis, estabeleça pontos de interrupção, saltar em pontos de seu código. Bibliotecas especiais: construídas para reimplementar as bibliotecas padrão, possuem segurança extra, para detectar e evitar erros. Traçadores de perfil: ferramentas que descrevem as pré e as pós-condições, ferramentas de cobertura que ajudam nos testes. Depuração

108 108 UNIDADE III A depuração é uma tarefa importante a fim de evitar erros e, consequentemente evitar uma necessidade de transformação total do código depois de pronto. O programador ao utilizar uma ferramenta de depuração possui uma ajuda extra, pois uma ferramenta que só precisa configurar um breakpoint corretamente e seguir os passos para a depuração faz com que não ocorra perda de tempo. Ou seja, a depuração é algo rotineiro na vida dos programadores e algo importante, pois ajuda sempre a descobrir os erros. Por que a depuração é tão difícil? Com toda certeza, a psicologia humana tem muito mais a ver com a resposta do que a tecnologia de software. No entanto, algumas características dos erros fornecem alguns indícios: 1. O sintoma e a causa podem ser geograficamente remotos. Isto é, o sintoma pode aparecer em uma parte de um programa, enquanto a causa pode realmente estar localizada em um ponto muito afastado. 2. O sintoma pode desaparecer (temporariamente) quando outro erro for corrigido. 3. O sintoma pode ser causado por erro humano que não é facilmente rastreável. 4. O sintoma pode ser um resultado de problemas de temporização, e não de problemas de processamento. Pode ser difícil reproduzir com precisão as condições de entrada. [...] 7. O sintoma pode ser intermitente. Isso é particularmente comum em sistemas embutidos que acoplam hardware e software inextricavelmente. 8. O sintoma pode ocorrer devido a causas distribuídas por várias tarefas, executando em diferentes processadores. Fonte: Pressman (2011, p. 490). IMPLEMENTAÇÃO DE SOFTWARE

109 109 ASSERÇÕES E PROGRAMAÇÃO DEFENSIVA Para Tsui e Karam (2013, p. 140), uma técnica muito útil consiste na utilização de asserções, o que está relacionado aos conceitos mais formais de precondições e pós-condições. As técnicas assertivas são validações lógicas de uma condição que é julgada necessária para o correto funcionamento do código no momento em que elas são verificadas. Mas o que isso significa? Quando a validação de alguma condição é testada pela técnica assertiva, significa que uma condição assumida shutterstock instrui o sistema a notificar sempre que essa condição não for satisfeita, sempre mostrando e garantindo que não haja um comportamento imprevisto. Falamos em pre - condições e pós-condições. O que significam? Precondição é uma condição em que seu módulo solicita condições de produzir resultados corretos e uma pós-condição é uma condição que deve se manter após a validação do seu código e que a precondição tenha sido atendida. Conforme Tsui e Karam (2013, p. 140), as precondições e as pós-condições podem ser utilizadas com métodos formais também, onde se pode provar que um código sempre funciona efetivamente e de forma correta sempre atento para a finalidade na qual as assertivas se propõem e, assim, evitar que sejam usadas erroneamente. A prática de programação defensiva é muito usada e instrui o código fonte a identificar falhas e comportamentos que não foram originalmente previstos e, assim, detectar bugs em seus estágios iniciais. Essa prática é muito utilizada para validar as entradas de métodos/rotinas, e sua proposta é validar condições consideradas obrigatórias e que, quando não satisfeitas, identificam uma falha ou erro no sistema. Asserções e Programação Defensiva

110 110 UNIDADE III Técnicas de programação defensiva são mecanismos preventivos contra a ocorrência de falhas de hardware ou de software. Para a verificação da segurança de sistemas de aplicações críticas, técnicas de injeção de falhas foram desenvolvidas, propiciando o teste dos mecanismos de tolerância a falhas em condições muito semelhantes às do ambiente operacional real. A introdução de técnicas de programação defensiva aumenta a segurança dos sistemas de aplicações críticas. Não há, na literatura pesquisada, qualquer referência a uma avaliação quantitativa das técnicas de programação defensiva. Esta tese é a descrição de um trabalho experimental, que visa esta avaliação quantitativa, e se organiza em algumas etapas. Primeiro, algumas técnicas de programação defensiva são apresentadas, caracterizadas e eleitas como objeto de avaliação. Fonte: Secall (2007). OTIMIZAÇÃO DE DESEMPENHO Segundo Tsui e Karam (2013, p. 140) o desempenho é um aspecto importante de praticamente qualquer programa, mas temos que entender as contrapartidas. A otimização para o desempenho geralmente (mas nem sempre) piora a mantenabilidade e a legibilidade. Mas devemos sempre pensar em exatidão, que é mais importante do que desempenho quando se está escrevendo um código. Mas toda regra tem as suas exceções e, neste caso, em sistemas de tempo real, o desempenho de uma ação dentro de um limite de tempo faz parte da exatidão. Vocês devem estar se perguntando: Por que otimizar o código? shutterstock Porque temos muitos sistemas de tempo real que são usados em mercados, são altamente sensíveis a custos, seu consumo de energia deve ser minimizado, em muitos casos o espaço físico é restrito. IMPLEMENTAÇÃO DE SOFTWARE

111 111 Conforme Tsui e Karam (2013, p. 141), o erro mais comum que um programador pode cometer é se preocupar no início com o desempenho do código e não lembrar que o primeiro objetivo ao escrever o programa, é que ele esteja correto e que seja de fácil manutenção e que após ele estiver pronto, será o momento de se preocupar com o desempenho, caso este não esteja satisfatório. Em alguns casos, somente algumas partes de um código que podem vir a causar lentidão e que precisam passar por otimização de desempenho, em outros casos, partes de um programa podem vir a serem executados somente algumas vezes e que não causaram impacto no desempenho. Assim como em qualquer outra atividade no desenvolvimento de um software, devemos fazer uma análise antes de ser efetuada qualquer otimização de desempenho no código, porque, às vezes, não se tem tempo no cronograma do projeto e o tempo de trabalho de um programador é muito caro, que compensa deixar o programa como está e simplesmente comprar um novo hardware mais apropriado. Existem algumas ferramentas que podem ser utilizadas para a otimização de desempenho, como o Profiler, um traçador de perfil que roda o programa e calcula quanto tempo ele gasta em cada parte do código e com isso facilitar a procura de gargalos de desempenhos em módulos que precisam ser otimizados. Sobre a otimização, Tsui e Karam (2013, p. 141) afirma que Em alguns casos, um mau desempenho é um sintoma de um design ou codificação deficiente, e tornar o código mais simples e mais fácil também resultará em um melhor desempenho. Em muitos casos, deve ser possível modularizar o código de modo que as otimizações de desempenho fiquem ocultas em locais bem específicos e que a maior parte do código esteja clara. Um bom compilador de otimização também pode encarregar-se de muitas otimizações de desempenho sem que o programador sacrifique a clareza. Para isso, adotar boas práticas de programação e usar algumas escolhas criteriosas de design, ajuda de forma significativa o desenvolvimento de um código correto, rápido e de fácil manutenção. Uma das melhores práticas seria reutilizar o máximo possível de código de alta qualidade já existente e se utilizar das bibliotecas padrão inclusas em seu compilador. Segundo Tsui e Karam (2013, p. 141), procure conhecer e utilizar bem sua biblioteca para desenvolver códigos de alta qualidade em vez de reimplementá-lo em um novo código. Otimização de Desempenho

112 112 UNIDADE III REFATORAÇÃO Segundo Tsui e Karam (2013, p. 141), mesmo quando se utiliza as melhores práticas e se faz um esforço consciente para produzir softwares de alta qualidade, é altamente improvável que se produza consistentemente programas que não possam ser melhorados. Refatoração é a mudança de um código fonte, na estrutura interna do software visando melhorar o entendimento e a manutenibilidade sem alterar seu comportamento e suas funções externas. A refatoração surgiu quando alguns desenvolvedores foram analisar seus códigos para alterar ou incluir novas funcionalidades, eles começaram a verificar que os códigos já existentes estavam em shutterstock grande parte desestruturados, trechos repetidos e de difícil compreensão e manutenção. Conforme Tsui e Karam a respeito da refatoração, Martin Fowler (1999) popularizou o termo refatoração para referir-se à atividade de aprimoramento de seu estilo de código sem alterar o seu comportamento. Ele também utiliza este termo para cada uma das mudanças individuais que você pode efetuar para melhorar a estrutura de seu código. Fowler define um catálogo de sintomas indicando que o seu código precisa de refatoração (o que ele chama de maus cheiros ) e fornece um catálogo de refatoração úteis (TSUI; KARAM, 2013, p. 141). A refatoração é considerada uma das técnicas mais poderosa para a produção de um bom código. Tsui e Karam (2013, p. 141) citam o catálogo de maus cheiros fornecido por Fowler: Código duplicado mostrando desperdício. Método longo. Classe grande. IMPLEMENTAÇÃO DE SOFTWARE

113 113 Instruções switch (em linguagens OO, podem ser substituídas por polimorfismo, assim o código fica mais claro). Inveja da funcionalidade, quando um método tende a utilizar mais de um objeto de uma classe diferente a aquele que pertence. Intimidade inapropriada, na qual uma classe refere-se a partes privadas de outras classes. Para Tsui e Karam (2013, p. 142), qualquer um destes sintomas, bem como os outros que Fowler cita e aqueles que você desenvolverá, indicará que seu código pode ser melhorado. Você pode utilizar refatoração para ajudá-lo a lidar com estes problemas. Apesar de trazer benefício para um código fonte existente, a refatoração pode apresentar riscos se aplicada da forma errada, tais como: atraso do projeto, introdução de falhas no sistema, tornar o código ilegível e não modificável, portanto, é uma mudança que deve ser efetuada com cuidado. Quando os desenvolvedores começaram a analisar seus códigos para incluírem novas funcionalidades ou modificarem as já existentes, eles observaram que os códigos estavam em sua maioria desestruturados, de difícil compreensão, manutenção e com trechos duplicados. A refatoração surgiu por meio dessa observação. Algumas pessoas pensam que Refatoração é apenas uma limpeza de código, mas ela vai, além disso, porque fornece técnicas específicas para cada tipo de alteração. Então se forem usadas da forma correta deixa-o menos propenso a erros. Refatoração é a alteração de um código fonte, visando melhorar o entendimento e a manutenibilidade sem alterar suas funções externas. Apesar de trazer benefícios para um código fonte existente, a refatoração pode apresentar riscos se não aplicada da forma correta, tais como: atraso do projeto, introdução de falhas no sistema, tornar o código ilegível e não modificável. Fonte: Barrozo, Vinhas e Reis (2013). Refatoração

114 114 UNIDADE III CONSIDERAÇÕES FINAIS Nesta unidade, analisamos a importância da fase de implementação dentro do processo de desenvolvimento de software. Vimos algumas características de uma boa implementação, como: legibilidade, mantenabilidade, desempenho, rastreabilidade, exatidão e integridade. Foram apresentados aspectos sobre a codificação, como atribuir nomes de variáveis, comentários e vários outros itens importantes de uma boa implementação. Aprendemos que na fase de implementação temos algumas atividades adicionais que podem ser desenvolvidas para melhorar a qualidade do código e corrigir erros, como depuração, otimização de desempenho e refatoração. Ao longo da unidade, aprendemos que a implementação é a fase mais crítica do processo de desenvolvimento do software, pois criamos a versão executável do software e convertemos a especificação do sistema em um sistema executável. A fase da implementação é a escrita do sistema em uma linguagem de programação pelo programador. A Implementação, atualmente, pode utilizar linguagens de programação visuais e orientadas a objeto, com ambientes de desenvolvimento fáceis e amigáveis para o desenvolvimento dos códigos. Vimos que não basta saber programar em uma linguagem de programação para implementar um software, é necessário, também, conhecer e aplicar boas práticas de programação e usar ferramentas disponíveis para tornar esta fase mais eficiente e eficaz. Aprendemos como ocorre a codificação/programação dos requisitos de software, baseado nas definições técnicas analisadas na fase de projeto. Depois desta fase, com o conhecimento que já adquirimos de projeto e implementação, podemos passar para a próxima unidade e nos aprofundamos nos conceitos de teste de software, para juntos chegarmos ao final das fases que envolvem um processo de software e obtermos um sistema eficiente e com qualidade. Preparados? Então, continue sua leitura! IMPLEMENTAÇÃO DE SOFTWARE

115 Na fase de implementação, quais as atividades que são desenvolvidas? Assinale a alternativa correta. a. Codificação, depuração, compilação, integração e expressão. b. Codificação, depuração, fatoração, integração e testes. c. Codificação, depuração, compilação, integração e testes. d. Codificação, degustação, compilação, integração e testes. e. Codificação, depuração, compilação, concretização e testes. 2. Na fase de implementação desenvolvemos algumas tarefas que são utilizadas para iteração, revisões, integração, entre outras. I. Planejamento detalhado da implementação das unidades de cada iteração. II. Implementação das classes e outros elementos do modelo de projeto, geralmente arquivos de código fonte. III. Verificação das unidades, por meio de revisões, inspeções e testes de unidade. IV. Compilação, ligação das unidades e integração das unidades entre si e com componentes reutilizados. V. Abstração, refinamento, arquitetura, hierarquia de funções das unidades de cada interação. Assinale a opção com a sequência CORRETA. a. Somente a questão III está correta. b. Somente as questões I e II estão corretas. c. Somente as questões I, II, III e IV estão corretas. d. Todas estão corretas. 3. Quais as características que devem ser encontradas em uma boa implementação? Assinale a alternativa correta. a. Legibilidade, Mantenabilidade, Desempenho, Rastreabilidade, Classificação e Integridade. b. Legibilidade, Mantenabilidade, Integração, Rastreabilidade, Exatidão e Integridade. c. Legibilidade, Manutenção, Desempenho, Rastreabilidade, Exatidão e Integridade. d. Facilidade, Mantenabilidade, Desempenho, Rastreabilidade, Exatidão e Integridade.

116 Complete as lacunas no texto abaixo: é considerado um processo usado para reduzir ou no seu sistema. De uma forma geral, o código não é uma tarefa fácil de ser executada. Um dos motivos, é que podem ocorrer muitas que podem vir a atrapalhar esse processo, um exemplo é a linguagem que está sendo utiliza e ferramentas disponíveis para fazermos a de um código. 5. A refatoração é considerada uma das técnicas mais poderosas para a produção de um bom código. Tsui e Karam (2013, p. 141) citam o catálogo de maus cheiros fornecido por Fowler. I. Código duplicado mostrando desperdício, método longo, classe grande, Instruções switch. II. Inveja dos funcionários e dos programadores do código. III. Intimidade inapropriada, na qual uma classe refere-se a partes privadas de outras classes. IV. Decisões de como o sistema irá se comportar, em termos de: estrutura de cabos, hardware, infraestrutura de telefonia, a interface. V. Inveja da funcionalidade, quando um método tende a utilizar mais de um objeto de uma classe diferente a aquele que pertence. Assinale a opção com a sequência CORRETA. a. Somente a questão III está correta. b. Somente as questões I, II e IV estão corretas. c. Somente as questões I, II, III e IV estão corretas. d. Todas estão corretas.

117 117 REFATORAÇÃO DE APLICAÇÕES WEB: UM ESTUDO DE CASO Jean Carlos Dalcero, Bruno Batista Boniati 1. Introdução Com a evolução da Internet, a importância e demanda das aplicações Web aumentou muito, em especial nos últimos anos. Os sistemas defasados ou não planejados podem possuir inúmeras falhas e limitações. Porém, essas características podem ser melhoradas por meio de técnicas e normas padronizadas que surgiram para o melhoramento dessas aplicações, fazendo com que os sistemas possam ser desenvolvidos com facilidade no entendimento e inclusão de novas funcionalidades por parte dos desenvolvedores (...). 2. Refatoração O conceito de refatoração vem originalmente da comunidade de programação orientada a objetos, datando do início dos anos 90, mas sendo popularizada por Martin Fowler em 1999 com o livro Refactoring (Addison-Wesley, 1999). Fowler (1999) define refatoração como o processo de aperfeiçoamento do código-fonte de um sistema de software, tornando-o mais bem entendido, menos custoso na modificação e sem mudanças no comportamento externo (...). Baseando-se nesses conceitos pode-se dizer que refatoração é o emprego de técnicas para melhorar o projeto do software auxiliando na reestruturação do código fonte, visando promover atributos não funcionais de software, tais como extensibilidade, modularidade, reusabilidade, complexidade e eficiência. 3. Refatoração para Aplicações Web Técnicas de refatoração são amplamente utilizadas em linguagens de programação como Java e C. Porém, não é só código orientado a objetos ou linguagens orientadas a objetos que podem produzir código ruim e com necessidade de refatoração. Pode-se dizer que não somente linguagens de programação, mas qualquer sistema suficientemente complexo e mantido ao longo do tempo pode se beneficiar de refatoração. Em um sistema Web, o lado servidor de uma grande aplicação distribuída, funciona geralmente sobre uma base de dados relacional, enquanto que o lado cliente é uma ou mais páginas web, quase sempre construídas com códigos HTML (HyperText Markup Language), CSS (Cascading Style Sheets) e JavaScript. O HTML tornou o desenvolvimento dessas aplicações mais rápidas, mas não as tornou mais fáceis, mais simples ou menos complexas (...).

118 Validade A validade garante que somente elementos e atributos especificados no HTML apareçam, mostrando o mesmo conteúdo para usuários de diversos navegadores. Para Harold (2010), adicionar atributos alt em imagens é uma técnica de refatoração essencial, uma vez que dá assistência para usuários com deficiências de visão à medida que navegadores de áudio vierem embarcados em celulares, carros e outros dispositivos direcionados a esse público Leiaute Harold (2010) cita que usar a semântica adequada para cada elemento torna as páginas inteligíveis para leitores de tela e faz com que sejam mostradas apropriadamente para diferentes plataformas. Muitos elementos, como o table são usados abusivamente para tornar as páginas com aparência agradável. Atualmente, tem-se trabalhado bastante com o desenvolvimento de páginas Web utilizando o conceito tableless, ou seja, sem tabelas. O padrão de desenvolvimento com o CSS e tags div permite a separação da camada de apresentação, tornando a manutenção das páginas mais fácil, dentre outros benefícios Acessibilidade A web tem o poder de integrar à sociedade as pessoas com necessidades especiais. As páginas Web devem ser projetadas de modo que não precisem saber qual o tipo de dispositivo o usuário está utilizando, seja ele um monitor de vídeo ou um leitor de tela. Harold (2010) lembra que os usuários com limitações visuais que utilizam leitores de tela não podem usar o leiaute visual de uma página para determinar quais rótulos estão associados a quais campos. É preciso rotular, deixar explícito cada um dos campos não ocultos, de forma que eles sejam facilmente identificados pelos dispositivos. Para cada elemento visível do tipo input, textarea ou select, deve existir ao menos um elemento do tipo label associado.

119 Aplicações Web Atualmente, muitos sites não são mais apenas estáticos, são aplicações completas para entrada de dados, processamento de texto, jogos e muito mais. Com a evolução das aplicações vem também a necessidade de tornar as páginas mais rápidas e seguras, de modo que o usuário passe a utilizar essas ferramentas sem medo de que seus dados sejam expostos e que o sistema suporte toda a demanda requerida. Um exemplo de refatoração é a substituição de requisições GET inseguras por POST. As requisições GET utilizam a própria URL para enviar os dados para o servidor, essas requisições podem ser navegadas por robôs, pré-carregadas, armazenadas em cache, repetidas ou acessadas automaticamente. Operações inseguras como, por exemplo, cadastrar, alterar ou excluir um cliente, devem ser realizadas apenas via POST, evitando que os dados sejam manipulados sem o consentimento do usuário (...). Na questão segurança, usar sequência de escape para as entradas de usuário é fundamental. Atualmente, a fonte mais comum de falhas de segurança na Web é a injeção de código SQL (Structured Query Language). Harold (2010) cita que é provavelmente mais fácil encontrar um site baseado em banco de dados com uma vulnerabilidade de injeção de código SQL que um site que não possua uma. Harold (2010) ainda diz que a injeção de código SQL tem levado ao roubo de dados confidenciais de clientes, fraudes de cartão de crédito, phishing, spams e a quase todos os outros tipos de crimes auxiliados por computador que possamos imaginar (...). Fonte: Dalcero e Boniati (2014).

120 MATERIAL COMPLEMENTAR Fábrica de Software - Implantação e Gestão de Operações Aguinaldo Aragon Fernandes e Descartes de Souza Teixeira Editora: Atlas Sinopse: Este livro ensina como projetar, implantar e contratar uma fábrica de software, bem como estruturar uma plataforma de offshore de desenvolvimento de software. Trata-se de uma obra de referência para todos os que queiram entender melhor os aspectos que contornam uma operação de desenvolvimento de software em larga escala. A experiência vivida pelos autores e o conhecimento que trazem sobre tecnologia da informação representam inestimáveis fontes de informação para toda a comunidade brasileira da área. Padrões de Programação - Para Fábrica de Software, Analistas e Programadores Cláudio Rodrigues Editora: Ciência moderna Sinopse: Essencial para profissionais e estudantes de programação, Padrões de Programação traz os conhecimentos básicos para o desenvolvimento de softwares simples, baseando-se nos padrões de programação em questão. São apresentados os padrões, e como eles ajudam a projetar um software. O autor mostra também como aplicar cada um dos padrões, baseando-se em exemplos práticos e de fácil entendimento.

121 MATERIAL COMPLEMENTAR Refatoração para Padrões Joshua Kerievsky Editora: Bookman Sinopse: Este livro mostra a conexão entre padrões de projeto e refatoração, uma das práticas-chave de programação extrema (XP). Adotando padrões ao estilo do livro clássico de Gamma e cols, Padrões de Projeto, e usando código do mundo real, Kerievsky documenta o raciocínio e os passos que fazem parte de muitas das transformações de projeto baseadas em padrões. Inclui maneiras práticas de começar a trabalhar, de grande valor até para iniciantes em padrões ou refatoração. Não perca tempo escrevendo código perfeito Este artigo mostra que precisamos escrever bons códigos: código que seja compreensível, correto e seguro. Precisamos refatorá-lo, revisá-lo e escrever bons testes, sabendo o tempo todo que alguns trechos desse código, ou talvez todo o código, poderão ser jogados fora em breve. Temos que reconhecer que alguns dos nossos trabalhos serão necessariamente desperdiçados e otimizar nosso tempo pensando nisso. Faça o que precisa ser feito e nada mais. Não perca tempo tentando escrever o código perfeito. Confiram. Ótima leitura! Acesse o site e leia o artigo na íntegra. Disponível em: < nao-perca-tempo-escrevendo-codigo-perfeito/?trace= &source=single/>. Não otimize seu código Este artigo mostra de forma divertida, o porquê não devemos otimizar o código. Será? Mas aí podemos pensar: como é cruel quando um software é lento. Acredito que todos vocês, pelo menos alguma vez, já se irritaram com um software lento em algum estabelecimento. O que pode passar despercebido é que, além da irritação, a lentidão pode causar outros impactos, até mesmo na sociedade! Leia este artigo e dê a sua opinião. Boa leitura. Acesse o site abaixo e leia o artigo completo. Disponível em: < Material Complementar

122 MATERIAL COMPLEMENTAR Dicas para programar melhor Artigo muito interessante com dicas, seja para uma linguagem específica, seja para a área da programação. Não são dicas para todas as linguagens, entretanto, algumas por serem genéricas, podem ser fornecidas e servem como base para toda a área e não somente para esta ou aquela linguagem. É disto que este artigo trata: dicas de como programar melhor. Vamos lá? Leia o artigo completo acessando o site abaixo e veja o que o autor explica sobre este assunto. Muito legal. Boa leitura! Disponível em: < Como ser um bom programador O artigo mostra algumas dicas de como ser um bom programador. O autor mostra algumas qualidades e alguns esforços que fazem a diferença entre um bom programador e um programador mediano. Vale a pena ler Leia o artigo na íntegra acessando o site abaixo. Boa leitura! Disponível em: < aspx#ixzz3xhlt8gup>. Programe defensivamente com asserções Artigo sobre como se programar defensivamente com asserções e como utilizá-las. O autor faz uma comparação ao trânsito e como é dirigir defensivamente, isto é, se prevenir dos problemas antes que eles aconteçam, evitando situações que coloquem em risco você ou os demais. Muito interessante. Acesse o site e leia o artigo na íntegra. Disponível em: < programe-defensivamente-com-assercoes/>. Não se repita? DRY e o dilema entre código duplicado e alto acoplamento Artigo muito interessante sobre o princípio do não se repita. O princípio DRY ( não se repita ) busca reduzir a duplicação de código e os problemas de manutenção resultantes, mas quando é mal aplicado aumenta o acoplamento e atrapalha a leitura do código. Conheça a opinião de vários especialistas sobre o princípio, suas aplicações e armadilhas. Artigo muito interessante, leia na íntegra acessando o site abaixo. Disponível em: <

123 REFERÊNCIAS 123 BARROZO, G. C.; VINHAS, H. M.; REIS, J. C. de S. Refatoração: Aperfeiçoando Um Código Existente. Alfenas: UNIFENAS, BECK, K. Padrões de Implementação, Porto Alegre: Bookman, DALCERO, J. C.; BONIATI, B. B. Refatoração de Aplicações Web: Um Estudo de Caso. Anais do EATI: Encontro Anual de Tecnologia da Informação. Frederico Westphalen: 2014, p PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, SANTOS NETO, P. de A. dos. Modulo IV - Introdução à Engenharia de Software. Teresina: Universidade federal do Piauí, SECALL, J. M. Avaliação comparativa do impacto do emprego de técnicas de programação defensiva na segurança de sistemas críticos. São Paulo: Escola Politécnica, SOMMERVILLE, I. Engenharia de Software, São Paulo: Pearson Prentice Hall, TSUI, F. KARAM, O. Fundamentos de engenharia de software, 2 ed. Rio de Janeiro: LTC, VALENTIN, L. G.; DIAS, M. M.; PACHECO R. C. S. Questões importantes na implementação de software. Revista Tecnológica. v. 17, 2008, p Disponível em: < periodicos.uem.br/ojs/index.php /RevTecnol/article/download/7985/5161>.Acesso em: 25 mar

124 GABARITO 1. C - Codificação, depuração, compilação, integração e testes. 2. C - Somente as questões I, II, III e IV estão corretas. 3. C - Legibilidade, Manutenção, Desempenho, Rastreabilidade, Exatidão e Integridade. 4. Depurar é considerado um processo usado para reduzir ou encontrar bugs no seu sistema. De uma forma geral, depurar o código não é uma tarefa fácil de ser executada. Um dos motivos, é que pode ocorrer muitas variações que podem vir a atrapalhar esse processo, um exemplo é a linguagem que está sendo utilizada e ferramentas disponíveis para fazermos a depuração de um código. 5. B - Somente as questões I, II e IV estão corretas.

125 Professora Esp. Janaína Aparecida de Freitas TESTE DE SOFTWARE UNIDADE IV Objetivos de Aprendizagem Definir Teste de software, seus objetivos e seus conceitos. Estudar os conceitos sobre defeitos e níveis de teste de software. Apresentar a documentação usada nos testes de software e suas técnicas. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: Introdução ao Teste de Software Conceitos básicos de Teste de Software Ciclo de Vida do Teste de Software Técnicas de Teste de Software Papéis e Cargos de Teste de software Ambiente de teste

126

127 127 INTRODUÇÃO Olá Aluno (a)! Vamos para mais uma unidade de estudos? Avançando em nosso aprendizado sobre as fases do processo de desenvolvimento de software, vamos estudar a fase de Teste de Software e entender porque ela é importante e essencial para garantir a qualidade do software. Nesta unidade, vamos aprender que o principal objetivo do teste de software é auxiliar na busca de um produto de software com o mínimo de erros possíveis. Para realizarmos esta tarefa, faz-se necessário o uso de ferramentas que auxiliem no processo de teste de software. Mas você, aluno(a), deve se perguntar: por que se faz necessário testes em software? Imagino que você tenha acesso a diferentes softwares diariamente, por exemplo, aplicações bancárias, sejam elas acessadas pela web, celular ou caixa eletrônico, entre outras. Você poderia imaginar o desastre se essas aplicações não fossem muito bem testadas? Você se sentiria seguro em realizar uma transação bancária pela web? Acho que não, certo? Esses exemplos servem para mostrar que softwares que não funcionam corretamente e que não foram testados podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam. Mas vamos pensar, falhas podem ocorrer, certo? E, neste caso, temos vários tipos de falhas, por eventos externos ao software, como quedas de luz, radiação, calor, poluição, campos magnéticos ou eletrônicos e muitos outros. Por outro lado, algumas causas dos problemas de software que são encontrados podem ser causadas por erros ou enganos humanos. Esse erro gera um defeito (bug) no software, e o bug gera uma falha no sistema. Vamos aprender nesta unidade também, que os testes têm funções específicas em cada fase do desenvolvimento do software. Além disso, servem para reduzir os riscos de ocorrências de problemas e erros no ambiente do usuário e isso pode representar a confiabilidade do software. Boa leitura! Introdução

128 128 UNIDADE IV shutterstock INTRODUÇÃO AO TESTE DE SOFTWARE O teste é uma atividade de verificação e validação do software e consiste na análise dinâmica, isto é, na execução do produto de software com o objetivo de verificar a presença de defeitos no produto e aumentar a confiança de que está correto. Hoje existe uma crescente preocupação pela necessidade de melhoria do software, percebida pelas próprias empresas, seja por exigência do mercado ou pelos clientes, como você, que utilizam esses softwares. Uma das formas das empresas melhorarem a qualidade do software por elas desenvolvido é por meio da implantação equipes de testes, cujo o objetivo é testar os sistemas produzidos e atingir um nível de qualidade aceitável e em um espaço de tempo cada vez menor. Entretanto, quando uma empresa desenvolvedora de software busca garantir a qualidade, ela percebe que é necessário investir pesado em testes de software. Levando em conta que existem vários tipos de testes no mercado para atender as suas necessidades, a empresa deve levar em conta que pode ser preciso implantar mais de um tipo ou investir em métricas de software para garantia da qualidade desses testes. TESTE DE SOFTWARE

129 129 Para Sommerville (2011, p. 144), o teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Conforme Sommerville, quando se testa o software, devemos executar o programa e incluir dados fictícios (simular como se fosse um usuário) e os resultados do teste são utilizados para procurar erros, anomalias ou se algum atributo não estiver funcionando adequadamente. Segundo Pressman (2011, p. 427), uma vez gerado o código fonte, o software deve ser testado para descobrir (e corrigir) tantos erros quanto possível antes de fornecê-lo ao seu cliente. Mas você deve estar se perguntando: Por que testar? Quando é preciso testar? Como testar? E quando os testes devem começar? Para responder a estas dúvidas, vamos ver o que pensa Tsui e Karam (2013, p. 147). Os autores afirmam que os testes de software geralmente possuem dois objetivos principais: Os testes devem encontrar defeitos no software, para que eles possam ser corrigidos ou minimizados. Os testes fornecem uma avaliação geral de qualidade e uma estimativa das possíveis falhas. Para Tsui e Karam (2013), exceto os programas mais simples, os testes de software não podem provar que um produto funciona e sim que ele pode apenas encontrar defeitos e que ele funciona para as situações em que foi testado, mas sem garantir seu funcionamento em outras situações que não foram testadas. Mas se os testes não foram executados de forma correta? Nesse caso, pode fornecer alguma garantia de que o software irá funcionar para as situações semelhantes às dos testes, não temos, porém, como provar que o software irá funcionar para todos os casos. Vale ressaltar que, mesmo se um teste não detectar defeitos, isso não quer dizer necessariamente que o produto não é um produto de boa qualidade. Muitas vezes, a atividade de teste empregada pode ter sido conduzida sem planejamento, sem critérios e sem uma sistemática bem definida, sendo, portanto, os testes de baixa qualidade. Ainda que os testes não possam demonstrar a ausência de defeitos, como benefício secundário, podem indicar que as funções do software parecem estar funcionando de acordo com o especificado. Introdução ao Teste de Software

130 130 UNIDADE IV Passamos agora a conhecer algumas definições de teste: Testar é verificar se o software está fazendo o que deveria fazer, de acordo com seus requisitos, e não está fazendo o que não deveria fazer (RIOS; MOREIRA, 2013). Testar é o processo de executar um programa ou sistema com a intenção de encontrar defeitos (teste negativo) (MYERS, 1979). Testar é qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema, seja possível determinar se ele alcança os resultados desejados (HETZEL, 1998). De acordo com Pressman (2011), todo software que se destina ao público e/ou ao mercado deve sofrer um nível mínimo de teste. Assim, quanto maior o nível de complexidade do software, mais testes e técnicas de testes se tornam necessários para a obtenção da sua qualidade. Segundo Tsui e Karam (2013, p. 147), os testes de software consistem na verificação dinâmica do comportamento de um programa com base em um conjunto finito de situações de teste, selecionado de forma apropriada a partir do habitualmente infinito domínio de execuções, em relação ao comportamento esperado. Um testador bem treinado, com experiência prática e com o espírito aberto para novos aprendizados dificilmente será derrotado. (Rios). Mas como toda atividade complexa que possui muitas ações, o teste deve ser planejado, ter seus objetivos determinados, a definição de quais metodologias e técnicas devem ser aplicadas, e de quais recursos e ferramentas devem ser utilizados para executar os testes. TESTE DE SOFTWARE

131 131 Portanto, teste é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente. Por essa razão, deverá ser definido para o processo de software um modelo, que pode ser chamado de template para o teste. Nesse template criamos um conjunto de etapas no qual pode-se colocar técnicas específicas de caso de teste e métodos de teste. Para Sommerville (2011, p. 144), o processo de teste apresenta dois objetivos distintos: 1. Demonstrar ao desenvolvedor e ao cliente que o software atende seus requisitos. 2. Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente do que foi especificado. No próximo tópico, vamos conhecer os conceitos básicos utilizados na fase de teste de software. Boa leitura! O teste, da maneira como é executado pela maioria das empresas como uma etapa dentro do processo de desenvolvimento e, em geral, executado pelos próprios desenvolvedores e pelos usuários do sistema, serve apenas para garantir que as especificações ou os requisitos do negócio foram de fato implementados. Como o processo de desenvolvimento cria produtos com defeitos, necessário se faz descobrir esses defeitos. Em um modelo de garantia de qualidade, isso é suficiente. Quem poderia garantir que um software testado pelos próprios desenvolvedores está corretamente testado? Com toda a certeza, existem exceções, mas a melhor maneira de testar um software é ter um processo de teste claramente definido. Os defeitos existentes nos softwares, na maior parte das vezes, constituem-se em riscos tanto para o negócio, quanto para a imagem da empresa. Fonte: Bastos, Rios, Cristalli e Morreira (2007). Introdução ao Teste de Software

132 132 UNIDADE IV shutterstock CONCEITOS BÁSICOS DE TESTE DE SOFTWARE Alguns conceitos que envolvem testes de software devem ser entendidos para facilitar o entendimento desse processo. Conforme Bastos et al. (2007, p. 283), Erro: resultado de uma falha humana. Defeito: resultado de um erro existente num código ou num documento. Conforme a terminologia padrão para Engenharia de Software do Institute of Electrical and Electronics Engineers (IEEE), defeitos são considerados parte do universo físico, provocados por pessoas e que podem levar a ocasionar erros em um software, fazendo com que ele fique diferente do que foi especificado. Resumindo, os erros provocam e geram falhas no sistema, e estas causam um comportamento que não se esperava e que pode afetar e inviabilizar a utilização de um software. Para alguns autores, o conceito de defeito é: É uma não conformidade em relação ao que o software se propõe a fazer, que diz que faz e não faz (MOLINARI, 2003). Resultado de um erro existe num código ou num documento (BAS- TOS et al., 2007). TESTE DE SOFTWARE

133 133 Quando executamos testes em um software, podemos demonstrar a presença de defeitos, mas não podemos provar que eles não existem. Você concorda com isso? Os testes quando executados, reduzem a probabilidade dos defeitos ocorrerem em um sistema, mas não garante que ele esteja perfeito e livre de defeitos. Para Bastos et al. (2007), os defeitos são resultados de erros existentes no software desenvolvido por pessoas. Segundo ele, devemos ter por base os seguintes princípios: O objetivo primordial é evitar defeitos. Ao testarmos os requisitos, estamos tentando evitar que defeitos ocorram em outras fases do desenvolvimento do software. Evitar defeitos é minimizar os riscos, não só os do projeto de desenvolvimento do software como também os do projeto de teste. Integração com os desenvolvedores, para que as duas equipes atuem em conjunto e harmonia. Para entendermos bem os defeitos, Bastos et al. (2007) descreve que um defeito pode ocorrer em função de desvios do que foi levantado na análise de requisitos. Segundo ele, temos: Defeitos decorrentes da falta de concordância com a especificação do produto Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto. Conforme Rios e Moreira (2013), temos alguns tipos de defeitos que podem ser: Defeitos de interface com os usuários: são defeitos gerados de funcionalidade, usabilidade, desempenho e resultados (saídas). Defeitos introduzidos no tratamento de defeitos: esses defeitos podem ser subdivididos em: prevenção de defeitos, detecção de defeitos e recuperação de defeitos. Defeitos de Limite: defeitos de valores extremos (maior, menor etc.) ou fora dos limites estabelecidos. Conceitos Básicos de Teste de Software

134 134 UNIDADE IV Defeitos de Cálculo. Defeitos de Controle de Fluxo. Defeitos de Inicialização ou fechamento. Defeitos de Manuseio ou interpretação de dados. Defeitos de condição de disputa. Defeitos de carga. Defeitos de hardware ou software. Defeitos de controle de versão. Existem outros tipos de defeitos, dependendo de como são classificados. É interessante a empresa ter uma lista com os tipos de defeitos e ir adicionando ou classificando conforme os defeitos forem surgindo e assim, facilitando as correções e prevenções dos defeitos. Pois, conforme Bastos et al. (2007), a maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software. Preparados para o próximo tópico? Vamos aprender sobre o Ciclo de vida do teste de software. Vamos seguir com a leitura! Saber identificar a importância dos defeitos é fundamental para entender o impacto que eles causarão no sistema e nos negócios. (Bastos et al). TESTE DE SOFTWARE

135 135 É preciso rastrear a origem dos defeitos, visando identificar a origem do problema. Entretanto, uma vez identificada a origem do problema, as ações tomadas jamais deverão visar punir alguém e sim melhorar os processos. A importância de um defeito está diretamente relacionada à frequência com que ele ocorre, ao custo para corrigi-lo, ao custo para identifica-lo e a sua correspondência para o sistema e para os negócios. Frequência: com que frequência esse tipo de bug ocorre? Custo da correção: qual o custo para corrigir o defeito após a sua ocorrência? Custo da instalação: qual o custo de disponibilizar a atualização para todos os clientes? Esse custo depende do número de instalações? Consequência: qual é a consequência desse defeito? O que acontecerá na ocorrência desse defeito? Fonte: Bastos, Rios, Cristalli e Moreira (2007). CICLO DE VIDA DO TESTE DE SOFTWARE Conforme Bastos et al. (2007, p. 29), quanto antes os testes iniciarem, mais barato será corrigir defeitos encontrados. Para que isso seja possível, é preciso que o processo de teste, assim como o processo de desenvolvimento, tenha também um ciclo de vida. As etapas do Ciclo de Vida de Teste de Software são: 1. Planejamento. 2. Preparação. 3. Especificação. 4. Execução. 5. Entrega. shutterstock Ciclo de Vida do Teste de Software

136 136 UNIDADE IV Segundo Bastos et al. (2007), pode existir outras etapas no Ciclo de Vida de testes, mas a estrutura básica consiste sempre na mesma, mudando apenas a terminologia usada. Mas os autores ressaltam que além de uma metodologia de teste, baseada em ciclo de vida de testes, deve ser compatível com a metodologia usada para o desenvolvimento do sistema. Figura 1: Modelo de Integração entre os processos de desenvolvimento e Teste Modelo de Integração entre os processos de desenvolvimento e teste P l a n e j a m e n t o Teste Especificação Execução (1) Execução (2) Gerência de Requisitos Validação Teste Unitário Teste de Sistema e Teste de Integração Desenvolvimento Desenho Lógico e Físico Construção Implantação P l a n e j a m e n t o Entrega Teste de Aceitação Entrega Fonte: Rios e Moreira (2013). TESTE DE SOFTWARE

137 137 Agora vamos conhecer cada etapa do Ciclo de Vida de testes: Planejamento: nessa etapa é elaborada a Estratégia de Teste e o Plano de Teste a ser utilizados. Esta etapa deve permanecer ativa até que o projeto seja concluído. Preparação: o objetivo dessa etapa é preparar o Ambiente de Teste (equipamentos, pessoal, ferramentas de automação, base de testes) para que os testes sejam executados conforme planejados. Especificação: nessa etapa temos as seguintes atividades: elaborar/ revisar casos de testes e elaborar/ revisar roteiros de testes. Eles serão elaborados à medida que a equipe de desenvolvimento libera os módulos ou partes para o teste. Execução: nessa etapa os testes são executados e os resultados obtidos são registrados. Entrega: nessa etapa o projeto é finalizado e toda documentação é finalizada e arquivada. Figura 2: Planejamento e Controle Procedimentos iniciais Planejamento e Controle Especificação Preparação Entrega Entrega Fonte: Rios e Moreira (2013). Conforme Rios (2008), quem testa um software sem fazer um plano de teste não vai conseguir fazer um procedimento bem feito. O planejamento dos testes permite ao gerente de teste prever situações futuras, tais como as necessidades de ambiente, de recursos humanos, dentre outros, que precisam ser tratados sempre como um projeto e como tal precisa ser planejado. Um trabalho bem planejado com um bom plano de teste bem feito, evitará muitas vezes inúmeras pressões a que o testador ou a equipe de teste estará submetido. Ciclo de Vida do Teste de Software

138 138 UNIDADE IV No próximo tópico, vamos definir as diversas técnicas de teste que podem ser aplicadas. Boa leitura. Ao considerar que o desenvolvedor comete erros banais muitas vezes deixamos de entrar fundo nos seus testes, que também acabam sendo negligenciados. (Rios). O processo de avaliação de um sistema demanda planejamento. Esse é o passo inicial para delimitar as tarefas do processo, tais como os tipos de testes que serão realizados, a partir da proposta de desenvolvimento. No planejamento são especificados os casos de teste. Estes podem ser definidos a partir dos casos de uso, podendo ser do tipo negativo (ações imprevistas) e positivo (ações previstas). A aplicação prática de testes de software somente é possível com a definição e aplicação de diretrizes mínimas a serem seguidas pelas equipes técnicas da instituição. É importante que os testes de software cubram todos os aspectos de um sistema, desde suas interfaces até as linhas de código. A revisão detalhada, sistêmica e auxiliada de roteiros, procedimentos e checklists, de um sistema permite o amadurecimento da solução antes de sua efetiva liberação, evitando transtornos e problemas maiores, garantindo segurança, qualidade, eficiência e satisfação. Fonte: Primão, Ribeiro e Kreutz (2010). TESTE DE SOFTWARE

139 139 TÉCNICAS DE TESTE DE SOFTWARE Técnicas de teste são procedimentos técnicos e gerenciais que ajudam na avaliação e melhorias do processo. Conforme Bastos et al. (2007, p. 49), a realização dos testes deve refletir as ações tomadas para descobrir erros introduzidos na codificação das funcionalidades definidas nas especificações dos programas e outros erros inseridos durante a codificação do programa. Conforme Tsui e Karam (2013), há uma grande variedade de técnicas de teste, aplicáveis a diferentes circunstâncias. Elas podem ser utilizadas para classificar diferentes conceitos de testes, técnicas de design de situação de testes, técnicas de execução de teste e organizações de testes. A técnica de testes estrutural tende a revelar erros que ocorrem durante a codificação do programa, garante que a implementação de uma funcionalidade será toda testada na shutterstock codificação. A análise estrutural deve ser utilizada em todas as fases do ciclo de desenvolvimento do software. A fase de testes de software é dividida em dois tipos: Os testes funcionais garante o atendimento aos requisitos, ou seja, que os requisitos estão corretamente codificados. São conhecidos como testes de Caixa Preta. Figura 3: Técnica de Teste Funcional? Fonte: Pressman (2011). Técnicas de Teste de Software

140 140 UNIDADE IV Os testes estruturais garantem que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico em que serão instalados. São conhecidos como testes de Caixa Branca. Figura 4: Técnica de Teste Estrutural? Fonte: Pressman (2011) Cada um desses testes possuem várias técnicas que ajudam o processo a assegurar o funcionamento adequado de alguns aspectos do sistema ou da unidade. TESTE ESTRUTURAL Para Bastos et al. (2007) o objetivo principal dos testes estruturais é garantir que o produto seja estruturalmente sólido e que funcione corretamente. As técnicas para esse tipo de teste são desenhadas, não para garantir que o sistema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto. Sendo assim, os testes estruturais ou caixa-branca estabelecem os objetivos do teste com base em uma determinada implementação, analisando os detalhes do código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações originadas por estruturas de condições/repetições são testadas. Conforme Bastos et al. (2007), as técnicas podem ser divididas de acordo com o tipo de teste: Testes de carga: verifica o volume de dados que um sistema consegue processar. Ele permite monitorar o comportamento do sistema diante de uma situação onde há um grande número de acessos simultâneos. Testes de conformidade: são realizados para garantir a conformidade com as metodologias e encorajar e auxiliar os profissionais de TI adotá- -las. Avalia-se a documentação do sistema de aplicação é racional e está TESTE DE SOFTWARE

141 141 completa, garante a conformidade aos padrões, procedimentos e guias de TI e verifica se as metodologias de desenvolvimento e de manutenção são seguidas. Testes de desempenho (performance): verifica o desempenho do sistema em um cenário previsto de baixa ou média carga. Por meio dele é possível mensurar o tempo de resposta ao acionar os comandos disponíveis e obter informações a respeito dos recursos físicos necessários num cenário comum de funcionamento. Testes de estresse: seu objetivo é avaliar o comportamento do software sobre condições críticas, tais como restrições significativas de memória, de área de disco e de CPU. Transações, tabelas internas, espaço em disco, saídas, capacidade do computador e interação com pessoas são aspectos que devem passar pelo teste de estresse. Testes de execução: são desenhados para avaliar o comportamento do sistema no ambiente de produção e verificar se são atendidas as premissas de desempenho estabelecidas. Os testes de execução verificam os tempos de resposta, os tempos de processamento e desempenho. Testes de operação: são desenhados principalmente para estabelecer se o sistema é executável durante a operação normal. Ele determina se a documentação da operação está completa, garante os mecanismos de suporte, avalia o treinamento dos operadores e testa se os operadores estão usando a documentação preparada, e se conseguem efetivamente operar o sistema. Testes de recuperação (contingência): recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação. O teste de recuperação é responsável por garantir a continuidade das operações após um desastre, o teste de recuperação não só verifica o processo de recuperação como também a eficácia das partes componentes do processo. Testes de segurança: são desenhados com o intuito de avaliar a adequação dos procedimentos de proteção e as contramedidas projetadas. Os defeitos de segurança não aparecem de maneira tão óbvia como os demais, assim os testes de segurança visam descobrir defeitos muito difíceis de identificar. Técnicas de Teste de Software

142 142 UNIDADE IV TESTE FUNCIONAL Para Bastos et al. (2007), os testes funcionais são desenhados para garantir que os requisitos e as especificações do sistema tenham sido atendidos. Os testes funcionais ou caixa-preta utilizam as especificações (de requisitos, análise e projeto) para definir os objetivos do teste e, portanto, para guiar o projeto de casos de teste. No teste funcional, o componente de software a ser testado é abordado como se fosse uma caixa-preta sem considerar o comportamento interno do mesmo. Entre os tipos de técnicas na execução dos testes funcionais temos: Teste de controle: ele garante que os dados estejam completos e corretos, as transações sejam autorizadas, a manutenção das informações da trilha de auditoria seja realizada, os processamentos sejam eficientes, eficazes e econômicos e que atendam às necessidades dos usuários. Teste de interconexão: são desenhados para garantir que a interconexão entre os softwares de aplicação funcione corretamente. Determina se os parâmetros e dados são transferidos corretamente entre os softwares, garante o momento certo de execução e a existência de coordenação das funções entre os softwares e se a documentação pertinente é correta e completa. Testes paralelos: serve para determinar se os resultados de um novo software de aplicação são consistentes com o processamento do antigo sistema ou da antiga versão do sistema. Ele ajuda a assegurar que a nova versão do software execute corretamente e que demonstre consistências e inconsistências entre as duas versões. Testes de requisitos: verificam se o sistema executa corretamente as funcionalidades e se ele é capaz de sustentar essa correção após sua utilização por um período de tempo contínuo. Testes de regressão: eles voltam a testar segmentos de códigos já testados após a implementação de uma mudança em outra parte do software. Sempre que ocorrem mudanças em um segmento de código, problemas podem surgir em outros segmentos já testados. TESTE DE SOFTWARE

143 143 Testes de suporte manual: verificam se os procedimentos de suporte manual estão documentados e completos, determinam se as responsabilidades pelo suporte manual foram estabelecidas, se o pessoal que dará suporte manual está adequadamente treinado e se ele está interligado apropriadamente com o segmento automatizado. Testes de tratamento de erros: eles determinam a capacidade do sistema de tratar apropriadamente transações incorretas, se todas as condições de erro esperadas são reconhecidas pelo sistema, se foi atribuída responsabilidade para processar os erros identificados e se é mantido um controle razoável sobre os erros durante o processo de correção. Na tabela 1 podemos ver uma lista com alguns outros tipos de testes que podem ser utilizados: Tabela 1: Alguns Tipos de Teste TIPO DE TESTE Teste de Unidade Teste de Integração Teste Positivo-negativo Teste de caixa-preta Teste caixa-branca Teste de Interface Teste de aceitação do usuário Teste de Volume DESCRIÇÃO Teste em um nível de componente ou classe. É o teste cujo objetivo é um pedaço do código. Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é composto por diversos testes de unidade. Garante que a aplicação vai funcionar no caminho feliz de sua execução e vai funcionar no seu fluxo de exceção. Testar todas as entradas e saídas desejadas. Não se está preocupado com o código, cada saída indesejada é vista como um erro. O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas. Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário. Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes (aqui, cabem quesitos fora da interface também). Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande ou além de grande). Técnicas de Teste de Software

144 144 UNIDADE IV Testes de Configuração Testes de Instalação Teste de sistemas Teste de Usabilidade Testes de Progressão Teste de Fumaça Fonte: Bastos et al. (2007) Testar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software. Testar se a instalação da aplicação foi OK. Testar a execução do sistema como um todo para validar a exatidão e perfeição na execução de suas funções Testar e simular as condições de utilização do software sobre a perspectiva do usuário final. Esses testes focalizam a facilidade de navegação entre as telas, clareza dos textos e as mensagens que são apresentadas aos usuários, dentre outros aspectos da interface do sistema. Testa apenas as funcionalidades (ou requisitos não funcionais) especificados para a versão. Teste que consiste em um teste rápido, executando as principais funcionalidades do sistema, sem se preocupar com as condições de erro. O mesmo que teste do Caminho Feliz. Outras técnicas de teste podem e devem ser utilizadas de acordo com a necessidades da empresa. Conforme Pressman (2011), algumas técnicas se destacam, por exemplo: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade e teste de recuperação. Em alguns livros, alguns autores mostram a definição de uma técnica de teste chamada de caixa cinza, que mescla as técnicas de caixa preta e caixa branca. Preparados para o próximo tópico? Vamos conhecer os papéis e cargos para quem participa nos projetos de teste de software. Boa leitura! Nos testes os riscos servirão de elemento de definição dos níveis de prioridade do projeto. (Bastos et al.). TESTE DE SOFTWARE

145 145 Uma das maneiras de priorizar os testes de um software é analisar os principais riscos para o negócio que uma determinada falha poderia causar. Vamos supor que, em um dado software, um dos requisitos do produto seja um tempo de resposta adequado à necessidade do negócio. O usuário do software definiu um tempo de resposta por página em torno de dois ou três segundos. O usuário desse sistema concluiu, após estudos de mercado, que um tempo de resposta superior a dois ou três segundos poderia levar os clientes a desistir do negócio. Para minimizar esse risco, é preciso fazer um teste de performance, simulando as condições reais, para verificar o comportamento do software. Claro que também seria necessário simular um número definido de usuários acessando o software ao mesmo tempo. Com isso queremos dizer, portanto, que um dos riscos para o negócio seria um tempo de resposta superior a dois ou três segundos. Fonte: Bastos et al. (2007). PAPÉIS E CARGOS DE TESTE DE SOFTWARE Nessa seção trataremos sobre alguns papéis que uma pessoa pode desenvolver em um projeto de teste de software. Ela poderá acumular mais de um dos papéis que serão citados, de acordo com suas características e restrições do projeto que está sendo desenvolvido. O Teste de Software possui algumas nomenclaturas de cargos definidos como default para área, mas alguns autores e especialistas da área podem mostrar com algumas variações. shutterstock Papéis e Cargos de Teste de Software

146 146 UNIDADE IV Na Tabela 2, é mostrada a Matriz de Responsabilidade com as funções que cada um deve desenvolver na fase de testes: Tabela 2 Matriz de responsabilidades Líder do Projeto de Testes É o técnico responsável pela liderança de um projeto de testes especifico, normalmente, seja um projeto novo ou um de manutenção. Arquiteto de Teste Analista de Teste Testador Fonte: Rios (2013). É o técnico responsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e capacitando a equipe para executar o seu trabalho nesse ambiente de teste. É o técnico responsável pela modelagem e elaboração dos casos de Teste e pelos scripts de teste. Pode ser que em alguns casos os scripts sejam elaborados pelos testadores. Técnico responsável pela execução dos casos de teste e scripts de teste. Qual o perfil de um bom testador? Um bom testador deve ser explorador, resolver problemas, ser incansável, ser criativo, ser perfeccionista, exercitar o julgamento, ser diplomático e também ser persuasivo. Conforme Rios (2008, p. 40), o trabalho do testador é muitas vezes estressante e cansativo. Encontrar defeitos num software não é fácil e envolve atenção e cuidado. O bom testador deve ter o perfeito controle do seu trabalho para poder negociar nessas condições de alta pressão. O bom testador deve conhecer o processo de desenvolvimento do software no qual está inserido, pois suas atividades fazem parte desse processo. O testador deve conhecer quais são os artefatos de entrada e saída de cada fase do processo, principalmente das que envolvem atividades de testes. Segundo Tsui e Karam (2013, p. 147), um testador é um profissional técnico cuja função para o item em particular sob teste é simplesmente compor situações de teste e garantir sua execução. Embora o conhecimento de programação seja extremamente útil para os testadores, os testes constituem uma atividade diferente com requisitos intelectuais diferentes. TESTE DE SOFTWARE

147 147 Esses são os perfis mais conhecidos, mas algumas empresas podem utilizar outros como, por exemplo: automatizador de testes, analista homologador, entre outros. Vamos seguir em frente? No próximo tópico vamos conhecer como é o ambiente em que os testes de software são desenvolvidos. Bons estudos! Um grupo independente de teste não tem o conflito de interesses que os criadores de software podem ter. (Pressman). O teste executado por uma equipe independente, mas integrada à equipe de desenvolvimento, precisa ter um projeto e um líder para que seja conduzida até o sucesso final. Nesta visão, o líder de teste deve estar alocado tão logo o plano de projeto comece a ser elaborado. Nunca é demais lembrar que a utilização de desenvolvedores como os próprios testadores nunca deu certo e dificilmente irá funcionar, pois é como deixar a raposa tomar conta do galinheiro. Os desenvolvedores tendem a usar métodos informais e incompletos de teste, o que permite que os problemas ocorram só quando o sistema é liberado para a produção. Muitas vezes, esses problemas poderão aparecer meses ou até anos depois, quando a equipe de desenvolvimento já estiver alocada em outro projeto ou até em outra empresa. Testar o software usando os desenvolvedores como testadores sai mais caro do que montar uma equipe específica de teste. Fonte: Bastos et al. (2007). Papéis e Cargos de Teste de Software

148 148 UNIDADE IV shutterstock AMBIENTE DE TESTE O ambiente de testes é um conjunto específico de configurações de hardware, software e outros ambientes necessários para a execução de testes mais precisos e que simulem o ambiente do usuário. Conforme Bastos et al. (2007, p. 77) o ambiente de teste tem uma relação direta com a estratégia de teste adotada no projeto. O ambiente não é apenas uma configuração de hardware, mas toda a estrutura em que o teste será executado. As configurações do ambiente de teste nos fornece uma ideia de como conduzir os testes necessários e como serão as atividades de avaliação. Fornecer um ambiente conhecido e controlado para a condução desses testes ajuda a assegurar que os resultados sejam precisos e válidos na busca de falhas e resolução de erros. TESTE DE SOFTWARE

149 149 Figura 5: Ambiente de Teste de Unidade Módulo a ser testado Pseudocontrolador Interface Estruturas de dados locais Condições de fronteira Caminhos independentes Caminhos de manipulação de erro Pseudocontrolados Fonte: Pressman (2011). Pseudocontrolados RESULTADOS Casos de teste Conforme Bastos et al. (2007), o escopo do ambiente poderá ser definido pelo nível de teste a ser executado: Quanto maior o nível: o ambiente de teste deverá ser capaz de reproduzir as características do ambiente de produção. Ainda segundo os autores, o ambiente de teste pode e deve ser planejado em duas fases do ciclo de vida do projeto de teste: na estratégia de teste e no plano de teste. Figura 6: Fluxograma de teste Definição da estratégia de testes Criação do ambiente de testes Gerenciamento do processo de testes (indicadores de desempenho) Planejamento dos testes dinâmicos Fonte Bastos et al. (2007). Execução dos testes dinâmicos Ambiente de Teste

150 150 UNIDADE IV Para Bastos et al. (2007), a distribuição da preparação do ambiente pode se dar em: fases, estágio ou níveis de teste: Teste unitário: estágio mais baixo da escala de testes e aplicado aos menores componentes de código. Teste de integração: aplicado à combinação das unidades de componentes. Teste de sistema: aplicado ao sistema como um todo. Teste de aceitação: teste final do sistema de funcionalidade e usabilidade. VOLUME DOS DADOS Segundo Bastos et al. (2007, p. 81), é a criação de um ambiente o mais real possível, tendo como base o escopo do teste. Isso inclui o volume de dados de teste. O volume de dados está diretamente relacionado à necessidade e à abrangência da massa de teste para cada fase ou estágio, nas etapas iniciais (unidade e integração) não existe a necessidade de uma grande quantidade de dados para exercitar a aplicação, mas nas fases de sistema e aceitação, é necessário um grande volume para garantir a qualidade dos testes. Bastos et al. (2007) definem que a técnica e o tipo de teste que estão sendo executados nos diferentes estágios também são fatores importantes nesse processo. Por exemplo: para um teste de carga ser executado, é necessário um grande volume de dados e que este seja criado de maneira estruturada e o mais próximo possível da realidade. A criação de um ambiente isolado, organizado, representativo e mensurável para os testes garante a descoberta de erros reais, que realmente poderiam acontecer na produção e que foram descobertos ainda em tempo de desenvolvimento. Conforme Bastos et al. (2007, p. 83), é preciso que a preparação do ambiente seja discutida o quanto antes, e suas necessidades básicas (equipamentos, softwares, browsers, etc) devem ser identificadas no momento inicial do projeto. Com o andamento do projeto de testes, esse ambientes ganham mais detalhes e começam a ser implementados, mais a frente, na fase de implementação do teste, o volume de dados será criado e o ambiente previamente estabelecido será utilizado para executar os cenários de teste elaborados. TESTE DE SOFTWARE

151 151 Segundo Bastos et al. (2007), ao definirmos o ambiente de teste devemos considerar: O sistema operacional. A arquitetura do sistema. A identificação dos componentes. O meio de acesso ao sistema. A linguagem de programação utilizada. A conectividade entre os ambientes. Para Mecenas e Oliveira (2005), os ganhos para o processo de qualidade dos projetos com a criação de um ambiente independente são: Ambiente controlado. Dados íntegros. Base de dados reduzida. Utilização de massa de dados construída e não real. Facilidade no gerenciamento. Testes não tendenciosos. Trabalhar na prevenção dos erros e não na correção deles. Garantia da utilização das normas e dos padrões especificados. Teste de todos os módulos e não apenas dos que sofreram alteração, garantindo que nada tenha sido alterado após a manutenção. A criação desses ambientes libera a equipe de desenvolvimento para continuar produzindo novos códigos, sem prejuízo à integridade do ambiente, mesmo durante a execução dos testes, e possibilita a realização dos testes de iteração e sistema, de modo a permitir a integração das diferentes camadas e/ou ambientes. Ambiente de Teste

152 152 UNIDADE IV Projete testes para executar todos os caminhos de manipulação de erro. Se não fizer isso, o caminho pode falhar quando for solicitado, piorando uma situação já ruim. (Pressman). O teste de software é uma das atividades que buscam contribuir para a melhoria da qualidade do software. O teste revela a presença de defeitos no software e atende as exigências de qualidade de software. O objetivo do presente trabalho foi esclarecer como o teste de software influência a qualidade do software no mercado. A metodologia utilizada para desenvolvimento do trabalho foi baseada em revisão bibliográfica, em materiais publicados em livros, revistas, jornais, rede eletrônica, periódicos especializados, monografias e dissertações como fonte de coleta de dados. Diante da incessante competitividade do mercado atual, empresas procuram garantir a qualidade de seus produtos como fator que represente sua capacidade em desenvolver sistemas com qualidade. No mercado existem várias técnicas de teste de software que auxiliam essa garantia. Fonte: Barbosa e Torres (2011). TESTE DE SOFTWARE

153 153 CONSIDERAÇÕES FINAIS Nessa unidade analisamos a importância da fase de teste de software dentro do processo de desenvolvimento de software. Vimos alguns conceitos básicos, seu ciclo de vida e as técnicas que envolvem o teste de software. Vimos questionamentos sobre o que aconteceria se os testes não forem executados de forma correta. Verificamos como podemos fornecer uma garantia ao cliente de que ele irá funcionar em diversas situações. Aprendemos que, mesmo se um teste não detectar defeitos, isso não quer dizer necessariamente que o produto não tenha uma boa qualidade. Ao longo da unidade, aprendemos que realizar testes não consiste simplesmente na geração e execução de casos de teste, mas envolvem também questões de planejamento, gerenciamento e análise de resultados. Aprendemos que quanto antes os testes iniciarem, mais barato será a correção dos defeitos encontrados. Para isso ser possível, é preciso que o processo de teste, assim como o processo de desenvolvimento, tenha também um ciclo de vida. Conhecemos uma grande variedade de técnicas de teste, aplicáveis a diferentes circunstâncias. Vimos que elas podem ser utilizadas para classificar diferentes conceitos de testes, técnicas de design de situação de testes, técnicas de execução de teste e organizações de testes. Também vimos como as configurações do ambiente de teste nos fornecem uma ideia de como conduzir os testes necessários e como serão as atividades de avaliação, pois eles nos asseguram que os resultados sejam precisos e válidos na busca de falhas e resolução de erros. Depois dessa unidade, com o conhecimento que já adquirimos sobre os testes de softwares, podemos passar para a próxima unidade e nos aprofundamos ainda mais nos de teste de software. Preparados? Então continue com sua leitura! Considerações Finais

154 Conforme Tsui e Karam (2013, pg. 147), os testes de software geralmente possuem dois objetivos principais: I. Os testes devem encontrar defeitos no software, para que eles possam ser corrigidos ou maximizados e restaurados. II. Os testes fornecem uma avaliação geral de qualidade e uma estimativa das possíveis falhas. III. Os testes devem encontrar defeitos no software, para que eles possam ser corrigidos ou minimizados. IV. Os testes geram uma avaliação de cada componente e uma estimativa dos possíveis sucessos. V. Os testes não encontram defeitos e apenas fornecem uma avaliação geral de qualidade. Assinale a opção com a sequência CORRETA. a. Somente a questão I está correta. b. Somente as questões II e III estão corretas. c. Somente as questões I, IV e V estão corretas. d. Todas estão incorretas. e. Todas estão corretas. 2. Para Sommerville (2011), o processo de teste apresenta dois objetivos distintos: I. Demonstrar ao desenvolvedor e ao cliente que o software atende seus requisitos. II. Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente do que foi especificado. III. Demonstrar ao usuário e ao cliente que o software não atende seus requisitos. IV. Demonstrar ao desenvolvedor e ao cliente que o software não atende seus requisitos. V. Descobrir situações em que o software se comporta de maneira correta, desejável ou de forma igual do que foi especificado.

155 155 Assinale a opção com a sequência CORRETA. a. Somente as questões I e II estão corretas. b. Somente as questões I e III estão corretas. c. Somente a questão I está correta. d. Somente as questões III e V estão corretas. e. Todas estão corretas. 3. A técnica de testes estrutural tende a revelar os erros que ocorrem durante a codificação do programa, garante que a implementação de uma funcionalidade será toda testada na codificação, além disso, a análise estrutural deve ser utilizada em todas as fases do ciclo de desenvolvimento do software. A fase de testes de software é dividida em dois tipos. Assinale a resposta correta: a. Testes Funcionais e Testes Estruturais. b. Teste de Cor Cinza e Testes Estruturais. c. Testes Funcionais e Teste de capacidade. d. Testes Estruturais e Testes de energia. e. Nenhuma resposta correta. 4. Você já deve ter passado alguma experiência com algum bug de software em algum momento. Descreva alguma experiência com bug que tenha passado ou tenha conhecimento. 5. Uma calculadora está para somar 2+2 e deu um resultado igual a 3. Qual é o tipo de defeito? a. Defeito de interface. b. Defeito de cálculo. c. Defeito de limites. d. Defeito de carga. e. Defeito de desempenho.

156 156 A ATIVIDADE DE TESTE DURANTE O CICLO DE VIDA DO SOFTWARE Autora: Luciane Neves 1. Introdução A fase de testes ocupa, normalmente, 40% do tempo planejado para um projeto e um erro descoberto tardiamente em um sistema provoca um acréscimo de 60% nos custos do projeto. Nenhum programador ou analista, por mais experiente que seja, está imune à falhas de codificação e projeto. Estes são alguns dos motivos que têm feito com que a atividade de teste de software tenha se tornado um dos itens mais estudados no contexto de aprimoramento da qualidade de software[...]. 2. Qualidade de software e testes A história da garantia de qualidade no desenvolvimento de software tem paralelo com a história da qualidade no processo de manufatura de hardware [...]. Neste artigo entende-se que a atividade de teste deve ser usada em todas as etapas do processo de desenvolvimento de software e que, ao invés de representar uma última revisão, seja utilizada como milestone entre todas as fases do projeto[...]. 3. Teste de software Este capítulo abordará os aspectos fundamentais da atividade de teste, por meio de revisão bibliográfica. Os princípios, limitações e objetivos da atividade de teste serão apresentados nos itens que se seguem. Veremos também as características principais de cada classe de testes. 3.2 Princípios do teste de software Alguns dos itens que são comuns a todos os autores e pesquisadores do assunto teste de software e que descrevem os fundamentos e princípios desta atividade estão relacionados abaixo: Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do projeto, geralmente nos módulos principais do sistema. A atividade de teste não prova a ausência de erros, apenas a sua existência. Bons casos de teste são aqueles que encontram falhas no sistema até então não descobertas. Bons casos de teste são projetados levando em conta os requisitos do projeto. Um critério que pode ser utilizado para determinação do esforço a ser gasto na atividade de teste de software é verificar qual o grau de severidade das consequências advindas do seu mau funcionamento.

157 157 A probabilidade de encontrar um erro em uma determinada parte do sistema é proporcional ao número de erros já encontrados nessa parte. O objetivo da atividade de teste pode ser entendido da seguinte forma: No início de cada fase verificar se essa etapa do projeto reflete exatamente os requisitos e definições da fase imediatamente anterior [...]. Verificar se não existem erros de lógica no projeto e código, no fluxo de dados, no entendimento de requisitos, de codificação, tipográficos ou de interface em todas as fases do projeto. Identificar e interferir na presença do erro, iniciando-se a depuração, sendo que quanto antes for descoberta a falha, menos custoso será para adequá-la. Ter em mente que, uma vez que errar é humano e atividade de desenvolvimento de software é um exercício bastante complexo, os erros existem e devem ser descobertos [...]. 3.4 Classificação dos testes Podemos classificar os métodos de teste de acordo com suas características básicas. Pode-se descrever resumidamente cada um destes grupos da seguinte forma: Testes estáticos ou testes humanos: não são feitos por meio da execução real do programa, mas sim por meio da sua execução conceitual [...]. Testes dinâmicos: requerem que o programa seja executado e, por isso, seguem o modelo tradicional de teste de programa, no qual o programa é executado com alguns casos de teste. Testes funcionais: uma vez que testes exaustivos não são viáveis, características do domínio de entrada são examinadas para que se tente descobrir formas de derivar um conjunto de dados de teste representativo que consiga exercitar completamente a estrutura do sistema. Testes estruturais: diferentemente dos testes funcionais, que se preocupam com a função que o programa desempenha sem se preocupar com a maneira como a função foi implementada, o teste estrutural enfoca a implementação e a estrutura da função [...]. Testes de unidade: concentra-se no esforço de verificação da menor unidade de projeto de software: o módulo. Por meio do uso da descrição do projeto detalhado como guia, caminhos de controle importantes são testados para descobrir erros dentro das fronteiras do módulo. Esse teste baseia-se sempre na caixa branca, e esse passo pode ser realizado em paralelo para múltiplos módulos [...]. Testes de integração: o objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura do programa que foi determinada pelo projeto de forma sistemática, testando também a interface dos módulos. A integração pode ser incremental ou não-incremental.

158 158 Testes de validação: o teste de validação pode ser considerado bem sucedido quando o software funciona da maneira esperada pelo cliente. A validação do software, na fase de testes, é realizada por meio de uma série de testes de caixa preta que demonstram a conformidade com os requisitos. Testes alfa e beta: são os testes de aceitação, feitos pelo usuário, que dificilmente opera o sistema da forma prevista, e visam descobrir erros cumulativos que poderiam deteriorar o sistema no decorrer do tempo. Teste de segurança: o teste de segurança tenta verificar se todos os mecanismos de proteção embutidos em um sistema o protegerão de acessos indevidos. Todas as formas de ataque devem ser simuladas. Testes de estresse: o teste de estresse é feito para confrontar o sistema com situações anormais. O teste de estresse executa o sistema de forma que exige recursos em quantidade, frequência ou volume anormais. Teste de desempenho: o teste de desempenho é idealizado para testar o desempenho do software quando executado dentro do contexto de um sistema integrado. Embora seja difícil medir e definir um software como sendo de boa qualidade, é fácil identificar um software de má qualidade. Os erros frequentes, o mau funcionamento ou a inadequação aos requisitos são sempre notados. Fonte: Neves (2009)

159 MATERIAL COMPLEMENTAR Teste de Software Emerson Rios, Trayahú Moreira Editora: Alta Books Sinopse: Tratar essa atividade de teste de software como uma daquelas inseridas no processo de desenvolvimento, quando era executada por programadores e analistas de sistemas, não atende mais ao nível atual de complexidade das aplicações. Os testadores são técnicos altamente qualificados, os quais precisam acumular uma gama enorme de conhecimentos para poderem desempenhar suas atividades. Esse livro dá um enfoque gerencial aos principais aspectos relacionados com teste de software e procura servir de base para que gerentes e testadores possam absorver os conhecimentos necessários para suas funções na época atual. Desta forma, os autores apresentam além das métricas e metodologias, como os testes devem ser corretamente organizados e executados na empresa, e o que os gerentes precisam saber para montar um ambiente de teste estruturado e adequado aos novos técnicos dos projetos de teste de software. Nessa edição de Teste de Software, os autores Emerson Rios e Trayahú Moreira incluíram o capítulo Documentação de Teste, onde o leitor adquire informações sobre a norma IEEE 829:2008, que trata da documentação que deve ser usada em projetos de teste de software. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis Leonardo Molinari Editora: Érica Sinopse: Esse livro, para melhor entendimento do leitor, está dividido em três partes. A primeira mostra a visão macro da qualidade de software e seus principais elementos. Em seguida, traz testes de software em detalhes e, por último, as principais áreas de testes. O autor faz uma análise do mercado de ferramentas de automação de testes e exercícios de fixação. A qualidade de software, ao longo do tempo, tem se modificado e evoluído. Então, como desenvolver sistemas usando uma nova ciência em explosão no mundo, chamada de testes de software? A resposta a esta pergunta é tratada do início ao fim deste livro. Ele é dividido em três partes: visão macro da qualidade de software e seus principais elementos, testes de software em detalhes e principais ou grandes áreas de teste. Contém ainda análise do mercado de ferramentas de automação de testes e exercícios de fixação ao final dos capítulos. Material Complementar

160 MATERIAL COMPLEMENTAR Base de Conhecimento Em Teste de Software - 3ª Ed Emerson Rios, Anderson Bastos, Ricardo Cristalli e Trayahú Moreira. Editora: Martins Editora Sinopse: Obra de referência para os profissionais da área, indicada para o leitor que começa a se preparar para os exames de certificação. A fim de auxiliá-lo ainda mais nessa tarefa, foram selecionados os temas mais abordados nos principais exames. De maneira complementar, esta obra, desde sua primeira edição, é também fonte de consulta para a execução das atividades relacionadas ao teste de software. Como trabalhar com testes de software? Nesse vídeo é dado algumas dicas do por que escolher a área de teste de software pode ser uma boa escolha para começar a trabalhar na área de TI, ou mesmo como uma opção para buscar um nova oportunidade do mercado de trabalho, visando crescimento na carreira profissional. Disponível em: < Introdução à garantia de qualidade de software e ferramentas para teste Veja neste artigo uma introdução à garantia de qualidade e ferramentas de teste de software. Atualmente, muito se fala sobre qualidade de software, entretanto, os desenvolvedores por vezes não sabem se estão no caminho certo. Para esclarecer um pouco sobre este assunto, nesse artigo vamos tratar alguns pontos principais sobre este tema. Boa leitura! Leia mais em: <

161 MATERIAL COMPLEMENTAR Formando Equipes Eficientes de Teste de Software Nesse artigo o autor mostra a importância de se formar equipes e times eficientes em teste de software, qualificações e requisitos tanto técnicos como gerenciais básicos que são necessários e completam o perfil ideal para trabalhar na área de teste de software. Também é mostrado o Processo de Formação de Equipes de Teste de Software, como desenvolver um modelo de hierarquia para projetos de teste de software. O autor mostra um guia «quase completo» para ser e contratar um bom Analista de teste de Software (Requisitos técnicos e requisitos Pessoais e Profissionais). Excelente artigo. Para ler o artigo na íntegra, acesse o link: < Artigo que mostra como o ciclo de vida do teste faz parte do ciclo de vida do software e eles devem ser iniciados ao mesmo tempo. O processo de design e desenvolvimento de testes pode ser tão complexo quanto o processo de desenvolvimento do software em si. Se os testes não forem iniciados juntamente com os primeiros releases executáveis do software, o esforço de teste retardará a descoberta de muitos problemas no ciclo de desenvolvimento. Boa leitura! Para ler o artigo na íntegra, acesse o site: < Material Complementar

162 REFERÊNCIAS BARBOSA F. B.; TORRES I. V. O Teste de Software no Mercado de Trabalho. Revista Tecnologias em Projeção. V. 2, 2011, p BASTOS A.; RIOS E.; CRISTALLI R.; MOREIRA T. Base de Conhecimento em Teste de Software. 2 ed. São Paulo: Editora Martins, HETZEL W. C. The Complete Guide to Software Testing. 2 ed. United States: John Wiley & Sons, MECENAS I.; OLIVEIRA V. Qualidade em software. Rio De janeiro: Alta Books, MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São Paulo: Érica, MYERS G. J. The Art of Software Testing. New York: John Wiley & Sons, NEVES, L. A atividade de teste durante o ciclo de vida do software. Bate byte. (online) Disponível em: < conteudo/ conteudo.php?conteudo=1097> Acesso em: 19 Mar PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, PRIMÃO A. P.; RIBEIRO P. da S.; KREUTZ D. L. Estudo de Caso: Técnicas de Teste como parte do Ciclo de Desenvolvimento de Software. In: Anais do IX Simpósio de Informática da Região Centro do RS. Santa Maria: UNIPAMPA, RIOS, E. Caratê Aplicado ao Teste de Software. 1 ed. Niterói: Imagem Art Studio, RIOS, E. ; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, TSUI, F.; KARAM, O. Fundamentos de engenharia de software. 2 ed. Rio de Janeiro: LTC, 2013.

163 GABARITO B - Somente as questões II e III estão corretas. 2. A - Somente as questões I e II estão corretas. 3. A - Testes Funcionais e Testes Estruturais 4. Um exemplo de bug pelo qual passei: Ao atualizar um cliente com a última versão disponível, ele reclamou que quando efetuava uma venda com baixa do depósito, o produto baixava duas vezes no estoque, uma do depósito e outra na loja. Ao verificar os testes que tinham sido feitos, o erro não ocorria, pois a venda baixava somente do depsito, como era a regra de venda do cliente. O analista foi verificar e descobriu que alguém do suporte tinha alterado uma configuração das baixas de estoque, alterando assim a regra do cliente e fazendo com que ocorresse esse erro. Ao voltar à configuração original, as vendas foram efetuadas corretamente. 5. B - Defeito de cálculo, pois a calculadora efetuou o cálculo e produziu um resultado errado, causado basicamente por: lógica errada, defeito de codificação e/ ou imprecisão no cálculo.

164

165 Professora Esp. Janaína Aparecida de Freitas PROCESSO DE TESTE DE SOFTWARE UNIDADE V Objetivos de Aprendizagem Compreender a Documentação de Teste de Software. Ter uma Visão geral da Validação e Verificação. Entender as técnicas e os critérios utilizados para validar um software. Aprender sobre algumas ferramentas utilizadas para a automação de testes. Compreendendo as Medidas de melhoria do processo. Possuir uma Visão geral sobre os riscos em teste de software. Plano de Estudo A seguir, apresentam-se os tópicos que você estudará nesta unidade: Documentação de Testes de Software Relatórios de Teste de Software Validação e Verificação em Teste de Software Ferramentas de Teste de Software Métricas e Medição Gerência de Risco em Teste de Software

166

167 167 INTRODUÇÃO Olá, caro(a) aluno(a)! Vamos para a última unidade do livro? Avançando em nosso aprendizado sobre a fase de teste de software, vamos nos aprofundar um pouco mais, aprendendo sobre os documentos que devem ser produzidos pela equipe de testes e porque ele é necessário e essencial para garantir a qualidade dos testes e sua manutenção. Nessa unidade, vamos aprender sobre validação e verificação e suas diferenças no teste de software e apresentaremos técnicas de verificação e validação que são fundamentais para identificar os defeitos do software. Atendendo, dessa forma, ao grande objetivo das organizações: evitar que os erros perdurem, ou melhor, que sejam descobertos antes que o software seja liberado para sua utilização. Também vamos aprender os principais conceitos relativos à automação de testes, sobre o que pode e quais devem ser os critérios na hora de escolher a ferramenta para determinado teste e a metodologia empregada na empresa. Vamos aprender nesta unidade, também, sobre as métricas e medição e ver porque o ato de medir e estimar é a parte mais importante de um projeto de software que seja bem-sucedido e com qualidade. E por fim, vamos aprender sobre como gerenciar os riscos no projeto de teste de software, quais regras e metodologias podem ser usadas para reduzir os riscos de ocorrências de problemas e erros no ambiente do usuário e como isso pode representar a confiabilidade no software. Os softwares que utilizamos são desenvolvidos por seres humanos, que são passíveis de falhas. Principalmente porque a maioria dos erros é humana e tem origem na falta de comunicação (analistas e desenvolvedores), entendimento (o desenvolvedor acha que entendeu) e transformação das informações (desenvolveu como entendeu). Se os softwares não funcionam corretamente podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam. Por isso, é necessário testar, pois os testes diminuem os riscos. Aproveite a leitura! Introdução

168 168 UNIDADE V shutterstock DOCUMENTAÇÃO DE TESTE DE SOFTWARE Conforme Bastos et. al (2007), durante o ciclo de um projeto de teste, o analista de teste gasta com a documentação do teste em torno de 50% a 60% do tempo. Será que é tão importante gastar tanto tempo assim com a documentação de teste? Para Bastos et. al (2007) sim, pois os documentos que são definidos pela norma e cobrem tarefas de planejamento, especificação ou elaboração e análise dos resultados. A norma ou padrão IEEE 829 (Institute of Electrical Engineers) especifica que devem ser usados os seguintes documentos: Plano de Teste. Especificação de Projeto de Teste: - Projeto de teste. - Casos de teste. - Procedimentos de teste. PROCESSO DE TESTE DE SOFTWARE

169 169 Relatórios de Teste: - Relatório de Passagem de Itens de Teste. - Relatório de Log de Teste. - Relatório de Incidentes de Teste. - Relatório de Sumário de Teste. Segundo a norma, esses são os documentos mínimos necessários para que um processo de testes funcione convenientemente, ou seja, bem sucedido. Empresas que trabalham com automação de teste, com certeza, já possuem softwares que geram automaticamente todos, ou quase todos, os documentos citados. Figura 1: Relacionamento entre os documentos de teste no processo de teste Documentos projeto desenv Especificação de Projeto de Teste Plano de Teste Especificação de Projeto de Teste Itens de Teste Artefatos usados nos testes Especificação de Projeto de Teste Itens de Teste Artefatos usados nos testes Relatórios de Itens de teste Especificação de Caso de Teste Fonte: IEEE 829 (1998). Especificação do Procedimento de Teste Documentação de Teste de Software

170 170 UNIDADE V PLANO DE TESTE O Plano de Teste, documento básico gerado através da etapa de planejamento, serve como escopo de referência durante a execução do teste e também serve como documento de comunicação junto ao cliente que contratou o serviço de teste. Ao passarmos para a etapa de especificação precisamos ter em mãos o Plano de Teste. Para Bastos et al. (2007, p. 150), apresenta o planejamento para a execução do teste, incluindo a abrangência, a abordagem, os recursos e o cronograma das atividades de teste. Identifica os itens e as funcionalidades a serem testadas, as tarefas a serem realizadas e os riscos associados com a atividade de teste, descrevendo ainda os diferentes ambientes que serão utilizados durante o teste. Executar testes para cobrir todo o sistema e garantir que o mesmo não terá mais nenhum defeito, é uma atividade custosa e muitas vezes impossível de ser realizada. Muitas empresas adotam alguns padrões de conteúdo de plano de teste para auxiliar nessa atividade, como IEEE, QAI e se for tratar o teste como um projeto, temos o PMBOK. Geralmente, a base de conteúdo do plano de teste segue o modelo IEEE 829, entretanto, pode variar de empresa para empresa. O IEEE 829 procurou adotar ou basear o Plano de Teste no padrão PMI. Principais Funções de um Plano de Teste O Plano de teste possui várias funções, dependendo de sua situação. Vamos listar as principais: Suportar o desenvolvimento da qualidade dos produtos, de forma sábia, sincronizada com as decisões. Descrever e justificar a estratégia de testes para com os requisitos do produto a ser testado. Suportar o início e a organização do projeto de teste, incluindo aí preparações, pessoal, delegação de responsabilidades, planejamento das tarefas etc. Suportar o gerenciamento diário e a evolução do projeto de teste e da estratégia. PROCESSO DE TESTE DE SOFTWARE

171 171 Suportar a efetiva coordenação, colaboração e outros relacionamentos entre os membros da equipe e o resto do projeto. Identificar e gerenciar quaisquer riscos ou questões que possam impactar no projeto. Ter as informações históricas do projeto, de forma a suportar auditoria e melhorias para futuros projetos. Principais etapas de elaboração de um Plano de Teste Pode-se dizer que um Plano de teste segue algumas etapas durante sua elaboração e utilização: Definição do escopo: define o que se deve testar em nível macro. Identificação de requisitos e casos de teste: identificação dos requisitos de teste de forma hierárquica e descritiva, de maneira que possamos entendê-los. Identificação dos casos de teste que contenham os requerimentos de teste em detalhes, incluindo os passos de execução dos testes. Identificação das propriedades: o que se deve testar e em qual ordem. Definição da estratégia: identificação das técnicas de teste que serão utilizadas em quais requisitos. Identificação de recursos: quem fará o que e o que será utilizado (software, hardware etc.). Criação de Schedule: elaboração de um cronograma de teste. Geração de documento de Plano de Teste: geração da documentação formal e revisada, com as devidas análises do planejamento de teste. Atualização constante do Plano de Teste: aqui o plano de teste será atualizado com resultados finais de cada teste e com os defeitos encontrados. Documentação de Teste de Software

172 172 UNIDADE V Tabela 1: Conteúdo de um Plano de Teste segundo IEEE 829 ITEM Identificador do plano de testes Introdução Itens a testar Aspectos a testar Aspectos que não serão testados Abordagem Critérios de completeza e sucesso Critérios de suspensão e retomada Resultados do teste Tarefas de teste Ambiente Responsabilidades Agenda Riscos e contingências Aprovação Fonte: Norma IEEE Std. 829 (1998). DESCRIÇÃO Identificador único para o plano. Objetivos, histórico, escopo, referências a documentos. Conjunto dos itens cobertos pelo plano. Conteúdo dos testes que serão feitos. Aspectos significativos que não serão testados. Opções metodológicas que são aplicáveis ao conjunto dos testes. Condições que devem ser satisfeitas e estado que deve ser atingido para que o conjunto dos testes seja considerado bem sucedido. Problemas graves que podem provocar a interrupção dos testes. Artefatos que serão produzidos durante a realização da bateria de testes. Lista detalhada das tarefas que são cobertas por este plano. Hardware e software das configurações usadas para o conjunto dos testes. Responsabilidades de cada um dos participantes dos testes. Data de inicio e de fim de cada tarefa do plano. Ricos e contingências aplicáveis aos testes deste plano. Nomes e assinaturas dos responsáveis pela aprovação do plano. PROCESSO DE TESTE DE SOFTWARE

173 173 Segundo Bastos et al. (2007, p. 154), o caso de teste deve ter as características a seguir para que possa ser usado e atender às expectativas de validação da qualidade : Efetivo: testar o que se planejou testar. Econômico: sem passos desnecessários. Reutilizável: que possa ser repetido. Rastreável: que possa identificar o requisito a ser testado. Autoexplicativo: que possa ser testado por qualquer testador. ESPECIFICAÇÃO DE PROJETO DE TESTE Segundo Bastos et al (2007, p. 155), trata-se de um detalhamento da abordagem apresentada no plano de teste que identifica as funcionalidades e as características a serem testadas pelo projeto. Esse documento também aponta os casos e os procedimentos de teste. Projeto de Teste O objetivo principal do projeto de teste é facilitar o entendimento e acompanhamento do plano de testes, por meio da sua abertura em diversos projetos de teste. O projeto de teste deve conter os seguintes campos: Identificador: código único que identifique o projeto de teste. Features a serem testadas: listar todas as funcionalidades ou programas que serão testados. Abordagem refinada: refinar a abordagem do plano de teste. Casos de teste com a sua respectiva identificação: breve descrição dos casos de teste e sua respectiva identificação. Critérios de passagem e falha por Features: condição para que uma funcionalidade passe pelos testes. Documentação de Teste de Software

174 174 UNIDADE V CASOS DE TESTE O caso de teste é a especificação mais detalhada do teste, com níveis de detalhes de campos de telas, formulários etc. Ele estabelece o que será testado e quais as informações que serão empregadas durante os testes dos cenários e quais serão os resultados esperados. Para isso acontecer é necessário estabelecer a massa a ser utilizada no teste de forma a validar todos os requisitos do software. Os casos de teste incluem dados de entrada, resultados esperados, ações e condições gerais para a execução do teste. Utiliza também a nomenclatura de plano de caso de teste. Identifica o maior número de cenários e variações de determinado requisito de software. Segundo Bastos et al. (2007, p. 152), o plano de caso de teste é o documento que registra todo o planejamento dos testes dos requisitos estabelecidos durante o ciclo de desenvolvimento do software. Esse documento determina o que será testado, e seu principal objetivo consiste em identificar o maior número de cenários e variações de determinado requisito de software. Os testadores enfrentam o desafio de testar, tanto quanto possível, dentro do disponível e geralmente em um curto cronograma, sendo impossível testar exaustivamente todas as combinações de casos de teste de um sistema. Definição do Caso de Teste Em geral, define-se formalmente um caso de teste como a especificação mais detalhada do teste, como os campos de tela, formulários e estabelece quais informações serão usadas durante os testes dos cenários e quais serão os resultados possíveis esperados. Segundo Bastos et al. (2007), é necessário para isso, determinar a massa a ser utilizada no teste de modo a validar todos os requisitos do software. Um bom caso de teste deve conter: Identificação das condições de teste: - pré-condições. - pós-condições. - critério de aceitação. PROCESSO DE TESTE DE SOFTWARE

175 175 Identificação dos casos de testes (o que testar). Detalhamento da massa de entrada e saída. Critérios especiais para geração da massa de teste. Especificação das configurações de ambiente no qual o teste será executado (sistema operacional, ferramentas, origem de dados etc. onde testar). Definir o tipo de implementação do teste (automático/manual como testar). Definir o cronograma, ou seja, em qual fase esse teste será executado (quando testar). Listar as interdependências, caso existam, entre os casos de teste. ELABORAÇÃO DE CENÁRIOS DE TESTE Os critérios de teste servem para orientar o testador na geração de casos de testes. Os casos de testes gerados devem exercitar os elementos quando o software for testado. Um requisito que não é verificável, não terá um caso de teste associado a ele. Existem métodos que auxiliam na escolha de critérios para a geração dos cenários de testes. Método Step-by-Step: tem por objetivo produzir rapidamente casos de testes completos para a especificação do sistema. Cobre: domínio entrada testando valores limites, valor médio, condições de erros e entradas inválidas. Método PairWise de Teste ou Combinação Dupla: tem por objetivo cobrir ao menos um caso de teste para cada combinação de valores validados entre dois parâmetros. Gráfico de Causa e Efeito: tem por objetivo oferecer uma representação concisa das condições lógicas e das ações correspondentes, em que elaboramos causas (condições de entrada) e efeitos (ações) são relacionados para um módulo e um identificador é atribuído a cada um. Documentação de Teste de Software

176 176 UNIDADE V Método Classe de Equivalência: tem por objetivo reduzir o número de caso de teste a um nível controlável, mas mantendo uma cobertura de teste razoável. Método Valores Limítrofes: tem por objetivo validar os valores limites do domínio de entrada de um determinado sistema. Ao invés de selecionar qualquer valor de uma determinada classe de equivalência, os casos de testes selecionados são os valores das fronteiras. Figura 2: Caso de teste como centro motivador do teste O que motivou meu teste? Requisitos Iteração Quando devo testar? Fonte: Bastos et al. (2007). Caso de Teste Onde devo testar? Configurações Implementação Como devo testar? PROCEDIMENTO DE TESTE Especifica os passos necessários para executar um grupo de casos de teste (cenários de teste ou funcionalidades do software). Muitos chamam o procedimento de teste de teste de roteiro de teste. PROCESSO DE TESTE DE SOFTWARE

177 177 O procedimento de teste é composto pelos seguintes campos: Identificador: código que permite identificar de uma forma única o procedimento de teste. Propósito: passos necessários para executar um grupo de casos de teste. Requisitos especiais: descrever procedimentos especiais necessários para executar esse procedimento. Passos do procedimento: - Log: para analisar os resultados. - Configurações: necessárias para executar o procedimento. - Procedimento de início. - Ações necessárias durante o procedimento. - Medições. - Suspensão. - Reinício. - Parar. - Restaurar. - Contingências. Como todas as outras etapas de teste, a validação tenta descobrir erros, mas o foco está no nível de requisitos em coisas que ficarão imediatamente aparentes para o usuário final. (Pressman). Documentação de Teste de Software

178 178 UNIDADE V A fase de elaboração dos testes tem como papel principal a atividade de elaboração dos cenários de teste, que serão executados, ou melhor, testados na fase seguinte. Um cenário é uma história hipotética que visa ajudar a solucionar um problema complexo, recriando ou visualizando um caminho a ser seguido. O conceito de planejamento baseado em cenários ganhou popularidade nos planejamentos militares e passou a ser utilizado em várias outras atividades que exigiam um planejamento detalhado. Um bom cenário é aquele que pode ser usado por qualquer pessoa. O cenário de teste é o caminho a ser seguido ou a situação a ser testada. O cenário que serve de base para o teste é descrito numa especificação do sistema: por exemplo, na Unified Modeling Language (UML), é o caso de uso. O caso de teste é o cenário a ser executado para verificar se o que foi especificado está devidamente implementado. Fonte: Bastos, Rios, Cristalli e Moreira (2007). RELATÓRIOS DE TESTE DE SOFTWARE Os relatórios dos testes do software registram os dados relativos à execução de um dos tipos de teste. Cada novo relatório deve ser adicionado sequencialmente aos relatórios dos testes do software. Os relatórios necessários para acompanharmos a evolução dos projetos de teste segundo a norma IEEE 829, são: shutterstock Relatório de Passagem de Itens. Relatório de Log de Teste. Relatório de Incidentes de Teste. Relatório de Sumário de Teste. PROCESSO DE TESTE DE SOFTWARE

179 179 Figura 3: Resumo do Fluxo de geração de documentos Plano de Teste Especificação do Projeto de Teste Especificação do Projeto de Teste Especificação do Projeto de Teste Casos de Teste Procedimentos de Teste Relatório encaminhamento item de teste Execução do Teste Diário de Teste Fonte: Norma IEEE 829, Incidente de Teste Relatório Resumo de teste Diário de Teste Incidente de Teste Segundo o IEEE 829 esses seriam os Relatórios de Testes necessários para que o projeto atinja os seus objetivos. Agora vamos conhecer melhor cada relatório. Preparado(s)? RELATÓRIO DE PASSAGEM DE ITENS DE TESTE O objetivo do relatório de passagem de itens é identificar os itens de teste que serão entregues para o teste, com a identificação do executor do teste e outros responsáveis, a localização onde estarão disponíveis para serem usados e baixados e o estado de cada um desses artefatos ou item de teste. Segundo o IEEE 829, o relatório de passagem de itens deve ter os seguintes campos: Identificador: deve ter um código único como identificador para o relatório. Relatórios de Teste de Software

180 180 UNIDADE V Itens passados: deve ter uma lista com a relação dos itens de teste. Localização: deve ter a descrição do local onde estão armazenados os itens de teste e orientações de como acessá-los. Estado: deve ter uma descrição do estado de cada item de teste que foi passado. Aprovações: deve ter um registro dos envolvidos no envio e recebimentos do relatório. Deve fazer parte desse relatório todos os artefatos recebidos pela equipe de teste para a execução do seu trabalho. Um exemplo pode ser o plano de projeto, a relação dos casos de uso, a relação dos programas que deverão ser testados etc. RELATÓRIO DE LOG DE TESTE Segundo Bastos et al. (2007), o objetivo do relatório de log é descrever tudo de relevante que ocorre durante o projeto de teste, de tal forma que seja um documento básico de registros de todas as atividades desenvolvidas e outras ocorrências. Pode ser considerado o log um diário de ocorrências da atividade de execução dos testes. Conforme o IEEE 829, o relatório de log deve ter os seguintes campos: Identificador: deve ter um identificador único para o relatório especificamente. Descrição: deve descrever o que estava sendo testado, incluindo identificação, versão etc. Entradas das atividades e eventos - Descrição da execução: identificação do que estava sendo executado, por quem e quando. - Resultados: de cada item executado. - Registrar se o teste foi bem sucedido ou se ocorreram problemas. - Informações sobre o ambiente. PROCESSO DE TESTE DE SOFTWARE

181 181 - Registrar qualquer situação especial de ambiente necessária para a execução do item de teste. - Eventos anormais. - Registrar qualquer tipo de evento que tenha ocorrido e impedido a execução dos itens de teste ou que tenha contribuído para a sua não correta execução. RELATÓRIO DE INCIDENTES DE TESTE Conforme Bastos et al. (2007), o objetivo do relatório de incidentes de teste é registrar qualquer ocorrência no projeto de teste que necessite de alguma investigação. O uso mais comum desse relatório é o registro dos defeitos ocorridos durante o teste de sistema que devam ser transmitidos para a equipe de desenvolvimento, para que ela tome as providências pertinentes. O Relatório de Incidentes de teste deve ter o seguinte conteúdo básico: Identificador do relatório: deve ter um identificador único do relatório. Sumário da ocorrência: deve descrever em detalhes o que estava sendo feito quando ocorreu o incidente. Descrição do incidente: o IEEE 829 sugere que seja descrito o incidente contendo os seguintes campos. - Entradas. - Resultados esperados. - Resultados encontrados. - Problemas. - Data e hora da ocorrência. - Sugestões de procedimentos a serem tomados. - Ambiente. Relatórios de Teste de Software

182 182 UNIDADE V - Tentativas de contornar o problema. - Testadores envolvidos. - Observadores. Impacto: o impacto causado pela ocorrência deve ser descrito. RELATÓRIO DE SUMÁRIO DE TESTE Para Bastos et al. (2007), o relatório de sumário de teste fornece um sumário das atividades realizadas durante um determinado projeto e mostra resumidamente as ocorrências durante todas as atividades realizadas. Esse relatório é usado para fechar o projeto de testes. O Relatório de Sumário de Teste deve ter o seguinte conteúdo básico: Identificador do relatório: deve ter um identificador único do relatório. Sumário: deve ser listado o que foi testado, registrando identificações, versões, o ambiente usado e os documentos referenciados e usados no projeto de testes. Variações: devem ser listados os procedimentos adotados que sejam diferentes do que foi inicialmente planejado, sobretudo, se não constar no plano de teste. Avaliações do processo: devem ser relatadas todas as ocorrências que possa causar impacto na qualidade do software liberado para o cliente. Sumário dos resultados: devem ser listados todos os parâmetros que possam quantificar o projeto de testes que está sendo encerrado, por exemplo: número de casos de teste, número de execuções de cada caso de teste, número de defeitos encontrados etc. Avaliação do teste: deve ser avaliado o projeto de teste e procurar identificar, por exemplo, alguns riscos que ainda não foram mitigados e que podem causar problemas no momento em que o software entre em produção. PROCESSO DE TESTE DE SOFTWARE

183 183 Sumário de atividades: deve listar as pessoas envolvidas no projeto de testes, o número de horas consumidas por atividade no projeto, tempo total consumido e outras informações relevantes. Aprovações: deve listar o nome das pessoas responsáveis pelas aprovação do projeto de teste. A menor unidade que pode ser testada em software orientado a objeto é a classe. O teste de classe é controlado pelas operações encapsuladas pela classe e o comportamento de estado da classe. (Pressman). Os relatórios de teste são compostos por quatro documentos: Diário de Teste, Relatório de Incidente de Teste, Relatório Resumo de Teste e Relatório de Encaminhamento de Item de Teste. O Diário de Teste exibe os registros cronológicos dos dados relevantes relacionados com a execução dos testes. O Relatório de Incidente de Teste documenta qualquer evento que ocorra durante a atividade de teste e que necessite de análise posterior. No qual são relatados os erros que podem ocorrer durante da execução do teste. Esses erros podem ser causados tanto pela falha na construção do teste como por erros encaminhados para o responsável pela correção. O Relatório-Resumo de Teste mostra um resumo dos resultados das atividades de teste associadas com uma ou mais nesses resultados. os itens encaminhados para teste no caso de equipes distintas serem responsáveis pelas tarefas de desenvolvimento e de teste. Fonte: Blanco (2012). Relatórios de Teste de Software

184 184 UNIDADE V VALIDAÇÃO E VERIFICAÇÃO EM TESTES DE SOFTWARE shutterstock Nesse tópico iremos aprender sobre as técnicas de verificação e validação e como são fundamentais para identificar os defeitos do software. Preparado(s)? Então, vamos seguir em frente. Pressman (2011, p. 402) define que o teste de software é um elemento de um tópico mais amplo, muitas vezes conhecido como verificação e validação (V&V). Verificação refere-se ao conjunto de tarefas que garantem que o software implementa corretamente uma função específica. Validação refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode ser rastreado segundo os requisitos do cliente. Quando se executa os testes de software, um importante objetivo é o de verificar se o produto desenvolvido satisfaz os requisitos solicitados pelo cliente. Um software pode conter defeitos, porém, se algum trecho do código nunca for executado, ou se o código não for exaustivamente executado, este defeito poderá não aparecer. O QUE É VERIFICAÇÃO? A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado, se os requisitos, funcionalidades documentados foram implementados. Segundo Bastos et al. (2007, p. 30), a verificação realiza inspeções e revisões sobre os produtos gerados pelas diversas etapas do processo de teste. PROCESSO DE TESTE DE SOFTWARE

185 185 O QUE É VALIDAÇÃO? A validação tem o objetivo de avaliar se o que foi entregue atende às expectativas. Ou seja, se os requisitos, independente do que foi planejado, estão implementados para atender ao negócio (cliente). Segundo Bastos et al. (2007, p. 30), avalia se o sistema atende aos requisitos do projeto (usuário). Os testes unitários, os de integração, de sistema e de aceitação podem ser classificados como testes de validação. Entendeu a diferença entre verificação e validação? Para facilitar e entender bem a diferença entre verificação e validação, vamos responder às perguntas: Verificação: Estamos construindo corretamente o sistema? Validação: Estamos construindo o sistema correto? Conforme Bastos et al. (2007), a primeira pergunta diz respeito ao que foi construído e a segunda diz respeito ao entendimento do que era para ser construído. Durante o desenvolvimento do software, podem surgir diversos tipos de problemas e erros que acabam resultando na obtenção de um produto diferente daquele que se esperava. Para que tais sejam descobertos antes de o software ser liberado para utilização, existe as atividades de Validação e Verificação, ou V&V, com a finalidade de garantir que tanto o modo pelo qual o software está sendo construído quanto o produto em si esteja em conformidade com o especificado nos requisitos. Para Bastos et al. (2007), as atividades de V&V não se aplicam apenas ao produto final, mas devem ser conduzidas durante todo o processo de desenvolvimento do software, desde a sua concepção, desenvolvimento e sua entrega, pois englobam diferentes técnicas. Alguns autores costumam dividir as atividades de V&V em estáticas e dinâmicas. As estáticas são aquelas que não requerem a execução ou mesmo a existência de um programa ou modelo executável para serem conduzidas. As dinâmicas são aquelas que se baseiam na execução de um programa ou de um modelo. Validação e Verificação em Testes de Software

186 186 UNIDADE V VERIFICAÇÃO E VALIDAÇÃO NO CONTEXTO DA QUALIDADE As atividades de verificações e validações são consideradas úteis na garantia da qualidade do software, principalmente porque são fortemente recomendadas pelos modelos atuais de qualidade de software, tais como as normas ISO e o CMMI. Segundo o IEEE, as atividades de verificação e validação possuem técnicas de revisão, análise e teste para determinar se o sistema de software desenvolvido está de acordo com a análise de requisitos. A qualidade do software está diretamente relacionada à satisfação do cliente, sendo assim, as empresas estão percebendo a importância em produzir software com qualidade. Como já vimos anteriormente, o teste de software é um dos elementos importantes na garantia da qualidade de software. Existe a Norma IEEE Software Verification and Validation, que trata da padronização dos processos de verificação e validação de Software (Standard for Software Verification and Validation). Ela é aplicada durante o ciclo de vida de desenvolvimento do software, onde inclui o processo de aquisição, desenvolvimento, operação e manutenção de sistemas (Institute of Eletrical and Eletronics Engineers). Na Norma IEEE 1012, está descrito que o objetivo dela é estabelecer procedimentos de verificação e validação, incluindo atividades e tarefas de apoio ao processo de ciclo de vida do software, garantindo que os requisitos do sistema estejam corretos, completos, consistentes e testados, e com isso, diminuindo os riscos operacionais do projeto, pois é verificado se os produtos de desenvolvidos em determinada atividade estão de acordo com as exigências dessa fase, e se o software satisfaz às necessidades do usuário. PROCESSO DE TESTE DE SOFTWARE

187 187 A Norma IEEE 1012 possui três princípios básicos: 1. Prover um padrão mínimo de requisitos que seja escopo do documento denominado plano de verificação e validação do software - SVVPs (Software Verification and Validation Plans). 2. Definir especificações mínimas de atividades de verificação e validação (V&V), incluindo os requisitos de entrada e saída, as quais devem ser incluídas no documento SVVPs. 3. Sugerir atividades de verificação e validação (V&V) opcionais para serem usadas sob medida no documento SVVPs, conforme os esforços V&V necessários. A Norma IEEE 2012 também solicita que alguns itens básicos sejam definidos em cada fase do projeto, tais como: Atividades de Verificação e Validação. Critérios e métodos. Entradas e Saídas. Cronograma. Recursos. Riscos. Regras e Responsabilidades. Para as atividades de Validação e Verificação que são associadas à fase de teste, ela recomenda a execução de testes de unidade, integração, sistema e aceitação, a documentação dos resultados obtidos e defeitos detectados na execução dos testes. Validação e Verificação em Testes de Software

188 188 UNIDADE V shutterstock FERRAMENTAS DE TESTE DE SOFTWARE Algumas ferramentas prestam auxílio diretamente à observação de comportamento do código, como os depuradores, monitores (profilers) e geradores de casos de teste. A automação de testes consiste em testar um software com outro software. Confuso? A automação é como robôs (vários scripts) construídos para usar o sistema no lugar dos usuários, podem ser mais rápidos na execução dos testes e detecção dos erros e trabalham em uma escala maior. Para Bastos et al. (2007, p. 87), as ferramentas de teste podem aliviar o fardo da produção e da execução de teste, da geração de informações e da comunicação. A escolha da ferramenta apropriada é um aspecto importante do processo de teste. Mas vamos a uma pergunta: qual a diferença entre ferramentas e técnicas de teste? Na unidade anterior, vimos várias técnicas de teste, e os conceitos de ferramentas e técnicas são importante no processo de teste. Conforme Bastos et al. (2007), o testador precisa entender as técnicas de teste primeiro, para que depois consiga entender quais ferramentas de teste devem ser utilizadas com cada técnica. Pois, a ferramenta é um recurso para o testador, mas sem a técnica é insuficiente para conduzir os testes. PROCESSO DE TESTE DE SOFTWARE

189 189 Sobre as ferramentas de teste, Bastos et al. (2007, p. 87) menciona que: A seleção da ferramenta afeta a eficiência e a eficácia do teste. As ferramentas de teste são o apoio dos profissionais da área de teste, pois cobrem grande parte das atividades de teste e são aplicáveis em todas as fases do ciclo de vida do desenvolvimento do software. Algumas técnicas são manuais, e outras, automáticas, algumas fazem testes estáticos, e outras, dos dinâmicos, algumas avaliam a estrutura do sistema e outras, sua função. A atividade de teste gera grande número de informações que, muitas vezes, necessitam de várias repetições e isso exige muita coordenação e comunicação entre a equipe. Mas por que automatizar? Para responder esta pergunta, vamos conhecer os objetivos da automação de testes: Aumenta a consistência e abrangência dos testes. Reduz o tempo ou esforço de teste. Diminui o custo dos testes. Aumenta a produtividade do desenvolvimento de software como um todo. Aumenta a qualidade do produto final. Temos várias razões para usar a automação de testes. Mas o que devemos automatizar no projeto de teste? Quais testes são interessantes serem automatizados? Vamos listar o que devemos automatizar: Testes de regressão. Smoke tests (teste de fumaça). Tarefas repetitivas e que demandam muito esforço. Cálculos matemáticos. Funcionalidades críticas. Entretanto, nem todos os testes devem ser automatizados. Mas a automação dos testes faz com que a equipe de testes seja liberada para a realização de testes mais complexos que exigem um ser humano ou testes mais específicos, como os de segurança, usabilidade, entre outros. Temos que alertar que a automação de testes exige que o ambiente de testes esteja com os dados rigorosamente controlados. Ferramentas de Teste de Software

190 190 UNIDADE V Hoje no mercado existem diferentes versões desse tipo de ferramenta. Os geradores de casos de teste estruturais criam casos de testes com base na estrutura do código-fonte. Um exemplo de ferramenta é a TestComplete, da AutomatedQA, que pode ser integrada às plataformas de desenvolvimento mais comuns atualmente. Geradores funcionais definem os casos de teste a partir das especificações do código, como o AETG Web Service. Como a ferramenta não depende do código-fonte, a rigor pode ser utilizado com qualquer linguagem de programação. A aplicação de critérios de teste (escolher o que será testado) sem o apoio de ferramentas automatizadas tende a ser uma atividade propensa a erros e limitada a programas muito simples. Tal aspecto motiva o desenvolvimento de ferramentas automáticas para auxiliar na condução de testes efetivos e na análise dos resultados obtidos por estes testes. Apesar de não auxiliarem diretamente na determinação das entradas de um programa, necessárias para a execução de caminhos específicos, grande parte das ferramentas de teste apresenta ao usuário os requisitos de teste exigidos para que os critérios sejam satisfeitos. Assim, de certa maneira, orientam e auxiliam o usuário na elaboração dos casos de teste. Abaixo, segue uma lista com algumas das ferramentas para testes de software mais utilizadas: JUnit: é um framework altamente eficaz e largamente utilizado na criação e execução de testes unitários de códigos. Selenium: ferramenta usada para a realização de testes integrados e de aceitação. JMeter: ferramenta com o propósito principal para testes de carga e stress de aplicações e pode ser usado para testes integrados e de aceitação. Clover: ferramenta para análise de cobertura dos testes existem na aplicação, integrado a várias IDEs Eclipse. Existem diversas opções semelhantes: JCoverage, Cobertura etc. PROCESSO DE TESTE DE SOFTWARE

191 191 CARACTERÍSTICAS DOS TESTES AUTOMATIZADOS Os testes automatizados possuem algumas características, para que sejam realizados com precisão: Conciso: devem ser simples, dentro do possível. Explícito: devem ser relatados os desvios que ocorrem durante a execução. Repetível: devem ser executados quantas vezes forem necessário. Robusto: devem produzir os mesmos resultados consistentes e sem alterações externas ou de ambiente. Necessário: devem identificar desvios entre o que foi especificado e o que foi desenvolvido. Clareza/Manutenção: devem ter instruções de códigos claras e de fácil entendimento. Eficiente: devem ter desempenho satisfatório. Independente: devem satisfazer as precondições e permitir a execução em qualquer ordem. Rastreável: devem ser restreáveis a partir dos requisitos e demais origens. Mas como escolher a ferramenta de testes ideal? Para isso, segue abaixo uma checklist com alguns critérios que podem ser utilizados para escolher a ferramenta certa. Facilidade de uso. Manuais e guias com informações utéis. Suporte técnico e treinamento. Integração com outras ferramentas. Possibilidade de automatizar várias tecnológias. Linguagem de script robusta. Recursos de depuração de scripts. Suporte para múltiplas plataformas e navegadores. Reconhecimento de objetos e suas propriedades. Ferramentas de Teste de Software

192 192 UNIDADE V Recursos para comparação de arquivos (*.txt, *.pdf etc). Recursos para acesso a banco de dados. Recursos para a criação de testes dirigidos a dados. Execução dos testes distruibuídos em múltiplos computadores simultâneos. Geração de relatórios detalhados com o resultado da execução dos testes. Sommerville (2011, p. 466) define que uma organização tem a intenção de introduzir uma nova ferramenta de teste de software. Antes de introduzir a ferramenta, em um determinado momento você registra o número de defeitos de software descoberto. Essa é uma baseline de avaliação da eficácia da ferramenta. Depois de algum tempo usando a ferramenta, esse processo é repetido. Se mais defeitos foram encontrados durante o mesmo período, depois que a ferramenta foi introduzida, você poderá decidir se ela fornece suporte útil para o processo de validação de software. PROCESSO DE AUTOMAÇÃO DE TESTES O processo de automação de testes, consiste nas seguintes etapas: Decidir automatizar os testes: estudar o retorno de investimentos, os paradigmas e tipos de testes existentes para evitar falhas. Aquisição de uma ferramenta de automação de testes: definir critérios e o processo de aquisição das ferramentas. Demonstrar os benefícios, limitações e restrições da ferramenta. Introdução da automação de testes nas organizações: conduzir os procedimentos e melhores práticas que serão adotadas para a atividade de automação de testes. Planejamento, projeto e desenvolvimento dos testes automáticos: planejar e desenvolver os testes automatizados de um projeto. PROCESSO DE TESTE DE SOFTWARE

193 193 Execução e controle da automação de testes: executar os testes automatizados desenvolvidos. Também coletar métricas para o controle, por exemplo, indicadores de progresso, cobertura e eficiência. Revisão e melhoria do processo: conduzir avaliações com o objetivo de melhorias no processo de automação de testes. Ao desenvolver um cronograma, divida o trabalho, anote as dependências entre as tarefas, atribua esforço e tempo para cada tarefa e defina responsabilidades, resultados e pontos de controle. (Pressman). O teste de software é uma das principais atividades realizadas para melhorar a qualidade de um produto em desenvolvimento. Seu principal objetivo é revelar a presença de erros no software o mais cedo possível no ciclo de desenvolvimento de software, buscando minimizar o custo da correção dos mesmos. Embora o teste de software seja uma atividade bastante complexa, geralmente ela não é realizada de forma sistemática devido a uma série de fatores como limitações de tempo, recursos e qualificação técnica dos envolvidos. A automação de parte do teste de software tem sido vista como a principal medida para melhorar a eficiência dessa atividade, e várias soluções têm sido propostas para esta finalidade. A automação do teste consiste em repassar para o computador tarefas de teste de software que seriam realizadas manualmente, sendo feita geralmente por meio do uso de ferramentas de automação de teste. Fonte: Fantinato et al. (2002). Ferramentas de Teste de Software

194 194 UNIDADE V shutterstock MÉTRICAS E MEDIÇÃO Conforme Pressman (2011, p. 538), um elemento-chave de qualquer processo de engenharia é a medição. Você pode usar medidas para melhorar o entendimento dos atributos dos modelos criados e para avaliar a qualidade dos produtos ou sistemas construídos. Por sua natureza, a engenharia é uma disciplina quantitativa. Mas vocês devem estar se perguntando: por que medimos e avaliamos? Medimos principalmente para obter controle de um projeto e, portanto, poder gerenciá-lo. Medimos e avaliamos para estimar se estamos pertos ou longe dos objetivos definidos no plano em termos de conclusão, qualidade, compatibilidade com os requisitos etc. E por que é importante medir? Segundo Pressman (2011), sempre haverá um elemento qualitativo no desenvolvimento do software e, em alguns casos, a avaliação qualitativa pode não ser suficiente. A métrica proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa. Para entendermos melhor sobre métricas e medição, vamos apresentar alguns conceitos relacionados a métricas, que serão fundamentais para se entender o conteúdo a ser tratado nos próximos tópicos. PROCESSO DE TESTE DE SOFTWARE

195 195 Mas qual a diferença entre uma medida e uma métrica? E os indicadores? São termos que são usados com frequência e que em algum momento você já ouviu falar. Vamos apenas nos ater ao contexto de engenharia de software. Segundo Pressman (2011, p. 539): Medida: indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum atributo de um produto ou processo. Medição: é o ato de determinar uma medida. O IEEE define métrica como uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo. Indicador: é uma métrica ou combinação de métricas que proporcionam informações sobre o processo de software, em um projeto de software ou no próprio produto. Um engenheiro de software coleta medidas e desenvolve métricas para obter indicadores. Pressman (2011, p. 594) define que o principal objetivo da engenharia de software é produzir um sistema, aplicação ou produto, de alta qualidade, dentro de um prazo que satisfaça as necessidades do mercado. Para atingir esse objetivo, devem-se aplicar métodos eficazes, combinados com modernas ferramentas dentro do contexto de um processo de software bem desenvolvido. Além disso, um bom engenheiro de software (e bons gerentes de engenharia de software) deve medir se a alta qualidade será obtida. As métricas de processo têm impacto de longo prazo. Seu objetivo é melhorar o próprio processo. As métricas de projeto muitas vezes contribuem para o desenvolvimento de métricas de processo. Sommerville (2011) define que a medição tem um objetivo a longo prazo que é o de ser usada para revisões e fazer julgamento sobre a qualidade de software. Segundo o autor, ao usar a medição de software, o sistema poderia ser parcialmente avaliado e com isso deduzir um valor para a qualidade do sistema e se ele atingir o valor estipulado, ele poderia ser aprovado. A medição também pode ser usada para realçar áreas do software que podem ser melhoradas. Métricas e Medição

196 196 UNIDADE V CONCEITOS RELACIONADOS A MÉTRICAS DE TESTE DE SOFTWARE Conforme Trodo (2009), o enfoque das métricas de teste de software são a produtividade e qualidade. Quando medimos um processo, estamos avaliando a produtividade, e quando estamos medindo um produto, a qualidade é que está sendo avaliada. A respeito das métricas de teste, o referido autor pontua que: As métricas de teste são um padrão de medidas muito útil para a verificação da efetividade e da eficiência de diversas atividades do desenvolvimento de software. Também são usadas para prover informações como estimativas do esforço necessário para o teste. É importante que elas sejam capturadas e utilizadas corretamente para que possam auxiliar na melhoria do processo de desenvolvimento do software através de informações objetivas e pragmáticas para iniciativas de mudanças do processo (TRODO, 2009, p. 15). Trodo (2009) menciona que as métricas de teste subdividem-se em: Métricas básicas: obtidas diretamente do esforço do teste. Exemplo de métricas básicas: quantidade de casos de teste criados, executados, bloqueados, reexecutados, que passaram, que falharam e que estão sob investigação. Métricas derivadas: obtidas pelo gerente ou pelo líder de teste, por meio da conversão das métricas básicas em dados mais úteis. Exemplo de métricas derivadas: percentual dos testes concluídos, da cobertura dos testes, dos casos de testes que passarão, ou que estão bloqueados, das falhas na primeira execução, dos defeitos, do retrabalho, da efetividade e da eficiência dos testes, a taxa de defeitos descobertos e o custo de remoção dos defeitos. Conforme Trodo (2009, p. 16) as principais medidas de um teste são a cobertura e qualidade. A cobertura diz respeito à abrangência do teste e a qualidade é uma medida de confiabilidade, estabilidade e desempenho do objetivo do teste. A avaliação da cobertura fornece uma medida para avaliar a conclusão dos testes e a avaliação dos defeitos detectados indica a qualidade do software. PROCESSO DE TESTE DE SOFTWARE

197 197 Alguns atributos podem ajudar os testadores nas métricas de teste. Para Trodo (2009) os atributos são: Senso de antecipação: é baseado na experiência e significa pensar adiante, nos tipos de métricas que podem ser úteis. Disciplina: auxilia os testadores a lidaram com o fato de que o serviço de testar é uma tarefa repetitiva e, por vezes, tediosa. Uso de ferramentas: ajuda os testadores a gerenciar melhor a tarefa de testar o software. Conforme Trodo (2009) alguns objetivos nos guiam para usamos as métricas de teste: Analisar os defeitos. Analisar a eficácia e a eficiência dos testes e do processo como um todo. Avaliar a produtividade do processo. Analisar o retorno de investimento. Determinar o esforço para automação dos testes. Calcular o tempo e os recursos para automação dos testes. Avaliar o andamento dos testes. Planejar os recursos, prazos e benefícios do processo de testes. Identificas áreas que necessitam de melhorias. Melhorar a exatidão das estimativas. Formar uma baseline para as estimativas. Auxiliar no gerenciamento do projeto e da execução dos testes. Auxiliar nos contratos de software. Auxiliar no relacionamento com os clientes. Auxiliar na melhoria do processo de desenvolvimento do software. Avaliar os benefícios de novos métodos e ferramentas. Métricas e Medição

198 198 UNIDADE V Embasar eventuais solicitações de novas ferramentas e treinamento. Avaliar o impacto na qualidade e na produtividade do produto ou do processo que eventuais variações podem causar. Viabilizar a tomada de decisão de forma ágil. Detectar tendências nos dados. Identificar áreas de riscos. Visualizar se o produto está pronto para a liberação ao cliente. Indicar a qualidade de forma geral. Segue uma lista de perguntas que podem ser feitas e respondidas quando se usa métricas de software: Quando parar de testar? Quanto tempo falta para terminar o ciclo de testes? Quanto já foi testado? Os testes serão concluídos dentro do prazo previsto? Quanto teste ainda tem que ser feito em determinada área? Já foi testado o suficiente? Qual o custo dos testes? Qual o custo para corrigir os defeitos? Quantos defeitos podem esperar? Quais os tipos de defeitos encontrados? Quantos defeitos já foram corrigidos? Quais as áreas do software que têm mais ou menos defeitos? Quão estável é a funcionalidade que está sendo testada? Qual a técnica de teste que é mais efetiva? PROCESSO DE TESTE DE SOFTWARE

199 199 Estamos testando de forma difícil ou inteligente? Temos um programa de teste robusto ou um suíte de testes fraca? Quais os defeitos prioritários? Qual o testador que encontrou mais defeitos? Quantos defeitos foram localizados por um determinado testador? Quantos defeitos foram encontrados pelo usuário? Para Trodo (2009), é difícil para a equipe de testes responder a todas as perguntas. Conforme o autor cita, por exemplo, para a pergunta Quanto já foi testado?, o uso da métrica da cobertura dos testes, que é o percentual dos testes que já foram concluídos, para respondê-la. Se os testadores não têm as estimativas não conseguem responder as perguntas, pois não sabem exatamente o quanto ainda precisam testar e assim achar que testaram o suficiente. Como muitos fatores afetam o trabalho de software, não use métricas para comparar indivíduos ou equipes. (Pressman). MÉTRICAS DE TESTE DE SOFTWARE EXISTENTES As métricas de teste de software existentes, segundo Trodo (2009), são: Métricas de produto: servem como auxiliar no controle da qualidade do produto que está sendo testado. Temos vários relatórios que são gerados para esse tipo de métrica, como os relatórios de defeitos no produto. Exemplo de métricas de produto: Métricas e Medição

200 200 UNIDADE V Número de ocorrências. Status das ocorrências. Índice de Densidade de defeitos. Índice de Severidade de defeitos. Tempo para arrumar um defeito. Tempo médio para encontrar um defeito. Qualidade de falhas encontradas no produto. Tipos de defeitos encontrados. Cobertura dos testes. Efetividade de Caso de teste. Defeitos por quantidade de linhas de código (Kloc). Situação ou Tendência dos defeitos em função do tempo. Providências adotadas em relação aos defeitos. Defeitos por módulo. Defeitos por tecnologia utilizada. Métricas de Processo: servem para auxiliar no controle da qualidade do processo de testes. Segue alguns exemplos de métricas de processo: Número de Casos de teste. Taxa de falhas na primeira execução dos Casos de Teste. Custo dos testes. Curva S. Curva Zero Bug Bounce. Relação entre defeitos e ocorrências. Ocorrências pendentes de correção. PROCESSO DE TESTE DE SOFTWARE

201 201 Probabilidade de defeitos. Mudanças no escopo. Densidade de defeitos por Unidade. Métricas de Projeto: os relatórios sobre o status do projeto, o andamento do processo, como funcionalidade, qualidade etc., despesas e outros consumos de recursos, são produzidos usando as métricas de projeto. Exemplos de métricas de projeto: Tempo de teste estimado X Tempos de teste efetivamente utilizado. Fator de segurança. Tempo necessário para executar um teste. Tempo disponível para o esforço de teste. Taxa de esforço de teste. Categoria de defeitos. As métricas de teste são, geralmente, identificadas quando se inicia o projeto e devem ser quantificáveis, de fácil coleta, simplificadas e que tenham um propósito. As métricas que foram coletadas devem ser sempre exploradas na avaliação do andamento e da integridade do projeto e devem ser guardadas para uso no futuro em outras estimativas de projetos novos. PROBLEMAS NA UTILIZAÇÃO DAS MÉTRICAS DE TESTE DE SOFTWARE Conforme Trodo (2009, p. 81), as métricas de teste de software são bastante úteis ao processo de teste, porém, é importante observar algumas dificultadas relacionadas ao assunto. As questões tratadas variam de problemas gerenciais e de relacionamento a observações específicas sobre como o uso isolado das métricas pode fornecer informações equivocadas. Métricas e Medição

202 202 UNIDADE V Abaixo, seguem algumas dicas de cuidado a serem adotadas quando se analisa a qualidade: As métricas de teste por si só não fornecem a percepção adequada da real qualidade aplicada. As métricas de teste não devem ser analisadas isoladamente. O estudo da origem dos problemas como parte da análise das métricas provê resultados mais confiáveis. Uma análise sistemática e completa das métricas de teste é importante para que sejam consideradas como ferramentas confiáveis para medir a qualidade da aplicação. As tendências de algumas métricas de teste podem ser analisadas por diversos ciclos de teste, enquanto outras são relativas a um ciclo de teste específico. O que achou das métricas de teste? Difícil? O que envolve a qualidade pode ser considerado um conceito complexo, porque pode significar diferentes situações para diferentes pessoas. Assim, como temos diferentes empresas com diferentes projetos, não há uma simples medida para qualidade de software que seja aceitável para todos. Mas sempre devemos pensar que para melhorar a qualidade de software, devemos definir quais aspectos de qualidade que interessa a empresa para depois decidir quais serão usados e, depois, como medi-los. PROCESSO DE TESTE DE SOFTWARE

203 203 Medindo-se características da especificação, é possível obter informações quantitativas sobre peculiaridade e totalidade. (Pressman). Assim como qualquer outra disciplina de engenharia, o desenvolvimento de software requer um mecanismo de medição para obter as informações sobre a execução do processo necessárias para o seu correto entendimento e avaliação. Medir é o processo por meio do qual números ou símbolos são atribuídos a características das entidades do mundo real de forma a tornar possível caracterizar cada entidade por meio de regras claramente definidas. O uso de métricas nos ajuda a entender e a interagir com o mundo para, então, poder melhorá-lo. Muitas métricas foram propostas e aplicadas em casos práticos a fim de alcançar os seguintes objetivos: i) melhorar o entendimento sobre o processo, produto, recursos e ambiente de desenvolvimento e, assim, estabelecer bases para comparação entre medições; ii) avaliar o andamento do projeto comparando com dados planejados; iii) fazer previsões sobre o futuro andamento do projeto baseado em comportamentos passados; iv) promover melhorias identificando falhas, ineficiências e outras oportunidades para melhorar a qualidade do produto e o desempenho do processo. Fonte: Gomes, Oliveira e Rocha (2001). Gerência de Risco em Teste de Software

204 204 UNIDADE V shutterstock GERÊNCIA DE RISCO EM TESTE DE SOFTWARE Bastos et al. (2007, pg. 89) define que a análise de riscos em projetos de teste de software, embora tenha suas características próprias, deve seguir as mesmas regras e metodologias aplicadas a projetos de software em geral. A atividade de teste é bastante cara. Podendo custar até 45% do valor inicial do projeto. A grande competitividade, o surgimento de softwares cada vez mais complexos e a necessidade de qualidade relacionada à satisfação do cliente, justificam este investimento. A análise de risco, segundo Bastos et al. (2007) é tratada no escopo de projeto pelo PMI e de processo pelo modelo CMMI e, em cada uma dessas abordagens, o projeto ou processo de Teste de Software pode perfeitamente ser enquadrado. Quando avaliamos os riscos de um projeto, conforme Bastos et al. (2007), estamos buscando aqueles fatos que poderão acarretar em perdas para a empresa. Não podemos sempre aliar um risco a uma perda. Um risco pode estar sempre presente, mas nem sempre ele gera uma perda. Existem riscos que sempre se transformam em perdas. Para Bastos et al. (2007) um avião sempre corre risco de cair, mas a perda só existirá se isso ocorrer. Resumindo, podemos dizer que o risco é uma probabilidade de ocorrência de uma perda para a empresa. PROCESSO DE TESTE DE SOFTWARE

205 205 Conforme Bastos et al. (2007) exemplifica, hoje, qualquer empresa corre risco, se em algum momento seus computadores pararem de funcionar. Um site fora do ar pode trazer muitos prejuízos para uma empresa. O risco para uma empresa está relacionado ao grau de dependência em relação ao seu equipamento. Agora, imagine, a ocorrência de erros de software e os prejuízos a uma empresa caso o seu software seja interrompido? Se por ventura o sistema de faturamento sofra algum defeito e ele seja interrompido e a empresa deixe de receber o dinheiro? Segundo Bastos (2007), devido a estes problemas, gerentes de TI passaram a investir para evitar riscos de defeitos em seus softwares, criando planos de contingência para contornar os problemas. Medindo-se características da especificação, é possível obter informações quantitativas sobre peculiaridade e totalidade. (Pressman). CONCEITUANDO RISCO Quando falamos de risco, estamos sempre pensando na perda que a empresa pode ter devido a sua ocorrência. Esta definição extraída do dicionário Houaiss, é bastante clara: risco é a probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimento eventual, incerto, cuja ocorrência não depende, exclusivamente, da vontade dos interessados. Tratar riscos depende de algumas decisões objetivas que poderão prevenir sua ocorrência ou, na pior das hipóteses, evitar que a sua ocorrência se reverta em sérios prejuízos. Mas o que leva um risco a se tornar uma perda? Ele se torna potencialmente uma perda quando ocorre a ameaça de sua ocorrência. E como elas podem ser reduzidas? Podem ser reduzidas com o uso de mecanismos de controle, que ajudam a controlar as ameaças e com isso evitar a sua ocorrência. Gerência de Risco em Teste de Software

206 206 UNIDADE V Segundo Bastos et al. (2007), quando os meios de controle são insuficientes ou inadequados para administrar a ocorrência de um risco, surgem então, vulnerabilidades. Para os autores, a análise de riscos é o processo de avaliar riscos, ameaças, controles e vulnerabilidades. Muitas informações? Para compreendermos melhor o gerenciamento de riscos, vamos conhecer alguns conceitos, conforme Bastos et al. (2007). Riscos: uma perda grande para a empresa e pode ser medido usando a análise de risco. Análise de risco: avaliação dos recursos de informação, seus controles e suas vulnerabilidades. Ameaça: capacidade de alguém explorar a vulnerabilidade de um sistema. Vulnerabilidade: é uma falha de projeto, implementação ou programação. Controle: maneira de reduzir as causas de riscos, evitando a sua ocorrência ou reduzindo a sua frequência. Então, podemos disser que os riscos podem causar grandes danos às empresas, se caso vir a acontecer uma ameaça de ocorrência. Seguindo informações de Bastos et al. (2007), o risco é uma materialização de uma ameaça e com a análise de riscos podemos identifica-los e com isso medir seu nível de severidade. Podemos dividir os riscos presentes na área de tecnologia, ligados ao uso de computadores em: riscos por ameaça física ou riscos decorrentes da ação de pessoas. No caso de riscos por ameaça física, temos terremotos, incêndios, enchentes etc. No caso de riscos decorrentes da ação de pessoas, temos: erros de documentos preenchidos errados, erros durante a operação do sistema, erros de alimentação de dados, entre outros. RISCOS RELATIVOS AO TESTE DE SOFTWARE A atividade de testar o software está bastante ligada ao risco. Teste custa dinheiro, e quanto maior for a cobertura dos testes, tanto mais terá que ser investido para que haja a garantia de que nenhum defeito irá ocorrer quando o software estiver em produção. As empresas concordarão em investir em teste, caso a ocorrência de um defeito seja um risco para o negócio. PROCESSO DE TESTE DE SOFTWARE

207 207 Conforme Bastos et al. (2007), os testes exaustivos visam garantir que nenhum defeito irá ocorrer quando o software for entregue, certamente não será executado pela maioria das empresas. Geralmente, as equipes de teste das empresas procuram um nível de cobertura que minimizem a possibilidade de defeitos graves, pois existem prazos a serem cumpridos. E o que os testadores podem fazer para minimizar esses defeitos? Os testadores podem procurar cobrir as partes mais importantes do software, em que estão os maiores riscos para os negócios. O risco é um dos elementos mais importantes para ser considerado na elaboração do projeto de testes, por isso, precisa ser analisado e incluído no plano de testes, porque esses riscos possuem níveis de prioridade altos. Segundo Bastos et al. (2007, p. 93), é importante lembrar que, quanto mais bem organizada a equipe de testes, melhores serão os resultados e é sempre bom lembrar que o risco é um dos elementos mais importantes a ser trabalhado no momento de se elaborar o projeto de testes. Assim, ao fazermos uma análise dos riscos devemos pensar em: Probabilidade de ocorrência do risco. O impacto e a perda que estão associados a esse risco. Os riscos podem estar associados, por exemplo, ao uso de uma nova tecnologia ainda não perfeitamente dominada pela equipe de desenvolvimento, ou pelas prioridades estabelecidas para algumas funcionalidades do negócio. Mas como saber qual o número de testes a ser executado para minimizar os defeitos ou a probabilidade para que não ocorrerem? Segundo Bastos et al. (2007), o total de testes a ser executado está diretamente relacionado ao total de riscos envolvidos. Uma análise de riscos bem feita, com uma adequação dos recursos disponíveis pela equipe, ajuda a estabelecer quais as prioridades do que será testado. Na tabela 2, podemos analisar que a maior prioridade de teste é dada a funcionalidade em que o impacto causado pelo defeito e a probabilidade de ocorrência de um risco são grandes (AA). Gerência de Risco em Teste de Software

208 208 UNIDADE V Tabela 2: Qualificação dos riscos - Probabilidade versus impacto IMPACTO QUE O RISCO CAUSA AO NEGÓCIO PROBABILIDADE DE OCORRÊNCIA DO RISCO Alta Média Baixa Alto AA AM AB Médio MA MM MB Baixo BA BM BB Fonte: Bastos et al. (2007). Bastos et al. (2007, p. 94) pontua que os riscos mudam no decorrer do tempo o que era um risco alto em um determinado momento pode deixar de ser no momento seguinte, e o que é risco em um determinado ambiente pode deixar de ser um risco em outro. Quanto mais você sabe, melhor você estima. Portanto, atualize suas estimativas à medida que o projeto avança. (Pressman). RISCOS DO PROCESSO DE TESTE Conforme Bastos et al. (2007) se considerar-nos apenas a atividade de testar, alguns riscos básicos podem ser caracterizados. Segue uma lista dos possíveis riscos básicos: Orçamento: o orçamento é insuficiente para executar o teste completo e com isso as prioridades podem sofrer mudanças. Qualificação da equipe técnica de teste: deve ser avaliado se a equipe de teste está preparada com a tecnologia adotada. Ambiente de teste: o ambiente de teste deve estar o mais próximo do ambiente do cliente. Ferramentas: a escolha de ferramentas pode ser um projeto específico que poderá conter seus próprios riscos. PROCESSO DE TESTE DE SOFTWARE

209 209 Metodologias: executar testes sem uma metodologia adequada é um risco que podem trazer resultados indesejados à qualidade do sistema. Cronograma de recebimento de programas para teste e Cronograma para devolução: negociar prazos adequados e que atendam ao padrão mínimo de qualidade estabelecido para o negócio. Testware: deve ser criada uma metodologia que permita guardar a documentação para uso futuro e o fato de não precisarmos refazer esse material diminui os riscos dos testes malfeitos. Novas tecnologias: o uso de novas tecnologias e novos ambientes para operação dos sistemas trouxe um novo elemento de risco para as empresa e com isso a equipe de testes deve dominar o uso de novas tecnologias. DETERMINAÇÃO DA MAGNITUDE DOS RISCOS Segundo Bastos (2007, p. 96), o problema muitas vezes consiste em determinar como classificar o risco e qual o custo de criação de um controle que evite a ocorrência desse risco. A relação custo-benefício precisa ser avaliada antes de tomar qualquer decisão, porque o custo do controle do risco pode ser maior do que o risco mesmo. O QAI Quality Assurance Institute estabelece que um risco pode ser determinado das seguintes formas: Intuição ou julgamento: um técnico qualificado e experiente da área de teste usa a sua intuição, aliado a sua experiência, para dizer que a ocorrência de um risco pode custar mais caro do que os controles necessários para que ele não ocorra. Consenso: consenso na equipe de que aquele risco tem um grau alto de severidade, nesses casos, não há necessidade de medir-se financeiramente o custo do risco, pois há consenso que a sua ocorrência causará um prejuízo muito grande, e o bom senso indica a criação de algum tipo de controle que evite a sua ocorrência. Fórmula de Risco: magnitude do risco é calculada por meio de uma fórmula. Existem dados financeiros que permitem medir o custo da perda pela ocorrência do risco. Medindo-se cada custo pelo número de ocorrências, por exemplo, por ano, temos uma estimativa de perdas. Nesse caso, podemos ter resultados bastante precisos sobre as perdas. Gerência de Risco em Teste de Software

210 210 UNIDADE V RISCOS BASEADOS NAS CARACTERÍSTICAS DA QUALIDADE Bastos et al. (2007) afirma que devemos tomar cuidado especial quando se classificam os riscos do projeto de testes e os riscos da ocorrência de defeitos. Para os autores, um projeto de testes, como todo projeto, está envolto em uma lista de possibilidade de riscos, que podem, por sua vez, fazer com que o software seja mal testado e com isso, pode ocasionar a ocorrência de defeitos. Como podemos minimizar a ocorrência de defeitos no software? Para minimizar a ocorrência de defeitos nos softwares, é utilizado uma norma de qualidade, como a Norma ISO/IEC A Norma ISO/IEC estabelece características de qualidade que todo software deve ter. Na tabela 3 apresentamos uma lista de algumas características: Tabela 3: Algumas características de qualidade dos softwares ISO/IEC CARACTERÍSTICA Funcionalidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade DESCRIÇÃO Capacidade do software de fornecer funcionalidades que atendam à necessidade definida quando usado sob determinadas condições preestabelecidas. Capacidade do software de manter um nível específico de desempenho quando usado sob determinadas condições preestabelecidas. Capacidade do software de ser entendido, aprendido, usado e atrativo quando empregado sob determinadas condições específicas. Capacidade do software de manter o desempenho, em relação aos recursos disponíveis, quando usado sob determinadas condições específicas. Capacidade do software de ser mantido. Capacidade do software de ser transferido de um ambiente para outro. Fonte: Bastos et al. (2007). PROCESSO DE TESTE DE SOFTWARE

211 211 Para garantir que o software não perca nenhuma das características de qualidade estabelecidas pela norma, Bastos et al. (2007) sugere que seja necessário fazer uma associação entre os tipos de teste e as características de qualidade que se quer alcançar ou cumprir. Lembra dos tipos de testes que vimos na unidade IV? Vamos recordar, associando-os com as características de qualidade que possam ser atendidas. Tabela 4: Características de qualidade com os tipos de teste CARACTERÍSTICA EXEMPLOS DE TESTES Funcionalidade Teste de funcionalidade Confiabilidade Teste de estresse Usabilidade Teste de usabilidade Eficiência Teste de desempenho Manutenibilidade Teste Caixa-branca (entre outros) Portabilidade Teste de produção (entre outros) Fonte: Bastos et al. (2007). Uma lembrança importante que o testador deve sempre manter em mente ao fazer a sua análise de riscos é que os riscos mudam com o tempo. Caso o sistema precise alguns anos depois voltar a ser testado, em decorrência de uma manutenção grande, pode ser que os riscos também tenham que sofrer uma manutenção. Neste caso, uma nova estratégia de testes deverá ser traçada. Para Bastos et al. (2007) uma das maneiras de reduzirmos os riscos do software é testarmos o software adequadamente. Chegamos ao final de mais uma unidade. E agora? Finalizamos os testes? Você(s) deve(m) estar se perguntando, depois de tudo que aprendemos sobre os testes: quando os testes de software param?. Gerência de Risco em Teste de Software

212 212 UNIDADE V A resposta para esta pergunta vai depender de cada projeto. Mas podem ter diversos motivos para definir em um projeto, quando os testes devem parar, por exemplo: prazo, orçamento e riscos. Conforme Pressman (2011) os testes trazem informações suficientes para a tomada de decisão pelos engenheiros do projeto e com isso o grau de maturidade e qualidade do software que está sendo desenvolvido. Mas o bom é saber que sempre temos uma versão beta. Está comprovado que quanto mais cedo for detectado e corrigido um defeito, menor será o impacto e a propagação nas demais fases do ciclo de vida. Desta forma, devemos procurar identificar os defeitos o mais breve dentro do processo de desenvolvimento, ou seja, já a partir da identificação dos requisitos do sistema. O pior resultado obtido por um sistema de informação é quando seus requisitos não correspondem àqueles esperados por seus usuários. Se a análise de requisitos for pobre, todo o restante do processo estará comprometido e o risco de insucesso do projeto será bastante alto. Para auxiliar na identificação de defeitos durante a etapa de análise de requisitos podemos recorrer às inspeções. Inspeções são uma das poucas técnicas de revisão disponíveis para aplicação em artefatos de software que não o código-fonte, podendo ser aplicadas a qualquer tipo de documento escrito, sejam eles especificações de requisitos, documentos ou modelos de projeto. Fonte: Costa Júnior e Melo (2003). PROCESSO DE TESTE DE SOFTWARE

213 213 CONSIDERAÇÕES FINAIS Nesta unidade, aprendemos a importância dos documentos de testes de software dentro do projeto de testes. Vimos quais os documentos mínimos necessários para que um processo de testes funcione convenientemente, ou seja, bem sucedido. Aprendemos sobre o Plano de Testes, que é um escopo de referência durante a execução do teste e também serve como documento de comunicação junto ao cliente que contratou o serviço de teste. Vimos sobre os Casos de Teste, que estabelecem o que será testado e quais as informações que serão empregadas durante os testes dos cenários e quais serão os resultados esperados. Aprendemos sobre os Relatórios de Testes do Software que são usados para registrar os dados relativos à execução de um dos tipos de teste. Cada novo relatório deve ser adicionado sequencialmente aos Relatórios dos Testes do Software. Ao longo desta unidade, aprendemos também sobre verificação e validação, e suas diferenças. Vimos que a verificação refere-se ao conjunto de tarefas que garantem que o software implemente corretamente uma função específica e a validação, que refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode ser rastreado segundo os requisitos do cliente Outro tópico importante que aprendemos, foram sobre as ferramentas de teste, que são o apoio dos profissionais da área de teste, pois cobrem grande parte das atividades de teste e são aplicáveis em todas as fases do ciclo de vida do desenvolvimento do software. Além disso, aprendemos sobre as métricas e medições. A métrica proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa. E chegando ao final da unidade, aprendemos sobre a gerência de riscos, em que vimos como a análise de riscos em projetos de teste de software, embora tenha suas características próprias, deve seguir as mesmas regras e metodologias aplicadas aos projetos de software. Considerações Finais

214 Conforme vimos, os documentos que são definidos pela norma cobrem tarefas de planejamento, especificação ou elaboração e análise dos resultados. A norma ou padrão IEEE 829 (Institute of Electrical Engineers) especifica que devem ser usados quais documentos? 2. O Plano de teste possui várias funções, dependendo de sua situação. Quais são as principais funções de um Plano de Teste: I. Suportar o desenvolvimento da qualidade dos produtos, de forma sábia, sincronizada com as decisões e não ter as informações históricas do projeto, de forma a suportar auditoria e melhorias para futuros projetos. II. Descrever e justificar a estratégia de testes para com os requisitos do produto a ser testado. III. Suportar o início e a organização do projeto de teste, incluindo aí preparações, pessoal, delegação de responsabilidades, planejamento das tarefas etc. IV. Suportar o gerenciamento diário e a revolução do projeto de implementação e da estratégia. V. Suportar a efetiva coordenação, colaboração e outros relacionamentos entre os membros da equipe e o resto do projeto. Identificar e gerenciais quaisquer riscos ou questões que possam impactar no projeto. Assinale a opção com a sequência CORRETA. a. Somente a questão II, III e V está correta. b. Somente as questões I e II estão corretas. c. Somente a questão II está correta. d. Todas estão corretas.

215 Podemos considerar como objetivo da Verificação e Validação: a. A capacidade do produto de software de evitar falhas decorrentes de defeitos no software. b. Determinar a completeza da documentação do software. c. Garantir que tanto o modo pelo qual o software está sendo construído quanto o produto em si esteja em conformidade com o especificado. d. Testar o software até que ele não apresente defeitos. 4. Para se modelar a confiabilidade de software é necessário considerar, exceto: a. A remoção de defeitos b. A prevenção de defeitos c. A introdução de defeitos d. O ambiente no qual o software é executado 5. Qual a importância da Gerência de Risco em projetos de Teste de Software?

216 216 GERENCIANDO RISCOS NOS PROJETOS DE SOFTWARE por Mauricio Aguiar Consta que o risco é uma ciência nascida no século dezesseis, durante a Renascença. A palavra risco tem origem na antiga palavra italiana risicare, que significa ousar. Naquela época, os jogos de azar levaram à descoberta da teoria das probabilidades, indispensável à determinação do risco. Hoje em dia, mais e mais organizações envolvidas com a produção de software voltam-se para o Gerenciamento de Riscos, como forma de antecipar e minimizar o efeito de eventos que possam impactar negativamente os objetivos dos projetos de software. Neste artigo introduziremos alguns conceitos básicos para o Gerenciamento de Riscos em projetos de software. Riscos em Projetos de Software O risco em um projeto de software é uma medida da probabilidade e da perda relacionadas à ocorrência de um evento negativo que afete o próprio projeto, seu processo ou o seu produto. Em outras palavras, qualquer coisa que possa acontecer e ameaçar o bom andamento do projeto é um risco. O risco do projeto relaciona-se com aspectos operacionais, organizacionais e contratuais. Este tipo de risco é uma responsabilidade do Gerente do Projeto, nele estando incluídos limitações de recursos, interfaces externas, relacionamentos com fornecedores e restrições contratuais. Exemplos comuns são fornecedores incapazes de responder à altura e falta de apoio da organização para o projeto. A falta de controle sobre as dependências externas do projeto torna extremamente difícil o gerenciamento dos riscos. Normalmente, o maior risco dos projetos de software é financeiro tem a ver com a obtenção dos recursos orçamentários. O risco do processo inclui tanto procedimentos técnicos quanto gerenciais. Nos procedimentos gerenciais, esse tipo de risco será encontrado no planejamento, na obtenção de recursos humanos, no acompanhamento e controle do projeto, na garantia da qualidade e na gerência de configuração. Nos procedimentos técnicos, o risco será encontrado em atividades tais como a análise de requisitos, o design, a codificação e o teste. O risco do produto está associado as suas características. Esse tipo de risco é uma responsabilidade técnica (não gerencial). Será encontrado na estabilidade dos requisitos, na performance do design, na complexidade do código e nas especificações de teste. O maior risco relativo ao produto nos projetos de software refere-se aos requisitos. Gerenciamento de Riscos em Projetos de Software O Gerenciamento de Riscos de Software consiste em avaliar e controlar os riscos que afetam o projeto, processo ou produto de software. A melhor maneira de descobrir os riscos é definir, inicialmente, os objetivos e metas do projeto. Os riscos são gerenciados tendo em vista objetivos específicos, podendo afetar apenas o trabalho que falta para alcançá-los.

217 217 As perguntas importantes são: qual o risco contido no plano? Qual o risco contido no trabalho ainda restante? A incerteza é inerente a todas as suposições do projeto. [...] A probabilidade de ocorrência do risco é um dos fatores para a determinação de sua prioridade. Um dos conceitos fundamentais do Gerenciamento de Riscos é a perda. É preciso que haja um potencial de perda para que haja risco. Um Processo para Gerenciamento de Riscos O risco nos projetos de software pode ser gerenciado através das seguintes atividades: identificação dos riscos, análise dos riscos, planejamento dos riscos, acompanhamento dos riscos e resolução dos riscos. O processo começa com a identificação dos riscos. Tudo o que se referir a incerteza, experiências anteriores, preocupações e questões a resolver pode ser útil na identificação dos riscos. Várias fontes podem ser utilizadas nesta fase: pessoas incluem clientes, integrantes da equipe, organizações envolvidas, disponibilidade, capacidade, experiência etc.; produto e processo abrangem requisitos, prazos, estimativas, receitas, despesas, orçamento, restrições de natureza legal, estilo de gerenciamento, tamanho e escopo do projeto etc.; tecnologia inclui mudanças, inovação, adoção e uso, integração e interfaces, experiência específica, segurança, arquitetura, escalabilidade etc. [...] Em seguida, deve-se calcular a exposição referente a cada risco, definida como o produto da probabilidade de ocorrência do risco pelo respectivo impacto. A exposição é utilizada na priorização dos riscos. O planejamento dos riscos inclui a definição de cenários para os riscos mais importantes, a definição de alternativas de solução para esses cenários, a escolha das alternativas mais adequadas, o desenvolvimento de um Plano de Ação de Riscos, assim como o estabelecimento de limiares ou disparadores para a ação. O acompanhamento dos riscos envolve a monitoração dos cenários de riscos, a verificação de que os limiares foram ou não atingidos, bem como a análise das medidas e indicadores referentes aos riscos [...] Gerenciamento de Riscos e o PMBOK O Project Management Institute (PMI) define um processo genérico para o Gerenciamento de Riscos, ligeiramente diferente do exposto acima. Segundo o Project Management Body of Knowledge PMBOK, o Gerenciamento de Riscos é o processo sistemático de identificação, análise e resposta aos riscos dos projetos. Inclui maximizar a probabilidade e as consequências dos eventos positivos, bem como minimizar a probabilidade e consequência dos eventos negativos, em relação aos objetivos do projeto. Ferramenta para Gerenciamento de Riscos Um ferramenta gratuita para o Gerenciamento de Riscos em geral (não apenas de software) é o software TRIMS, desenvolvido pelo BMP Center of Excellence, uma organização patrocinada pela Marinha e pelo Departamento do Comércio Norte-Americanos, bem como pela Universidade de Maryland. O software contém o questionário para avaliação de riscos do Software Engineering Institute, para utilização em projetos de software. Fonte: Aguiar (online, 2016).

218 MATERIAL COMPLEMENTAR Garantia da Qualidade de Software Alexandre Bartié Editora: Elsevier Sinopse: Totalmente alinhado com as mais modernas metodologias existentes no mercado, este livro coloca você diante dos conceitos mais avançados sobre como aplicar um Processo de Garantia da Qualidade de Software na sua empresa. Usando uma abordagem simplificada e de fácil de entendimento, possibilita aos leitores assimilar gradualmente os aspectos mais relevantes envolvidos na implantação de um Processo de Garantia da Qualidade de Software. Estabelece uma visão corporativa de qualidade de software e prepara a organização ao desafio de incorporar estes conceitos no seu dia a dia. Combinando visão acadêmica com realidade empresarial, o livro apresenta um modelo metodológico viável tanto para as organizações que nunca iniciaram um SPI (Software Process Improvement) quanto às organizações que buscam atingir os níveis CMM 2 e 3. A busca pela viabilidade na aplicação das melhores práticas voltadas à garantia da qualidade de software torna este livro uma peça-chave para fazer uma verdadeira revolução na sua organização. Planeje seus Testes de Software e não morra na praia. Imagem Art Studio Editora: Imagem Art Studio Sinopse: Um gerente ou um líder de projeto, normalmente não tem tempo para ficar pesquisando em livros as informações que precisa. Por outro lado, a informação, quando encontrada, é apresentada de uma forma complexa e muitas vezes inacessível para um acesso rápido. Um livro leve, de fácil leitura, não significa que é um documento superficial. Nós nos preocupamos em passar por todos os tópicos importantes que envolvem o planejamento nos projetos de teste de software. Desta forma, tomamos como objetivo o Plano de Teste, instrumento básico de planejamento desses projetos, e abordamos numa linguagem acessível tópicos como: Processo; Planejamento; Equipe; Documentação; Ambiente e Estimativas. Além disso, o livro tem um anexo sobre a história do teste de software no Brasil e no mundo e uma visão rápida sobre teste ágil. Achamos melhor esta abordagem do que incluir um capítulo sobre metodologia de teste.

219 MATERIAL COMPLEMENTAR Apresentação: Ferramentas de suporte ao Teste de Software. Artigo que apresentada algumas ferramentas de diferentes características e classificações voltadas para fornecer um amplo suporte ao teste de software. Maior agilidade nas atividades do Processo de Teste, como a utilização de ferramentas de suporte ao teste pode contribuir para consideráveis ganhos de tempo, produtividade, confiabilidade e principalmente com a qualidade em cada uma das etapas do ciclo de vida do teste. Ao longo do artigo serão apresentadas algumas ferramentas de diferentes características e classificações voltadas para fornecer um amplo suporte ao teste de software. Muito interessante o artigo. Para consultá-lo, acesse o link: < Apresentação: Padrão para Documentação de Teste de Software. Veja neste artigo uma apresentação do Padrão para Documentação de Teste de Software (IEE Standard for Software Test Documentation). O padrão apresentado nesse artigo é o IEEE 829, está relacionado com o processo de testes, etapa do processo de desenvolvimento de software de suma importância para garantia e controle da qualidade. Sua abrangência vai desde testes unitários até testes de aceitação e tem por objetivo definir documentos consistentes e adequados capazes de definir, registrar e prover condições de análise dos resultados obtidos ao longo do processo. Para consultá-lo, acesse o link < Material Complementar

220 MATERIAL COMPLEMENTAR Apresentação: Métricas e Estimativas de Software - O início de um rally de regularidade. Este artigo descreve as métricas e estimativas de software de uma forma legal, fazendo você imaginar que faz parte de uma equipe de rally, e que você e sua equipe tenham que atravessar um deserto enorme e cheio de obstáculos e que vocês precisem calcular o tempo e distância, por meio do uso de estimativas. Depois é mostrado ao longo do artigo, conceitos sobre as métricas e estimativas de software. Aproveitem. Boa leitura! Para consultá-lo, acesse o link: < metricas-e-estimativas-de-software-o-inicio-de-um-rally-de-regularidade. aspx#ixzz40u61nr9f> Apresentação: Como trabalhar com testes de software? Nesse vídeo serão apresentadas dicas do porque escolher a área de Teste de Software e como essa pode ser uma oportunidade para você aluno(a) entrar no mercado de trabalho em uma das áreas de TI que mais cresce. Para consultá-lo, acesse o link: <

221 CONCLUSÃO 221 Chegamos ao final do nosso estudo sobre Projetos, Implementação e Teste de Software. Espero que você tenha conseguido entender os conceitos relacionados que fazem parte do processo de software e como ele é composto de atividades que são necessárias para o desenvolvimento de um sistema. Estudamos os aspectos relativos ao projeto, mostrando a sua importância e como essa fase é fundamental para o desenvolvimento de um software. Um dos principais objetivos da fase de projeto é que ela define como vai ser a arquitetura do software, tendo como base o que foi levantado na análise de requisitos. Depois de aprendermos sobre a fase de projeto, passamos a analisar a importância da fase de implementação dentro do processo de desenvolvimento de software. Após a implementação do software, passamos a fase de testes, em que é hora de validar e verificar se ele realmente está funcionando. Aprendemos conceitos e vimos que as razões de realizar testes não consistem simplesmente na geração e execução de casos de teste, mas em uma atividade que envolve também questões de planejamento, gerenciamento e análise de resultados. Vimos como compreender os processos de teste de software, mapear e implantar técnicas de teste, melhorar os testes de software, planejar as estratégias, inspecionar a qualidade do produto, do processo e do projeto com base em métricas e indicadores, utilização de ferramentas para auxílio à gestão de teste e gestão de defeitos, avaliar a qualidade de uso do software por meio de avaliações de usabilidade, automatização de testes unitários, funcionais e não funcionais. Esperamos ter alcançado o objetivo inicial, que era mostrar a importância das atividades que fazem parte do processo de desenvolvimento do software que são as fases: projeto, a implementação e o teste de software. Desejamos que a utilização do que foi apresentado aqui possa ser adotado ou te ajudar na empresa em que você trabalha (ou que irá trabalhar) e que te garanta sucesso e realização profissional. Muito obrigada pela atenção em todas as unidades e até uma próxima! Prof.ª Janaína.

222 REFERÊNCIAS AGUIAR, M. Gerenciando Riscos nos Projetos de Software. Developers Magazine. (Online). Disponível em: < Acesso em: 16 mar BASTOS A.; RIOS E.; CRISTALLI R.; MOREIRA T. Base de Conhecimento em Teste de Software. 2 ed. São Paulo: Editora Martins, BLANCO M. Z. Documentação de teste baseado na Norma IEEE 829 estudo de caso: Sistema de apoio a tomada de decisão. T.I.S. v. 1, n. 1, São Carlos; 2012, p COSTA JÚNIOR P. J. da.; MELO W. L. Um processo de inspeção utilizando leitura baseada em perspectiva aplicado à análise de requisitos do unified process. UCB - Universidade Católica de Brasília, FANTINATO M.; CUNHA A. C. R. da; DIAS S. V.; MIZUNO S. A.; CUNHA C. A. Q. AutoTest Um Framework Reutilizável para a Automação de Teste Funcional de Software. Hífen (PUCRS. Impresso). v. 26. Porto Alegre: 2002, p GOMES A.; OLIVEIRA K.; ROCHA A. R. Avaliação de Processos de Software baseada em Medições. In: XV Simpósio Brasileiro de Engenharia de Software, Rio de Janeiro: 2001, p IEEE, The Institute of Electrical and Electronics Engineers. IEEE Std 829: Standard for Software Test Documentation. New York: IEEE Computer Society, September, PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, RIOS, E. Caratê Aplicado ao Teste de Software. 1 ed. Niterói: Imagem Art Studio, RIOS, E. ; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, TRODO, L. D. Uso de Métricas nos Testes de Software. Trabalho de Conclusão de Curso Ciência da Computação da Universidade Federal do Rio Grande do Sul. 128 f. Porto Alegre, 2009.

223 GABARITO Os documentos são: Plano de Teste. Especificação de Projeto de Teste. Projeto de teste. Casos de teste. Procedimentos de teste. Relatórios de Teste. Relatório de Passagem de Itens de Teste. Relatório de Log de Teste. Relatório de Incidentes de Teste. Relatório de Sumário de Teste. 2. A - Somente as questões II, III e V estão corretas. 3. C - Garantir que tanto o modo pelo qual o software está sendo construído quanto o produto em si esteja em conformidade com o especificado. 4. B - A prevenção de defeitos. 5. A Gerência de riscos é muito importante em projetos de testes, pois a equipe de teste sempre estará focada em atacar os riscos maiores, ou seja, defeitos graves, que podem gerar uma maior implicação no processo, pois sabemos que os prazos são apertados e não existe um tempo para gastar na atividade de teste. Assim, no Plano de Teste esses riscos serão os de maior prioridade.