Usuário(a):Mateus Chagas/Testes

Engenharia de software: conceito e objetivos

    Ensina Schach (2008), em sua obra “Engenharia de software: os paradigmas clássico e orientado a objetos”, que “Engenharia de software é uma disciplina cujo objetivo é produzir software isento de falhas, entregue dentro do prazo e orçamentos previstos, e que atenda às necessidades do cliente. Além disso, o software deve ser fácil de ser modificado quando as necessidades dos usuários mudarem”.

    Alternativamente, para uma melhor definição do conceito de Engenharia de software, faz-se necessária a explicação isolada dos termos que o compõem. De forma genérica, pode-se definir software como:

●    instruções que, quando executadas, produzem a função desejada;

●    estruturas de dados que possibilitam que os programas manipulem a informação;

●    documentação relativa ao sistema.

     Engenharia diz respeito ao projeto e manufatura, circunstâncias nas quais os requisitos e as especificações do produto assumem importância crítica na qualidade final do produto. Trata-se da definição clássica de Engenharia. Por ser imaterial, um programa de computador não passa por um processo de manufatura como se conhece no meio industrial de produtos complexos. Fica claro também que, apesar da semelhança com a engenharia tradicional, a produção de programas de computador possui situações particulares.

     Fica claro, então, que o objetivo da Engenharia de Software é a entrega de produto de qualidade, respeitados os prazos e os limites de dispêndio de recursos humanos e financeiros.

Aspectos gerais

   

Abstração

Para resolver um problema, deve-se separar os aspectos que estão ligados a uma realidade particular, visando representá-lo em forma simplificada e geral. 

Formalidade: significa seguir uma abordagem rigorosa e metódica para resolver um problema.

Dividir para conquistar

Resolver um problema complexo dividindo-o em um conjunto de problemas menores e independentes que são mais fáceis de serem compreendidos e resolvidos.

Organização hierárquica

organizar os componentes de uma solução em uma estrutura hierárquica tipo árvore. Assim, a estrutura pode ser compreendida e construída nível por nível, cada novo nível com mais detalhes.

Ocultação

esconder as informações não essenciais. Permitir que o módulo "veja" apenas a informação necessária àquele módulo.

Localização

colocar juntos os itens relacionados logicamente (o usuário não pensa como o analista!).

Integridade conceitual

seguir uma filosofia e arquitetura de projeto coerentes.

Completeza

checar para garantir que nada foi omitido.

Principais categorias de software, classificadas segundo sua aplicação

Software básico

Apoio a outros programas. Forte interação com o hardware. Exemplos: compiladores, device drivers, componentes de sistema operacional.

Software em tempo real

trata-se de um tipo de software que monitora eventos por meio de coleta e análise de dados, tais como temperatura, pressão, vazão, entre outros. Usa-se a expressão “tempo real” por conta da resposta imediata (um segundo ou menos) que o software deve fornecer.

Software comercial

caracteriza-se pela manipulação de grande volume de dados e uso em aplicações comerciais. Exemplos: folha de pagamento, estoque, recursos humanos. Forte interação com banco de dados.

Software científico

Algoritmos de processamento numérico. Usados na astronomia, mecânica e projeto auxiliado por computador.

Software de computador pessoal

Forte interação com o ser humano. Deve ser fácil e amigável. Exemplos: Planilhas, editores de texto, browsers, entre outros.

A crise do software

Crise do Software

    Na década de 1960, alguns atores do processo de desenvolvimento de software cunharam a expressão “Crise do Software“ na intenção de evidenciar o momento adverso que a atividade atravessava. Em seu sentido literal, crise indica estado de incerteza ou declínio e, de fato, esse era o retrato de um setor inapto a atender demanda crescente por produção de software, que entregava programas que não funcionavam corretamente, construídos por meio de processos falhos e que não podiam passar por manutenção facilmente.

     Além disso, a incerteza causada pela imprecisão nas estimativas de custo e prazo afetava a confiança das equipes e principalmente dos seus clientes. A precária – e muitas vezes ignorada – comunicação entre cliente e equipe de desenvolvimento contribuía para que a qualidade do levantamento dos requisitos fosse perigosamente baixa, acarretando consequente incorreções no produto final. O cenário era agravado pela inexistência de métricas que retornassem avaliações seguras – fossem qualitativas ou quantitativas – dos subprodutos gerados nas fases de requisitos, projeto, implementação e testes.

    Não havia, ainda, dados históricos de outros projetos que ajudassem nas estimativas para os projetos atuais e na adequada avaliação da eficácia da aplicação de uma ou outra metodologia no desenvolvimento. Quando, apesar das adversidades, o programa era entregue, o processo de implantação tendia a ser turbulento, já que raramente eram considerados os impactos que o novo sistema causaria na organização. Treinamentos aos usuários após a implantação não era atividade prioritária e o fator humano era ignorado com frequência, gerando insatisfações nos funcionários impactados.

    Por fim, há que se considerar a dificuldade e o alto valor em se empreender manutenção nos produtos em funcionamento, normalmente ocasionados por projetos mal elaborados. Estava claro que algo deveria ser feito. Ações que aprimorassem e dessem segurança ao processo de desenvolvimento deveriam ser tomadas. Sob pena de verem seu negócio naufragar, empreendedores de TI deveriam a todo custo entrar em sintonia com seus clientes, trazendo-os para dentro do processo e dando voz ativa a eles.

Fundamentos dos processos de desenvolvimento de software

  O desenvolvimento de um software pode ser considerado como um processo e não um conjunto de ações isoladas. A previsibilidade e a economia de recursos propiciada por um processo bem estruturado conferem segurança ao desenvolvimento.

    Ao resumir e agrupar os muitos conceitos que a literatura disponibiliza, tem-se que, no âmbito da Engenharia de Software, processo é a sequência de passos que visam a produção e manutenção de um software e que se inter-relacionam com recursos (humanos e materiais), com padrões, com entradas e saídas e com a própria estrutura da organização. Esse conceito pode ser estendido a outros ramos da atividade humana, como a fabricação de um bem de consumo.

Projetos, atividades e estruturas analíticas

    O termo “projeto”, comumente utilizado neste âmbito, precisa ser diferenciado de “processo”. De acordo com o Guia do Conhecimento em Gerenciamento de Projetos (PMBOK, 2013, n. p.), projeto "é um conjunto de atividades temporárias, realizadas em grupo, destinadas a produzir um produto, serviço ou resultado únicos".

    Ensina Wazlawick (2013), que processo é o conjunto de regras que definem como um projeto deve ser executado. Um processo é adotado pela organização para que seja praticado e aperfeiçoado pelos seus colaboradores durante o desenvolvimento de um projeto.

 

  Ainda de acordo com Wazlawick (2013), há vantagens em se definir o desenvolvimento de software como um processo. O autor apresenta três delas:

a) Redução no tempo de treinamento, já que funções e procedimentos bem definidos e documentados facilitam a inclusão de novo membro na equipe de trabalho;

b) Produção de artefatos mais uniformizados, já que a previsibilidade do processo ajuda a equipe a trabalhar de forma mais padronizada;

c) Transformação de experiências em valor, já que a sistemática utilização do procedimento poderá aperfeiçoá-lo com o tempo.

   

  Os processos podem conter divisões em sua estrutura:

  Fases: um conjunto de atividades afins e com objetivos bem definidos são realizados em uma fase do processo. O modelo cascata de desenvolvimento, por exemplo, apresenta fases bem definidas, quais sejam a fase dos requisitos, a fase do projeto, da programação e assim por diante (WAZLAWICK, 2013).

  Atividades ou tarefas: comumente descritas com conceitos semelhantes, uma atividade ou uma tarefa constitui um projeto em pequena escala. Ela visa promover modificações nos artefatos do processo, que podem ser descritos como diagramas, documentos, programas e tudo o que puder ser desenvolvido no processo. As atividades devem possuir entradas, saídas, responsáveis, participantes e recursos bem definidos (WAZLAWICK, 2013)

Ciclo de vida

    O ciclo de vida natural de um software, de acordo com Rezende (2005), abrange as seguintes fases: concepção, construção, implantação, implementações, maturidade, declínio, manutenção e descontinuidade. Estas fases são mais comumente descritas como fase de requisitos, projeto, implementação, teste e manutenção.

Requisitos

    A fase de requisitos de software preocupa-se com a descoberta, análise, especificação e validação das propriedades que devem ser apresentadas para resolver tarefas relacionadas ao software que será desenvolvido. Requisitos são as condições necessárias para que um determinado evento aconteça. Tome como exemplo uma aula presencial de Engenharia de Software. Para que ela aconteça, é necessário professor, alunos, lousa, giz, carteiras. Todos esses itens formam o conjunto de requisitos da aula. No desenvolvimento de software acontece o mesmo. Fazem parte dos requisitos de um software suas funções, suas características, restrições e todas as demais condições para que ele exista e cumpra seu objetivo.

    O projeto de um software fica vulnerável quando o levantamento dos requisitos é executado de forma não apropriada. Os requisitos expressam as necessidades e restrições colocadas num produto de software que contribuem para a solução de algum problema do mundo real.

Técnicas de levantamento de requisitos

O levantamento de requisitos é atividade essencialmente humana, que requer habilidade em trabalhar com especialistas humanos e com o conhecimento tácito, que é trivial para quem conhece a informação, mas não é trivial para quem procura obtê-la.O documento.

Antes da sua aplicação, a entrevista deve ser planejada. Seus objetivos devem ser fixados, seu local e roteiro definidos e os entrevistados criteriosamente escolhidos. A interação entre entrevistado (especialista do conhecimento) e entrevistador (engenheiro de requisitos) deve buscar revelar conceitos, objetos e a organização do domínio do problema, além de buscar soluções ou projeções de soluções que comporão o domínio da solução.

Análise de requisitos

Concluída a fase de levantamento, tem início a análise de requisitos. Aqui os requisitos serão analisados e classificados e, como resultado, serão divididos principalmente em requisitos funcionais e não funcionais. Os primeiros descrevem as funções que o software irá executar. Por exemplo, formatar algum texto ou imprimir um relatório de vendas. Os requisitos funcionais definem a funcionalidade que o software deve prover com o objetivo de capacitar os usuários a realizar

suas tarefas. Eles descrevem o comportamento planejado do sistema, podendo ser expressos como os serviços, tarefas ou as funções que o sistema irá executar.Requisitos não funcionais são aqueles que restringem a solução de um problema. Não se referem às funções específicas do sistema, mas sim a propriedades, tais como tempo de resposta, requisitos de armazenamento, restrições de entrada e saída, memória, entre outras.

Validação dos requisitos

A validação serve para assegurar que o engenheiro compreendeu os requisitos e se estes são compreensíveis, consistentes e completos. No processo de validação a participação do cliente é fundamental. A revisão é feita por profissionais designados para assegurar que não há no documento falta de clareza, sentido dúbio e desvio dos padrões.

Projeto

    Uma vez levantados, analisados, especificados e validados os requisitos, o processo deverá nos levar ao desenho do produto. Se os requisitos nos mostram “o que” o sistema deverá fazer, o projeto deverá refletir “como” ele o fará. Por meio do projeto, os requisitos são refinados de modo a se tornarem aptos a serem transformados em programa. O trabalho principal de um projetista é o de decompor o produto em módulos, que podem ser conceituados como blocos de código que se comunicam com outros blocos por meio de interfaces.

Implementação

Nesta fase, o projeto é transformado em linguagem de programação para que, de fato, o produto passe a ser executável. Para que se possa avaliar se os requisitos foram corretamente traduzidos, a equipe pode optar por construir protótipo do sistema, ou seja, uma versão com funcionalidades apenas de tela para proporcionar entendimento e validação das entradas e saídas do software. Como estratégia de implementação, a equipe poderá dividir o trabalho de forma que cada programador (ou um pequeno grupo deles) fique responsável por um módulo do sistema. Idealmente, a documentação gerada pela fase de projeto deve servir como principal embasamento para a codificação, o que não afasta a necessidade de novas consultas ao cliente e à equipe de projetistas.

Escolha da linguagem de programação

Esta decisão passa pela vontade expressa do cliente, pela experiência da equipe em determinada linguagem e pela necessidade pontual do projeto. Em todos os casos, a escolha deverá ter sido registrada previamente pela equipe e pelo cliente.

Práticas de programação adequadas

O estilo usado no desenvolvimento do software deve obedecer, preferencialmente, a padrões consagrados de codificação.

Integração de software

Integrar o software significa combinar em um todo os módulos construídos durante a implementação.possibilidade de efetivar a integração do produto é codificar e testar cada um dos artefatos (ou módulo) de código separadamente, unir e testar o produto como um todo. Também estão inclusas nessas boas práticas a documentação do código. Ela deve ser objetiva, clara e transmitir dados elementares sobre o programa, que incluem descrição da função principal (ou do módulo), programadores envolvidos, interfaces externas e as últimas alterações feitas no código.

Teste

Testar significa executar um programa com o objetivo de revelar a presença de defeitos. Caso esse objetivo não possa ser cumprido, considera-se o aumento da confiança sobre o programa. O processo de teste deve incluir seu planejamento, projeto de casos de teste, execução do programa com os casos de teste e análise de resultados. As técnicas Funcional e Estrutural são duas das mais utilizadas técnicas de se testar um software. A primeira baseia-se na especificação do software para derivar os requisitos de teste e a segunda baseia-se no conhecimento da estrutura interna (implementação) do programa.

Manutenção

    Os esforços de desenvolvimento de um software resultam na entrega de um produto que satisfaça os requisitos do usuário. Espera-se, contudo, que o software sofra alterações e evolua. Uma vez em operação, defeitos são descobertos, ambientes operacionais mudam, e novos requisitos dos usuários vêm à tona. A manutenção é parte integrante do ciclo de vida do software e deve receber o mesmo grau de atenção que outras fases. A manutenção de software é definida como modificações em um produto de software após a entrega ao cliente a fim de corrigir falhas, melhorar o desempenho ou adaptar o produto a um ambiente diferente daquele em que o sistema foi construído.

Manutenção corretiva

Modificação reativa em um produto de software executada após a entrega a fim de corrigir problemas descobertos.

Manutenção adaptativa

Modificação em um produto de software executada após a entrega do produto a fim de manter o software usável em um ambiente alterado ou em alteração.

Manutenção perfectiva

Modificação em um produto de software realizada após a entrega a fim de melhorar o desempenho.

Manutenção preventiva

Modificação em um software após a entrega a fim de reparar falhas latentes antes que se tornem efetivas

Manutenibilidade

Definida como a facilidade com que um software pode sofrer manutenção, melhoramentos, adaptações ou correções para satisfazer requisitos específicos. Ela deve ser perseguida durante o desenvolvimento do software, de modo a minimizar os custos futuros de manutenção, que são inevitáveis.

Definição dos programadores

Cada um dos responsáveis pela codificação dos módulos projetados deve ser destacado e informado sobre a linguagem de programação a ser utilizada. É boa prática a busca e adequação de funções já codificadas em outros projetos e que eventualmente poderão ser utilizadas neste atual;

Escalonamento das atividades

A divisão de tarefas e seus respectivos responsáveis devem ser definidos em documento público. Nesse ponto, deve-se também definir os responsáveis pela integração e teste dos módulos;

Controle de versão

Durante a codificação, as atualizações feitas no sistema serão informadas a toda equipe de programação, por meio de ferramenta de controle de versão instalada em servidor próprio.

Desenvolvimento de Softwares

Na computação, o desenvolvimento de software é o ato de elaborar e implementar um sistema computacional, isto é, transformar a necessidade de um utilizador ou de um mercado em um produto de software. Também é entendido como a aplicação dos processos da engenharia de software combinados com a pesquisa das necessidades do produto para desenvolver software.

Processo tradicional de desenvolvimento

Modelo cascata

O processo tradicional de desenvolvimento baseia-se na construção linear do sistema, com sequência definida de fases, como mostra a figura ao lado.

Além da linearidade, outras características – com raízes nas formas tradicionais de fabricação de bens de consumo – costumam estar presentes no desenvolvimento tradicional, cujo foco contempla o determinismo, especialização e foco na execução .

Para explicar esses conceitos cabe a analogia com o processo de montagem de veículos. Vejamos:

• Materiais alimentam um processo de fabricação, ao final, temos um automóvel terminado. As alterações pelas quais os materiais passam são DETERMINÍSTICAS e devem sempre gerar um resultado conhecido. Acarreta segurança, redução de tempo e custo.

• A indústria tradicional divide o processo de montagem em inúmeras atividades ESPECIALIZADAS, desenvolvidas por trabalhadores igualmente especializados.

• FOCO NA EXECUÇÃO: a fórmula é simples: determinismo + especialização = não há o que pensar. Basta executar.

Não é difícil de inferir que o modo tradicional tenha sido concebido com base nessas ideias de desenvolvimento industrial em linha. De acordo com elas, a mera obediência a eventos consecutivos (de requisitos até implantação), a especialização (funções de analista, projetista, programador, testador) e o foco na execução seriam capazes de criar um produto de qualidade, no tempo estipulado e sem ultrapassar o orçamento.

Havia, e ainda há, a presunção de que a sequência de etapas do projeto será transformada corretamente em software.

Agora, considere a possibilidade de dividirmos nossos recursos humanos em dois tipos: trabalhadores manuais e trabalhadores do conhecimento. O primeiro tipo desempenha trabalhos repetitivos, predeterminados e dependem principalmente das suas habilidades manuais e físicas para a execução de suas tarefas. Os trabalhadores do conhecimento, por sua vez, cumprem a missão com base em seu raciocínio, devem ter oportunidades de praticar sucessivas revisões em sua obra e não seguem processo linear em seus processos de criação.

Em qual dos dois tipos você classificaria um desenvolvedor de software? Acertou se pensou no trabalhador do conhecimento. No entanto, pela metodologia tradicional de desenvolvimento, são tratados como trabalhadores manuais. O erro é tratado como “pecado” e o medo de errar torna os desenvolvedores defensivos. Há pouca possibilidade de reverem sua obra depois de pronta e seu trabalho se baseia num processo linear.

Processo ágil de desenvolvimento  

Tradicional x ágil

Em sua essência, os métodos ágeis têm menos ênfase nas definições de atividades e mais ênfase nos fatores humanos do desenvolvimento. São claramente mais adequados à natureza do trabalho de profissionais de TI, já que se baseiam na necessidade de sucessivas revisões na obra. Atividades intelectuais não são executadas de forma linear e não são determinísticas.

         Durante a construção de um software, há que se considerar uma infinidade de detalhes que nem sempre são lembrados logo na primeira oportunidade. Da mesma forma, ao tratar pela primeira vez das funcionalidades que deseja para o produto, o cliente ainda não as conhece por completo e não consegue ter visão global do que necessita.

         “O aprendizado do qual estamos tratando decorre do feedback que o software fornece ao cliente quando este o manipula. No desenvolvimento ágil, o conceito de feedback está presente ao longo de todo o desenvolvimento do software e exerce um papel fundamental”.

Extreme Programming (XP)

        

O XP é uma metodologia adequada para projetos que possuem requisitos que se alteram constantemente, para equipes pequenas e para o desenvolvimento de programas orientados a objetos. É indicado também para ocasiões em que se deseja partes executáveis do programa logo no início do desenvolvimento e que ganhem novas funcionalidades assim que o projeto avança.

Equipe de trabalho

         Embora a especialização não seja estimulada nas metodologias ágeis, há necessidade de se estabelecer funções entre os participantes do projeto. Uma típica equipe de trabalho no XP tem a seguinte configuração:

Gerente do projeto: responsável pelos assuntos administrativos, incluindo relacionamento com o cliente. Opera nos bastidores do projeto.

Coach: responsável técnico pelo projeto. Deve ser tecnicamente bem preparado e experiente. Compete a ele assegurar o bom andamento do processo.

Analista de teste: ajuda o cliente a escrever os testes de aceitação e fornece feedback para a equipe interna de modo que as correções no sistema possam ser feitas.

Redator técnico: ajuda a equipe de desenvolvimento a documentar o sistema, permitindo que os desenvolvedores foquem a construção do programa propriamente dito.

Desenvolvedor: realiza análise, projeto e codificação do sistema. No XP, não há divisão entre estas especialidades.

Valores do XP

O Extreme Programming apoia-se em quatro pilares para atingir seus objetivos:

Feedback: quando o cliente aprende com o sistema que utiliza e reavalia suas necessidades, ele gera feedback para sua equipe de desenvolvimento.

Comunicação: entre equipe e cliente permite que os detalhes sejam tratados com atenção. (manter o cliente por perto)

Simplicidade: implementar o que é suficiente para atender à necessidade do cliente.

Coragem: Melhorar o que já está funcionando.

a partir desses pilares são geradas treze práticas:

Jogo do planejamento, programação em pares, pequenas versões, propriedade coletiva, metáforas, integração contínua, projeto simples, semana de 40 horas, testes, cliente presente, refatoração, padronização de código e reunião diária. As práticas reforçam os valores.

Abaixo veremos melhor o que são cada uma das práticas do XP.

Versões Pequena(Releases)

Release é algo que é implantado no cliente, ou seja, está pronto para ser utilizado. As Releases normalmente são pequenas e frequentes (a cada 2-3 meses) sendo que funcionalidades prioritárias são desenvolvidas mais cedo para serem entregues mais rapidamente ao cliente, pois prioriza-se o que ele mais precisa no momento. Obviamente que algumas organizações não querem essas entregas frequentes e pequenas, pois precisam dar treinamentos antes do sistema ser entregue e isso leva um certo tempo ou então não faz parte da cultura organizacional. Nesse caso, se a organização não seguir isso não está seguindo realmente o que mandam as metodologias ágeis como o XP.

Uma Release também pode ser guiada por funcionalidade ou prazo, nesse caso deveremos analisar o que é mais importante, liberar até um certo dia, ou liberar com determinadas funcionalidades. Por exemplo, Google Docs quando lançado tinha poucas funcionalidades, mas ao longo do tempo agregou cada vez mais funcionalidades. Neste caso preferiu-se liberar poucas funcionalidades para os usuários que quisessem logo trabalhar com esse software e que aproveitassem esse serviço que não era preciso pagar e era integrado ao e-mail.

Releases são construídas ao longo de iterações. Uma iteração sempre alcança algum objetivo perceptível ao cliente, ou seja, não adianta usarmos uma iteração para projetarmos ou melhorarmos a arquitetura do nosso software se ele não vai agregar absolutamente nenhum valor ao cliente. Nada é feito que não seja imediatamente útil e necessário para não afetar os prazos de desenvolvimento. As iterações são divididas em tarefas que são a menor quantidade de trabalho que pode ser feita até que todos os testes voltem a funcionar. As Tarefas não levam mais que um dia, pois elas devem ser integradas imediatamente assim que o programador finaliza essa tarefa, seja ao final do dia ou antes disso, para que assim os testes sejam executados e verifique-se caso algo errado foi feito. Portanto, uma vez concluídas, tarefas são integradas imediatamente.

Jogo do Planejamento

Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas. Portanto no XP planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente ele define o escopo para a próxima Release. Dessa forma, define-se as features, prioridades e o escopo da release.

Os desenvolvedores irão definir estimativas, consequências técnicas de adotar determinadas plataformas ou componentes (por exemplo, os programadores podem dizer que determinado componente dá muito problema e seria mais adequado utilizar um componente pago que economizará muito tempo), e por fim os desenvolvedores também ajudam no detalhamento de prazos para as atividades. Por fim, mantemos o plano atualizado sempre que houver um novo “toque de realidade” no projeto como algum imprevisto ou algo desejável que não contava-se que iria acontecer, ou qualquer outra coisa que possa afetar o plano atual.

Testes no Extreme progamming

A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação. Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõe também confiança ao sistema e dão coragem para altera-lo, pois podemos saber imediatamente se algo introduziu um bug no sistema.

Entre os tipos de testes temos o Teste Unitário que automatiza o teste da funcionalidade e tipicamente testa uma classe, ou pequeno grupo de classes. Nesse caso usamos frameworks de testes como Junit para Java e Nunit para DotNet. Se um bug é descoberto, acrescenta-se imediatamente um caso de teste para ele. Assim garantimos que ele não se repetirá. Outro tipo de teste é o Teste de Aceitação (Teste funcional) que é especificado pelo cliente para testar que o sistema funciona conforme especificado por ele. Quando todos os seus testes de aceitação passam, a história é considerada completa.

Teste automatizado é a prática que sustenta e viabiliza muitas outras práticas como Integração contínua, Projeto Simples, Versão Pequena, Refatoração, e Propriedade Coletiva.

Programação em pares

Trata-se de duas pessoas trabalhando com uma máquina onde um codifica, e o outro crítica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.

Evidente que essa prática requer ambiente de trabalho apropriado como, por exemplo, um ambiente que provê mobilidade, e pessoas que devem concordar com o barulho que será causado.

Projeto Simples

Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.

O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.

Refatoração

A refatoração significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos.

A refatoração provê um aumento contínuo de qualidade do código.

Propriedade Coletiva

Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.

Integração Contínua

Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.

Cliente presente

Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações.

Semana de 40 horas

O XP preconiza que não se pode trabalhar horas extras por mais de uma semana, pois trabalho extra é sintoma de que algo está errado. Devemos manter um ritmo sustentável.

Padrões de Codificação

Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no início dos projetos.

Metáfora

É uma linguagem comum que todos devem possuir. Por exemplo, ao invés de descrevermos como uma certa arquitetura funciona apenas comunicamos o seu nome e todos entendem o que um programador quis dizer.

Reunião diária

É uma prática vinda do SCRUM em que todos fazem uma rápida reunião de pé para discutir o que foi feito no dia anterior, o que será feito no dia atual e se existe algum impedimento.

Neste artigo, vimos o que é o XP, quais são as suas práticas e o que são cada uma delas. Também vimos o que o XP preconiza como sendo realmente importante e fizemos algumas comparações com o SCRUM que também é bastante utilizado hoje, porém mais como um framework gerencial, diferente do XP que é mais técnico.

Scrum

Scrum

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo:

Daily Scrum

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizados no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

·        O que você fez ontem?

·        O que você fará hoje?

·        Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.

Product Backlog

É uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

Product Owner

É a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

Release Burndown

Gráfico de trabalho

Em um projeto Scrum, a equipe monitora seu progresso em relação a um plano atualizando um Release Burndown Chart ao final de cada Sprint (iteração). O eixo horizontal de um Release Burndown Chart mostra os Sprints; o eixo vertical mostra a quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe: story points, dias ideais, team days e assim por diante.

Scrum Master

Procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.

Scrum Team

É a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

Sprint Backlog

É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

Sprint Planning Meeting

É uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.

Sprint Retrospective

Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

Sprint Review Meeting

Feito ao final de cada Sprint, é uma reunião onde o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.

Feature-Driven Development (FDD)

Entre as metodologias ágeis que existiam antes do manifesto ágil, o FDD é uma delas. Concebido originalmente por Jeff de Luca, o FDD surgiu em Singapura, entre os anos de 1997 e 1999 com base no método Coad (Criado por Peter Coad – 1980/1990) e nos processos interativos e lean já utilizados por Jeff de Luca.

O FDD ou Feature-Driven Development (Desenvolvimento Dirigido por Funcionalidade) é um método ágil que enfatiza o uso de orientação a objetos e possui apenas duas grandes fases:

a) Concepção e planejamento

O modelo sugere que se conceba e planeje o produto por uma ou duas semanas antes de começar a construir.

b) Construção

Desenvolvimento por iterações do produto em ciclos de uma a duas semanas.

A primeira fase inclui três subfases:

DMA (Desenvolver Modelo Abrangente)

Etapa na qual especialistas estabelecidos em grupos desenvolvem um modelo de negócio amplo, representado por diagramas.

CLF (Construir Lista de Funcionalidades)

Atividade inicial que abrange todo o projeto, com o objetivo de identificar todas as funcionalidades que satisfaçam os requisitos levantados.

PPF (Planejar por Funcionalidade)

Nesta etapa é definida a ordem em que as funcionalidades serão implementadas, com base na disponibilidade da equipe de desenvolvimento, na complexidade e nas dependências entre as funcionalidades.

A fase de construção inclui outras duas subfases:

DPF (Detalhar por Funcionalidade):

Momento em que o design de implementação da funcionalidade é criado, por meio de diagramas de sequência ou comunicação.

CPF (Construir por Funcionalidade)

Fase em que se produz efetivamente código para as funcionalidades escolhidas (WAZLAWICK, 2013).

Busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do sistema. É prático para o trabalho com projetos iniciais ou projetos com codificações existentes. Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia. O FDD atua muito bem em conjunto com o Scrum, pois o Scrum atua no foco do gerenciamento do projeto e o FDD atua no processo de desenvolvimento.

Assim como acontece na metodologia XP, o FDD faz uso de teste de software. Desta forma é possível utilizar TDD, aliás, é indicada a utilização deste para manter a qualidade do software.

O FDD, assim como a teoria de sistemas afirma, entende que a soma das partes é maior do que o todo. Desta forma, apesar de criar um modelo abrangente baseado no todo que será desenvolvido, esta fase inicia-se com o detalhamento do domínio do negócio com divisão de áreas que serão modeladas. O modelo só está pronto quando todos da equipe estiverem de acordo, o planejamento é feito com base na lista de funcionalidades. Se fossemos trabalhar com FDD em conjunto com o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de usuários a serem desenvolvidas.

Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este planejamento é incremental. Isto em conjunto com o Scrum, deve ser analisado como etapa de desenvolvimento do incremento, então este planejamento é feito com base no que será desenvolvido naquele incremento.

Vamos novamente ao Scrum, separando o que será feito na Sprint. Colocamos no backlog da Sprint. O que está no backlog da sprint são funcionalidades que serão desenvolvidas durante a sprint (que pode ser de duas a quatro semanas), estas tarefas são então planejadas com maior rigor, neste ponto, temos então o planejamento incremental, ou seja, planejamos apenas o que vamos desenvolver. Nesta etapa os envolvidos no processo resumem-se apenas à equipe, ou seja, os desenvolvedores, analistas, testadores, etc., que vão atuar no processo. Eles devem selecionar os itens com base no tempo que eles possuem e nas qualificações atuais da equipe.

Após o planejamento, é feito o detalhamento, nesta fase é de extrema importância que o desenho esteja de acordo com o que o cliente deseja, então é mantido contato constante com o cliente, como em todas as metodologias ágeis.

Esta documentação é a base para o desenvolvimento, não deve-se perder tempo com documentação que não será utilizada, mas é necessário documentar.

Posteriormente inicia-se a fase de desenvolvimento, esta fase é a etapa de desenvolvimento e teste real.

O desenvolvimento também é incremental, e indica-se a utilização de testes do início ao fim do processo, além da utilização de integração continua.

Um ponto que diverge do XP é que no FDD é incentivado o desenvolvedor como único responsável pelo módulo que este desenvolve, já no XP, o código é comunitário.

Integração contínua

A utilização da integração continua permite que a equipe esteja em contato constante com o cliente, tornando o processo ágil e com entregas constantes.

Como cada fase apresentada acima é específica e curta, e as fases se completam, são necessários relatórios para manter o controle, para analisar a quantidade de recursos que estão sendo desenvolvidos, semelhante ao burndonw e o burnup do Scrum.

Segundo a metodologia, o percentual de tempo gasto em cada etapa é:

·        Levantamento do domínio da aplicação = 1%;

·        Projeto = 40%;

·        Inspeção do projeto = 3%;

·        Desenvolvimento = 45%;

·        Inspeção do código = 10%;

·        Integração = 1%.

Além disso, o FDD possui as chamadas melhores práticas que indicam boas práticas ao desenvolver com o FDD, são elas:

·        Modelagem Orientada a Objetos do Domínio;

·        Desenvolvimento por funcionalidade;

·        Classe proprietária, ou seja, a unidade é feita individualmente, evitando-se assim conflitos na equipe;

·        Equipes de recursos: são equipes pequenas, destinadas a desenvolver recursos necessários ao projeto, de forma secundária;

·        Inspeção é realizada constantemente para garantir a boa qualidade do código e do projeto;

·        Gerenciamento de configuração;

·        Integração contínua para demonstrar constantemente as funcionalidades ao cliente e;

·        Visibilidade de progressos e resultados.

É possível notar como o FDD pode atuar em conjunto com outras metodologias, principalmente com o Scrum, encaixando-se perfeitamente como metodologia de engenharia ágil de software com projeto ágil de software.

Além disso, é possível notar que as boas práticas do FDD podem entrar em embate com o XP, na forma em que o código é tratado por cada uma das metodologias. Lembrando que as metodologias possuem características que podem ser adaptadas à necessidade de cada empresa, se notarmos o foco principal em todas as metodologias, temos o desenvolvimento por incremento, a comunicação constante com o cliente e a integração continua.

Conceito de qualidade

O que é qualidade de software e por que ela é tão importante? Uma boa maneira de começarmos esta discussão é afastando a ideia de que qualidade signifique perfeição. É comum entendermos que sempre será possível encontrar algo a ser melhorado em algo que se reconhece como de boa qualidade.

Também não se pode caracterizar a qualidade como algo absoluto, definitivo e que tenha meios de ser medida universalmente, em parâmetros aceitáveis para todas as pessoas. O que parece ser de boa qualidade para mim pode não parecer para você. E vice-versa.

Por ser considerada um conceito de muitas dimensões, talvez uma boa maneira de começarmos a entender a qualidade, é que esta se realiza por meio de um conjunto de características e atributos de um certo produto. Como qualidade não significa perfeição, é natural que tenhamos que estabelecer um nível aceitável de qualidade para um produto e meios para verificar se esse nível foi alcançado.

Embora você possa não encontrar uma definição universal e definitiva para a qualidade aplicada a um software, fatores como a corretude, a eficiência e a usabilidade são algumas medidas amplamente aceitas como indicadores da qualidade do produto. Esses fatores serão estudados com mais propriedade e detalhes na próxima seção, mas vale uma olhada agora:

• Corretude

Capacidade do software em executar suas funcionalidades conforme elas foram definidas. Se pudéssemos resumir esse fator em uma pergunta, ela seria próxima de: “o software faz aquilo que eu quero?”

• Eficiência

Relaciona-se ao grau de adequação do programa aos recursos de hardware, tais como processador e memória. Eficiência é uma palavra muito comumente usada, embora muitas vezes de forma incorreta. Para ele, eficiência é a medida de quantos recursos são usados para que uma tarefa seja completada. Atualmente, com o hardware custando tão pouco, não se presta muita atenção no fator eficiência como no passado, exceto em processos que incluem quantidade muito grande de dados, como o Big Data, por exemplo (SHAFFER, 2013).

• Usabilidade

Este fator está relacionado com a facilidade de uso do produto. Em outras palavras, trata-se da medida da capacidade do público-alvo em obter valor do software por meio da sua interface.

• Portabilidade

É possível usá-lo em outra plataforma? Trata-se da medida de facilidade em mudar o software de uma plataforma (Windows, por exemplo) para outra (Mac, por exemplo).

• Interoperabilidade

Trata-se da “capacidade de diversos sistemas e organizações trabalharem em conjunto (interoperar) de modo a garantir que pessoas, organizações e sistemas computacionais interajam para trocar informações de maneira eficaz e eficiente”.

Gestão da qualidade do software

Com a finalidade de conseguirmos um melhor aproveitamento neste tema, ficaria melhor se definirmos a gestão da qualidade como um sistema. Idealmente esse sistema de gestão da qualidade já deve estar incorporado na organização e, como se espera de qualquer sistema, ele deve incluir processos, pessoas e ferramentas dirigidas à obtenção da qualidade nas entregas.

Quando tomamos um sistema de gerenciamento financeiro ou um sistema de gerenciamento de pessoas em uma organização como exemplos, por si sós eles não deveriam demandar uma nova equipe de gerenciamento ou novos recursos. Ao contrário disso, espera-se que tais sistemas sejam partes integrantes da organização, alinhadas com necessidades particulares de finanças ou de gestão de pessoas.

De acordo com SWEBOK (2004), publicação criada pela IEEE (Instituto de Engenheiros Eletricistas e Eletrônicos, do inglês Institute of Electrical and Electronics Engineers), o gerenciamento da qualidade de software é tratado como um processo, que se aplica a todas as perspectivas de processos de software, produtos e recursos. Ele define os requisitos e os responsáveis pelos processos, suas medições e saídas, além dos canais de feedback. O planejamento da qualidade do software envolve:

• A definição do produto em termos de suas características de qualidade;

• O planejamento do processo para se obter o produto desejado.

Outro processo que visa conferir qualidade ao produto é o que chamamos de Verificação e Validação. Para facilitar as referências ao tema, os termos verificação e validação são tratados como apenas um. De acordo com SWEBOK (2004), trata-se de um processo bem estruturado para avaliar os produtos de software em todo o seu ciclo de vida, do planejamento até sua efetiva entrega. Em resumo, retrata o esforço da equipe para garantir que a qualidade está embutida no software e que ele reflete o desejo do usuário. A V&V, como também é conhecido esse processo, está interessada diretamente na qualidade do produto.

O grupo revisões e auditorias, nosso último processo de qualidade abordado aqui e também tratado como um único item, inclui dois principais procedimentos:

• Revisões técnicas

O objetivo de uma revisão (ou análise) técnica é o de avaliar um produto de software para determinar a sua adequação para a sua utilização pretendida. O objetivo é o de identificar discrepâncias a partir das especificações e dos padrões aprovados. Os resultados devem fornecer evidências que confirmem (ou não) que o produto atende às especificações;

• Inspeções

O propósito de uma inspeção é detectar e identificar anomalias no software. Esta prática se diferencia das revisões em dois aspectos: alguém que exerça cargo de gestão sobre qualquer membro da equipe de inspeção não deverá participar desse processo, e uma inspeção deve ser conduzida por um facilitador imparcial, treinado em técnicas de inspeção.

As inspeções incluem também um líder, um responsável pelos registros da seção e um número reduzido de inspetores, comumente de 2 a 5 pessoas.

Garantia da Qualidade de Software (SQA)

Uma definição aceitável para a SQA (Software Quality Assurance) é expressa como "padrão planejado e sistemático de ações que são exigidas para garantir a qualidade do software” (PRESSMAN, 1995, p. 733). Em outras palavras, são as providências tomadas pela equipe para assegurar a qualidade do seu produto, de maneira vinculada ao processo que o cria.

Como a abrangência temporal de tais providências se estende das fases iniciais do processo até a finalização do software, é esperado que a responsabilidade das equipes do projeto e demais envolvidos também seja extensa. Por exemplo, os engenheiros de software, o profissional que gerencia o projeto, o grupo de SQA e o próprio cliente, todos eles são responsáveis pela garantia da qualidade.

Atividades SQA

Assegurar a qualidade de um software envolve algumas tarefas, três das quais são descritas na sequência (PRESSMAN, 1995):

• Aplicação de métodos técnicos

A SQA começa a ser aplicada desde a especificação e o desenho do sistema. Uma especificação malfeita – ou uma história mal escrita pelo cliente ou mal interpretada pela equipe – certamente irão comprometer a qualidade do produto final. Assim que uma especificação, protótipo ou release de um sistema tiverem sido criados, será apropriado avaliá-los quanto à qualidade.

• Realização de revisões técnicas formais

Esta é a atividade central no contexto da avaliação da qualidade de um produto. Uma revisão técnica formal é um encontro no qual uma equipe (de 3 a 5 pessoas, normalmente) destacada para o trabalho, concentra-se na busca por problemas de qualidade no produto ou, mais comumente, numa parte específica dele. Elas são aplicadas em momentos variados do processo e são também usualmente referenciadas como walkthrough (passo a passo). Se você é fã de games, então já ouviu ou leu essa expressão.

• Atividades de teste de software

Por melhor que seja sua técnica, por maior que seja sua capacidade de fazer bons programas e por mais que você siga uma metodologia, submeter seu programa a um processo de teste nunca sairá de moda. O motivo é simples: errar é humano.

Fatores que influenciam na qualidade do software

Já que temos tratado de processos formais de qualidade na construção do nosso conhecimento sobre o tema, nada mais apropriado do que a busca por um modelo de qualidade consagrado para definirmos as características desejáveis em um programa. O modelo de qualidade ISO/IEC 25010:2011 estabelece um conjunto de oito características internas e externas de um software, divididas em outras tantas subcaracterísticas.

1. Adequação funcional

Antes conhecida como funcionalidade apenas; ela se refere à existência de um conjunto de funções que satisfazem às necessidades previamente estabelecidas, quando o produto é usado sob condições específicas. Duas de suas subcaracterísticas são a Completude Funcional (o software apresenta todas as funções necessárias ao usuário?) e a Corretude Funcional ou Acurácia (o software gera dados e consultas corretos segundo o que foi definido?) (WAZLAWICK, 2013).

2. Confiabilidade

Se um software é capaz de manter comportamento consistente com o que se espera dele ao longo do tempo, então ele pode ser considerado confiável. A confiabilidade tem a ver com o funcionamento do programa em situações incomuns. Ela pode ser medida diretamente e estimada usando-se dados históricos e de desenvolvimento, ou seja, um computador poderá ser considerado livre de falhas quando não tiver alguma incidência em um determinado ambiente e num determinado período (MUSA et al., 1987 apud PRESSMAN, 1995). Desta definição, o que ainda não temos claro é o que significa falha. Quando tratarmos de teste de software com mais detalhes, esse conceito será abordado.

Vale aqui também destacar duas de suas subcaracterísticas: a Disponibilidade (avalia o quanto o software está operacional e livre para uso quando necessário) e a Tolerância a Falhas (avalia a forma como o software reage em situação anormal).

3. Usabilidade

De forma simplificada, podemos entender essa característica como a facilidade em se usar um programa, do ponto de vista do usuário. Em linhas gerais, o programa é fácil de usar se ele é (REISS, 2012):

• Funcional – ele realmente funciona?

• Responsivo – ele me fornece respostas adequadas?

• Ergonômico – eu posso facilmente ver, clicar, arrastar e girar as coisas?

• Conveniente – tudo está bem onde eu preciso que esteja?

• “À prova de tolos” – o projetista me ajuda a não cometer erros ou quebrar coisas?

A usabilidade também apresenta subcaracterísticas, incluindo (WAZLAWICK, 2005):

• Operabilidade – o produto é fácil de usar e controlar?

• Proteção contra erro do usuário – o programa consegue evitar que o usuário cometa erros?

• Acessibilidade – avalia o grau em que o produto foi projetado para atender usuários com necessidades especiais.

4. Segurança

Se um programa consegue proteger os dados e as funções de acessos não autorizados, então ele tem um bom nível de segurança. Algumas de suas subcaracterísticas devem ser destacadas. Entre elas:

• Confidencialidade – mede o grau em que os dados e funções ficam disponíveis para quem, de fato, tem autorização para acessá-los;

• Rastreabilidade de uso – mede o grau em que as ações realizadas por uma pessoa ou por um sistema podem ser rastreadas de forma a ser efetivamente comprovado que, de fato, foi essa pessoa ou sistema que realizou tais ações.

5. Capacidade de manutenção

Trata de uma característica que atrai interesse direto apenas da equipe de desenvolvimento, já que não afeta a percepção do usuário em relação ao sistema. Como você certamente já inferiu, trata-se da capacidade do sistema em passar por manutenção. Assim como todas as outras características apresentadas, essa também conta com divisões. Vamos a elas:

• Modularidade – o sistema é bem dividido em módulos? Mudanças em um dos módulos deve causar mínimo impacto nos outros.

• Reusabilidade – há partes do sistema que podem ser usadas na construção de outro sistema?

• Analisabilidade – o sistema permite que se faça depuração com facilidade?

No âmbito das características de qualidade do software em uso, vale destacar (WAZLAWICK, 2013):

6. Efetividade

Capacidade que o produto tem de proporcionar ao cliente o atingimento de seus objetivos de negócio.

7. Satisfação

Capacidade que o produto tem de satisfazer o cliente em ambiente de uso. Pode ser dividida em Utilidade, Prazer, Conforto e Confiança.

8. Uso sem riscos

O uso do software não pode implicar riscos para pessoas, negócios ou ambiente. Divide-se em mitigação do risco econômico, mitigação do risco ambiental e mitigação do risco à saúde e segurança.

ISO 9001 – Sistema de Gestão da Qualidade

A ISO 9001 é um dos mais conhecidos e utilizados padrões mundiais de qualidade. Atualizado no ano de 2015, ele especifica requisitos para um sistema de gestão de qualidade, com foco naquilo que o cliente exige para que o produto ou serviço seja entregue de acordo com suas necessidades (SEEAR, 2015).

Esse padrão é implantado quando uma organização precisa demonstrar sua capacidade de fornecer produtos e serviços que atendam às exigências de regulamento e estatuto da organização e que pretende aumentar a satisfação do cliente por meio da aplicação eficaz do sistema

A ISO 9001:2015 adota uma abordagem de processo para desenvolvimento, implementação e melhoria da eficácia de um sistema de gestão da qualidade, com o objetivo de aumentar a satisfação do cliente por meio do atendimento aos seus requisitos.  Para isso, ela se baseia em 7 princípios de gerenciamento de qualidade: Foco no Cliente, Liderança, Engajamento de Pessoas, Abordagem de Processo, Melhoria, Tomada de Decisão Baseada em Evidências, Gestão de Relacionamento.

Esses termos, se considerados de forma isolada, podem não transmitir por completo o “espírito” do padrão.

ISO/IEC 90003 – Orientações para Qualidade de Processo de Software

A ISO/IEC 90003:2014 fornece orientações para aplicação da ISO 9001 nos processos de aquisição, fornecimento, desenvolvimento, operação e manutenção de um programa de computador e serviços de suporte relacionados.

A aplicação desse padrão é apropriada para produtos de software que são parte de um contrato comercial com uma outra organização, para produtos disponíveis para um segmento de mercado, produtos usados para dar suporte a um processo em uma empresa, produtos incorporados em um hardware específico ou produtos relacionados a um serviço de software.

O padrão ISO/IEC 90003:2014 não está atrelado à tecnologia, modelos de ciclo de vida, processos de desenvolvimento, sequência de atividades e estrutura organizacional.

CMMI

O CMMI, sigla de Capability Maturity Model Integration é o sucessor do CMM, mantido pela SEI (Software Engineering Institute) de 1987 até 1997.  Trata-se de um modelo que visa aprimorar a capacidade da maturidade do processo de software.  Para melhor entendê-lo, voltemos à nossa primeira unidade.

A versão atual do CMMI, a 1.3, possui três divisões:

• CMMI-ACQ

Modelo que foca em atividades de gerenciamento da aquisição de produtos e serviços de software.

• CMMI-DEV

Criado para o desenvolvimento de produtos e serviços de qualidade.

• CMMI-SVC

Modelo que tem o objetivo de fornecer serviços de qualidade para clientes e usuários finais.

O CMMI é um caminho de melhoramento evolucionário, trilhado em 5 níveis de maturidade e 4 níveis de capacidade, feito para que organizações de software possam sair de um processo de software imaturo para um processo maduro e disciplinado.

Níveis de Capacidade do Processo

Um nível de capacidade do processo é alcançado quando todos os objetivos genéricos para aquele nível são satisfeitos.

Nível 0 – Incompleto

Um processo incompleto é um processo que não está sendo colocado em prática ou que é usado apenas parcialmente.  Um ou mais objetivos específicos da área de processo não estão sendo satisfeitos e inexistem metas genéricas para serem alcançadas, daí não haver razão para tornar oficial um processo parcialmente executado.

Nível 1 – Realizado

Este nível é caracterizado como um processo que está sendo seguido, é capaz de gerar produtos, é viável no atingimento de metas específicas e já pode ser considerado como um fator de melhorias na organização.  No entanto, tais melhorias podem ser perdidas ao longo do tempo, já que o processo ainda não foi institucionalizado.

Nível 2 – Gerenciado

Um processo no nível 2 já é planejado e executado de acordo com a política definida, emprega pessoas qualificadas que tenham recursos adequados para produzir saídas controladas; envolve as partes interessadas (os stakeholders), é monitorado, controlado e avaliado. A disciplina do processo refletido por este nível ajuda a garantir que as práticas existentes são mantidas durante períodos de estresse.

Nível 3 – Definido

Trata-se de um processo gerenciado que é feito sob medida a partir do conjunto de processos padrão e diretrizes da organização.  Este nível também se caracteriza por manter registros de descrição do processo. No nível de capacidade  2 (Gerenciado), as normas, as descrições de processos e os procedimentos podem ser bastante diferentes em cada instância específica do processo. No nível de capacidade 3, as normas, descrições de processos e procedimentos para um projeto são feitos sob medida a partir do conjunto de processos padrão da organização para atender um determinado projeto ou unidade organizacional e, portanto, são mais consistentes.

Outra distinção importante é que, no nível de capacidade 3, processos são geralmente descritos de forma mais rigorosa do que no nível 2. Um processo definido estabelece claramente a finalidade, os insumos, os critérios de entrada, as atividades, os papéis de cada membro, medidas, saídas e critérios de saída. Enfim, no nível 3, os processos são geridos de forma mais proativa e disciplinada.

Níveis de Maturidade

Para dar suporte à representação por estágios, o CMMI contempla níveis de maturidade em sua concepção.  Um nível de maturidade é composto por práticas específicas e genéricas relacionadas para um conjunto predefinido de áreas de processos que melhoram o desempenho global da organização. O nível de maturidade fornece uma maneira de caracterizar o seu desempenho da organização.  Você sabe: quanto maior o nível de maturidade, mais organizada em seus processos a organização é.  Em consequência, a tendência de gerar produtos de qualidade avançada é maior.  Os níveis são o seguinte:

Nível 1 – Inicial

O processo de software é caracterizado como caótico. Poucos processos são definidos e o sucesso depende de esforços individuais. A organização não provê um ambiente estável para o desenvolvimento e manutenção do software e cronogramas e orçamentos são frequentemente abandonados por não serem baseados em estimativas próximas da realidade.

Nível 2 e Nível 3 Gerenciado e Definido

As características dos níveis de maturidade 2 e 3 são semelhantes às dos níveis de capacidade 2 e 3.

Nível 4 – Quantitativamente gerenciado

Nesse nível, a organização estabelece metas de qualidade e usa essas medidas na gestão de seus projetos.  A qualidade de processo e de produto é entendida por meios estatísticos e gerenciada de forma que seja quantitativamente previsível.

Nível 5 – Em otimização

Nesse nível, a organização melhora continuamente seus processos, com base nas medições quantitativas já obtidas (WAZLAWICK, 2013).

MPS.BR

O MPS.BR ou MR-MPS (Modelo de Referência para Melhoria do Processo de Software) é um modelo de avaliação voltado às empresas brasileiras, criado no ano de 2003 pela SOFTEX, em parceria com o Governo Federal e pesquisadores.  Sua concepção leva em consideração normas e modelos internacionalmente reconhecidos, além das indispensáveis boas práticas da Engenharia de Software e a realidade de negócio dos desenvolvedores nacionais. Sua criação se justifica, inclusive, pelos altos custos de certificação nas normas internacionais.

O guia de implementação da norma se divide em 11 partes, sendo as 7 primeiras relacionadas aos 7 níveis de maturidade implantados no MPS.BR. As demais são guias de implementação nas empresas.

Esse modelo também é formado por níveis: Em Otimização, Gerenciado Quantitativamente, Definido, Largamente Definido, Parcialmente Definido, Gerenciado, Parcialmente Gerenciado.

Métrica e Medição

A medição é o processo pelo qual os números são atribuídos aos atributos de entidades do mundo real. Na medição, atribui-se um valor numérico a uma grandeza física.  Por exemplo, quando medimos a distância entre dois pontos e obtemos 5 metros, estamos atribuindo o valor 5 à grandeza física chamada distância.  Usaremos o termo medição tanto para descrever um processo como um valor de atributo. A medição é tipicamente uma quantificação direta, que envolve um único valor, ao passo que métrica é uma quantificação indireta, que envolve o cálculo e o uso de mais de uma medida. Vamos a um exemplo de métrica: considerando a medida de número de linhas de código de um programa e a medida de número de defeitos encontrados em todo o programa, podemos estabelecer a métrica de quantidade de defeitos por linha de código.

No âmbito da construção de um software, as medidas podem ser categorizadas em (SWEBOK, 2004):

• Medidas de Processo

A expressão “medida de processo” que usamos aqui significa a coleta, análise e interpretação de informações quantitativas sobre o processo utilizado pelo desenvolvedor. A medição é usada para identificar os pontos fortes e deficiências do processo, além de avaliar o processo após sua implementação ou mudança. Por exemplo, a introdução de inspeções de software no processo pode reduzir o esforço para realização de testes.  No entanto, pode haver aumento de tempo até a entrega do produto, caso as reuniões de inspeção sejam extensas demais. A decisão de se investir mais tempo nas inspeções do que nos testes, por exemplo, deverá ser tomada com base em métrica aplicada no processo.

• Medidas de Produto

As medidas de um produto incluem o tamanho do produto, sua estrutura e sua qualidade. Trataremos melhor dessas medidas e algumas das métricas correspondentes no decorrer desta seção. Outras duas medidas também devem ser consideradas neste contexto (MOORTHY, 2013):

• Medidas de Projeto

Usadas para quantificar o desempenho de um projeto de software. Por exemplo, uma métrica comumente usada neste contexto é a porcentagem de variação no cronograma do projeto, assim expressa: (data real de término – data planejada de término *100) / (data planejada de término – data real de início).

• Medidas de Recursos

Usadas para quantificar a utilização de recursos em um projeto de software. Imagine que estejamos tratando de recursos humanos, ou seja, pessoas.  Uma boa medida de efetividade seria dada pela quantidade de tarefas cumpridas por unidade de tempo, considerando tarefas de complexidade e duração semelhantes.

Análise de pontos por função

Essa técnica se baseia nos requisitos do software para a obtenção da métrica.  Por isso, ela é aplicável a partir do momento em que os requisitos funcionais do programa (ou as histórias) tenham sido definidos.  Esses requisitos (ou funções – daí o nome de Pontos por Função) são convertidos em valores numéricos que, depois de calculados e ajustados, proverão excelente ideia do esforço necessário para desenvolver o sistema (WAZLAWICK, 2013).

Devemos considerar que os resultados obtidos pela aplicação dessa métrica não se prestam apenas para estimar esforço de desenvolvimento.  Dependendo da intenção de uso da métrica, a contagem dos pontos de função também pode ser usada para:

• Melhoria de um produto – neste caso, são contadas as funcionalidades alteradas, suprimidas ou adicionadas durante a manutenção adaptativa.

• Contagem de aplicação – técnica usada para contar pontos de aplicações já existentes.

• Funções do tipo dados

Representam as necessidades de dados dos usuários, de acordo com sua visão de negócio.  Divide-se em:

Arquivo Lógico Interno (ALI): trata-se de um elemento percebido pelo usuário e mantido internamente pelo sistema.  Exemplos: arquivos de cadastro de clientes, cadastro de funcionários, arquivos de mensagens de auxílio e arquivos de mensagens de erros.

Arquivo de Interface Externa (AIE): representa as necessidades de dados externos à aplicação, ou seja, são dados armazenados fora da fronteira da aplicação, mas que não sofrem manutenção internamente.

• Funções do tipo transação

Representam as funcionalidades de processamento de dados identificados pelos usuários. Existem três funções deste tipo:

Entrada Externa (EE): função que obtém dados informados pelo usuário ou por outra aplicação e os inserem no sistema. A função deve ter como objetivo armazenar, alterar ou remover dados no sistema. O nome de um cliente e seu endereço são exemplos de entradas externas.

Saída Externa (SE): função que obtém dados do sistema e apresentam ao cliente ou enviam a outras aplicações, sendo que pelo menos um valor obtido por cálculo deve existir para que seja considerada saída externa. Exemplo: fatura de um cliente, relação de clientes inadimplentes.

Consulta Externa (CE): função que apresenta dados da mesma forma que foram armazenados, sem cálculos ou transformações.  Configura uma consulta externa, por exemplo, informar o CPF de uma pessoa ao sistema para se obter seus dados cadastrais completos.

Ocorre que, para que essa métrica possa ser útil de fato, há que se levar em consideração a real complexidade técnica dessas funções.  Por exemplo, um sistema de controle de uma loja de locação de vídeo tende a possuir funções mais simples e estruturadas do que um sistema bancário. O método, então, prevê a aplicação de ajuste neste valor obtido em função de 14 características gerais do sistema, aplicáveis a todo o projeto.  Seguem:

1) Comunicação de dados: em que grau a comunicação de dados é requerida?

2) Processamento de dados distribuído: em que grau o processamento distribuído está presente?

3) Performance: o desempenho é fator crítico na aplicação?

4) Uso do sistema: o usuário deseja executar a aplicação em um equipamento já existente ou comprado e que será altamente utilizado?

5) Taxa de transações: qual o volume de transações esperado?

6) Entrada de dados on-line: são requeridas entrada de dados on-line?

7) Eficiência do usuário final: as funções interativas fornecidas pela aplicação enfatizam um projeto para o aumento da eficiência do usuário final?

8) Atualização on-line: há arquivos atualizados on-line?

9) Processamento complexo: qual o grau de complexidade do processamento interno?

10) Reusabilidade: em que grau o código é reutilizável?

11) Facilidade de instalação: em que grau o sistema é fácil de ser instalado?

12) Facilidade de operação: em que grau o sistema é fácil de ser operado?

13) Múltiplos locais: o sistema é projetado para múltiplas instalações em diferentes organizações?

14) Facilidade para mudanças: a aplicação é projetada de forma a facilitar mudanças?

Revisões e inspeções de software

Dada a importância de ambos e a intenção de introduzir desde já temas relacionados a teste de software, uma nova abordagem será feita aqui. Uma inspeção típica apresenta cinco etapas formais (SCHACH, 2008):

1. Uma visão geral do documento a ser inspecionado (histórias, projeto, código ou outro) é dada e, logo após, é distribuído aos presentes na sessão;

2. Por meio de uma lista de imperfeições detectadas em inspeções recentes, a equipe deverá analisar e entender o presente documento;

3. Um participante escolhido deve percorrer o documento e conduzir a equipe de inspeção, garantindo que cada item seja verificado, em busca de falhas. A missão é encontrar falhas, não as corrigir. No prazo de um dia, o líder da equipe dever gerar relatório do que foi discutido;

4. No processo chamado reformulação, o responsável resolve as imperfeições encontradas;

5. No acompanhamento, o responsável deve garantir que cada questão levantada tenha sido adequadamente resolvida.

Para determinar a eficácia de uma inspeção, você pode usar a métrica da taxa de inspeção. Quando, por exemplo, a especificação dos requisitos (ou histórias) passam por inspeção, o número de páginas inspecionadas por hora pode ser medido.  Se a inspeção recair sobre o código, uma métrica interessante é a de quantidade de linhas de código inspecionadas por hora.

                               

Os testes de software

É sempre bom destacar que o objetivo do teste é encontrar problemas no software, e não garantir que o programa é livre de defeitos. Se o processo de teste não revelar defeitos, há que se aprimorar os casos de teste e o processo empregadoO processo de teste é normalmente separado em quatro grandes etapas:

• Planejamento: nesta etapa deve ser definido quem executa os testes, em que período, com quais recursos (ferramentas de teste e computadores, por exemplo) e qual será a técnica utilizada (técnica estrutural ou técnica funcional, por exemplo).

• Projeto de casos de teste: aqui são definidos os casos de teste que serão utilizados no processo. No próximo item, este conceito será detalhado.

• Execução do programa com os casos de teste: nesta etapa, o teste é efetivamente realizado. • Análise dos resultados: aqui verifica-se se os testes retornaram resultados satisfatórios. Na sequência, um item muito importante para a resolução do problema proposto será abordado.

Casos de teste

Um caso de teste é o par formado por uma entrada no programa e a correspondente saída esperada, de acordo com os requisitos do sistema.

É certo que a boa escolha dos casos de teste é fundamental para o sucesso da atividade. Um conjunto de casos de teste de baixa qualidade pode não exercitar partes críticas do programa e acabar não revelando defeitos no código

cada conjunto de casos de teste deverá estar associado a um grande requisito diferente a ser testado. Para que não se corra o risco de definilos incorretamente, é necessário planejamento e o bom conhecimento da aplicação

• Definir o ambiente no qual o teste será realizado;

• Definir a entrada deste caso de teste;.

• Definir a saída esperada para cada entrada;

• Definir os passos a serem realizados para executar os testes. Quando um caso de teste é executado, o seu resultado deve ser coletado.

• Passou: todos os passos do caso de teste foram executados com sucesso para todas as entradas;

• Falhou: nem todos os passos foram executados com sucesso para uma ou mais entradas;

• Bloqueado: o teste não pôde ser executado, pois o seu ambiente não pôde ser configurado. Pois bem, dessa forma definimos casos de teste. Há, no entanto, três conceitos especialmente importantes no contexto de teste e que são frequentemente confundidos entre si. Vamos a eles.

Defeito, Falha e Erro Que expressão que você usa quando um programa simplesmente trava ou não produz o resultado que se espera dele?

Tudo o que acontece de incomum em um programa pode ser chamado de erro? Observe os conceitos: Defeito: trata-se de deficiência algorítmica que, se ativada, pode levar a uma falha. Vamos a um exemplo. Observe o trecho que segue, escrito em pseudocódigo:

a = -1;

b = 0;

enquanto a < 0 faça

b = b + 1;

imprima (b);

imprima (a);

fim_enquanto;

Em algum momento o valor da variável deixará de ser menor que zero? Estamos diante de um defeito, mais precisamente um laço infinito.

Falha: é tida como um não funcionamento do programa, provavelmente provocada por um defeito. No entanto, uma falha também pode ser atribuída a uma queda na comunicação ou a um erro na leitura do disco, por exemplo.

Erro: ocorre quando o resultado obtido em um processamento e o que se esperava dele não são coincidentes. Um erro também está associado a uma violação nas próprias especificações do programa.

Depuração Enquanto testar significa executar o software para encontrar Pesquise mais Os conceitos de defeito, falha e erro não são uniformes nas referências. Outros conceitos básicos também podem variar entre autores. Uma boa fonte introdutória e conceitual pode ser obtida em: . Acesso em: 14 fev. 2016. 170 U4 -Os testes de software defeitos desconhecidos, a depuração é a atividade que consiste em buscar no código a localização desses erros. O fato de saber que o programa não funciona não implica, necessariamente, já se saber também em qual ou quais linhas o problema está. Os ambientes de programação atuais oferecem recursos para depuração do programa. Durante esse processo, o valor assumido pelas variáveis sob inspeção em cada passo do algoritmo pode ser observado.

Técnica de teste funcional

Esta técnica baseia-se nas especificações do software para derivar os requisitos de teste. O teste é realizado nas funções do programa, daí o nome funcional. Não é seu objetivo verificar como ocorrem internamente os processamentos, mas se o algoritmo inserido produz os resultados esperados (BARTIÉ, 2002).

Uma das vantagens dessa estratégia de teste é o fato de ela não requerer conhecimento de detalhes da implementação do programa. Sequer o código-fonte é necessário.

O planejamento do teste funcional envolve dois passos principais: identificação das funções que o software deve realizar (por meio da especificação dos requisitos) e a criação de casos de teste capazes de checar se essas funções estão sendo executadas corretamente.

Apesar da simplicidade da técnica e apesar de sua aplicação ser possível em todos os programas cujas funções são conhecidas, não podemos deixar de considerar uma dificuldade inerente

Técnica de teste estrutural

Os testes estruturais (ou de caixa branca) são assim conhecidos por serem baseados na arquitetura interna do programa. De posse do código-fonte (ou do código-objeto) e, se for o caso, das estruturas de banco de dados, o profissional designado para a atividade submete o programa a uma ferramenta automatizada de teste.

Se é certo que um teste, por melhor que seja executado, não conseguirá assegurar que o programa é 100% livre de defeitos, qual a indicação de que é chegado o momento de interromper os testes? Pois é justamente durante o planejamento do teste que os critérios de parada da atividade são definidos.

Pois bem, a devida introdução ao teste de software foi dada. Existem outras tantas técnicas e métodos de aplicação de teste cuja abordagem extrapolaria os objetivos desta seção. Embora de difícil execução e de Reflita Se é certo que um teste, por melhor que seja executado, não conseguirá assegurar que o programa é 100% livre de defeitos, qual a indicação de que é chegado o momento de interromper os testes? Pois é justamente durante o planejamento do teste que os critérios de parada da atividade são definidos. 174 U4 -Os testes de software custo relativamente alto, a atividade de teste é fundamental no processo de criação de programas. É certo que desenvolvedores têm investido em ferramentas e em material humano para conferir graus elevados de qualidade aos seus produtos. E é importante que seja assim.

                 

O ciclo de vida de um erro

Compreende o período entre a identificação do erro e sua efetiva correção, sempre durante o processo de testes. Em cada fase de seu ciclo, o erro recebe uma denominação diferente, providência importante para que os envolvidos identifiquem seu estado com rapidez e correção

Vamos ao exemplo de como o erro percorre seu caminho da descoberta até sua correção. Imagine um aplicativo de envio de e-mail sendo testado. Assim que o programa é terminado, o responsável confere a página de login e descobre que o campo de nome de usuário permite nomes duplicados. A partir da constatação, o responsável registra o erro e o reporta ao líder do teste. O líder então verifica o erro e, caso o valide, este receberá o status de “novo” e será passado à equipe de desenvolvimento. O líder da equipe de desenvolvimento faz nova verificação e, se for constatado que se trata de fato de um erro no programa, o erro é atribuído a um desenvolvedor – no caso um especialista em banco de dados – para correção. O desenvolvedor cria uma chave primária na tabela, altera o status do erro para “corrigido” e reporta a ação para o líder do teste que, por sua vez, muda o status para “novo teste” e atribui a tarefa de revisão a um testador. Se, depois disso, o erro tiver sido sanado, seu status passará para “fechado”.

Pois bem, esse é um meio possível de se tratar um erro. Sejam quais forem as ações escolhidas, elas devem ser registradas, estruturadas e, naturalmente, desempenhadas por todos os envolvidos no processo de teste.

O testador reporta um erro ao líder do teste, que não interpreta a situação como erro e o rejeita;

• O líder do teste valida o erro encontrado pelo testador e o reporta ao líder do desenvolvimento, que o rejeita;

• Tanto o líder do teste quanto o líder do desenvolvimento validam o erro. O desenvolvedor trabalha para corrigi-lo e reporta ao líder do teste que ele está resolvido. Mais uma vez, o testador realiza o teste e verifica que ele não foi resolvido.

• Com base em sua prioridade ou gravidade, o erro pode ser postergado. A classificação da gravidade pode ser baixa, média, alta ou crítica.

A intenção do que chamamos de Engenharia de Testes é simples: oferecer entendimento do que é um erro e oferecer formas de encontrálo

Modelo Cascata Teoricamente, a fase de testes nesta metodologia concentra-se logo após o término da fase de codificação do programa. Na prática, contudo, o que se tem adotado é a revisão dos artefatos criados em cada uma das fases, sejam eles documentos, especificações, projetos ou um programa.

Na sequência, abordaremos o já conhecido TDD, meio pelo qual o XP conduz seu processo de teste.

TDD - Test-Driven Development (Desenvolvimento Guiado pelos Testes)

Trata-se de um formato de teste muito parecido com o “codificar e testar”, modelo de desenvolvimento no qual não se dá ênfase a outras etapas, senão as de codificar e testar.

Para a realização dos testes, o TDD apoia-se no fato de que a descrição dos requisitos – ou as estórias escritas pelo cliente – não constitui documento com excessiva formalidade e detalhamento de funções e que, por esse motivo, o cliente deve acompanhar o processo de codificação e teste.

O teste de parte do código segue-se à sua criação, ou seja, o teste e a integração são feitos logo após sua codificação. Os passos do desenvolvimento guiado pelos testes incluem:

• A seleção de um conjunto de casos de teste;

• A execução do caso de teste. Encontrando-se o defeito, o código deverá ser ajustado. Caso não se encontre defeito, novo conjunto de casos de teste deve ser selecionado e o processo deve ser reiniciado (PINHEIRO, 2015).

                                      

Os testes de release e de usuário

Testes de unidade Para entender um teste de unidade, imagine o software como um conjunto de partes que, juntas, formam o todo

No contexto dos testes de unidade (ou testes unitários) insereNão pode faltar 192 U4 -Os testes de software se um elemento conhecido como stub. Ele simula resultados que são retornados por um determinado componente do qual o software depende (PINHEIRO, 2015). Em outras palavras, um stub é um trecho de código que substituirá as entradas, dependências e comunicações que a unidade deveria receber em uma execução do programa.

Veja um bom exemplo de aplicação de um stub: Suponha que o componente A é uma classe que deve usar um gerador de números primos B. A implementação de B ainda não foi feita. No entanto, para testar a unidade A não será necessária a geração de alguns poucos números primos. Assim, B pode ser substituído por uma função stub que gera apenas os 5 primeiros números primos (WAZLAWICK, 2013)

Testes de integração

Trata-se de teste executado pelo testador para garantir que vários componentes do sistema funcionem corretamente juntos (PINHEIRO, 2015).

Teste de usuário (ou teste de aceitação)

Quando já se dispõe da interface final do sistema, o teste de aceitação já pode ser aplicado. Como o próprio nome nos faz supor, esse teste é executado pelo usuário e não pela equipe de testadores ou desenvolvedores.

Teste de sistema

É feito quando todas as unidades e as integrações entre elas já foram testadas. Pode ser que a equipe já se sinta confiante o bastante nesse ponto para assumir que seu produto é de boa qualidade. No entanto, é necessário que ele passe por esse novo teste depois de integrado.

O teste de aceitação

É chamado de Teste Alfa quando feito pelo cliente sem planejamento rígido ou formalidades. Se o teste é ainda menos controlado pelo time de desenvolvimento e as versões do programa são testadas por vários usuários, sem acompanhamento direto ou controle da desenvolvedora, então o procedimento é chamado de Teste Beta. Nesta modalidade, as versões disponibilizadas costumam expirar depois de certo tempo de uso.

Um termo bastante comum no contexto dos testes de aceitação é o release. Literalmente, o termo refere-se a uma liberação ou lançamento de uma nova versão de um produto de software.

• Alfa: nesta fase, o lançamento ainda está em processo de testes, que são realizados por pessoas situadas normalmente fora do processo de desenvolvimento.

• Beta: trata-se da classificação posterior a Alfa. Um lançamento em beta teste é avaliado por testadores beta, normalmente clientes em potencial que aceitam a tarefa de teste sem cobrar por isso.

• Release Candidate: trata-se de versão do sistema com potencial para ser a versão final. Neste caso, todas as funcionalidades já foram devidamente testadas por meio das fases Alfa e Beta.

De uma forma ou de outra, as modalidades de teste apresentadas até aqui relacionam-se diretamente às funcionalidades do sistema. Em outras palavras, elas fazem a verificação dos processos que efetivamente devem ser realizados pelo programa.

Teste de Desempenho

Tipo que tem por objetivo determinar se, nas situações de pico máximo de acesso e concorrência, o desempenho ainda permanece consistente com o que foi definido para essa característica do sistema

• Validar todos os requisitos de desempenho identificados;

• Simular n usuários acessando a mesma informação, de forma simultânea;

• Simular n usuários processando a mesma transação, de forma simultânea; 196 U4 -Os testes de software

• Simular n% de tráfego na rede;

• Combinar todos esses elementos.

Quando o procedimento eleva ao máximo a quantidade de dados e transações às quais o sistema é submetido, o teste realizado é chamado de Teste de Estresse. Ele é realizado para que se possa verificar se o sistema é suficientemente robusto em situações extremas de carga de trabalho.

Teste de recuperação

Seu objetivo é avaliar o software após a ocorrência de uma falha ou de uma situação anormal de funcionamento. Algumas aplicações demandam alta disponibilidade do programa e, no caso de falha, o software deve ter a capacidade de se manter em execução até que a condição adversa desapareça.

• Queda de energia na organização em que o sistema está em funcionamento;

• Discos corrompidos;

• Problemas de queda de comunicação;

• Quaisquer outras condições que possam provocar a terminação anormal do programa ou a interrupção temporária em seu funcionamento

Pois bem, eis então algumas das outras modalidades de teste e outros conceitos relacionados à atividade. Chega a hora, então, de tratarmos dos registros das atividades de teste, visando capacitá-lo ainda mais para o desafio desta seção. Vamos a eles

Os relatórios da qualidade do software

O registro das atividades relacionadas ao processo de qualidade, sobretudo os testes, são feitos em relatórios específicos. Além do efetivo registro, eles servem também como instrumentos de medição e análise.

Log de execução

Este documento é criado para registrar todos os procedimentos realizados durante a execução de um ciclo de testes, bem como apontar as eventuais interrupções ocorridas.

Ocorrências da validação

Neste documento registram-se todas as ocorrências geradas durante um teste. Uma ocorrência pode ser, por exemplo, a identificação de um defeito

Um dado também bastante importante a ser registrado é a classificação do defeito. Apesar de haver muitas classificações, alguns deles são mais relevantes:

a) Falha na descrição funcional: esta classificação refere-se à discrepância entre a descrição da funcionalidade e sua efetiva implementação.

b) Falha no controle, lógica ou sequenciamento do algoritmo: um laço de repetição infinito é um exemplo desse tipo de falha;

c) Falha nas estruturas de dados: trata-se da definição incorreta, por exemplo, de matrizes e tabelas de banco de dados;

A norma IEEE 829 é o padrão criado pela IEEE para documentação do processo de teste. Um dos relatórios recomendados pelo padrão é o de incidente de teste, que prevê a descrição dos seguintes itens, entre outros, em caso de ocorrência de um incidente: entradas, resultados esperados e resultados encontrados. Vale registrar que um incidente pode ser entendido como discrepância entre o resultado esperado e o encontrado na execução dos casos de teste. Crie um exemplo de um processo de teste que contemple uma entrada de caso de teste, faça previsão de um resultado esperado para aquela entrada e forneça a descrição do resultado obtido.

                                

A manutenção e evolução de software

A expressão manutenção de software, quando entendida da forma costumeira, remete apenas a correções no programa provocadas pela ocorrência de erros durante a operação feita pelo usuário final. No entanto, essa atividade pode e deve assumir caráter mais significativo do que o meramente corretivo.

A manutenção pós-entrega

Assim que o produto passa pelo teste de aceitação, ele está apto a ser entregue ao cliente. Embora longe de ser considerada o encerramento definitivo do ciclo do software, a entrega marca o término do desenvolvimento de uma versão apta a ser utilizada em meio produtivo e adequada ao propósito de resolver as situações colocadas pelo cliente como requisitos do produto.

É correto imaginar que, após seu desenvolvimento, um software terá seu valor diminuído com o passar do tempo? Se imaginou que sim, está correto. Conforme falhas são descobertas no programa, conforme seus requisitos originais mudam e conforme produtos menos complexos, mais eficientes e mais avançados são lançados, o valor (não necessariamente financeiro) do software original vai se perdendo. Daí a necessidade de se aplicar melhorias que façam o produto evoluir.

A diferença entre a necessidade de novo desenvolvimento e a necessidade de aplicação da manutenção em produto já existente pode parecer clara, mas vale a pena contrastarmos as duas situações

considerando outros fatores que não o aspecto técnico apenas. Leia com atenção o que segue. Imagine que uma mulher teve seu retrato pintado aos 18 anos.

Anos mais tarde, já casada, ela decide que o marido deve ser incluído no quadro, ao seu lado. Grandes dificuldades acompanham essa decisão:

• A tela não é grande o suficiente para acomodar o marido ao lado dela;

• Com o tempo, as cores do quadro ficaram menos vivas. Haveria possibilidade de retoque, mas a tinta usada já não é mais fabricada;

• O artista original se aposentou e foi morar em outro país;

• O rosto da mulher envelheceu e não há garantia de que a figura do quadro possa ficar parecida com a feição atual da mulher. Considere agora a manutenção de um programa de computador que custa R$ 2 milhões para ser desenvolvido. Quatro dificuldades se apresentam:

• O disco rígido no qual a base de dados está armazenada está quase cheio e novos dados não podem mais ser incluídos;

• A empresa que fabricava o disco faliu e outro disco de maior capacidade, de outro fabricante, já foi comprado. No entanto, há incompatibilidade entre o novo disco e o software e as adequações custarão R$ 100 mil;

• Os desenvolvedores originais já se aposentaram e a manutenção deverá ser feita por profissionais que jamais cuidaram do programa antes;

• O produto original foi construído por meio do uso do modelo clássico de desenvolvimento. No entanto, há real necessidade de que o paradigma de orientação a objeto seja usado no produto que surgirá depois da manutenção. Percebe a correspondência entre os itens do quadro e os itens do programa? A conclusão para o primeiro caso é que, partindo da estaca zero, um outro artista deverá pintar o retrato do casal para atender ao pedido da mulher. Isso também significa que, ao invés da manutenção de R$ 100 mil, um novo produto de R$ 2 milhões deve ser criado? Independentemente de estarmos tratando de quadros ou de programas de computador, muitas vezes parecerá mais simples e viável a criação de um novo produto

Entre os anos de 1974 e 1996, o pesquisador alemão Meir M. Lehman publicou oito leis que colocam a evolução do software como necessária e inevitável. Você pode pesquisar sobre o tema em: . Acesso em: 10 mar. 2016

Como exemplo, se tomarmos um programa que foi desenvolvido com o esforço de 80 horas de desenvolvimento/mês, seu SDT será igual a 80. Se a taxa anual esperada de linhas em manutenção (ACT) for de 2%, então o esforço anual esperado de manutenção para esse programa será dado por E = 0,02 * 80; E = 1,6.

De acordo com essa técnica, espera-se esforço anual de 1,6 horas de desenvolvimento/mês destacadas para atividade de manutenção (WAZLAWICK, 2013).

É claro que você deve considerar a criticidade da manutenção, a experiência dos programadores, a complexidade do programa e outros fatores que poderão influenciar na necessidade de mão de obra. Contudo, não se pode negar que essa estimativa irá te ajudar a ter boa noção da quantidade de programadores que deverá destacar para a atividade. Pois bem, chegamos assim ao fim do nosso conteúdo teórico. Torcemos vivamente para que a compreensão dos assuntos abordados em nossos 16 encontros tenha sido satisfatória e que o conhecimento adquirido seja decisivo na realização do seu projeto de vida. Fica a seguinte sugestão: não pare por aqui! A Engenharia de Software é um campo vastíssimo e tópicos mais avançados desta disciplina devem merecer sua atenção.

ACT - Modelo de Estimação de Esforço de Manutenção

O modelo ACT (Annual Change Traffic ou Tráfego Anual de Mudança) foi proposto por Boehm (1981) e se baseia em uma estimativa de porcentagem de linhas de código que passarão por manutenção. Para efeito de contagem, são consideradas como linhas em manutenção tanto as linhas a serem alteradas quanto as novas linhas criadas. O valor da variável ACT reflete o número de linhas que sofrem manutenção dividido pelo número total de linhas do código em um ano típico (WAZLAWICK, 2013). A fórmula criada é E = ACT * SDT, em que E representa o esforço, medido em desenvolvedor/mês, a ser aplicado no período de um ano nas atividades de manutenção, ACT representa a porcentagem esperada de linhas modificadas ou adicionadas durante um ano em relação ao tamanho do software e SDT é o tempo de desenvolvimento do software, ou Software Development Time.

                       

Referências

·        Neto, Roque Maitino. << engenharia de software>>(PDF)

·        https://www.desenvolvimentoagil.com.br/scrum/