Engenharia de Software - compilado anotações

Prévia do material em texto

Curso: Banco de Dados Disciplina: Engenharia de Software. Professor: Jose Reginaldo de Sousa Mendes Junior 
Comentário da Aula: Conceitos Básicos de Software
O que é engenharia de Software: softwares são programas de computador e documentação associadas a estes.
Quais são os tipos de softwares? 
· Genéricos ou de prateleira: são os que já vem preparados para uso;
· Sob encomenda: eles são específicos para demanda do cliente. 
Software é algo abstrato e intangível. Desenvolver um programa é uma atividade complexa. Desenvolver um programa de qualidade demanda uma série de processos, métodos. 
Processo: passos gerais para se desenvolver ou manter sistemas de software. Serve como estrutura de encadeamento dos métodos. 
Métodos: descreve como fazer um passo específico do processo. Envolvem um amplo número de processos, é ação do processo. 
Ferramentas: editor de texto, programa e.g., Visual Studio. 
Causas da falha dos projetos: tecnologia errada, processo errado, pouco tempo e pouco investimento, prazos irreais. Falta de recursos, falhas no processo de captura.
Comentário Aula: Atividades do Processo de Software
O que é processo de software: o processo que contém atividades e resultados associados que geram um software. 
Elementos do processo de software: existe uma tríade realizada pelo TRABALHADOR, ATIVIDADE E ARTEFATOS. 
· Trabalhador: desempenha o papel;
· Atividades: são as tarefas;
· Artefatos: produtos do trabalho. 
Principais atividades: 
· Especificação: requisito. A atividade é aplicada às identificações das necessidades do programa. Produz como principal artefato o documento de requisitos. 
· Desenvolvimento: análise, projeto, codificação. O projeto descreve a estrutura geral do software, sua arquitetura, interface, banco de dados. 
· Implementação: codifica-se o sistema. 
· Validação: teste. Verificação e validação, visa apurar se o sistema construído atende as especificações, testes de software. Plano de testes. 
· Evolução: manutenção. Requer aferição da qualidade para avaliar se o software deve ou não evoluir.
Comentário da Aula: Ciclo de Vida do Software 
Clico de vida do software: encadeamento específico das atividades do desenvolvimento de software. é aplicado para conduzir o desenvolvimento e vai produzir artefatos na finalização de cada atividade. 
Modelos de ciclo de vida: 
· Cascata: também chamado de clássico ou sequencial linear. As atividades são realizadas em sequência. Requisitos estáveis, bem definidos e compreendidos. 
· Incremental: desenvolver uma versão inicial e continuar criando versões/ incrementos. Divisão em várias cascatas. 
· Iterativo ou evolucionário: Série de iterações evolucionárias ou ciclos. Modelos de prototipação e em espiral. 
· Ágil: utiliza os modelos iterativos e incrementais. Maior colaboração com o cliente. Maior integração entre as equipes de desenvolvimento.
Comentário da Aula: Modelos Iterativos
Software é o desenvolvido por uma série de iterações evolucionárias ou ciclos. Cada ciclo representa uma fase do processo. Representado pelos modelos de prototipação e em espiral. 
Modelo de prototipação: consiste em construir um software a partir de um protótipo. Ideal para quando os requisitos estão obscuros/indefinidos. Pode ser utilizado como um modelo isolado ou como uma técnica passível de ser implementada por outro modelo de processo. Representação da prototipação: plano rápido, modelagem do projeto rápido, construção do protótipo, implantação entrega e feedback, comunicação. 
O que é protótipo? É uma versão inicial de um sistema, usada para demonstrar conceitos e testar opções de projeto, podendo ser utilizado na elicitação e validação de requisitos. Execução de teste de sistema. Desenvolvimento do protótipo: objetivos, funcionalidades, desenvolvimento, avaliação do protótipo. 
Modelo em espiral: Também chamado de modelo de Boehm. Natureza iterativa da prototipação com a sistemática do modelo cascata. O software é desenvolvido por uma série de iterações evolucionárias ou ciclos. Fase do processo. Faz uma análise de riscos.
Comentário de aula: Modelo de processo Unificado
Processo Unificado: processo de desenvolvimento do software definido para apoiar a utilização da UML. 
Característica da PU: interativo e incremental, caso de uso, centrado na arquitetura, centrado em componentes, avaliação de riscos. 
Fases do PU: iniciação/concepção, elaboração, construção e transição. 
Boas práticas da PU: desenvolver o software iterativamente. Gerenciar requisitos. Usar arquiteturas baseadas em componentes, modelar o software visualmente, verificar a qualidade do software, controlar as mudanças do software. 
Modelos derivados do PU: Rational Unified Process, OpenUP.
Comentário da Aula: Conceitos Essenciais de Desenvolvimento Ágil
Modelos ágeis: processo de desenvolvimento de software tradicionais (RUP) são normalmente longos e inflexíveis. Havia uma grande demora entre o início e a entrega do projeto. Modelos ágeis têm como objetivo reduzir a demora no processo de software e permitir uma resposta rápida aos requisitos em constante mudança sem retrabalho excessivo. 
Princípios dos modelos ágeis: 
· Envolvimento do cliente; 
· Entrega incremental; 
· Pessoas, não processos; 
· Aceitar mudanças; 
· Manter a simplicidade.
Aplicabilidade do modelo ágil: quando o sistema é pequeno ou de médio porte. Quando o cliente se envolve no processo de desenvolvimento. 
Exemplos de modelos ágeis:
Extreme programming (XP). Scrum, Feature Driven development (FDD), Dynamic systems development method (DSDM).
Comentários Aula: O Manifesto Ágil
Manifesto ágil: declaração de princípios que fundamentam o desenvolvimento ágil de software. 
Valores do Manifesto ágil: 
· Indivíduos e interações são mais importantes que processos e ferramentas; 
· Software em funcionamento mais que documentação abrangente; 
· Colaboração com o cliente é mais que a negociação de contratos;
· Responder a mudanças mais que seguir um plano. 
Princípios do Manifesto ágil:
· satisfação do cliente via entrega contínua e adiantada; 
· aceitar mudanças de requisitos; 
· entregar frequentemente software funcionando;
· pessoas do negócio e desenvolvedores devem trabalhar diariamente em { };
· construir projetos em torno de indivíduos motivados;
· o método mais eficiente e eficaz de transmitir informações entre a equipe é por meio de um Tête-à-tête*. 
· software funcionando é a medida primária de progresso; 
· processos ágeis promovem o desenvolvimento sustentável; 
· contínua atenção à excelência técnica e bom design. simplicidade é essencial; 
· melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis; 
· Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz.
*tête-a-tête: Conversa particular entre duas pessoas.
Comentário da Aula: Extreme Programming (XP)
Extreme Programming (XP): 
· desenvolvimento iterativo ao extremo; 
· requisitos expressos como cronologia do usuário; 
· código fonte é refatorado e estado; 
· releases do sistema entregues em curto intervalo de tempo. 
Ciclo de vida do XP: as tarefas são planejadas, desenvolvidas via software, liberadas para teste, avaliadas pelo cliente. 
Valores do XP: 
· comunicação: conversas pessoais entre clientes e desenvolvedores. 
· coragem: falar a verdade, lidar com os riscos; 
· feedback: troca de informações entre clientes e desenvolvedores;
· simplicidade: fazer de um modo mais simples para conseguir modificar depois;
· respeito: valor que deve imperar entre os pares da equipe. 
Práticas do XP: 
· planejamento incremental; 
· pequenos releases; 
· projeto simples; 
· desenvolvimento test-first; 
· refatoração; 
· programação em pares; 
· propriedade coletiva; 
· integração contínua; 
· ritmo sustentável;
· cliente no local.
Comentário da Aula: Scrum
O que é SCRUM? 
É uma metodologia ágil que utiliza o processo de desenvolvimento iterativo e incremental. 
· divisão do desenvolvimento em sprints (período de tempo);
· lista de backlog;
· equipes pequenas e auto-organizadas. 
Ciclo de vida do Scrum.
1) visãodo produto + equipe -> Backlog (resumo histórico) de produto, backlog de sprint. Produto + Capacidade da equipe. 
2) Após o SPRINT temos = produto + capacidade da equipe.
Práticas do Scrum: 
· Elaboração do Product Backlog;
· Planejamento da Sprint;
· elaboração da Sprint Backlog;
· reuniões diárias;
· elaboração do Burndown (gráfico que representa o trabalho); 
· revisão da sprint;
· retrospectiva da sprint.
Produto Backlog: 
1) Lista contendo todas as funcionalidades desejadas; 
2) A lista cresce muda conforme aprende-se mais sobre o produto/usuários. 
SPRINT Planning: 
1) Reunião de planejamento envolvendo todos;
2) Divisão do product backlog em sprint, que devem durar de uma semana até um mês. 
SPRINT Backlog:
1) Lista de tarifas que time de desenvolvimento se compromete a fazer um sprint; 
2) Cada sprint possui uma lista de itens selecionados da product backlog com suas respectivas tarefas. 
Scrum Daily:
1) reunião de 15 minutos, cada membro conta o que fez no dia de trabalho anterior, o que fará no dia. 
Release Burndown: 
1) Gráfico que mostra o progresso do projeto atualizado;
2) elaborado pelo time de desenvolvimento a cada sprint. 
SPRINT Review: 
1) reunião ao final de cada sprint com o cliente; 
2) apresentação do que será entregue e do que não foi possível fazer em relação ao planejamento da sprint; 
3) se surgirem mudanças elas serão tratadas na próxima Sprint.
SPRINT Retrospective: 
1) reunião que ocorre ao final de um sprint e serve para identificar o que deu certo, melhorias e ações a serem tomadas. 
Papéis no Scrum: 
1) product owner = proprietário do produto. 
2) scrum master: gerente de projeto ou líder técnico. 
3) scrum team: equipe de desenvolvimento.
Comentário aula: Gerenciamento e Escalonamento de Métodos Ágeis
Gerenciamento ágil de projetos: 
1) Os gerentes de projetos são responsáveis por gerenciar o projeto para que o software seja entregue dentro do prazo e custo;
 2) Gerenciamento ágil requer uma abordagem adaptada ao desenvolvimento incremental e aos pontos fortes de métodos ágeis. 
Kanban: metodologia baseada no sistema puxado. Controle visual de trabalho. 
Práticas do Kanban. 
1. Visualizar fluxo de trabalho = estágio do processo;
2. limitar o trabalho em progresso; 
3. gerenciar o fluxo de trabalho;
4. explicitar políticas de processo;
5. Focar na melhoria contínua;
6. alterar o processo colaborativamente.
O Kanban tem três colunas: a fazer, em processo, feito. 
Burndown: ferramenta de medição visual do Scrum. Permite aos gerentes de projeto verificarem se o trabalho está dentro do esperado. Mede a produtividade. 
Planejamento de Sprints: os sprints possuem comprimento fixo = timebox, os itens do product backlog são estimados pela equipe por meio do jogo de planejamento para ver se cabem na sprint. A definição da sprint envolve a participação de todos os envolvidos no projeto. 
Escalonamento de métodos ágeis: os métodos ágeis são ideias para projetos pequenos e médios que podem ser desenvolvidos por uma equipe pequena. Projetos maiores e múltiplas equipes requerem o escalonamento dos métodos ágeis.
Comentário da Aula: Conceitos de Requisitos
O que é requisito? Uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente para satisfazer um contrato, padrão, especificação ou outro documento de formalidade. Algo que precisa ser atendido. 
Gerência de Requisitos: 
1. levantamento de requisitos; 
2. Análise de requisitos; 
3. Documentação de requisitos;
4. Verificação e validação de requisitos;
5. Gerenciamento de requisitos. 
O que é Engenharia de Requisitos? 
O processo de compreensão e definição dos serviços requisitados do sistema e identificação das restrições relativas à operação e ao desenvolvimento do sistema. 
Fases da Engenharia de Requisitos
· Levantamento de Requisitos: técnicas de elicitação, necessidades da cliente; mudanças frequentes; 
· Análise e negociação de requisitos: atividade de montagem, identifica os conflitos; soluções tec. 
· Documentação de requisitos: elaborar um documento de requisitos, rastreabilidade e auditabilidade; 
· Verificação e validação de requisitos: Stakeholders valiam o documento de requisitos; aceite do cliente;
· Gerência de requisitos: gerencia as mudanças nos requisitos. Ocorre em paralelo.
Comentário Aula: Tipos de Requisitos
Os três tipos de fontes de requisitos são: Stakeholders, documentos e sistema em operação. 
Categoria de Classificação dos requisitos: 
Requisitos:
· usuário, sistema;
· funcionais e não-funcionais;
· não funcionais: produto, organização e externo. 
Requisitos do usuário: serviços que o usuário espera do sistema e as restrições sob as quais ele deve operar. 
Requisitos de Sistema: funções, serviços, restrições do sistema. Versões estendidas dos requisitos de usuário usadas para o desenvolvimento do sistema. 
Requisitos Funcionais: definem as funcionalidades do sistema. Pode trazer também a identificação do que o sistema não deve fazer. Os requisitos funcionais descrevem como o sistema deve se comportar, atendendo aos propósitos para o qual ele será desenvolvido. Exemplo: cadastrar cliente, cadastrar pedido, aplica cupom de desconto, cadastrar pizza. 
Requisitos Não-Funcionais: definem as restrições de funcionamento do sistema. São importantes para a fase de projeto, servindo como base para a tomada de decisões nessa fase. Estar especificado quantitativamente para ser testável e não gerar interpretações equivocadas ou dúbias. 
Requisitos de produto: tem a ver com o funcionamento do software, ao desempenho, eficiência, confiabilidade, tamanho, usabilidade e segurança. Exemplo: o sistema fazer backup em 5 minutos, ser acessível aos dispositivos móveis, ter autenticação em vários fatores. 
Requisitos Organizacionais: características inerentes às políticas e procedimentos da organização do cliente e do desenvolvedor. Incluem requisitos de processo, requisitos de implementação, restrições de entrega, restrições orçamentárias. 
Requisitos Externos: são requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem ser normas reguladoras, requisitos legais, requisitos éticos. Exemplo: sistema deve atender a LGPD.
Documento de Requisitos: principal artefato gerado pela engenharia de requisitos. Com ele, os stakeholders poderão conhecer as funcionalidades que serão implementadas no sistema. 
Comentários aula: Técnicas de Elicitação e análise de requisitos. 
Elicitação (levantamento) de requisitos: Processo de descobrir, explicar, e obter o máximo de informações para o conhecimento do produto em questão. Para facilitar esse processo, são utilizadas algumas técnicas de elicitação de requisitos. 
Técnicas de Elicitação de Requisitos:
· Brainstorming: técnica utilizada para gerar ideias sobre possíveis soluções sistêmicas; 
· Cenários: são histórias que simulam a execução de vários processos no sistema. Objetivo de apresentar soluções sistêmicas para cada uma delas; 
· Entrevistas: reuniões com diversas pessoas envolvidas no projeto, recomendado para se fazer com poucas pessoas;
· Garimpo de documentos: documentos de processo e regras de negócio relacionadas ao sistema são acessados e lidos. Ideal para recuperar normas/padrões para entender o funcionamento dos processos de negócio;
· Etnografia: observação do processo acontecendo no local, características observadas no processo são anotadas;
· Prototipagem: técnica que prevê a criação de protótipos para a validação de requisitos e interface junto ao cliente;
· Questionários: aplicação de questionários para serem respondidos por usuários e pessoas importantes no processo;
· Role playing: analista executa as tarefas sendo orientado pelo usuário, ideia é fazer o analista ter uma noção do processo acontecendo;
· Workshops: reuniões em que o assunto principal é o domínio ou área do sistema que será desenvolvido com participação de profissionais especialistas. 
Comentários aula: Modelagem de requisitos
Unified Modeling Language: Grady Booch, James Rumbaug, Ivar Jacobson. 
O que é UML? É uma linguagempadrão para visualizar, especificar, construir e documentar os artefatos de software de um sistema. 
Características da UML? 
· Boa expressividade, onde cada símbolo possui uma semântica bem definida;
· É independente de linguagens de programação e de processos;
· Define um conjunto de diagramas que abrange todas as visões necessárias ao desenvolvimento de softwares. 
O Diagrama da UML é dividido em: diagrama de estruturas e diagrama de comportamentos. É uma forma visual (fluxograma) de representar a estrutura, o comportamento, e a interação de um sistema de software ou de um processo de negócios. 
Diagramas de Caso de Uso: 
· Permite ter uma visão dos requisitos funcionais do sistema;
· Representação gráfica contendo um conjunto de atores, de casos de usos e de relacionamentos entre eles. 
O que é ator? É um elemento externo que interage com o sistema. O ator pode ser do tipo primário, secundário. 
Quem pode ser ator? Cargos, organizações, sistemas, equipamentos. 
O que é caso de uso? É uma sequência de interações entre os atores e o sistema. 
Caso de uso – Notação da UML. Tipos de caso de uso: abstrato, concreto. Exemplos: matricular em uma turma, reservar um livro, realizar um saque, consultar produtos. 
O que é um relacionamento? É uma conexão entre os atores e casos de usos entre atores, e entre casos de usos. Tipos de relacionamento: comunicação, inclusão, extensão, generalização. 
Relacionamento de Comunicação: associações entre atores e casos de uso. Podem conter setas indicando o sentido em que as informações trafegam na comunicação. 
Relacionamento de Inclusão: Utilizado para incluir um caso de uso em outros casos de uso. O caso de uso incluído é executado obrigatoriamente. 
Relacionamento de Extensão: Utilizado para estender um caso de uso para outros casos de uso. O caso de uso estendido é executado dependendo de uma condição ser satisfeita. 
Relacionamento de Generalização: Relaciona casos de uso ou atores com características semelhantes e pequenas diferenças entre si. Um ator genérico é definido com as associações que são herdadas pelos atores especializados. 
Comentário aula: especificação e documentação de requisitos
Especificação de casos de uso: descrever textualmente os casos de usos, informando o passo a passo de sua execução a partir do fluxo de dados iniciados pelo usuário e continuado pelo próprio sistema. UML não define nada acerca de como essa descrição textual deve ser construída. 
Modelo de Especificação de CSU: 
· Identificação do caso de uso; 
· Objetivo do caso de uso;
· Atores;
· Precondições;
· Fluxos de eventos;
· Pós-condições;
· Regras de negócio;
· Mensagens do Sistema. 
Identificação do caso de uso: o nome do caso de uso é geralmente um verbo no infinitivo para indicar um processo ou ação segundo a perspectiva do ator. Exemplo: Registrar um pedido, abrir uma ordem de serviço, alugar um filme. 
Objetivos do caso de uso: deve ser descrito de maneira simples e direta. Exemplo: CSU01 – Manter vaga, objetivo de cadastrar/alterar/consultar/excluir uma vaga. 
Atores: listar os atores envolvidos classificando-os em primário ou secundário. Exemplo: CSU03 – lançar notas. Ator primário = professor, ator secundário = aluno. 
Precondições: descrever o estado atual do sistema para que o caso de uso possa iniciar. Exemplo: a vaga tem que estar com o status livre. O professor está autenticado no sistema. 
Fluxo de Eventos: indicam a sequência de passos realizados na execução do caso de uso. Tipicamente descritos na forma sujeito + predicado. Podem ser divididos em vários subfluxos.
Tipos de Fluxo de Eventos:
 
Fluxo Principal: representa o caminho feliz do caso de uso, sequência não ramificada e não aninhada de passos de interação. Exemplo de fluxo principal: 
Fluxo Alternativo: sequência alternativa ao fluxo principal escolhida pelo ator, recomenda-se referenciar no próprio passo a possibilidade do chamar o outro fluxo de evento. 
Fluxo de Exceção: Um tipo de fluxo associado ao tratamento de erros. Exemplo: o número de vagas para interdição foi excedido; Sistema informa ao cliente que o número de vagas para interdição foi excedido. 
Pós-condições: Lista os possíveis estados do sistema ao final da execução do caso de uso. Exemplo: A vaga fica interditada. A média de cada aluno é calculada. 
Regras do Negócio: políticas, condições, ou restrições que normalmente influenciam o comportamento dos casos de uso. Exemplos: RN01. O limite de vagas interditadas é até 20% do total. RN02. A nota do aluno deve ser um valor entre 0,0 e 10,0.
Mensagens do Sistema: informações apresentadas aos atores para avisar ou alertar sobre algo, indicar sucesso na execução, indicar erro na execução, solicitar uma confirmação. 
Erros comuns na especificação: As operações CRUD (Create, Read, Update e Delete) sendo descritas como casos de uso. Mais de uma ação indicada no mesmo passo (Ex.: o sistema valida os dados, salva as informações e confirma ao usuário). Fluxos de evento, regras de negócio e mensagens não sendo referenciados nos passos.
Comentários aula: Gerenciamento e Planejamento de Projetos de Software
O que é um projeto? É um esforço temporário empreendido para criar um produto, serviço, ou resultado único. 
O gerenciamento de projeto tem 4 variáveis: escopo, qualidade, tempo, custos. 
O que é gerenciamento de projeto: aplicação de conhecimentos, habilidades, ferramentas, e técnicas adequadas à condução das atividades do projeto de forma a atingir seus requisitos. 
Ciclo de vida do projeto de Software: 
Benefícios da gestão de projetos 
· Maior controle dos processos; 
· Maior agilidade na tomada de decisões; 
· Resultados mais assertivos; 
· Maior engajamento da equipe; 
· Otimização do tempo; 
· Maior satisfação do cliente.
Gerente de projeto 
· Controla escopo, prazos e custos do projeto. 
· Distribui tarefas à equipe. 
· Monitora indicadores e toma decisões
PMBOK 
· Um guia das melhores práticas de gerenciamento de projetos publicado pelo Project Management Institute (PMI). 
· Pode ser aplicado a todos os tipos de projetos, independentemente do nicho, da dimensão, do pessoal envolvido, dos prazos e orçamentos.
Gerenciamento de Escopo
· Trata da descrição formal do que precisa ser feito e entregue no projeto;
· O escopo é visualizado na forma de EAP (estrutura analítica do projeto);
Gerenciamento de Cronograma
· Cuida do monitoramento e controle dos prazos relacionados a cada etapa e ao projeto como um todo;
· O Gráfico de Gantt permite visualizar e acompanhar as tarefas a serem executadas ao longo do projeto em uma perspectiva do tempo.
Gerenciamento de Custos
· Cuida da questão financeira, para que o projeto não ultrapasse o orçamento que foi definido inicialmente;
· Usa planilhas e dashboards que apoiam a visualização dos gastos e orçamento.
Gerenciamento de Qualidade
· Garante que um controle de qualidade seja implementado para que o projeto alcance um nível aceitável de qualidade.
Gerenciamento de Recursos 
· Gerencia os recursos necessários para a condução do projeto, como recursos humanos, materiais, equipamentos e infraestrutura necessária;
· A Matriz de Responsabilidade serve para atribuir responsabilidades às pessoas quanto às tarefas a serem desenvolvidas.
· 
Gerenciamento de Comunicação 
· Assegura que a informação do projeto seja distribuída, coletada, armazenada e gerenciada.
Gerenciamento de Riscos
· Trata os riscos do projeto tomando medidas que levem a identificação, análise e planejamento de respostas para os pontos de vulnerabilidade do projeto;
· A Matriz de Impacto e Probabilidade é usada para avaliar os impactos dos riscos sobre cada um dos processos existentes nas áreas de conhecimento, bem como avaliar sua probabilidade de ocorrência.
· 
Gerenciamento de Aquisições 
· Auxilia no processo de tomada de decisão de compra;
· Tratar do relacionamento com os fornecedores;
· Estabelece normas para comprar produtos e contratar serviços externos à equipe do projeto.
Gerenciamento de Stakeholders
· Identifica todas as pessoas e entidades que podem afetar o projetoou serem afetadas por ele. 
· Utiliza a Matriz de Poder x Interesse, que permite classificar os stakeholders para que torne mais fácil o entendimento sobre o fluxo de informações que devem transitar entre eles.
Gerenciamento de Integração 
· Junta todas as demais áreas do projeto para atingir um objetivo comum, coordenando todas as práticas e demais áreas.
Comentários aula: Teste de Software 
O que é teste de software? É um processo sistemático e planejado que tem por finalidade única a identificação de erros. 
Já na etapa de análise de requisitos (fase inicial do projeto) deve-se pensar em quais Testes serão executados. Quais são os valores que eu vou aplicar nos meus testes? A massa de dados. 
Na Implementação eu vou programar os testes. 
A execução dos testes é justamente a parte de testá-los. 
Estratégias de testes: Caixa branca, caixa preta. 
Teste Caixa Branca (técnica estrutural): 
· Identifica defeito nas estruturas internas do sistema;
· Validação de algoritmos no código fonte;
· Requer conhecimento da tecnologia;
· Mais eficiente e mais difícil de implementar. 
Teste Caixa preta (técnica funcional):
· Valida se o sistema produz os resultados esperados;
· Requisitos decompostos em casos de teste;
· Não requer conhecimento da tecnologia;
· Mais simples de implantar.
Tipos de testes: 
· Funcionalidade: simula cenários de negócio. Conformidade dos requisitos funcionais. Ex.: Validar precondições e pós-condições. Validar fluxo principal. Validar fluxos alternativos. 
· Usabilidade: simula as condições de utilização do software. Foco em navegabilidade, acessibilidade, padrão visual, clareza de mensagens etc. Ex.: Avaliar a facilidade de navegação, avaliar mensagens de alerta. 
· Desempenho: avalia o desempenho em situações de pico. Compara tempo de resposta com limites especificados. Exemplos: Vários usuários acessando ao mesmo tempo, vários usuários processando a mesma transação. 
· Volume: simula condições extremas de utilização, aumento contínuo de processamento. Determina os limites máximos do sistema. Exemplos: aumentar sucessivamente o volume de transações. Aumentar o volume de consultas, aumentar sucessivamente o volume de dados. 
· Carga: Simula condições atípicas de utilização, variações sucessivas de processamento que chegam a ultrapassar os limites do sistema. 
· Segurança:
· Recuperação:
· Contingência: 
· Instalação:
· Configuração:
image6.png
image7.png
image8.png
image9.png
image10.png
image11.png
image12.png
image1.png
image2.png
image3.png
image4.png
image5.png