Usuário(a):Eng.software/Testes

Unidade I

Seção 1.1

Introdução à Engenharia de software: aspectos gerais, objetivos, evolução do software e crise do software.

“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.”

Princípios ou paradigmas (Pilares):

Como toda disciplina, a Engenharia de Software também possui alguns aspectos, tais como:

1. 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.

1. 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.

1. 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.

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

1. 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.

1. Integridade conceitual: seguir uma filosofia e arquitetura de projeto coerentes.

1. Completeza: checar para garantir que nada foi omitido.

Também podemos classificar as Principais categorias de software veja a seguir:

1. Software básico: apoio a outros programas. Forte interação com o hardware. Exemplos: compiladores, device drivers, componentes de sistema operacional.

1. 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.

1. 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.

1. Software científico: algoritmos de processamento numérico. Usados na astronomia, mecânica e projeto auxiliado por computador.

1. 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 de Software

Em 2002, uma empresa global de pesquisa em Tecnologia da Informação chamada Cutter Consortium, constatou que 78% das empresas de TI pesquisadas fizeram parte de ações judiciais motivadas por desavenças relacionadas a seus produtos. Na maioria destes casos (67%), os clientes reclamavam que as funcionalidades entregues não correspondiam à suas demandas. Em outros tantos casos, a alegação era que a data prometida para entrega havia sido por várias vezes desrespeitada e, por fim, em menor quantidade, a reclamação se originava do fato de o sistema ser tão ruim que simplesmente se podia utilizá-lo.

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.

Seção 1.2

-Fundamentos dos processos de desenvolvimento de software

De acordo com o Guia do conhecimento em gerenciamentos de projetos, projeto “É um conjunto de atividades temporárias, realizadas em grupo destinadas a produzir um produto, serviço ou resultado únicos”. Segundo Wazlawick processo é o conjunto de regras que definem como um projeto deve ser executado, ainda de acordo com esse autor transformar o desenvolvimento de software como um processo trás inúmeras vantagens como:

Redução no tempo de treinamento com funções predefinidas

Produção de artefatos mais uniformizados, já que a previsibilidade dos processos ajuda a trabalhar de forma mais padronizada.

Transformação de experiencias em valor aperfeiçoando com o tempo.

Os processos de software contêm divisões em sua estrutura tais como:

Fases: Em uma fase do processo ocorre um conjunto de atividades e afins com objetivos bem definidos. A modelo cascata de desenvolvimento, por exemplo apresenta fases bem definidas como a fase de requisitos, fase de projeto.

Atividades ou tarefas: Geralmente semelhante a um projeto em pequena escala, visa promover modificações nos artefatos do processo. As atividades devem possuir entradas, saídas, responsáveis, participantes e recursos bem definidos.

Sabemos até o momento que processo é um conjunto disciplinado e articulado de tarefas, que serve para sistematizar o desenvolvimento de software. Há, no entanto, certos tipos de processos ditos como prescritivos que contem detalhes das atividades realizadas. A modelo cascata também conhecido como modelo mais tradicional e mais usado ainda é utilizado para desenvolvimento de softwares.

O ciclo da vida de um software e descrito por Rezende (2005) com as seguintes fases: Fase de requisitos, projeto, implementação, teste e manutenção. Nesse tipo de processo uma fase depende do resultado ou do produto gerado pela anterior. Neste modelo se utiliza o retrocesso a uma fase anterior para sanar problemas que se levados adiante podem gerar prejuízo ao desenvolvedor.

Fase de requisitos: Levantamento de informações necessárias para iniciar o projeto de um sistema. Fazem parte dos requisitos suas funções, suas características e suas restrições.

Fase de projeto: Por meio do projeto os requisitos são refinados de modo a se tornarem aptos a serem transformados no software. Analise requisitos.

Fase de implementação: Projeto transformado em protótipo para que seja executado com a finalidade de avaliar o software.

Fase de testes: Executar o protótipo do programa para revelar a presença de defeitos.  

Fase de manutenção: Fase onde se corrige falhas para a melhorar o desempenho de software.

Seção 1.3

Modelos e etapas do processo de software: características, requisitos, projeto de sistema, desenvolvimento, integração, instalação e manutenção.

Requisitos de software: A área de requisitos de software preocupa-se com o levantamento, análise, especificação e validação das propriedades que devem ser apresentadas para resolver tarefas relacionadas ao software em desenvolvimento. Requisitos são a expressão mais detalhada sobre aquilo de que o usuário ou cliente precisa em termos de um produto de software.

1. 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.

1. Entrevista: 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.

1. Aplicação de questionário: O questionário geralmente é aplicado em formulário distribuído para os futuros usuários do sistema. Seu elaborador deve utilizar questões diretas e objetivas, dispostas preferencialmente na mesma ordem para todos os participantes e que consigam extrair deles respostas sobre o procedimento atual adotado.

Análise de requisitos: 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.

Especificação dos requisitos de software: Refere-se a produção de um documento contendo os requisitos levantados e analisados, que podem ser sistematicamente revistos, 36 U1 - Fundamentos de Engenharia de software avaliados e aprovados. Ele estabelece um contrato entre cliente e desenvolvedor. Geralmente escrito em linguagem natural, forma base realista para estimativas de custos, riscos e cronograma.

1. Estabelece a base para a concordância entre clientes e fornecedores, naquilo que o software deve produzir;
2. Reduz o esforço para o desenvolvimento. Uma revisão cuidadosa dos requisitos na ERS pode trazer à tona omissões e falhas em fases iniciais no ciclo de desenvolvimento quando esses problemas são mais fáceis de corrigir;
3. Fornece base para estimativa de custos e agendas. A descrição do produto a ser desenvolvido é uma base realista para a estimativa dos custos do projeto e pode ser usada como referência de preço do produto; e
4. Fornece uma linha de base para validação e verificação. As organizações podem desenvolver seus planos de validação e verificação de forma muito mais produtiva a partir de uma boa ERS.

Validação dos requisitos: corresponde aos 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.

Seção 1.4

-Modelos de processos de software: Aplicabilidade e evolução.

O modelo tradicional de desenvolvimento de sistemas caracteriza-se pelo uso dos resultados das etapas anteriores para a construção da etapa seguinte. Por meio do material entregue na fase de projeto que se construirá o programa. Segundo a (SCHACH, 2008) Implementação é o processo de converter o projeto em código. Com todas as etapas anteriores realizadas com sucesso a implementação tende a ser bem compreendida. Alguns pontos desse processo devem ser alvos de atenção.

Escolha da linguagem de programação: A tomada dessa decisão passa pelas mãos do cliente e também depende da experiencia da equipe em determinada linguagem. Geralmente essa escolha é feita com previamente.

Práticas de programação adequada: O estilo escolhido pela equipe deve obedecer aos padrões da codificação com os nomes das variáveis sendo coerentes com sua real função. Também é incluído nessas boas praticas a documentação do código sendo ela objetiva e clara incluindo a descrição da função principal do programa.

Integração de software

Integrar significa reunir todos os módulos construídos durante a implementação em um grande modulo só. Uma das abordagens usadas é codificar e testar tudo separadamente e só então unir e testar o produto como um todo. Porem essa pratica possui algumas dificuldades em sua execução pois vários dos módulos possuem relacionamentos com outros e não podem ser testados isoladamente. A solução é a adoção de técnicas de integração incluindo a integração top-down, bottom-up e integração sanduiche.

Top-down: Isolamento de falhas, falhas de projeto são detectadas logo no início.

Bottom-up: Isolamento de falhas. Artefatos de código com potencial para serem reutilizados são testados adequadamente.

Integração sanduiche: Basicamente a mistura dos dois tipos de integração descritos acima.

Implantação de software: A ultima fase de desenvolvimento de um software., apesar de grandes chances de sofrer alterações durante sua vida útil espera-se que dessa fase saia o software em sua versão final. É comum que a implantação de um software se dê para substituir um anterior, nesse caso dados uteis devem ser preservados e convertidos para o novo formato.

Manutenção de software: O principal objetivo da equipe e entregar um software que satisfaça os requisitos do usuário adequadamente, uma vez em operação defeitos são descobertos. A manutenção é parte do ciclo de vida de um software e é definida como modificações em um produto afim de corrigir falhas e melhorar o desempenho.

Categorias de manutenção

Manutenção corretiva:  Feita após a entrega a fim de corrigir problemas descobertos.

Manutenção adaptativa: Modificação do software feita após a entrega a fim de manter o software usável em um ambiente alterado.

Manutenção perfectiva: Feita para a melhoria de desempenho.

Manutenção preventiva: Repara falhas latentes antes que se tornem maiores.

Unidade 2

Seção 2.1

Introdução a metodologias ágeis e comparações com a tradicional

Em empresas de desenvolvimento de software, a maioria das vezes o processo de desenvolvimento passa por etapas, desde a conversa com o cliente até o teste final e a entrega do produto.

·        O processo tradicional de desenvolvimento é baseado na construção linear do sistema, e que tem uma sequência já proposta de fases.

Fonte: Adaptado de Teles (2004).

Além de ser linear, existem outras características, como formas de se fabricar os bens de consumo, onde se prega o determinismo, a especialização e o foco na execução de quem está desenvolvendo o software.

Irei citar um exemplo para que fique bem mais explicado esse processo.

Pense em uma montagem de um Slot de um determinado produto, quando se escaneia um produto, lá aparece o nome do produto, o Item do produto e, e a validade de alguns dos produtos, e isso sempre gera um resultado conhecido, tem a segurança, a redução do tempo e o custo que esse produto pode acarretar.

           Os modelos tradicionais prezam muito pelo trabalho linear, isso acaba fazendo com que os desenvolvedores trabalhem de forma defensiva, com medo de errar, pois, a maioria dos modelos tradicionais, rever a sua obra depois de pronta é uma possibilidade baixa.

Agora nos processos ágeis de desenvolvimento, o processo é totalmente diferente do modelo tradicional, nos processos ágeis tem métodos para se fazer revisões sucessivas no projeto e as atividades não são feitas de forma linear e nem determinísticas.

Nos modelos ágeis o cliente está sempre presente no desenvolvimento, pois se houver alguma mudança e ela é solicitada, já na fase de desenvolvimento o profissional altera no projeto o que o cliente pediu.

Logo abaixo irei mostrar 2 métodos de desenvolvimento ágil:

·        Extreme Programming (XP)

Vamos começar pela equipe de trabalho do XP, o que ela faz?

O gerente de projeto é responsável pelos assuntos administrativos, incluindo relacionamento com o cliente. Fica por trás do projeto.

O coach é igual um técnico de futebol, tem que ser experiente e saber de tudo o que está acontecendo no projeto.

O analista de teste da um suporte ao cliente para escrever os testes de aceitação do projeto, com isso o analista de testes passa isso para os desenvolvedores para que isso possa ser feito.

O redator técnico faz a parte da documentação do sistema, proporcionando os desenvolvedores focar na construção do projeto.

E por fim o desenvolvedor que codifica o projeto e realiza a análise do mesmo, diferente dos outros os desenvolvedores não tem divisão entre as suas especialidades.

           O XP preza muito por quatro pilares para que se possa terminar seus objetivos:

O feedback faz com que o cliente veja e utilize o sistema, para que assim seja reavaliado suas necessidades e por fim passa o feedback para os desenvolvedores.

A comunicação faz com que o cliente e a equipe do projeto se comuniquem bastante para que tudo seja esclarecido de forma que o projeto saia “perfeito”.

A simplicidade é uma maneira de fazer o simples sem inventar muita coisa e que atenda tudo o que o cliente deseja.

E por fim a coragem que serve para melhorar o que já está em funcionamento.

Já no modelo Scrum, as práticas tem um pouco de semelhança com o XP, mais possuem nomes e graus de importância diferentes. Logo abaixo você conhecerá um dos principais elementos dessa metodologia.

Product Backlog: Onde se tem as funcionalidades que o cliente deseja ter no seu software.

Sprint Backlog: Nesse elemento será listado o que cada desenvolvedor irá fazer até finalizar o Sprint, com as funções propostas pelo Product Owner (Dono do produto).

Sprint: Onde é definido os ciclos para que se construa o que foi designado a cada desenvolvedor no Sprint Backlog. Os ciclos duram de 2 a 4 semanas, dependendo da empresa. No Sprint o Product Owner é como um mediador para que fique tudo em ordem. E por fim se houver alguma alteração pedida pelo cliente terá que ser feita no próximo Sprint.

           Agora vamos conhecer um pouco sobre a equipe dessa metodologia:

Scrum Master: É a pessoa que facilita o projeto, conhece sobre todas as funcionalidades, e que faz toda a manutenção durante a fase de desenvolvimento, deve atuar como um administrador para que sua equipe não faça tarefas que não consigam executa-las.

Product Owner: Como dito em cima é o dono do projeto, é a pessoa que determina no Product Backlog o que cada desenvolvedor irá fazer.

Scrum Team: O time do Scrum é composto por 6 a 10 pessoas da área de desenvolvimento (Dependendo da Empresa).

Seção 2.2

Métodos ágeis - Extreme Programming (XP): valores e práticas

Nesta seção foram abordados assuntos referentes a práticas de programação ágeis, sendo ela a metodologia XP (Extreme Programming). Essa metodologia tem algumas práticas e valores que a diferenciam das outras, sendo elas: Cliente presente, Programação em par, Código coletivo e entre outras.

Cliente presente:​ Esta primeira prática assume o papel principal no processo de quebra de paradigmas proposto pelo XP. Afinal, quando adotamos o modelo tradicional, nunca consideramos como válida – sequer aconselhável – a presença efetiva do cliente durante o desenvolvimento de um programa. Via de regra, a participação dele no projeto se dava apenas no momento da coleta de requisitos e na implantação do sistema. O modelo ágil, no entanto, sugere que o cliente deve conduzir o desenvolvimento a partir da utilização do sistema e sua proximidade da equipe viabiliza esta condução. Essa prática nos revela que a proximidade fomenta o feedback, o torna mais constante e evita mudanças bruscas na condução do projeto; Cliente próximo evita trabalho especulativo; Quanto mais distante o cliente estiver, mais difícil será demonstrar o valor do serviço; A proximidade provoca aumento da confiança mútua entre cliente e desenvolvedor.

Programação em par: ​Em determinado momento, o condutor assume o teclado e o navegador acompanha o trabalho, fazendo revisões e sugestões. Em outro, há revezamento de papéis. As correções são feitas no momento da programação, evitando que pequenos erros se tornem grandes problemas no futuro. A condução da programação deve ser realizada, em tempos alternados, pelos dois programadores. Eles devem se alternar, escrevendo código a cada 15 ou 20 minutos. O programador que não estiver escrevendo verifica cuidadosamente o código, enquanto ele está sendo criado pelo seu companheiro. A prática influencia na boa modelagem da solução, que passa a ser fruto do entendimento e da conversa entre os pares. Se um parceiro concebe algo muito complexo, o outro pode propor solução mais simples. O par exerce pressão positiva no desenvolvimento, evitando distrações de e-mail, bate-papos, cansaço, desânimo momentâneo. O compromisso deixa de ser individual e passa a ser também em relação ao par. Além de reduzir as chances de defeitos na programação, essa prática tende a tornar o conhecimento geral da equipe mais homogêneo e contribuir para o aprendizado contínuo.

Código coletivo: ​Já que o XP sugere a programação em par e, neste contexto, o rodízio de programadores, é normal que toda a equipe seja responsável pelo código que está sendo produzido. Sendo assim, não será necessária autorização para que seja alterado arquivo, por quem quer que seja, desde que mantido o padrão estabelecido. Você entende melhor agora o porquê de a coragem ser um dos valores do XP? Estimar estórias na presença do cliente, deixando-o priorizar as funcionalidades e manter o sistema simples são mais indicativos de que o uso do XP requer coragem. A prática do código coletivo pode ter o efeito benéfico de evitar “ilhas de conhecimento”, ou seja, profissionais que detenham conhecimento quase exclusivo sobre determinado projeto. O “sabe tudo” pode se ausentar por doença, férias, viagem ou mesmo deixar a empresa repentinamente e os demais

colaboradores poderão não saber alterar partes do projeto cujo conhecimento é quase exclusivo da “ilha”. Outro efeito importante do código coletivo é que, quando todos o acessam, o código tende a ser mais bem revisado. 

Stand up meeting 

           Uma das práticas mais simples e de implementação mais imediata é a stand up meeting (reunião feita em pé). Um dia de trabalho no XP começa com uma reunião rápida, com não mais do que 10 minutos de duração e que serve para que todos os membros da equipe comentem o trabalho do dia anterior e planeje o dia atual. Ao final do stand up, cada membro saberá o que deve fazer ao longo do dia. Esta prática pode reflita a programação em par é, de fato, imune a contratempos? Reflita. Na prática, foram observados alguns inconvenientes na programação em duplas. Por exemplo, ela requer grandes blocos ininterruptos de tempo, e os profissionais poderão ter dificuldades em alocar períodos de tempo de 3 a 4 horas ininterruptas. Em tempo: aconselha-se que a reunião seja feita todos os dias e com todos os participantes em pé, de modo a evitar prolongamento excessivo do tempo da conversa.

           Lembre-se:​ É do senso comum entre profissionais de TI que a metodologia XP, para atingir sua plenitude e ser efetiva, deve ser implantada em sua totalidade. Sua adoção parcial, embora possa trazer algum benefício momentâneo, não deverá ser entendida como regra. Há, contudo, a sensação de que a implantação das práticas deva ser gradual. A troca repentina e integral de uma metodologia em uma organização que sempre a praticou poderá ser, no mínimo, traumática. É justamente a mudança gradual e controlada que nosso desafio propõe.

Seção 2.3

Práticas do Extreme Programming e suas contra indicações.

Nesta seção serão tratadas outras práticas do XP, tão importantes quanto as primeiras.

Desenvolvimento Guiado pelos Testes: O teste de unidade consiste em verificar se um componente individual do software (uma unidade) foi implementado corretamente. Este componente pode ser uma classe, um método ou um pacote de funções e geralmente está isolado do sistema do qual faz parte. O desenvolvimento guiado pelos testes recomenda, inclusive, que antes de o programador desenvolver uma unidade de software, ele deve gerar o seu driver de teste, que é um programa que obtém ou gera um conjunto de dados que serão usados para testar o componente que ainda será desenvolvido. O teste de aceitação é realizado pelo cliente, que utilizará a interface final do sistema. A aplicação do teste de aceitação visa a validar o software em relação aos requisitos e não mais em relação a verificação de defeitos.

O desenvolvimento guiado pelos testes possui algumas regras que devem ser seguidas para que seja feita de forma correta e produza bons resultados, são els:

a) Todo código deve passar pelos testes de unidade antes de ser entregue: esta providência ajuda a assegurar que sua funcionalidade seja implementada corretamente. Os testes de unidade também favorecem a refatoração – que será abordada adiante nesta seção – porque protegem o código de mudanças indesejadas de funcionalidade. A introdução de uma nova funcionalidade deverá levar à adição de outros testes ao teste de unidade específico;

b) Quando um erro de funcionalidade é encontrado, testes são criados: um erro de funcionalidade identificado exige que testes de aceitação sejam criados. Desta forma, o cliente explica com clareza aos desenvolvedores o que eles esperam que seja modificado;

c) Testes de aceitação são executados com frequência e os resultados são publicados. Os testes de aceitação são criados a partir das estórias do cliente. Durante uma iteração, as estórias selecionadas para implementação serão traduzidas em testes de aceitação.

Durante o desenvolvimento do código é necessário ter padrões de codificação. Num ambiente XP a equipe deve se comunicar de forma clara através de código e, por isso, o XP sugere a adoção de padrões de codificação. As características desse padrão devem adotar um padrão fácil e de simples compreensão, sendo eles:

• Endentação: mesma largura na tabulação e mesmo posicionamento de chaves (abertura e fechamento de bloco);

• Letras maiúsculas e minúsculas: deve ser mantida a consistência com a caixa da letra (alta ou baixa). Java, por exemplo, tem uma padronização bem definida de maiúsculas e minúsculas;

• Comentários: evite comentários no código. Código simples transmite mais a mensagem do que quaisquer comentários;

• Nomes de identificadores: use nomes que comuniquem a ideia. Se preciso, use nomes longos. Padrões para nomes de tabelas também devem ser seguidos. É essencial que a equipe consiga descrever coisas similares com nomes similares.

Refatoração

A refatoração é uma palavra usada para identificar a melhoria na escrita de código já criado, sem que isso acarrete alterações em seu comportamento. A necessidade de se refatorar um código não é criação do XP, mas foi alçada a uma de suas práticas pela sua importância no contexto do pensamento ágil. A refatoração está ligada ao código coletivo e à implantação de padrões de codificação. Se a ideia é que todos tenham acesso ao código, que ele seja padronizado e ofereça facilidade em sua leitura.

Seção 2.4

Scrum

           Nesta parte iremos falar um pouco sobre a metodologia ágil Scrum. A metodologia Scrum teve a sua ideia em 1980 em uma empresa de automóvel, e tem o Sprint como pratica mais importante. As práticas do Scrum são muito parecidas com a metodologia XP, isso faz com que o Scrum seja bem aceito nas empresas, pois se baseia em uma metodologia que é bem conhecida já no mercado.

           O Scrum tem três figuras bem importantes que o compõe, e abaixo irei explicar um pouco sobre cada uma dessas figuras.

           O Scrum Team é basicamente a equipe de desenvolvimento (quem faz a codificação do código), igualmente ao XP a quantidade de pessoas nessa equipe varia de 8 a 10 pessoas, dependendo da empresa. Uma semelhança bastante notada é que todos colaboram para que o desenvolvimento seja em conjunto. Ex.ª: o analista, programador e projetista trabalham todos em conjunto, não separados igual em algumas empresas.

           Outra figura é o Product Owner (dono do produto), ele é basicamente o responsável pelo projeto em si, é quem determina o cada irá fazer em cada Sprint.

           Por último o Scrum Master, é o mediador do projeto em si, é quem conhece de todas as áreas, na maioria das vezes a pessoa mais experiente, ele faz de tudo para que as práticas do Scrum estejam sendo seguidas corretamente.

           O Scrum também lida com documentos que serão seguidos, um deles é o Product Backlog, é um tipo de documento que não pode faltar de nenhuma maneira em uma empresa que prega Scrum, essa prática é criada pelo Scrum Master juntamente com o cliente. No Product Backlog deve ser tudo listado e explicado a frente, um exemplo é a Tela de login, ela irá ter usuário e senha, e precisa ter a parte de criação de usuário. Basicamente as tarefas são dividas dessa forma sempre demonstradas a frente.

           E por fim a última prática mais conhecida e a que mais se destaca no Scrum é o Sprint, é onde o projeto se inicia, com ciclos, determinados pelo Product Owner. Em uma reunião chamada Sprint Planning Meeting, onde todos tem que ficar com pé, para que a atenção seja maior, irá se decidir o que cada desenvolvedor irá fazer, seguindo o que foi colocado no Product Backlog. Cada Sprint dura de 1 a 4 semanas, dependendo do que são as funcionalidades propostas, no Sprint o desenvolvedor que tiver dificuldade em fazer alguma coisa, o Product Owner, pega uma funcionalidade que o desenvolvedor consiga fazer, e essa funcionalidade que ele tem dificuldade, fica para um Sprint futuro.

           A cada Sprint avançado as funções determinadas vão sendo finalizadas, em um quadro chamado Sprint Burndown, que fica a vista de todos, apresenta-se as tarefas concluídas e as que serão feitas ainda.

           Finalizando o Sprint, a equipe realiza uma nova reunião chamada de Sprint Review Meeting, onde será avaliado aquele determinado Sprint, lembrando que todas as reuniões duram apenas alguns minutos e que são feitas de pé, para que as pessoas não fiquem relaxadas, fazendo com que prestem atenção no que está sendo dito.

           No Scrum também juntamente com o XP, prática reuniões diárias chamada de Daily Scrum, é um encontro da equipe para que seja planejado o dia presente e que o dia já finalizado seja revisto e revisado.

Unidade 3

Seção 3.1

Engenharia de Software

No caso da Engenharia de Software, devemos lembrar que a Qualidade não significa perfeição, mas sim que o produto atenda a todos os requisitos e funcionalidades que o cliente precisar. Desse modo, a Qualidade é como o Framework Scrum, não sendo universal, ou seja, para cada produto elaborado a Qualidade será atingida de forma diferente.

Ao longo dos anos, autores e organizações têm definido o termo qualidade de formas diferentes. Para Crosby (1979, p. 23), qualidade é a "conformidade com os requisitos do usuário".

Humphrey (1989, p. 280) refere-se à qualidade como "a conquista de excelentes níveis de adequação ao propósito", enquanto a IBM cunhou a frase "qualidade dirigida ao mercado", que se baseia na conquista total da satisfação do cliente.

Porém mais recentemente, a qualidade foi definida pela norma ISO 9001-00 como "o grau no qual um conjunto de características inerentes preenche os requisitos".

Para identificar a qualidade ou a falta dela nos produtos utiliza-se características como:

·        Corretude: capacidade do software de executar suas funções como foram definidas pelo cliente.

·        Eficiência: está ligada ao grau de adequação do programa aos recursos de hardware, tais como processador e memória.

·        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 conseguir usufruir de todas as funções do software por meio da sua interface.

·        Portabilidade: é a capacidade de usar o mesmo software em diferentes plataformas.

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

De acordo com Moorthy (2013), um sistema de gestão de qualidade de software deve possuir 4 níveis: o nível 1 é composto pelo manual de qualidade da empresa; o nível 2 refere-se aos métodos e processos usados pela equipe para entregar suas tarefas; o nível 3 contém as linhas principais, os checklists e os modelos, usados com bastante frequência no dia a dia e importantes na manutenção da consistência das informações e, por fim, o nível 4 refere-se aos registros e documentos usados para fins de validação de um produto, usados como evidências de uma atividade e úteis para referência futura.

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.

Pois bem, um processo específico de gestão de software é definido no padrão IEEE 12207.0-96 e inclui o Processo de garantia da qualidade, mais conhecido pela abreviatura SQA (Software Quality Assurance ou Garantia da Qualidade do Software).

Esse processo – também composto por várias etapas – visa assegurar que os produtos de software e os processos que os constroem estão em conformidade com os requisitos (ou funcionalidades) por meio de planejamento e execução de um conjunto de atividades destinadas a transmitir a certeza de que a qualidade é fator integrante do produto.

Outro processo que visa conferir qualidade ao produto é o que chamamos de Verificação e Validação. 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.

O grupo revisões e auditorias 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.

Seção 3.2

Qualidade e teste do Software

A Garantia da Qualidade de Software (SQA) Software Quality Assurance, de acordo com (PRESSMAN, 1995, p. 733) é o padrão pré-estabelecido de ações necessárias para se garantir a boa qualidade do software.

Assegurar a qualidade de um software envolve várias etapas de acordo com (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 e 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 tiver sido criado, deve-se avaliar seus quesitos de qualidade.

Realização de revisões técnicas formais: esta é a principal atividade no contexto da avaliação da qualidade de um produto. Uma revisão técnica formal é um encontro no qual uma equipe destacada para o trabalho concentra-se na busca por problemas de qualidade no produto ou numa parte específica dele. Elas são aplicadas em momentos variados do processo e também são usualmente referenciadas como walkthrough (passo a passo).

Atividades de teste de software: realizar teste é o meio mais rápido e barato de verificar se o software está pronto para uso.

O processo de teste possui quatro etapas: planejamento, projeto de casos de teste, execução e avaliação dos resultados, que devem ser realizadas ao longo de todo o processo de desenvolvimento (ROCHA; MALDONADO; WEBER, 2001).

O modelo de qualidade ISO/IEC 25010:2011 estabelece oito características nomeadas de (características do produto), as quais interferem diretamente na qualidade do software, sendo elas:

1. Adequação funcional: se refere à existência de um conjunto de funções que satisfazem às necessidades estabelecidas, quando o produto é usado sob condições específicas. Duas de suas subcaracterísticas são a Completude Funcional (quando 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 corretas para seus usuários) (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).

3. Usabilidade: 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?

• 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.

Seção 3.3

Padronização de Software

Em Genebra, cidade da Suíça, está localizado o escritório central da ISO (International Organization for Standardization) organização independente e não governamental, com membros em 162 países e que desde fevereiro de 1947 já publicou mais de 20.500 padrões internacionais que cobrem quase todos os aspectos dos ramos da atividade humana, tais como saúde, agricultura, manufatura e, tecnologia.

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).

A ISO 9001:2015 se baseia em 7 princípios de gerenciamento de qualidade: Engajamento de Pessoas, Foco no Cliente, Liderança, Abordagem de Processo, Melhoria, Tomada de Decisão Baseada em Evidências e Gestão de Relacionamento.

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.

O CMMI (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.

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

Nível	Capacidade	Maturidade
0	Incompleto	-
1	Realizado	Inicial
2	Gerenciado	Gerenciado
3	Definido	Definido
4	-	Quantitativamente gerenciado
5	-	Em otimização

Existem duas estruturas do CMMI: em estágios e contínua.  Embora a diferença seja sutil, ela é significativa. A representação (ou estruturação) em estágios usa níveis de maturidade para caracterizar o estado geral dos processos da organização em relação ao modelo como um todo, enquanto a representação contínua utiliza níveis de capacidade para caracterizar o estado dos processos da organização em relação a uma área de processo individual. Em outras palavras, a representação por estágios é aplicada à organização como um todo e permite que se compare à maturidade de diferentes organizações.  Já a representação contínua é projetada para permitir à empresa focar em processos específicos que deseja melhorar em função de suas prioridades (WAZLAWICK, 2013).

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.

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. Assim, 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:

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).

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.

Seção 3.4

Os Processos

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. A medição é tipicamente uma quantificação direta, que envolve um único valor, enquanto a métrica é uma quantificação indireta, que envolve o cálculo e o uso de mais de uma medida.

É desejável que as métricas sejam capazes de fornecer informação relevante para a tomada de decisão e para a comparação de desempenhos. A métrica pode tanto ser usada em sua forma original, como também modificada de acordo com as necessidades da empresa para a tomada de decisões.

Em relação a construção de um software, as medidas podem ser categorizadas de acordo com (SWEBOK, 2004) em:

• Medidas de Processo: 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.

• 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.

Algumas métricas são geradas a partir de medidas obtidas diretamente, geralmente por contagem do atributo observado. Às métricas geradas damos o nome de métricas diretas. Outras métricas, porém, são obtidas indiretamente. A elas damos o nome de métricas indiretas.

A técnica da Análise de pontos por função 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 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).

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.

Na sequência do processo, vem a contagem das funções do sistema. Vejamos o procedimento (MECENAS; OLIVEIRA, 2005):

• 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?

Como cada um receberá uma nota de 0 a 5, o somatório desses fatores ficará entre 0 e 70.  Assim, finalmente, a fórmula para o cálculo dos pontos por função ficará como segue:

Onde: VAF = Value Adjustment Factor ou Fator de Ajuste da Função;

GSC = General Systems Characteristics ou Características Gerais do Sistema.

Por fim, tendo sido obtido os pontos não ajustados, que chamaremos de UFP (Unadjusted Function Points, ou pontos por função não ajustados), basta aplicar a fórmula que segue para o número de pontos por função ajustado:

AFP= Pontos por Função

UFP= Somatório das notas das 14 perguntas

VAF= Fator de Ajuste da Função

Unidade 4

Testes de Softwares

           Nesta seção o assunto abordado é responder e mostrar como as atividades de teste de software podem contribuir de forma primordial e decisiva para a qualidade do produto final e consequentemente, reduzindo erros que podem acontecer no futuro.

           Um caso de teste é um dado de entrada que leva o programa a executar partes de seu código e o respectivo resultado de acordo com a entrada desses dados.

           No decorrer das unidades, vimos que sempre citamos o teste como uma parte final, mas primordial para o desenvolvimento do produto final afinal, é graças ao teste que saberemos se nosso produto estará de qualidade para os nossos clientes, poderemos ver melhor como usarmos os testes corretamente de acordo com seus fundamentos:

           Um teste – ou um processo de teste – consiste em uma sequência de ações executadas com o objetivo de encontrar problemas no software, o que aumenta a percepção de qualidade geral do software e garante que o usuário final tenha um produto que atenda às suas necessidades (PINHEIRO, 2015).

           O uso do teste não é garantir que o software esta livre de problemas e sim encontrar os problemas, caso não seja encontrado nenhum problema, devemos sempre analisarmos com calma e aprimorarmos nossos casos de teste. A chance de um sistema não possuir um problema é muito baixa, podendo passar um grande problema despercebido.

           O processo de teste é dividido em quatro etapas, são eles:

           • 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.

Para obtermos um resultado satisfatório com o processo de teste, devemos sempre analisar o ambiente no qual o teste será realizado, definir a entrada deste caso de teste, definir a saída esperada para cada entrada e definir os passos a serem realizados para a execução do teste assim, quando passarmos desta etapa encontraremos nossos resultados sendo eles:

• 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.

Porem mesmo seguindo tudo em ordem temos três conceitos muito importante no uso de teste e que são bastante confundidos entre si, são eles:

Defeito: trata-se de deficiência algorítmica que, se ativada, pode levar a uma falha.

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.

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.

Apesar de toda essa dificuldade, temos outros três conceitos que nos auxiliam a entender melhor, são eles:

Depuração: Enquanto testar significa executar o software para encontrar 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. Além disso, alguns pontos de parada da execução do programa podem ser inseridos no código. Tudo para possibilitar que o testador identifique e isole o defeito no código.

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).

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. A ferramenta constrói uma representação de programa conhecida como grafo de programa. No grafo, os nós equivalem a blocos indivisíveis, ou seja, não existe desvio de fluxo do programa para o meio do bloco e, uma vez que o primeiro comando do bloco é executado, os demais comandos são executados sequencialmente. As arestas ou arcos representam o fluxo de controle entre os nós.

Com base no que foi apresentado ate o momento, vimos que o caso de teste pode auxiliar demais a encontrar erros que passaram despercebidos durante a montagem do software, porém, devemos seguir técnicas para nosso caso ser sempre bem utilizado e sempre tirar o maior proveito do que podemos encontrar em nosso programa.

Seção 4.2

TDD (Test-Driven Development)

Nesta seção será abordada o uso da nova abordagem TDD (Test-Driven Development) e também mostrar como tratar um erro, qual a tomada de decisão de um testador após encontra-lo.

Engenharia de testes: Um erro ocorre quando uma ou mais das opções a seguir for verdadeira (PINHEIRO, 2015):

• O software não faz algo que a especificação estabelece que ele deveria fazer;

• O software faz algo que a especificação estabelece que ele não deveria fazer;

• O software faz algo que a especificação não menciona;

• O software não faz algo que a especificação não menciona, mas deveria mencionar;

• O software é difícil de usar, entender ou, na visão do testador, pode ser visto pelo usuário final como não estando correto.

Então como podemos perceber, que a especificação incorreta é uma das grandes causas de erros em programas.

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. O ciclo inclui os seguintes estados:

Novo: Erro encontrado pelo testador.

Aberto: Erro que foi revisado e confirmado como um defeito.

Rejeitado: Erro que não foi confirmado como tal

Atribuído: Erro confirmado e já designado (ou atribuído) a um desenvolvedor para correção.

Corrigido: Erro já corrigido e pronto para passar por novo teste.

Reaberto: Erro que se manifestou novamente durante o novo teste.

Fechado: Erro que passou com sucesso pelo novo teste.

Postergado: O erro será tratado em versões futuras do programa, seja por baixa prioridade ou tempo escasso.

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. Há, no entanto, algumas outras situações que podem ocorrer durante o tratamento de um erro. Vejamos:

• 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. O erro, então, reassume o status de “aberto”;

• 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.

Após toda essa análise, vamos ver como os Modelos Cascata e XP (Extreme Programming) recebem os testes:

           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, 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. Ao longo dos anos, a aplicação de verificações e validações (nas quais o teste está incluído) apenas no programa executável mostrou-se ineficiente, principalmente por deixar incorreções da especificação dos requisitos propagarem-se pela fase de implementação (PINHEIRO, 2015).

XP: 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. Em tempos passados, o teste era realizado tomando-se como base o código completo, ou quase completo, já que as linguagens de programação dificultavam a execução de apenas partes do programa. Hoje em dia, tecnologias que suportam linguagens orientadas a objeto (como o Java, por exemplo) permitem não só a automatização dos testes – ação tão importante no âmbito do TDD – como também a execução de partes autônomas de um programa, como uma classe.

Como podemos ver, nessa seção tratamos das implementações de testes e como desenvolvedores, chefes utilizam e aplicam a devida manutenção em bugs, erros encontrados. Também vimos como eles funcionam nos modelos XP e Cascata.

Seção 4.3

Modalidades Testes de Softwares

           Diversas modalidades de testes vêm sendo aplicadas por diferentes atores do processo, o que visa garantir que pessoas com diferentes visões do produto e em tempos distintos possam avalizá-lo.

           E justamente isso que iremos abordar nessa seção, iremos imaginar um software como um conjunto de partes e que juntas, formam ele por completo. Esse teste é realizado a uma rotina, classe que é executada por um desenvolvedor que faz testes para testar se uma unidade pode ser integrada ao software sem causar algum erro.

           Nos testes inserimos um elemento conhecido como stub. 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. Quando um componente A que vai ser testado chama operações de outro componente B que ainda não foi implementado, pode-se criar uma implementação simplificada de B, chamada stub. Neste caso, devemos entender que o componente A é a unidade a ser testada.

           Teste de integração: Trata-se de teste executado pelo testador para garantir que vários componentes do sistema funcionem corretamente juntos (PINHEIRO, 2015). Eles são feitos quando as unidades (as classes, por exemplo) já foram testadas de forma isolada e precisam ser integradas para gerar uma nova versão do software.

           Com isso está na hora do usuário fazer o teste, o teste de usuário funciona da seguinte forma: Como o próprio nome nos faz supor, esse teste é executado pelo usuário e não pela equipe de testadores ou desenvolvedores. Para entendermos melhor essa modalidade deteste, é interessante que a coloquemos em oposição ao teste de sistema.

           Já o teste de sistema funciona da seguinte forma: O 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 objetivo da sua aplicação é o de verificar se o programa é capaz de executar processos completos, sempre adotando o ponto de vista do usuário.

           Logo após ser passado pelo teste de sistema e de usuário, temos o teste de aceitação, que chamamos de teste Alfa, é um teste feito sem planejamento ou formalidade. Se o teste é ainda menos controlado pela desenvolvedora, ele é chamado de Teste Beta.

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. Os produtos em fase de teste alfa podem ser instáveis e sujeitos a travamento.

• 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. Uma versão Beta é utilizada para demonstrações dentro da organização e para clientes externos.

• 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. No entanto, a abrangência dos testes é maior e demanda a aplicação de outros tipos de verificações no produto. A esses tipos damos o nome de testes suplementares.

           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. Assim, o critério de sucesso aqui é a obtenção de tempo de resposta compatível com o que se espera do produto, quando o sistema trabalha em seu limite.

           Teste de recuperação: seu objetivo é avaliar o software pó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.

           Após isso tudo, analisamos os relatórios das qualidades do software:

           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. O log de execução certifica que, de fato, o teste foi realizado.

           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. Neste caso, alguns dos dados a serem relatados serão: um nome ou número de identificação do defeito, a data em que foi encontrado e a sequência de ações capazes de reproduzi-lo (BARTIÉ, 2002).

Seção 4.4

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.

           Por mais improvável que possa parecer, a manutenção pós-entrega consome mais tempo e recurso do que qualquer outra atividade do ciclo do produto. Atualmente, aproximadamente dois terços do custo total de um programa estão relacionados à manutenção (SCHACH, 2008).

ens orientadas a objeto (como o Java, por exemplo) permitem não só a automatização dos testes – ação tão importante no âmbito do TDD – como também a execução de partes autônomas de um programa, como uma classe.

Como podemos ver, nessa seção tratamos das implementações de testes e como desenvolvedores, chefes utilizam e aplicam a devida manutenção em bugs, erros encontrados. Também vimos como eles funcionam nos modelos XP e Cascata.