Aula - Engenharia de Software

Prévia do material em texto

26/02/2015
1
Faculdade de Tecnologia de Alagoas - FAT
Análise e Desenvolvimento de Sistemas
Engenharia de Software
3º Módulo
5º Semestre
Docente: Victor Augusto Fragoso Florentin
Victor Augusto Fragoso Florentin
Mestrando em Informática – UFAL
Especialista em Gestão de Projetos em TI – CESMAC
Tecnólogo em Análise e Desenvolvimento de Sistemas – UNOPAR
victor.fragoso@live.com
26/02/2015
2
Apresentação de Discentes
Nome
Falar um pouco de você
Falar um pouco de sua expectativa do curso
Engenharia de Software
APRESENTAÇÃO DA DISCIPLINA
26/02/2015
3
Objetivos
Ementas
Metodologia
Bibliografia
 Compreender o processo de construção de software;
 Utilizar ferramentas para Engenharia de Softwares avançadas;
 Utilizar técnicas para medir e estimar o tamanho de um software;
 Pesquisar e estudar cenários de grande porte onde sejam úteis as
práticas de Engenharia de Software estudadas;
 Complementar o estudo das técnicas utilizadas em todo um ciclo de
desenvolvimento de software.
Objetivos
Ementas
Metodologia
Bibliografia
 Fundamentos da Engenharia de Software;
 Ciclo de vida de software;
 Gestão de Projetos de Software;
 Testes de Software;
 Qualidade de Software;
 Gestão de Versão e Configuração de Software;
Métricas e Estimativas de Software;
 Uso de Ferramentas CASE na Engenharia de Software.
26/02/2015
4
Objetivos
Ementas
Metodologia
Bibliografia
 Aulas expositivas com slides;
 Exercícios;
 Trabalhos individuais;
 Trabalhos em equipe;
 Aulas práticas em laboratório.
Objetivos
Ementas
Metodologia
Bibliografia
 Bibliografia Básica:
 ENGENHARIA DE SOFTWARE
 Autor: PRESSMAN, R.
 Edição: 6ª
 Editora: MCGRAW-HILL INTERAMERICANA DO BRASIL – RIO DE JANEIRO
 Ano: 2006
 ENGENHARIA DE SOFTWARE
 Autor: SOMMERVILLE, IAN
 Edição: 6ª
 Editora: PRENTICE-HALL – SÃO PAULO
 Ano: 2003
Bibliografia Auxiliar:
 UML: UMA ABORDAGEM PRÁTICA
 Autor: GILLEANES T. A. GUEDES
 Edição: 1ª
 Editora: NOVATEC – SÃO PAULO
 Ano: 2004
26/02/2015
5
Engenharia de Software
INTRODUÇÃO
Engenharia de Software
Introdução
26/02/2015
6
Engenharia de Software
Conceitos
O que é Sistema?
 Conjunto de elementos e componentes, dinamicamente
relacionados, organizados em função de um objetivo.
 Todo sistema é composto de subsistemas e todo sistema
é parte integrante de um sistema maior.
Engenharia de Software
Conceitos
O que é Engenharia?
 É a arte de aplicar conhecimentos científicos à inovação, aperfeiçoamento ou utilização da técnica
industrial em todas as suas determinações.
 Todo sistema é composto de subsistemas e todo sistema é parte integrante de um sistema maior.
O que é Software?
 Subsistema de um sistema computacional;
 São os programas de computador e documentação associada;
 Produtos de Software podem ser desenvolvidos para um cliente especifico ou para o mercado em geral.
O que é Engenharia de Software?
 Disciplina de engenharia que se preocupa com todos os aspectos de produção de software.
26/02/2015
7
Engenharia de Software
FUNDAMENTOS DA ENGENHARIA DE SOFTWARE
Engenharia de Software
Fundamentos da Engenharia de Software
Aplicações de Software:
 Básico:
 Aplicativos de escritórios (editores, planilhas, ...),
programas CAD, edição de fotos, ...
 Iterativas baseadas em transações:
 Aplicações WEB como comércio eletrônico, portais
empresariais e educacionais, ...
 Controle Embutido:
 Aplicações que controlam e e gerenciam dispositivos de
Hardware, como: software em celulares, micro-ondas,
carros, ...
 Processamento em Lotes:
 Sistemas periódicos de cobrança (telefonia, ...), sistemas de
folha de pagamento, ...
 Entretenimento:
 Em sua maioria jogos.
 Modelagem e Simulação:
 Sistemas que simulam situações do mundo real como:
simulador de uma cabine de avião, ...
 Coleta de Dados:
 Coletam informações por meio de sensores, como: Controle
de combustível de um carro, ...;
 Computadores pessoais, internet, redes locais e
globais;
 Redução dos custos relacionados a Hardware e Software;
 Regras de negócios mais complexas;
 C++, Delphi, ...
26/02/2015
8
Engenharia de Software
Fundamentos da Engenharia de Software
Evolução do Software:
 1945 – 1960 (Primeira Era):
 Softwares sem complexidade e geralmente desenvolvidos
sob encomenda;
 Foco e altos custos de Hardware;
 Alta customização e pouca reutilização.
 COBOL, FORTRAN, ...
 1965-1980 (Segunda Era):
 Expansão do mercado computacional;
 Sistemas multiusuários;
 Programação Estruturada;
 1ª Geração de Sistemas de Gerenciamento de banco de
dados (SGBD);
 Baixa manutenção do software;
 PASCAL, C, ...
 1980 - 1990 (Terceira Era):
 Sistemas distribuídos em tempo real;
 Interface homem-máquina (IHC);
 Tecnologias Estruturadas;
 Computadores pessoais, internet, redes locais e globais;
 Redução dos custos relacionados a Hardware e Software;
 Regras de negócios mais complexas;
 C++, Delphi, ...
 A partir de 1990 (Quarta Era):
 Redes Neurais Artificiais, Computação Paralela;
 Tecnologias orientadas a objetos;
 Internet, dispositivos móveis (exemplo: celular);
 Softwares de Inteligência Artificial;
 Hardware e Software de baixo custo;
 C#, Java, Python, ...
Engenharia de Software
Fundamentos da Engenharia de Software
Crise do Software (1968):
 Motivos Principais:
 Preços de hardware e software diminuem;
 Maior demanda do mercado;
 Falta de documentação;
 Baixa produtividade e qualidade de softwares;
 Softwares sem manutenção
 Resultado:
 Software entregue fora do prazo, com baixa qualidade e
com maior custo;
 Grandes falhas.
 Solução:
 Necessidade da utilização de processos e métodos bem
definidos, que pudessem ser quantificados, formalizados,
para o desenvolvimento de software;
 Aplicação de conceitos de Engenharia ao
Desenvolvimento de Software;
 Surge assim o termo Engenharia de Software.
26/02/2015
9
Engenharia de Software
Fundamentos da Engenharia de Software
Definição:
 Engenharia de Software é uma tecnologia em camadas
que precisa se apoiar em um compromisso
organizacional com a qualidade.
Objetivo:
 A Engenharia de Software surgiu da necessidade de um
desenvolvimento de software sem defeitos e produzidos
dentro de um tempo estipulado, com o uso de
ferramentas, métodos, processos e foco na qualidade;
 De modo geral, considera-se que os objetivos primários
da Engenharia de Software são o aprimoramento da
qualidade dos produtos de software e o aumento da
produtividade dos engenheiros de software, além do
atendimento aos requisitos de eficácia e eficiência, ou
seja, efetividade.
Engenharia de Software
Fundamentos da Engenharia de Software
Foco na qualidade:
 Procurada durante cada fase do processo de desenvolvimento
de Software;
 Permite ao gerente um maior controle e ao desenvolvedor
uma referência.
Processos:
 Constituem o elo de ligação entre os métodos e as
ferramentas;
 Definem: a sequência em que os métodos serão aplicados; os
produtos que são exigidos a entrega (relatórios, documentos,
formulários, etc.);
 Os controles que ajudam a assegurar a qualidade e coordenar
as mudanças;
 Os marcos que possibilitam aos gerentes de software a avaliar
o progresso.
26/02/2015
10
Engenharia de Software
Fundamentos da Engenharia de Software
Métodos:
 Proporcionam os detalhes de como fazer para construir o
software: planejamento e estimativa de projeto, análise de
requisitos de software, projeto da estrutura de dados,
arquitetura de programa e algoritmo de processamento,
codificação, testes e manutenção;
 Conjunto de tarefascom técnicas específicas para cada fase
do desenvolvimento de Software.
Ferramentas:
 São os instrumentos que proporcionam os detalhes de como
fazer para construir o software;
 Proporcionam suporte automatizado ou parcialmente
automatizado aos métodos;
 Conhecidos também como CASE (Computer Aided Software
Engineering).
Engenharia de Software
Fundamentos da Engenharia de Software
Qualidade:
 Atributos de um bom software:
 Facilidade de manutenção;
 Confiança;
 Eficiência;
 Usabilidade.
26/02/2015
11
Engenharia de Software
CICLO DE VIDA DE SOFTWARE
Engenharia de Software
Ciclo de Vida de Software
O que é um Ciclo de Vida?
 É considerado o intervalo de tempo decorrido desde
o momento de sua concepção até a sua conclusão
ou seu fim.
26/02/2015
12
Engenharia de Software
Ciclo de Vida de Software
Atividade de sala:
Como seriam as fases do Ciclo de Vida de um homem?
 Concepção;
 Crescimento;
 Maturidade;
 Declínio/Morte.
Engenharia de Software
Ciclo de Vida de Software
O que é Software?
 Subsistema de um sistema computacional;
 São os programas de computador e documentação associada;
 Produtos de Software podem ser desenvolvidos para um cliente específico ou para o mercado em geral.
O que é Engenharia de Software?
 Disciplina de engenharia que se preocupa com todos os aspectos de produção de software.
26/02/2015
13
Engenharia de Software
Ciclo de Vida de Software
O que é um Ciclo de Vida de Software?
 É considerado o intervalo de tempo
decorrido desde o momento da concepção
do software até a sua conclusão ou sua
descontinuidade;
 O ciclo de vida define as fases que
conectam o início de um projeto a seu fim.
A organização em fases é um mecanismo
que permite um controle gerenciável;
 A transição entre as fases normalmente é
marcada por alguma entrega e/ou revisão;
 Também conhecido como processo de
software. Assim como um projeto, um
processo demanda um ciclo de vida para
organizar suas atividades.
Engenharia de Software
Ciclo de Vida de Software
O que é Processo de Software?
 Conjunto de atividades relacionadas para o desenvolvimento (produção) de um produto de software;
26/02/2015
14
Engenharia de Software
Ciclo de Vida de Software
Atividades Fundamentais de Processos de Software
 Especificações de Software:
 Define o software a ser produzido e as restrições de sua operação, de acordo com as
necessidades (requisitos) solicitadas pelo cliente;
 Desenvolvimento de Software:
 Atividade em que o software é projetado e programado, de acordo as
especificações de software;
 Validação de Software:
 Atividade em que o software é analisado e verificado para garantir se os requisitos
(necessidades ) solicitados pelo cliente estão contemplados e funcionais como o
cliente queria;
 Evolução de Software:
 Atividade em que o software é modificado como consequência de mudança de
requisitos do cliente e/ou do mercado;
Especificação
DesenvolvimentoValidação
Evolução
Engenharia de Software
Ciclo de Vida de Software
Atividades Fundamentais de Processos de Software
 Especificações de Software:
 Engenharia de Sistema:
 Sugestão de uma solução para o problema, relacionando questões extra
software.
 Análise de Requisitos:
 Levantamento das necessidades do cliente do software a ser desenvolvido.
Tendo como o finalidade produzir a especificação de requisitos.
 Especificação de Sistema:
 Descrição funcional do sistema. Pode-se incluir um plano de testes para
verificar adequadamente às funcionalidades.
Especificação
DesenvolvimentoValidação
Evolução
26/02/2015
15
Engenharia de Software
Ciclo de Vida de Software
Atividades Fundamentais de Processos de Software
 Desenvolvimento de Software:
 Projeto Arquitetural:
 Desenvolvimento de um modelo conceitual para o sistema, composto de
módulos relacionados.
 Projeto de Interface:
 Cada módulo tem sua interface de comunicação avaliada e definida.
 Projeto Detalhado:
 Módulos são definidos internamente, podendo ser traduzidos para
pseudocódigos.
 Codificação:
 Desenvolvimento do sistema em uma linguagem de desenvolvimento de
computador.
Especificação
DesenvolvimentoValidação
Evolução
Engenharia de Software
Ciclo de Vida de Software
Atividades Fundamentais de Processos de Software
 Validação de Software:
 Teste de Unidade e Módulo:
 Realização de testes para verificação de presença de erros e de comportamento
adequado de funcionalidades e módulos do sistema.
 Integração:
 Agrupamento dos diversos módulos em um produto de software homogêneo e a
verificação dos relacionamentos entre estes módulos quando operando em
conjunto.
 Validação:
 Aceite do cliente do software, de acordo com as especificações, testes, módulos,
integrações e funcionalidades estabelecidas.
Especificação
DesenvolvimentoValidação
Evolução
26/02/2015
16
Engenharia de Software
Ciclo de Vida de Software
Atividades Fundamentais de Processos de Software
 Evolução de Software :
 Manutenção e Evolução:
 Nesta atividade, o software entra em um ciclo iterativo que abrange as demais
atividades (atualizações de software).
Especificação
DesenvolvimentoValidação
Evolução
Engenharia de Software
Ciclo de Vida de Software
O que é Modelos de Processos de Softwares?
 Uma representação abstrata e simplificada do processo de desenvolvimento de software, tipicamente 
mostrando as principais atividades e dados usados na produção e manutenção de software;
O que é Metodologia?
 Conjunto de métodos e processos.
Modelos de Processos de Softwares:
 Cascata;
 Espiral;
 Prototipação;
 RUP;
 Extremming Programming.
26/02/2015
17
Engenharia de Software
Ciclo de Vida de Software
Atividade de Grupo:
 Forme grupos e defina, exemplifique e defenda um dos Modelos
de Processos de Softwares:
 Cascata;
 Espiral;
 Prototipação;
 RUP;
 Extremming Programming.
Engenharia de Software
METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE
26/02/2015
18
Engenharia de Software
Metodologias de desenvolvimento de software
Objetivo:
 O software deve ser desenvolvido conforme os requisitos de sistema, no prazo estabelecido e com a
qualidade esperada
Modelos de Processos de Software:
 É uma estratégia para o desenvolvimento de softwares, com o foco na qualidade;
 Define a ordem de execução das atividades durante as fases de Engenharia de Software;
 São a continuidade dos projetos, desenvolvimento, manutenção e substituição do software;
 Descrições abstratas do processo de desenvolvimento de software;
 Representação simplificada de um processo .
Atividades Básicas dos Modelos de Processos:
 Comunicação;
 Planejamento;
 Modelagem;
 Desenvolvimento;
 Implantação.
Engenharia de Software
Metodologias de desenvolvimento de software
26/02/2015
19
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo em Cascata – Modelo Linear Sequencial
 Metodologia Tradicional;
 Conhecido também como Ciclo de Vida Clássico;
 Sugere uma abordagem sistemática e sequencial;
 A entrega de uma fase constitui na entrada de outra fase e esta apenas pode ser iniciada após o término
da anterior;
 Facilita a gestão, uma vez que, possui pontos de controle bem definidos;
 Baixa visibilidade para o cliente;
 Clientes raramente são capazes de relacionar todos os requisitos em um único momento no início do
projeto;
 Dificuldade de introduzir mudanças quando o processo encontra-se em estágio avançado;
 Podem ser encontradas diversas variações deste modelo, como: Modelo em Cascata com
Realimentação.
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo em Cascata:
26/02/201520
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo de Prototipagem
 Apropriado quando o cliente não tem os requisitos de entrada e saída devidamente definidos;
 Utilizado como um mecanismo para identificar requisitos de software;
 Concepção um modelo bem próximo do software a ser desenvolvido;
 O cliente participa ativamente da construção e validação do protótipo do software;
 Permite a antecipação do treinamento aos usuários;
 Partes do protótipo podem ser reaproveitadas (reuso) durante o desenvolvimento do software;
 O custo em grande parte dos casos é considerado alto;
 O cliente tende a confundir o protótipo do software.
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo de Prototipagem:
26/02/2015
21
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo Espiral
 Baseado a riscos;
 Modelo Evolutivo que possibilita uma maior integração entre as fases e facilita a depuração e a
manutenção do sistema;
 O produto é desenvolvido em uma série de iterações;
 Cada iteração corresponde à uma volta na espiral;
 Avaliação de riscos exige muita experiência;
 Cada volta do espiral é dividida em quatro setores:
 Definição de Objetivos: Restrições ao processo e ao produto são identificadas, e um plano de gerenciamento é elaborado; os riscos
do projeto são identificados;
 Avaliação e redução de risco: Para cada risco identificado medidas para redução deste risco são adotadas;
 Desenvolvimento e validação: Selecionado um modelo de desenvolvimento de software;
 Planejamento: O projeto é revisado e a decisão de sua continuidade é tomada para uma nova volta no espiral.
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo Espiral:
26/02/2015
22
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo RUP (Rational Unified Process)
 Processo iterativo e incremental;
 Organização baseada no conteúdo:
 Disciplina, papeis, artefatos, atividades;
 Processo de configuração e evolutivo;
 Elementos chave do RUP: Funções, Tarefas e Produtos de Trabalhos (Artefatos);
 Uma iteração pode incluir múltiplas disciplinas;
 Separação de fases e workflows;
 Reconhecimento de que a implantação de software em um ambiente do usuário é parte do processo.
Engenharia de Software
Metodologias de desenvolvimento de software
Modelo RUP (Rational Unified Process):
26/02/2015
23
Engenharia de Software
Metodologias de desenvolvimento de software
Metodologias Ágeis
 Movimento iniciado por desenvolvedores e consultores experientes em desenvolvimento de software;
 Opõem-se a uma série de práticas adotadas em abordagens tradicionais de Engenharia de Software e
Gerência de Projetos;
 Manifesto Ágil:
 Assinado por 17 desenvolvedores em Utah (Estados Unidos) em fevereiro de 2001.
Metodologia Ágil X Metodologia Tradicional
Indivíduos e interações mais importantes do que Processos e ferramentas
Software funcionando mais importante do que Documentação completa e
detalhada
Colaboração com o cliente mais importante do que Negociação de contratos
Adaptação a mudanças mais importante do que Seguir o plano inicial
Engenharia de Software
Metodologias de desenvolvimento de software
Extreme Programming (XP)
 Mais conhecido e utilizado dos métodos ágeis;
 Requisitos expressos como cenários;
 Práticas do XP:
 Desenvolvimento incremental por meio de pequenos e frequentes releases do sistema.
 Requisitos baseados em cenários, usadas como base para decidir a funcionalidade que deve ser incluída em um incremento do
sistema;
 Engajamento contínuo do cliente com a equipe de desenvolvimento. O cliente é responsável por definir os testes de aceitação do
sistema;
 Programação em pares, propriedade coletiva do código do sistema;
 Mudanças são aceitas com a utilização de releases contínuos para os clientes;
 Manutenção baseada em refatoração ao ser encontrado melhorias no código.
 Clientes envolvidos ativamente na especificação e priorização de requisitos.
26/02/2015
24
Engenharia de Software
Metodologias de desenvolvimento de software
Extreme Programming (XP):
Dividir os cenários em tarefas 
Planejar releases
Desenvolver 
Integrar
Testar
Liberar software
Avaliar sistema
Cenários de Requisitos
Especificação de Sistemas
MODELANDO SISTEMAS COM UML – LINGUAGEM DE MODELAGEM 
UNIFICADA
26/02/2015
25
Especificação de Sistemas
Modelando sistemas com UML
O que é Modelagem de Sistemas?
 Consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que
representam partes do sistema em diferentes perspectivas;
 Notações gráficas e textuais constituem a documentação de um modelo;
 Foco: clientes, requisitos e funcionalidades;
 Documentar a estrutura e o comportamento do sistema;
 Os modelos são desenvolvidos para:
 Controlar a complexidade do sistema;
 Delimitar o escopo do sistema;
 Ajudar a planejar as soluções.
 Dimensões modeladas: dados, funcionalidades e comportamentos.
Paradigma?
 Forma de abordar um problema.
Especificação de Sistemas
Modelando sistemas com UML
O que é UML?
 É uma linguagem visual utilizada para modelar softwares com o objetivo de especificar, visualizar,
construir e documentar os produtos de software;
 Através de elementos gráficos definidos na linguagem podem-se construir diagramas para representar
diferentes perspectivas de um sistema;
 Facilita entender melhor funcionalidades e requisitos de um sistema;
 Cada elemento gráfico possui:
 Sintaxe: forma predeterminada de desenhar o elemento;
 Semântica: Significado do elemento e com que objetivo deve ser usado.
 www.uml.org
26/02/2015
26
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Tipos:
 Itens: Abstrações;
 Relacionamentos: Entre os Itens;
 Diagramas: Agrupam coleções de itens.
 Itens:
 Estruturais;
 Comportamentais;
 Agrupamento;
 Notacionais.
 Relacionamentos:
 Dependência;
 Associação;
 Generalização;
 Realização.
 Diagramas:
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Itens Estruturais:
 São os substantivos dos modelos;
 Partes estática, representando elementos conceituais ou físicos.
26/02/2015
27
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Itens Comportamentais:
 São os verbos dos modelos;
 Partes dinâmicas, representando comportamentos no tempo e espaço.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Itens de Agrupamento:
 Partes organizacionais, representando os blocos em que os modelos podem ser decompostos (pacotes).
26/02/2015
28
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Itens Notacionais:
 Partes explicativas, representando comentários, incluídos para descrever, esclarecer e fazer alguma observação importante sobre
qualquer elemento do modelo.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Dependência:
 Relacionamento entre dois itens, nos quais a alteração de um pode afetar a semântica do outro.
26/02/2015
29
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Associação:
 Relacionamento que descreve um conjunto de ligações, que fazem conexões entre objetos.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Generalização:
 Relacionamentos nos quais os objetos dos elementos filhos são substituídos por objetos do elemento pai.
26/02/2015
30
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Realização:
 Relacionamentosentre classificadores, em que um classificador especifica um conjunto que outro classificador garante executar.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Diagramas:
 Representações gráficas de um conjunto de elementos, geralmente representando itens e relacionamentos.
26/02/2015
31
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Diagrama de Caso de Uso:
 Modelam a funcionalidade do sistema através do uso de atores e casos de uso.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Diagrama de Caso de Uso:
 <<include>>: Relacionamento com outro caso de uso que sempre será executado.
 <<extend>>: Relacionamento com outro caso de uso que pode ou não ser executado.
26/02/2015
32
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Diagrama de Classes:
 Descrevem a estrutura estática do sistema: entidades e relacionamentos.
Especificação de Sistemas
Modelando sistemas com UML
Blocos de Construção:
 Diagrama de Sequência:
 Descrevem as interações entre as classes através das trocas de mensagens ao longo de um tempo.
26/02/2015
33
Engenharia de Software
GESTÃO DE PROJETOS DE SOFTWARE
Engenharia de Software
Gestão de Projetos de Software
O que é Gestão?
 Ato de administrar, direcionar, gerenciar.
O que é Projeto?
 Um esforço:
 Temporário;
 Contínuo;
 Objetivo: criar um produto, serviço ou resultado único.
O que é Gerenciamento de Projetos?
 Aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades de projetos a fim de
atender aos seus requisitos (objetivos);
 Envolve o planejamento, monitoração, controle do pessoal, processos e eventos que ocorrem à medida
que o software evolui de sua concepção a sua implementação operacional.
26/02/2015
34
Engenharia de Software
Gestão de Projetos de Software
Evolução do Gerenciamento de Projeto:
• Busca de Técnicas 
para ambientes 
dinâmicos.
Até 1960
• Saída da 
informalidade, 
sedimentação de 
processos nas 
empresas.
Até 1980
• Gerenciamento de 
projetos deixa de 
ser uma escolha.
Até 2000
• Reconhecimento 
dos benefícios do 
gerenciamento de 
projetos.
A partir de 
2000
Engenharia de Software
Gestão de Projetos de Software
Chaos Report – Standish Group:
 Escopo:
 30.000 projetos
 Grandes Empresas nos Estados Unidos
16%
28%
0%
5%
10%
15%
20%
25%
30%
Projetos entregues dentro dos Prazos, Custos e Especificações
Projetos entregues dentro dos Prazos, Custos e 
Especificações
1994 2001
26/02/2015
35
Engenharia de Software
Gestão de Projetos de Software
Chaos Report – Standish Group:
 Escopo:
 30.000 projetos
 Grandes Empresas nos Estados Unidos
31%
23%
0%
5%
10%
15%
20%
25%
30%
35%
Projetos Cancelados antes de serem finalizados
Projetos Cancelados antes de serem finalizados
1994 2001
Engenharia de Software
Gestão de Projetos de Software
Chaos Report – Standish Group:
 Escopo:
 30.000 projetos
 Grandes Empresas nos Estados Unidos
189%
45%
0%
20%
40%
60%
80%
100%
120%
140%
160%
180%
200%
Projetos com extrapolação do Orçamento Inicial
Projetos com extrapolação do Orçamento Inicial
1994 2001
26/02/2015
36
Engenharia de Software
Gestão de Projetos de Software
Chaos Report – Standish Group:
 Escopo:
 30.000 projetos
 Grandes Empresas nos Estados Unidos
222%
63%
0%
50%
100%
150%
200%
250%
Projetos com extrapolamento do Prazo Inicial
Projetos com extrapolação do Prazo Inicial
1994 2001
Engenharia de Software
Gestão de Projetos de Software
Passos (4Ps):
 Produto:
 A comunicação com o cliente precisa ocorrer para que o escopo e os requisitos do produto sejam corretamente entendidos.
 Pessoas:
 Precisam ser organizadas para realizar o trabalho de software efetivamente.
 Processo:
 Precisa ser selecionado a fim de se adequar ao pessoal e ao produto.
 Projeto:
 Precisa ser planejado, estimando o esforço e o tempo para executar as tarefas de trabalho: definição, marcos de qualidade e
estabelecimento de mecanismos para monitorar e controlar o trabalho definido no plano.
26/02/2015
37
Engenharia de Software
Gestão de Projetos de Software
Áreas do Conhecimento:
Engenharia de Software
Gestão de Projetos de Software
Tríplice Restrição:
 O que é um projeto de sucesso?
26/02/2015
38
Engenharia de Software
Gestão de Projetos de Software
Processos:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Integração:
 Engloba os processos necessários para garantir que os vários elementos do projeto estão propriamente
coordenados;
 Identificar, definir, combinar, unificar e coordenar os processos e atividades;
 Gerenciar as dependências mútuas entre as demais áreas do conhecimento.
26/02/2015
39
Engenharia de Software
Gestão de Projetos de Software
Gerência de Integração:
Processos
4.1 – Desenvolver termo de abertura do projeto
4.2 – Elaboração do plano do projeto
4.3 – Execução de plano do projeto
4.4 – Monitorar e controlar o projeto
4.5 – Controle integrado de alterações
4.6 – Encerrar projeto ou fase
Entregas
Plano de Projeto
Engenharia de Software
Gestão de Projetos de Software
Gerência de Integração:
 Conteúdo do Plano de Projeto:
 Declaração do escopo;
 Cronograma;
 Ciclo de vida do projeto;
 Recursos humanos;
 Plano de gerenciamento de qualidade;
 Infraestrutura;
 Riscos;
 Plano de Comunicações;
 Principais interessados (stakeholders);
 Matriz de responsabilidades.
26/02/2015
40
Engenharia de Software
Gestão de Projetos de Software
Gerência de Escopo:
 Engloba os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e
somente o trabalho necessário, para ser completado com sucesso;
 É um conjunto de processos exigidos para assegurar que o projeto inclua todo o trabalho, e somente o
necessário, para completar o projeto de forma bem sucedida;
 A preocupação fundamental compreende em definir e controlar o escopo que está ou não incluído no
projeto.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Escopo:
Processos
5.1 – Requisitos
5.2 – Definição do escopo
5.3 – Criar EAP
5.4 – Verificação do escopo
5.5 – Controle de Alteração
Entregas
Justificativa
Produto
Resultados Práticos
Objetivos
 Qualidade;
 Tempo;
 Custo.
EAP
26/02/2015
41
Engenharia de Software
Gestão de Projetos de Software
Gerência de Escopo:
 EAP – Estrutura Analítica do Projeto:
 Organiza e define o escopo integral do projeto, subdividindo o trabalho do projeto em partes menores e mais facilmente
gerenciáveis, em que cada nível descendente da EAP representa uma definição cada vez mais detalhada do trabalho do projeto
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Engloba os processos necessários para garantir que o projeto termine dentro do prazo previsto;
 Sofre grande influência dos outros fatores do projeto;
 Utiliza-se diagramas que devem ser percorridos e calculados;
 Softwares ajudam no processo, auxiliando na geração do cronograma, relatório de andamento e
cenários, mas não mostram como gerenciar o projeto.
26/02/2015
42
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
Processos
6.1 – Definição das atividades
6.2 – Sequenciamento das atividades
6.3 – Estimativa de recursos
6.4 – Estimativa da duração de atividades
6.5 – Elaborar cronograma
6.6 – Controle de cronograma
Entregas
Análise do Caminho Crítico
Gráficode Gantt
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Relações de Precedência:
 FS (Finish to Start): Apenas inicia uma outra atividade, quando a anterior terminar:
26/02/2015
43
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Relações de Precedência:
 SS (Start to Start): Atividade tem início ao mesmo tempo do início de outra:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Relações de Precedência:
 FF (Finish to Finish): Atividades terminam ao mesmo tempo:
26/02/2015
44
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico:
 Inicia com o diagrama de rede da atividade:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico:
 Encontre todos os caminhos do diagrama:
26/02/2015
45
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico:
 Encontre a duração de cada caminho somando as durações de cada uma de suas atividades:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico – Folga:
 Inicia com o diagrama de rede da atividade:
26/02/2015
46
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico – Folga:
 A folga no caminho critico é igual a zero:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Caminho Crítico – Folga:
 Para calcular as folga entre as atividades, subtraia sua duração com a do caminho crítico:
26/02/2015
47
Engenharia de Software
Gestão de Projetos de Software
Gerência de Tempo:
 Gráfico de Gantt:
 Diagramas de barras, representando a duração e o sequenciamento das atividades;
 Possibilita uma visão global das atividades em um intervalo de tempo.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Engloba os processos necessários para garantir que o projeto termine dentro do orçamento aprovado;
26/02/2015
48
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
Processos
7.1 – Estimativas de custos
7.2 – Orçamento de custos
7.3 – Controle de custos
Entregas
Cronograma de desembolso por período
Quadro de custeio por atividade
Análise de valor agregado
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Cronograma de desembolso por período:
26/02/2015
49
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Quadro de custeio por atividade:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Análise do valor agregado:
26/02/2015
50
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Análise do valor agregado:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Custo:
 Análise do valor agregado:
 O projeto está atrasado quando: 0 < IDP < 1.
 O projeto está acima do orçamento quando: 0 < IDC < 1.
 O projeto está indo bem quando: IDP >= 1 e IDC >= 1.
26/02/2015
51
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Engloba os processos necessários para garantir que o projeto satisfaça as necessidades para o qual foi
empreendido. Inclui a gerência de qualidade do projeto e do produto do projeto;
 Foca em satisfação do cliente e conformidade de requisitos.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
Processos
8.1 – Planejamento da qualidade
8.2 – Garantia da qualidade
8.3 – Controle da qualidade
Entregas
PDCA
Inspeção
Checklist
Custos de qualidade
Gráficos de controle
26/02/2015
52
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Ciclo PDCA:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Inspeção:
 Verificação de um produto do trabalho para determinar se ele está de acordo com as normas de qualidade estabelecidas;
 Checklist:
 Utilizado para verificar se uma lista de passos requeridos foram realizados.
26/02/2015
53
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Custos de qualidade:
 Conformidade: investimentos para garantir a conformidade do produto/serviço;
 Não conformidade: gastos realizados para reverter problemas relacionados à qualidade.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Apresentação gráfica dos resultados de um processo em um intervalo de tempo;
 Podem ser usados para monitorar custos, cronogramas e mudanças no escopo.
26/02/2015
54
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Diagrama Causa e Efeito (Espinha de peixe):
 Permite analisar as causas de um problema. Pergunte-se: Quem? O quê? Onde? Quando? Por que? Como?
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Histograma:
 Modelagem de um gráfico de barras com a frequência de ocorrência de algum evento.
26/02/2015
55
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Diagrama de Pareto:
 Baseia-se na teoria do economista italiano Vilfredo Pareto: Regra do 80/20 – 20% da população tem 80% da riqueza;
 Em qualidade, significa que 20% das causas contribuem para 80% dos problemas;
 Assim é construído um diagrama de barras contendo as causas ordenadas pela frequência das ocorrências;
 É comparado também o estado anterior e o posterior depois de uma tomada de decisão.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Diagrama de Pareto:
26/02/2015
56
Engenharia de Software
Gestão de Projetos de Software
Gerência de Qualidade:
 Gráficos de controle:
 Gráfico de Execução:
 Apresenta o histórico e padrão de uma variação;
 Utiliza um gráfico de linha que mostra os resultados na ordem de ocorrência para avaliar tendências e previsão de valores.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Recursos Humanos:
 Engloba os processos necessários para garantir o uso mais efetivo das pessoas envolvidas no projeto.
Inclui todos os stakeholders (pessoas envolvidas no projeto) do projeto;
 Definir os processos, ferramentas e técnicas para desenvolver, mobilizar e gerenciar a equipe do
projeto.
26/02/2015
57
Engenharia de Software
Gestão de Projetos de Software
Gerência de Recursos Humanos:
Processos
9.1 – Planejamento do RH
9.2 – Formar equipe do projeto
9.3 – Desenvolver equipe do projeto
9.4 – Gerenciar equipe do projeto
Entregas
Organograma
Matriz de responsabilidades
Custos individuais (hora trabalhada)
Engenharia de Software
Gestão de Projetos de Software
Gerência de Recursos Humanos:
 Matriz de responsabilidade:
26/02/2015
58
Engenharia de Software
Gestão de Projetos de Software
Gerência de Comunicação:
Engenharia de Software
Gestão de Projetos de Software
Gerência de Comunicação:
 Engloba os processos necessários para garantir a correta geração, distribuição, armazenamento, coleta,
e disposição final das informações relativas ao projeto;
 Definir os meios de coleta, formatação, distribuição, armazenamento e recuperação das informações do
projeto;
 Enviar aos interessados, de forma periódica, relatórios sobre o progresso do projeto;
 Comunicar os problemas, alterações, riscos, pendências, correções que ocorreram ou foram realizadas
em um período;
 Assegurar que a informação necessária seja coletada no momento adequado de forma completae
correta;
 Capturar e registrar as informações importantes do Projeto em um repositório central, organizado e
permanente;
 Gerenciar expectativa dos stakeholders.
26/02/2015
59
Engenharia de Software
Gestão de Projetos de Software
Gerência de Comunicação:
Processos
10.1 – Identificar stakeholders
10.2 – Planejamento de comunicações
10.3 – Distribuição das informações
10.4 – Gerenciar expectativa dos stakeholders
10.5 – Relatório de desempenho
Entregas
Matriz de comunicação
Engenharia de Software
Gestão de Projetos de Software
Gerência de Comunicação:
 Matriz de comunicação:
26/02/2015
60
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
 Engloba os processos necessários para garantir a correta identificação, análise, e resposta aos riscos do
projeto; maximizando os efeitos positivos e minimizando a consequência de efeitos negativos;
 Um risco é um evento ou condições incertos que podem afetar o projeto (de forma positiva ou
negativa);
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
Processos
11.1 – Planejamento do gerenciamento de riscos 
11.2 – Identificação de riscos
11.3 – Análise qualitativa de riscos
11.4 – Análise quantitativa de riscos
11.5 – Planejamento de respostas a riscos
11.6 – Monitoração e Controle de Riscos
Entregas
Plano de resposta ao riscos
26/02/2015
61
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
 Evento: O que pode ocorrer, composto por causa e efeito;
 Probabilidade: Chance de um evento ocorrer;
 Impacto: O que vai causar. Extensão de perda ou ganho resultante da ocorrência do evento de um risco.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
 Evitar ou prevenir:
 Impedir que um risco aconteça, evitando causar danos para a continuidade do projeto;
 Mitigar:
 Planejar ação para diminuir ao máximo o impacto do risco a continuidade do projeto;
 Transferir:
 Atribuir responsabilidade para outras pessoas do projeto;
 Aceitar:
 Sem alternativas. Normalmente acontece quando o risco não foi identificado ou não tem como ser tratado pelo gerente do projeto.
26/02/2015
62
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
 Exercitar:
 Um membro da equipe descobre que os regulamentos (restrições de circulação, entregas e ruídos) na
região poderiam encarecer o local escolhido que o gerente de projetos planejou usar. É solicitado a
equipe para pesquisar um novo local que não prejudiquem os custos do projeto. Este cenário é um
exemplo de:
 Aceitar
 Transferir
 Mitigar
 Evitar
Engenharia de Software
Gestão de Projetos de Software
Gerência de Riscos:
 Plano de resposta ao riscos:
26/02/2015
63
Engenharia de Software
Gestão de Projetos de Software
Gerência de Aquisições:
 Engloba os processos necessários para compra de produtos e serviços de fora da organização executora
do projeto;
 Avaliar as medidas e os processos que devem ser observados antes do início do processo de seleção dos
fornecedores;
 Analisar os mecanismos para preparação dos processos de aquisições pela empresa pública e pela
iniciativa privada;
 Analisar e comparar os tipos de contratos que deverão ser utilizados.
Engenharia de Software
Gestão de Projetos de Software
Gerência de Aquisições:
Processos
12.1 – Planejamento de aquisições
12.2 – Solicitação
12.3 – Administração de contratos
12.4 – Encerramento de contratos
Entregas
Análise de Fazer ou Comprar
26/02/2015
64
Engenharia de Software
Gestão de Projetos de Software
Gerência de Aquisições:
 Análise de Fazer ou Comprar:
 Determinar se o trabalho será feito pela equipe do projeto ou se será terceirizado. Como decidir?
 Qual será o custo de cada escolha;
 Qual será o tempo de entrega de cada escolha;
 Qual será o impacto de cada escolha no escopo;
 Como será monitorado cada escolha.
Engenharia de Software
FERRAMENTAS DE SOFTWARES PARA GESTÃO DE PROJETOS
26/02/2015
65
Engenharia de Software
FERRAMENTAS DE SOFTWARES PARA GESTÃO DE PROJETOS
Introdução:
 Softwares de apoio com o objetivo de automatizar os processos de gerenciamento de projetos;
 Inicialmente é preciso definir os processos;
 A ferramenta não gerencia o projeto, apenas o automatiza;
 O gerente do projeto é responsável pelo bom andamento do projeto, devendo gerenciar integralmente
o projeto, utilizando as ferramentas para melhorar o controle, a colaboração e o aumento da
produtividade.
Tipos:
 Ferramentas Web;
 Ferramentas Desktop.
Engenharia de Software
FERRAMENTAS DE SOFTWARES PARA GESTÃO DE PROJETOS
Ferramentas Web:
 http://www.archievo.org
 https://www.wrike.com/pt_BR/
 https://www.zoho.com/projects/
 http://goplanapp.com
 http://www.easyprojets.net
 http://www.gotproject.com/
 http://www.thymer.com/
 http://helmricks.weebly.com/project2manage
26/02/2015
66
Engenharia de Software
FERRAMENTAS DE SOFTWARES PARA GESTÃO DE PROJETOS
Ferramentas Desktop:
 http://www.ganttproject.biz/index.php
 http://openproj.org
 http://office.microsoft.com/pt-br/project/
Engenharia de Software
TESTES DE SOFTWARE
26/02/2015
67
Engenharia de Software
TESTES DE SOFTWARE
Engenheiros de Software buscam qualidade (e desenvolvem atividades de garantia de qualidade
e de controle de qualidade) aplicando métodos e medidas técnicas sólidas, conduzindo revisões
técnicas formais e efetuando teste de software bem planejado [Pressman, 2002].
Objetivos Distintos:
 Demonstrar as desenvolvedor e ao cliente que o software atende as requisitos. Significa que deve haver
um teste para cada requisito ou características do sistema. Implica em testes de validação;
 Descobrir situações em que o software comporta-se de maneira incorreta, indesejável ou de forma
diferente das especificações. Implica em testes de defeitos.
Siglas e Abreviações:
 V & V: Validação e verificação;
 VVT ou VV & T: Validação, verificação e testes.
Engenharia de Software
TESTES DE SOFTWARE
Conceitos:
 Validar: visa assegurar que o software corresponda aos requisitos estabelecidos.
 estamos construindo o produto certo?
 Verificação: visa assegurar que o software seja desenvolvido de modo apropriado e consistente.
 estamos construindo o produto da maneira certa?
 Teste: visa examinar o comportamento do software através de sua execução.
26/02/2015
68
Engenharia de Software
TESTES DE SOFTWARE
Conceitos:
 Falta (FAULT): defeito, deficiência física ou algorítmica que pode gerar uma falha;
 Erro (ERROR): item de informação ou estado de execução inconsistente. Diferença entre o valor obtido e
o esperado;
 Falha (FAILURE): incapacidade de um sistema desempenhar a função exigida, violando suas
especificações.
Falta Erro Falha
Engenharia de Software
TESTES DE SOFTWARE
Atividades de Teste de Software:
 Os testes de software tem como objetivo causar falhas em um software;
 Testes podem somente mostrar a presença de erros, não sua ausência [Dijkstra et al., 1972];
 A depuração é uma consequência dos testes. Após confirmar a presença de falha, o mesmo deve ser
encontrado e corrigido;
26/02/2015
69
Engenharia de Software
TESTES DE SOFTWARE
Atividades de Teste de Software:
 A inexistência de falhas em um software pode ser
explicado como:
 Software de alta qualidade?
 Os testes foram de baixa qualidade?
Engenharia de Software
TESTES DE SOFTWARE
Atividades de Teste de Software:
 Para garantir a qualidade dos testes, deve-se incluir:
 Planejamento de testes;
 Projeto de caso de teste;
 Execução e avaliação de resultados.
26/02/2015
70
Engenhariade Software
TESTES DE SOFTWARE
Defeitos durante o processo de desenvolvimento:
Diversas transformações de um requisito de software:
Defeitos tendem a aparecer e/ou a propagar durante as transformações.
Descrição Textual
Casos de uso
Diagramas 
Codificação
Engenharia de Software
TESTES DE SOFTWARE
Exercício de Sala:
 Dada a especificação abaixo [Sommerville, 1996]:
 Um sistema para emissão automática de passagens de trem deve ser construído. Os usuários selecionam seu
destino desejado e fornecem um número de cartão de crédito. O bilhete é emitido e seu preço é descontado no
cartão de crédito fornecido. Quando o usuário aperta o botão «início» é mostrado um menu com vários destinos
possíveis e mensagem solicitando ao usuário que escolha um destino. Depois que o destino foi escolhido, é
solicitado ao usuário que entre com o cartão de crédito. A validade do cartão é verificada e em seguida é solicitado
ao usuário um número de identidade (CPF ou RG). O bilhete é emitido após a transação de crédito ter sido
validada.
 Descubra ambiguidades e omissões;
 Reescreva-a eliminando os problemas encontrados.
 Envie para o e-mail do docente.
26/02/2015
71
Engenharia de Software
TESTES DE SOFTWARE
Níveis de Teste de Software:
 Os testes devem ser executados em diversos níveis, com o objetivo de avaliar o softwares em diferentes
momentos durante o ciclo de vida de desenvolvimento do software:
 Testes de Unidade: as menores unidades funcionam corretamente?
 Testes de Integração: quando integradas as unidades continuam a produzir o resultado esperado?
 Testes de Validação: o programa produz o resultado esperado pelo usuário?
 Testes de Sistema: o programa funciona como esperado em seu ambiente como um todo?
Engenharia de Software
TESTES DE SOFTWARE
Técnicas de Testes de Software:
 Teste de Caixa Branca: baseado em estrutura, ou seja, na análise da estrutura interna de um
componente ou sistema;
 Teste de Caixa Preta: baseado na especificação, ou seja, na validação dos requisitos funcionais sem se
prender ao funcionamento interno do sistema.
26/02/2015
72
Engenharia de Software
TESTES DE SOFTWARE
Técnicas de Testes de Software:
 Teste de Caixa Branca: baseado em estrutura, ou seja, na análise da estrutura interna de um
componente ou sistema.
 Teste e cobertura de comandos;
 Teste e cobertura de decisão;
 Baseadas na experiência.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Comandos:
 Definir casos de teste que executem todos os comandos pelo menos uma vez (passa por todos os nodos do grafo);
 Métrica: número de nodos cobertos;
 Fácil de ser satisfeito;
 Não garante a qualidade do código.
26/02/2015
73
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Comandos
 Exemplo 1:
1. a = Integer.parseInt(args[0]);
2. b = Integer.parseInt(args[1]);
3. while(a < 0){
4. if (b < 0){
5. b = b + 2;
6. }
7. a = a + 1;
8. }
9. c = a + b;
Um teste é o suficiente
a b c
(resultado)
-1 -1 1
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Comandos
 Exemplo 2:
 Se você estiver voando com um bilhete da classe econômica, há uma possibilidade de você conseguir
mudar para a classe executiva. Principalmente se você tiver um cartão fidelidade da companhia aérea.
Se você não tiver o cartão fidelidade (CF), há a possibilidade de você ser "despejado" do voo se ele
estiver lotado e você chegar atrasado.
26/02/2015
74
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Comandos
 Exemplo 2:
Três testes foram executados:
 Teste 1: O passageiro tem o CF e mudou para a
classe executiva;
 Teste 2: O passageiro não tem o CF e
permaneceu na classe econômica;
 Teste 3: O passageiro foi "despejado" do voo.
Qual é a cobertura de comando obtida com esses
três testes?
a) 60%.
b) 70%.
c) 80%.
d) 90%.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Comandos
 Exemplo 2:
Resolução: c) 80%.
26/02/2015
75
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Decisão:
 Teste de decisão é uma forma de teste de controle de fluxo, já que ele gera um fluxo específico através dos pontos
de decisões;
 Uma decisão é um IF, um loop (ex. do-while ou repeat-until), ou um CASE, no qual existem duas ou mais
possibilidades de saídas ou resultados a partir de um comando
 Os testes devem cobrir cada saída possível de um nodo que tenha uma condição;
 Teste de decisão derivam-se dos casos de testes para executar decisões específicas, normalmente para se
aumentar a cobertura;
 A cobertura de decisão é mais eficiente que a cobertura de comandos.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Decisão
 Exemplo 1:
1. a = Integer.parseInt(args[0]);
2. b = Integer.parseInt(args[1]);
3. while(a < 0){
4. if (b < 0){
5. b = b + 2;
6. }
7. a = a + 1;
8. }
9. c = a + b;
Necessário Três Testes
a b c
(resultado)
-1 -1 1
0 0 0
-1 0 1
26/02/2015
76
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Decisão
 Exemplo 2:
 Se você estiver voando com um bilhete da classe econômica, há uma possibilidade de você conseguir
mudar para a classe executiva. Principalmente se você tiver um cartão fidelidade da companhia aérea.
Se você não tiver o cartão fidelidade (CF), há a possibilidade de você ser "despejado" do voo se ele
estiver lotado e você chegar atrasado.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Teste e Cobertura de Decisão
 Exemplo 2:
Três testes foram executados:
 Teste 1: O passageiro tem o CF e mudou para a
classe executiva;
 Teste 2: O passageiro não tem o CF e
permaneceu na classe econômica;
 Teste 3: O passageiro foi "despejado" do voo.
Qual é a cobertura de decisão obtida com esses
três testes?
a) 50%.
b) 60%.
c) 70%.
d) 80%.
26/02/2015
77
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Branca:
 Baseadas na experiência:
 Suposição de erro:
 Depende muito da habilidade e experiência do testador;
 Não há regras para a suposição de erro;
 Deve ser usada sempre como um complemento à outras técnicas mais formais.
 Teste exploratório:
 É uma abordagem muito usual, em locais onde a especificação é rara ou inadequada e existe grande pressão por
conta de prazo, ou para aprimorar/complementar um teste mais formal;
 Pode servir como uma checagem do processo de teste, assegurando que os defeitos mais importantes sejam
encontrados;
 Deve ser usada sempre como um complemento à outras técnicas mais formais.
Engenharia de Software
TESTES DE SOFTWARE
Técnicas de Testes de Software:
 Teste de Caixa Preta: baseado na especificação, ou seja, na validação dos requisitos funcionais sem se
prender ao funcionamento interno do sistema.
 Partição de equivalência;
 Análise do valor limite;
 Tabela de decisão;
 Teste de transição de estados;
 Teste de caso de uso.
26/02/2015
78
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Partição de equivalência:
 Aplicada em qualquer nível de teste;
 Muitos testadores aplicam ela sem saber (informalmente);
 A ideia é dividir (particionar) as entradas em grupos que tenham um comportamento similar, podendo ser tratados
da mesma forma
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Partição de equivalência:
 Passo a Passo:
1) Decompor o programa em funções;
2) Identificar as variáveis que determinam o comportamentode cada função;
3) Particionar os valores de cada variável em classes de equivalência (válidas e inválidas);
4) Especificar os casos de teste:
a) eliminar as classes impossíveis ou os casos desinteressantes;
b) selecionar casos de testes cobrindo as classes válidas das diferentes variáveis;
c) para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez.
26/02/2015
79
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Partição de equivalência
 Exemplo 1:
Vamos imaginar que esse delicioso ao lado, tem 6 sabores:
chocolate, nozes, morango, maracujá, baunilha e limão. Quantos
testes são necessários, usando a técnica de partição de
equivalência?
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Partição de equivalência
 Exemplo 2:
Um programa valida um campo numérico da seguinte maneira:
 Valores inferiores ou iguais a 0 são rejeitados, valores entre 1 e 130 são aceitos, valores maiores ou iguais a 131 são
rejeitados. Qual das alternativas contém os valores de entrada que cobre todas as partições de equivalência?
a) -1, 50, 120.
b) 0, 1, 131.
c) -131, 65, 130.
d) 10, 130, 200.
26/02/2015
80
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Partição de equivalência
 Exemplo 2:
Resolução: b) 0, 1, 131.
Ela é a única que cobre as três partições:
 Partição inválida (abaixo do valor mínimo) <=0;
 Partição válida 1 <> 130;
 Partição inválida (acima do valor máximo) >=131.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite:
 Limites são áreas onde os testes estão mais propensos a indicar defeitos;
 Os valores limites de uma partição são seu máximo e seu mínimo.
26/02/2015
81
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite
 Exemplo 1:
Voltando ao exemplo do bolo...
Agora vamos considerar que cada “camada” do bolo tem 10cm.
Desta maneira, o nosso bolo tem 60cm, sendo composto de:
 10cm de chocolate;
 10cm de nozes;
 10cm de morango;
 10cm de maracujá;
 10cm de baunilha;
 10cm de limão.
Portanto, agora é a hora de fazer um teste mais “guloso”...
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite
 Exemplo 1:
No teste anterior...
Particionamos o bolo em 6 pedaços de bolo e comemos cada
pedaço, para verificar se o bolo contém os seis sabores mesmo.
Agora...
Além de verificar se o bolo contém os seis sabores, vamos
verificar se cada sabor tem exatamente 10 cm de altura. Como
teste iremos usar a técnica de análise do valor limite, irá resultar
em 24 entradas diferentes.
26/02/2015
82
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite
 Exemplo 1:
Entendo melhor...
Usando a análise de valor limite são 14 pedaços de bolo, necessários
para o teste. O motivo para esse resultado é:
Assim sendo iremos cortar os seguintes centímetros do bolo: 0, 1, 10,
11, 20, 21, 30, 31, 40, 41, 50, 51, 60 e 61. Logo, teremos 12 pedaços
de bolo e mais 2 “pedaços” vazios, que são equivalentes aos valores
inferiores inválidos 0cm e 61cm. Totalizando 14 pedaços. BOM
APETITE!
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite
 Exemplo 2:
Um campo de entrada (Input Field) referente a data de nascimento, aceita valores de 1860 até 2860. Utilizando a
análise do valor limite o teste usaria quais valores?
a) 0, 1860, 2860, 3000.
b) 1860, 2860.
c) 1859, 1900, 1861, 2859, 2860, 2861 .
d) 1859, 1860, 2860, 2861.
26/02/2015
83
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Análise do valor limite
 Exemplo 2:
Resolução: d) 1859, 1860, 2860, 2861.
 1859 = valor limite mínimo inválido;
 1860 = valor limite mínimo válido;
 2860 = valor limite máximo válido;
 2861 = valor limite máximo inválido
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Tabela de decisão:
 Foco nas regras de negócio;
 As condições de entrada e ações são declaradas de uma forma que possam ser entendidas, como verdadeiras ou
falsas;
 Conhecida também como “causa e efeito” ou “regressão”;
 O grande ganho na utilização da tabela de decisão, é que ela cria combinações de condições que, geralmente, não
foram exercitadas durante os testes;
 Pode ser aplicada a todas as situações quando a execução do software depende de muitas decisões lógicas.
26/02/2015
84
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Tabela de decisão
 Exemplo 1:
Condição Regra 1 Regra 2 Regra 3 Regra 4
valor > 100 V F V F
quantidade > 100 V V F F
Ações para dar 
brinde
X
Dar desconto X
Mensagem de erro X
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Tabela de decisão
 Exemplo 2:
Qual das alternativas seria um exemplo de teste usando tabela de decisão para uma aplicação financeira, no teste de
nível de sistema?
a) Uma tabela contendo regras para combinações de entrada para dois campos da tela.
b) Uma tabela contendo regras de interface entre componentes.
c) Uma tabela contendo regras para aplicações de hipoteca.
d) Uma tabela contendo regras de xadrez.
26/02/2015
85
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Tabela de decisão
 Exemplo 2:
Resolução: c) Uma tabela contendo regras para aplicações de hipoteca.
 Note que o nível do teste é o de sistema, no qual estamos interessados no funcionamento do sistema como um todo,
não no funcionamento particular de cada componente, que é verificado no teste de componente. E nem estamos
interessados na interface entre os componentes, que é verificada do teste de integração. Logo excluímos as
alternativas: a, b. A alternativa d refere-se as regras comuns de xadrez. Restando apenas a alternativa correta c.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de transição de estados:
 É utilizado quando algum aspecto do sistema pode ser descrito usando uma máquina de estados ;
 O sistema pode ter um número (finito) de estados diferentes, e as transições de um estado para outro são
determinadas por regras de "máquina";
 Muito utilizada em softwares industriais embarcados e automações técnicas em geral, e também adequada para
modelar um objeto de negócio tendo estado específico ou para testar fluxos de telas de diálogos;
 Os testes podem ser construídos para cobrir uma sequência típica de estados, cobrir todos os estados, exercitar
todas as transições, exercitar uma sequência específica de transições ou testar transições inválidas.
26/02/2015
86
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de transição de estados
 Exemplo 1:
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de transição de estados
 Exemplo 1:
Insere cartão Senha OK Senha NOK
E1) Iniciar E2
E2) Esperar senha
E3) 1ª tentativa E6 E4
E4) 2ª tentativa E6 E5
E5) 3ª tentativa E6 E7
E6) Acessar conta
E7) Bloquear cartão E1
26/02/2015
87
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de transição de estados
 Exemplo 2:
Dado o segundo diagrama, qual é o caso de teste que cobre o número mínimo de transações válidas para todos os
estados?
a) SS-S1-S2-S4-S1-S3-ES.
b) SS-S1-S2-S3-S4-ES.
c) SS-S1-S2-S4-S1-S3-S4-S1-S3-ES.
d) SS-S1-S4-S2-S1-S3-ES.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de transição de estados
 Exemplo 2:
Resolução: a) SS-S1-S2-S4-S1-S3-ES.
 As alternativas b e d são inválidas, pois possuem transições que não são possíveis de serem feitas: b S2-S3; d S4-S2.As alternativas a e c são válidas, porém a questão pede o “teste que cobre o número mínimo de transações válidas”.
Logo a alternativa a é a correta, por cobrir o número mínimo de transações válidas.
26/02/2015
88
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de caso de uso:
 Ajuda a identificar casos de testes que exercitam todo o sistema, transação por transação, do início ao fim;
 Baseada em casos de uso;
 Um caso de uso é a descrição de um uso particular do sistema feito por um ator (usuário do sistema);
 Casos de uso muitas vezes são tratados como cenários, e úteis para construir testes de aceite com a participação
do usuário final;
 Eles podem ajudar a descobrir defeitos de integração causados pela interação e interferência de diferentes
componentes, que testes individuais de componentes podem não ter detectado;
 Casos de uso são definidos de acordo com o autor, não com o sistema, descrevendo o que o ator ver, mais do que
as entradas e resultados esperados do sistema;
 Eles costumar usar uma linguagem e termos a nível de negócio, ao invés de termos técnicos, especialmente
quando o ator é parte do negócio.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de caso de uso
 Exemplo 1:
Cenário – criar post (fluxo principal):
 Pré-condição: [A - Ator] [S - Sistema]
 Usuário logado no sistema.
 Cenário:
1) A: Seleciona opção de novo post;
2) S: Abre página para postagem;
3) A: Digita o post;
4) A: Seleciona opção de salvar post;
5) S: Salva o post;
6) S: Carrega página com o post salvo.
26/02/2015
89
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de caso de uso
 Exemplo 1:
Caso de teste – criar post (fluxo principal):
 Pré-condição: [A - Ator] [S - Sistema]
 Usuário logado no sistema.
 Cenário:
1) Clicar no botão “novo post”;
2) Digitar texto;
3) Clicar no botão “salvar como rascunho”.
 Resultado esperado:
 S: Salvar o post e apresentar a página com o post salvo.
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de caso de uso
 Exemplo 2:
Utilizar teste de caso de uso é útil para:
P) Modelar os testes de aceitação com os usuários ou clientes;
Q) Garantir os principais fluxos do negócio serão testados;
R) Achar os defeitos na interação dos componentes;
S) Identificar os valores máximo e mínimo de cada campo de entrada;
T) Identificar a porcentagem de comandos exercitados por um conjunto de testes.
Quais são as afirmativas que representam características do teste de caso de uso?
a) P, Q e R.
b) Q, S e T.
c) P, Q e S.
d) R, S e T.
26/02/2015
90
Engenharia de Software
TESTES DE SOFTWARE
Teste de Caixa Preta:
 Teste de caso de uso
 Exemplo 2:
Resolução: a) P, Q e R.
 O item S faz referência a técnica de análise do valor limite. Já o T refere-se ao teste de comandos. Os demais são
características do teste de caso de uso. Logo, a alternativa correta é: a.
Engenharia de Software
QUALIDADE DO SOFTWARE
26/02/2015
91
Engenharia de Software
QUALIDADE DO SOFTWARE
Conceitos de Qualidade:
 Engenharia de Software é uma tecnologia em camadas que precisa se apoiar em um compromisso
organizacional com a qualidade;
 O principal objetivo da Engenharia de Software (ES) é ajudar a produzir software de qualidade;
 Empresas que desenvolvem software de qualidade são mais competitivas.
Adaptado de Pressman, 2006
Engenharia de Software
QUALIDADE DO SOFTWARE
Conceitos de Qualidade:
 “As pessoas podem comprar um carro na cor que desejarem, contanto que seja preto”.
[Henry Ford]
26/02/2015
92
Engenharia de Software
QUALIDADE DO SOFTWARE
Conceitos de Qualidade:
 “É um conceito complexo que não é diretamente comparável com a qualidade na manufatura”.
[Sommerville, 2007]
 “Conformidade com requisitos funcionais e de desempenho explicitamente declarados, normas de
desenvolvimento explicitamente documentadas e características implícitas, que são esperadas em todo
software desenvolvido profissionalmente”.
[Pressman, 2006]
 “Software que atenda às necessidades do cliente, execute de forma precisa e confiável e gere valor para
todos aqueles que o utilizam”.
[Pressman, 2011]
Engenharia de Software
QUALIDADE DO SOFTWARE
Fatores de Qualidade:
 Fatores Externos:
 Percebidos tanto pelas pessoas que desenvolvem software quanto pelos usuários. Por exemplo: confiabilidade, eficiência e
facilidade de uso são fatores externos.
 Fatores Internos:
 Percebidos apenas pelas pessoas que desenvolvem software. Por exemplo, modularidade e legibilidade são fatores internos.
26/02/2015
93
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Controle da Qualidade:
 Medições locais que são utilizadas para detectar e reparar todos os defeitos ainda remanescentes;
 Evita que produtos defeituosos sejam entregues aos clientes;
 Natureza reativa (ser o efeito; receber; estar sob o controle das coisas);
 Objetiva monitoração de processo, e detecção e correção de defeitos;
 Exemplos: Inspeções, ensaios e testes.
26/02/2015
94
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Garantia de Qualidade:
 Processos que estão destinados a prevenir eventuais defeitos;
 Tenta produzir software com uma baixa taxa de defeitos;
 Natureza proativa (ser a causa; compartilhar, estar no controle das coisas; ser o criador de novas situações)
 Definição de procedimentos, padrões, treinamentos;
 Gerência e melhoria de processo.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Controle da Qualidade x Garantia de Qualidade:
26/02/2015
95
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Dimensões de Qualidade;
 Melhoria de Processos (PDCA);
 Ferramentas de Qualidade;
 Custo da Qualidade;
 Certificações (Exemplo: MPS.br).
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Dimensões de Qualidade:
26/02/2015
96
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA):
 O PDCA implementado conforme as etapas descritas permite
que a empresa esteja constantemente melhorando seus
processos;
 Uma organização que absorve estes conceitos e utiliza estas
ferramentas de maneira sistematizada, amplia sua capacidade
analítica e amadurece sua gestão, avançando no controle de
seus processos.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
1. Identificação do Problema:
 É o resultado indesejado (EFEITO) de um processo;
 É a diferença entre o Resultado Atual e o Resultado Necessário (META).
26/02/2015
97
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
2. Observação ou Análise do Problema:
 Consiste em investigar as características específicas do problema com uma visão ampla e sob vários pontos de
vista;
 Onde está localizado o problema?
 Quais os eventos que mais impactam no problema?
 Quanto representa cada fatia do problema?
 O que devo solucionar primeiro, isto é, o que é prioritário?
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
3. Análise das Causas do Problema:
 Esta etapa busca descobrir as causas fundamentais do problema identificado;
 Analisaras possíveis causas dos problemas, priorizando as principais.
26/02/2015
98
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
4. Preparação do Plano de Ação:
 Quando o problema e suas causas já forem conhecidos, resta determinar as ações ou estratégias que garantam o
alcance dos objetivos desejados. Para cada meta, deve ser feito um Plano de Ação;
 O Plano de Ação é o planejamento de todas as ações necessárias para atingir um resultado desejado.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
4. Preparação do Plano de Ação – EXEMPLO:
 5W2H:
26/02/2015
99
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – PLAN:
4. Preparação do Plano de Ação – EXEMPLO:
 5W2H:
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – DO:
5. Execução do Plano de Ação:
 Deve-se divulgar o plano, explicar o papel de cada um para seu cumprimento e treinar os envolvidos;
 Durante a fase de execução deve-se avaliar periodicamente o resultado dos indicadores atribuídos ao problema
e checar o status das ações previstas no Plano de Ação.
26/02/2015
100
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – CHECK:
6. Verificação dos Resultados:
 Periodicamente deve-se verificar o alcance das metas e a situação de execução das ações;
 Se as metas estabelecidas não estiverem sendo atingidas, deve ser elaborado um plano complementar, resultado
de um novo giro do PDCA.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – ACTION:
7. Análise de desvios e implantação de ações corretivas:
 Trata-se da análise dos resultados. Deve-se fazer uma análise das etapas executadas e recapitular todo processo
de solução do problema. Caso seja necessário, deve-se implantar ações corretivas.
26/02/2015
101
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Melhoria de Processos (PDCA) – ACTION:
8. Padronização:
 Trata-se da padronização do novo modelo de execução das atividades relacionadas aos problemas solucionados;
 Nesse momento devem ser atualizados os novos fluxogramas, procedimentos, normas, entre outros que foram
envolvidos no processo.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
1. BRAINSTORMING:
 O Brainstorming é um método de geração coletiva de novas ideias através da contribuição e participação de
diversos indivíduos inseridos num grupo;
 O Brainstorming é um exercício de geração de ideias. Não espere que a ideia final seja obtida durante ou após a
sessão. O resultado de um bom “temporal de palpites” é gerar uma boa quantidade de boas ideias brutas que
depois precisam ser lapidadas.
26/02/2015
102
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
1. BRAINSTORMING – Regras Básicas:
 Críticas são proibidas: Adiar o julgamento das ideias, pois as críticas tendem a inibir a criatividade;
 Disparates são bem-vindos: Por mais absurda que seja a ideia, é preciso que seja revelada;
 Quanto mais ideias, melhor: A quantidade leva à qualidade;
 Procure combinações e melhorias: Metáforas, associações, analogias e perguntas (“e se….?” e “Por que não?”)
 Pode ser realizada de forma:
 Estruturada: todas pessoas do grupo devem dar uma ideia a cada rodada;
 Não Estruturada: as pessoas do grupo dão as ideias conforme elas surgem em suas mentes.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
1. BRAINSTORMING – Orientações Gerais:
 Escolha um local agradável para a reunião e disponha as cadeiras em semicírculo – se possível sem mesas, um quadro
para anotações, post-it e canetas coloridas;
 Apresente o problema central iniciando com a frase: “De quais maneiras podemos…”. Assim você já indica que é possível
mais de uma resposta;
 Estabeleça um tempo de 15 minutos para a atividade;
 O grupo deve ser pequeno (ter de quatro a seis pessoas);
 Defina um coordenador, ou seja, a pessoa que irá conduzir a atividade;
 Quanto mais diversificado o grupo, maiores as chances de “novas boas ideias”;
 Promova um ambiente de bom humor, espontaneidade e descontração;
 Quando as pessoas começarem a expor suas ideias, o coordenador deve escrever no quadro ou pedir que falem em voz
alta e que depois escrevam as ideias nos post-it e, em seguida, colem no quadro;
 Após o tempo estimulado, reúna as ideias por categoria e selecione as mais viáveis com base no objetivo, impacto,
implantação, urgência e recursos.
26/02/2015
103
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
1. BRAINSTORMING – Exemplo:
 Tema: Causas de fila em bomba de posto de gasolina.
 Equipe: Gerente do posto, Frentista, Encarregado das compras e Responsável pelos Frentistas.
 Líder ou condutor da sessão: Gerente de Recursos Humanos.
 Ideias de Brainstorming: Possíveis causas para fila em bomba de posto de gasolina?
Número de bombas insuficientes;
 Baixa vazão das bombas;
 Frentistas em número insuficiente;
 Frentistas mal treinados;
 Layout das bombas inadequado;
 Poucas linhas telefônicas para pagamento por cartão de débito ou de crédito;
Nota fiscal demora a ser emitida;
 Serviços adicionais realizados pelo frentista (limpeza de vidros, checagem de óleo, entre outros).
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
2. FLUXOGRAMA:
 Um fluxograma é uma sequência lógica de procedimentos inter-relacionados cujo objetivo é orientar a execução
de uma tarefa ou atividade.
26/02/2015
104
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
2. FLUXOGRAMA – Lógica de Elaboração:
a) Fazer um rascunho com a visão global do sistema;
b) Passar a limpo o primeiro rascunho e verificar a visão global;
c) Submeter o fluxograma à crítica e análise de outros analistas e do(s) usuário(s);
d) Verificar a necessidade de alterações e incluí-las se for o caso;
e) Elaborar o desenho final.
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
2. FLUXOGRAMA – Símbolos Padronizados:
26/02/2015
105
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
2. FLUXOGRAMA - Exemplo:
 Exemplo de um fluxograma de um cliente em um restaurante.
Engenharia de Software
QUALIDADE DO SOFTWARE
26/02/2015
106
Engenharia de Software
QUALIDADE DO SOFTWARE
Melhoria de Qualidade:
 Qualidade Total (Melhoria Contínua):
 Ferramentas de Qualidade:
3. DIAGRAMA DE CAUSA E EFEITO (ESPINHA DE PEIXE):
 O Diagrama de Causa e Efeito é uma ferramenta que representa a relação entre o “efeito” e as possibilidades de
“causa” que podem contribuir para tal resultado;
 Também conhecido como “Espinha de