Fundamentos de BPM e sua Integração com a Gestão de Projetos
Análise Sistemas II e Empreendedorismo
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 ...
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
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
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)
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
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
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
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
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]
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
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).
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.
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
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
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
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.)
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
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.
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.
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.
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..
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)
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)
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.
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
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
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.
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?
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.
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.
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);
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
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
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
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
