Análise e Projeto de Sistemas II<br />Prof.a Márcia Rabello<br />marcia@imed.edu.br<br />
Perfil do gerente empreendedor<br />Empregado (Gerente) vira Empresário (Empreendedor)<br />
O ser EMPREENDEDOR <br />Empreendedor é o Individuo preparado para  <br />Identificar oportunidades <br />Assumir riscos  ...
Atitude Empreendedora<br />Praticar Networking<br />Ser Proativo<br />Disposição em assumir riscos calculados<br />Postura...
Atitude- Proativo<br />Missão = Tarefa + Objetivo<br />Tarefa – “o que fazer?”<br />Eficiência - Fazer certo as coisas<br ...
Você acha certa a afirmativa abaixo?<br />“Faça o que o cliente precisa(e não o  que ele pede)”<br />6<br />www.NewtonBrag...
Atitude- Disposição em assumir Riscos Calculados<br />Risco<br />Se der errado será acusado (pelo chefe, colegas, subordin...
Identificamos o empreendedor pelo seu perfil, não pela atividade que exerce<br />
Atividade<br />Pense numa pessoa que você conhece pessoalmente e considera empreendedora.<br />Liste, no mínimo, 5 caracte...
Características do empreendedor<br />Capacidade de assumir riscos<br />Aproveitar oportunidades<br />Conhecer o ramo<br />...
Características do empreendedor<br />Das qualidades empreendedoras que vimos, quais são aquelas com que nós nascemos?<br /...
Que características você tem?<br />Para cada uma das características empreendedoras, reflita como elas estão sendo desenvo...
O gerenciamento de Projetos em TI<br />
Importância da Análise<br />Manutenção<br />Manutenção<br />Teste<br />Implantação<br />Implantação<br />Programação<br />...
Imaginando as três caixas<br />Análise do Sistema<br />Implementação <br />e Implantação<br />Gerência do Projeto<br />
O que é inovação<br />Edivandro Carlos Conforto<br />PhD Research Candidate<br />
Quebra de paradigma<br />
Gerenciamento ágil de projeto<br />
Exceto atividades de análise, projeto e desenvolvimento propriamente dito, que envolvem metodologias, técnicas e ferrament...
O que é o PMBOK ?( Project Management BodyofKnowledge )<br />Um guia que pretende reunir o conhecimento geral sobre metodo...
Quem deve ocupar o cargo de gerente de projetos ?<br />Preferencialmente um profissional ligado a tecnologia da informação...
PMBOK<br />Tem como objetivo a melhoria do processo de Gerência de Projetos<br />Abrange 9 áreas de conhecimento:<br />Ger...
Ciclo de vida de um projeto<br />Pmbok<br />
Processo básico<br />
PMBOK<br />Áreas Núcleo<br />GERÊNCIA DA QUALIDADE<br />GERÊNCIA DO CUSTO<br />GERÊNCIA DO TEMPO<br />GERÊNCIA DO ESCOPO<b...
PMBOK - Utilização <br />Focado em Gerência de Projetos<br />Não possui processo de avaliação formal para a organização  <...
Envolvidos nas fases<br />
Conseqüências de uma análise inadequada<br />   o aumento dos custos<br />  realização de atividades desnecessárias<br...
Gerência do projeto de software<br />Tonsig, 2003.<br />
Etapas de processos gerenciais<br />Tonsig, 2003.<br />
“ item de Avaliação da Disciplina”Trabalho individual ou dupla<br /> Realizar uma síntese sobre o Modelo CMMI, MPSBR, ISO ...
Situação Atual das Organizações<br />Demanda por Melhor Qualidade!<br />melhor qualidade inclui:<br />menos prazos, custos...
Situação Atual das Organizações<br />  Como as empresas de software podem obter a melhoria viável e necessária?<br />Melho...
 POG - Programação orientadas a gambiarras<br />
37<br />A Comunicação... Um problema...<br />
O que é Qualidade ? <br />
O que é qualidade ?<br />“Qualidade consiste em desenvolver, criar e<br />fabricar mercadorias mais econômicas, úteis e<br...
O que é qualidade ?<br />“Qualidade é o conjunto de características<br />do produto que determinam o grau de<br />satisfaç...
O que é qualidade ?<br />“A QUALIDADE somente pode ser definida em termos de quem a avalia.” <br />DEMING<br />
Qualidade de Software<br />Visão do produto pela qual qualidade está relacionada a características do produto. (PFLEEGER)<...
O que é qualidade ? Conceitos e tipos de clientes<br />“A QUALIDADE é tudo que alguém faz ao longo do processo para garant...
Conceitos e tipos de clientes<br />“A QUALIDADE é tudo que alguém faz ao longo<br />do processo para garantir que um clien...
Outras definições ...<br /><ul><li>“QUALIDADE é a aptidão para o uso. Sua avaliação baseia-se no fato de que o produto est...
“QUALIDADE não é somente satisfazer o cliente, mas sim seduzi-lo.” (TOM PETERS)</li></li></ul><li>Outras definições ...<br...
Qualidade e Produtividade<br />Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significam s...
Qualidade e produtividade<br />Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremen...
 Diminuição de custos de panes e paralisações;
 Nível de serviço prestado ao cliente (confiabilidade);
 Rapidez de resposta aos clientes e às pressões externas.</li></li></ul><li>Realidade X qualidade<br /><ul><li> Muitos ges...
 Não consideravam o fato de gastar entre 40% e 50% de seus recursos produtivos em retrabalho,  conserto de um defeito no s...
Maior Produtividade<br />QUALIDADE !!<br />Ser Competitivo<br />Garantir a Sobrevivência<br />
Certificação de Qualidade<br />Confrontação das práticas de definição de processos e elaboração de produtos com uma Norma ...
Controle de Qualidade<br />É a atividade e técnica operacional utilizada para satisfazer os requisitos de qualidade segund...
Garantia de Qualidade<br />É uma atividade aplicada ao longo do processo de Engenharia de Software. <br />Consiste dos pro...
55<br />Características de Qualidade na Web<br />(Olsina, 99)<br />
Qualidade na Web (Offut 2002)<br />56<br /><ul><li>Segurança
Disponibilidade – 24H-7-365D
Escalabilidade/Desempenho
Prazo de colocação no mercado</li></ul>como atender a estas especificações?<br />
Melhoria<br />Melhoria de Processo de Software, é uma abordagem baseada em processos, para melhoria de uma organização.<br...
Processo de Software<br />É o que as pessoas fazem, utilizando procedimentos, métodos e ferramentas, para adquirir, desenv...
Melhoria de Processo de Software<br />Ações realizadas para alterar os processos de uma organização para que eles satisfaç...
Benefícios da Melhoria doProcesso de Software<br />
Qualidade do produto x Processo<br />A qualidade do produto de software é altamente determinada pela qualidade do processo...
Premissas da Qualidade<br /><ul><li> Deve estar inserida já nas primeiras fases do ciclo de vida do desenvolvimento de sof...
Envolvimento de todas as pessoas (desde a alta administração até os técnicos);
Treinamento e comunicação;
Planejar e estimar prazos.....
Gerência de Projetos
Estratégias da Tecnologia da Informação
Gerenciamento de Custos
Gerenciamento de Recursos Humanos
Gerenciamento de Riscos
Gerenciamento de Aquisições </li></li></ul><li>Qualidade e produtividade<br />Qualidade e produtividade na produção de ser...
Qualidade e Produtividade<br />   Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significa...
A Norma ISO 9000-3<br />Grupo<br />Atividade<br />Estrutura do Sistema de Qualidade<br />Responsabilidade do fornecedor, R...
A Norma ISO 9000-3 - Utilização <br />Possui processo de certificação formal<br />Implementação por completo<br />Permite ...
A Norma ISO 12207 - Processos do Ciclo de Vida do Software<br />Esta Norma, lançada em 1995, formaliza a arquitetura do Ci...
Qualidade do Processo<br />P<br />R<br />O<br />C<br />E<br />S<br />S<br />O<br />D<br />E<br />A<br />D<br />A<br />P<br...
VV&T e a norma ISO/IEC 12207<br />Verificação<br />Verificação do contrato<br />Verificação do produto<br />Verificação do...
A Norma ISO 12207 - Utilização<br />Possui processo de certificação formal<br />Implementação por completo<br />Permite me...
Responda<br />A atividade de teste de software no processo de desenvolvimento deve ser aplicada em que momento ? <br />Ape...
CapabilityMaturityModel - CMM<br />   É um modelo, desenvolvido pelo SEI para avaliação e melhoria da capacitação das empr...
Maturidade 	<br />A maturidade dos processos possui grande influência em:<br />Metas de custos<br />Cronogramas <br />Qual...
Organizações Maduras<br />Organizações Imaturas<br />Papéis e Responsabilidades bem definidos<br />Processo improvisado<br...
CMM – Níveis de Maturidade<br />Nível CMM<br />Descrição<br />Inicial<br />Processo desorganizado. Poucos processos defini...
Principais atividades para controle e garantia da qualidade<br />Verificação<br />Validação<br />Testes<br />
CMM<br />Processo continuamente aprimorado<br /><ul><li>Prevenção de defeitos
Gerência de mudançastecnológicas
Gerência de mudanças no processo</li></ul>Otimizado<br />5<br />Processo previsível<br />Gerenciado<br />4<br /><ul><li>Ge...
Gerênciadaqualidade de software
Foco no processo
Definição do processo
Programa de treinamento
Administração de software integrada
Engenharia de produtos
Coordenação entre grupos
Revisões</li></ul>Processo consistente, padrão<br />Definido<br />3<br />Repetitível<br />2<br />Processodisciplinado<br /...
Planejamento de Projetos
Acompanhamento de projetos
Gerência de subcontratos
Garantia de qualidade
Gerência de configuração</li></ul>Inicial<br />1<br />CMM - Áreas -Chave de Processo<br />São os itens a serem focados pel...
CMM - Características Comuns e Práticas-Base<br />Práticas-Base relacionadas <br />Estabelecimento de políticas<br />Carac...
CMM - Utilização <br />Possui processo de avaliação formal<br />É didático e conhecido no mercado empresarial <br />Permit...
Nome<br />Nível<br />Atividades<br />Medição Pessoal<br />PSP0<br />Registro de Tempo, Registro de Defeitos, Padrão de Tip...
Personal Software Process - PSP<br />
PSP - Utilização <br /><ul><li>Não possui processo de avaliação formal
Permite implementações por níveis
Permite melhoria de alguns processos para garantia de qualidade
Permite estabelecimento de alguns controles
Identifica pontos forte do indivíduo assim como oportunidades de melhoria
Custo mais reduzido
Normalmente utilizado em pequenas organizações</li></li></ul><li>ISO 15504<br />Constitui-se de um padrão para avaliação d...
Descrição<br />Adquirir software, Gerenciar necessidades do cliente, Fornecer Software, Operar software, Prover serviço ao...
ISO 15504 - Níveis de Capacitação<br />Processo<br />Descrição<br />Incompleto<br />Não existem produtos de trabalho nem s...
ISO 15504<br />ProcessosFundamentais<br />Processos de Apoio<br />Documentação<br />Fornecimento<br />Aquisição<br />Ger. ...
ISO 15504 - Utilização<br />Possui processo de certificação formal <br />Ainda não está muito difundido no meio empresaria...
Qualidade de Software X CMMI<br />88<br />
Capability...<br />Capacidade?<br />Capacitação?<br />“Capabilidade”?<br />89<br />Qualidade que uma pessoa ou coisa tem d...
CMMI<br />Foi criado para resolver o problema de existirem múltiplos CMM´s<br />Sua missão é combinar o SW-CMM (Capability...
Considerações <br />Trabalhar com avaliação oferece capacidade para as empresas desenvolverem futuros projetos de uma form...
Pense ...<br />O CMMI é apenas para software?<br />O CMMI não descreve processo algum, apenas define orientações  através ...
Capability...<br />Software processcapability - descreve o intervalo de resultados esperados que podem ser alcançados segu...
Origem<br />“Não há nada de novo no CMMI (i de integration)”<br />94<br />
Origem<br />O SEI estruturou o CMM para contratação de grandes projetos de software<br />Hoje, porém, o CMM e o CMMI são u...
CMMI – dupla representação<br />ContinuousRepresentation<br /><ul><li>Níveis de Capacidade
Agrupamento das Áreas de ProcessoporCategoria
Avaliaçãodacapacidade das Areas de Processo</li></ul>CMMI<br />StagedRepresentation<br /><ul><li>5 níveis (estágios) de Ma...
Agrupamento de Áreas de ProcessoporNível
AvaliaçãodaOrganizaçãocomo um todo</li></ul>Estágio – para estar no nível 1 basta desenvolver software<br />96<br />
Comparando as Representações<br />Staged<br />ML5<br />Process Area Capability<br />ML4<br />0    1   2    3    4    5<br ...
B<br />D<br />A<br />C<br />O foco<br />o foco está nos processos, pq a idéia é se tem um processo falho provavelmente ter...
99<br />Premissa do Gerenciamento do Processo de Software<br />A qualidade de um sistema de software é altamente influenci...
Processo em perspectiva<br />100<br />Este componente permanece na organização!<br />Organização<br />Tecnologia<br />Pess...
Por que o foco está no processo?<br />102<br />Processo de software<br />Requisitos<br />Software<br />
Por que o foco está no processo?<br />103<br />a<br />a<br />a<br />x<br />Requisitos<br />Software<br />
Por que o foco está no processo?<br />104<br />a<br />a<br />a<br />a<br />Software<br />Requisitos<br />O fato de ter um ...
Considerações<br />106<br />Quando tudo é importante.... Nada é importante!<br />Por isso é necessário seguir um processo<...
CMMI<br />O CMMI diz “o que” e não “COMO”<br />Supri as limitações do CMM, permitindo a inclusão de novos modelos ao longo...
Níveis de maturidade<br />Formados por um conjunto predefinidos de áreas de processo.<br />Como realiza-se a medição<br />...
CMMI  - Continuous<br />Área de Processo 2<br />Área de Processo 1<br />Área de Processo 3<br />Objetivos Específicos<br /...
CMMI - Contínuo<br />Uma organização pode escolher melhorar o desempenho de um único ponto problemático<br />
CMMI - Contínuo<br />Process  Area Capability<br />0    1   2    3    4    5<br />PA<br />PA<br />PA<br />Áreas do Process...
Exemplo de área de processo e Capacidade<br />CAPACIDADE<br /><ul><li>Baseado ISO15504
6 níveis de maturidade
 onde qualquer área do processo pode ter sua</li></li></ul><li>Os níveis de capacidade são Acumuladtivos<br />
Área de Processo - Engenharia<br />Gerenciamento de requisitos<br />Desenvolvimento de requisitos<br />Solução técnica<br ...
CMMI  - Staged<br />Nível de Maturidade<br />Área de Processo 2<br />Área de Processo 1<br />Área de Processo 3<br />Objet...
Níveis de Maturidade<br />
Componentes CMMI - estágios<br />Áreas de Processo (PA)<br /> Metas específicas (SG)<br /> Práticas específicas (SP)<br />...
CMMI - Utilização <br />Possui processo de avaliação formal<br />Permite implementação contínua<br />Permite implementaçõe...
Método de avaliação<br />SCAMPI - Standard CMMI Assessment Method for Process Improvement:<br />Desenvolvido pelo Software...
CMM x Testes <br />PAs (Áreas de Processo)  relacionadasestritamente a testes:<br />VAL – Validação<br />VER – Verificação...
Áreas de processos relacionadas a teste de software (CMMI x TESTES)<br /><ul><li> Integração do Produto (PI)
 Verificação (VER)
 Validação (VAL)</li></ul>nível 3<br />
Áreas de Processo do modelo CMMI - Nível 3<br />
123<br />CMMI<br />TSP<br />PSP<br />Team Software Process &Personal Software Process<br />
Resumo (principais conceitos)<br />O que é o CMMI?<br />Quais os principais componentes do CMMI?<br />Para que serve o CMM...
Questionamentos<br />Qual deles escolher?<br />Quando utilizar?<br />Como utilizar?<br />
Resumo<br />Compreensão prévia dos processos da organização<br />Identificação dos pontos fortes<br />Identificação das op...
Resumo<br />Identificação do objetivo da organização<br />Certificação/avaliação<br />Controle<br />Garantia de Qualidade<...
Plano de Ação<br />Determinar o contexto onde se aplicará a melhoria<br />Definir "patrocinadores"  <br />Montar a infra-e...
Algumas “dicas”<br /><ul><li> PSP- Organizações de pequeno porte com poucos recursos e que não necessitem de uma certifica...
CMM OU ISO - Organizações de grande porte com possibilidade de alocação de recursos para cuidar dos processos que serão de...
CMM -  É o mais didático se o objetivo for apenas melhoria de processos;</li></li></ul><li>Algumas “dicas”<br /><ul><li>PM...
CMMI ou ISO -  Se há necessidade de avaliação ou certificação ;
CMMI – Se o objetivo for a melhoria de processos em apenas algumas áreas isoladas, o CMMI é próprio para isso.
Se a organização trabalha com soluções sistêmicas
desenvolvimento de software e dispositivos de hardware.</li></li></ul><li>Algumas dificuldades na área de Qualidade<br /><...
A engenharia de software ainda não está madura;
Inexistência de processos definidos;
As pessoas ainda são muito resistentes;
Empresas da região precisam conhecer melhor seus processos
Não há consenso entre os profissionais sobre o que é qualidade;
Restrições quanto a investimentos e recursos...</li></li></ul><li>Testes de Software<br />Conceitos, Princípios e Modelos<...
Relação com outras Disciplinas<br />Engenharia de Software – Metodologias de desenvolvimento de software.<br />Engenharia ...
Qual o perfil de um Eng. de Testes?<br />Conhecimentos de engenharia de software.<br />Ciclo de vida<br />Especificação<br...
Perfil pessoal<br />Paciência / Perseverança / Organização<br />Firmeza de opinião<br />Espírito investigador<br />Capacid...
Para ser um testador, requer um bom entendimento do processo de desenvolvimento e do produto sendo gerado, além da habilid...
Testes de integração<br />CMMIx SCRUM<br />
Categorias de teste de software - Fonte: Bartié (2002).<br />
Esquema de Teste<br />Revisões<br />Revisões<br />Teste estrutural<br />Esse plano, deve descrever a funcionalidade do sof...
Introdução aos testes de software<br />O que é testar?<br />Encontramos na literatura algumas definições sobre que é a ati...
Qual o objetivo dos testes?<br />   O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito ...
Erro, Defeito e Falha<br />Erro (error): é uma ação humana que produz um resultado incorreto.<br />Defeito (fault): A mani...
Erro, Defeito e Falha<br />
Confiabilidade do Software x Defeitos<br />Pode existir um software livre de defeitos?<br /> É possível existir softwares ...
O que provoca erro no software?<br />Especificação de requisitos incorreta,<br />Mudança de requisitos, <br />Projeto inad...
Confiabilidade do Software<br />Nenhuma falha encontrada = confiança<br />
O que é Testes de Software ?<br />"É uma estratégia popular para o gerenciamento de risco".  (LEWIS, 2004, p. 19)<br />O t...
“Teste é o processo de executar um programa com o intuito de encontrar erros”  <br />Glenford J. Myers (1979)<br />
Fluxo da gestão de defeitos<br />Adaptado de Rex Black<br />
Porque defeitos ocorrem no software?<br />Softwares são escritos por humanos<br /> As pessoas não conhecem e não dominam t...
Vale a pena investir em testes?<br /> Reduz em 70% o índice de <br />    re-trabalho de correção de falhas <br /> Reduz em...
Realidade atual do mercado de software<br />Complexidade dos softwares<br /> Complexidade das equipes<br /> Cronograma ape...
O custo da não-qualidade<br /> Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manute...
Por que testar um software?<br />Todo o software visa atender a uma demanda:<br /> Por questão de Qualidade<br /> Por ques...
O custo da correção dos defeitos<br />A regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada ve...
Porque testar é necessário?<br /> Porque é provável que o software possua defeitos;<br /> Para descobrir a confiabilidade ...
Não devemos testar:<br /> Para provar que o software não tem defeitos;<br /> Apenas porque os testes estão incluídos no pl...
A abordagem tradicional dos testes<br />Mostrar que o sistema:<br /> Faz o que deve fazer<br /> Não faz o que não deve faz...
A melhor abordagem para o testes<br />Mostrar que o sistema:<br /> Faz o que não deve fazer<br /> Não faz o que deve fazer...
O paradoxo do teste<br />A proposta do teste é encontrar defeitos<br />Encontrado defeitos a confiança é “destruída”<br />...
Por que as empresas não testam?<br />Software é complexo<br /> Software é intangível<br /> Software é altamente modificáve...
Conceitos iniciais<br />Para que consigamos entender os conteúdos seguintes, é importante termos um perfeito entendimento ...
TMM TestMaturityModel<br />
TMM - TestMaturityModel<br />Modelo de maturidade focado em testes com 5 níveis de maturidade<br />Desenvolvido em 1996 po...
TMM - TestMaturityModel<br /><ul><li>Criado para complementar o CMMI
 Define atividades, tarefas e responsabilidades
Contém um Modelo de Maturidade e um Modelo de Acessibilidade
 O TMM possui cinco níveis de maturidade que refletem o grau de maturidade do processo de teste</li></li></ul><li>TMM - Te...
Os sw são avaliados a partir de critérios de qualidade por características, como reusabilidade, usabilidade e mantenabilid...
Os testes são completamente integrados ao ciclo de vida do software.
Reconhecido em todos os níveis do modelo V.</li></ul>Estratégias baseadas nos riscos<br /><ul><li> mostrar que a aplicação...
TMM – Nível 1<br />Nãoháobjetivos de maturidade<br />Teste é um processocaótico e desorganizado<br />Testesãorealizados de...
TMM – Nível 2<br />Objetivos de teste e de depuraçãosãoestabelecidos<br />Planejamento dos testes<br />Institucionalização...
TMM – Nível 2<br />Realização de objetivos de teste e de depuração:<br />Uma equipe de testes deve ser formado, responsáve...
TMM – Nível 2<br />Planejamento dos testes<br />Estabelecimento do plano de testes organizacional<br />Criação e distribui...
TMM – Nível 2<br />Institucionalização de métodos e técnicasbásicas de teste<br />As técnicas devem ser avaliadas e recome...
TMM – Nível 3<br />Criação de umafábrica de testes (Ambiente)<br />Treinamentostécnicos<br />Integração do processo de tes...
TMM – Nível 3<br />Estabelecimento de umafábrica de testes<br />O grupo de testes é estabelecido, com liderança própria e ...
TMM – Nível 3<br />Programa de treinamentostécnicos<br />Organização e criação de um programa de treinamentos<br />Estabel...
TMM – Nível 3<br />Integração do processo de testes aociclo de desenvolvimento do software<br />A fase de testes deve ser ...
TMM – Nível 3<br />Processo de gerenciamento de riscos<br />Políticas e estratégias para controle das atividades da equipe...
TMM – Nível 4<br />Programasorganizacionais de revisões<br />Programa de medições<br />Avaliaçãodaqualidade do Software<br />
TMM – Nível 4<br />Programasorganizacionais de revisões<br />Programas de revisão devem ser implantados de maneira organiz...
TMM – Nível 4<br />Criação de um programa de medições<br />Políticas organizacionais de medição e análise<br />Definição d...
TMM – Nível 4<br />Avaliaçãodaqualidade do Software <br />As metas de qualidade devem ser definidas <br />atributos de qua...
TMM – Nível 5<br />Aplicação de um processo de prevenção de defeitos<br />Controle de Qualidade<br />Otimização do Process...
TMM – Nível 5<br />Aplicação de um processo de prevenção de defeitos<br />Formação de uma equipe de prevenção de defeitos<...
TMM – Nível 5<br />Controle de Qualidade<br />A equipe de testes e equipe de qualidade <br />Estabelecem as metas como qua...
TMM – Nível 5<br />Otimização do Processo de Testes<br />Ocorre a identificação de práticas que podem ser melhoradas<br />...
Classificação dos Testes<br />Os tipos e técnicas de testes podem ser classificados em:<br />Caixa branca: técnica de test...
Caixa Branca - estrutural<br />Comportamento interno do sw<br />Código fonte:<br />teste de condição, <br />teste de fluxo...
Caixa Preta<br />Caixa preta: são conduzidos na interface do software, sem preocupação com a estrutura lógica interna do s...
Caixa preta – teste funcional<br />O que pode ser testado ? <br />Um método, função interna, um programa, um componente, u...
Mitos sobre testes<br />Alguns mitos sobre a atividade de testes:<br /> O testador é inimigo do desenvolvedor<br /> A equi...
Visão geral de processos<br />Um processo é formado por atividades inter-relacionadas com um objetivo especifico. Possui e...
Visão geral de processos<br />
Processo de teste<br />Cenário atual:<br /> Testes são realizados como uma etapa do processo de desenvolvimento<br /> Pres...
Cenário desejável:<br /> O teste é tratado como um processo independente, porém altamente integrado ao processo de desenvo...
Pontos de verificação<br />Tendo em mãos as planilhas de testes o testador em busca dos erros...<br />Albuquerque, et. All...
Objetivo do processo de teste<br />Permitir o teste de softwares usando pessoal técnico qualificado, ferramentas adequadas...
Verificação e Validação<br />O processo de teste é dividido em duas grandes áreas:<br />Verificação<br />Responde se o sis...
Modelo V<br />A estrutura do modelo V é uma aproximação do processo de testes que pode ser integrada com todo a processo d...
Modelo V<br />Modelagem de Negócios<br />Testes de Aceitação<br />Verificação<br />Análise de Requisitos<br />Testes de Si...
Fluxo básico de atividades<br />
Principais envolvidos no processo de teste<br />
Princípios gerais do teste de software<br />Alguns princípios foram sugeridos ao longo dos últimos 40 anos:<br />Teste dem...
Principais organizações e institutos envolvidos<br />A disseminação dos processos de teste é relativamente nova no Brasil....
A Norma IEEE 829<br />
Exercícios de revisão<br />Indique se é verdadeiro ou falso:<br />a - ( ) O testes devem ser realizados para mostrar a aus...
Considerações<br />Teste é um projeto - e como tal deve ser planejado<br /> Teste é um projeto integrado ao projeto de des...
Limitação<br />  Muitas empresas ainda usam o modelo Waterfall, ou modelo cascata, que foca justamente a atividade de test...
Estratégia, estágios, tipos e técnicas de teste<br />
O que é estratégia de teste?<br /> 	Uma estratégia de testes de software descreve a abordagem geral e os objetivos das ati...
O que deve conter uma estratégia de teste?<br />A estratégia de teste deve responder as perguntas que seguem:<br /> Quando...
Estratégia de teste - Pressman<br />
Estratégia de teste<br />Eng. De sistemas – define o papel sosw, análise dos requisitos, função, comportamento, restrições...
Desenvolvimento da estratégia de teste<br />	Ao elaborar uma estratégia de teste eficiente e eficaz, devemos ter em mente ...
Dimensões de testes<br />Tipos de Teste<br />(O que testar?)<br />Estrutural<br />Funcional<br />Técnica de Teste<br />(Co...
Estágio ou níveis de teste<br />	Estágios ou níveis de teste é a dimensão do teste que trata do “quando testar”, ou seja, ...
Testes Unitários<br />O primeiro nível de teste é o Teste Unitário, que envolve assegurar que cada funcionalidade especifi...
Testes de Iteração ou Integração<br />	Como os componentes são construídos e testados separadamente, ao serem acoplados de...
Testes de Iteração ou Integração - Abordagem<br />Os módulos são integrados movimentando-se de cima para baixo, através da...
Testes de Iteração ou Integração - Abordagem<br />Abordagem Bottom-Up<br />Apropriado para desenvolvimento orientado a obj...
Testes de Sistema<br />   Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a exatidão ...
Tipos de Testes de Sistema<br />	Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a ex...
Teste de Aceitação<br />	Último nível de testes antes da implantação do software em ambiente de produção. Seu objetivo é v...
Dimensão 2: Tipos de Teste<br />	Todo software visa atender uma demanda de qualidade, e para isso deve atender a certos at...
Características da qualidade<br />
Características da qualidade<br />A ISO 9126-1 define seis características de qualidade que o software deve atender:<br />...
Upcoming SlideShare
Loading in …5
×

APSI2

3,941 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,941
On SlideShare
0
From Embeds
0
Number of Embeds
39
Actions
Shares
0
Downloads
55
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

APSI2

  1. 1. Análise e Projeto de Sistemas II<br />Prof.a Márcia Rabello<br />marcia@imed.edu.br<br />
  2. 2. Perfil do gerente empreendedor<br />Empregado (Gerente) vira Empresário (Empreendedor)<br />
  3. 3. O ser EMPREENDEDOR <br />Empreendedor é o Individuo preparado para <br />Identificar oportunidades <br />Assumir riscos <br />Errar e apreender com os erros (principalmente dos outros)<br />Má notícia- O emprego esta sumindo<br />Boa notícia - As oportunidades de trabalho não !<br />Entretanto, é necessário novas habilidades para aproveitá-las<br />3<br />
  4. 4. Atitude Empreendedora<br />Praticar Networking<br />Ser Proativo<br />Disposição em assumir riscos calculados<br />Postura face a desafios e problemas<br />4<br />
  5. 5. Atitude- Proativo<br />Missão = Tarefa + Objetivo<br />Tarefa – “o que fazer?”<br />Eficiência - Fazer certo as coisas<br />Objetivo – “por que fazer?” <br />Eficácia- Fazer as coisas certas<br />Exemplo real <br />Chefe para Técnico de Informática <br />“Leve este CD no cliente e entregue para o chefe das vendas” - Isto é uma tarefa.<br />É mais fácil de se cumprida.<br />É menos arriscada - Fazendo certinho não dá problema (com o chefe)<br />Atitude Empreendedora<br />Empregado pergunta - Porque o cliente precisa deste CD? Resposta do Chefe- “O sistema está trava quando tenta “baixar” a nova lista de preços. Ela deverá ser carregada diretamente do CD no Computador do cliente”<br />5<br />
  6. 6. Você acha certa a afirmativa abaixo?<br />“Faça o que o cliente precisa(e não o que ele pede)”<br />6<br />www.NewtonBragaRosa.com.br - CHA DO EMPREENDEDOR <br />
  7. 7. Atitude- Disposição em assumir Riscos Calculados<br />Risco<br />Se der errado será acusado (pelo chefe, colegas, subordinados etc) de ter ido longe demais...<br />Benefício em assumir risco calculado<br />Maiores benefícios para si e para a empresa<br />Construir relações de longo prazo<br />Indicações de novos clientes<br />Foco no resultado para cliente, empresa ...<br />
  8. 8. Identificamos o empreendedor pelo seu perfil, não pela atividade que exerce<br />
  9. 9. Atividade<br />Pense numa pessoa que você conhece pessoalmente e considera empreendedora.<br />Liste, no mínimo, 5 características empreendedoras que você perceba nela.<br />
  10. 10. Características do empreendedor<br />Capacidade de assumir riscos<br />Aproveitar oportunidades<br />Conhecer o ramo<br />Saber organizar<br />Tomar decisões<br />Ser líder<br />Ter criatividade<br />Ser independente<br />10<br />Iniciativa<br />Autoconfiança<br />Necessidade de realizar<br />Comprometimento com o que faz<br />Manter o otimismo<br />Persistência<br />Alta capacidade de trabalho<br />
  11. 11. Características do empreendedor<br />Das qualidades empreendedoras que vimos, quais são aquelas com que nós nascemos?<br />Como podemos desenvolver as demais? Para ser um líder ? Gerente ?<br />A maioria é comportamento.<br />11<br />
  12. 12. Que características você tem?<br />Para cada uma das características empreendedoras, reflita como elas estão sendo desenvolvidas em você.<br />12<br />
  13. 13. O gerenciamento de Projetos em TI<br />
  14. 14. Importância da Análise<br />Manutenção<br />Manutenção<br />Teste<br />Implantação<br />Implantação<br />Programação<br />Programação<br />Projeto Físico<br />Projeto Lógico<br />Desenvolvimento<br />com sistemática<br />Desenvolvimento<br />sem sistemática<br />
  15. 15. Imaginando as três caixas<br />Análise do Sistema<br />Implementação <br />e Implantação<br />Gerência do Projeto<br />
  16. 16. O que é inovação<br />Edivandro Carlos Conforto<br />PhD Research Candidate<br />
  17. 17. Quebra de paradigma<br />
  18. 18. Gerenciamento ágil de projeto<br />
  19. 19.
  20. 20.
  21. 21. Exceto atividades de análise, projeto e desenvolvimento propriamente dito, que envolvem metodologias, técnicas e ferramentas de desenvolvimento...<br />Ademais em um projeto de sistemas é ação de GERÊNCIA!<br />
  22. 22. O que é o PMBOK ?( Project Management BodyofKnowledge )<br />Um guia que pretende reunir o conhecimento geral sobre metodologias de gerência de projetos;<br />Apresenta “melhores práticas geralmente aceitas” conforme contribuintes de grupos de estudos formados em diversas entidades;<br />Fornece uma referência para qualquer profissional interessado na profissão de Gerência de Projetos.<br />22<br />
  23. 23. Quem deve ocupar o cargo de gerente de projetos ?<br />Preferencialmente um profissional ligado a tecnologia da informação ?<br />Algo impede que seja um profissional com a mínima vivência em TI ?<br />
  24. 24. PMBOK<br />Tem como objetivo a melhoria do processo de Gerência de Projetos<br />Abrange 9 áreas de conhecimento:<br />Gerência de Integração<br />Gerência de Escopo<br />Gerência de Tempo<br />Gerência de Custos<br />Gerência de Qualidade<br />Gerência de Recursos Humanos<br />Gerência de Comunicação<br />Gerência de Riscos<br />Gerência de Contratação<br />Determina ferramentas a serem utilizadas no processo de gerência de projetos<br />Define algumas atividades que não trata como Área de Conhecimento (ex: Gerência de Configuração) <br />
  25. 25. Ciclo de vida de um projeto<br />Pmbok<br />
  26. 26. Processo básico<br />
  27. 27. PMBOK<br />Áreas Núcleo<br />GERÊNCIA DA QUALIDADE<br />GERÊNCIA DO CUSTO<br />GERÊNCIA DO TEMPO<br />GERÊNCIA DO ESCOPO<br />GERÊNCIA DA INTEGRAÇÃO<br />GERÊNCIA DOS<br />RECURSOS<br />HUMANOS<br />GERÊNCIA DA COMUNICAÇÃO<br />GERÊNCIA DO RISCO<br />GERÊNCIA DAS<br />AQUISIÇÕES<br />Áreas Facilitadoras<br />
  28. 28. PMBOK - Utilização <br />Focado em Gerência de Projetos<br />Não possui processo de avaliação formal para a organização <br />A implementação é feita de forma completa<br />Permite estabelecimento de controles<br />Identifica pontos fortes do Gerente do Projeto e indiretamente da organização <br />Não se tem registro de custos de implementação em organizações<br />Pode ser utilizado para verificar processos do fornecedor<br />Pode ser utilizado como item de qualificação em concorrências <br />Requerido em grandes e pequenas organizações<br />
  29. 29. Envolvidos nas fases<br />
  30. 30. Conseqüências de uma análise inadequada<br />  o aumento dos custos<br /> realização de atividades desnecessárias<br /> usuários insatisfeitos<br /> aumento da tarefa de manutenção<br />
  31. 31. Gerência do projeto de software<br />Tonsig, 2003.<br />
  32. 32. Etapas de processos gerenciais<br />Tonsig, 2003.<br />
  33. 33. “ item de Avaliação da Disciplina”Trabalho individual ou dupla<br /> Realizar uma síntese sobre o Modelo CMMI, MPSBR, ISO ou TMM.<br />Muitos consideram que os modelos de qualidade como por exemplo CMM e CMMI muito caros e ou inadequados para serem implementados em pequenas empresas.<br />Procurar dados a respeito.<br />Elaborar um documento discutindo o assunto considerando, inclusive, a possibilidade de implementação de um modelo em sua empresa, quais as mudanças necessárias e quais os passos adequados a sua realidade.<br />
  34. 34. Situação Atual das Organizações<br />Demanda por Melhor Qualidade!<br />melhor qualidade inclui:<br />menos prazos, custos, defeitos, insatisfações, mais qualidade dos produtos, previsibilidade, produtividade, competitividade, e melhores resultados de negócio (ROI)<br />
  35. 35. Situação Atual das Organizações<br /> Como as empresas de software podem obter a melhoria viável e necessária?<br />Melhoria do Processo de Software baseada em Modelos<br />
  36. 36. POG - Programação orientadas a gambiarras<br />
  37. 37. 37<br />A Comunicação... Um problema...<br />
  38. 38. O que é Qualidade ? <br />
  39. 39. O que é qualidade ?<br />“Qualidade consiste em desenvolver, criar e<br />fabricar mercadorias mais econômicas, úteis e<br />satisfatórias para o comprador”. <br />KAORU ISHIKAWA<br />
  40. 40. O que é qualidade ?<br />“Qualidade é o conjunto de características<br />do produto que determinam o grau de<br />satisfação que o mesmo proporciona ao<br />consumidor” <br />ArmanoFeigenbaum<br />
  41. 41. O que é qualidade ?<br />“A QUALIDADE somente pode ser definida em termos de quem a avalia.” <br />DEMING<br />
  42. 42. Qualidade de Software<br />Visão do produto pela qual qualidade está relacionada a características do produto. (PFLEEGER)<br />Alinhamento total entre as especificaçõesaprovadas e o produto concluído.<br />Produto final com a menor quantidade de erros possível.<br />42<br />
  43. 43. O que é qualidade ? Conceitos e tipos de clientes<br />“A QUALIDADE é tudo que alguém faz ao longo do processo para garantir que um cliente, interno ou externo à organização, obtenha exatamente aquilo que deseja.” (INTHURN)<br />Cliente interno – São aqueles que fazem parte da empresa e, são impactados pelas<br />atividades desenvolvidas por ela (funcionários e acionistas)<br />
  44. 44. Conceitos e tipos de clientes<br />“A QUALIDADE é tudo que alguém faz ao longo<br />do processo para garantir que um cliente, interno ou externo à organização, obtenha exatamente aquilo que deseja.” (INTHURN)<br />Cliente externo – São pessoas ou organizações que não fazem parte da empresa, mas também são impactadas<br />pelas suas atividades (quem compra ou quem fornece)<br />
  45. 45. Outras definições ...<br /><ul><li>“QUALIDADE é a aptidão para o uso. Sua avaliação baseia-se no fato de que o produto está apto ao uso e ele continuará assim.” (JURAN)
  46. 46. “QUALIDADE não é somente satisfazer o cliente, mas sim seduzi-lo.” (TOM PETERS)</li></li></ul><li>Outras definições ...<br />“QUALIDADE é produzir conforme foi especificado (atendendo as REAIS necessidades do cliente).” <br />PHILIP CROSBY<br />
  47. 47. Qualidade e Produtividade<br />Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significam satisfação do cliente e o sucesso do negócio. <br />DENTON<br />
  48. 48. Qualidade e produtividade<br />Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremento da produtividade e aumento da qualidade dependem:<br /><ul><li> Otimização dos custos de produção;
  49. 49. Diminuição de custos de panes e paralisações;
  50. 50. Nível de serviço prestado ao cliente (confiabilidade);
  51. 51. Rapidez de resposta aos clientes e às pressões externas.</li></li></ul><li>Realidade X qualidade<br /><ul><li> Muitos gestores de empresas de software julgavam elevados os custos de ferramentas, metodologias e acesso a recursos de capacitação.
  52. 52. Não consideravam o fato de gastar entre 40% e 50% de seus recursos produtivos em retrabalho, conserto de um defeito no software liberado para o mercado que podem chegar a custar até 200 vezes mais que o necessário para identificá-lo e corrigi-lo internamente .</li></li></ul><li>Segundo a NBR ISO 9000:2005, “Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos". <br />
  53. 53. Maior Produtividade<br />QUALIDADE !!<br />Ser Competitivo<br />Garantir a Sobrevivência<br />
  54. 54. Certificação de Qualidade<br />Confrontação das práticas de definição de processos e elaboração de produtos com uma Norma ou padrão de modo a se reconhecer a conformidade entre as mesmas.<br />Para tal é preciso realizar um processo de avaliação e julgamento de acordo com determinada Norma ou Padrão.<br />
  55. 55. Controle de Qualidade<br />É a atividade e técnica operacional utilizada para satisfazer os requisitos de qualidade segundo definição da ISO.<br />Pode ser realizado através de inspeções, revisões e testes usados durante o ciclo de desenvolvimento para garantir que cada trabalho produzido está de acordo com sua especificação.<br />
  56. 56. Garantia de Qualidade<br />É uma atividade aplicada ao longo do processo de Engenharia de Software. <br />Consiste dos procedimentos, técnicas e ferramentas aplicadas para assegurar que um produto atinge ou excede padrões especificados. Abrange:<br />Métodos e ferramentas<br />Revisões técnicas formais<br />Estratégias de teste<br />Controle de Documentação<br />Mecanismos de medição e divulgação<br />
  57. 57. 55<br />Características de Qualidade na Web<br />(Olsina, 99)<br />
  58. 58. Qualidade na Web (Offut 2002)<br />56<br /><ul><li>Segurança
  59. 59. Disponibilidade – 24H-7-365D
  60. 60. Escalabilidade/Desempenho
  61. 61. Prazo de colocação no mercado</li></ul>como atender a estas especificações?<br />
  62. 62. Melhoria<br />Melhoria de Processo de Software, é uma abordagem baseada em processos, para melhoria de uma organização.<br />Processos<br />Pessoas<br />Tecnologias<br />
  63. 63. Processo de Software<br />É o que as pessoas fazem, utilizando procedimentos, métodos e ferramentas, para adquirir, desenvolver, manter e melhorar software e produtos associados.<br />
  64. 64. Melhoria de Processo de Software<br />Ações realizadas para alterar os processos de uma organização para que eles satisfaçam de forma mais eficiente os objetivos e necessidades de negócio da organização.<br />Uma abordagem para “aprender a trabalhar de forma inteligente para desenvolver e manter melhores sistemas de software, mais barato e em menos tempo”. [adaptado de A.Dorling, SIMPROS 2001]<br />
  65. 65. Benefícios da Melhoria doProcesso de Software<br />
  66. 66. Qualidade do produto x Processo<br />A qualidade do produto de software é altamente determinada pela qualidade do processo de desenvolvimento e de manutenção escolhido para a construção.<br />Adaptado de Summerville<br />
  67. 67. Premissas da Qualidade<br /><ul><li> Deve estar inserida já nas primeiras fases do ciclo de vida do desenvolvimento de software;
  68. 68. Envolvimento de todas as pessoas (desde a alta administração até os técnicos);
  69. 69. Treinamento e comunicação;
  70. 70. Planejar e estimar prazos.....
  71. 71. Gerência de Projetos
  72. 72. Estratégias da Tecnologia da Informação
  73. 73. Gerenciamento de Custos
  74. 74. Gerenciamento de Recursos Humanos
  75. 75. Gerenciamento de Riscos
  76. 76. Gerenciamento de Aquisições </li></li></ul><li>Qualidade e produtividade<br />Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremento da produtividade e aumento da qualidade dependem:<br /> Otimização dos custos de produção;<br /> Diminuição de custos de panes e paralisações;<br /> Nível de serviço prestado ao cliente (confiabilidade);<br /> Rapidez de resposta aos clientes e às pressões externas.<br />
  77. 77. Qualidade e Produtividade<br /> Qualidade e produtividade são partes integrantes de uma mesma equação. As duas significam satisfação do cliente e o sucesso do negócio. (DENTON)<br /> A qualidadedeve ser vista <br />com olhos de empreendedor!<br />A qualidade de um produto, serviço e processo está boa quando <br />os custos estão baixos, a rotatividade da equipe é gerenciada, <br />as vendas estão elevadas e crescentes, os clientes são mantidos <br />e outros são agregados.<br />
  78. 78. A Norma ISO 9000-3<br />Grupo<br />Atividade<br />Estrutura do Sistema de Qualidade<br />Responsabilidade do fornecedor, Responsabilidade do comprador, Análise crítica conjunta <br />Atividades do Ciclo de Vida<br />Análise crítica do contrato, Especificação dos requisitos do comprador, Planejamento do desenvolvimento, Projeto e implementação, Testes e validação, Aceitação, Cópia, Entrega e instalação, Manutenção <br />Atividades de Apoio<br />Gerenciamento de configuração, Controle de documentos, Registros da QualidadeMedição, Regras e convenções, Aquisição, Produto de Software incluído, Treinamento <br />Traz os roteiros para aplicar a ISO 9001 especificamente na área de desenvolvimento, fornecimento e manutenção de Software. Todas as orientações giram em torno de uma "situação contratual", onde uma outra empresa contrata a empresa em questão para desenvolver um produto de Software.<br />
  79. 79. A Norma ISO 9000-3 - Utilização <br />Possui processo de certificação formal<br />Implementação por completo<br />Permite melhoria de processos para garantia de qualidade<br />Permite estabelecimento de controles<br />Identifica pontos fortes da organização assim como oportunidades de melhoria<br />Custo pode ser elevado dependendo da implementação<br />Há processo de re-certificação<br />Pode ser utilizada para verificar processos do fornecedor<br />Pode ser utilizado como item de qualificação em concorrências<br />Orientações giram em torno de uma "situação contratual"<br />Normalmente utilizada em grandes organizações<br />
  80. 80. A Norma ISO 12207 - Processos do Ciclo de Vida do Software<br />Esta Norma, lançada em 1995, formaliza a arquitetura do Ciclo de Vida do Software. Detalha os diversos processos envolvidos no ciclo de vida do Software e os divide em três classes: <br />Fundamentais - Aquisição, Fornecimento, Desenvolvimento, Operação e Manutenção <br />Apoio - Documentação, Gerência de Configuração, Garantia de Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria e Resolução de Problemas<br />Organizacionais - Gerência, Infra-estrutura, Melhoria e Treinamento <br /> Descreve com detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de Software<br />
  81. 81. Qualidade do Processo<br />P<br />R<br />O<br />C<br />E<br />S<br />S<br />O<br />D<br />E<br />A<br />D<br />A<br />P<br />T<br />A<br />Ç<br />Ã<br />O<br />Processos Fundamentais<br />Processos de Apoio<br />Documentação<br />Ger. de Configuração<br />Garantia de Qualidade<br />Verificação<br />Validação<br />Revisão Conjunta<br />Auditoria<br />Resolução de Problemas<br />Processos Organizacionais<br />Infra-estrutura<br />Gerência<br />Treinamento<br />Melhoria<br />Aquisição<br />Fornecimento<br />Desenvolvimento<br />Operação<br />Manutenção<br />ISO/IEC 12207Processos do Ciclo de Vida do Software<br />V&V devem ser aplicados durante todo o ciclo de vida do projeto para o efetivo gerenc. De qualidade.<br />
  82. 82. VV&T e a norma ISO/IEC 12207<br />Verificação<br />Verificação do contrato<br />Verificação do produto<br />Verificação dos requisitos<br />Verificação do projeto<br />Verificação dos códigos<br />Verificação da integração<br />Verificação da documentação<br />Validação – está relacionada a implementação seguindo um plano de validação<br />Preparar os requisitos de testes, casos de testes e especificações para assegurar que os itens refletem os requisitos particulares para o uso do software.<br />Teste – no contexto da norma é visto como uma ATIVIDADE e não um processo de VV.<br />Teste de desenvolvimento, operação e manutenção<br />
  83. 83. A Norma ISO 12207 - Utilização<br />Possui processo de certificação formal<br />Implementação por completo<br />Permite melhoria de processos para garantia de qualidade<br />Permite estabelecimento de controles<br />Identifica pontos forte da organização assim como oportunidades de melhoria<br />Custo pode ser elevado dependendo da implementação<br />Há processo de re-certificação<br />Pode ser utilizada para verificar processos do fornecedor<br />Pode ser utilizada como item de qualificação em concorrências <br />Normalmente utilizada em grandes organizações<br />
  84. 84. Responda<br />A atividade de teste de software no processo de desenvolvimento deve ser aplicada em que momento ? <br />Apenas na fase de codificação ?<br /> Ou em todo o ciclo de vida ?<br />
  85. 85. CapabilityMaturityModel - CMM<br /> É um modelo, desenvolvido pelo SEI para avaliação e melhoria da capacitação das empresas que produzem software. Publicado em 1992.<br /> Tem como principal objetivo a medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento de software.<br />
  86. 86. Maturidade <br />A maturidade dos processos possui grande influência em:<br />Metas de custos<br />Cronogramas <br />Qualidade <br />
  87. 87. Organizações Maduras<br />Organizações Imaturas<br />Papéis e Responsabilidades bem definidos<br />Processo improvisado<br />Existe Base Histórica<br />Não existe base histórica<br />É possível julgar a qualidade do produto<br />Não há maneira de julgar a qualidade do produto<br />A qualidade dos produtos e processos é monitorada<br />Qualidade e funcionalidade do produto sacrificadas<br />O processo pode ser atualizado<br />Não há rigor no processo a ser seguido<br />Existe comunicação entre o gerente e seu grupo<br />Resolução de crises imediatas<br />CMM - Maturidade<br />
  88. 88. CMM – Níveis de Maturidade<br />Nível CMM<br />Descrição<br />Inicial<br />Processo desorganizado. Poucos processos definidos. Sucesso depende de esforços individuais<br />Repetível<br />Processos básicos de gerenciamento. Permitem acompanhar custo, cronograma e funcionalidade. Repetir o sucesso usando processos similares.<br />Definido<br />Todas as atividades de engenharia de processo e de produto estão documentadas, padronizadas e integradas em um processo padrão. Os projetos adaptam o processo padrão.<br />Gerenciado<br />Medidas detalhadas da qualidade do produto e do processo de desenvolvimento são coletadas. Todos os produtos e processos são controlados quantitativamente.<br />Otimizado<br />Melhoramento contínuo do processo é conseguido através de “feedback” quantitativo dos processos e pelo uso de tecnologias inovadoras.<br />O CMM classifica as organizações em 5 níveis distintos. Do nível 1 (organizações onde não há nenhuma metodologia implantada) até o nível 5 (cada detalhe do processo de desenvolvimento está definido, qualificado, acompanhado e sendo melhorado continuamente).<br />
  89. 89. Principais atividades para controle e garantia da qualidade<br />Verificação<br />Validação<br />Testes<br />
  90. 90. CMM<br />Processo continuamente aprimorado<br /><ul><li>Prevenção de defeitos
  91. 91. Gerência de mudançastecnológicas
  92. 92. Gerência de mudanças no processo</li></ul>Otimizado<br />5<br />Processo previsível<br />Gerenciado<br />4<br /><ul><li>Gerênciaquantitativa de processos
  93. 93. Gerênciadaqualidade de software
  94. 94. Foco no processo
  95. 95. Definição do processo
  96. 96. Programa de treinamento
  97. 97. Administração de software integrada
  98. 98. Engenharia de produtos
  99. 99. Coordenação entre grupos
  100. 100. Revisões</li></ul>Processo consistente, padrão<br />Definido<br />3<br />Repetitível<br />2<br />Processodisciplinado<br /><ul><li>Gerência de requisitos
  101. 101. Planejamento de Projetos
  102. 102. Acompanhamento de projetos
  103. 103. Gerência de subcontratos
  104. 104. Garantia de qualidade
  105. 105. Gerência de configuração</li></ul>Inicial<br />1<br />CMM - Áreas -Chave de Processo<br />São os itens a serem focados pela organização para melhoria do seu processo<br />
  106. 106. CMM - Características Comuns e Práticas-Base<br />Práticas-Base relacionadas <br />Estabelecimento de políticas<br />Característica Comum<br />Descrição<br />Alocação de recursos, definição da estrutura organizacional e devidos treinamentos<br />Compromisso de realizar<br />Atitudes a serem tomadas pela organização para que o processo se estabeleça<br />Capacidade de realizar<br />Pré-requisitos que devem existir na organização para implementação do processo<br />Estabelecimento de planos, procedimentos, realização do trabalho e tomada de ações corretivas caso necessário<br />Atividades realizadas<br />Papéis e procedimentos necessários para implementar uma área-chave de processo<br />Realização de medições para determinar o estado e a efetividade das atividades realizadas<br />Medições e análise<br />Necessidade de medir o processo e analisar medições<br />Revisão, auditoria e garantia de qualidade<br />Implementação com verificação<br />Passos para garantir que as atividades são realizadas de acordo com o processo estabelecido<br />São itens a serem observados para que se possa verificar a implementação e institucionalização das áreas-chave do processo. <br />
  107. 107. CMM - Utilização <br />Possui processo de avaliação formal<br />É didático e conhecido no mercado empresarial <br />Permite implementações por níveis<br />Permite melhoria de processos para garantia de qualidade<br />Permite estabelecimento de controles<br />Identifica pontos forte da organização assim como oportunidades de melhoria<br />Custo pode ser elevado dependendo da implementação<br />Não há processo de re-certificação, ocorre sempre na do próximo nível<br />Pode ser utilizado para verificar processos do fornecedor<br />Pode ser utilizado como item de qualificação em concorrências <br />Utilizado em grandes organizações com muitos resultados documentados<br />Permite certificação somente por níveis<br />
  108. 108. Nome<br />Nível<br />Atividades<br />Medição Pessoal<br />PSP0<br />Registro de Tempo, Registro de Defeitos, Padrão de Tipos de Defeito, Padrão de Codificação, Medida de Tamanho, Proposta de Melhoramento do Processo<br />Planejamento Pessoal<br />PSP1<br />Estimativa de Tamanho, Relatório de Testes, Planejamento de Tarefas, Cronogramas<br />Qualidade Pessoal<br />PSP2<br />Revisões de código, Revisões de projeto, Padrões de projeto<br />Processo Cíclico Pessoal<br />PSP3<br />Desenvolvimento cíclico<br />Personal Software Process - PSP<br />Criado a partir da necessidade de definição de um modelo mais simples que o CMM voltado para pequenas organizações ou até para um único indivíduo. Possui quatro níveis, cada um com suas características próprias.<br />
  109. 109. Personal Software Process - PSP<br />
  110. 110. PSP - Utilização <br /><ul><li>Não possui processo de avaliação formal
  111. 111. Permite implementações por níveis
  112. 112. Permite melhoria de alguns processos para garantia de qualidade
  113. 113. Permite estabelecimento de alguns controles
  114. 114. Identifica pontos forte do indivíduo assim como oportunidades de melhoria
  115. 115. Custo mais reduzido
  116. 116. Normalmente utilizado em pequenas organizações</li></li></ul><li>ISO 15504<br />Constitui-se de um padrão para avaliação do processo de software visando determinar a capacitação da organização. Visa orientar a organização para uma melhoria contínua do processo.<br />Inclui um modelo de referência, que serve de base para o processo de avaliação. É um conjunto padronizado de processos fundamentais, que orientam para uma boa engenharia de software. Este modelo é dividido em cinco grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gerência e Organização. <br />Além dos processos, define também os 6 níveis de capacitação de cada processo, que pode ser incompleto, executado, gerenciado, estabelecido, previsível e otimizado.<br />
  117. 117. Descrição<br />Adquirir software, Gerenciar necessidades do cliente, Fornecer Software, Operar software, Prover serviço ao cliente <br />Processo<br />Desenvolver requisitos e o projeto, Implementar o projeto, Integrar e testar o software, Integrar e testar o sistema, manter o sistema e o software<br />Cliente - Fornecedor<br />Engenharia<br />Desenvolver documentação, Desempenhar gerência de configuração, Executar garantia de qualidade, Executar verificação de produtos, Executar validação de produtos, Executar revisões conjuntas, Executar auditorias, Executar resolução de problemas<br />Suporte<br />Gerenciar o projeto, Gerenciar a qualidade, Gerenciar riscos, Gerenciar subcontratadas<br />Gerência<br />Construir o negócio, Definir o processo, Melhorar o processo, Prover recursos de treinamento, Prover infra-estrutura organizacional<br />Organização<br />ISO 15504 - Categorias e Processos<br />
  118. 118. ISO 15504 - Níveis de Capacitação<br />Processo<br />Descrição<br />Incompleto<br />Não existem produtos de trabalho nem saídas do processo facilmente identificáveis.<br />Realizado<br />Existe um consenso na organização de que as ações devem ser realizadas. Os produtos existentes são utilizados para atestar o atendimento dos objetivos<br />Gerenciado<br />O processo produz os produtos de trabalho com qualidade aceitável e dentro do prazo. Isso é feito de forma planejada e controlada. Os produtos estão de acordo com padrões e requisitos.<br />Estabelecido<br />O processo é realizado e gerenciado usando um processo definido. As pessoas que implementam o processo usam processos aprovados, que são versões adaptadas do processo padrão documentado. <br />Predizível<br />O processo é realizado de forma consistente, dentro dos limites de controle, para atingir os objetivos. Medidas são coletadas e analizadas. Há entendimento quantitativo da capacitação do processo.<br />Otimizado<br />A realização do processo é otimizada para atender as necessidades atuais e futuras de negócio. O processo atinge seus objetivos e consegue ser repetido. Existem objetivos quantitativos de eficácia e eficiência. Monitoração constante do processo. <br />
  119. 119. ISO 15504<br />ProcessosFundamentais<br />Processos de Apoio<br />Documentação<br />Fornecimento<br />Aquisição<br />Ger. de Configuração<br />Ger. NecessidadesCliente<br />ServiçosCliente<br />Garantia de Qualidade<br />TESTES<br />Verificação<br />Desenvolvimento<br />Operação<br />Validação<br />ISO/IEC 15504SPICE<br />Revisão Conjunta<br />Auditoria<br />Manutenção<br />Resolução de Problemas<br />Medição prod/ processo<br />Processo de Reuso<br />ProcessosOrganizacionais<br />AlinhamentoOrganizacional<br />Ger. de Processos<br />Melhoria<br />Infra-estrutura<br />Ger. Recursos Humanos<br />
  120. 120. ISO 15504 - Utilização<br />Possui processo de certificação formal <br />Ainda não está muito difundido no meio empresarial<br />Permite implementações por níveis<br />Permite melhoria de processos para garantia de qualidade<br />Permite estabelecimento de controles<br />Identifica pontos fortes da organização assim como oportunidades de melhoria<br />Há processo de re-certificação<br />Custo pode ser elevado dependendo da implementação<br />Pode ser utilizado para verificar processos do fornecedor<br />Não possui grande histórico de utilização com resultados<br />Possui manuais para realização de Avaliações <br />
  121. 121. Qualidade de Software X CMMI<br />88<br />
  122. 122. Capability...<br />Capacidade?<br />Capacitação?<br />“Capabilidade”?<br />89<br />Qualidade que uma pessoa ou coisa tem de possuir para um determinado fim; habilidade, aptidão. (Aurélio)<br />?<br />Ato ou efeito de capacitar (-se). (Aurélio)<br />CMMI- Tradução correta é modelo de capacidade e maturidade<br />
  123. 123. CMMI<br />Foi criado para resolver o problema de existirem múltiplos CMM´s<br />Sua missão é combinar o SW-CMM (CapabilityMaturityModel for Software<br />Cobre as seguintes áreas de conhecimento:<br />Engenharia de Sistemas<br />Engenharia de Software<br />Desenvolvimento integrado de produtos e processos<br />Contratação de fornecedores<br />Permite implementação Contínua (áreas de processo organizadas por categorias) e implementação por níveis (áreas de processo organizadas por níveis)<br />Indica apreciação de fatores da organização (negócio, cultura, legado em processos) para decisão de como fazer a implementação<br />Possui Níveis de 0 a 5.<br />
  124. 124. Considerações <br />Trabalhar com avaliação oferece capacidade para as empresas desenvolverem futuros projetos de uma forma mais adequada.<br />CMMI pode ser utilizado independente da metodologia de processo (XP, estruturada, OO) – modelos robustos que trabalham independente da plataforma.<br />80% das avaliações ficam nas disciplinas de análise de sistemas e engenharia de software.<br />O grande desafio no final é a produtividade e os LUCROS. <br />91<br />
  125. 125. Pense ...<br />O CMMI é apenas para software?<br />O CMMI não descreve processo algum, apenas define orientações através de práticas específicas<br />
  126. 126. Capability...<br />Software processcapability - descreve o intervalo de resultados esperados que podem ser alcançados seguindo-se um processo de software. Um indicador que permite prever os resultados de futuros projetos de software. (SEI)<br />93<br />
  127. 127. Origem<br />“Não há nada de novo no CMMI (i de integration)”<br />94<br />
  128. 128. Origem<br />O SEI estruturou o CMM para contratação de grandes projetos de software<br />Hoje, porém, o CMM e o CMMI são utilizados por empresas/organizações de vários tamanhos<br />95<br />
  129. 129. CMMI – dupla representação<br />ContinuousRepresentation<br /><ul><li>Níveis de Capacidade
  130. 130. Agrupamento das Áreas de ProcessoporCategoria
  131. 131. Avaliaçãodacapacidade das Areas de Processo</li></ul>CMMI<br />StagedRepresentation<br /><ul><li>5 níveis (estágios) de Maturidade
  132. 132. Agrupamento de Áreas de ProcessoporNível
  133. 133. AvaliaçãodaOrganizaçãocomo um todo</li></ul>Estágio – para estar no nível 1 basta desenvolver software<br />96<br />
  134. 134. Comparando as Representações<br />Staged<br />ML5<br />Process Area Capability<br />ML4<br />0 1 2 3 4 5<br />ML3<br />ML2<br />ML 1<br />PA<br />PA<br />PA<br />. . .para um conjunto de áreas<br />de processoestabelecidaspela<br />organização.<br />… paraumaúnicaárea de processoou um conjunto de áreas de processo.<br />Fonte: http://www.sei.cmu.edu<br />
  135. 135. B<br />D<br />A<br />C<br />O foco<br />o foco está nos processos, pq a idéia é se tem um processo falho provavelmente terá comprometimento no produto.<br />Procedimentos e métodos definindo o relacionamento entre as tarefas e a sua seqüência<br />Processo<br />Ferramentas e equipamentos que vão apoiar os processos<br />Pessoas com habilidades, treinamento e motivação a idéia que se tenha um processo que tenha uma seqüência <br />98<br />Paulket al. (1995)<br />
  136. 136. 99<br />Premissa do Gerenciamento do Processo de Software<br />A qualidade de um sistema de software é altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo<br />
  137. 137. Processo em perspectiva<br />100<br />Este componente permanece na organização!<br />Organização<br />Tecnologia<br />Pessoas<br />Processos<br /><ul><li>Maiores determinantes do custo, do prazo de entrega e da qualidade dos produtos</li></li></ul><li>Por que o foco está no processo?<br />101<br />Processo<br />Produtos<br />Insumos<br />
  138. 138. Por que o foco está no processo?<br />102<br />Processo de software<br />Requisitos<br />Software<br />
  139. 139. Por que o foco está no processo?<br />103<br />a<br />a<br />a<br />x<br />Requisitos<br />Software<br />
  140. 140. Por que o foco está no processo?<br />104<br />a<br />a<br />a<br />a<br />Software<br />Requisitos<br />O fato de ter um processo bem definido garante que terá um produto de qualidade?<br /><ul><li> É necessário Análise de mercado, Entendimento dos Requisitos ?..</li></li></ul><li>Outros processos da vida diária<br />Qualidade total<br />Gravar um cd<br />Ex. das enfermeiras<br />105<br />
  141. 141. Considerações<br />106<br />Quando tudo é importante.... Nada é importante!<br />Por isso é necessário seguir um processo<br />Deve ser definido<br />Implementado<br />Documentado<br />Estar ‘vivo‘ estar continuamente sendo revisado<br />A criatividade é um desafio na implementação de um modelo de qualidade<br />O CMMI não define o como fazer e sim o que fazer<br />Para migrar de um CMM aconselha-se utilizar o CMMI pode estágios pois a migração será mais direta.<br />
  142. 142. CMMI<br />O CMMI diz “o que” e não “COMO”<br />Supri as limitações do CMM, permitindo a inclusão de novos modelos ao longo do tempo,sempre que surgirem necessidades específicas;<br />Implementa melhorias a partir das experiências adquiridas com projetos já implementados;<br />Assegura a integridade da norma ISO/IEC 15504 e permite a representaçãocontínua, com áreas independentes do nível de maturidade;<br />
  143. 143. Níveis de maturidade<br />Formados por um conjunto predefinidos de áreas de processo.<br />Como realiza-se a medição<br />Verifica-se se os objetivos específicos e genéricos estão sendo atendidos.<br />
  144. 144. CMMI - Continuous<br />Área de Processo 2<br />Área de Processo 1<br />Área de Processo 3<br />Objetivos Específicos<br />Objetivos Genéricos<br />Práticas Específicas<br />Níveis de Capacidade<br />Práticas Genéricas<br />
  145. 145. CMMI - Contínuo<br />Uma organização pode escolher melhorar o desempenho de um único ponto problemático<br />
  146. 146. CMMI - Contínuo<br />Process Area Capability<br />0 1 2 3 4 5<br />PA<br />PA<br />PA<br />Áreas do Processo<br />– Metas genéricas (Requeridos)<br />» Práticas genéricas (esperados)<br />O que uma organização fará para atender aos componentes requeridos.<br />– Metas específicas (Requeridos)<br />» Práticas específicas (esperados)<br />Níveis de Capacidade<br />
  147. 147. Exemplo de área de processo e Capacidade<br />CAPACIDADE<br /><ul><li>Baseado ISO15504
  148. 148. 6 níveis de maturidade
  149. 149. onde qualquer área do processo pode ter sua</li></li></ul><li>Os níveis de capacidade são Acumuladtivos<br />
  150. 150. Área de Processo - Engenharia<br />Gerenciamento de requisitos<br />Desenvolvimento de requisitos<br />Solução técnica<br />Integração de produto<br />Verificação<br />Validação<br />
  151. 151. CMMI - Staged<br />Nível de Maturidade<br />Área de Processo 2<br />Área de Processo 1<br />Área de Processo 3<br />Objetivos Específicos<br />Objetivos Genéricos<br />Características Comuns<br />Implemen<br />tação<br />Verificação<br />Habilidades<br />Compromisso<br />Práticas Específicas<br />Práticas Genéricas<br />
  152. 152. Níveis de Maturidade<br />
  153. 153. Componentes CMMI - estágios<br />Áreas de Processo (PA)<br /> Metas específicas (SG)<br /> Práticas específicas (SP)<br /> Características comuns<br />Compromissos(commitment to perform - CO)<br />Habilidades (ability to perform - AB)<br />Diretivas (directingimplementation – DI)<br />Verificações (verifyingimplementation – VE)<br /> Produtos de trabalho<br />
  154. 154. CMMI - Utilização <br />Possui processo de avaliação formal<br />Permite implementação contínua<br />Permite implementações por níveis<br />Permite melhoria de processos para garantia de qualidade<br />Permite estabelecimento de controles<br />Identifica pontos fortes da organização assim como oportunidades de melhoria<br />Custo pode ser elevado dependendo da implementação<br />Pode ser utilizado para verificar processos do fornecedor<br />Utilizado em grandes e pequenas organizações<br />
  155. 155. Método de avaliação<br />SCAMPI - Standard CMMI Assessment Method for Process Improvement:<br />Desenvolvido pelo Software EngineeringInstitute (SEI)<br />Métodoquereúneas melhorespráticas<br />Métodosamplamenteutilizadospelo SW-CMM e outrosmodelos de melhoria de processos<br />Existemcerca de 180 avaliadores SCAMPI no mundo:<br />Autorizadospelo SEI a realizaravaliações do CMMI. <br />
  156. 156. CMM x Testes <br />PAs (Áreas de Processo) relacionadasestritamente a testes:<br />VAL – Validação<br />VER – Verificação<br />Outrasaçõesconcentradasem PAs queenvolvemmais de umaequipe (TreinamentoOrganizacionais, Desenvolvimento de Requisitos, etc.)<br />
  157. 157. Áreas de processos relacionadas a teste de software (CMMI x TESTES)<br /><ul><li> Integração do Produto (PI)
  158. 158. Verificação (VER)
  159. 159. Validação (VAL)</li></ul>nível 3<br />
  160. 160. Áreas de Processo do modelo CMMI - Nível 3<br />
  161. 161. 123<br />CMMI<br />TSP<br />PSP<br />Team Software Process &Personal Software Process<br />
  162. 162. Resumo (principais conceitos)<br />O que é o CMMI?<br />Quais os principais componentes do CMMI?<br />Para que serve o CMMI?<br />Se você fosse responsável pela implementação de um programa de melhoria de processos com base no CMMI:<br />Por qual modelo CMMI (disciplinas e representação) optaria?<br />Por quê?<br />124<br />
  163. 163. Questionamentos<br />Qual deles escolher?<br />Quando utilizar?<br />Como utilizar?<br />
  164. 164. Resumo<br />Compreensão prévia dos processos da organização<br />Identificação dos pontos fortes<br />Identificação das oportunidades de melhoria<br />Estudos dos modelos e Normas disponíveis.<br />Identificação de quais se aplicam à organização<br />Estimular a equipe para mudanças<br />ISO<br />SPICE<br />CMM<br />Melhores práticas<br />Processo Padrão<br />
  165. 165. Resumo<br />Identificação do objetivo da organização<br />Certificação/avaliação<br />Controle<br />Garantia de Qualidade<br />Caracterização do estado corrente do processo e do estado que se deseja alcançar<br />Definição de um plano de ação<br />Processo Padrão<br />
  166. 166. Plano de Ação<br />Determinar o contexto onde se aplicará a melhoria<br />Definir "patrocinadores" <br />Montar a infra-estrutura necessária para a realização do processo de melhoria.<br />Determinação de prioridades da melhoria<br />Planejamento de ações para atingi-la.<br />Criação, teste, refino e implementação e de soluções<br />Análise e validação das soluções implementadas <br />Definição das ações futuras que devem ser propostas.<br />Processo Padrão<br />
  167. 167. Algumas “dicas”<br /><ul><li> PSP- Organizações de pequeno porte com poucos recursos e que não necessitem de uma certificação/avaliação formal;
  168. 168. CMM OU ISO - Organizações de grande porte com possibilidade de alocação de recursos para cuidar dos processos que serão definidos, mesmo que o objetivo não seja a certificação ou avaliação;
  169. 169. CMM - É o mais didático se o objetivo for apenas melhoria de processos;</li></li></ul><li>Algumas “dicas”<br /><ul><li>PMI - Gerência de Projetos;
  170. 170. CMMI ou ISO - Se há necessidade de avaliação ou certificação ;
  171. 171. CMMI – Se o objetivo for a melhoria de processos em apenas algumas áreas isoladas, o CMMI é próprio para isso.
  172. 172. Se a organização trabalha com soluções sistêmicas
  173. 173. desenvolvimento de software e dispositivos de hardware.</li></li></ul><li>Algumas dificuldades na área de Qualidade<br /><ul><li>Complexidade dos produtos de software;
  174. 174. A engenharia de software ainda não está madura;
  175. 175. Inexistência de processos definidos;
  176. 176. As pessoas ainda são muito resistentes;
  177. 177. Empresas da região precisam conhecer melhor seus processos
  178. 178. Não há consenso entre os profissionais sobre o que é qualidade;
  179. 179. Restrições quanto a investimentos e recursos...</li></li></ul><li>Testes de Software<br />Conceitos, Princípios e Modelos<br />
  180. 180. Relação com outras Disciplinas<br />Engenharia de Software – Metodologias de desenvolvimento de software.<br />Engenharia de Requisitos - captura os requisitos do software, que representam uma das bases principais para a identificação dos testes que devem ser executados.<br />Análise e Design determina o design adequado para o software. Essa é outra base importante para a identificação dos testes que devem ser executados.<br />Fase de Implementação produz builds do software que são validados pela disciplina Teste. Em uma iteração, vários builds são testados, geralmente um por ciclo de teste.<br />Gerenciamento planeja o projeto e o trabalho necessário em cada iteração. Descrito em um Plano de Iteração, esse artefato é uma base importante para definir a missão de avaliação correta para o esforço de teste.<br />Gerenciamento de Configuração e Mudança controla a mudança dentro da equipe de projeto. O esforço de teste verifica se cada mudança foi efetuada corretamente.<br />
  181. 181. Qual o perfil de um Eng. de Testes?<br />Conhecimentos de engenharia de software.<br />Ciclo de vida<br />Especificação<br />Projeto<br />Teste propriamente dito<br />Gerência da qualidade.<br />Conhecimentos básicos de programação<br />Conhecimentos básicos de banco de dados<br />operação e configuração.<br />Conhecimentos médios de redes<br />configuração, operação, administração, segurança.<br />
  182. 182. Perfil pessoal<br />Paciência / Perseverança / Organização<br />Firmeza de opinião<br />Espírito investigador<br />Capacidade de trabalhar em equipe<br />Diplomacia<br />analisador, investigador<br />procurar defeitos<br />Criativo<br />criar novos cenários de teste<br />Organizado<br />lidar com massas de dados<br />seguir o plano de teste<br />
  183. 183. Para ser um testador, requer um bom entendimento do processo de desenvolvimento e do produto sendo gerado, além da habilidade de indicar possíveis falhas e erros.<br />
  184. 184.
  185. 185. Testes de integração<br />CMMIx SCRUM<br />
  186. 186. Categorias de teste de software - Fonte: Bartié (2002).<br />
  187. 187. Esquema de Teste<br />Revisões<br />Revisões<br />Teste estrutural<br />Esse plano, deve descrever a funcionalidade do software, os métodos e técnicas que serão utilizados, para que seja formulado um plano de teste a ser seguido durante todo o ciclo de vida do software. exemplo<br />Teste funcional<br />
  188. 188. Introdução aos testes de software<br />O que é testar?<br />Encontramos na literatura algumas definições sobre que é a atividade de testar:<br /> Segundo Myers - “Testar é analisar um programa com a intenção de descobrirerros e defeitos.”<br /> Testar é exercitar ou simular a operação de um programa ou sistema.<br /> Testar é confiar que um sistema faz o que se espera que ele faça e não faz o que se espera que não faça.<br /> Testar é medir a qualidade e funcionalidade de um sistema.<br /> “O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)<br />
  189. 189. Qual o objetivo dos testes?<br /> O objetivo principal dos testes é reduzir a probabilidade da ocorrência de um defeito quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente estão sendo atendidas<br />“Uma pessoa inteligente resolve um problema. Uma pessoa sábia evitá-o”. [Einsten]<br />
  190. 190. Erro, Defeito e Falha<br />Erro (error): é uma ação humana que produz um resultado incorreto.<br />Defeito (fault): A manifestação de um erro no software <br />Também conhecido como Bug<br />Se executado, o defeito pode causar uma falha<br />Falha (Failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado)<br />Falha é um evento; defeito é um estado do software, causado por um erro.<br />
  191. 191. Erro, Defeito e Falha<br />
  192. 192. Confiabilidade do Software x Defeitos<br />Pode existir um software livre de defeitos?<br /> É possível existir softwares confiáveis mas que possuem defeitos?<br />Confiabilidade do Software é a probabilidade que o software não causará uma falha no sistema por um tempo especificado, sob condições determinadas.<br />
  193. 193. O que provoca erro no software?<br />Especificação de requisitos incorreta,<br />Mudança de requisitos, <br />Projeto inadequado, <br />Módulos mal especificados,<br />Erros de codificação..<br />
  194. 194. Confiabilidade do Software<br />Nenhuma falha encontrada = confiança<br />
  195. 195. O que é Testes de Software ?<br />"É uma estratégia popular para o gerenciamento de risco". (LEWIS, 2004, p. 19)<br />O teste de software é usado para:<br />verificar se requisitos funcionais e não-funcionais foram devidamente implementados. <br />
  196. 196. “Teste é o processo de executar um programa com o intuito de encontrar erros” <br />Glenford J. Myers (1979)<br />
  197. 197. Fluxo da gestão de defeitos<br />Adaptado de Rex Black<br />
  198. 198. Porque defeitos ocorrem no software?<br />Softwares são escritos por humanos<br /> As pessoas não conhecem e não dominam tudo;<br /> As pessoas tem habilidades, mas não são perfeitas;<br /> As pessoas cometem erros;<br />Softwares são desenvolvidos sob crescente pressão para entregá-los em prazos rigorosos<br /> Sem tempo para checar as atividades realizadas;<br /> Sistemas podem estar incompletos.<br />Se você já escreveu softwares....<br />
  199. 199. Vale a pena investir em testes?<br /> Reduz em 70% o índice de <br /> re-trabalho de correção de falhas <br /> Reduz em 50% do tempo de homologação de uma nova versão<br /> Aumenta em 90% o índice de falhas detectadas antes da entrega<br />Aumenta a abrangência dos testes<br />
  200. 200. Realidade atual do mercado de software<br />Complexidade dos softwares<br /> Complexidade das equipes<br /> Cronograma apertado para Desenvolvimento<br /> Mercado/Cliente/Usuários mais exigentes<br /> Menos tolerância a falhas<br /> Menos tolerância aos atrasos das entregas<br />Precisamos construir softwares MELHORES<br />e mais BARATOS, de forma mais RÁPIDA<br />
  201. 201. O custo da não-qualidade<br /> Estatísticas de mercado apontam que para cada R$ 1,00 investido no desenvolvimento e manutenção de software, entre R$ 2,00 e R$ 3,00 são gastos com re-trabalho.<br />Não se sabe o percentual de re-trabalho e quanto isso custa<br /> O software ou parte dele tem de ser refeito<br /> Não se sabe, através de métricas claras e precisas, quais são as principais áreas de produção que geram re-trabalho<br /> A empresa não toma iniciativas para corrigir os problemas nas áreas de produção ineficientes<br />
  202. 202. Por que testar um software?<br />Todo o software visa atender a uma demanda:<br /> Por questão de Qualidade<br /> Por questão de Economia<br /> Por questão de Segurança<br /> Por questão de Confiabilidade<br /> Por questão de Negócio<br />
  203. 203. O custo da correção dos defeitos<br />A regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada vez maior quanto mais tarde ele for descoberto.<br />Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do software são mais baratos de serem corrigidos do que aqueles encontrados na produção.<br />
  204. 204. Porque testar é necessário?<br /> Porque é provável que o software possua defeitos;<br /> Para descobrir a confiabilidade do software;<br /> Porque falhas podem custar muito caro;<br /> Demonstrar as conformidades com os requisitos;<br /> Para assegurar que as necessidades dos usuários estejam sendo atendidas;<br /> Para reduzir custos;<br /> Para avaliar a qualidade do software;<br />
  205. 205. Não devemos testar:<br /> Para provar que o software não tem defeitos;<br /> Apenas porque os testes estão incluídos no plano de projeto;<br />
  206. 206. A abordagem tradicional dos testes<br />Mostrar que o sistema:<br /> Faz o que deve fazer<br /> Não faz o que não deve fazer<br />META: Mostrar que o sistema funciona<br />CRITÉRIO DE SUCESSO: Sistema em funcionamento correto<br />RESULTADO: Sistema com defeitos<br />
  207. 207. A melhor abordagem para o testes<br />Mostrar que o sistema:<br /> Faz o que não deve fazer<br /> Não faz o que deve fazer<br />META: Encontrar defeitos<br />META: Encontrar defeitos<br />RESULTADO: Sistema com menos defeitos<br />
  208. 208. O paradoxo do teste<br />A proposta do teste é encontrar defeitos<br />Encontrado defeitos a confiança é “destruída”<br />Proposta do teste: “destruir” a confiança do software<br />Proposta do teste: Estabelecer a confiança<br />A melhor maneira de estabelecer a confiança é tentar destruí-la.<br />
  209. 209. Por que as empresas não testam?<br />Software é complexo<br /> Software é intangível<br /> Software é altamente modificável<br /> Teste lida com pessoas<br /> Há desconhecimento sobre a relação custo x benefício<br /> Há falta de profissionais especializados<br /> Há dificuldade em implantar um processo de teste<br /> Há desconhecimento das técnicas adequadas de teste<br /> Há desconhecimento de como planejar as atividades<br /> Só se preocupam com testes no final do projeto<br />
  210. 210. Conceitos iniciais<br />Para que consigamos entender os conteúdos seguintes, é importante termos um perfeito entendimento dos conceitos abaixo:<br />Erro: engano, alguma coisa feita por humanos.<br />Defeito: o resultado de um erro.<br />Falha: diferença indesejável entre o observado e o esperado.<br />Depurar: descobrir e corrigir erros ou defeitos no código.<br />Testar: descobrir falhas através da execução do sistema.<br />Requisitos: regras de negócio do sistema.<br />Testware: todo o conjunto de documentação gerado pelo processo de teste de software.<br />
  211. 211. TMM TestMaturityModel<br />
  212. 212. TMM - TestMaturityModel<br />Modelo de maturidade focado em testes com 5 níveis de maturidade<br />Desenvolvido em 1996 por IleneBurnstein no IIT (IllinoisInstituteofTechnology)<br />
  213. 213. TMM - TestMaturityModel<br /><ul><li>Criado para complementar o CMMI
  214. 214. Define atividades, tarefas e responsabilidades
  215. 215. Contém um Modelo de Maturidade e um Modelo de Acessibilidade
  216. 216. O TMM possui cinco níveis de maturidade que refletem o grau de maturidade do processo de teste</li></li></ul><li>TMM - TestMaturityModel<br />Resultados - arquivados com o objetivo de melhoramentos em estágios anteriores.<br />- Resultado = sw com baixo risco e pouco esforço de testes<br /><ul><li>Os testes são completamente definidos, bem fundamentados e medidos.
  217. 217. Os sw são avaliados a partir de critérios de qualidade por características, como reusabilidade, usabilidade e mantenabilidade.
  218. 218. Os testes são completamente integrados ao ciclo de vida do software.
  219. 219. Reconhecido em todos os níveis do modelo V.</li></ul>Estratégias baseadas nos riscos<br /><ul><li> mostrar que a aplicação não funciona</li></ul>Definição clara de um processo de teste.<br />Os testes são caóticos, não existe processo definido - OBJETIVO mostrar que funciona<br />
  220. 220. TMM – Nível 1<br />Nãoháobjetivos de maturidade<br />Teste é um processocaótico e desorganizado<br />Testesãorealizados de maneiraapósfinalização do código.<br />
  221. 221. TMM – Nível 2<br />Objetivos de teste e de depuraçãosãoestabelecidos<br />Planejamento dos testes<br />Institucionalização de métodos e técnicasbásicas de teste<br />
  222. 222. TMM – Nível 2<br />Realização de objetivos de teste e de depuração:<br />Uma equipe de testes deve ser formado, responsável pela definição das metas de teste<br />A equipe desenvolve e registra os objetivos dos testes<br />A equipe de testes é responsável pela definição das metas de testes<br />Os planos de testes devem refletir as metas de testes<br />
  223. 223. TMM – Nível 2<br />Planejamento dos testes<br />Estabelecimento do plano de testes organizacional<br />Criação e distribuição de um template para planejamento de testes <br />Documentação dos requisitos dos clientes que servirão como entrada no doc. de planejamento de testes <br />Ferramentas para apoio a planejamento de testes devem ser avaliadas, recomendadas e utilizadas<br />
  224. 224. TMM – Nível 2<br />Institucionalização de métodos e técnicasbásicas de teste<br />As técnicas devem ser avaliadas e recomendadas<br />As políticas institucionais garantem que as técnicas recomendadas são constantemente aplicadas por toda a organização.<br />
  225. 225. TMM – Nível 3<br />Criação de umafábrica de testes (Ambiente)<br />Treinamentostécnicos<br />Integração do processo de testes aociclo de desenvolvimento do software<br />Início de um processo de gerenciamento de riscos<br />Controle e monitoramento do processo de testes<br />
  226. 226. TMM – Nível 3<br />Estabelecimento de umafábrica de testes<br />O grupo de testes é estabelecido, com liderança própria e suporte da gerência do projeto<br />Os papéis e responsabilidades são definidos para o grupo<br />Seleciona-se engenheiros melhor capacitados, treinados e motivados<br />Definição das formas de comunicação com os usuários para atendimento as necessidades do usuário e requisitos<br />
  227. 227. TMM – Nível 3<br />Programa de treinamentostécnicos<br />Organização e criação de um programa de treinamentos<br />Estabelecimento de objetivos e planos de treinamento <br />Treinamento interno do grupo deve acontecer, as ferramentas e os materiais devem ser disponibilizados<br />
  228. 228. TMM – Nível 3<br />Integração do processo de testes aociclo de desenvolvimento do software<br />A fase de testes deve ser particionada em sub-fases que se conectam<br />Uma adapção do modelo em V deve ser desenvolvida e adotada<br />Padrões devem ser desenvolvidos para os artefatos gerados pela equipe de testes<br />Integração entre as equipes de desenvolvimento e de testes<br />
  229. 229. TMM – Nível 3<br />Processo de gerenciamento de riscos<br />Políticas e estratégias para controle das atividades da equipe de testes<br />Medições ligadas ao processo devem ser iniciadas<br />Planos de ação que partem das medições são aplicadas na melhoria do processo de testes<br />
  230. 230. TMM – Nível 4<br />Programasorganizacionais de revisões<br />Programa de medições<br />Avaliaçãodaqualidade do Software<br />
  231. 231. TMM – Nível 4<br />Programasorganizacionais de revisões<br />Programas de revisão devem ser implantados de maneira organizacional<br />A equipe de testes deve participar, junto com a equipe de qualidade da definição de verificações para revisões<br />A equipe de qualidade deve definir metas para as revisões<br />Equipes devem ser treinadas sobre o processo de revisão<br />
  232. 232. TMM – Nível 4<br />Criação de um programa de medições<br />Políticas organizacionais de medição e análise<br />Definição de plano de medição<br />Planos de ação provenientes da análise dessas métricas devem ser utilizadas para a melhoria continua do processo de testes<br />
  233. 233. TMM – Nível 4<br />Avaliaçãodaqualidade do Software <br />As metas de qualidade devem ser definidas <br />atributos de qualidade,<br />equipes de teste de qualidade e a gerência (ISO 9126)<br />O processo de testes deve ser moldado de forma a conseguir atingir as metas determinadas no plano de qualidade<br />
  234. 234. TMM – Nível 5<br />Aplicação de um processo de prevenção de defeitos<br />Controle de Qualidade<br />Otimização do Processo de Testes<br />
  235. 235. TMM – Nível 5<br />Aplicação de um processo de prevenção de defeitos<br />Formação de uma equipe de prevenção de defeitos<br />Os defeitos são identificados e reportados durante todas as fases do ciclo de desenvolvimento<br />Mecanismo para análise de causas dos defeitos<br />O planos de ação <br />envolvem as equipes de desenvolvimento testes e gerência para evitar a repetição dos defeitos<br />
  236. 236. TMM – Nível 5<br />Controle de Qualidade<br />A equipe de testes e equipe de qualidade <br />Estabelecem as metas como quantidade de defeitos em cada fase do desenvolvimento<br />Tais metas devem ser incorporadas no plano de testes<br />O feedback do usuário deve ser colhido para melhoria do software<br />
  237. 237. TMM – Nível 5<br />Otimização do Processo de Testes<br />Ocorre a identificação de práticas que podem ser melhoradas<br />Implementar e acompanhar as melhorias<br />Avaliação constante das ferramentas de apoio<br />Estudo e suporte as mudanças de tecnologias<br />
  238. 238. Classificação dos Testes<br />Os tipos e técnicas de testes podem ser classificados em:<br />Caixa branca: técnica de teste que avalia o comportamento interno do componente de software. Trabalha diretamente sobre o código-fonte.<br />
  239. 239. Caixa Branca - estrutural<br />Comportamento interno do sw<br />Código fonte:<br />teste de condição, <br />teste de fluxo de dados,<br />teste de ciclos <br />teste de caminhos lógicos<br />Exemplo uso da ferramenta JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos em Java<br />Esta técnica deve ser aplicada pelos desenvolvedores que conhecem bem o código produzido, testes de unidades e integração.<br />
  240. 240. Caixa Preta<br />Caixa preta: são conduzidos na interface do software, sem preocupação com a estrutura lógica interna do software.<br />
  241. 241. Caixa preta – teste funcional<br />O que pode ser testado ? <br />Um método, função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. <br />é aplicável a todas as fases de teste<br />teste de unidade (ou teste unitário), <br />teste de integração, <br />teste de sistema e aceitação.<br />Gera um conjunto de casos de teste (entradas, saídas e critérios de teste). <br />
  242. 242. Mitos sobre testes<br />Alguns mitos sobre a atividade de testes:<br /> O testador é inimigo do desenvolvedor<br /> A equipe pode ser formada pelos desenvolvedores menos qualificados<br /> Quando estiver tudo pronto, o sistema vai para teste.<br />
  243. 243. Visão geral de processos<br />Um processo é formado por atividades inter-relacionadas com um objetivo especifico. Possui entradas de dados e produtos, para, através da identificação dos recursos necessários ao processo, transformar estas entradas nos objetivos desejados.<br />
  244. 244. Visão geral de processos<br />
  245. 245. Processo de teste<br />Cenário atual:<br /> Testes são realizados como uma etapa do processo de desenvolvimento<br /> Pressões sobre prazos fazem com que o esforço de testes seja reduzido ou até mesmo eliminado<br /> O objetivo é assegurar que as especificações foram construídas<br /> Testes são realizados pelos desenvolvedores ou analistas de sistema<br /> Testes são realizados ao final do desenvolvimento<br /> Não há garantias de que o software foi testado adequadamente<br />
  246. 246. Cenário desejável:<br /> O teste é tratado como um processo independente, porém altamente integrado ao processo de desenvolvimento<br /> Os testes são iniciados paralelamente ao processo de desenvolvimento<br /> Testes realizados por equipes altamente qualificadas e especializadas<br />
  247. 247. Pontos de verificação<br />Tendo em mãos as planilhas de testes o testador em busca dos erros...<br />Albuquerque, et. All.<br />
  248. 248. Objetivo do processo de teste<br />Permitir o teste de softwares usando pessoal técnico qualificado, ferramentas adequadas e base em metodologia aderente ao processo de desenvolvimento da organização<br />
  249. 249. Verificação e Validação<br />O processo de teste é dividido em duas grandes áreas:<br />Verificação<br />Responde se o sistema foi construído<br />Validação<br />Responde se construímos o sistema correto<br />
  250. 250. Modelo V<br />A estrutura do modelo V é uma aproximação do processo de testes que pode ser integrada com todo a processo de desenvolvimento. O modelo V representa o desenvolvimento versus o teste.<br />O modelo V focaliza-se em testar durante todo o ciclo de desenvolvimento para conseguir uma detecção adiantada dos erros.<br />
  251. 251. Modelo V<br />Modelagem de Negócios<br />Testes de Aceitação<br />Verificação<br />Análise de Requisitos<br />Testes de Sistema<br />Validação<br />Arquitetura do Sistema<br />Testes de Integração<br />Testes Unitários<br />Design<br />Construção<br />
  252. 252. Fluxo básico de atividades<br />
  253. 253. Principais envolvidos no processo de teste<br />
  254. 254. Princípios gerais do teste de software<br />Alguns princípios foram sugeridos ao longo dos últimos 40 anos:<br />Teste demonstra a presença de defeitos<br />Teste exaustivo é impossível<br />Teste antecipado (iniciar o quanto antes)<br />Agrupamento de defeitos <br />Teste depende do contexto<br /> A ilusão da ausência de erros (deve atender as necessidades dos usuários)<br />Fonte: Certificação em Teste FoundationLevelSyllabus – Versão 2007br<br />
  255. 255. Principais organizações e institutos envolvidos<br />A disseminação dos processos de teste é relativamente nova no Brasil. Algumas organizações/institutos criados estão tendo a missão de profissionalizar a atividade no país.<br />ALATS – Associação Latino Americana de Teste de Software<br /> CBTS – Certificação Brasileira de Teste de Software<br />QAI – QualityAssuranceInstitute<br /> CSTE – CertifiedSoftwareTester<br />BSTQB – Brazilian Software Testing Qualifications Board<br /> CTFL – Certified Tester Foundation Level<br />ISEB – Foundation Certificate in Software Testing<br /> Certificação em teste de software<br /> Norma IEEE 829<br /> Define normas e padrões ao processo de teste e qualidade do produto.<br />ISO 9126-1 Define as características da qualidade do software<br />
  256. 256. A Norma IEEE 829<br />
  257. 257. Exercícios de revisão<br />Indique se é verdadeiro ou falso:<br />a - ( ) O testes devem ser realizados para mostrar a ausência de defeitos.<br />b - ( ) Caixa branca são testes baseados em um exame rigoroso do detalhe procedimental. Caminhos lógicos e colaborações entre componentes são testadas.<br />c - ( ) O processo de teste deve ser independente do processo de desenvolvimento, porém integrado.<br />d - ( ) Testes de software é uma das atividades de Verificação e Validação. <br />e - ( ) A equipe de testes pode ser formada por desenvolvedores menos qualificados.<br />f - ( ) Um processo é formado por atividades inter-relacionadas com um objetivo especifico. Possui entradas de dados e produtos, para, através da identificação dos recursos necessários ao processo, transformar estas entradas nos objetivos desejados.<br />
  258. 258. Considerações<br />Teste é um projeto - e como tal deve ser planejado<br /> Teste é um projeto integrado ao projeto de desenvolvimento<br /> Testar reduz riscos do negócio<br /> Não dá para planejar sem saber o tamanho do seu projeto<br /> O Plano de Teste é o instrumento básico de planejamento de projeto de teste<br /> Os artefatos devem estar sob gerência da configuração<br /> Deve ser possível, a partir dos requisitos do negócio, rastrear-se os artefatos de teste<br />
  259. 259. Limitação<br /> Muitas empresas ainda usam o modelo Waterfall, ou modelo cascata, que foca justamente a atividade de teste de software somente no final do modelo, ou seja, caso algum defeito seja encontrado (erros em requisitos, por exemplo) todo ciclo deverá ser inicializado novamente. O teste de software na verdade, foca quase que exclusivamente as atividades de verificação e validação. <br />
  260. 260. Estratégia, estágios, tipos e técnicas de teste<br />
  261. 261. O que é estratégia de teste?<br /> Uma estratégia de testes de software descreve a abordagem geral e os objetivos das atividades de teste. Ela deve contemplar os níveis ou fases de teste, os tipos de testes a serem realizados e as técnicas para sua execução. A estratégia de testes de softwares também deve descrever com clareza os critérios para a conclusão dos testes e os critérios de sucesso a serem usados.<br />
  262. 262. O que deve conter uma estratégia de teste?<br />A estratégia de teste deve responder as perguntas que seguem:<br /> Quando vamos testar?<br /> O que vamos testar?<br /> Como vamos testar?<br />
  263. 263. Estratégia de teste - Pressman<br />
  264. 264. Estratégia de teste<br />Eng. De sistemas – define o papel sosw, análise dos requisitos, função, comportamento, restrições e critério de validação.<br />Para desenvolvimento de software o espiral dá voltas para dentro.<br />Para os testes as voltas são para fora.<br />
  265. 265. Desenvolvimento da estratégia de teste<br /> Ao elaborar uma estratégia de teste eficiente e eficaz, devemos ter em mente a execução de alguns passos:<br /> Avaliar os requisitos do sistema.<br /> Identificar e analisar os riscos para o negócio.<br /> Analisar as possibilidades de testes para minimizar os riscos.<br /> Estabelecer os tipos e técnicas de teste a serem realizadas.<br /> Definir prioridades para os testes.<br /> Estabelecer quais produtos serão inspecionados ou testados.<br />
  266. 266. Dimensões de testes<br />Tipos de Teste<br />(O que testar?)<br />Estrutural<br />Funcional<br />Técnica de Teste<br />(Como testar?)<br />Estágios ou Níveis de Teste (Quando testar?)<br />
  267. 267. Estágio ou níveis de teste<br /> Estágios ou níveis de teste é a dimensão do teste que trata do “quando testar”, ou seja, a qual fase do desenvolvimento de software se aplica um determinado tipo de teste. Seguem os quatro estágios ou níveis de teste:<br />1: Estágios ou níveis de teste<br /> Testes Unitários<br /> Testes de Iteração ou Integração<br /> Testes de Sistema<br /> Teste de Aceitação<br />
  268. 268. Testes Unitários<br />O primeiro nível de teste é o Teste Unitário, que envolve assegurar que cada funcionalidade especificada no desenho do componente tenha sido implementada corretamente neste componente.<br />Características deste nível:<br /> Testes realizados em uma unidade independente do produto.<br /> Estágio mais baixo da escala de teste.<br /> Aplicado nos menores componentes de código criados, visando garantir que estes.<br />atendem as especificações funcionais e de arquitetura.<br /> Geralmente realizado pelo desenvolvedor que construiu a unidade.<br /> Utiliza técnicas de Caixa Branca.<br />
  269. 269. Testes de Iteração ou Integração<br /> Como os componentes são construídos e testados separadamente, ao serem acoplados deve-se verificar se eles interagem corretamente.<br /> Neste nível os testes não são focados em “o quê” os componentes fazem, mas se eles se comunicam conforme especificado no desenho do sistema.<br />Características deste nível:<br /> Acontece após os Testes Unitários.<br /> Realizados dentro de um ambiente controlado.<br /> Geralmente realizado pelo analista de sistema para um módulo ou conjunto de programas.<br /> Normalmente são seguidos dois métodos de interação:<br /> Abordagem Top-Down<br /> Abordagem Bottom-Up<br />
  270. 270. Testes de Iteração ou Integração - Abordagem<br />Os módulos são integrados movimentando-se de cima para baixo, através da hierarquia de controle, iniciando-se com o módulo de controle principal.<br /> Funciona bem com desenvolvimento estruturado.<br /> Identifica problemas no desenho da arquitetura mais cedo.<br /> Pode necessitar muita infra-estrutura.<br />
  271. 271. Testes de Iteração ou Integração - Abordagem<br />Abordagem Bottom-Up<br />Apropriado para desenvolvimento orientado a objetos.<br /> Os componentes de intra-estrutura são críticos.<br /> Só consegue identificar os maiores problemas de arquitetura tardiamente.<br />
  272. 272. Testes de Sistema<br /> Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a exatidão e a perfeição na execução das funções requeridas.<br />Características deste nível:<br />Acontece após todos os testes de integração<br /> Realizado dentro de um ambiente controlado<br /> Realizado pela equipe de testes<br /> Envolve testes especializados para validar todos os requisitos funcionais e<br />não-funcionais:<br /> Desempenho<br /> Volume<br /> Documentação<br /> Robustez<br />
  273. 273. Tipos de Testes de Sistema<br /> Os testes de sistema têm foco no funcionamento do sistema como um todo, para validar a exatidão e a perfeição na execução das funções requeridas.<br />Entre outros, são realizados os seguintes testes:<br /> Teste de Funcionalidade<br /> Teste de Segurança<br /> Teste de Estresse<br /> Teste de Desempenho<br />
  274. 274. Teste de Aceitação<br /> Último nível de testes antes da implantação do software em ambiente de produção. Seu objetivo é verificar se o sistema tem condições de ser implantado em produção, com base nos critérios de aceitação.<br />Algumas características:<br />É de responsabilidade do Cliente.<br />Tem a finalidade de validar se o software está apto a entrar em produção e executar as funções ou tarefas a que se propôs.<br />Geralmente realizado em ambiente de homologação do Cliente.<br /> Testes de aceitação são realizados pelo usuário final para capacitá-lo e para validar todos os requisitos.<br />
  275. 275. Dimensão 2: Tipos de Teste<br /> Todo software visa atender uma demanda de qualidade, e para isso deve atender a certos atributos de qualidade como:<br /> Funções<br /> Interface<br /> Características de tempo de resposta e de segurança<br /> Integridade<br /> Habilidade de ser instalado e executado em diferentes plataformas<br /> Habilidade de lidar com muitas requisições simultâneas, Etc.<br /> Para conseguir isto, diferentes tipos de teste são implementados e executados. Cada tipo de teste tem objetivo e técnica de suporte específicos. Cada técnica de teste foca em testar uma ou mais características ou atributos do objetivo do teste.<br />
  276. 276. Características da qualidade<br />
  277. 277. Características da qualidade<br />A ISO 9126-1 define seis características de qualidade que o software deve atender:<br />Funcionalidade: verifica a capacidade do sistema em prover funcionalidades definidas que atendam as necessidades do usuário, quando usado sob determinadas condições preestabelecidas.<br />Confiabilidade: o produto de software é capaz de manter seu nível de desempenho, ao longo do tempo, nas condições estabelecidas de utilização.<br />Usabilidade: capacidade do software em ser entendido, aprendido e utilizado sob condições estabelecidas de utilização.<br />Eficiência: os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido pelo software.<br />Manutenibilidade: refere-se ao esforço necessário para a realização de alterações específicas no produto de software.<br />Portabilidade: facilidade de o software poder ser transferido de um ambiente para outro.<br />
  278. 278. Características x Técnicas<br />Como dito anteriormente, é possível executar tipos de testes para assegurar que cada característica de qualidade seja atendida.<br />
  279. 279. Dimensão 3: Técnicas de teste<br />Técnica de teste estrutural<br />Utilizada quando o objetivo é garantir que o produto desenvolvido está estruturado e funciona corretamente. Pretende determinar se a tecnologia utilizada foi apropriada e se os componentes montados funcionam como uma unidade coesa.<br />Técnica de teste funcional<br />Utilizada quando o objetivo é verificar se os requisitos do sistema e as especificações foram atendidas. Envolve a criação de cenários de testes para uso na avaliação das funcionalidades da aplicação, validando se o que foi especificado foi implementado corretamente. <br /> O teste funcional não está preocupado com o processo ocorre em si, e sim com os resultados do processo.<br />
  280. 280. Teste de estresse<br /> A principal meta do teste de estresse é entender o comportamento do sistema durante condições-limite de execução ou fora da tolerância esperada. Tipicamente envolve a execução do sistema com baixos recursos de hardware e software, ou a concorrência por estes recursos.<br />
  281. 281. Teste de estresse<br />A principal meta do teste de estresse é entender o comportamento do sistema durante condições-limite de execução ou fora da tolerância esperada.<br />Tipicamente envolve a execução do sistema com baixos recursos de hardware e software, ou a concorrência por estes recursos.<br />
  282. 282. Teste de estresse<br />Objetivos:<br /> Determinar a que condições-limite de recursos o software é capaz de ser executado.<br /> Verificar se o sistema é capaz de garantir tempos adequados de resposta sendo executado em condições-limite.<br />Verificar se há restrições quanto ao ambiente em que o software vai operar.<br /> Determinar que volumes de transação, normais e acima dos normais, podem ser processados num período de tempo esperado.<br />
  283. 283. Quando usar<br />Quando não se sabe quais as condições mínimas de recursos para operacionalização do sistema, sem que haja perdas significativas.<br />
  284. 284. Teste de contingência<br /> A meta principal do teste de contingência é verificar se, após uma falha, a sua recuperação é adequadamente executada, garantindo a continuidade dos serviços.<br />Objetivos:<br /> Manter o backup dos dados<br /> Armazenar o backup em local seguro<br /> Documentar os procedimentos de recuperação<br /> Deixar claro as responsabilidades das pessoas em caso de um desastre<br />
  285. 285. Quando usar<br />Sempre que a continuidade dos serviços for essencial para o negócio.<br /> Perdas devem ser estimadas (quanto vou perder por hora?).<br /> A quantidade de perda potencial estipula a quantidade de esforço que irá ser empregada.<br />
  286. 286. Teste de segurança<br /> A principal meta do teste de segurança é garantir que os dados ou funções de um sistema possam ser acessados apenas por atores autorizados a acessá-las. Todas as formas de ataque de acesso indevido devem ser simuladas.<br />Objetivos:<br /> Garantir que os dados do sistema estão protegidos adequadamente.<br /> Assegurar que todos os riscos que envolvem os acessos indevidos foram identificados.<br />Analisar as ameaças e vulnerabilidades, tanto físicas como lógicas.<br /> Assegurar que os mecanismos de controle contra acessos indevidos foram corretamente implementados.<br />
  287. 287. Quando usar<br /> Testes básicos de segurança devem ser aplicados a todos os softwares.<br /> Quando a informação que circula através do software for de importância fundamental para a organização.<br />
  288. 288. Teste de performance<br /> O teste de performance, ou de desempenho como também é conhecido, mede e avalia o tempo de resposta, o número de transações e outros requisitos sensíveis ao tempo de resposta do sistema.<br />Objetivos:<br /> Determinar o tempo de resposta das transações.<br /> Verificar se os critérios de desempenho estabelecidos estão sendo atendidos.<br /> Identificar pontos de gargalo no sistema.<br /> Verificar o nível de utilização do hardware e software.<br />
  289. 289. Quando usar<br />Quando se deseja avaliar o tempo de resposta de uma.<br />funcionalidade do sistema ou de todo o sistema.<br /> Devem ser realizados quando ainda há tempo hábil de serem realizadas correções.<br />
  290. 290. Teste de conformidade<br /> Verificar se a aplicação foi desenvolvida seguindo os padrões, procedimentos e guias da área de processos.<br /> As metodologias são usadas para aumentar a probabilidade de sucesso do projeto, e portando devem ser testadas.<br />Objetivos:<br /> Verificar se as metodologias de sistema estão sendo seguidas<br /> Garantir as conformidades aos padrões da empresa<br /> Avaliar se a documentação do sistema é racional e está completa<br />
  291. 291. Quando usar<br />Quando se deseja que os padrões sejam seguidos.<br /> Quando se deseja determinar o nível de seguimento dos padrões.<br /> Quando se deseja identificar pontos falhos na metodologia.<br />
  292. 292. Testes funcionais<br /> O teste funcional tem por meta verificar se o software executa corretamente suas funções, se a implementação das regras de negócio foi apropriada e se o sistema é capaz de sustentar sua correta execução por um período contínuo de uso. <br />Objetivos:<br /> Assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta.<br /> Verificar se os requisitos dos usuários estão implementados e se atendem os usuários.<br /> Verificar se o sistema funciona corretamente após um período contínuo de utilização.<br />
  293. 293. Quando usar<br />Qualquer sistema deve ser suas funcionalidades testadas.<br /> Pode ser usado desde a fase de especificação de requisitos até a fase de operação do sistema.<br />
  294. 294. Teste de regressão<br />Tem como propósito garantir que os defeitos encontrados foram corrigidos e que as correções ou inserções de novos códigos em determinados locais do software não afetaram outras partes inalteradas do produto.<br />Objetivos:<br /> Verificar se as alterações realizadas geraram alguma inconsistência no aplicativo ou em outros sistemas<br />Verificar se as funções previamente testadas continuam funcionando após realização de mudanças<br /> Determinar se a documentação do sistema permanece atual<br /> Determinar se os dados e as condições de teste permanecem atuais<br />Quando usar:<br />Quando há o risco de que mudanças em uma parte do<br />sistema afetem outras partes inalteradas do sistema.<br />
  295. 295. Teste de interconexão<br /> O teste de interconexão, ou teste integrado como também <br />é conhecido, tem como propósito testar as integrações com sistemas externos.<br />Objetivos:<br /> Verificar se os dados que são transferidos de um sistema para o outro estão sendo transferidos corretamente<br /> Garantir que as ações de integração de um software estão alinhadas com as ações de integração do outro software<br />Quando usar:<br /> Sempre que uma alteração que possui impacto nas funcionalidades integradas for realizada<br />
  296. 296. Teste de usabilidade<br />O teste de usabilidade verifica a facilidade que o software possui de ser claramente entendido e facilmente operado pelos usuários<br />Objetivos:<br /> Verificar a facilidade de operação do sistema pelo usuário<br /> Verificar a facilidade de entendimento das funções do sistema pelo usuário, através da utilização de manuais, on-line help, agentes e assistentes eletrônicos, etc.<br />Como usar:<br /> Executar diversas operações do sistema, utilizado a documentação do mesmo.<br />
  297. 297. Desenvolvendo a estratégia de testes<br /><ul><li>Teste de funcionalidade
  298. 298. Desempenho
  299. 299. Interface
  300. 300. Stress (carga)
  301. 301. Usabilidade
  302. 302. Segurança</li></ul>Tipos de Teste<br />(O que testar?)<br />Estrutural<br />Funcional<br />Técnica de Teste<br />(Como testar?)<br /><ul><li>Teste de unidade
  303. 303. Teste de integração
  304. 304. Teste de sistema
  305. 305. Teste de aceitação
  306. 306. Teste de regressão</li></ul>Estágios ou Níveis de Teste (Quando testar?)<br />
  307. 307. Baseando-se nos riscos<br />Quanto mais crítico for o software, mais testes terão de ser gastos para a garantia da qualidade do produto. Isso significa dizer que quem define a quantidade de testes é a criticidade do negócio.<br />Falhas ou defeitos estão associados a riscos que podem prejudicar o negócio. Existem diversas técnicas para elaborar Análises de Riscos, e conseqüentemente escrever uma Estratégia de Testes.<br />Uma das formas de se fazer uma Análise de Riscos é associar o risco a uma característica de qualidade de software.<br />
  308. 308. Coleta de falhas<br />Ficha de coleta de erros<br />
  309. 309. Exercícios de revisão<br />1) A MELHOR definição do objetivo do teste de aceitação é:<br />a) Garantir que o software entre sem erros na produção<br />b) Garantir que o grupo de testes fez um bom trabalho<br />c) Executar um teste funcional<br />d) Garantir que o software esteja fazendo exatamente aquilo que foi solicitado nos requisitos de negócio<br />2) Quais fatores de qualidade deveriam ser usados num software de navegação de uma aeronave?<br />a) Confiabilidade, Integridade e Eficiência<br />b) Eficiência, Confiabilidade e Correção<br />c) Portabilidade, Integridade e Correção<br />d) Portabilidade, Testabilidade e Usabilidade<br />
  310. 310. TESTES - Princípios básicos para o teste de software - WebApps<br /> Pressman (2006) apresenta uma abordagem que adota os princípios básicos para o teste de todo software, aplica estratégias e táticas que são recomendadas para sistemas OO. <br />Revisar o conteúdo a fim de descobrir erros de grafia, gramática, consistência do conteúdo, representações gráficas, dentre outros;<br />Revisar o projeto de navegação para descobrir erros nos links e/ou na permissão de acesso de cada usuário;<br />testar cada página focando seu processamento;<br />Testar a funcionalidade geral e conteúdo fornecido;<br />Testar a compatibilidade da aplicação em diferentes configurações <br />diferentes browsers, sistemas operacionais, plataformas de hardware e protocolos de comunicação. <br />
  311. 311. Ambientes de testes<br />
  312. 312. Ambiente de testes<br />infra-estrutura onde o teste será executado<br />Configurações de hardware e software,<br />Ferramentas de automação,<br />Equipe envolvida, <br />Aspectos organizacionais, <br />Documentação<br />
  313. 313. Elementos do Ambiente de testes<br />Devem ser considerados no planejamento e deve ser pensada na fase inicial.<br />- Deve prever possíveis problemas que poderão ocorrer <br />
  314. 314. Ambientes – 3 tipos<br />A simulação dos testes deve chegar mais próximo do cenário real possivel<br />
  315. 315. Ferramentas essenciais para gestão e automação de testes de software<br />A adoção de ferramentas visa dar suporte ao processo de melhoria.<br />254<br />
  316. 316. 255<br />Mantishttp://www.mantisbt.org/ <br />Ferramenta Open Source.<br /> Objetivo: Registrar e acompanhar os bugs encontrados em um projeto, desde o seu nascimento até o seu fechamento. <br />Fases:<br />Confirmação,<br />Correção,<br /> Revisão e o fechamento do bug. <br />
  317. 317. Entre as diversas funcionalidades oferecidas pelo Mantis, devemos destacar as seguintes: <br />Pode ser executado em qualquer plataforma que suportar PHP/Apache (Windows, Linux, Mac, Solaris, AS400/i5, etc); <br />Suporta vários bancos de dados (MySQL, MS SQL, PostgreSQL); <br />Suporta múltiplos mecanismos de autenticação (Interna, LDAP, HTTP Basic, ActiveDirectory); <br />Traduzido em 68 línguas diferentes (incluindo "portuguese_brazil"); <br />Criação ilimitada de projetos e relatos de defeitos; <br />Controle de acesso e níveis de permissões para os usuários; <br /><ul><li> Ciclo de vida dos defeitos personalizável;
  318. 318. Gerador interno de relatórios e gráficos (possibilidade para exportar os dados nos formatos CSV, Excel e Word);
  319. 319. Mecanismo para a criação de campos personalizáveis;
  320. 320. Notificações por email automáticas ou por meio de RSS Feeds;
  321. 321. Integração com ferramentas de controle de versões (Subversion e CVS);
  322. 322. Interface Webservice para integração com outras ferramentas; </li></ul>256<br />
  323. 323. 257<br />Criando um novo projeto no Mantis<br />
  324. 324. 258<br />Registrando um bug no Mantis<br />
  325. 325. 259<br />Exemplo de bugs<br />
  326. 326. TestLink - http://www.teamst.org/ <br />Por meio do TestLink é possível :<br />Criar Test Cases e organizá-los em TestSuites;<br />Associar um conjunto de Test Cases a um testador e acompanhar os resultados da execução dos testes;<br />Gerar relatórios com diversas métricas para o acompanhamento da execução dos testes;<br />Registrar e organizar os requisitos do projeto;<br />Associar os Test Cases aos requisitos, visando garantir o rastreamento entre os requisitos ;<br />260<br />
  327. 327. TestLink - Funcionalidades<br />Pode ser executado em qualquer plataforma que suportar PHP/Apache/Mysql;<br />Controle de acesso e níveis de permissões por papéis (Líder, Testador, etc); <br />Os casos de testes são organizados hierarquicamente em suítes; <br />Os casos de testes podem ser classificados por palavras-chave "keyword" para facilitar a pesquisa e organização; <br />Criação ilimitada de projetos e casos de testes; <br />Os ciclos de testes podem ser priorizados e atribuídos aos testadores; <br />Gerador interno de relatórios e gráficos (possibilidade para exportar os dados nos formatos CSV, Excel e Word); <br />Integração com ferramentas de gestão de defeitos (Bugzilla, Mantis, Jira); <br />261<br />
  328. 328. 262<br />Criando um novo Test Case <br />
  329. 329. 263<br />Seleniumhttp://www.openqa.org/selenium/<br />Utilizada para criação de testes de regressão automatizados para aplicações WEB;<br />Escrito utilizando Java Script e DHTML ;<br />
  330. 330. 264<br />O TestRunner é a página que gerencia a execução dos testes e exibe o relatório de progresso da execução. <br />
  331. 331. Caso de teste escrito em Selenês<br />265<br />
  332. 332. Automação de testes de performance <br />266<br />
  333. 333. Razões<br />mudança de plataforma das aplicações legadas para a plataforma WEB.<br />A migração para a plataforma WEB trouxe novos desafios sob o ponto de vista do planejamento e execução dos testes, tais como: <br /> Performance, segurança, suportabilidade, usabilidade ...<br />267<br />
  334. 334. Escrita em Java;<br />Pode ser executada em qualquer plataforma que suporte a máquina virtual do Java;<br />Facilita todo o processo de criação e depuração dos testes por meio de uma interface gráfica intuitiva<br />JMeterhttp://jakarta.apache.org/jmeter/index.html <br />268<br />
  335. 335. JMeter<br />O JMeter oferece recursos para realizar:<br />Testes de performance, <br />volume e estresse automatizados para aplicações WEB, <br />servidores FTP, <br />WEB Services, <br />Banco de Dados, entre outros.<br />269<br />
  336. 336. Recursos oferecidos pelo JMeter<br />Ferramenta gratuita para Windows;<br />Pode ser executado em qualquer plataforma que suporte a máquina virtual do Java;<br />Suporta a criação de testes de performance para os protocolos (HTTP, JDBC, FTP, JMS, LDAP, SOAP, entre outros); <br />Possibilidade de executar os testes em computadores distribuídos;<br />Possibilidade de monitorar a performance de um servidor Apache Tomcat; <br />Permite a utilização de pré-processadores e pós-processadores para modificar o comportamento das requisições; <br />Suporta diversos tipos de monitores para avaliar a performance da aplicação em teste; <br />270<br />
  337. 337. Microsoft WEB Application Stress <br />O WAS permite que você crie um teste de performance por meio dos seguintes mecanismos: <br />Manual: Você deverá inserir manualmente as requisições HTTP (GET, POST, etc) trocadas entre o navegador e o servidor da aplicação WEB; <br />Record: Cria o teste automaticamente por meio da gravação das requisições HTTP (GET, POST, etc) trocadas entre o navegador e o servidor da aplicação WEB; <br />Log file: Cria o teste automaticamente com base nas informações de um arquivo de log do IIS; <br />Content: Cria o teste automaticamente com base na leitura dos arquivos (HTML) e diretórios do site ou aplicação WEB; <br />271<br />http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en<br />
  338. 338. Microsoft WEB Application Stress <br />272<br />Gravando um teste por meio de um HTTP Proxy <br />
  339. 339. Executando o teste <br />273<br />
  340. 340. Visualizando o resultado geral dos testes<br />274<br />
  341. 341. Data Generator<br />Aplicação WEB Open Source;<br />Baseada em JavaScript, PHP andMySQL;<br />Principal função é gerar enormes volumes de dados para popular banco de dados de testes;<br />Tem grande serventia quando a aplicação é nova e não existem dados nas tabelas do banco de dados para realizar os testes.<br />275<br />
  342. 342. Data Generator - http://www.generatedata.com/<br />276<br />
  343. 343. http://getfirebug.com/ <br />277<br />Principal função é editar, depurar e monitorar o conteúdo HTML, CSS e JavaScript utilizados em aplicações WEB. <br />Monitora o que está acontecendo por trás da aplicação em teste <br />

×