Ricardo Jos de Souza

Melhoria do Processo de Verificao & Validao para Atender aos Modelos de Qualidades Vigentes na Empresa CMMI, Norma ISO e PMBOK

Rio de Janeiro 2007

Melhoria do Processo de Verificao & Validao para Atender aos Modelos de Qualidades Vigentes na Empresa CMMI, Norma ISO e PMBOK.

Ricardo Jos de Souza

Universidade Federal do Rio de Janeiro MBA em Engenharia de Software (ENGSOFT)

Orientadora: Claudia Capelli

Rio de Janeiro 2006

FICHA CATALOGRFICA Souza, Ricardo Jos de. Melhoria do Processo de Verificao & Validao para Atender aos Modelos de Qualidades Vigentes na Empresa CMMI, Norma ISO e PMBOK / Ricardo Jos de Souza - Rio de Janeiro, 2006. V, 32 f.: il. Monografia (MBA em Engenharia de Software) Universidade Federal Do Rio de Janeiro UFRJ, Escola Politcnica, 2006. Orientadora: Claudia Capelli 1. Testes de Software. 2. Melhoria de Processos Monografia. I. Capelli, Claudia (Orient.). II. Universidade Federal do Rio de Janeiro. Escola Politcnica. III. Ttulo

RESUMO SOUZA, Ricardo Jos de. Melhoria do Processo de Verificao & Validao para Atender aos Modelos de Qualidades Vigentes na Empresa CMMI, Norma ISO e PMBOK. Orientadora: Claudia Capelli. Rio de Janeiro: UFRJ/Escola Politcnica, 2006. Monografia (MBA em Engenharia de Software).

A sociedade atual est muito dependente do software. Falhas podem gerar catstrofes. O desafio do Desenvolvimento de Software desenvolver software confivel de acordo com o cronograma e os recursos estipulados. Contudo, prticas bem conhecidas de teste no so empregadas pela maioria dos desenvolvedores de software. O problema agravou-se ainda mais com o surgimento da Tecnologia Web. Esta trouxe novos aspectos que permeiam os softwares da atualidade, gerando aumento da complexidade da soluo. Dentre os aspectos mencionados podemos citar fatores como: segurana, criptografia, tecnologias orientadas a componentes e SOA. A soluo dos problemas de software se torna de 100 a 1000 vezes mais custosa, se realizada aps a implantao. A verificao e o gerenciamento da qualidade durante o ciclo de vida do projeto so essenciais para atingir os objetivos corretos no momento certo. Nesta viso, o estudo proposto apresenta conceitos e abordagens de melhorias de processos e implantao das prticas de Verificao e Validao a fim de atender primeiramente ao modelo CMMI e, na medida do possvel, atendendo tambm Norma ISO, com aplicao prtica e concluses.

Palavras-chaves: Teste de Software, Reviso de Software, Verificao, Validao, Melhorias de Processos, CMMI, ISO, PMBOK.

SUMRIO

1 Introduo................................................................................................... 01 1.1 - Apresentao do problema............................................................. 01 1.2 - Estrutura do Trabalho..................................................................... 01 1.2.1 - Objetivo do Trabalho.............................................. 01 1.2.2 - Escopo do Trabalho............................................... 02 1.2.3 - Organizao do Trabalho...................................... 02 2 Conceitos sobre Qualidade de Software................................................ 03 2.1 - Segundo o PMBOK....................................................................... 03 2.2 - Segundo a ISO, famlia 9000........................................................ 04 2.3 - Segundo o CMMI.......................................................................... 04 2.4 - Mapeamento entre os Modelos de Qualidade.............................. 08 3 Estratgia para Implantao da Melhoria do Processo de V&V.......... 10 3.1 - Objetivo da Melhoria..................................................................... 10 3.2 Motivao..................................................................................... 11 3.3 - Fatores Crticos de Sucesso......................................................... 11 3.4 - Anlise SWOT............................................................................... 11 3.4.1 - Pontos Fortes.................................................................. 11 3.4.2 - Pontos Fracos................................................................. 11 3.4.3 Oportunidades................................................................ 12 3.4.4 - Ameaas/ Riscos............................................................. 12 3.5 - Ganhos Rpidos............................................................................ 12 3.6 - Priorizao de Aes de Rpida Implementao......................... 13 3.7 - Aes Futuras............................................................................... 14 4 Definio do Novo Processo de V&V..................................................... 15 4.1 - Contextualizando: etapas de um Processo de Software............... 15 4.2 - Desenho do Processo.................................................................... 16 4.3 - Definio de Papis e Responsabilidades..................................... 19 4.4 - Atividades do Processo.................................................................. 21

4.4.1 - Planejar Verificao e Validao.................................... 21 4.4.2 - Definir ambiente.............................................................. 23 4.4.3 - Definir critrios e procedimentos..................................... 25 4.4.4 - Preparar Revises.......................................................... 25 4.4.5 - Realizar Verificao e Validao................................... 26 4.4.6 - Avaliar Resultados de Testes........................................ 27 5 Concluso e Benefcios Obtidos........................................................... 28 5.1 - Melhoria dos Testes e Revises.................................................. 28 5.2 - Validaes ao Longo do Ciclo do Desenvolvimento................... 29 6 Referncias............................................................................................. 31

Melhoria do Processo de Verificao & Validao para Atender aos Modelos de Qualidades Vigentes na Empresa CMMI, Norma ISO e PMBOK. 1 - Introduo 1.1 - Apresentao do problema O cliente vinha demonstrando sua crescente insatisfao quanto baixa qualidade dos servios e produtos entregues, chegando inclusive a enviar direo da empresa uma notificao oficial, ameaando o descumprimento do contrato. O relacionamento que nunca havia sido dos melhores era seguidamente arranhado e ramos seguidamente punidos com multas contratuais. Tal postura agressiva do cliente resultou num outro problema correlato: os gestores e usurios se recusavam a realizar o aceite final das solicitaes de servio etapa obrigatria no processo de gerenciamento de mudanas estabelecido. Desta forma, as solicitaes de servio apesar de estarem atendendo aos requisitos e terem sido entregues no podiam ser cobradas, acarretando inmeros prejuzos empresa. Precisvamos demonstrar para o cliente que trabalhamos seguindo os padres de qualidade vigentes no mercado e, para tal, deveramos melhorar nossa forma de trabalho, adequando nosso processo de Verificao e Validao, a fim de atender ao modelo CMMI e aos requisitos da Norma ISO 9001, mantendo alinhamento com a Metodologia de Gerenciamento de Projetos utilizada pela corporao compatvel com o PMBOK. 1.2 - Estrutura do Trabalho 1.2.1 - Objetivo do Trabalho O propsito deste trabalho fornecer subsdios para que os projetos possam planejar e implementar verificaes e validaes de produtos de trabalho.

Estabelecer todos os procedimentos de testes necessrios para disponibilizao dos aplicativos no ambiente de Produo, englobando todos os ambientes de execuo, visando testes completos e planejados, a segurana dos dados do cliente e a identificao dos impactos no ambiente. Implementar revises em produtos de trabalho reconhecido como uma das melhores prticas de gerenciamento de projeto. O objetivo das revises remover defeitos dos produtos mais cedo e eficientemente. Os resultados da reviso so armazenados e repassados para o autor ou responsvel pela correo dos defeitos descobertos durante a reviso. 1.2.2 - Escopo do Trabalho O escopo desse trabalho a definio das prticas de Verificao e Validao a fim de atender primeiramente o CMMI e, na medida do possvel, atendendo tambm Norma ISO. 1.2.3 - Organizao do Trabalho O trabalho est estruturado da forma a iniciar-se com uma conceituao inicial equalizando conceitos, nomenclaturas e prticas de mercado existentes e os vrios focos da Qualidade de software. Em seguida, relacionaremos o mapeamento entre os modelos citados no trabalho, a fim de encontrar pontos em comum, redundncias e potenciais incongruncias entre os modelos e definiremos uma estratgia para implantao da melhoria do processo de V&V, priorizando aes de rpida implementao (quick wins). De acordo com a estratgia estabelecida, redefiniremos o processo de V&V, definindo papis e responsabilidades e determinaremos as atividades que formaro o novo fluxo de trabalho. Por fim, avaliaremos as concluses encontradas e analisaremos os benefcios obtidos com esta mudana de processo.

2 - Conceitos sobre Qualidade de Software 2.1 - Segundo o PMBOK Controle da Qualidade representa Preveno sobre inspeo. O custo de preveno de erros em geral muito menor que o custo de corrigi-los, conforme revelado pela inspeo. O planejamento da qualidade envolve a identificao dos padres de qualidade relevantes para o projeto e a determinao de como satisfaz-los. Ele um dos principais processos durante a execuo do grupo de processos de planejamento (Seo 3.3) e o desenvolvimento do plano de gerenciamento do projeto (Seo 4.3) e deve ser realizado em paralelo com outros processos de planejamento do projeto. Por exemplo, as mudanas necessrias no produto para atender aos padres de qualidade identificados podem exigir ajustes nos custos ou no cronograma ou a qualidade desejada do produto pode exigir uma anlise de risco detalhada de um problema identificado. A realizao do controle da qualidade (CQ) envolve o monitoramento de resultados especficos do projeto a fim de determinar se eles esto de acordo com os padres relevantes de qualidade e a identificao de maneiras de eliminar as causas de resultados insatisfatrios. Ele deve ser realizado durante todo o projeto. Os padres de qualidade incluem metas de produtos e processos do projeto. Os resultados do projeto incluem entregas e resultados de gerenciamento de projetos, como desempenho de custos e de prazos. O CQ muitas vezes realizado por um departamento de controle da qualidade ou uma unidade organizacional com nome semelhante. O CQ pode incluir tomar aes para eliminar as causas de um desempenho insatisfatrio do projeto. A equipe de gerenciamento de projetos deve ter um conhecimento prtico de controle estatstico da qualidade, especialmente de amostragem e probabilidade, para ajudar a avaliar as sadas do CQ.

2.2 - Segundo a ISO, famlia 9000 Verificao: Comprovao, atravs de fornecimento de evidncia objetiva, de que os requisitos especificados foram atendidos. Verificao de Software: Processo de examinar atravs de medio, ensaio ou outro meio, se o resultado de uma atividade est em conformidade com os requisitos estabelecidos para a mesma. Validao: Confirmao, por exame e fornecimento de evidncia objetiva, de que os requisitos especficos para um determinado uso pretendido so atendidos. Validao de Software: Confirmao, aps verificao bem sucedida, de que os requisitos especificados para um determinado uso pretendido foram atendidos, ou seja, o software est em conformidade com as expectativas do usurio. 2.3 - Segundo o CMMI Verificao O propsito da Verificao garantir que os produtos de trabalho selecionados atendam aos requisitos especificados. A Verificao garante que os requisitos foram atendidos, enquanto que a Validao garante que o produto atenda seu uso pretendido. A Verificao garante que eu construa certo, enquanto a Validao garante que eu construa a coisa certa. Este processo pode ser detalhado em: Preparar para Verificao Selecionar Produtos de Trabalho para verificao Estabelecer o ambiente de verificao Estabelecer procedimentos e critrios de verificao Realizar Peer-reviews Preparar Peer-reviews Conduzir Peer-reviews

Analisar dados do Peer-review Verificar Produtos de Trabalho Selecionados Realizar Verificao Analisar os resultados da verificao e identificar aes corretivas Este processo responde s perguntas: estamos construindo corretamente o produto? e estamos atendendo aos requisitos?. As revises fazem parte desse contexto. A Verificao utiliza de configuraes e simuladores para realizar testes. Algumas vezes, as mesmas ferramentas podem ser utilizadas tanto para Verificao quanto para Validao - s utilizadas com propsitos diferentes, procurando aspectos distintos. O termo genrico Teste citado nesse processo. Alguns exemplos de tipos de teste so citados cobertura de caminhos, stress, reutilizao de casos de testes, etc. mas testes durante o ciclo de vida do software (o modelo V, que determina a seqncia Unidade-Integrao-Sistemas-Aceitao-Regresso) no so mencionados. Validao O propsito da validao demonstrar que um produto cumpre seu uso designado quando posto no seu ambiente-alvo. Esse Processo pode ser detalhado em: Preparar para Validao Selecionar Produtos de Trabalho para Validao Estabelecer o ambiente de Validao Estabelecer procedimentos e critrios de Validao Verificar Produtos de Trabalho Selecionados Realizar Validao Analisar os resultados da Validao A Validao compreende as mesmas estratgias utilizadas na Verificao, exceto que agora estaremos determinando o que necessrio para validar o produto, e no apenas verificar que os requisitos foram satisfeitos. A Validao envolve a criao do ambiente o mais parecido possvel ao ambiente no qual o produto ser

utilizado, a fim de realizar os testes finais do produto. Entretanto nem sempre uma atividade lgica e prtica. A Validao procura responder pergunta: estou construindo o produto certo?.

Resumindo, o conceito por detrs dos termos Validao e Verificao algo bastante simples: Validao significa averiguar se o que foi executado ou especificado atende ao que o cliente requisitou ou deseja (necessidades do cliente - demanda inicial). Verificao serve para comprovar se o que foi executado est de acordo com o que foi especificado, ou seja, se o produto, work product, componente, etc. esto de acordo com a especificao do produto. Note que ambas as atividades so complementares. Na validao, eu averiguo se o que estou fazendo est de acordo com o que o cliente quer - este o objetivo primrio. Em seguida, aps a especificao ser criada (que deve estar de acordo com as exigncias do usurio e, portanto, ser validada), eu crio o produto e tenho que verificar se ele atende s especificaes. Normalmente, o nvel de detalhe da

verificao maior, pois inclui uma srie de requisitos tcnicos que so alheios ao cliente, mas que so necessrios para que o sistema como um todo funcione. Citando o modelo, "na verificao voc garante que voc construiu corretamente" (de acordo com as instrues), enquanto que "na validao, voc garante que construiu a coisa correta" (o que o cliente esperava). Exemplo: vamos supor que o usurio deseje, entre tantos campos de um relatrio, saber o nmero de dias teis entre a data da compra e a data de entrega do produto. Na hora de capturar os requisitos, anotou-se que ele queria o nmero de dias e a especificao foi criada. O programador, de posse da especificao criou um relatrio no qual era exibida a data da compra, a data de entrega e a diferena entre elas. Ele testou inmeras vezes e os resultados de seus testes foram sempre corretos ele verificou que o que ele programou est de acordo com o que foi especificado. Porm, foi isso que o cliente pediu? Esse relatrio ir satisfaz-lo? Fazendo uma analogia ao QFD (Quality Function Deployment - ferramenta bastante usada no Six-Sigma), quando voc captura os requisitos do usurio, na maioria dos casos voc tem que traduzir essa informao para uma linguagem tcnica e transformar isso em especificaes. No entanto, isto um processo longo e passa por diversas pessoas, que podem ter entendimentos diferentes, desde a captura dos requisitos, criao do Caso de Uso, etc. A validao serve para voc manter sempre o foco no cliente. Em exemplo que podem existir mais de uma soluo que atende especificao, mas somente uma delas atende ao que o cliente quer. Para validar, no apenas testes de sistema e aceitao so cabveis. Reunies com o cliente tambm servem para isso e devem ser amplamente usadas, principalmente no incio do ciclo de vida do produto, onde as correes de rumo so mais fceis e mais baratas. Prottipos tambm devem ser usados para validar a soluo, pois endeream a seguinte pergunta: "olha, isto que eu vou construir, realmente isto que voc quer?"

Normalmente, os usurios finais participam das atividades de validao, enquanto que na verificao, no. 2.4 - Mapeamento entre os Modelos de Qualidade Utilizados A tabela a seguir foi utilizada para identificar as convergncias e potenciais divergncias entre as prticas exigidas pelos trs modelos. Tendo o modelo CMMI como referncia esquerda, as PAs de VER e VAL e suas respectivas prticas especficas fez-se o cruzamento com as prticas de Gerenciamento da Qualidade do PMBOK e com as prticas diretamente ligadas Verificao e Validao da Norma ISO: CMMI ISO9001* 7.2.2 7.3.1 7.3.5 7.3.6 7.4.3 7.5.2 8.2.4 1.1 X X X 1.2 X X 1.3 X X X 2.1 X X X 8.3 8.1 Quality Planning X 8.3 Perform Quality Control 5.4 Scope Verification 8.3.2.9 Inspection 8.3.3.9 Validated Deliverables 8.3.2.10 Defect Repair Review 8.3.3.1 Quality Control Measurements 8.3.3.4 Recommended Corrective Action 8.3.3.5 Recommended Preventive Actions 8.3.3.7 Recommended Defect VER SP 1.1 1.2 X X X X Repair 8.1 Quality Planning PMBOK

VAL

SP

2.2

1.3 2.1 2.2

X X X

X X X

X 8.3 Perform Quality Control 8.3.2.9 Inspection 8.3.2.10 Defect Repair Review 8.3.3.1 Quality Control Measurements 8.3.3.4 Recommended

2.3

Corrective Action 8.3.3.5 Recommended Preventive Actions 8.3.3.7 Recommended Defect Repair 8.3 Perform Quality Control 5.4 Scope Verification 8.3.2.9 Inspection 8.3.2.10 Defect Repair Review 8.3.3.1 Quality Control Measurements 8.3.3.4 Recommended

3.1

3.2

Corrective Action 8.3.3.5 Recommended Preventive Actions 8.3.3.7 Recommended Defect

Repair (*) Correlao entre CMMI e as clusulas da norma ISO9001, de acordo com Mutafelija Stromberg. Na figura abaixo, observamos a correspondncia entre as Prticas Genricas do CMMI com a Norma ISO9001

10

3 - Estratgia para Implantao da Melhoria do Processo de V&V 3.1 - Objetivo da Melhoria Alinhamento com modelos de Qualidade. Implementar prticas de controle da qualidade dos produtos de software. Aumentar a efetividade das atividades de revises tcnicas (peer-reviews) e testes. Conseguir detectar, na maior quantidade possvel e antecipadamente, erros, bugs e defeitos que possam estar induzidos no processo de desenvolvimento de software.

11

3.2 - Motivao 1) Alto ndice de defeitos detectados em produo, pelo usurio final, gerando crescente insatisfao do cliente devido baixa qualidade do produto entregue 2) Problemas para aceite final da soluo. Muitas vezes o que era entregue no correspondia s reais necessidades do cliente. 3.3 - Fatores Crticos de Sucesso 1) Apoio da Alta Gerncia 2) Conscientizao, por parte da equipe de projeto, da importncia das prticas 3) Concordncia e apoio por parte do Cliente 3.4 - Anlise SWOT 3.4.1 - Pontos Fortes 1) A empresa possui uma cultura de processos sedimentada. 2) Ferramentas para automao de testes disponveis na empresa. 3) Estrutura de Fbrica de Software garante a independncia das equipes de testes. 4) Motivao dos envolvidos. 3.4.2 - Pontos Fracos 1) Falta de perfil adequado, na equipe de desenvolvimento, para atividades de reviso e testes. 2) Carncia das competncias necessrias aos usurios para efetuarem validaes de enfoque mais tcnico. 3) Processo de Gerenciamento de Configurao de Software incipiente. 4) Recursos reduzidos ambientes e bases de dados so compartilhadas; vrias pessoas executam mltiplos papis.

12

3.4.3 - Oportunidades 1) Melhoria significativa na percepo da qualidade do produto, sob a tica do cliente. 2) Diminuio do retrabalho. 3) Aumento da produtividade no desenvolvimento de software. 4) Constante capacitao da equipe. 5) Diminuio dos custos do ciclo-de-vida do desenvolvimento. 3.4.4 - Ameaas/ Riscos 1) Piora no time-to-market do processo de desenvolvimento, aumentando o tempo de entrega do produto final, acarretando aumento da insatisfao do cliente com relao pontualidade das entregas. 2) No institucionalizao plena das prticas do processo, sendo necessria utilizao de atalhos na maioria das vezes. 3) Aumento da quantidade de atividades destinadas equipe de desenvolvimento, acarretando desinteresse e problemas de alocao de recursos. 3.5 - Ganhos Rpidos Conscientizao da Equipe srie de estudos dirigidos com o objetivo de melhorar o entendimento do problema, envolv-los no diagnstico das possveis causas e colher sugestes das aes corretivas. Conscientizao dos Usurios seqncia de workshops com a finalidade de promover, dentre usurios e gestores, entendimento sobre a importncia que seu envolvimento no desenvolvimento do produto acarreta na melhoria da qualidade do software.

13

Treinamento em Tcnicas de Reviso e Teste de Software adquirir treinamento formal nas tcnicas para melhoria na execuo de peerreviews e testes Melhoria no Processo de Verificao e Validao Reviso das atividades Envolvimento de validaes ao longo de todo o ciclo-de-vida do Desenvolvimento do Software Reviso do template de Especificao de Testes (Casos de Testes) e dos guias de Peer-Reviews 3.6 - Priorizao de Aes de Rpida Implementao
Categoria Sugesto Impacto

Incluso no Caso de Teste de um campo para classificao do mesmo, indicando qual objetivo que Melhorias em artefatos de projeto ser contemplado em sua execuo (conforme definio do processo de teste): demonstrar que o caso de uso no faz o que deveria ou que faz o que Melhorias em artefatos de projeto Melhorias em artefatos de projeto Maior efetividade nas aes de QA Maior efetividade nas aes de QA Melhoria nas tcnicas utilizadas Melhoria nas tcnicas utilizadas no deveria. Definio no Caso de Teste dos valores que devem ser includos na base de dados (massa de teste) Melhoria dos guias para Peer-Reviews Validao dos casos de teste Verificao se todos os casos de teste possuem os resultados esperados definidos Utilizao de tcnicas de caixa branca na realizao de testes de unidade Utilizao de inspeo de cdigo, substituindo o peer review de cdigo adotado atualmente Alterao template CT Alterao Guia Peer-Review Alterao em QA Alterao em QA Treinamento Alocao de recursos; treinamento 2 Alterao template CT 1

1 1 1 1 2

14

Melhoria nas tcnicas utilizadas Melhoria nas atividades do processo Melhoria nas atividades do processo Melhoria nas atividades do processo Mtricas

Usar walkthrough ao invs de peer review de requisitos e projeto Envolvimento dos usurios na homologao (testes de aceitao) de verso do produto Armazenamento dos dados (massa de teste) utilizados na execuo de um caso de teste Casos de teste devem ser desenvolvidos por recursos diferentes Determinao de uma produtividade especfica para os testes, a partir do tempo mdio necessrio para o teste de um ponto de funo Determinao de uma produtividade especfica para correo de erros Apurao da relao entre esforo planejado e realizado para os testes, esforo planejado para implementao e testes e esforo realizado para implementao e testes

Alocao de recursos; treinamento Alocao recurso Mudana de Procedimento Alocao recurso Criao de Novas Mtricas Criao de Novas Mtricas Criao de Novas Mtricas 2

2 3 3

Mtricas

Mtricas

3.7 - Aes Futuras 1) Melhoria no Controle de Configurao (hardware e software), visando otimizar a utilizao de recursos computacionais e o versionamento do produto. 2) Automatizao de Testes, com o objetivo de concentrar esforos em atividades que agreguem mais do que os exaustivos e repetitivos testes de regresso. 3) Envolvimento de testadores durante todo o ciclo do desenvolvimento, contribuindo com uma viso mais crtica nas decises de projeto e antecipando o projeto de casos de teste.

15

4) Envolvimento mais efetivo do usurio durante a fase de homologao. Esta atividade no tem sido realizada a contento, visto que o mesmo se esquiva de suas responsabilidades. 4 - Definio do Novo Processo de V&V 4.1 - Contextualizando: etapas de um Processo Tpico de Desenvolvimento / Manuteno de Software a) Definio do Escopo consiste no atendimento solicitao do cliente, priorizao e resoluo de conflitos. b) Elicitao de Requisitos entendimento dos requisitos que atendero s necessidades do cliente. O usurio tem papel importante nessa fase. c) Desenvolvimento de Requisitos detalhamento dos requisitos da soluo que atendero s necessidades do cliente. Desenvolvimento das especificaes. d) Anlise anlise dos requisitos e elaborao da modelagem conceitual e lgica da soluo. Complemento das especificaes e realizao dos Casos de Uso. e) Design elaborao da modelagem fsica da soluo. Complemento das especificaes. f) Codificao implementao da soluo especificada, tendo como base os artefatos produzidos nas etapas anteriores. O produto desta etapa o cdigofonte. g) Integrao montagem e preparao da soluo e de seus componentes no ambiente alvo. h) Disponibilizao instalao da soluo nos diversos ambientes do projeto.

16

4.2 - Desenho do Processo

17

Etapas do Processo

Descrio

Tcnica

Participantes

18

de Verificao Reviso de Requisitos

Verificar se o requisito de software foi desenvolvido conforme o especificado Certificar que o requisito de software foi realizado conforme o especificado Certificar que a arquitetura da soluo corresponde aos requisitos de anlise Conferir se a codificao est conforme as especificaes Aferir se o cdigo gerado atende s situaes previstas nas especificaes Examinar se as interfaces entre componentes foram

Recomendada Walkthrough

Analistas de Sistemas

Reviso de Anlise

Peer-Deskcheck

Analistas de Sistemas

Reviso de Design

Peer-Deskcheck

Arquiteto de Software

Reviso de Cdigo

Peer-Deskcheck

Arquiteto de Software Desenvolvedor

Testes Unitrios

Testes Estruturais

Desenvolvedor

Testes Integrados

Testes Estruturais Testes Funcionais

Integrador

19

implementadas conforme descritas e Testes de Sistemas especificadas Verificar que o sistema, como um todo, foi desenvolvido conforme as especificaes. Etapas do Processo de Validao Validao de Escopo Descrio Formalizar, junto ao cliente, todo o escopo da sua Validao de Requisitos necessidade. Validar se os requisitos para atendimento da necessidade do cliente esto inteligveis, nodbios e so implementveis. Validao da Soluo Tcnica Estas validaes podem ocorrer nas fases de anlise ou projeto e tem como Walkthrough Walkthrough Testes Funcionais Testes de carga, stress e capacidade. Testes de Usabilidade. Tcnica Recomendada Inspeo Formal Participantes Cliente Usurio Especialista de Negcio Cliente Usurio Especialista de Negcio Analista de Sistemas Arquiteto de Software Testador Analista de Sistemas Arquiteto de Software Especialista de Testador

20

objetivo certificar que soluo projetada atende Homologao Interna solicitao Validar se a soluo pronta atende s necessidades do Aceitao cliente. Aceite formal da soluo, aps realizao de inspees e testes. 4.3 - Definio de Papis e Responsabilidades a) Cliente/Usurio Testes de Aceitao Testes de Aceitao

Negcio

Homologador Especialista de Negcio

Cliente Usurio

Papel externo equipe do projeto. Solicita demandas por solues de software, que devem ser atendidas pela equipe de desenvolvimento. Estas demandas devem ser protocoladas por intermdio de solicitaes formais. Deve interagir com a equipe de projeto a fim de que suas necessidades sejam claramente entendidas e, ao final de todo o ciclo-de-vida do desenvolvimento de software, conferir o aceite final ao produto. b) Especialista de Negcio Papel interno equipe de projeto e externo equipe de desenvolvimento. Interface entre o usurio e a equipe de projeto. Formaliza as demandas, participa da priorizao das necessidades e participa da homologao interna do produto. c) Analista de Sistemas

21

Papel interno equipe de projeto e equipe de desenvolvimento. responsvel pelo desenvolvimento de requisitos e realizao destes. Anlise conceitual da soluo. d) Arquiteto de Software Papel interno equipe de projeto e equipe de desenvolvimento. responsvel pela arquitetura da soluo. Anlise fsica do produto. e) Desenvolvedor Papel interno equipe de projeto e equipe de desenvolvimento. Responsvel por implementar e codificar a soluo. Gerao de cdigo-fonte e testes unitrios. f) Integrador Papel interno equipe de projeto e equipe de desenvolvimento. Responsvel pela gerncia de configurao da equipe de desenvolvimento (artefatos tcnicos) e pela integrao e disponibilizao das verses da soluo. g) Testador Papel interno equipe de projeto e externo equipe de desenvolvimento. Realizam os testes de sistema, com nfase nos aspectos de funcionalidade, carga, stress e capacidade. h) Homologador Papel interno equipe de projeto e externo equipe de desenvolvimento. Realiza a primeira bateria dos testes de aceitao, ainda dentro dos limites da equipe de projeto. O foco desses testes validar se a soluo contempla as reais necessidades do usurio. 4.4 - Atividades do Processo 4.4.1 - Planejar Verificao e Validao

22

a) Selecionar estratgia de validao e verificao Devem ser definidas no planejamento do projeto as atividades de testes e os produtos que so objeto dos testes. Dentre as atividades, devem ser selecionadas as fases em que sero feitas validaes e verificaes, quais os responsveis, quais testes validaro o produto final. b) Definir os produtos a serem verificados e validados. O Plano de Teste do projeto define quais so os artefatos que sero verificados e validados. c) Definir abordagem dos testes No Plano de Testes deve ser definida a abordagem de testes identificando quais tcnicas sero usadas no projeto. Cada projeto deve definir as tcnicas mais apropriadas para utilizao, devendo, porm, executar as tcnicas bsicas de Teste Funcional.

23

O Modelo-V para Testes o framework adotado pela organizao.

Um exemplo de atribuio tpica de atividades e responsveis: Atividade Verificao Revises por pares Teste de Unidade Teste de Integrao Teste de Sistemas Validao Validao de Requisitos Validao da Soluo Teste de Aceitao Responsvel Equipe de Projeto Desenvolvedores Integrador Equipe de Testes Especialista de Negcio Arquiteto de Software Especialista de Negcio Equipe de Homologao

24

d) Definir critrios de validao dos testes Devem ser definidos os critrios de validao para a realizao dos testes. Os critrios podem ser, entre outros, padres definidos, critrios de aceitao ou desempenho do software. 4.4.2 - Definir ambiente Detalhamento dos requisitos mnimos de hardware, software e ferramentas de apoio para realizao das atividades previstas. A configurao mnima necessria de hardware e software dos ambientes depende das necessidades e requisitos do cliente e das caractersticas, requisitos e arquitetura da soluo. Todo o ambiente para Verificao e Validao deve ser homologado com o intuito de certificar que atenda sua atividade fim. Ambiente Ambiente de Desenvolvimento Descrio Workstation dos desenvolvedores. Devem ter o bsico para desenvolvimento do software. Ferramentas de automao de testes unitrios tambm so de grande serventia. Etapas do Processo de V&V Reviso de Requisitos Reviso de Anlise Reviso de Design Reviso de Cdigo Validao de Escopo Validao de Requisitos Validao da Soluo Tcnica Papis Envolvidos Analistas de Sistemas Arquitetos de Software Desenvolvedores

25

Ambiente de Testes

Este ambiente deve ser semelhante ao ambiente-alvo da soluo (ambiente de produo), inclusive se for necessrio grande volume de dados para realizao de testes especficos. Ferramentas de automao de testes de carga e de regresso tambm so de grande serventia. Deve ser o ambiente que reflita possvel com o ambiente-alvo da soluo (ambiente de produo) e dados para testes especficos. Ambiente-alvo da soluo. Deve ser homologado a fim de garantir que atenda s

Testes Unitrios Validao da Soluo Tcnica Testes Integrados Testes de Sistemas

Testadores

Ambiente de Homologao Interna

Homologao Interna

Homologadores Clientes/Usurios Especialistas de Negcio

a maior semelhana Aceitao

Ambiente de Produo

Aceitao

Clientes/Usurios

26

necessidades. Para as atividades que envolvam um nmero considervel de pessoas (walkthrough, inspees, validaes com clientes, etc.) o ambiente de projeto deve prover salas de reunies com os requisitos bsicos, de acordo com as necessidades: projetores, telas, flip-charts, quadros, mesas, pincis-atmicos, etc. 4.4.3 - Definir critrios e procedimentos So definidos critrios como: facilidade de leitura, modularidade, consistncia, funcionalidade, testabilidade, etc. Identificar padres de documentao e desenvolvimento de software. O Analista de Testes ou Analista de Sistemas deve elaborar os Casos de Testes, com base nos requisitos definidos. Os casos de testes devem satisfazer os critrios de qualidade do projeto. a) b) c) Identificar elementos para os testes Definir critrios de avaliao Elaborar Casos de Testes

4.4.4 - Preparar Revises Os checklists devem ser desenvolvidos e revistos pelos pares e potenciais usurios do documento. A utilizao de checklists auxilia na deteco e classificao de defeitos do produto. a) Planejar as revises.

27

As revises devem ser planejadas e programadas conforme definidas no Plano de Teste. Revises devem ser conduzidas a fim de atingir os marcos definidos no plano do projeto. b) Selecionar Tipo de Reviso Os critrios para seleo do tipo de reviso para cada artefato devem ser documentados no Plano de Teste. 4.4.5 - Realizar Verificao e Validao a) Definir as atividades para a Reviso selecionada Os procedimentos devem estabelecer os templates mnimos utilizados para planejar, preparar e executar cada um dos tipos de reviso. b) Realizar a Reviso Compreende: agendamento com os participantes, definio de papis, definio do material utilizado e execuo da reviso propriamente dita. Os procedimentos especficos de cada tipo de reviso esto descritos conforme o item 7.2a. A Equipe deve executar as atividades de acordo com o que fora definido no Plano de Testes. a) Implementar testes A equipe de testes poder utilizar uma ferramenta de apoio para o registro dos testes e das ocorrncias. b) Implementar sute de testes c) Executar sute de testes

28

4.4.6 - Avaliar Resultados de Testes Avaliar os resultados obtidos durante a execuo dos testes. Compar-los com os resultados previstos e tomar as aes pertinentes. Atividade realizada para avaliar o efetivo custo/benefcio da implantao do processo. Medies so feitas e utilizadas para determinar o status das atividades de uma reviso. Alguns exemplos: - Nmero de revises realizadas comparado com o planejado - Esforo total gasto em revises comparado com o planejado - Nmero de produtos revistos comparado com o planejado Dados que podem ser coletados e utilizados para mensurar a efetividade do Processo: - Quantidade e tipo de defeitos encontrados e solucionados - Resultados da anlise causal realizada - Horas gastas no esforo de retrabalho - Horas gastas no esforo de verificao e validao total - Sugestes para melhoria do processo

29

5 - Concluso e Benefcios Obtidos Algumas aes comprovadamente apresentaram maior efetividade no endereamento das causas-razes. Algumas aes no podem ser mensuradas diretamente ou apresentaram ganhos indiretos e at alguns efeitos colaterais indesejados ligeira diminuio da produtividade. Alguns ajustes esto sendo feitos nos procedimentos, a fim de diminuir a sobrecarga de trabalho que foi acrescida e otimizar o desempenho do processo. Destacaremos aqui as 2 aes que contriburam diretamente para o sucesso do projeto de melhoria: 5.1 Melhoria dos Testes e Revises Implantao de um processo estruturado de reviso e melhoria da qualidade dos testes. Diminuio do percentual de erros encontrados no ambiente de produo. O percentual de defeitos encontrados pelos usurios antes do projeto de melhoria se encontrava em torno de 80%. Aps as aes realizadas, o percentual de erros se estabilizou em um patamar prximos dos 30%, como podemos verificar no grfico:
80 70 60 50 40 30 20 10 0
s o n li s e P Im ro je pl to em en ta eq ui ro du es te s si to o

%Defeito (Antes) %Defeito (Depois)

30

O efeito diretamente perceptvel foi a melhoria da percepo do cliente, constatada nas avaliaes de satisfao quanto qualidade do produto. Vale lembrar que a quantidade total de defeitos das entregas praticamente no foi alterada. Porm, o que ocorreu foi a antecipao da deteco destes erros, que atualmente so encontrados nas fases anteriores do ciclo de vida do desenvolvimento. Uma nova iniciativa foi desencadeada, em decorrncia dos sintomas acima analisados - ao de melhoria diretamente no processo de desenvolvimento e manuteno de software. 5.2 - Validaes ao Longo do Ciclo do Desenvolvimento Percebemos um aumento no percentual de aceite final do cliente o que estamos realmente entregando corresponde exatamente s necessidades do cliente. Isso foi identificado na melhoria do percentual do indicador organizacional de Entregas Rejeitadas. Uma prxima etapa de melhoria inclui envolver o usurio diretamente nos testes de Aceitao e nas Validaes de Soluo Tcnica. Alm disso, algumas questes conceituais foram esclarecidas durante a fase de conscientizao tanto da equipe quanto dos usurios. Exemplo: Mas por que a equipe de desenvolvimento no valida nada? S verifica? A verificao s certifica que o produto foi construdo conforme o especificado, mas no garante que ele atenda necessidade do cliente. o conceito de verificao: certificar que estamos fazendo o que est especificado. Verificao comparar o produto com a especificao. Como tais especificaes geralmente se limitam apenas ao contexto da equipe, o usurio no tem acesso a esse nvel de artefatos tcnicos as verificaes passam a ser atividades internas da equipe de desenvolvimento. Mesmo nos testes integrados e de sistema - voc confronta o funcionamento do software contra as especificaes de testes (casos de testes).

31

A validao do ponto de vista do cliente: se estamos fazendo o que deve ser feito e o que o usurio precisa. As atividades de validao so realizadas por Equipe, em conjunto com os Usurios. Nos testes de validao, voc compara o software contra a necessidade do cliente o que foi solicitado. Pode ser at o mesmo teste, s que com enfoque diferente. Exemplo: teste de sistemas e de aceitao (homologao interna e externa) so praticamente a mesma coisa. S que os de sistemas so feitos comparando o sistema com a especificao. O de aceitao confronta o sistema contra a solicitao do cliente. Se o processo de validao estiver funcionando bem ao longo de todo o processo de desenvolvimento, os resultados dos 2 testes sero os mesmos. Isso evita surpresas desagradveis ao usurio, do tipo: "Legal! Funciona maravilhosamente bem, mas no foi isso que eu pedi!. O grande problema : voc coleta necessidades com o usurio l no incio de tudo. Mas no se valida se, por acaso, ao decorrer do processo, a soluo ainda corresponde necessidade. Na prtica, no necessrio o envolvimento do usurio o tempo todo. E o usurio nem sempre tem competncia tcnica para fazer validao de artefatos tcnicos. A entra o Especialista de Negcio, que valida sob a perspectiva do usurio. Pra disseminar essas boas prticas e implantao do processo, necessrio bastante treinamento de processos e nas tcnicas utilizadas, sob forma de workshops, coaching, mentoring e treinamentos formais, inclusive com fornecedores externos.

32

6 Referncias Livros - CHRISSIS, Mary Beth; KONRAD, Mike; SHRUM, Sandy. CMMI: guidelines for process integration and product improvement. New Jersey: Addison Wesley, 2002. - PROJECT MANAGEMENT INSTITUTE. Guia para o Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK). 3. ed. Pennsylvania. 2004. - KULPA , Margaret K.; JOHNSON, Kent A. Interpreting the CMMI: a process improvement approach. Florida: Auerbach, 2003. - PRESSMAN, Roger S. Engenharia de software. 5. ed. Rio de Janeiro: McGrawHill, 2002. - SCHULMEYER, Gordon G.; MCMANUS, James (Ed.). Handbook of software quality assurance. 3.ed. New York: Prentice Hall, 1998. - JARVIS, Alka / CRANDALL, Vern. Inroads to software quality: how to; guide and toolkit. New York: Prentice Hall, 1997. - STAA, Arndt Von; FIORINI, Soeli T; BAPTISTA, Renan Martins. Engenharia de software com CMM. Rio de Janeiro: Brasport, 1998. - JONES, Capers. Software quality: analysis and guidelines for success. London: Thomson Learning, 1997. - MINISTRIO DA CINCIA E TECNOLOGIA; Secretaria de Poltica de Informtica e Automao (Brasil). Qualidade no setor de software brasileiro, 1998. - PUTNAM, Lawrence H.; MYERS, Ware. Controlling software development: an executive briefing. California: IEEE Computer Society, 1996. - ALEXANDER, L. C.; DAVIS, A. M. Criteria for selecting software process models. In: Proceedings of the Fifteenth Annual International Computer Software & Applications Conference COMPSAC 9, 1991. Sites

33

- Test-Driven Development: http://testdriven.com. - HIGHTOWER, Richard; LESIECKI, Nicholas. Java tools for Extreme Programming. Disponvel em: <http://junit.org>. Acesso em: 13 maio 2006. - CONTINUOUS PERFORMANCE. Disponvel em: <http://www.javapronews.com/javapronews-47-20030721 ContinuousPerformanceTestingwithJUnitPerf.html>. Acesso em: 17 abr. 2006. - CONTINUOUS TESTING. Disponvel em: <http://pag.lcs.mit.edu/~saff/continuoustesting.html>. Acesso em: 17 abr. 2006. - ABNT www.abnt.org.br. - Softex www.tecsoft.softex.br. - SEI/CMM www.sei.cmu.edu. - QAInstitute http://qai.org. - ISO www.iso.ch. - IEEE www.ieee.org. - Software Produtivity Center www. spc.ca. - Technical Council on Software Engineering www.tcse.org. - Software Productivity Consortium www.software.org.