SlideShare uma empresa Scribd logo
Análise e Projeto de Sistemas II Prof.a Márcia Rabello marcia@imed.edu.br
Perfil do gerente empreendedor Empregado (Gerente) vira Empresário (Empreendedor)
O ser EMPREENDEDOR  Empreendedor é o Individuo preparado para   Identificar oportunidades  Assumir riscos   Errar e apreender com os erros (principalmente dos outros) Má notícia- O emprego esta sumindo Boa notícia - As oportunidades de trabalho não ! Entretanto, é necessário novas habilidades para aproveitá-las 3
Atitude Empreendedora Praticar Networking Ser Proativo Disposição em assumir riscos calculados Postura face a desafios e problemas 4
Atitude- Proativo Missão = Tarefa + Objetivo Tarefa – “o que fazer?” Eficiência - Fazer certo as coisas Objetivo – “por que fazer?”	  Eficácia- Fazer as coisas certas Exemplo real  Chefe para Técnico de Informática  “Leve este CD no cliente e entregue para o chefe das vendas” - Isto é uma tarefa. É mais fácil de se cumprida. É menos arriscada - Fazendo certinho não dá problema (com o chefe) Atitude Empreendedora 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” 5
Você acha certa a afirmativa abaixo? “Faça o que o cliente precisa(e não o  que ele pede)” 6 www.NewtonBragaRosa.com.br - CHA DO EMPREENDEDOR
Atitude- Disposição em assumir Riscos Calculados Risco Se der errado será acusado (pelo chefe, colegas, subordinados etc) de ter ido longe demais... Benefício em assumir risco calculado Maiores benefícios para si e para a empresa Construir relações de longo prazo Indicações de novos clientes Foco no resultado para cliente, empresa ...
Identificamos o empreendedor pelo seu perfil, não pela atividade que exerce
Atividade Pense numa pessoa que você conhece pessoalmente e considera empreendedora. Liste, no mínimo, 5 características empreendedoras que você perceba nela.
Características do empreendedor Capacidade de assumir riscos Aproveitar oportunidades Conhecer o ramo Saber organizar Tomar decisões Ser líder Ter criatividade Ser independente 10 Iniciativa Autoconfiança Necessidade de realizar Comprometimento com o que faz Manter o otimismo Persistência Alta capacidade de trabalho
Características do empreendedor Das qualidades empreendedoras que vimos, quais são aquelas com que nós nascemos? Como podemos desenvolver as demais? Para ser um líder ? Gerente ? A maioria é comportamento. 11
Que características você tem? Para cada uma das características empreendedoras, reflita como elas estão sendo desenvolvidas em você. 12
O gerenciamento de Projetos em TI
Importância da Análise Manutenção Manutenção Teste Implantação Implantação Programação Programação Projeto Físico Projeto Lógico Desenvolvimento com sistemática Desenvolvimento sem sistemática
Imaginando as três caixas Análise do Sistema Implementação  e Implantação Gerência do Projeto
O que é inovação Edivandro Carlos Conforto PhD Research Candidate
Quebra de paradigma
Gerenciamento ágil de projeto
Exceto atividades de análise, projeto e desenvolvimento propriamente dito, que envolvem metodologias, técnicas e ferramentas de desenvolvimento... Ademais em um projeto de sistemas é ação de GERÊNCIA!
O que é o PMBOK ?( Project Management BodyofKnowledge ) Um guia que pretende reunir o conhecimento geral sobre metodologias de gerência de projetos; Apresenta “melhores práticas geralmente aceitas” conforme contribuintes de grupos de estudos formados em diversas entidades; Fornece uma referência para qualquer profissional interessado na profissão de Gerência de Projetos. 22
Quem deve ocupar o cargo de gerente de projetos ? Preferencialmente um profissional ligado a tecnologia da informação ? Algo impede que seja um profissional com a mínima vivência em TI ?
PMBOK Tem como objetivo a melhoria do processo de Gerência de Projetos Abrange 9 áreas de conhecimento: Gerência de Integração Gerência de Escopo Gerência de Tempo Gerência de Custos Gerência de Qualidade Gerência de Recursos Humanos Gerência de Comunicação Gerência de Riscos Gerência de Contratação Determina ferramentas a serem utilizadas no processo de gerência de projetos Define algumas atividades que não trata como Área de Conhecimento (ex: Gerência de Configuração)
Ciclo de vida de um projeto Pmbok
Processo básico
PMBOK Áreas Núcleo GERÊNCIA DA QUALIDADE GERÊNCIA DO CUSTO GERÊNCIA DO TEMPO GERÊNCIA DO ESCOPO GERÊNCIA DA INTEGRAÇÃO GERÊNCIA DOS RECURSOS HUMANOS GERÊNCIA DA COMUNICAÇÃO GERÊNCIA DO RISCO GERÊNCIA DAS AQUISIÇÕES Áreas Facilitadoras
PMBOK - Utilização  Focado em Gerência de Projetos Não possui processo de avaliação formal para a organização   A implementação é feita de forma completa Permite estabelecimento de controles Identifica pontos fortes do Gerente do Projeto e indiretamente da organização  Não se tem registro de custos de implementação em organizações Pode ser utilizado para verificar processos do fornecedor Pode ser utilizado como item de qualificação em concorrências  Requerido em grandes e pequenas organizações
Envolvidos nas fases
Conseqüências de uma análise inadequada    o aumento dos custos   realização de atividades desnecessárias   usuários insatisfeitos   aumento da tarefa de manutenção
Gerência do projeto de software Tonsig, 2003.
Etapas de processos gerenciais Tonsig, 2003.
“ item de Avaliação da Disciplina”Trabalho individual ou dupla  Realizar uma síntese sobre o Modelo CMMI, MPSBR, ISO ou TMM. Muitos consideram que os modelos de qualidade como por exemplo CMM e CMMI muito caros e ou inadequados para serem implementados em pequenas empresas. Procurar dados a respeito. 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.
Situação Atual das Organizações Demanda por Melhor Qualidade! melhor qualidade inclui: menos prazos, custos, defeitos, insatisfações, mais qualidade dos produtos, previsibilidade, produtividade, competitividade, e melhores resultados de negócio (ROI)
Situação Atual das Organizações   Como as empresas de software podem obter a melhoria viável e necessária? Melhoria do Processo de Software baseada em Modelos
 POG - Programação orientadas a gambiarras
37 A Comunicação... Um problema...
O que é Qualidade ?
O que é qualidade ? “Qualidade consiste em desenvolver, criar e fabricar mercadorias mais econômicas, úteis e satisfatórias para o comprador”.  KAORU ISHIKAWA
O que é qualidade ? “Qualidade é o conjunto de características do produto que determinam o grau de satisfação que o mesmo proporciona ao consumidor”  ArmanoFeigenbaum
O que é qualidade ? “A QUALIDADE somente pode ser definida em termos de quem a avalia.”  DEMING
Qualidade de Software Visão do produto pela qual qualidade está relacionada a características do produto. (PFLEEGER) Alinhamento total entre as especificaçõesaprovadas e o produto concluído. Produto final com a menor quantidade de erros possível. 42
O que é qualidade ? Conceitos e tipos de clientes “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) Cliente interno – São aqueles que fazem parte da empresa e, são impactados pelas atividades desenvolvidas por ela (funcionários e acionistas)
Conceitos e tipos de clientes “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) Cliente externo – São pessoas ou organizações que não fazem parte da  empresa, mas também são impactadas pelas suas atividades (quem compra ou quem fornece)
Outras definições ... ,[object Object]
“QUALIDADE não é somente satisfazer o cliente, mas sim seduzi-lo.” (TOM PETERS),[object Object]
Qualidade e Produtividade 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
Qualidade e produtividade Qualidade e produtividade na produção de serviços estão inter-relacionados, pois o incremento da produtividade e aumento da qualidade dependem: ,[object Object]
 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.,[object Object]
 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 .,[object Object]
Maior Produtividade QUALIDADE !! Ser Competitivo Garantir a Sobrevivência
Certificação de Qualidade 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. Para tal é preciso realizar um processo de avaliação e julgamento de acordo com determinada Norma ou Padrão.
Controle de Qualidade É a atividade e técnica operacional utilizada para satisfazer os requisitos de qualidade segundo definição da ISO. 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.
Garantia de Qualidade É uma atividade aplicada ao longo do processo de Engenharia de Software.  Consiste dos procedimentos, técnicas e ferramentas aplicadas para assegurar que um produto atinge ou excede padrões especificados. Abrange: Métodos e ferramentas Revisões técnicas formais Estratégias de teste Controle de Documentação Mecanismos de medição e divulgação
55 Características de Qualidade na Web (Olsina, 99)
Qualidade na Web (Offut 2002) 56 ,[object Object]
Disponibilidade – 24H-7-365D
Escalabilidade/Desempenho
Prazo de colocação no mercadocomo atender a estas especificações?
Melhoria Melhoria de Processo de Software, é uma abordagem baseada em processos, para melhoria de uma organização. Processos Pessoas Tecnologias
Processo de Software É o que as pessoas fazem, utilizando procedimentos, métodos e ferramentas, para adquirir, desenvolver, manter e melhorar software e produtos associados.
Melhoria de Processo de Software 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. 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]
Benefícios da Melhoria doProcesso de Software
Qualidade do produto x Processo A qualidade do produto de software é altamente determinada pela qualidade do processo de desenvolvimento e de manutenção escolhido para a construção. Adaptado de Summerville
Premissas da Qualidade ,[object Object]
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 ,[object Object]
Qualidade e Produtividade    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)  A qualidadedeve ser vista  com olhos de empreendedor! A qualidade de um produto, serviço e processo está boa quando  os custos estão baixos, a rotatividade da equipe é gerenciada,  as vendas estão elevadas e crescentes, os clientes são mantidos  e outros são agregados.
A Norma ISO 9000-3 Grupo Atividade Estrutura do Sistema de Qualidade Responsabilidade do fornecedor, Responsabilidade do comprador, Análise crítica conjunta  Atividades do Ciclo de Vida 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  Atividades de Apoio Gerenciamento de configuração, Controle de documentos, Registros da QualidadeMedição, Regras e convenções, Aquisição, Produto de Software incluído, Treinamento  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.
A Norma ISO 9000-3 - Utilização  Possui processo de certificação formal Implementação por completo Permite melhoria de processos para garantia de qualidade Permite estabelecimento de controles Identifica pontos fortes da organização assim como oportunidades de melhoria Custo pode ser elevado dependendo da implementação Há processo de re-certificação Pode ser utilizada para verificar processos do fornecedor Pode ser utilizado como item de qualificação em concorrências Orientações giram em torno de uma "situação contratual" Normalmente utilizada em grandes organizações
A Norma ISO 12207 - Processos do Ciclo de Vida do Software 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:  Fundamentais - Aquisição, Fornecimento, Desenvolvimento, Operação e Manutenção  Apoio - Documentação, Gerência de Configuração, Garantia de Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria e Resolução de Problemas Organizacionais - Gerência, Infra-estrutura, Melhoria e Treinamento     Descreve com detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de Software
Qualidade do Processo P R O C E S S O D E A D A P T A Ç Ã O Processos Fundamentais Processos de Apoio Documentação Ger. de Configuração Garantia de Qualidade Verificação Validação Revisão Conjunta Auditoria Resolução de Problemas Processos Organizacionais Infra-estrutura Gerência Treinamento Melhoria Aquisição Fornecimento Desenvolvimento Operação Manutenção ISO/IEC 12207Processos do Ciclo de Vida do Software V&V devem ser aplicados durante todo o ciclo de vida do projeto para o efetivo gerenc. De qualidade.
VV&T e a norma ISO/IEC 12207 Verificação Verificação do contrato Verificação do produto Verificação dos requisitos Verificação do projeto Verificação dos códigos Verificação da integração Verificação da documentação Validação – está relacionada a implementação seguindo um plano de validação 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. Teste – no contexto da norma é visto como uma ATIVIDADE e não um processo de VV. Teste de desenvolvimento, operação e manutenção
A Norma ISO 12207 - Utilização Possui processo de certificação formal Implementação por completo Permite melhoria de processos para garantia de qualidade Permite estabelecimento de controles Identifica pontos forte da organização assim como oportunidades de melhoria Custo pode ser elevado dependendo da implementação Há processo de re-certificação Pode ser utilizada para verificar processos do fornecedor Pode ser utilizada como item de qualificação em concorrências   Normalmente utilizada em grandes organizações
Responda A atividade de teste de software no processo de desenvolvimento deve ser aplicada em que momento ?  Apenas na fase de codificação ?  Ou em todo o ciclo de vida ?
CapabilityMaturityModel - CMM    É um modelo, desenvolvido pelo SEI para avaliação e melhoria da capacitação das empresas que produzem software. Publicado em 1992.   Tem como principal objetivo a medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento de software.
Maturidade 	 A maturidade dos processos possui grande influência em: Metas de custos Cronogramas  Qualidade
Organizações Maduras Organizações Imaturas Papéis e Responsabilidades bem definidos Processo improvisado Existe Base Histórica Não existe base histórica É possível julgar a qualidade do produto Não há maneira de julgar a qualidade do produto A qualidade dos produtos e processos é monitorada Qualidade e funcionalidade do produto sacrificadas O processo pode ser atualizado Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu grupo Resolução de crises imediatas CMM - Maturidade
CMM – Níveis de Maturidade Nível CMM Descrição Inicial Processo desorganizado. Poucos processos definidos. Sucesso depende de esforços individuais Repetível Processos básicos de gerenciamento. Permitem acompanhar custo, cronograma e funcionalidade. Repetir o sucesso usando processos similares. Definido 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. Gerenciado Medidas detalhadas da qualidade do produto e do processo de desenvolvimento são coletadas. Todos os produtos e processos são controlados quantitativamente. Otimizado Melhoramento contínuo do processo é conseguido através de “feedback” quantitativo dos processos e pelo uso de tecnologias inovadoras. 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).
Principais atividades para controle e garantia da qualidade Verificação Validação Testes
CMM Processo continuamente aprimorado ,[object Object]
Gerência de mudançastecnológicas
Gerência de mudanças no processoOtimizado 5 Processo previsível Gerenciado 4 ,[object Object]
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õesProcesso consistente, padrão Definido 3 Repetitível 2 Processodisciplinado ,[object Object]
Planejamento de Projetos
Acompanhamento de projetos
Gerência de subcontratos
Garantia de qualidade
Gerência de configuraçãoInicial 1 CMM - Áreas -Chave de Processo São os itens a serem focados pela organização para melhoria do seu processo
CMM - Características Comuns e Práticas-Base Práticas-Base relacionadas  Estabelecimento de políticas Característica Comum Descrição Alocação de recursos, definição da estrutura organizacional e devidos treinamentos Compromisso de realizar Atitudes a serem tomadas pela organização para que o processo se estabeleça Capacidade de realizar Pré-requisitos que devem existir na organização para implementação do processo Estabelecimento de planos, procedimentos, realização do trabalho e tomada de ações corretivas caso necessário Atividades realizadas Papéis e procedimentos necessários para implementar uma área-chave de processo Realização de medições para determinar o estado e a efetividade das atividades realizadas Medições e análise Necessidade de medir o processo e analisar medições Revisão, auditoria e garantia de qualidade Implementação com verificação Passos para garantir que as atividades são realizadas de acordo com o processo estabelecido São itens a serem observados para que se possa verificar a implementação e institucionalização das áreas-chave do processo.
CMM - Utilização  Possui processo de avaliação formal É didático e conhecido no mercado empresarial  Permite implementações por níveis Permite melhoria de processos para garantia de qualidade Permite estabelecimento de controles Identifica pontos forte da organização assim como oportunidades de melhoria Custo pode ser elevado dependendo da implementação Não há processo de re-certificação, ocorre sempre na do próximo nível Pode ser utilizado para verificar processos do fornecedor Pode ser utilizado como item de qualificação em concorrências  Utilizado em grandes organizações com muitos resultados documentados Permite certificação somente por níveis
Nome Nível Atividades Medição Pessoal PSP0 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 Planejamento Pessoal PSP1 Estimativa de Tamanho, Relatório de Testes, Planejamento de Tarefas, Cronogramas Qualidade Pessoal PSP2 Revisões de código, Revisões de projeto, Padrões de projeto Processo Cíclico Pessoal PSP3 Desenvolvimento cíclico Personal Software Process - PSP 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.
Personal Software Process - PSP
PSP - Utilização  ,[object Object]
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,[object Object]
Descrição Adquirir software, Gerenciar necessidades do cliente, Fornecer Software, Operar software, Prover serviço ao cliente  Processo Desenvolver requisitos e o projeto, Implementar o projeto, Integrar e testar o software, Integrar e testar o sistema, manter o sistema e o software Cliente - Fornecedor Engenharia 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 Suporte Gerenciar o projeto, Gerenciar a qualidade, Gerenciar riscos, Gerenciar subcontratadas Gerência Construir o negócio, Definir o processo, Melhorar o processo, Prover recursos de treinamento, Prover infra-estrutura organizacional Organização ISO 15504 - Categorias e Processos
ISO 15504 - Níveis de Capacitação Processo Descrição Incompleto Não existem produtos de trabalho nem saídas do processo facilmente identificáveis. Realizado 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 Gerenciado 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. Estabelecido 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.  Predizível 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. Otimizado 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.
ISO 15504 ProcessosFundamentais Processos de Apoio Documentação Fornecimento Aquisição Ger. de Configuração Ger. NecessidadesCliente ServiçosCliente Garantia de Qualidade TESTES Verificação Desenvolvimento Operação Validação ISO/IEC 15504SPICE Revisão Conjunta Auditoria Manutenção Resolução de Problemas Medição prod/ processo Processo de Reuso ProcessosOrganizacionais AlinhamentoOrganizacional Ger. de Processos Melhoria Infra-estrutura Ger. Recursos Humanos
ISO 15504 - Utilização Possui processo de certificação formal  Ainda não está muito difundido no meio empresarial Permite implementações por níveis Permite melhoria de processos para garantia de qualidade Permite estabelecimento de controles Identifica pontos fortes da organização assim como oportunidades de melhoria Há processo de re-certificação Custo pode ser elevado dependendo da implementação Pode ser utilizado para verificar processos do fornecedor Não possui grande histórico de utilização com resultados Possui manuais para realização de Avaliações
Qualidade de Software X CMMI 88
Capability... Capacidade? Capacitação? “Capabilidade”? 89 Qualidade que uma pessoa ou coisa tem de possuir para um determinado fim; habilidade, aptidão. (Aurélio) ? Ato ou efeito de capacitar (-se). (Aurélio) CMMI- Tradução correta é modelo de capacidade e maturidade
CMMI Foi criado para resolver o problema de existirem múltiplos CMM´s Sua missão é combinar o SW-CMM (CapabilityMaturityModel for Software Cobre as seguintes áreas de conhecimento: Engenharia de Sistemas Engenharia de Software Desenvolvimento integrado de produtos e processos Contratação de fornecedores Permite implementação Contínua (áreas de processo organizadas por categorias) e implementação por níveis (áreas de processo organizadas por níveis) Indica apreciação de fatores da organização (negócio, cultura, legado em processos) para decisão de como fazer a implementação Possui Níveis de 0 a 5.
Considerações  Trabalhar com avaliação oferece capacidade para as empresas desenvolverem futuros projetos de uma forma mais adequada. CMMI pode ser utilizado independente da metodologia de processo (XP, estruturada, OO) – modelos robustos que trabalham independente da plataforma. 80% das avaliações ficam nas disciplinas de análise de sistemas e engenharia de software. O grande desafio no final é a produtividade  e os LUCROS.  91
Pense ... O CMMI é apenas para software? O CMMI não descreve processo algum, apenas define orientações  através de práticas específicas
Capability... 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) 93
Origem “Não há nada de novo no CMMI (i de integration)” 94
Origem O SEI estruturou o CMM para contratação de grandes projetos de software Hoje, porém, o CMM e o CMMI são utilizados por empresas/organizações de vários tamanhos 95
CMMI – dupla representação ContinuousRepresentation ,[object Object]
Agrupamento das Áreas de ProcessoporCategoria
Avaliaçãodacapacidade das Areas de ProcessoCMMI StagedRepresentation ,[object Object]
Agrupamento de Áreas de ProcessoporNível
AvaliaçãodaOrganizaçãocomo um todoEstágio – para estar no nível 1 basta desenvolver software 96
Comparando as Representações Staged ML5 Process Area Capability ML4 0    1   2    3    4    5 ML3 ML2 ML 1 PA PA PA . . .para um conjunto de áreas de processoestabelecidaspela organização. … paraumaúnicaárea de processoou um conjunto de áreas de processo. Fonte: http://www.sei.cmu.edu
B D A C O foco o foco está nos processos, pq a idéia é se tem um processo falho provavelmente terá comprometimento no produto. Procedimentos e métodos definindo o relacionamento entre as tarefas e a sua seqüência Processo Ferramentas e equipamentos que vão apoiar os processos Pessoas com habilidades, treinamento e motivação a idéia que se tenha um processo que tenha uma seqüência  98 Paulket al. (1995)
99 Premissa do Gerenciamento do Processo de Software A qualidade de um sistema de software é altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo
Processo em perspectiva 100 Este componente permanece na organização! Organização Tecnologia Pessoas Processos ,[object Object],[object Object]
Por que o foco está no processo? 102 Processo de software Requisitos Software
Por que o foco está no processo? 103 a a a x Requisitos Software
Por que o foco está no processo? 104 a a a a Software Requisitos O fato de ter um processo bem definido garante que terá um produto de qualidade? ,[object Object],[object Object]
Considerações 106 Quando tudo é importante.... Nada é importante! Por isso é necessário seguir um processo Deve ser definido Implementado Documentado Estar ‘vivo‘ estar continuamente sendo revisado A criatividade é um desafio na implementação de um modelo de qualidade O CMMI não define o como fazer e sim o que fazer Para migrar de um CMM aconselha-se utilizar o CMMI pode estágios pois a migração será mais direta.
CMMI O CMMI diz “o que” e não “COMO” Supri as limitações do CMM, permitindo a inclusão de novos modelos ao longo do tempo,sempre que surgirem necessidades específicas; Implementa melhorias a partir das experiências adquiridas com projetos já implementados; Assegura a integridade da norma ISO/IEC 15504 e permite a representaçãocontínua, com áreas independentes do nível de maturidade;
Níveis de maturidade Formados por um conjunto predefinidos de áreas de processo. Como realiza-se a medição Verifica-se se os objetivos específicos e genéricos estão sendo atendidos.
CMMI  - Continuous Área de Processo 2 Área de Processo 1 Área de Processo 3 Objetivos Específicos Objetivos Genéricos Práticas Específicas Níveis de Capacidade Práticas Genéricas
CMMI - Contínuo Uma organização pode escolher melhorar o desempenho de um único ponto problemático
CMMI - Contínuo Process  Area Capability 0    1   2    3    4    5 PA PA PA Áreas do Processo – Metas genéricas (Requeridos) » Práticas genéricas (esperados) O que uma organização fará para atender aos componentes requeridos. – Metas específicas (Requeridos) » Práticas específicas (esperados) Níveis de Capacidade
Exemplo de área de processo e Capacidade CAPACIDADE ,[object Object]
6 níveis de maturidade
 onde qualquer área do processo pode ter sua,[object Object]
Área de Processo - Engenharia Gerenciamento de requisitos Desenvolvimento de requisitos Solução técnica Integração de produto Verificação Validação
CMMI  - Staged Nível de Maturidade Área de Processo 2 Área de Processo 1 Área de Processo 3 Objetivos Específicos Objetivos Genéricos Características Comuns Implemen tação Verificação Habilidades Compromisso Práticas Específicas Práticas Genéricas
Níveis de Maturidade
Componentes CMMI - estágios Áreas de Processo (PA)  Metas específicas (SG)  Práticas específicas (SP)  Características comuns Compromissos(commitment to perform - CO) Habilidades (ability to perform - AB) Diretivas (directingimplementation – DI) Verificações (verifyingimplementation – VE)  Produtos de trabalho
CMMI - Utilização  Possui processo de avaliação formal Permite implementação contínua Permite implementações por níveis Permite melhoria de processos para garantia de qualidade Permite estabelecimento de controles Identifica pontos fortes da organização assim como oportunidades de melhoria Custo pode ser elevado dependendo da implementação Pode ser utilizado para verificar processos do fornecedor Utilizado em grandes e pequenas organizações
Método de avaliação SCAMPI - Standard CMMI Assessment Method for Process Improvement: Desenvolvido pelo Software EngineeringInstitute (SEI) Métodoquereúneas melhorespráticas Métodosamplamenteutilizadospelo SW-CMM e outrosmodelos de melhoria de processos Existemcerca de 180 avaliadores SCAMPI no mundo: Autorizadospelo SEI a realizaravaliações do CMMI.
CMM x Testes  PAs (Áreas de Processo)  relacionadasestritamente a testes: VAL – Validação VER – Verificação Outrasaçõesconcentradasem PAs queenvolvemmais de umaequipe (TreinamentoOrganizacionais, Desenvolvimento de Requisitos, etc.)
Áreas de processos relacionadas a teste de software (CMMI x TESTES) ,[object Object]
 Verificação (VER)
 Validação (VAL)nível 3
Áreas de Processo do modelo CMMI - Nível 3
123 CMMI TSP PSP Team Software Process &Personal Software Process
Resumo (principais conceitos) O que é o CMMI? Quais os principais componentes do CMMI? Para que serve o CMMI? Se você fosse responsável pela implementação de um programa de melhoria de processos com base no CMMI: Por qual modelo CMMI (disciplinas e representação) optaria? Por quê? 124
Questionamentos Qual deles escolher? Quando utilizar? Como utilizar?
Resumo Compreensão prévia dos processos da organização Identificação dos pontos fortes Identificação das oportunidades de melhoria Estudos dos modelos e Normas disponíveis. Identificação de quais se aplicam à organização Estimular a equipe para mudanças ISO SPICE CMM Melhores práticas Processo Padrão
Resumo Identificação do objetivo da organização Certificação/avaliação Controle Garantia de Qualidade Caracterização do estado corrente do processo e do estado que se deseja alcançar Definição de  um plano de ação Processo Padrão
Plano de Ação Determinar o contexto onde se aplicará a melhoria Definir "patrocinadores"   Montar a infra-estrutura necessária para a realização do processo de melhoria. Determinação de prioridades da melhoria Planejamento de ações para atingi-la. Criação, teste, refino e implementação e de soluções Análise e validação das soluções implementadas  Definição das ações futuras que devem ser propostas. Processo Padrão
Algumas “dicas” ,[object Object]
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;
CMM -  É o mais didático se o objetivo for apenas melhoria de processos;,[object Object]
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.,[object Object]
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...,[object Object]
Relação com outras Disciplinas Engenharia de Software – Metodologias de desenvolvimento de software. Engenharia de Requisitos - captura os requisitos do software, que representam uma das bases principais para a identificação dos testes que devem ser executados. 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. 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. 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. 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.
Qual o perfil de um Eng. de Testes? Conhecimentos de engenharia de software. Ciclo de vida Especificação Projeto Teste propriamente dito Gerência da qualidade. Conhecimentos básicos de programação Conhecimentos básicos de banco de dados operação e configuração. Conhecimentos médios de redes configuração, operação, administração, segurança.
Perfil pessoal Paciência / Perseverança / Organização Firmeza de opinião Espírito investigador Capacidade de trabalhar em equipe Diplomacia analisador, investigador procurar defeitos Criativo criar novos cenários de teste Organizado lidar com massas de dados seguir o plano de teste
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.
Testes de integração CMMIx SCRUM
Categorias de teste de software - Fonte: Bartié (2002).
Esquema de Teste Revisões Revisões Teste estrutural 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 Teste funcional
Introdução aos testes de software O que é testar? Encontramos na literatura algumas definições sobre que é a atividade de testar:  Segundo Myers - “Testar é analisar um programa com a intenção de descobrirerros e defeitos.”  Testar é exercitar ou simular a operação de um programa ou sistema.  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.  Testar é medir a qualidade e funcionalidade de um sistema.  “O teste de programas pode ser usado para mostrar a presença de defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra)
Qual o objetivo dos testes?    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 “Uma pessoa inteligente resolve um problema. Uma pessoa sábia evitá-o”. [Einsten]
Erro, Defeito e Falha Erro (error): é uma ação humana que produz um resultado incorreto. Defeito (fault): A manifestação de um erro no software  Também conhecido como Bug Se executado, o defeito pode causar uma falha Falha (Failure): diferença indesejável entre o observado e o esperado. (Defeito encontrado) Falha é um evento; defeito é um estado do software, causado por um erro.
Erro, Defeito e Falha
Confiabilidade do Software x Defeitos Pode existir um software livre de defeitos?  É possível existir softwares confiáveis mas que possuem defeitos? Confiabilidade do Software é a probabilidade que o software não causará uma falha no sistema por um tempo especificado, sob condições determinadas.
O que provoca erro no software? Especificação de requisitos incorreta, Mudança de requisitos,  Projeto inadequado,  Módulos mal especificados, Erros de codificação..
Confiabilidade do Software Nenhuma falha encontrada = confiança
O que é Testes de Software ? "É uma estratégia popular para o gerenciamento de risco".  (LEWIS, 2004, p. 19) O teste de software é usado para: verificar se requisitos funcionais e não-funcionais foram devidamente implementados.
“Teste é o processo de executar um programa com o intuito de encontrar erros”   Glenford J. Myers (1979)
Fluxo da gestão de defeitos Adaptado de Rex Black
Porque defeitos ocorrem no software? Softwares são escritos por humanos  As pessoas não conhecem e não dominam tudo;  As pessoas tem habilidades, mas não são perfeitas;  As pessoas cometem erros; Softwares são desenvolvidos sob crescente pressão para entregá-los em prazos rigorosos  Sem tempo para checar as atividades realizadas;  Sistemas podem estar incompletos. Se você já escreveu softwares....
Vale a pena investir em testes?  Reduz em 70% o índice de      re-trabalho de correção de falhas   Reduz em 50% do tempo de homologação de uma nova versão  Aumenta em 90% o índice de falhas detectadas antes da entrega Aumenta a abrangência dos testes
Realidade atual do mercado de software Complexidade dos softwares  Complexidade das equipes  Cronograma apertado para Desenvolvimento  Mercado/Cliente/Usuários mais exigentes  Menos tolerância a falhas  Menos tolerância aos atrasos das entregas Precisamos construir softwares MELHORES e mais BARATOS, de forma mais RÁPIDA
O custo da não-qualidade  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. Não se sabe o percentual de re-trabalho e quanto isso custa  O software ou parte dele tem de ser refeito  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  A empresa não toma iniciativas para corrigir os problemas nas áreas de produção ineficientes
Por que testar um software? Todo o software visa atender a uma demanda:  Por questão de Qualidade  Por questão de Economia  Por questão de Segurança  Por questão de Confiabilidade  Por questão de Negócio
O custo da correção dos defeitos 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. 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.
Porque testar é necessário?  Porque é provável que o software possua defeitos;  Para descobrir a confiabilidade do software;  Porque falhas podem custar muito caro;  Demonstrar as conformidades com os requisitos;  Para assegurar que as necessidades dos usuários estejam sendo atendidas;  Para reduzir custos;  Para avaliar a qualidade do software;
Não devemos testar:  Para provar que o software não tem defeitos;  Apenas porque os testes estão incluídos no plano de projeto;
A abordagem tradicional dos testes Mostrar que o sistema:  Faz o que deve fazer  Não faz o que não deve fazer META: Mostrar que o sistema funciona CRITÉRIO DE SUCESSO: Sistema em funcionamento correto RESULTADO: Sistema com defeitos
A melhor abordagem para o testes Mostrar que o sistema:  Faz o que não deve fazer  Não faz o que deve fazer META: Encontrar defeitos META: Encontrar defeitos RESULTADO: Sistema com menos defeitos
O paradoxo do teste A proposta do teste é encontrar defeitos Encontrado defeitos a confiança é “destruída” Proposta do teste: “destruir” a confiança do software Proposta do teste: Estabelecer a confiança A melhor maneira de estabelecer a confiança é tentar destruí-la.
Por que as empresas não testam? Software é complexo  Software é intangível  Software é altamente modificável  Teste lida com pessoas  Há desconhecimento sobre a relação custo x benefício  Há falta de profissionais especializados  Há dificuldade em implantar um processo de teste  Há desconhecimento das técnicas adequadas de teste  Há desconhecimento de como planejar as atividades  Só se preocupam com testes no final do projeto
Conceitos iniciais Para que consigamos entender os conteúdos seguintes, é importante termos um perfeito entendimento dos conceitos abaixo: Erro: engano, alguma coisa feita por humanos. Defeito: o resultado de um erro. Falha: diferença indesejável entre o observado e o esperado. Depurar: descobrir e corrigir erros ou defeitos no código. Testar: descobrir falhas através da execução do sistema. Requisitos: regras de negócio do sistema. Testware: todo o conjunto de documentação gerado pelo processo de teste de software.
TMM TestMaturityModel
TMM - TestMaturityModel Modelo de maturidade focado em testes com 5 níveis de maturidade Desenvolvido em 1996 por IleneBurnstein no IIT (IllinoisInstituteofTechnology)
TMM - TestMaturityModel ,[object Object]
 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,[object Object]
Os sw são avaliados a partir de critérios de qualidade por características, como reusabilidade, usabilidade e mantenabilidade.
Os testes são completamente integrados ao ciclo de vida do software.
Reconhecido em todos os níveis do modelo V.Estratégias baseadas nos riscos ,[object Object],Definição clara de um processo de teste. Os testes são caóticos, não existe processo definido - OBJETIVO mostrar que funciona
TMM – Nível 1 Nãoháobjetivos de maturidade Teste é um processocaótico e desorganizado Testesãorealizados de maneiraapósfinalização do código.
TMM – Nível 2 Objetivos de teste e de depuraçãosãoestabelecidos Planejamento dos testes Institucionalização de métodos e técnicasbásicas de teste
TMM – Nível 2 Realização de objetivos de teste e de depuração: Uma equipe de testes deve ser formado, responsável pela definição das metas de teste A equipe desenvolve e registra os objetivos dos testes A equipe de testes é responsável pela definição das metas de testes Os planos de testes devem refletir as metas de testes
TMM – Nível 2 Planejamento dos testes Estabelecimento do plano de testes organizacional Criação e distribuição de um template para planejamento de testes  Documentação dos requisitos dos clientes que servirão como entrada no doc. de planejamento de testes  Ferramentas para apoio a planejamento de testes devem ser avaliadas, recomendadas e utilizadas
TMM – Nível 2 Institucionalização de métodos e técnicasbásicas de teste As técnicas devem ser avaliadas e recomendadas As políticas institucionais garantem que as técnicas recomendadas são constantemente aplicadas por toda a organização.
TMM – Nível 3 Criação de umafábrica de testes (Ambiente) Treinamentostécnicos Integração do processo de testes aociclo de desenvolvimento do software Início de um processo de gerenciamento de riscos Controle e monitoramento do processo de testes
TMM – Nível 3 Estabelecimento de umafábrica de testes O grupo de testes é estabelecido, com liderança própria e suporte da gerência do projeto Os papéis e responsabilidades são definidos  para o grupo Seleciona-se engenheiros melhor capacitados, treinados e  motivados Definição das formas de comunicação com os usuários para atendimento as necessidades do usuário e requisitos
TMM – Nível 3 Programa de treinamentostécnicos Organização e criação de um programa de treinamentos Estabelecimento de objetivos e planos de treinamento  Treinamento interno do grupo deve acontecer, as ferramentas e os materiais devem ser disponibilizados
TMM – Nível 3 Integração do processo de testes aociclo de desenvolvimento do software A fase de testes deve ser particionada em sub-fases que se conectam Uma adapção do modelo em V deve ser desenvolvida e adotada Padrões devem ser desenvolvidos para os artefatos gerados pela equipe de testes Integração entre as equipes de desenvolvimento e de testes
TMM – Nível 3 Processo de gerenciamento de riscos Políticas e estratégias para controle das atividades da equipe de testes Medições ligadas ao processo devem ser iniciadas Planos de ação que partem das medições  são aplicadas na melhoria do processo de testes
TMM – Nível 4 Programasorganizacionais de revisões Programa de medições Avaliaçãodaqualidade do Software
TMM – Nível 4 Programasorganizacionais de revisões Programas de revisão devem ser implantados de maneira organizacional A equipe de testes deve participar, junto com a equipe de qualidade da definição de verificações para revisões A equipe de qualidade deve definir metas para as revisões Equipes devem ser treinadas sobre o processo de revisão
TMM – Nível 4 Criação de um programa de medições Políticas organizacionais de medição e análise Definição de plano de medição Planos de ação provenientes da análise dessas métricas devem ser utilizadas para a melhoria continua do processo de testes
TMM – Nível 4 Avaliaçãodaqualidade do Software  As metas de qualidade devem ser definidas  atributos de qualidade, equipes de teste de qualidade e a gerência (ISO 9126) O processo de testes deve ser moldado de forma a conseguir atingir as metas determinadas no plano de qualidade
TMM – Nível 5 Aplicação de um processo de prevenção de defeitos Controle de Qualidade Otimização do Processo de Testes
TMM – Nível 5 Aplicação de um processo de prevenção de defeitos Formação de uma equipe de prevenção de defeitos Os defeitos são identificados e reportados durante todas as fases do ciclo de desenvolvimento Mecanismo para análise de causas dos defeitos O planos de ação  envolvem as equipes de desenvolvimento testes e gerência para evitar a repetição dos defeitos
TMM – Nível 5 Controle de Qualidade A equipe de testes e equipe de qualidade  Estabelecem as metas como quantidade de defeitos em cada fase do desenvolvimento Tais metas devem ser incorporadas no plano de testes O feedback do usuário deve ser colhido para melhoria do software
TMM – Nível 5 Otimização do Processo de Testes Ocorre a identificação de práticas que podem ser melhoradas Implementar e acompanhar as melhorias Avaliação constante das ferramentas de apoio Estudo e suporte as mudanças de tecnologias
Classificação dos Testes Os tipos e técnicas de testes podem ser classificados em: Caixa branca: técnica de teste que avalia o comportamento interno do componente de software. Trabalha diretamente sobre o código-fonte.
Caixa Branca - estrutural Comportamento interno do sw Código fonte: teste de condição,  teste de fluxo de dados, teste de ciclos  teste de caminhos lógicos Exemplo uso da ferramenta JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos em Java Esta técnica deve ser aplicada pelos desenvolvedores que conhecem bem o código produzido, testes de unidades e integração.
Caixa Preta Caixa preta: são conduzidos na interface do software, sem preocupação com a estrutura lógica interna do software.
Caixa preta – teste funcional O que pode ser testado ?  Um método, função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade.  é aplicável a todas as fases de teste teste de unidade (ou teste unitário),  teste de integração,  teste de sistema e aceitação. Gera um conjunto de casos de teste (entradas, saídas e critérios de teste).
Mitos sobre testes Alguns mitos sobre a atividade de testes:  O testador é inimigo do desenvolvedor  A equipe pode ser formada pelos desenvolvedores menos qualificados  Quando estiver tudo pronto, o sistema vai para teste.
Visão geral de processos 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.
Visão geral de processos
Processo de teste Cenário atual:  Testes são realizados como uma etapa do processo de desenvolvimento  Pressões sobre prazos fazem com que o esforço de testes seja reduzido ou até mesmo eliminado  O objetivo é assegurar que as especificações foram construídas  Testes são realizados pelos desenvolvedores ou analistas de sistema  Testes são realizados ao final do desenvolvimento  Não há garantias de que o software foi testado adequadamente
Cenário desejável:  O teste é tratado como um processo independente, porém altamente integrado ao processo de desenvolvimento  Os testes são iniciados paralelamente ao processo de desenvolvimento  Testes realizados por equipes altamente qualificadas e especializadas
Pontos de verificação Tendo em mãos as planilhas de testes o testador em busca dos erros... Albuquerque, et. All.
Objetivo do processo de teste Permitir o teste de softwares usando pessoal técnico qualificado, ferramentas adequadas e base em metodologia aderente ao processo de desenvolvimento da organização
Verificação e Validação O processo de teste é dividido em duas grandes áreas: Verificação Responde se o sistema foi construído Validação Responde se construímos o sistema correto
Modelo V 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. O modelo V focaliza-se em testar durante todo o ciclo de desenvolvimento para conseguir uma detecção adiantada dos erros.
Modelo V Modelagem de Negócios Testes de Aceitação Verificação Análise de Requisitos Testes de Sistema Validação Arquitetura do Sistema Testes de Integração Testes Unitários Design Construção
Fluxo básico de atividades
Principais envolvidos no processo de teste
Princípios gerais do teste de software Alguns princípios foram sugeridos ao longo dos últimos 40 anos: Teste demonstra a presença de defeitos Teste exaustivo é impossível Teste antecipado (iniciar o quanto antes) Agrupamento de defeitos  Teste depende do contexto  A ilusão da ausência de erros (deve atender as necessidades dos usuários) Fonte: Certificação em Teste FoundationLevelSyllabus – Versão 2007br
Principais organizações e institutos envolvidos 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. ALATS – Associação Latino Americana de Teste de Software  CBTS – Certificação Brasileira de Teste de Software QAI – QualityAssuranceInstitute  CSTE – CertifiedSoftwareTester BSTQB – Brazilian Software Testing Qualifications Board  CTFL – Certified Tester Foundation Level ISEB – Foundation Certificate in Software Testing  Certificação em teste de software  Norma IEEE 829  Define normas e padrões ao processo de teste e qualidade do produto. ISO 9126-1 Define as características da qualidade do software
A Norma IEEE 829
Exercícios de revisão Indique se é verdadeiro ou falso: a - ( ) O testes devem ser realizados para mostrar a ausência de defeitos. 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. c - ( ) O processo de teste deve ser independente do processo de desenvolvimento, porém integrado. d - ( ) Testes de software é uma das atividades de Verificação e Validação.  e - ( ) A equipe de testes pode ser formada por desenvolvedores menos qualificados. 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.
Considerações Teste é um projeto - e como tal deve ser planejado  Teste é um projeto integrado ao projeto de desenvolvimento  Testar reduz riscos do negócio  Não dá para planejar sem saber o tamanho do seu projeto  O Plano de Teste é o instrumento básico de planejamento de projeto de teste  Os artefatos devem estar sob gerência da configuração  Deve ser possível, a partir dos requisitos do negócio, rastrear-se os artefatos de teste
Limitação   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.
Estratégia, estágios, tipos e técnicas de teste
O que é estratégia de teste?  	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.
O que deve conter uma estratégia de teste? A estratégia de teste deve responder as perguntas que seguem:  Quando vamos testar?  O que vamos testar?  Como vamos testar?
Estratégia de teste - Pressman
Estratégia de teste Eng. De sistemas – define o papel sosw, análise dos requisitos, função, comportamento, restrições e critério de validação. Para desenvolvimento de software o espiral dá voltas para dentro. Para os testes as voltas são para fora.
Desenvolvimento da estratégia de teste 	Ao elaborar uma estratégia de teste eficiente e eficaz, devemos ter em mente a execução de alguns passos:  Avaliar os requisitos do sistema.  Identificar e analisar os riscos para o negócio.  Analisar as possibilidades de testes para minimizar os riscos.  Estabelecer os tipos e técnicas de teste a serem realizadas.  Definir prioridades para os testes.  Estabelecer quais produtos serão inspecionados ou testados.
Dimensões de testes Tipos de Teste (O que testar?) Estrutural Funcional Técnica de Teste (Como testar?) Estágios ou Níveis de Teste (Quando testar?)
Estágio ou níveis de teste 	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: 1: Estágios ou níveis de teste  Testes Unitários  Testes de Iteração ou Integração  Testes de Sistema  Teste de Aceitação
Testes Unitários 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. Características deste nível:  Testes realizados em uma unidade independente do produto.  Estágio mais baixo da escala de teste.  Aplicado nos menores componentes de código criados, visando garantir que estes. atendem as especificações funcionais e de arquitetura.  Geralmente realizado pelo desenvolvedor que construiu a unidade.  Utiliza técnicas de Caixa Branca.
Testes de Iteração ou Integração 	Como os componentes são construídos e testados separadamente, ao serem acoplados deve-se verificar se eles interagem corretamente. 	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. Características deste nível:  Acontece após os Testes Unitários.  Realizados dentro de um ambiente controlado.  Geralmente realizado pelo analista de sistema para um módulo ou conjunto de programas.  Normalmente são seguidos dois métodos de interação:  Abordagem Top-Down  Abordagem Bottom-Up
Testes de Iteração ou Integração - Abordagem 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.  Funciona bem com desenvolvimento estruturado.  Identifica problemas no desenho da arquitetura mais cedo.  Pode necessitar muita infra-estrutura.
Testes de Iteração ou Integração - Abordagem Abordagem Bottom-Up Apropriado para desenvolvimento orientado a objetos.  Os componentes de intra-estrutura são críticos.  Só consegue identificar os maiores problemas de arquitetura tardiamente.
Testes de Sistema    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. Características deste nível: Acontece após todos os testes de integração  Realizado dentro de um ambiente controlado  Realizado pela equipe de testes  Envolve testes especializados para validar todos os requisitos funcionais e não-funcionais:  Desempenho  Volume  Documentação  Robustez
Tipos de Testes de Sistema 	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. Entre outros, são realizados os seguintes testes:  Teste de Funcionalidade  Teste de Segurança  Teste de Estresse  Teste de Desempenho
Teste de Aceitação 	Ú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. Algumas características: É de responsabilidade do Cliente. 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. Geralmente realizado em ambiente de homologação do Cliente.  Testes de aceitação são realizados pelo usuário final para capacitá-lo e para validar todos os requisitos.
Dimensão 2: Tipos de Teste 	Todo software visa atender uma demanda de qualidade, e para isso deve atender a certos atributos de qualidade como:  Funções  Interface  Características de tempo de resposta e de segurança  Integridade  Habilidade de ser instalado e executado em diferentes plataformas  Habilidade de lidar com muitas requisições simultâneas, Etc. 	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.
Características da qualidade
Características da qualidade A ISO 9126-1 define seis características de qualidade que o software deve atender: Funcionalidade: verifica a capacidade do sistema em prover funcionalidades definidas que atendam as necessidades do usuário, quando usado sob determinadas condições preestabelecidas. Confiabilidade: o produto de software é capaz de manter seu nível de desempenho, ao longo do tempo, nas condições estabelecidas de utilização. Usabilidade: capacidade do software em ser entendido, aprendido e utilizado sob condições estabelecidas de utilização. Eficiência: os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido pelo software. Manutenibilidade: refere-se ao esforço necessário para a realização de alterações específicas no produto de software. Portabilidade: facilidade de o software poder ser transferido de um ambiente para outro.

Mais conteúdo relacionado

Mais procurados

Aulas - Gestão Da Qualidade - 2006 - Prof. Sergio.Jr
Aulas - Gestão Da Qualidade - 2006 -  Prof. Sergio.JrAulas - Gestão Da Qualidade - 2006 -  Prof. Sergio.Jr
Aulas - Gestão Da Qualidade - 2006 - Prof. Sergio.Jr
Sergio Luis Seloti Jr
 
Aula Lean
Aula LeanAula Lean
Philip Bayard Crosby
Philip Bayard CrosbyPhilip Bayard Crosby
Philip Bayard Crosby
Jose Donizetti Moraes
 
BPM Conceito e Caso prático
BPM Conceito e Caso práticoBPM Conceito e Caso prático
BPM Conceito e Caso prático
Sergio Calura
 
Six Sigma Metodologia DMAIC
Six Sigma Metodologia DMAICSix Sigma Metodologia DMAIC
Six Sigma Metodologia DMAIC
CLT Valuebased Services
 
Material CMMI
Material CMMIMaterial CMMI
Material CMMI
Fernando Palma
 
Gestão da Qualidade & Produtividade
Gestão da Qualidade & ProdutividadeGestão da Qualidade & Produtividade
Gestão da Qualidade & Produtividade
Marcos Magnanti
 
Noções de Administração: Qualidade Total (aula 2)
Noções de Administração: Qualidade Total (aula 2)Noções de Administração: Qualidade Total (aula 2)
Noções de Administração: Qualidade Total (aula 2)
Gustavo Zimmermann
 
Gestao Estrategica da Qualidade
Gestao Estrategica da QualidadeGestao Estrategica da Qualidade
Gestao Estrategica da Qualidade
Jairo Siqueira
 
Projeto green belt andre carvalho versão final
Projeto green belt andre carvalho   versão finalProjeto green belt andre carvalho   versão final
Projeto green belt andre carvalho versão final
Andre Celestino de Carvalho
 
Melhoramento da produção [modo de compatibilidade]
Melhoramento da produção [modo de compatibilidade]Melhoramento da produção [modo de compatibilidade]
Melhoramento da produção [modo de compatibilidade]
Daniel Moura
 
Passo a passo_gerente_projeto
Passo a passo_gerente_projetoPasso a passo_gerente_projeto
Passo a passo_gerente_projeto
gtiprotec
 
Desburocratização
DesburocratizaçãoDesburocratização
Desburocratização
Jairo Siqueira
 
DMAIC - Ferramentas para projetos Six Sigma - Lean
DMAIC - Ferramentas para projetos Six Sigma - LeanDMAIC - Ferramentas para projetos Six Sigma - Lean
DMAIC - Ferramentas para projetos Six Sigma - Lean
Aragon Vieira
 
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
EloGroup
 
Seminário Aese - Definição das ferramentas do LSS
Seminário Aese - Definição das ferramentas do LSSSeminário Aese - Definição das ferramentas do LSS
Seminário Aese - Definição das ferramentas do LSS
PedrodosSantos
 
Aulas Gestão da Qualidade & Produtividade 2015
Aulas Gestão da Qualidade & Produtividade 2015 Aulas Gestão da Qualidade & Produtividade 2015
Aulas Gestão da Qualidade & Produtividade 2015
Marcos Magnanti
 
Gurus da qualidade
Gurus da qualidadeGurus da qualidade
Gurus da qualidade
Alaxiel
 
Gestão da qualidade
Gestão da qualidadeGestão da qualidade
Gestão da qualidade
Adriano Pereira
 
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (... CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (...
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
Paula Gomes
 

Mais procurados (20)

Aulas - Gestão Da Qualidade - 2006 - Prof. Sergio.Jr
Aulas - Gestão Da Qualidade - 2006 -  Prof. Sergio.JrAulas - Gestão Da Qualidade - 2006 -  Prof. Sergio.Jr
Aulas - Gestão Da Qualidade - 2006 - Prof. Sergio.Jr
 
Aula Lean
Aula LeanAula Lean
Aula Lean
 
Philip Bayard Crosby
Philip Bayard CrosbyPhilip Bayard Crosby
Philip Bayard Crosby
 
BPM Conceito e Caso prático
BPM Conceito e Caso práticoBPM Conceito e Caso prático
BPM Conceito e Caso prático
 
Six Sigma Metodologia DMAIC
Six Sigma Metodologia DMAICSix Sigma Metodologia DMAIC
Six Sigma Metodologia DMAIC
 
Material CMMI
Material CMMIMaterial CMMI
Material CMMI
 
Gestão da Qualidade & Produtividade
Gestão da Qualidade & ProdutividadeGestão da Qualidade & Produtividade
Gestão da Qualidade & Produtividade
 
Noções de Administração: Qualidade Total (aula 2)
Noções de Administração: Qualidade Total (aula 2)Noções de Administração: Qualidade Total (aula 2)
Noções de Administração: Qualidade Total (aula 2)
 
Gestao Estrategica da Qualidade
Gestao Estrategica da QualidadeGestao Estrategica da Qualidade
Gestao Estrategica da Qualidade
 
Projeto green belt andre carvalho versão final
Projeto green belt andre carvalho   versão finalProjeto green belt andre carvalho   versão final
Projeto green belt andre carvalho versão final
 
Melhoramento da produção [modo de compatibilidade]
Melhoramento da produção [modo de compatibilidade]Melhoramento da produção [modo de compatibilidade]
Melhoramento da produção [modo de compatibilidade]
 
Passo a passo_gerente_projeto
Passo a passo_gerente_projetoPasso a passo_gerente_projeto
Passo a passo_gerente_projeto
 
Desburocratização
DesburocratizaçãoDesburocratização
Desburocratização
 
DMAIC - Ferramentas para projetos Six Sigma - Lean
DMAIC - Ferramentas para projetos Six Sigma - LeanDMAIC - Ferramentas para projetos Six Sigma - Lean
DMAIC - Ferramentas para projetos Six Sigma - Lean
 
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
[BPM Day Porto Alegre] Maurício Bitencourt - Como o iBPM e as tecnologias mai...
 
Seminário Aese - Definição das ferramentas do LSS
Seminário Aese - Definição das ferramentas do LSSSeminário Aese - Definição das ferramentas do LSS
Seminário Aese - Definição das ferramentas do LSS
 
Aulas Gestão da Qualidade & Produtividade 2015
Aulas Gestão da Qualidade & Produtividade 2015 Aulas Gestão da Qualidade & Produtividade 2015
Aulas Gestão da Qualidade & Produtividade 2015
 
Gurus da qualidade
Gurus da qualidadeGurus da qualidade
Gurus da qualidade
 
Gestão da qualidade
Gestão da qualidadeGestão da qualidade
Gestão da qualidade
 
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (... CMMI: Para além do desenvolvimento de Software  - Carlos Sánchez Fernández (...
CMMI: Para além do desenvolvimento de Software - Carlos Sánchez Fernández (...
 

Semelhante a APSI2

Governança e Gestão - 2ª Aula
Governança e Gestão - 2ª AulaGovernança e Gestão - 2ª Aula
Governança e Gestão - 2ª Aula
Alessandro Almeida
 
Conhecendo o CMMI
Conhecendo o CMMIConhecendo o CMMI
Conhecendo o CMMI
Alessandro Almeida
 
Pensando processos(1)
Pensando processos(1)Pensando processos(1)
Pensando processos(1)
Ze Roberto Seners
 
[slides] CMMI (2011: 1º semestre)
[slides] CMMI (2011: 1º semestre)[slides] CMMI (2011: 1º semestre)
[slides] CMMI (2011: 1º semestre)
Alessandro Almeida
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Norton Guimarães
 
Melhoria de Processos de Software
Melhoria de Processos de SoftwareMelhoria de Processos de Software
Melhoria de Processos de Software
Alessandro Almeida
 
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócioPalestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
CRA - MG
 
Apresentação GRS-CONSULTORIA
Apresentação GRS-CONSULTORIAApresentação GRS-CONSULTORIA
Apresentação GRS-CONSULTORIA
Renato Sona Gonçalves
 
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
Teamware do Brasil
 
Como justificar o seu projeto de BI
Como justificar o seu projeto de BIComo justificar o seu projeto de BI
Como justificar o seu projeto de BI
PunkMetrics
 
Palestra ERP Graduação v1.0
Palestra ERP Graduação v1.0Palestra ERP Graduação v1.0
Palestra ERP Graduação v1.0
GrupoMENTHOR
 
20100202 Diretor De Fabrica V.1.0
20100202 Diretor De Fabrica V.1.020100202 Diretor De Fabrica V.1.0
20100202 Diretor De Fabrica V.1.0
Sindico de Aluguel
 
Palestra ERP MBA Unisinos v1.0
Palestra ERP MBA Unisinos v1.0Palestra ERP MBA Unisinos v1.0
Palestra ERP MBA Unisinos v1.0
GrupoMENTHOR
 
Desafios de um projeto de BPM [Webinares iProcess 2015]
Desafios de um projeto de BPM [Webinares iProcess 2015]Desafios de um projeto de BPM [Webinares iProcess 2015]
Desafios de um projeto de BPM [Webinares iProcess 2015]
iProcess Soluções em BPM e RPA
 
Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0
Juan Bernabó
 
PMO - Escritório de Projetos | Workshop
PMO - Escritório de Projetos | WorkshopPMO - Escritório de Projetos | Workshop
PMO - Escritório de Projetos | Workshop
CompanyWeb
 
Desenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowskiDesenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowski
Erick Krulikowski
 
Project value - Maturidade em Gestão de Projectos
Project value - Maturidade em Gestão de ProjectosProject value - Maturidade em Gestão de Projectos
Project value - Maturidade em Gestão de Projectos
Alcides Cabral PMP
 
[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)
Alessandro Almeida
 

Semelhante a APSI2 (20)

Governança e Gestão - 2ª Aula
Governança e Gestão - 2ª AulaGovernança e Gestão - 2ª Aula
Governança e Gestão - 2ª Aula
 
Conhecendo o CMMI
Conhecendo o CMMIConhecendo o CMMI
Conhecendo o CMMI
 
Pensando processos(1)
Pensando processos(1)Pensando processos(1)
Pensando processos(1)
 
[slides] CMMI (2011: 1º semestre)
[slides] CMMI (2011: 1º semestre)[slides] CMMI (2011: 1º semestre)
[slides] CMMI (2011: 1º semestre)
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Melhoria de Processos de Software
Melhoria de Processos de SoftwareMelhoria de Processos de Software
Melhoria de Processos de Software
 
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócioPalestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
 
Apresentação GRS-CONSULTORIA
Apresentação GRS-CONSULTORIAApresentação GRS-CONSULTORIA
Apresentação GRS-CONSULTORIA
 
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
2 - Organizações e normas ISO - Prof.ª Cristiane Fidelix
 
Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
 
Como justificar o seu projeto de BI
Como justificar o seu projeto de BIComo justificar o seu projeto de BI
Como justificar o seu projeto de BI
 
Palestra ERP Graduação v1.0
Palestra ERP Graduação v1.0Palestra ERP Graduação v1.0
Palestra ERP Graduação v1.0
 
20100202 Diretor De Fabrica V.1.0
20100202 Diretor De Fabrica V.1.020100202 Diretor De Fabrica V.1.0
20100202 Diretor De Fabrica V.1.0
 
Palestra ERP MBA Unisinos v1.0
Palestra ERP MBA Unisinos v1.0Palestra ERP MBA Unisinos v1.0
Palestra ERP MBA Unisinos v1.0
 
Desafios de um projeto de BPM [Webinares iProcess 2015]
Desafios de um projeto de BPM [Webinares iProcess 2015]Desafios de um projeto de BPM [Webinares iProcess 2015]
Desafios de um projeto de BPM [Webinares iProcess 2015]
 
Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0Da Gestão 1.0 A Gestão 2.0
Da Gestão 1.0 A Gestão 2.0
 
PMO - Escritório de Projetos | Workshop
PMO - Escritório de Projetos | WorkshopPMO - Escritório de Projetos | Workshop
PMO - Escritório de Projetos | Workshop
 
Desenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowskiDesenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowski
 
Project value - Maturidade em Gestão de Projectos
Project value - Maturidade em Gestão de ProjectosProject value - Maturidade em Gestão de Projectos
Project value - Maturidade em Gestão de Projectos
 
[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)[slides] Gestão de Projetos (2015: 2º semestre)
[slides] Gestão de Projetos (2015: 2º semestre)
 

Último

DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdfDESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
Momento da Informática
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
joaovmp3
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 

Último (8)

DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdfDESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
DESENVOLVIMENTO DE SOFTWARE I_aula1-2.pdf
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 

APSI2

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