Resumo - UNIVESP - Engenharia de Software

Prévia do material em texto

<p>SOFTWARE</p><p>ENGENHARIA DE SOFTWARE</p><p>Programas de computador e documentação associada. Os produtos de software podem ser</p><p>desenvolvidos para um determinado cliente ou para um mercado genérico. O bom software</p><p>deve proporcionar a funcionalidade e o desempenho necessários e deve ser manutenível,</p><p>usável e com a dependabilidade (dependability). O desenvolvimento de diferentes tipos de</p><p>sistemas de software pode exigir diferentes técnicas de engenharia. O desenvolvimento de</p><p>software é uma atividade de engenharia.</p><p>Engenharia de</p><p>Software SEMANA 1</p><p>Conhecer os objetivos e principais conceitos da área de Engenharia de Software;</p><p>Conhecer os principais conceitos associados a modelos de processo de software, incluindo os principais</p><p>exemplos de modelos de processo;</p><p>Conhecer os principais conceitos associados aos métodos de desenvolvimento ágil.</p><p>é uma disciplina de engenharia que se preocupa com os aspectos da</p><p>produção de software, desde sua concepção inicial até sua operação e</p><p>manutenção e se preocupa com as questões práticas de desenvolver e</p><p>entregar software útil.</p><p>CARACTERÍSTICAS QUE OS PRODUTOS DE SOFTWARE DEVEM TER</p><p>ETAPAS DO PROCESSO DE</p><p>SOFTWARE</p><p>MODELOS DE PROCESSO</p><p>TIPOS DE PRODUTO DE SOFTWARE</p><p>a organização que desenvolve o software controla a sua especificação.</p><p>a especificação é desenvolvida e controlada pela organização que está comprando o software.</p><p>Aplicável em:</p><p>Exemplo: MODELO DE BOEHM</p><p>ENGENHARIA DE SOFTWARE ORIENTADA PARA REUSO</p><p>PROCESSO DE ENGENHARIA DE REQUISITOS</p><p>O processo de engenharia de requisitos (Figura</p><p>2.4) visa à produção de um documento de</p><p>requisitos acordados que especifique um</p><p>sistema que satisfaça os requisitos dos</p><p>stakeholders. Os requisitos são apresentados</p><p>normalmente em dois níveis de detalhe. Os</p><p>usuários finais e os clientes precisam de uma</p><p>declaração de requisitos mais superficial desse</p><p>sistema; os desenvolvedores, de uma</p><p>especificação mais detalhada.</p><p>MODELO GERAL DO PROCESSO DE PROJETO</p><p>ETAPA DE TESTES</p><p>MÉTODOS ÁGEIS</p><p>CARACTERÍSTICAS COMUNS:</p><p>TÉCNICAS DE DESENVOLVIMENTO ÁGIL</p><p>REQUISITOS DE SISTEMA</p><p>Definição:</p><p>Descrições do que o sistema/software</p><p>deve fazer, os serviços que ele oferece, as</p><p>restrições sobre seu funcionamento.</p><p>SCRUM</p><p>SEMANA 2</p><p>conhecer os principais conceitos associados aos tipos de requisitos.</p><p>conhecer o processo de engenharia de requisitos.</p><p>conhecer as atividades de elicitação, especificação e validação de requisitos.</p><p>Diferenças entre requisitos de usuário e sistema:</p><p>Alguns problemas durante o processo de engenharia de requisitos é a não diferenciação</p><p>entre os níveis de descrição.</p><p>Declaração abstrata</p><p>(alto nível)</p><p>Definição detalhada</p><p>(baixo nível)</p><p>TIPOS DE REQUISITOS</p><p>Declarações de serviços que o sistema deve fornecer.</p><p>✔ Declarações de como o sistema deve reagir às entradas específicas.</p><p>✔ Declarações de como o sistema deve se comportar em</p><p>determinadas situações.</p><p>✔ Declarações do que o sistema não deve fazer</p><p>Restrições aos serviços ou funções oferecidas pelo sistema.</p><p>✔ Incluem restrições de tempo, restrições no processo de</p><p>desenvolvimento e restrições impostas por normas.</p><p>✔ Geralmente, aplicam-se ao sistema como um todo</p><p>ENTREVISTAS</p><p>ETNOGRAFIA</p><p>SEMANA 3</p><p>conhecer os principais conceitos associados ao projeto de arquitetura de</p><p>sistemas de software.</p><p>conhecer os principais conceitos associados à refatoração de software..</p><p>Desempenho</p><p>Segurança da Informação</p><p>Segurança</p><p>Disponibilidade</p><p>Manutenibilidade</p><p>1.</p><p>2.</p><p>3.</p><p>4.</p><p>5.</p><p>PADRÕES DE ARQUITETURA</p><p>REFATORAÇÃO</p><p>quando</p><p>3</p><p>Refatore Quando Acrescentar Funções</p><p>Refatore Quando Precisar Consertar uma Falha</p><p>Refatore Enquanto Revisa o Código</p><p>Primeiro, o propósito da refatoração é tornar o</p><p>software mais fácil de entender e modificar. Somente</p><p>as mudanças feitas para tornar o software mais fácil</p><p>de entender são consideradas refatorações. Um</p><p>bom contraste é a otimização de desempenho. A</p><p>segunda coisa que quero destacar é que a</p><p>refatoração não altera o comporta- mento</p><p>observável do software.</p><p>Refatorar Melhora o Projeto do Software</p><p>Refatorar Torna o Software Mais Fácil de Entender</p><p>Refatorar Ajuda a Encontrar Falhas</p><p>Refatorar Ajuda a Programar mais Rapidamente</p><p>REFATORAR</p><p>Refatoração é algo que você faz todo o tempo em pequenas rajadas. Você</p><p>não decide refatorar, você re- fatora porque quer fazer alguma outra coisa</p><p>qualquer e refatorar ajuda a fazê-lo.</p><p>Na primeira vez em que faz algo, você apenas faz. Na segunda vez em que faz algo</p><p>parecido, você estremece diante da duplicação, mas a faz de qualquer forma. Na terceira</p><p>vez em que faz algo parecido, você refatora.</p><p>Regra</p><p>das</p><p>O que torna os programas difíceis de trabalhar? Posso pensar em quatro coisas en- quanto digito isto:</p><p>■ Programas que são difíceis de ler, são difíceis de modificar.</p><p>■ Programas que têm lógica duplicada, são difíceis de modificar.</p><p>■Programas que, para a inclusão de novas funcionalidades, requerem a alteração de código existente,</p><p>são difíceis de modificar.</p><p>■ Programas com lógicas condicionais complexas são difíceis de modificar.</p><p>Então, queremos programas que sejam fáceis de ler, que tenham toda a lógica especificada em um e</p><p>apenas um lugar, que não permitam que as alterações arrisquem o comportamento preexistente e que</p><p>permitam que lógica condicional seja expressa tão simplesmente quanto possível. Refatorar é o</p><p>processo de pegar um programa em produção e agregar a ele valor, não por meio da alteração de seu</p><p>comportamento mas dando a ele mais destas qualidades que nos permitem continuar desenvolvendo</p><p>rapidamente.</p><p>PROBLEMAS</p><p>Bancos de dados</p><p>A maioria das aplicações comerciais são altamente acopladas ao esquema do banco</p><p>de dados que as suporta. Esse é um motivo pelo qual bancos de dados são difíceis de</p><p>modificar.</p><p>Difícil refatorar bancos de dados.</p><p>Difícil refatorar interfaces de objetos.</p><p>Pode diminuir o desempenho do software.</p><p>Alterando Interfaces</p><p>Não há problema em mudar o nome de um método se você tem acesso a todo</p><p>o có- digo que chama esse método. Mesmo que o método seja público, desde</p><p>que você pos- sa alcançar e alterar os usuários desse método, você pode</p><p>renomeá-lo. Só há um pro- blema se a interface estiver sendo usada por</p><p>código que você não pode encontrar e al- terar. Quando isso acontece, digo</p><p>que a interface se torna uma interface publicada (um passo além de uma</p><p>interface pública).</p><p>Uma vez que você publique uma interface, não pode mais alterá-la com segurança e apenas modificar a</p><p>chamada nos métodos que a invocam. Você precisa de um processo um pouco mais complicado. Você</p><p>pode normalmente arranjar as coisas de modo que a interface antiga ainda funcione. Tente fazer isso de</p><p>uma maneira que a interface antiga chame a nova. Dessa forma, quando você alterar o nome de um</p><p>método, mantenha o antigo, e apenas deixe-o cha- mar o novo. Não copie o corpo do método – isso o</p><p>leva ao caminho da danação através da duplicação de código.Manter as antigas interfaces normalmente é</p><p>factível, mas é um tormento. Você de- ve construir e manter estes métodos extras, pelo menos durante</p><p>um certo tempo. Os métodos complicam a interface, tornando-a mais difícil de usar. Há uma alternativa:</p><p>Não publique a interface. Não estou falando de uma proibição total aqui, obviamente você tem que ter</p><p>interfaces publicadas. Se você estiver construindo</p><p>Alterações no Projeto Que São Difíceis de Refatorar</p><p>O exemplo básico é quando você deve reescrever a partir da estaca</p><p>zero. Há situações em que o código está tão confuso que, embora</p><p>você pudesse refatorá-lo, seria mais fácil recomeçar do princí- pio.</p><p>quando</p><p>NÃO REFATORAR</p><p>1. Extrair método</p><p>2. Internalizar método</p><p>3. Internalizar variável temporária</p><p>4. Substituir variável temporária por consulta</p><p>5. Introduzir variável explicativa</p><p>6. Dividir variável temporária</p><p>7. Remover atribuições a parâmetros</p><p>8. Substituir método por objeto método</p><p>9. Substituir o algoritmo</p><p>Métodos</p><p>1. Mover método</p><p>2. Mover campo</p><p>3. Extrair classe</p><p>4. Internalizar classe</p><p>5. Ocultar delegação</p><p>6. Remover intermediário</p><p>7. Introduzir método externo</p><p>8. Introduzir extensão local</p><p>Movendo recursos</p><p>entre</p><p>objetos</p><p>Organizando Dados</p><p>1. Autoencapsular campo</p><p>2. Substituir atributo por objeto</p><p>3. Mudar de valor para referência</p><p>4. Mudar de referência para valor</p><p>5. Substituir vetor por objeto</p><p>6. Duplicar dados observados</p><p>7. Transformar associação unidirecional em bidirecional</p><p>8. Transformar associação bidirecional em unidirecional</p><p>9. Substituir números mágicos por constantes</p><p>simbólicas</p><p>10. Encapsular campo</p><p>11. Encapsular coleção</p><p>12. Substituir registro por classe de dados</p><p>13. Substituir enumeração por classe</p><p>14. Substituir enumeração por subclasses</p><p>15. Substituir enumeração pelo padrão state/strategy</p><p>16. Substituir subclasse por campos</p><p>1. Decompor condicional</p><p>2. Consolidar expressão condicional</p><p>3. Consolidar fragmentos condicionais duplicados</p><p>4. Remover flag de controle</p><p>5. Substituir condição aninhada por cláusulas guarda</p><p>6. Substituir comando condicional por polimorfismo</p><p>7. Introduzir objeto nulo</p><p>8. Introduzir asserção</p><p>Simplificando</p><p>expressões condicionais</p><p>1. Renomear método</p><p>2. Acrescentar parâmetro</p><p>3. Remover parâmetro</p><p>4. Separar a pesquisa do modificador</p><p>5. Parametrizar método</p><p>6. Substituir parâmetro por métodos explícitos</p><p>7. Preservar o objeto inteiro</p><p>8. Substituir parâmetro por método</p><p>9. Introduzir objeto parâmetro</p><p>10. Remover método de gravação</p><p>11. Ocultar método</p><p>12. Substituir construtor por um método fábrica</p><p>13. Encapsular downcast</p><p>14. Substituir código de erro por exceção</p><p>15. Substituir exceção por teste</p><p>Tornando as chamadas de</p><p>métodos mais simples</p><p>1. Subir campo na hierarquia</p><p>2. Subir método na hierarquia</p><p>3. Subir o corpo do construtor na hierarquia</p><p>4. Descer método na hierarquia</p><p>5. Descer campo na hierarquia</p><p>6. Extrair subclasse</p><p>7. Extrair superclasse</p><p>8. Extrair interface</p><p>9. Condensar hierarquia</p><p>10. Criar um método padrão</p><p>11. Substituir herança por delegação</p><p>12. Substituir delegação por herança</p><p>Lidando com generalização</p><p>1. Desembaraçar herança</p><p>2. Converter projeto procedural em objetos</p><p>3. Separar o domínio da apresentação</p><p>4. Extrair hierarquia</p><p>Refatorações grandes</p><p>SEMANA 4</p><p>Conhecer os principais conceitos associados ao reúso de software;</p><p>Conhecer os principais conceitos associados a padrões de projeto;</p><p>Conhecer os principais conceitos associados a componentes de software.</p><p>Desenvolvimento acelerado</p><p>•Uso eficaz de especialistas</p><p>•Maior dependabilidade</p><p>•Custos de desenvolvimento mais baixos</p><p>•Menos risco para o processo</p><p>•Conformidade com os padrões</p><p>Criar, manter e usar uma biblioteca de</p><p>componentes</p><p>•Encontrar, entender e adaptar</p><p>componentes reusáveis</p><p>•Maiores custos de manutenção</p><p>•Falta de apoio da ferramenta</p><p>+ -</p><p>O QUE DEVE SER CONSIDERADO AO PLANEJAR O REÚSO</p><p>Projetar software orientado a objetos é difícil, mas projetar software reutilizável orientado a objetos é</p><p>ainda mais complicado. Você deve identificar objetos pertinentes, fatorá-los em classes no nível correto de</p><p>granularidade, definir as interfaces das classes, as hierarquias de herança e estabelecer as relações-chave</p><p>entre eles. O seu projeto deve ser específico para o problema a resolver, mas também genérico o</p><p>suficiente para atender problemas e requisitos futuros.</p><p>A abordagem MVC é composta por três tipos de objetos. O Modelo é o objeto de aplicação, a Visão é a</p><p>apresentação na tela e o Controlador é o que define a maneira como a interface do usuário reage às</p><p>entradas do mesmo.</p><p>A abordagem MVC separa Visão e Modelos pelo estabelecimento de um protocolo do tipo</p><p>inserção/notificação (subscribe/notify) entre eles. Uma visão deve garantir que a sua aparência reflita o</p><p>estado do modelo. Sempre que os dados do modelo mudam, o modelo notifica as visões que dependem</p><p>dele. Em resposta, cada visão tem a oportunidade de atualizar-se. Esta abordagem permite ligar</p><p>múltiplas visões a um modelo para fornecer diferentes apresentações. Da mesma forma, você também</p><p>pode criar novas visões para um modelo sem ter de reescrevê-lo.</p><p>Os padrões de projeto tornam mais fácil reutilizar projetos e arquiteturas bem- sucedidas. Expressar</p><p>técnicas testadas e aprovadas as torna mais acessíveis para os desenvolvedores de novos sistemas. Os</p><p>padrões de projeto ajudam a escolher alternativas de projeto que tornam um sistema reutilizável e a evitar</p><p>alternativas que comprometam a reutilização. Os padrões de projeto podem melhorar a documentação e</p><p>a manutenção de sistemas ao fornecer uma especificação explícita de interações de classes e objetos e o</p><p>seu objetivo subjacente. Em suma, ajudam um projetista a obter mais rapidamente um projeto adequado.</p><p>Nenhum dos padrões de projeto descreve projetos novos ou não-testados</p><p>PADRÕES DE PROJETO</p><p>Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum</p><p>para torná-la útil para a criação de um projeto orientado a objetos reutilizável. O padrão de projeto</p><p>identifica as classes e instâncias participantes, seus papéis, colaborações e a distribuição de</p><p>responsabilidades. Cada padrão de projeto focaliza um problema ou tópico particular de projeto orientado</p><p>a objetos. Ele descreve em que situação pode ser aplicado, se ele pode ser aplicado em função de outras</p><p>restrições de projeto e as conseqüências, custos e benefícios de sua utilização.</p><p>3. A solução descreve os elementos que compõem o padrão de projeto, seus relacionamentos,</p><p>suas responsabilidades e colaborações. A solução não descreve um projeto concreto ou uma</p><p>implementação em particular porque um padrão é como um gabarito que pode ser aplicado em muitas</p><p>situações diferentes. Em vez disso, o padrão fornece uma descrição abstrata de um problema de projeto e</p><p>de como um arranjo geral de elementos (classes e objetos, no nosso caso) o resolve.</p><p>4. As conseqüências são os resultados e análises das vantagens e desvantagens (trade-offs) da</p><p>aplicação do padrão. Embora as conseqüências sejam raramen- te mencionadas quando descrevemos</p><p>decisões de projeto, elas são críticas para a avaliação de alternativas de projetos e para a compreensão</p><p>dos custos e benefícios da aplicação do padrão. As conseqüências para o software freqüentemente</p><p>envolvem balanceamento entre espaço e tempo. Elas também podem abordar aspectos sobre lingua-</p><p>gens e implementação. Uma vez que a reutilização é freqüentemente um fator no projeto orientado a</p><p>objetos, as conseqüências de um padrão incluem o seu impacto sobre a flexibilidade, a extensibilidade ou</p><p>a portabilidade de um sistema. Relacionar essas conseqüências explicitamente ajuda a compreendê-las e</p><p>avaliá-las.</p><p>Um padrão de projeto tem quatro elementos essenciais:</p><p>1. O nome do padrão é uma referência que podemos usar para descrever um problema de projeto, suas</p><p>soluções e conseqüências em uma ou duas pala- vras. Dar nome a um padrão aumenta imediatamente o</p><p>nosso vocabulário de projeto. Isso nos permite projetar em um nível mais alto de abstração. Ter um</p><p>vocabulário para padrões permite-nos conversar sobre eles com nossos colegas, em nossa documentação</p><p>e até com nós mesmos. O nome torna mais fácil pensar sobre projetos e a comunicá-los, bem como os</p><p>custos e benefícios envolvidos, a outras pessoas. Encontrar bons nomes foi uma das partes mais difíceis</p><p>do desenvolvimento do nosso catálogo.</p><p>2. O problema descreve em que situação aplicar o padrão. Ele explica o problema e seu contexto.</p><p>Pode descrever problemas de projeto específicos, tais como representar algoritmos como objetos. Pode</p><p>descrever estruturas de classe ou objeto sintomáticas de um projeto inflexível. Algumas vezes, o problema</p><p>incluirá uma lista de condições que devem ser satisfeitas para que faça sentido aplicar o padrão.</p><p>O primeiro critério, chamado finalidade, reflete o que um padrão faz. Os padrões podem ter</p><p>finalidade de criação, estrutural ou comportamental. Os padrões de criação se preocupam com o</p><p>processo de criação de objetos. Os padrões estruturais lidam com a composição de classes ou de</p><p>objetos. Os padrões comportamentais caracterizam as maneiras pelas quais classes ou objetos</p><p>interagem e distribuem responsabilidades.</p><p>O segundo critério, chamado escopo, especifica se o padrão se aplica primari- amente a classes</p><p>ou a</p><p>objetos. Os padrões para classes lidam com os relacionamentos entre classes e suas subclasses. Esses</p><p>relacionamentos são estabelecidos através do mecanismo de herança, assim eles são estáticos –</p><p>fixados em tempo de compilação. Os padrões para objetos lidam com relacionamentos entre objetos</p><p>que podem ser mudados em tempo de execução e são mais dinâmicos.</p><p>Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum</p><p>para torná-la útil para a criação de um projeto orientado a objetos reutilizável. O padrão de projeto</p><p>identifica as classes e instâncias participan- tes, seus papéis, colaborações e a distribuição de</p><p>responsabilidades. Cada padrão de projeto focaliza um problema ou tópico particular de projeto</p><p>orientado a objetos. Ele descreve em que situação pode ser aplicado, se ele pode ser aplicado em função</p><p>de outras restrições de projeto e as conseqüências, custos e benefícios de sua utilização.</p><p>Sobre critérios de um padrao:</p><p>Um padrão de projeto descreve um problema e o cerne</p><p>da sua solução (em OO), de forma que possa ser</p><p>reusado, fazendo os ajustes necessários para cada caso</p><p>Quase todos utilizam a herança em certa medida. Note que a maioria está no escopo de Objeto. Os</p><p>padrões de criação voltados para classes deixam alguma parte da criação de objetos para subclasses,</p><p>enquanto que os padrões de criação voltados para objetos postergam esse processo para outro objeto.</p><p>Os padrões estruturais voltados para classes utilizam a herança para compor classes, enquanto que os</p><p>padrões estruturais voltados para objetos descrevem maneiras de montar objetos. Os padrões comporta-</p><p>mentais voltados para classes usam a herança para descrever algoritmos e fluxo de controle, enquanto</p><p>que os voltados para objetos descrevem como um grupo de objetos coopera para executar uma tarefa</p><p>que um único objeto não pode executar sozinho.</p><p>FRAMEWORK</p><p>SCM</p><p>SEMANA 5</p><p>conhecer os principais conceitos associados a estratégias de teste de</p><p>software.</p><p>conhecer os principais conceitos associados ao teste funcional.</p><p>conhecer os principais conceitos associados ao teste estrutural.</p><p>GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE</p><p>é uma atividade de apoio aplicada a toda a gestão da qualidade. As atividades de SCM são</p><p>desenvolvidas para (1) identificar a alteração, (2) controlar a alteração, (3) assegurar que a</p><p>alteração esteja sendo implementada corretamente e (4) relatar as alterações a outros envolvidos.</p><p>Elementos de componente.</p><p>Conjunto de ferramentas acopladas</p><p>em um sistema de gestão de</p><p>arquivos (p. ex., um banco de dados)</p><p>que possibilita acesso à gestão de</p><p>cada item de configuração de</p><p>software.</p><p>Elementos de processo. Coleção de</p><p>procedimentos e tarefas que definem</p><p>uma abordagem eficaz de gestão de</p><p>alterações (e atividades relacionadas)</p><p>para todas as partes envolvidas na</p><p>gestão, engenharia e uso do</p><p>software.</p><p>Elementos de construção. Conjunto de ferramentas que automatizam a construção do software, assegurando que tenha</p><p>sido montado o conjunto apropriado de componentes validados (i.e., a versão correta).</p><p>Elementos humanos. Conjunto de ferramentas e características de processo (abrangendo outros elementos de CM)</p><p>usado pela equipe de software para implementar um SCM eficaz.</p><p>Gerenciamento de configuração é um conjunto de atividades de rastreamento e controle iniciadas</p><p>quando um projeto de engenharia de software começa e terminadas apenas quando o software sai de</p><p>operação.</p><p>Um dos principais objetivos da engenharia de software é incrementar a facilidade com que as alterações</p><p>podem ser acomodadas e reduzir o esforço necessário quando alterações tiverem de ser feitas.</p><p>O processo de software resulta em informações que podem ser divididas em três categorias principais:</p><p>(1) programas de computador (tanto na forma de código-fonte quanto na forma executável), (2) produtos</p><p>que descrevem os programas de computador (focados em vários envolvidos) e (3) dados ou conteúdo</p><p>(contidos nos programas ou externos a ele).</p><p>À medida que o trabalho de engenharia de software avança, cria-se uma hierarquia de itens de</p><p>configuração de software (SCIs, do inglês software configuration items).</p><p>O papel do gerente de configuração garantir que sejam seguidos os procedimentos e</p><p>políticas para criar, alterar e testar o código, bem como tornar acessíveis as informações</p><p>sobre o projeto. Para implementar técnicas para manter controle sobre as mudanças de</p><p>código, esse gerente introduz mecanismos para fazer solicitações oficiais de alterações,</p><p>avaliar as alterações propostas junto à equipe de desenvolvimento e garantir que as</p><p>mudanças sejam aceitáveis para o product owner. Além disso, o gerente coleta dados</p><p>estatísticos sobre os componentes do sistema de software, como, por exemplo,</p><p>informações determinando quais componentes do sistema são problemáticos.</p><p>Como o produto está sob o controle da gestão de configuração (CM, do inglês configuration</p><p>management), o cliente segue procedimentos formais para solicitar alterações e para indicar erros no</p><p>produto.</p><p>No caso ideal, um sistema de CM usado nesse cenário deveria suportar todos esses papéis e tarefas; isto</p><p>é, os papéis determinam a funcionalidade exigida para um sistema de CM. O gerente de projeto vê a CM</p><p>como um mecanismo de auditoria; o gerente de configuração a vê como um mecanismo de controle,</p><p>rastreamento e criador de políticas; o engenheiro de software a vê como um mecanismo de alteração,</p><p>criação e controle de acesso; e o cliente a vê como um mecanismo de garantia de qualidad</p><p>Uma referência é um conceito de gerenciamento de configuração de software que ajuda a controlar</p><p>alterações sem obstruir seriamente as alterações justificáveis. Uma especificação ou produto que tenha</p><p>sido formalmente revisado e acordado, que depois serve de base para mais desenvolvimento e pode ser</p><p>alterado somente por meio de procedimentos formais de controle de alteração.</p><p>Para que um item de configuração de software se torne uma referência para o desenvolvimento, as</p><p>alterações devem ser feitas rápida e informalmente. No entanto, uma vez estabelecida uma referência,</p><p>podem ser feitas alterações, mas deve ser aplicado um processo específico e formal para avaliar e verificar</p><p>cada alteração.</p><p>REFERÊNCIAS</p><p>ITENS DE CONFIGURAÇÃO DE SOFTWARE</p><p>GESTÃO DE DEPENDÊNCIAS E RASTREABILIDADE</p><p>A matriz de rastreabilidade é um modo de documentar dependências entre requisitos, decisões de</p><p>arquitetura e causas de defeito. Essas dependências precisam ser levadas em conta ao se determinar o</p><p>impacto de uma alteração proposta e orientar a escolha dos casos de teste que devem ser usados para</p><p>teste de regressão. Segundo de Sousa e Redmiles, ver a gestão de dependências como gestão de</p><p>impacto3 ajuda os desenvolvedores a se concentrarem no modo como as alterações feitas afetam seu</p><p>trabalho.</p><p>A análise de impacto se concentra no comportamento organizacional e nas ações individuais. A gestão</p><p>de impacto envolve dois aspectos complementares: (1) garantir que os desenvolvedores de</p><p>software empreguem estratégias para minimizar o impacto das ações de seus colegas em seu próprio</p><p>trabalho; e (2) estimular os desenvolvedores de software a usar práticas que minimizem o impacto de seu</p><p>trabalho no de seus colegas. É importante observar que, quando um desenvolvedor tenta minimizar o</p><p>impacto de seu trabalho sobre o de outros, ele também está diminuindo o trabalho necessário para</p><p>minimizar o impacto de seu próprio trabalho no deles.</p><p>REPOSITÓRIO DE SCM</p><p>Um item de configuração de software é uma informação</p><p>criada como parte do processo de engenharia de software.</p><p>Em um caso extremo, um SCI poderia ser considerado</p><p>uma única seção de uma grande especificação ou um caso</p><p>de teste em um grande conjunto de testes. Os SCIs são</p><p>organizados para formar objetos de configuração que</p><p>podem ser catalogados no banco de dados do projeto</p><p>com um nome único. Um objeto de configuração tem um</p><p>nome, atributos e é “conectado” a outros objetos por</p><p>relações.</p><p>Para suportar o SCM, o repositório deve ser capaz de</p><p>manter SCIs relacionados a muitas versões diferentes</p><p>do</p><p>software. Mais importante ainda, deve fornecer os</p><p>mecanismos para montagem desses SCIs em uma</p><p>configuração específica da versão. O conjunto de</p><p>ferramentas do repositório deve oferecer suporte para</p><p>as características a seguir.</p><p>Versões.</p><p>Acompanhamento de dependências e</p><p>gestão de alterações.</p><p>Controle de requisitos.</p><p>Gestão de configuração.</p><p>Pistas de auditoria.</p><p>O controle de versão combina procedimentos e ferramentas para gerenciar diferentes versões dos</p><p>objetos de configuração criados durante o processo de software. Um sistema de controle de versão</p><p>implementa ou está diretamente integrado a quatro recursos principais: (1) um banco de dados de</p><p>projeto (repositório) que armazena todos os objetos de configuração relevantes; (2) um recurso de</p><p>gestão de versão que armazena todas as versões de um objeto de configuração (ou permite que</p><p>qualquer versão seja construída usando diferenças das versões anteriores); (3) uma facilidade de</p><p>construir que permite coletar todos os objetos de configuração relevantes e construir uma versão</p><p>específica do software. Além disso, os sistemas de controle de versão e controle de alteração muitas</p><p>vezes implementam um recurso chamado acompanhamento de tópicos (também conhecido como</p><p>acompanhamento de bug), que permite à equipe de software registrar e acompanhar o status de todos</p><p>os problemas pendentes associados a cada objeto de configuração.</p><p>Alguns conjuntos de modificações que receberam denominação podem ser identificados para uma</p><p>aplicação ou sistema. Isso permite construir uma versão do software especificando os conjuntos de</p><p>modificações (pelo nome) que devem ser aplicados à configuração referencial. Para isso, aplica-se uma</p><p>abordagem de modelagem de sistema. O modelo de sistema contém: (1) um gabarito que inclui</p><p>hierarquia de componentes e uma “ordem de construção” para os componentes, descrevendo como o</p><p>sistema deve ser construído; (2) regras de construção; e (3) regras de verificação.</p><p>CONTROLE DE VERSÃO</p><p>As melhores práticas do SCM incluem: (1) minimizar o número de variantes de código; (2) testar desde o</p><p>início e com frequência; (3) integrar desde o início e com frequência; e (4) usar ferramentas para</p><p>automatizar o teste, a construção e a integração do código. A integração contínua (CI, do inglês</p><p>continuous integration) é importante para os desenvolvedores ágeis que seguem o fluxo de trabalho do</p><p>DevOps. A CI também agrega valor ao SCM ao garantir que todas as alterações são imediatamente</p><p>integradas ao código-fonte do projeto, compiladas e testadas automaticamente. A CI oferece às equipes</p><p>de desenvolvimento diversas vantagens concretas, como: feedback acelerado, menor risco, maior</p><p>qualidade e melhores relatórios.</p><p>INTEGRAÇÃO CONTÍNUA</p><p>O processo de gestão de alterações de software define uma série de tarefas que têm quatro objetivos</p><p>principais: (1) identificar todos os itens que coletivamente definem a configuração do software; (2)</p><p>gerenciar alterações de um ou mais desses itens; (3) facilitar a construção de diferentes versões de uma</p><p>aplicação; e (4) assegurar que a qualidade do software seja mantida à medida que a configuração evolui</p><p>com o tempo.</p><p>Como uma equipe de software identifica os elementos discretos de uma configuração de software?</p><p>Como uma organização lida com as várias versões de um programa (e sua documentação) de maneira que</p><p>venha a permitir que a alteração seja acomodada eficientemente?</p><p>Como uma organização controla alterações antes e depois que o software é entregue ao cliente?</p><p>Como uma organização avalia o impacto das alterações e gerencia o impacto efetivamente?</p><p>Quem tem a responsabilidade de aprovar e classificar as alterações solicitadas?</p><p>Como podemos assegurar que as alterações foram feitas corretamente?</p><p>Qual mecanismo é usado para alertar outras pessoas sobre as alterações feitas?</p><p>A partir dessas questões, são definidas cinco tarefas SCM:</p><p>As tarefas SCM podem ser vistas como camadas</p><p>concêntricas. Os SCIs fluem para fora através dessas</p><p>camadas por toda a sua vida útil, tornando-se, por fim,</p><p>parte da configuração do software de uma ou mais</p><p>versões da aplicação ou sistema.</p><p>Controle de Alterações</p><p>Gestão de Impacto</p><p>Primeiro, uma rede de impacto identifica os membros de uma equipe de</p><p>software (e outros envolvidos) que podem afetar ou ser afetados pelas</p><p>alterações feitas no software. Uma definição clara da arquitetura do</p><p>software (Capítulo 10) ajuda muito na criação de uma rede de impacto. Em</p><p>seguida, a gestão de impacto adiante (forward impact management) avalia</p><p>o impacto das alterações feitas por você sobre os membros da rede de</p><p>impacto e, então, informa-os sobre o impacto dessas alterações. Por</p><p>último, a gestão de impacto retroativo (backward impact management)</p><p>examina as alterações feitas por outros membros da equipe e o impacto</p><p>sobre o seu trabalho e incorpora mecanismos para reduzir o impacto.</p><p>O relatório de status de configuração (CSR, do inglês configuration status</p><p>reporting) (às vezes chamado de contabilidade de status) é uma tarefa do</p><p>SCM que responde às seguintes questões: (1) O que aconteceu? (2) Quem</p><p>fez? (3) Quando aconteceu? (4) O que mais será afetado?</p><p>Relatório de Status</p><p>Uma auditoria de configuração de software complementa a revisão técnica avaliando o objeto de configuração quanto</p><p>a características que em geral não são consideradas durante a revisão. A auditoria propõe e responde às seguintes</p><p>questões:</p><p>Foi feita a alteração especificada na ECO? Alguma modificação adicional foi incorporada?</p><p>Foi feita uma revisão técnica para avaliar a exatidão técnica?</p><p>Seguiu-se o processo do software, e os padrões de engenharia de software foram aplicados adequadamente?</p><p>A alteração foi “destacada” no SCI? A data e o autor da alteração foram especificados? Os atributos do objeto de</p><p>configuração refletem a alteração?</p><p>Seguiram-se os procedimentos do SCM para anotar, registrar e relatar a alteração?</p><p>Todos os SCIs relacionados foram adequadamente atualizados?</p><p>Auditoria de Configuração</p><p>CONTROLE ELETRÔNICO DE ALTERAÇÕES</p><p>Classe 1. Alteração de conteúdo ou função</p><p>que corrige um erro ou melhora o conteúdo</p><p>ou a funcionalidade local.</p><p>Classe 2. Alteração de conteúdo ou função</p><p>que tenha impacto sobre outros objetos de</p><p>conteúdo ou sobre os componentes</p><p>funcionais.</p><p>Classe 3. Alteração de conteúdo ou função</p><p>que tenha um amplo impacto em uma</p><p>aplicação (p. ex., extensão ou funcionalidade</p><p>principal, melhora significativa ou redução em</p><p>conteúdo, alterações importantes necessárias</p><p>na navegação).</p><p>Classe 4. Uma alteração importante</p><p>de projeto (p. ex., alteração na</p><p>abordagem de projeto da interface</p><p>ou na estratégia de navegação) que</p><p>será notada imediatamente por uma</p><p>ou mais categorias de usuário.</p><p>GESTÃO DE CONTEÚDO</p><p>Um repositório central para o projeto de jogo ou aplicativo deve ser estabelecido. O repositório terá as</p><p>versões atuais de todos os objetos de configuração (conteúdo, componentes funcionais e outros).</p><p>Cada desenvolvedor Web cria sua própria pasta de trabalho. A pasta contém os objetos que estão</p><p>sendo criados ou alterados em determinado instante.</p><p>Os relógios das estações de trabalho de todos os desenvolvedores devem estar sincronizados. Isso é</p><p>feito para evitar conflitos de sobrescrita, quando dois desenvolvedores fazem alterações em horários</p><p>muito próximos.</p><p>À medida que novos objetos de configuração são desenvolvidos ou objetos existentes são alterados,</p><p>são importados para o repositório central. A ferramenta de controle de versão vai gerenciar todas as</p><p>funções de entrada (check-in) e saída (check-out) das pastas de trabalho de cada desenvolvedor. A</p><p>ferramenta também fornecerá atualizações automáticas de e-mail a todas as partes envolvidas quando</p><p>forem feitas alterações no repositório.</p><p>À medida que objetos são importados ou exportados do repositório, é gerada uma mensagem</p><p>automática com data e hora. Isso proporciona informações úteis para auditoria e pode se tornar parte</p><p>de um esquema eficaz de relatórios.</p><p>1.</p><p>2.</p><p>3.</p><p>4.</p><p>5.</p><p>CONTROLE DE VERSÃO</p><p>TESTE DE SOFTWARE</p><p>A gestão de conteúdo está relacionada à</p><p>gestão de configuração no sentido</p><p>de que</p><p>um sistema de gestão de conteúdo (CMS,</p><p>do inglês content management system)</p><p>estabelece um processo (suportado por</p><p>ferramentas apropriadas) que adquire o</p><p>conteúdo existente (de uma ampla</p><p>variedade de objetos de configuração de</p><p>jogos e/ou aplicativos), estrutura esse</p><p>conteúdo de maneira que ele possa ser</p><p>apresentado a um usuário e, então,</p><p>fornece-o ao ambiente no lado do cliente</p><p>para ser exibido.</p><p>O uso mais comum de um sistema de</p><p>gestão de conteúdo ocorre quando é criada</p><p>uma aplicação dinâmica</p><p>O software é testado para revelar erros cometidos inadvertidamente quando ele foi projetado e</p><p>construído. Uma estratégia de teste de componentes de software considera o teste de componentes</p><p>individuais e a sua integração a um sistema em funcionamento.</p><p>O teste de software é um elemento de um tema mais amplo, muitas vezes conhecido como verificação e</p><p>validação (V&V). Verificação refere-se ao conjunto de tarefas que garantem que o software implemente</p><p>corretamente uma função específica. Validação refere-se ao conjunto de tarefas que asseguram que o</p><p>software foi criado e pode ser rastreado segundo os requisitos do cliente.</p><p>De um ponto de vista procedimental, o teste dentro do contexto de engenharia de software é, na realidade,</p><p>uma série de quatro etapas implementadas sequencialmente. Inicialmente, os testes focalizam cada</p><p>componente individualmente, garantindo que ele funcione adequadamente como uma unidade. Daí o</p><p>nome teste de unidade. O teste de unidade usa intensamente técnicas de teste, com caminhos específicos</p><p>na estrutura de controle de um componente para garantir a cobertura completa e a máxima detecção de</p><p>erros. Em seguida, o componente deve ser montado ou integrado para formar o pacote de software</p><p>completo. O teste de integração cuida de problemas associados a aspectos duais de verificação e</p><p>construção de programa. Técnicas de projeto de casos de teste que focalizam entradas e saídas são mais</p><p>predominantes durante a integração, embora técnicas que usam caminhos específicos de programa</p><p>possam ser utilizadas para segurança dos principais caminhos de controle. Depois que o software foi</p><p>integrado (construído), é executada uma série de testes de ordem superior. Os critérios de validação</p><p>(estabelecidos durante a análise de requisitos) devem ser avaliados. O teste de validação proporciona a</p><p>garantia final de que o software satisfaz a todos os requisitos funcionais, comportamentais e de</p><p>desempenho. A última etapa de teste de ordem superior extrapola os limites da engenharia de software,</p><p>entrando em um contexto mais amplo de engenharia de sistemas de computadores</p><p>O teste de unidade começa no centro da espiral</p><p>e se concentra em cada unidade (p. ex.,</p><p>componente, classe ou objeto de conteúdo de</p><p>WebApp) do software, conforme implementado</p><p>no código-fonte. O teste prossegue movendo-se</p><p>em direção ao exterior da espiral, passando</p><p>pelo teste de integração, em que o foco está no</p><p>projeto e na construção da arquitetura de</p><p>software. Continuando na mesma direção da</p><p>espiral, encontramos o teste de validação, em</p><p>que requisitos estabelecidos como parte dos</p><p>requisitos de modelagem são validados em</p><p>relação ao software criado. Por fim, chegamos</p><p>ao teste do sistema, no qual o software e outros</p><p>elementos são testados como um todo. Para</p><p>testar um software de computador, percorre-se</p><p>a espiral em direção ao seu exterior, ao longo</p><p>de linhas que indicam o escopo do teste a cada</p><p>volta.</p><p>O objetivo do teste de software é descobrir erros. Para o software convencional, esse objetivo é atingido</p><p>com uma série de etapas de teste. Testes de unidade e de integração (discutidos no Capítulo 20)</p><p>concentram-se na verificação funcional de um componente e na incorporação dos componentes na</p><p>arquitetura de software. A estratégia para teste de software orientado a objetos começa com testes que</p><p>exercitam as operações dentro de uma classe e depois passa para o teste baseado em sequências de</p><p>execução para integração (discutido na Seção 20.4.1). Sequências de execução são conjuntos de classes</p><p>que respondem a uma entrada ou a um evento.</p><p>Os testes caixa-branca focam na estrutura de controle do programa. São criados casos de teste para</p><p>assegurar que todas as instruções do programa foram executadas pelo menos uma vez durante o teste</p><p>e que todas as condições lógicas foram exercitadas. O teste de caminho base, uma técnica caixa-branca,</p><p>usa diagramas de programa (ou matrizes de grafo) para derivar o conjunto de testes linearmente</p><p>independentes que garantirão a cobertura. O teste de condições e de fluxo de dados exercita mais a</p><p>lógica do programa, e o teste de ciclos complementa outras técnicas caixa-branca, fornecendo um</p><p>procedimento para exercitar ciclos com vários graus de complexidade.</p><p>TESTE CAIXA BRANCA</p><p>Teste de Caminho Básico: permite ao</p><p>projetista de casos de teste derivar uma</p><p>medida da complexidade lógica de um</p><p>projeto procedimental e usar essa</p><p>medida como guia para definir um</p><p>conjunto-base de caminhos de</p><p>execução. Casos de teste criados para</p><p>exercitar o conjunto-base executam</p><p>com certeza todas as instruções de um</p><p>programa pelo menos uma vez durante</p><p>o teste.</p><p>Teste de Estrutura de Controle: O teste de ciclo é</p><p>uma técnica de teste caixa-branca que se concentra</p><p>exclusivamente na validade das construções de ciclo.</p><p>TESTE CAIXA PRETA</p><p>Teste de Interface: uilizado para verificar que o componente do programa aceita informações</p><p>repassadas na ordem apropriada e nos tipos de dados apropriados e retorna informações na ordem e no</p><p>formato de dados apropriados [Jan16]. O teste de interface costuma ser considerado parte do teste de</p><p>integração.</p><p>Os testes caixa-preta são projetados para validar requisitos funcionais sem levar em conta o</p><p>funcionamento interno de um programa. As técnicas caixa-preta focam o domínio de informações do</p><p>software, derivando casos de teste e particionando o domínio de entrada e saída de um programa de</p><p>forma a proporcionar uma ampla cobertura do teste. O particionamento de equivalência divide o domínio</p><p>de entrada em classes de dados que tendem a usar uma função específica do software. A análise de valor</p><p>limite investiga a habilidade do programa para manipular dados nos limites do aceitável. Chamado de</p><p>teste comportamental ou teste funcional, focaliza os requisitos funcionais do software. As técnicas de</p><p>teste caixa-preta permitem derivar séries de condições de entrada que utilizarão completamente todos os</p><p>requisitos funcionais para um programa. O teste caixa-preta não é uma alternativa às técnicas caixa-</p><p>branca. Em vez disso, é uma abordagem complementar, com possibilidade de descobrir uma classe de</p><p>erros diferente daquela obtida com métodos caixa-branca.</p><p>O teste caixa-preta tenta encontrar erros nas seguintes categorias: (1) funções incorretas ou ausentes; (2)</p><p>erros de interface; (3) erros em estruturas de dados ou acesso a bases de dados externas; (4) erros de</p><p>comportamento ou de desempenho; e (5) erros de inicialização e término.</p><p>Diferentemente do teste caixa-branca, que é executado antecipadamente no processo de teste, o teste</p><p>caixa-preta tende a ser aplicado durante estágios posteriores do teste. Devido ao teste caixa-preta</p><p>propositadamente desconsiderar a estrutura de controle, a atenção é focalizada no domínio das</p><p>informações.</p><p>Se uma condição de entrada especifica um intervalo, são definidas uma classe de equivalência válida e</p><p>duas classes de equivalência inválidas.</p><p>Se uma condição de entrada exige um valor específico, são definidas uma classe de equivalência válida</p><p>e duas classes de equivalência inválidas.</p><p>Se uma condição de entrada especifica um membro de um conjunto, são definidas uma classe de</p><p>equivalência válida e uma classe de equivalência inválida.</p><p>Se uma condição de entrada for booleana, são definidas uma classe válida e uma inválida.</p><p>Particionamento de equivalência: é um método de teste caixa-preta que divide o domínio de entrada</p><p>de um programa em classes de dados a partir das quais podem ser criados casos de teste. Um caso de</p><p>teste ideal descobre, sozinho, uma classe de erros (p. ex., processamento incorreto de</p><p>componentes do sistema são responsáveis pela</p><p>degradação de desempenho?</p><p>4. Qual o tempo médio de resposta para usuários sob</p><p>uma variedade de condições de carga?</p><p>5. A degradação do desempenho tem um impacto sobre</p><p>a segurança do sistema?</p><p>6. A confiabilidade ou precisão do aplicativo é afetada</p><p>quando a carga no sistema aumenta?</p><p>7. O que acontece quando são aplicadas cargas maiores</p><p>do que a capacidade máxima do servidor?</p><p>8. A degradação de desempenho tem impacto sobre os</p><p>lucros da empresa?</p><p>CARACTERÍSTICAS BÁSICAS DAS TÉCNICAS DE TESTE DE DESEMPENHO:</p><p>TESTES DE</p><p>SEGURANÇA</p><p>Todo sistema com informações sigilosas, ou cujo acesso possa causar</p><p>prejuízos/benefícios, é alvo para acesso impróprio ou ilegal</p><p>O desenvolvedor deve tornar o custo da invasão maior do que o valor das</p><p>informações que poderiam ser obtidas.</p><p>Motivação para invasão: Hackers que tentam</p><p>invadir sistemas por diversão; Funcionários</p><p>desgostosos que tentam invadir por vingança;</p><p>Indivíduos desonestos que tentam invadir para obter</p><p>ganhos pessoais ilícitos; Concorrentes desonestos;</p><p>Exemplos de invasão: Roubar informações</p><p>sigilosas; Modificar conteúdo de forma mal-</p><p>intencionada; Degradar o desempenho;</p><p>Desabilitar funcionalidade; Atrapalhar uma</p><p>pessoa, organização ou negócio.</p><p>Teste de segurança visa checar se os mecanismos de proteção incorporados ao sistema são</p><p>suficientemente adequados de acordo com os requisitos e põe à prova as tecnologias de segurança</p><p>buscando descobrir brechas na segurança</p><p>TEST-DRIVEN DEVELOPMENT (TDD)</p><p>Violação de segurança ocorre quando uma aplicação</p><p>executa uma ação além das permissões concedidas</p><p>dentro da plataforma na qual está sendo executada.</p><p>Violação de privacidade pode ser mais sutil, pois</p><p>muitas aplicações recolhem informações sensíveis,</p><p>como a localização do usuário ou identificadores, a fim</p><p>de oferecer uma funcionalidade útil.</p><p>Teste de segurança visa checar os</p><p>riscos de ocorrer divulgação de</p><p>dados/informações sensíveis sem</p><p>o consentimento dos proprietários.</p><p>Teste de Privacidade</p><p>Abordagem para o desenvolvimento de software em que</p><p>se intercalam testes e desenvolvimento de código. É incremental.</p><p>Benefícios do TDD</p><p>AUTOMATIZAÇÃO DE TESTES</p><p>Testes de carga e desempenho: testes automáticos são um pré-requisito para esse tipo de teste. É</p><p>impraticável economicamente utilizar cem ou mais usuários, durante um teste, para acessar um</p><p>sistema simultanea-mente a fim de avaliar a sua qualidade sob tais condições.</p><p>Testes de regressão: representam uma das melhores aplicações da au-tomação de testes. Testes</p><p>de regressão usualmente custam muito tempo para serem executados manualmente e são muito</p><p>suscetíveis a erro hu-mano, devido ao seu nível de repetitividade. Ao automatizar, reduz-se</p><p>drasticamente a possibilidade de o sistema ser produzido com a inserção de um novo defeito em</p><p>uma funcionalidade antiga. Além disso, o ganho em tempo de execução dos testes geralmente</p><p>justifica a sua utilização.</p><p>Tarefas repetitivas: nesses casos, a grande vantagem do teste automá-tico se deve à redução de</p><p>erros. Testes manuais repetitivos normalmente exigem um grande nível de concentração do testador,</p><p>que não deve se distrair, apesar do cansaço psicológico da repetição. Assim, justifica--se a automação</p><p>nos casos em que se verifica que os testes têm obtido resultados não verdadeiros devido a falhas</p><p>humanas.</p><p>Smoke tests: são testes básicos aplicados às principais funcionalidades do sistema. Esse tipo de</p><p>teste visa a identificar defeitos nas funciona-lidades com o intuito de avaliar se a versão liberada pode</p><p>continuar sendo testada pela equipe de testes.</p><p>Testes de unidade: com a existência de tantas ferramentas gratuitas de testes unitários para quase</p><p>todas as linguagens, não utilizá-las é con-traprodutivo. O ganho em tempo ao utilizar essas</p><p>ferramentas justifica a sua utilização na maioria dos casos.</p><p>Cálculos matemáticos: o objetivo desse tipo de texto é evitar erros humanos.</p><p>Funcionalidades críticas: como seres humanos são influenciados pelo seu humor ao executarem</p><p>uma tarefa, funcionalidades críticas não deveriam depender de um testador, que pode esquecer-se</p><p>de testar algo importante.</p><p>Preparação de pré-condições: ferramentas de automação de testes podem e devem ser usadas</p><p>para preparar ambientes de teste, como condições iniciais ou entradas que serão utilizadas nos</p><p>testes. É claro que esse jamais será o primeiro passo a ser dado quando se pretende automatizar um</p><p>software; porém, uma vez que se possua a ferramenta, deve-se utilizá-la de modo a maximizar a</p><p>produtividade.</p><p>O Selenium é um conjunto de ferramentas que permite automatizar testes de diferentes formas. Ele faz isso por meio de um</p><p>conjunto de funções que possibilitam a localização de elementos de interface do usuário e a comparação entre os resultados</p><p>previstos para o teste e o comportamento real da aplicação (SELENIUMHQ, 2013). As estratégias de automação simulam o</p><p>usuário interagindo com o sistema em desenvolvimento. Em geral, os profissionais de testes aprendem a usar duas</p><p>estratégias para automatizar os testes funcionais de interface com o usuário: codificar scripts de testes e utilizar ferramentas</p><p>de captura/reprodução para gravar as ações do usuário com a aplicação.</p><p>SEMANA 7</p><p>Conhecer os principais conceitos associados a testes automatizados;</p><p>Conhecer os principais conceitos associados integração contínua;</p><p>Conhecer os principais conceitos associados à gestão de configuração de</p><p>software.</p><p>Automatizar testes é uma forma de exercitar e verificar o software de-senvolvido sem que haja</p><p>participação humana. A integração das ferra-mentas de automatização de testes nos processos de</p><p>desenvolvimento de software contribui para que o ciclo de vida do projeto seja reduzido, assim como o</p><p>seu custo. Além disso, essas ferramentas apresentam maior eficácia. Dessa forma, elas encontram maior</p><p>quantidade de falhas e erros no sistema em desenvolvimento. Com a identificação de mais erros e a sua</p><p>correção, a chance de a aplicação ter falhas ao ser entregue ao cliente é reduzida.</p><p>Casos onde a automatização é recomendada:</p><p>Aumento de produtividade</p><p>Aumento de qualidade</p><p>Funcionalidades novas: essas funcionalidades têm uma grande pro-babilidade de mudanças,</p><p>então o ideal seria criar o teste quando se alcança certa estabilidade.</p><p>Funcionalidades pouco usadas: haverá um custo e um esforço des-necessários, já que os testes</p><p>serão pouco aplicados em decorrência da pouca utilização da funcionalidade.</p><p>Funcionalidades que exigem inspeção visual: não existe uma maneira de avaliar a interface de</p><p>um sistema e a sua usabilidade. Para isso, é necessária a visão de um testador.</p><p>Protótipos: o protótipo é utilizado momentaneamente no início de um projeto de software, para ser</p><p>exibido para clientes ou para a própria organização. Por isso, não há a necessidade de automatizar</p><p>testes em um protótipo, já que ele ainda não é o software propriamente dito.</p><p>Por outro lado, a automação não é recomendada para os casos listados a seguir.</p><p>A automação de testes de software não possui competências isoladas. Para o sucesso e o bom uso da</p><p>automação de testes, deve haver testabilidade no software. A testabilidade examina as diferentes</p><p>probabilidades e características comportamentais que levam o código a falhar se alguma coisa estiver</p><p>incorreta. Assim, a testabilidade está alinhada e engajada com a qualidade da aplicação.</p><p>INTEGRAÇÃO CONTÍNUA</p><p>Mesmo organizações que não usam métodos ágeis podem usar integração contínua</p><p>• Estima-se que mais de 50% das desenvolvedoras de software usam integração contínua</p><p>O teste fumaça exercita o sistema fim-a-fim</p><p>• Não precisa ser exaustivo, mas ser capaz de</p><p>expor os principais problemas</p><p>• Deve ser bastante rigoroso, pois ao passar</p><p>por ele, entende-se que os testes de</p><p>aceitação/sistema podem ser iniciados</p><p>Os desenvolvedores realizam commits de pequenas</p><p>atualizações regularmente...</p><p>• ...e são notificados rapidamente caso suas</p><p>modificações provoquem falhas no sistema em</p><p>desenvolvimento</p><p>A integração contínua deve ser um processo simples,</p><p>de repetibilidade</p><p>TESTE DE VALIDAÇÃO</p><p>Teste</p><p>de recuperação de falhas</p><p>Teste de segurança</p><p>Teste de estresse</p><p>Teste de desempenho</p><p>Teste de implantação</p><p>TESTE DE SISTEMAS envolve:</p><p>TESTE DE VERSÃO</p><p>TESTE DE USUÁRIO</p><p>TESTE DE ACEITAÇÃO</p><p>GESTÃO DE CONFIGURAÇÃO DE SOFTWARE</p><p>O gerenciamento de configuração de software é uma atividade de apoio aplicada a toda a gestão da</p><p>qualidade. Como as mudanças podem ocorrer a qualquer instante, as atividades de SCM são</p><p>desenvolvidas para (1) identificar a alteração, (2) controlar a alteração, (3) assegurar que a alteração</p><p>esteja sendo implementada corretamente e (4) relatar as alterações a outros envolvidos.</p><p>Novos negócios ou condições de mercado ditam mudanças nos requisitos do produto ou nas</p><p>regras comerciais.</p><p>Novas necessidades dos envolvidos demandam modificação dos dados produzidos pelos sistemas</p><p>de informação, na funcionalidade fornecida pelos produtos ou nos serviços fornecidos por um</p><p>sistema baseado em computador.</p><p>Reorganização ou crescimento/enxugamento causa alterações em prioridades de projeto ou na</p><p>estrutura da equipe de engenharia de software.</p><p>Restrições orçamentárias ou de cronograma causam a redefinição do sistema ou produto.</p><p>Há quatro fontes fundamentais de alterações:</p><p>O gerenciamento de configuração de software é um conjunto de atividades desenvolvidas para</p><p>gerenciar alterações ao longo de todo o ciclo de vida de um software. O SCM pode ser visto como uma</p><p>atividade de garantia de qualidade do software aplicada em todo o processo do software.</p><p>Elementos de componente. Conjunto de ferramentas acopladas em um sistema de gestão de</p><p>arquivos (p. ex., um banco de dados) que possibilita acesso à gestão de cada item de configuração de</p><p>software.</p><p>Elementos de processo. Coleção de procedimentos e tarefas que definem uma abordagem eficaz</p><p>de gestão de alterações (e atividades relacionadas) para todas as partes envolvidas na gestão,</p><p>engenharia e uso do software.</p><p>Elementos de construção. Conjunto de ferramentas que automatizam a construção do software,</p><p>assegurando que tenha sido montado o conjunto apropriado de componentes validados (i.e., a</p><p>versão correta).</p><p>Elementos humanos. Conjunto de ferramentas e características de processo (abrangendo outros</p><p>elementos de CM) usado pela equipe de software para implementar um SCM eficaz.</p><p>Elementos que constituem o SCM:</p>de recuperação de falhas
Teste de segurança
Teste de estresse
Teste de desempenho
Teste de implantação
TESTE DE SISTEMAS envolve:
TESTE DE VERSÃO
TESTE DE USUÁRIO
TESTE DE ACEITAÇÃO
GESTÃO DE CONFIGURAÇÃO DE SOFTWARE
O gerenciamento de configuração de software é uma atividade de apoio aplicada a toda a gestão da
qualidade. Como as mudanças podem ocorrer a qualquer instante, as atividades de SCM são
desenvolvidas para (1) identificar a alteração, (2) controlar a alteração, (3) assegurar que a alteração
esteja sendo implementada corretamente e (4) relatar as alterações a outros envolvidos.
Novos negócios ou condições de mercado ditam mudanças nos requisitos do produto ou nas
regras comerciais.
Novas necessidades dos envolvidos demandam modificação dos dados produzidos pelos sistemas
de informação, na funcionalidade fornecida pelos produtos ou nos serviços fornecidos por um
sistema baseado em computador.
Reorganização ou crescimento/enxugamento causa alterações em prioridades de projeto ou na
estrutura da equipe de engenharia de software.
Restrições orçamentárias ou de cronograma causam a redefinição do sistema ou produto.
Há quatro fontes fundamentais de alterações:
O gerenciamento de configuração de software é um conjunto de atividades desenvolvidas para
gerenciar alterações ao longo de todo o ciclo de vida de um software. O SCM pode ser visto como uma
atividade de garantia de qualidade do software aplicada em todo o processo do software.
Elementos de componente. Conjunto de ferramentas acopladas em um sistema de gestão de
arquivos (p. ex., um banco de dados) que possibilita acesso à gestão de cada item de configuração de
software.
Elementos de processo. Coleção de procedimentos e tarefas que definem uma abordagem eficaz
de gestão de alterações (e atividades relacionadas) para todas as partes envolvidas na gestão,
engenharia e uso do software.
Elementos de construção. Conjunto de ferramentas que automatizam a construção do software,
assegurando que tenha sido montado o conjunto apropriado de componentes validados (i.e., a
versão correta).
Elementos humanos. Conjunto de ferramentas e características de processo (abrangendo outros
elementos de CM) usado pela equipe de software para implementar um SCM eficaz.
Elementos que constituem o SCM: