Usuário(a):Leandro Gregório/Testes

Capitulo 1

Seção 1.1

         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.

        

         Pilares da Engenharia de Software:

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:

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. 12 U1 - Fundamentos de Engenharia de software

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.

         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.

         A precária – e muitas vezes ignorada – comunicação entre cliente e equipe de desenvolvimento contribuía para que a qualidade do U1 - Fundamentos de Engenharia de software 13 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, 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.

         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.

Seção 1.2

         Ao resumirmos e agruparmos os muitos conceitos que a literatura disponibiliza, teremos 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.

         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:

         Fases: um conjunto de atividades afins e com objetivos bem definidos são realizados em uma fase do processo.

         Atividades ou tarefas: comumente descritas com conceitos semelhantes, uma atividade ou uma tarefa constitui um projeto em pequena escala.

         Em suas regras processuais, a organização pode determinar que seja adotado um documento que descreva a atividade. Há, no entanto, certos modelos de processos ditos prescritivos, que contêm descrições de como as atividades são realizadas. O modelo Cascata, também conhecido como modelo tradicional, é o mais conhecido e ainda bastante utilizado para desenvolvimento de produtos de software.

         Resumindo cada uma das fases:

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.

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á

Implementação: Nesta fase, o projeto é transformado em linguagem de programação para que, de fato, o produto passe a ser executável.

Testes: 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.

Manutenção:Os esforços de desenvolvimento de um software resultam na entrega de um produto que satisfaça os requisitos do usuário. Esperase, contudo, que o software sofra alterações e evolua.

Seção 1.3

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. Além das funcionalidades, eles relacionam-se também aos objetivos, restrições e padrões do sistema. São subetapas da fase de requisitos:

1. Levantamento de requisitos

         Schach (2008) aponta ações que devem nortear o trabalho de levantamento de requisitos. A primeira é determinar o que o cliente precisa, em vez do que o cliente quer. No entanto, é muito comum que os clientes não saibam do que precisam ou que tenham dificuldade em expressá-lo. É necessário também que o grupo destacado conheça o campo de aplicação. Por fim, é indispensável que o engenheiro de requisitos conheça as regras (ou modelo) de negócios do cliente. Trata-se da descrição dos processos que compõem o negócio da organização.

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.

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.

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.

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

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

I) Estabelece a base para a concordância entre clientes e fornecedores, naquilo que o software deve produzir;

II) 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;

Validação dos requisitos

         Como última etapa da fase do processo, a validação deve incidir sobre o documento de especificação.

         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.

         Uma maneira eficaz de validar os requisitos é pela prototipação. Trata-se da criação de versão simplificada de determinadas funções do sistema, indicada para capturar a real compreensão do engenheiro em relação aos requisitos levantados.

Projeto de software

         O projeto é o primeiro passo da fase de desenvolvimento de qualquer produto ou sistema de engenharia. Sua meta é produzir modelo ou representação do produto a ser construído.

         Projeto é o processo pelo qual os requisitos são traduzidos numa representação do software.

         O nível de detalhamento deve ser suficiente para permitir sua realização física e, de acordo com o modelo de processo tradicional, o projeto se inicia depois de levantados, analisados e especificados os requisitos.

Aspectos fundamentais de projeto

1. Abstração

         Solução modular leva a vários níveis de abstração. Abstrair é concentrar-se em certos aspectos relevantes ao ambiente do problema.

2. Abstração de dados

         Coleção de dados que descreve um objeto. Exemplo: contracheque contém o nome do beneficiado, quantia bruta, imposto de renda, contribuição sindical (conjunto de dados).

3. Modularidade:

         Divisão do software em componentes chamados módulos. Permite a administração intelectual do software, já que um grande software monolítico (composto por apenas um módulo) é praticamente incompreensível.

         Qualitativamente, a noção de qualidade passa pelos conceitos de coesão e acoplamento. De forma simplificada, coesão é o grau de interação dentro de um módulo e o acoplamento é o grau de interação entre dois módulos.

4. Procedimento de software:

         Focaliza os detalhes de processamento de cada módulo da hierarquia. O procedimento oferece especificação precisa do processamento do módulo.

Seção 1.4

Implementação de software

         Implementação é o processo de converter o projeto detalhado em código. Com as etapas anteriores de requisitos e projeto bem-sucedidas, a implementação tende a ser relativamente bem compreendida. Alguns pontos do processo devem ser alvo de atenção (SCHACH, 2008):

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

b) 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. A figura 1.3 mostra uma típica configuração de comunicação entre módulos de um programa. Uma 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.

Integração de software

         Integrar o software significa combinar em um todo os módulos construídos durante a implementação. A figura 1.3 mostra uma típica configuração de comunicação entre módulos de um programa. Uma 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.

Implantação de software

         A implantação é a última fase de desenvolvimento de um software. Embora deva sofrer alterações durante sua vida útil, espera-se que o software seja disponibilizado ao cliente em sua versão final. Destaca Rezende (2005), que o envolvimento do cliente deve ser buscado nesta fase assim como o foi nas fases anteriores do projeto e que, da mesma forma que em outras etapas do processo de desenvolvimento, a implantação requer gerenciamento, como será abordado na sequência

         a) Direta: o funcionamento do software antigo cessa assim que o novo entra em operação. Não há concomitância na operação dos dois;

         b) Paralela: os dois sistemas funcionam por um tempo em paralelo, com a base de dados atualizada em ambos. Neste caso, a segurança na implantação de sistema novo é maior;

         c) Piloto: neste caso, o sistema atual poderá refazer os processamentos feitos pelo antigo, para fins de comparação de resultados;

         d) Parcial ou por etapas: o funcionamento do novo sistema inclui apenas parte do antigo. As novas rotinas substituem aos poucos as antigas.

Manutenção de software

         Os esforços de desenvolvimento de um software devem resultar na entrega de um produto que satisfaça os requisitos do usuário. Adequadamente, espera-se 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.

Necessidade de manutenção

         A manutenção é necessária para assegurar que o software continuará a satisfazer os requisitos do usuário. O sistema se altera devido a ações corretivas e não corretivas aplicadas ao software. A manutenção deve ser executada a fim de corrigir falhas, melhorar o projeto, implementar melhorias, construir interface com outros sistemas, adaptar programas para que novas facilidades de hardware possam ser usadas, migrar software legado, retirar software de operação.

Categorias

         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 ou a manutenibilidade.

         Manutenção preventiva: modificação em um software após a entrega a fim de reparar falhas latentes antes que se tornem efetivas (IEEE, 2004).

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.

Capitulo 2

Seção 2.1

Desenvolvimento Ágil de Software (em inglês: Agile software development) ou Método ágil é uma disciplina que estuda um conjunto de comportamentos, processos, práticas e ferramentas utilizados para a criação de produtos (geralmente de, mas não limitados à, software) e sua subsequente disponibilização para os usuários finais. As metodologias e frameworks que fazem parte do conceito de desenvolvimento ágil (como o Scrum, por exemplo) providenciam uma estrutura conceitual para conduzir projetos de engenharia de software.

Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente cara a cara, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projetistas de iteração, redatores técnicos e gerentes.

Seção 2.2

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é considerada uma metodologia ágil pois se ajusta bem a pequenas e médias em desenvolvimento de software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

O XP possui algumas características marcantes que são:

·       Feedback constante.

·       Abordagem incremental.

·       Encoraja a comunicação entre as pessoas envolvidas.

Os cinco valores fundamentais são: comunicação, simplicidade, feedback, coragem e respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.

Seção 2.3

Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

·       Jogo de Planejamento: O desenvolvimento é feito em interações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento e nelas já devem estar criadas antecipadamente pelos usuários as User Stories (história dos usuários). Nessa reunião, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software.

·       Fases pequenas: A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.

·       Metáfora: Procura facilitar a comunicação com o cliente, entendendo a realidade dele. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

·       Design Simples: Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Código fácil deve ser identificado e substituído por código simples.

·       Testes de Aceitação: São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.

·       Semana de 40 horas: Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

·       Propriedade Coletiva: O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

·       Programação Pareada: é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

·       Padronização do Código: A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

·       Desenvolvimento Orientado a Testes: Primeiro crie os testes unitários e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

·       Refatoração: É um processo que permite a melhoria contínua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refatorar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte;

·       Integração Contínua: Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Seção 2.4

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

No Scrum, os projetos são divididos em ciclos 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.

·       Sprints: é o nome dado para os ciclos de cada projeto. Em geral são ciclos mensais e são determinados para que as tarefas sejam realizadas.

·       Product Backlog: é o nome dado para o conjunto de objetivos de um projeto. No caso de um projeto de desenvolvimento de software (para o qual o Scrum foi pensado inicialmente), é o nome dado ao pacote de funcionalidades a serem desenvolvidas em um projeto.

·       Sprint Planning Meeting: são reuniões periódicas que acontecem no início de cada sprint, ou ciclo, para planejar e priorizar os itens do Product Backlog que serão desenvolvidos naquele período.

·       Sprint Backlog: é como se chamam as tarefas específicas que serão realizadas e desenvolvidas em cada ciclo, ou sprint.

·       Daily Scrum: essa é uma reunião diária para acompanhamento do projeto. A ideia é que toda a equipe se reúna diariamente para discutir as atividades desenvolvidas, disseminar conhecimento, identificar impedimentos e priorizar o trabalho daquele dia. Um ponto interessante é que o Scrum propõe que estas reuniões sejam realizadas com os participantes em pé, exatamente para serem rápidas e objetivas.

·       Sprint Review Meeting: essa é a reunião que acontece ao final de cada sprint para que a equipe apresente o que foi realizado e os resultados do trabalho daquele ciclo. A ideia é que depois dessa etapa, todos sigam para o próximo ciclo.

Capitulo 3

Seção 3.1

Não se pode conceber um produto, qualquer que seja sua natureza, que não seja criado levando-se em conta sua qualidade. A busca por níveis satisfatórios e previamente definidos de excelência deve basear qualquer processo de fabricação em larga escala ou de manufatura, sob pena de se obter produto com baixa aceitação de mercado. O que é qualidade de software e por que ela é tão importante? Uma boa maneira de começarmos é afastando a ideia de que qualidade signifique perfeição, qualidade é uma propriedade, positiva ou negativa, de parte ou de todo o conjunto de um determinado produto, que aproxima ou afasta o mesmo do seu maior grau de excelência.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. 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. O “nível aceitável” de qualidade precisa ser o mais objetivo possível, extraído por meio de processos estruturados e ferramentas apropriadas de medição de qualidade. Uma das possíveis medidas de qualidade é, de fato, a adequação ao propósito, o que significa que o software funciona efetivamente de acordo com o que foi projetado.

Alguns indicadores que podem ajudar a classificar um software como sendo de qualidade são:

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

Seção 3.2

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. 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.A definição de SQA inclui a expressão “padrão planejado e sistemático de ações”.

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.

Seção 3.3

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.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. Nosso último item de estudo tratou de aspectos gerais da ISO 9001 e a colocou como um padrão geral para gestão da qualidade.  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, 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.

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.

Seção 3.4

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.É 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. É necessário que você tenha em mente um fato importante: existem métricas referenciais, usadas normalmente de forma padronizada pelos desenvolvedores.  No entanto, uma métrica pode ser baseada no objetivo da organização e na sua necessidade de informação para a tomada de uma decisão.Imagine que dois projetos de software – com alguma similaridade funcional entre eles – estejam em construção. Se você quiser saber qual dos dois projetos está sendo mais produtivo, você deve realizar a medição do tamanho do projeto e do esforço para produzi-lo. Contudo, sem uma métrica, a comparação não seria viável, tampouco útil (MOORTHY, 2013).

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.

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

Capitulo 4

Seção 4.1

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

         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

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. Entenda o conceito de entrada como o conjunto de dados necessários para a execução do programa. A saída esperada é o resultado de uma execução do programa ou função específica. Imagine que estejamos colocando sob teste um programa que valida datas inseridas pelo usuário. Um caso de teste possível seria (25/12/2016; válida). Ao receber a entrada 25/12/2016, o programa de validação de data deveria retornar “data válida”.

         • 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. Podemos assumir diferentes abordagens para definir o resultado da aplicação de um caso de teste específico. A mais comum define as seguintes opções (PINHEIRO, 2015):

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

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:

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

         Imagine o programa como uma caixa. Quando o testador não tem acesso ao código-fonte, ele está lidando com uma caixa preta, cujo interior não se consegue ver. Daí o teste funcional também ser conhecido como caixa preta. A técnica estrutural, por sua vez, é também conhecida como caixa branca, cujo interior se pode ver. Essa comparação é feita justamente pela disponibilidade do código-fonte e das estruturas internas do programa.

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

         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.

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ção 4.2

Engenharia de Testes

         Em nossa última seção, quando tratamos de temas iniciais de teste de software, foi dada ênfase às definições de defeito, erro e falha. Entre um exemplo e outro, o texto procurou deixar clara a sutileza entre os conceitos, sem que as diferenças entre os três se perdessem

         Em seções anteriores, foi discutida a impossibilidade de assegurar a completa e irrestrita ausência de erros em um programa, justamente pela condição falível dos programadores. Mas será que apenas os programadores falham?

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

         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

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.

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.

Seção 4.3

Teste de release é o processo de testes de uma versão particular de um sistema que se destina para uso fora da equipe de desenvolvimento.

O principal objetivo do processo de teste de release é convencer o cliente de que o sistema é bom o suficiente para o uso. Portanto, os testes de release precisam mostrar que o sistema oferece a funcionalidade, o desempenho e confiabilidade especificados, e que não falha durante o uso normal.

Geralmente, os testes de release são um processo de teste caixa‐preta, em que os testes são derivados somente a partir da especificação do sistema.

Testes de release são uma forma de teste do sistema.

Diferenças importantes: Uma equipe separada, sem envolvimento com o desenvolvimento do sistema, deve ser responsável pelos testes de release. Os testes de sistema realizados pela equipe de desenvolvimento devem se centrar na descoberta de bugs do sistema (teste de defeitos). O objetivo do teste de release é verificar se o sistema atende aos seus requisitos e é bom o suficiente para uso externo. (teste de validação).

Seção 4.4

Manutenção de Software

O objetivo do processo de Manutenção de sistema e software é modificar o produto de sistema/software depois de liberado, para corrigir falhas, melhorar desempenho ou outros atributos ou adaptar às mudanças do ambiente.

O objetivo é modificar e/ou aposentar os produtos de software/sistema existentes preservando a integridade das operações da organização.

As alterações ocorrem por diversas razões. As razões para as alterações determinam a categoria de manutenção.

Categorias de Manutenção

Identificar e Corrigir Erros > Manutenção Corretiva

Adaptar o Software ao Ambiente > Manutenção Adaptativa

Atender Pedidos do Usuário para Modificar Funções Existentes, Incluir Novas Funções e Efetuar Melhoramentos Gerais > Manutenção Perfectiva

Melhorar a manutenibilidade ou confiabilidade futuras e fornecer uma base melhor para futuros melhoramentos > Manutenção Preventiva

A Fase de Manutenção de Software

É a fase mais problemática do Ciclo de Vida de Software. Pode despender mais de 70% de todo esforço de uma Organização. Esses sistemas devem continuar rodando e as alterações são inevitáveis

Por que é exigida tanta Manutenção e por que é despendido tanto Esforço nessa atividade? Idade Média de 10 a 15 anos. Principal Interesse: Tamanho do Programa e Espaço de Armazenamento. Migração Para Novas Plataformas. Sistemas mal estruturados

Por que é exigida tanta Manutenção e por que é despendido tanto Esforço nessa atividade?

Melhoramentos Para Atender Novas Necessidades. Nenhuma preocupação com a Arquitetura Global. Codificação, Lógica e Documentação ruins.

Custo de Manutenção

Fora os custos monetários que vão estar sempre presentes.

Outros Custos não Monetários: Adiamento de oportunidades de desenvolvimento. Insatisfação do cliente q Redução da qualidade global do software. Insatisfação do pessoal de manutenção

O Custo de manutenção pode ser dividido em:  tentar entender o que o software faz, interpretar as estruturas de dados, as características de interface e limites de desempenho, analisar, avaliar, projetar, codificar e testar as modificações

Problemas da Manutenção

A maioria dos problemas com a manutenção do software é causada por deficiências na maneira como o software foi planejado e desenvolvido

É difícil ou impossível traçar a evolução do software em suas várias versões. As alterações não são adequadamente documentadas. É difícil ou impossível traçar o processo pelo qual o software foi criado.

É muito difícil entender programas "de outras pessoas". A dificuldade aumenta conforme o número de elementos na configuração de software diminui. "As outras pessoas" frequentemente não estão presentes para explicar.

A documentação não existe, é incompreensível ou está desatualizada. A maioria dos softwares não foram projetados para suportar alterações. A manutenção não é vista como um trabalho glamoroso

Manutenibilidade

A Manutenibilidade pode ser definida qualitativamente como a facilidade com que o software pode ser entendido, corrigido, adaptado e ou melhorado.