ana paula barbosa michel - · pdf fileana paula barbosa michel análise de riscos em...
TRANSCRIPT
Curso de Bacharelado em Ciência da Computação
ANA PAULA BARBOSA MICHEL
ANÁLISE DE RISCOS EM PROCESSO DE TESTE DE SOFTWARE
CANOAS, 2009.
ANA PAULA BARBOSA MICHEL
ANÁLISE DE RISCOS EM PROCESSO DE TESTE DE SOFTWARE
Trabalho de conclusão apresentado para a banca examinadora do curso de Ciência da Computação do Centro Universitário La Salle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.
Orientação: Prof. MSc. Roberto Petry e Co-orientação de MSc. Elceni Gelain
CANOAS, 2009.
Dedico este trabalho a minha mãe Clecy,
meu irmão Flávio e meu namorado
Reginaldo que sempre me apoiaram e
incentivaram meus estudos.
AGRADECIMENTOS
Agradeço a minha família, minha mãe, Clecy B. Michel, meu irmão Flávio Z.
Michel Jr, meu amor Reginaldo Pereira e em especial agradecer à minha co-
orientadora, ex-chefe e minha amiga Ceni por toda dedicação, muitos, muitos finais
de semana de estudo e revisão do trabalho.
Aos meus amigos e meus colegas do lasalle Rodrigo Wolf, Tatiana
Brezezinski, Adriana G. Severo, Cristian Bonotto, Nelson Sonntag ( em memória).
Aos meus amigos Vera, Márcia, Clemilson, Mara, Luciano, Bárbara e Josion.
Ao meu orientador Roberto Petry.
Aos Professores do Unilasalle: Eurico, Lincoln, que por muitas vezes me
auxiliaram durante a graduação e em especial durante o andamento do trabalho de
conclusão.
Aos que participaram de alguma maneira no trabalho: Tiago, Paloma, Bruna,
Sandro, Tati, Fábio, Leandro, Marselha, Luciano, Reinaldo, Mari, Emily, Fladhimyr e
Bárbara. Essas pessoas contribuíram de forma significativa para que a pesquisa
obtivesse resultados reais.
RESUMO
Este trabalho investiga a possibilidade de identificação de problemas relacionados
ao processo de teste de software, identificando quais são os riscos desses
problemas no processo a afetarem a execução dos testes, associando um conjunto
de ações de mitigação e contingência para os esses riscos identificados. Finalmente,
a proposição de uma arquitetura que possibilite a recomendação automática dessas
ações, para que possa auxiliar responsáveis por projetos de Teste de Software à
tomada de decisões. Além disso, foi desenvolvido um protótipo baseado na técnica
de Raciocínio Baseado em Casos (RBC) visando a melhoraria no processo de teste
de software.
Palavras-Chave: Riscos. Processo de Teste de software, Melhoria.
ABSTRACT
This study investigates the possibility of identifying failures related to the testing of
software, identifying what are the risks of such problems in the process that can
affect the implementation of testing. This analisys will be base on the association of a
set of actions for mitigation and contingency for those identified risks and propose an
architecture that allows the recommendation of such actions that can help project
software testing owners. Furthermore, it was developed a prototype based on the
technique of Case Based Reasoning (CBR) in order to improve the process of
software testing.
Key words: Risk, Software Testing Process, Process Improvement.
LISTA DE ILUSTRAÇÕES
Figura 1 - Ciclo de Vida do Processo de teste. .........................................................18
Figura 2 - Níveis de Maturidade do TMMi e Áreas de Processo. .............................19
Figura 3 - EAR de Riscos .........................................................................................21
Figura 4 - Percentual de Uso das Técnicas de Identificação de Riscos. ..................23
Figura 5 - Processo Sistema RBC............................................................................26
Figura 6 - Etiqueta Classe Gramatical......................................................................29
Figura 7 - Riscos Identificados Através das Técnicas. .............................................43
Figura 8 - Porte Empresas Pesquisadas. .................................................................45
Figura 9 - Ramo das Atividades ...............................................................................45
Figura 10 - Número de Empresas Certificadas. .......................................................46
Figura 11 - Terceirização da Área de Teste. ............................................................47
Figura 12 - Metodologia Utilizada.............................................................................47
Figura 13 - Projetos que Utilizam SCRUM. ..............................................................48
Figura 14 - Automatizam e Utilizam Técnicas de Teste. ..........................................49
Figura 15 - Tipos de Teste. ......................................................................................49
Figura 16 - Existência de Técnicas de Revisão no Processo...................................50
Figura 17 - Técnica de Revisão................................................................................50
Figura 18 - Projetos têm Ferramenta de Apoio à Decisão........................................51
Figura 19 - Utilizam na Prática essa Ferramenta. ....................................................51
Figura 20 - Abordagem para Gerenciamento de Riscos ..........................................52
Figura 21 - Realização de Análise de Risco no Produto de Teste de Software. ......53
Figura 22 - Realização de Análise de Risco no Processo de Teste de Software. ....53
Figura 23 - Perfil dos Entrevistados .........................................................................54
Figura 24 - Número de Participantes X Tempo de Atuação na Área de Teste.......55
Figura 25 - Profissionais de Teste Certificados. .......................................................55
Figura 26 - Saída do Sistema FORMA.....................................................................57
Figura 27 - Base de Casos.......................................................................................59
Figura 28 - Tela de Cadastro de Projetos.................................................................60
Figura 29 - Tela Cadastro de Casos ........................................................................61
Figura 30 - Tela Recuperação de Casos na Base....................................................62
Figura 31 - Relatório de Projetos..............................................................................62
Figura 32 - Relatório de Categoria de Riscos...........................................................63
Figura 33 - Etapas GQM ..........................................................................................72
Figura 34 - Média da Melhoria no Processo de Teste..............................................74
Figura 35 - Comparação dos Valores Atribuídos .....................................................75
Figura 36 - Comparação Projetos. ...........................................................................76
LISTA DE QUADROS
Quadro 1 - Comparação dos Modelos Pesquisados. ................................................33
Quadro 2 - Riscos Encontrados na Literatura ...........................................................40
Quadro 3 - Comparação Riscos Identificados...........................................................42
Quadro 4 - Grau de Instrução dos Profissionais Entrevistados.................................56
Quadro 5 - Classificação da Pontuação. ...................................................................65
Quadro 6 - Classificação da Probabilidade. ..............................................................66
Quadro 7 - Classificação do Impacto. .......................................................................66
Quadro 8 - Matriz de Probabilidade e Impacto. .........................................................67
Quadro 9 - Riscos Classificados em Baixo/ Médio e Alto..........................................69
Quadro 10 - Questões GQM .....................................................................................73
Quadro 11 - Resultado das Questões .......................................................................74
LISTA DE SIGLAS
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
SEI Software Engineering Institute
TMM Modelo de Maturidade de Teste
TMMi Modelo de Maturidade de Teste Integrado
TMAP Test management approach
RBC Raciocínio Baseado em Casos
CBR Case Based Reasoning
SE Sistemas Especialista
IEEE Institute of Electrical and Electronics Engineers
WBS Work BreakDown Structure
PMI Project Management Institute
EAR Estrutura Analítica de Riscos
POS Part-Of-Speech
PA Área de Processo
MPS Melhoria Processo de Software
ASSESPRO Associação das Empresas Brasileiras de Tecnologia da
Informação
SEPROGRS Sindicato das Empresas de Informática do Rio Grande do Sul
ALATS Associação Latino-Americana de Teste de Software
GQM Goal Question Metric
DAR Decision Analysis and Resolution
CSTE Certified softare tester
ISTQB Internation Software Testing qualifications Board
SUMÁRIO
1 INTRODUÇÃO ........................................................................................... 14
2 REFERENCIAL TEÓRICO................................ ......................................... 17
2.1 Processo de Teste de Software...................... ......................................... 17
2.2 Modelo de Maturidade de Teste Integrado (TMMi)..... ........................... 18
2.3 Riscos............................................. .......................................................... 20
2.3.1 Categoria de Riscos ................................................................................. 20
2.3.2 Identificação de Riscos............................................................................. 22
2.3.3 Planejamento de Risco............................................................................. 23
2.3.3.1 Plano de Mitigação................................................................................... 23
2.3.3.2 Plano de Contingência ............................................................................. 24
2.4 Técnicas de Apoio à Decisão ........................ ........................................ 24
2.4.1 Raciocínio Baseado em Casos – RBC ..................................................... 25
2.4.2 Ferramenta FORMA ................................................................................. 27
2.4.2.1 Normalização Linguística ......................................................................... 27
2.4.2.2 Etiquetagem Part-Of-Speech ................................................................... 28
2.4.3 Processo de Classificação........................................................................ 29
2.4.4 Técnica do Vizinho mais Próximo............................................................. 29
3 TRABALHOS RELACIONADOS ............................. ................................ 31
4 METODOLOGIA........................................ ................................................ 33
4.1.1 Checklist .................................................................................................... 34
4.1.2 Expert Interview ......................................................................................... 34
4.1.2.1 Processo das Entrevistas .......................................................................... 36
4.1.2.2 Elaboração das Questões ......................................................................... 36
4.1.2.3 Seleção dos Entrevistados ........................................................................ 36
4.1.2.4 Realização das Entrevistas ....................................................................... 37
4.1.3 Brainstorming ............................................................................................. 37
5 COMPARAÇÃO ENTRE RISCOS IDENTIFICADOS .............. ................... 39
6 PERFIL DAS EMPRESAS, PROJETOS E ENTREVISTADOS...... ............ 44
6.1 Perfil das Empresas ................................ .................................................. 44
6.2 Perfil dos Projetos................................ ..................................................... 47
6.3 Perfil dos Entrevistados........................... ................................................. 54
7 PROTÓTIPO .............................................................................................. 57
7.1 Base de Conhecimento ............................... ............................................. 58
7.2 Recuperação de Padrões............................. ............................................ 59
7.3 Telas do Protótipo ................................. ................................................... 60
8 ESTRATÉGIAS E FERRAMENTAS DE AVALIAÇÃO ............. ................. 64
8.1 Avaliação Qualitativa.............................. .................................................. 64
8.1.1 Avaliação e Resultado Qualitativo dos Riscos Identificados ...................... 65
8.1.2 Matriz de Probabilidade e Impacto ............................................................. 66
8.2 Avaliação Quantitativa ............................. ................................................. 72
8.2.1 Avaliação e Resultado Quantitativo da Melhoria no Processo de teste através
Protótipo Apoio à decisão...................................................................................... 73
9 CONCLUSÃO .......................................... .................................................... 77
REFERÊNCIAS..................................................................................................... 79
APÊNDICE A – Checklist Riscos TMMi ................................................................ 82
APÊNDICE B – CheckList Expert Interview .......................................................... 83
APÊNDICE C – Entrevistas................................................................................... 84
APÊNDICE D – Planejamento Riscos Classificados............................................. 88
APÊNDICE E – Questionário Verificação Melhoria Processo de Teste ................ 94
APÊNDICE F – Caso de Uso ................................................................................ 95
14 1 INTRODUÇÃO
A área de qualidade de software, e consequentemente a área de teste de
software têm constituído foco de pesquisas acadêmicas. Paralelamente, os
conceitos que envolvem essa área de conhecimento têm sido aplicados com
crescente freqüência na indústria de software, como meio de qualificação de seus
produtos. Entretanto, devido à grande diversidade de linguagens de programação,
sistemas operacionais, hardware, evolução das plataformas e atividades, os
processos de teste de software têm se tornado cada vez mais complexos (MYERS,
2004).
Visando melhorar o processo de software, foram desenvolvidos vários
modelos como, por exemplo, CMM, CMMI (SEI, 2006), os quais servem como
diretrizes para muitas organizações de desenvolvimento de software como um todo.
Especificamente para a área de testes foram desenvolvidos modelos visando o
processo e produto de testes, tais como: TMM, TMMi (TMMI FONDATION, 2009) e
Tmap. O objetivo do TMMi é modelar um processo de teste de software, visando
reduzir os problemas na entrega do produto de software.
Em um processo convencional, as fases de desenvolvimento de software
podem apresentar inúmeros problemas ou falhas, os mesmos se caracterizam de
forma distinta ao longo do processo.
Estes problemas podem ser propagados para as demais fases, como por
exemplo, a fase de testes, fato que agrega custos significativos a atividades de
manutenção. De acordo com Myers (1979), quanto mais cedo os defeitos forem
corrigidos, menor será o custo de correção. Esse princípio ficou conhecido como
“Regra 10 de Myers”, onde faz uma comparação do custo: um defeito identificado na
fase de testes poderá ser dez vezes maior que se identificado na fase de design.
A possibilidade de ocorrerem problemas pode caracterizar risco ao processo
de teste de software e consequente ao produto, que são objetos de pesquisa deste
trabalho. Os riscos podem ser antecipados e tratados antes de se caracterizarem
como falhas, reduzindo assim os custos associados ao produto final.
Como objetivo de pesquisa primeiramente buscou-se investigar técnicas de
identificação de riscos, comparando-as, definindo quais se adaptam melhor ao
15 problema de pesquisa e aplicando essas técnicas de forma detalhada através de
uma amostragem com diversas organizações que tenham processo de teste de
software.
Assim foram investigadas as técnicas para identificação de riscos, como o
checklist realizado com base no modelo TMMi, bem como suas premissas para um
processo com nível 2 de maturidade, a partir dessa lista foi aplicadas as demais
técnicas, expert interview e brainstorming. Além da identificação se desenvolveu um
plano de mitigação e contingência.
A partir das técnicas definidas se pesquisou os riscos em processo de teste
citados pela literatura e comparou-se com os riscos identificados com as técnicas
aplicadas. Com os riscos comparados e identificados, os planos de mitigação e
contingência gerados, foi então idealizado a melhoria desse processo.
Segundo Gusmão (2008), a constante busca pela melhoria de processos, a
Engenharia de Software, apoiada pela Inteligência Artificial, desenvolve diversas
aplicações, que atualmente suportam aquisições, organizações, reuso e
compartilhamento de conhecimento sobre processo de software.
Visando melhorar o processo de análise de risco e principalmente o de teste
foi elaborada uma arquitetura e desenvolvido um protótipo de apoio à decisão para
automação da análise.
Além da apresentação do presente Capítulo, este trabalho está organizado na
seguinte estrutura:
Capitulo 2, Referencial Teórico, onde está descrito o estado da arte nesta
pesquisa, o processo de teste, modelo de maturidade de teste integrado, riscos,
suas categorias, como identificá-los, planejá-los e finalmente técnicas de apoio à
decisão;
Capítulo 3, apresentação dos trabalhos relacionados;
Capítulo 4 está descrita a metodologia da pesquisa deste trabalho e
comparação entre modelos;
Capítulo 5 está à comparação entre os riscos identificados;
Capítulo 6 é descrito o perfil da amostra de pesquisa (perfil das empresas,
projetos, e os profissionais entrevistados), onde é apresentada a amostragem com
dez empresas e quinze projetos com processo de teste;
16
Capítulo 7 é apresentado o protótipo e descrito a forma que foi desenvolvida a
arquitetura;
Capítulo 8, Estratégias e Ferramentas de avaliação, onde são descritas quais
as avaliações foram realizadas (qualitativa e quantitativa), as abordagens utilizadas
para a avaliação e os resultados das mesmas, e;
Capítulo 9, a Conclusão do trabalho.
17 2 REFERENCIAL TEÓRICO
Nesta seção são apresentados os conceitos dos temas relacionados com a
pesquisa em questão. São introduzidos conceitos sobre testes, mais
especificamente em processo de teste de software, Será apresentado o modelo
Tmap, este será utilizado para a pesquisa, pois se trata de uma abordagem
estruturada e genérica para o teste de produtos de software, na qual o modelo TMMi
foi baseado.
Descritos os conceitos sobre processo de teste, aborda-se o modelo TMMi e
sua estrutura, e como esse modelo pode colaborar para redução de riscos no
processo. Riscos são conceituados apontando possíveis técnicas de identificação a
serem utilizadas, destacando os modelos que servirão como apoio na pesquisa.
A partir das descrições, foram estudadas técnicas que possibilitaram a
automação do planejamento de riscos no processo de teste. Dentre as técnicas
podemos citar os Sistemas Especialistas (SE), baseados em Regras de Inferência,
Raciocínio Baseado em Casos (RBC), etc. A técnica que melhor se adaptou foi
RBC, devido a melhor se adaptar ao problema de pesquisa.
2.1 Processo de Teste de Software
Teste de software de acordo com Myers (2004) é um processo, ou uma série
de processos, concebidos para certificar que o código faz o que foi projetado para
fazer. Entende-se como modelo de processo de teste de software, as etapas,
artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos,
ampliação da organização e controle de projetos de teste. O Processo compreende
fundamentalmente o planejamento, a especificação, a execução, o registro, a
verificação da finalização e as atividades de fechamento (VEENENDAAL, POL
2007).
Atualmente enfocam-se as falhas em processos de teste de software que
estão associadas a problemas, como planos e casos de testes mal elaborados,
18 ambientes de teste instáveis, dentre outros (RIOS, 2005). Fatos estes que dificultam
de forma considerável a qualidade dos testes realizados.
O modelo de processo de teste a ser utilizado é o Tmap, criado por Martim
Pol. Esse modelo é consistente, amplamente utilizado e apresenta características
adequadas ao cenário de aplicação do presente trabalho de pesquisa.
No Tmap, as atividades do processo de teste são organizadas através de um
ciclo de vida, que funciona em paralelo com o desenvolvimento de software. “Na
estrutura do Tmap, as atividades de teste são divididas em cinco fases: preparação,
planejamento e controle, especificação, execução e entrega” (VEENENDAAL, POL
1997).
Figura 1 - Ciclo de Vida do Processo de teste. Fonte: VEENENDAAL, POL 1997.
2.2 Modelo de Maturidade de Teste Integrado (TMMi)
Tendo-se adotado o modelo de processo de teste, faz-se necessária a
definição de capacitação deste modelo no cenário pesquisado. Tal parâmetro
permite a identificação de lacunas nestes processos e a consequente definição de
riscos associados. Para definição do grau ou nível de capacitação adotou-se como
referência o padrão TMMi.
A arquitetura do TMMi tem fases para a melhoria do processo, que contém
cinco níveis através dos quais uma organização é submetida enquanto seu processo
de teste evolui, de um modelo ad hoc e não gerenciado, a um modelo que está
controlado, definido, medido e otimizado. Cada nível tem um conjunto de áreas de
processo onde as organizações precisam focar para atingir esse nível de
19 maturidade. As áreas de processo para cada nível de maturidade do TMMi são
apresentadas na figura 2.
Figura 2 - Níveis de Maturidade do TMMi e Áreas de Processo.
Fonte: Tmmi Fondation, 2009.
O modelo TMMI pode ser utilizado isoladamente, ou também pode ser
utilizado como um complemento ao modelo CMMI. Em muitos casos, um
determinado nível deste modelo tem necessidades específicas de apoio a partir de
áreas em seu processo, as quais correspondem a um nível superior do CMMI. Áreas
de Processo (PA) e práticas que são elaboradas no âmbito do CMMI não são na sua
maioria repetidas dentro TMMi, são somente referenciadas.
É o caso da gestão de riscos, onde no TMMi está definida no nível 2 e 3, já no
CMMI em seu nível 3. As práticas desta área de processo podem ser reutilizadas
(1) Inicial
(2) Controlado Política e estratégia de teste Planejamento de teste Monitoramento e controle de teste Projeto e execução de teste Ambiente de teste
(3) Definido Organização do teste Programa de formação de testadores Integração dos testes ao ciclo de vida Testes não-funcionais Revisões aos pares
(4) Gerenciado e Medido Medidas de Teste Avaliação de qualidade de software Revisão aos pares avançado
(5) Otimizado Prevenção de defeitos Otimização processo de teste Controle de qualidade
20 para identificar e controlar os riscos do produto e os riscos do projeto de teste,
tarefas que são na sua maioria críticas.
2.3 Riscos
Risco é a probabilidade de um evento, perigo, ameaça ou situação ocorrida e
suas consequências indesejáveis; um potencial problema. Trata-se de uma perda
(ou ganho, em caso de risco positivo) em potencial para a organização, que pode
ser expresso em termos qualitativos ou quantitativos (IEEE, 2001).
Segundo Rios (2005), uma aplicação mal-testada poderá também ser um
risco de perda para a empresa. É um dos elementos mais importantes para ser
trabalhado no momento da elaboração do projeto de testes de uma aplicação.
Conforme a recomendação do TMMi, os riscos dos projetos de teste devem
ser identificados, pois analisar os riscos de um projeto, poderá impedir a propagação
de falhas para fases posteriores, assim incorrendo em redução de custos.
Nos subitens abaixo, serão descritos conceitos sobre riscos pertinentes ao
trabalho em questão, e que metodologias serão utilizadas para a construção do
mesmo.
2.3.1 Categoria de Riscos
O CMMI recomenda determinar as categorias de risco, que expressam os
fatores utilizados para coleta e organização destas. Para que as categorias possam
vir a serem utilizadas em futuros planos de mitigações. Os fatores citados pelo
CMMI a serem considerados são os seguintes:
• Fases do modelo de ciclo de vida do projeto;
• Tipos de processos usados;
• Tipos de produtos utilizados;
• Gerenciamento risco do projeto (por exemplo, contrato, orçamento / custos,
cronograma, recursos, o desempenho, riscos e suporte de riscos), e;
21
• Riscos do Fornecedor (por exemplo: a viabilidade financeira do fornecedor e
localização geográfica).
A partir da categorização e dos fatores a serem considerados deve-se pensar
como gerenciar os riscos. A Gerência de Riscos é composta pelas seguintes
atividades (processos):
• Planejamento do gerenciamento de riscos;
• Identificação de riscos;
• Análise qualitativa dos riscos;
• Análise quantitativa dos riscos;
• Planejamento de respostas a riscos, e;
• Monitoramento e controle de riscos.
A execução desses processos de categorização durante o projeto visa
minimizar a probabilidade de ocorrência dos riscos, bem como minimizar seus
impactos. Por isso, a atividade inicial da Gerência de Riscos é sua identificação de
riscos. Através da identificação dos riscos, planos de mitigação e contingência
podem ser bem elaborados.
Conforme o PMI (2008), a categorização de riscos trata-se de um grupo de
possíveis causas de riscos. Essas causas podem ser agrupadas em categorias
como: técnico, externo, organizacional, ambiental ou de gerenciamento de projetos.
Uma categoria pode incluir subcategorias, como maturidade técnica, como pode ser
observada na figura 3, mas, essa é uma sugestão para gerenciamento de projeto
genérico, pois tipos de projetos e de organizações podem requerer diferentes
Estruturas Analíticas de Riscos (EARs).
Figura 3 - EAR de Riscos
Fonte: PMI, 2008.
22 2.3.2 Identificação de Riscos
Existem na literatura diferentes abordagens que são utilizadas para a
identificação de riscos, dentre elas pode-se incluir o uso de questionários,
taxonomias, brainstorming, análise do cenário, lições aprendidas ou de outros tipos
de aquisição de conhecimento (IEEE, 2001).
Na abordagem dos projetos de desenvolvimento de software, o CMMI, indica
as seguintes práticas:
• Examinar cada entregável do WBS (Work BreakDown Structure) do projeto;
• Expert interviews (entrevistas peritas);
• Rever os esforços de gestão de riscos dos produtos similares;
• Examinar documentos de lições aprendidas ou bases de dados, e;
• Examinar requisitos e especificações;
Em projetos de teste de software, o TMMi indica que riscos devem ser
identificados e associados com o teste, analisados e documentados, indicando as
técnicas de como identificar os riscos de teste do projeto, como exemplo, cita-se:
• Brainstorming (Sessões de troca de informações);
• Expert interviews (entrevistas peritas) e;
• Checklist (lista de verificação).
Além das técnicas sugeridas pelo TMMi pode-se utilizar outras técnicas, como
PMI, que cita a Técnica DELPHI, onde consulta um grupo de especialistas através
de questionário que são repassados contínuas vezes até que seja obtido um
consenso nas respostas.
A análise SWOT também é referenciada, técnica conhecida como análise dos
pontos fortes e fracos, que procura aferir questões positivas e negativas de uma
organização (PMI, 2008).
O PMI, em 2006, após pesquisa, listou as técnicas mais utilizadas na
identificação de riscos, como na figura 4.
23
Figura 4 - Percentual de Uso das Técnicas de Identificação de Riscos. Fonte: PMI, 2006.
2.3.3 Planejamento de Risco
É uma descrição da forma como os elementos e recursos do processo de
gestão do risco serão implementados dentro de uma organização ou projeto (IEEE,
2001).
2.3.3.1 Plano de Mitigação
Um plano de mitigação serve para que o gerente possa tentar diminuir o
impacto do risco ou até mesmo evitar a ocorrência (PMI, 2008). Para Salles et al.
(2006) a mitigação de riscos em projetos tem o objetivo de reduzir a probabilidade
ou impacto de um evento adverso até o limite em que o valor esperado resultante
seja aceitável.
Na visão de teste de software podemos citar um exemplo dado por Rios
(2005):
Devido à <falta e documentação dos casos de uso>, < os casos de teste foram preparados inadequadamente ou incompletos>, o que poderá <produzir testes mal feitos causando o surgimento de defeitos posteriores no ambiente de produção>.
Nesta etapa são implementadas as ações para redução da probabilidade de
ocorrência dos riscos que se caracterizam por um grau de criticidade elevado.
24 2.3.3.2 Plano de Contingência
De acordo com PMI (2008), plano de contingência é a determinação de ações
de recuperação quando da concretização de um risco ou ocorrência de um
determinado problema. Será sempre acionado quando o risco se transformar em um
problema.
Para o exemplo citado no plano de mitigação, possivelmente um plano de
contingência seria a contratação de técnico para, em caráter de urgência, realizar a
atividade.
2.4 Técnicas de Apoio à Decisão
Os sistemas de informação estão presentes em todas as empresas e
organizações. O conhecimento detido pelas organizações frequentemente é
encontrado e disseminado por diversos suportes. Ao utilizar um sistema de apoio à
decisão o profissional poderá especificar e modelar os processos de decisão,
representar e gerir o conhecimento existente na organização (RUSSEL, 2004).
Existem diversas técnicas de apóio a decisão, como os SEs, RBC entre
outras (RUSSEL 2004). Para o problema em questão, documentar as informações
de lições aprendidas é de fundamental importância, pois a partir da documentação
dos dados dos próximos projetos desenvolvidos, possivelmente, existirão os erros
dos projetos anteriores. Entretanto, os custos associados a estas práticas e as
características das demandas dos projetos de software impedem, e por vezes
inviabilizam a execução de tais atividades.
Visando o fato de que a possível solução é facilitar a aquisição de
conhecimento, foi selecionado para esta pesquisa o uso da técnica especialista
RBC.
25 2.4.1 Raciocínio Baseado em Casos – RBC
Conforme Abel (2005), o RBC surgiu como uma técnica poderosa para
solução automática de problemas. Essa técnica busca encontrar soluções para
novos problemas tomando como base soluções de problemas passados ou
similares. Desta forma, a solução já aplicada ao problema pode ser utilizada
novamente ou adaptada para o caso em questão.
Para Oliveira (2006), os casos são geralmente obtidos, consultando um
especialista humano. Um profissional com experiência deve transmitir seus
conhecimentos, assim, se inserirmos toda sua experiência em um sistema e
recuperarmos os casos de maneira eficiente teremos um sistema inteligente.
Um caso segundo Kolodner (1993) representa a informação completa de um
problema e solução específica, citada por (ABEL, 2005) “É uma instância concreta
do problema”, um caso pode diferenciar-se de outras experiências armazenadas
para contribuir com a melhor solução do problema. Que formalmente destaca a
composição dos casos como:
• Descrição do problema que caracteriza alguma situação particular a ser
resolvida, chamada de representação dos casos;
• O contexto no qual o caso se insere, chamado de índices dos casos;
• Descrição da solução associada ao problema, na forma de um diagnóstico,
uma classificação, uma sequência de ações, entre outros, e;
• Uma avaliação da solução empregada ao problema particular.
O processo básico de um sistema RBC é composto pelas etapas que são
apresentadas na figura 5.
26
Figura 5 - Processo Sistema RBC
Fonte: Lee, 1998.
A recuperação é uma fase que analisa o caso de entrada extraindo as
informações relevantes, fazendo uma busca na memória dos casos, e selecionando
os casos que podem ser aproveitados. A procura por casos é realizada por
algoritmos que selecionam os casos com determinada similaridade em relação ao
problema de entrada (SILVA, 2004). Nesta etapa podem ser utilizados (combinados
ou não) os métodos mais conhecidos de recuperação de casos, como: algoritmo de
vizinhança, algoritmo de indução, algoritmo indução guiada por conhecimento entre
outros e a recuperação de padrões (ABEL, 2005).
A reutilização constrói novas soluções a partir das soluções dos casos
recuperados e/ou partes destes através de ajustes e adaptações, ou seja, a partir do
novo caso é reutilizado o caso mais similar que houver na base de casos. Na revisão
se avalia e testa a solução construída para determinar sua eficácia, utilidade e
robustez, para que deste modo a solução seja confirmada. Na retenção se
acrescenta o novo caso à memória de casos, é nesta fase que um sistema RBC
passa pelo processo de aprendizado.
E, a indexação é uma questão importante considerando a estrutura e o
conteúdo da memória do sistema de RBC. A memória deve ser indexada para
proporcionar recuperação e reutilização eficientes. A partir da descrição do
problema, os índices devem apontar quais características do caso devem ser
Caso Aprendido
Novo Caso
Caso Adaptado
Novo Caso
Caso Recuperado
Caso Validado
Memória de
Casos
Problema
Solução Confirmada
Solução Proposta
27 comparadas, determinando assim o caso que pode ser útil para se chegar a uma
solução. Isto implica em inserir índices nos casos no momento de sua inclusão na
base de casos, para que mais tarde eles possam ser recuperados (SILVA, 2004).
Conforme Kolodner, os índices podem ser automáticos ou manuais. Os
métodos automáticos visam qualificar as diferenças entre os casos e os
relacionamentos entre feições do problema e solução adotadas, apesar dos métodos
automáticos auxiliarem na escolha de bons índices, Kolodner cita que na prática os
sistemas que são definidos artesanalmente tendem a ter melhor desempenho.
Neste trabalho, o RBC foi utilizado para a recuperação; o propósito é
recuperar mitigações e contingências para os riscos identificados visando a melhoria
no processo de teste de software. Portanto, não foi implementado o ciclo completo,
ou seja, não há aprendizagem de forma automática, mas há a possibilidade do
usuário especialista inserir um novo caso na base, se o mesmo não for recuperado.
Sendo assim, foi aplicado no trabalho o algoritmo da vizinhança por ser o mais
utilizado.
2.4.2 Ferramenta FORMA
A ferramenta FORMA foi desenvolvida por Marco Gonzalez (2006). Conforme
o autor esta ferramenta faz uma normalização morfológica que deriva o lema da
palavra original, ou seja, essa ferramenta tem a capacidade de segmentar as
sentenças em palavras, aplicar a normalização lingüística (lematização) e etiquetar
as palavras conforme as suas classes gramaticais.
2.4.2.1 Normalização Linguística
De acordo com Gonzáles (2005):
O reconhecimento de variações linguísticas encontradas em um texto permite o controle de vocabulário. Seleciona, os restringe em número e, em conseqüência, influencia o cálculo da representatividade dos mesmos.
28
O autor cita três tipos de normalização lingüística existentes: sintática, léxico-
semântica e morfológica.
A normalização sintática, que ocorre quando há a transformação de frases
semanticamente equivalentes, mas sintaticamente diferentes, em uma forma única e
representativa das mesmas, como: “eficiente processo rápido “e” processo rápido e
eficiente “.
A normalização léxico-semântica “ocorre quando são utilizados
relacionamentos semânticos para substituir palavras morfologicamente distintas por
uma única forma que representa o conceito referenciado”.
A Normalização Morfológica é o processo que reduz as variações de uma
palavra a uma forma única. A normalização mais usual segundo Gonzáles é o
processo Stemming. Trata-se de um processo que reduz ao mesmo stem (parte
fundamental semelhante ao radical) palavras que se diferenciam basicamente pela
flexão. Exemplo do funcionamento:
• stemming(livro) = stemming(livros) = livr
• stemming(caminhada) = stemming(caminhei) = caminh.
A lematização reduz as palavras variáveis à correspondente forma canônica: verbos no infinitivo e palavras, como substantivos e adjetivos, no singular e, quando existir, masculino. São exemplos:
• lematização(livro) = lematização(livrinho) = livro
• lematização(livre) = lematização(livres) = livre
• lematização(caminhar) = lematização(caminhei) = caminhar.
Para Gonzáles, os estudos demonstram que a utilização de lematização tem
trazido melhores resultados que stemming, porém cabe lembrar que a lematização
também tem erros.
2.4.2.2 Etiquetagem Part-Of-Speech
Conforme Gonzáles (2006) e Ramos (2008), a Ferramenta FORMA identifica
as classes gramaticais das palavras em uma sentença, mecanismo que é conhecido
em processamento de linguagem natural como POS, ou seja, Part-Of-Speech,
traduzindo por alguns autores como atos de fala. As etiquetas atribuídas pela
ferramenta FORMA são apresentadas na Figura 6.
29
Figura 6 - Etiqueta Classe Gramatical
Fonte: Gonzales, 2006.
2.4.3 Processo de Classificação
O processo de classificação é iniciado após o término do processo lingüístico
e o seu objetivo é obter a resposta adequada da base de conhecimento através da
utilização de dois métodos de recuperação tipicamente utilizados em sistemas de
RBC: a recuperação de padrões e o algoritmo de vizinhança.
2.4.4 Técnica do Vizinho mais Próximo
Segundo Abel (2005), o algoritmo de vizinhança (Nearest Neighbour), é um
método que consiste em definir pesos para as características mais importantes do
caso (elementos-chave). Através desses pesos podem ser calculados os índices de
similaridade entre a descrição dos casos e o problema. Estes índices permitem
classificar os casos por grau de semelhança e, desta forma, escolher o “mais
parecido”.
O problema deste algoritmo é justamente a escolha dos pesos. Geralmente,
eles são determinados pelo especialista do domínio ou por métodos estatísticos que
permitem identificar as características de maior importância a partir de suas
30 ocorrências. A fórmula abaixo apresenta o cálculo usado pelo algoritmo da
vizinhança para determinar a similaridade entre os casos e o problema.
( )
∑
∑
=
=
×
n
ii
Rii
n
ii
w
ffsimw
1
1
1
Esta fórmula consiste:
iW = corresponde ao peso de uma feição i qualquer que descreve o caso;
sim, é a função de similaridade;
l
if ’e R
if , são os valores da feição i para o novo caso e a caso recuperado,
respectivamente.
31 3 TRABALHOS RELACIONADOS
Para a solução da automação do planejamento de riscos, pode ser citado um
projeto que vem sendo desenvolvido no Departamento de Sistemas e Computação
(DSC – UPE) através da pesquisa de modelos que suportem a busca por
experiências passadas – CBR Risk Method. Segundo Gusmão (2008), o CBR risk é
um método que objetiva auxiliar gerentes de projetos nas suas atividades de
Gerência de Riscos, através de suporte à identificação de riscos para novos projetos
baseado em analogia. Esse método já está disponibilizado como funcionalidade da
ferramenta de Gestão de Riscos mPRIME Tool .
Essa ferramenta foi utilizada como pré-piloto durante a fase inicial da
pesquisa e pode-se concluir que é uma ferramenta limitada quanto à portabilidade,
pois funciona com um plugin do Microsoft Project, portanto, essa pode ser utilizada
somente associada à ferramenta da Microsoft, sendo que o objetivo do presente
trabalho na questão de automatização é obter possíveis soluções para riscos já
identificados, ou seja, tal ferramenta não é apropriada para o problema em questão.
Outra referência pesquisada foi a ferramenta: “Faqbot - Um Sistema De
Raciocínio Baseado Em Casos Com Processamento Lingüístico” de Ramos (2008),
este sistema responde a perguntas mais freqüentes de usuários em um domínio,
utiliza RBC e processamento lingüístico para recuperar as respostas mais
adequadas a cada pergunta. O processamento lingüístico é feito pela ferramenta
FORMA que inclui lematização e identificação das classes gramaticais das palavras
em um texto.
Em Mendes, Oleiveira, Gomes (2007), é destacada a importância de um
planejamento de um projeto de Melhoria processo Software (MPS) e da definição de
uma forma de monitoramento dos riscos do projeto. De acordo com os acadêmicos,
é necessário que seja escolhida uma técnica para identificação e monitoramento dos
riscos e que seja levada em consideração a extensa experiência da comunidade de
Engenharia de Software no desenvolvimento deste plano.
Rios (2005) destaca a análise de riscos em projetos de teste de software,
autor cita tipos de riscos de teste: em produto de software, projeto de teste de
software ou em processo de teste software. Segundo Rios, geralmente os riscos de
32 produto ou projetos são sintomas do processo de teste. Neste trabalho são
referenciados os principais riscos citados pelo autor.
33 4 METODOLOGIA
A metodologia de trabalho inícia com o estudo para a comparação entre
modelos e definição das técnicas de identificação de riscos que melhor se adaptam
ao problema de pesquisa.
Como descrito até o momento, os modelos referenciados buscam melhorar a
qualidade dos processos de desenvolvimento de software e ou testes de software, e
o PMI refere-se ao gerenciamento do projeto, o quadro 1 de comparação entre
modelos apresentado a seguir define os modelos utilizados na pesquisa.
Quadro 1 - Comparação dos Modelos Pesquisados.
Fonte: Autoria própria, 2009.
Baseado nos modelos que foram apresentados e comparados se faz a
definição dos métodos que foram utilizados para o desenvolvimento da pesquisa que
são descritos abaixo:
Categorização de riscos: É um método extremamente importante para se
iniciar uma análise de riscos. Como visto no quadro 1, o CMMI e PMI fazem
referência à categorização durante o processo de gerenciamento de risco. Como o
CMMI apenas indica categorizar os riscos como uma boa prática, será utilizado o
PMI, pois tem embasamento sobre o assunto, indicando possíveis categorias e
subcategorias a serem utilizadas.
Técnicas de Identificação de Riscos: Conforme a caracterização dos projetos
descrita no capítulo 5 e a técnica sugerida pelos modelos analisados, se definiu que
a utilização das técnicas: checklist, expert interviews e Brainstorming. Primeiramente
é realizado o estudo do TMMi, gerando o checklist, baseado nessa lista são
elaboradas as questões para utilização no expert interview e finalmente através dos
resultados das técnicas citadas anteriormente é realizado o brainstorming.
34
Para o planejamento de Riscos: análise que atente mais as necessidades da
pesquisa em questão, também é CMMI. Descrevem com maior clareza às melhores
práticas sobre esse método.
A seguir são descritas as técnicas selecionadas para identificação de riscos em
processo de testes neste trabalho:
4.1.1 Checklist
Esta foi a primeira técnica a ser utilizada na pesquisa. De acordo com PMI
(2008) trata-se de itens listados juntos para facilitar a comparação ou para garantir
que ações associadas a eles sejam gerenciadas adequadamente e não sejam
esquecidas. Um exemplo básico é o "fazer lista”. A mais avançada checklist seria um
calendário, que define as tarefas a serem feitas de acordo com a hora do dia ou
outros fatores.
Após o estudo do modelo TMMi foi extraído uma listagem de possíveis riscos
no processo de teste de software. Essa listagem encontra-se no Apêndice A.
4.1.2 Expert Interview
As entrevistas peritas têm o objetivo de obter o domínio de conhecimentos do perito - Perito é pessoa que é responsável pelo desenvolvimento, implementação ou o controle das soluções / estratégias / políticas - Pessoa que tem acesso privilegiado a informações sobre grupos de pessoas ou de processos de decisão.(BOGNER, 2005).
A metodologia defendida por Bogner distingue em três tipos de entrevistas:
• Explorative Expert Interviews – Baseada em conhecimentos técnicos
• Systematizing Expert Interviews – Baseada em processo de conhecimento
• Theory generating Expert Interviews – Baseada em exposição conhecimento
Os autores argumentam para a diferenciação dos tipos de interação, no qual
separam os seguintes tipos de entrevistadores:
35
• Interviewer as Co-expert: O conhecimento nível comparável, a comunicação
durante entrevista, simétrico, alto nível de interação, muitas questões por
especialistas, o entrevistador deve ter conhecimento e domínio da
terminologia, o diálogo deve ter permanentes questões em profundidade no
interrogatório.
• Interviewer as Expert outside of field – O Conhecimento deve ter nível de pé
de igualdade, a comunicação é simétrica, alto nível de interação, muitas
questões por especialistas, o entrevistador deve ter mais conhecimento da
terminologia e menos de campo, o diálogo deve ser permanente em
profundidade, sendo que o entrevistador deve intervir nas questões.
• Interviewer as Lay person – Há baixo nível de conhecimento do campo, a
comunicação é feita como um monólogo, paternalistaAssimétrica em favor do
entrevistado, o entrevistador tem o baixo nível de interesse do entrevistado,
as questões são grandes.
• Interviewer as Authority - O entrevistador tem maior campo conhecimento, a
comunicação é assimétrica em favor do entrevistador, a entrevista tem estilo
de interrogatório, mas com estilo autoritário no questionamento, com
frequentes críticas e questões subsequentes.
• Interviewer as Confederate – A comunicação durante entrevista é partilhada
de experiências e informal, estilo de diálogo, tem estilo de interrogatório.
• Interviewer as Possible Critic – Têm diferentes molduras normativas do
pensamento, a comunicação durante entrevista tem declinação de responder,
respostas curtas, questões críticas regresso, os entrevistados são críticos e
tendenciosos nos questionamentos.
O tipo que mais se adapta a entrevista realizada neste trabalho é Explorative
Expert Interviews, pois visa encontrar nas entrevistas conhecimentos técnicos dos
entrevistados, buscando melhor estruturar o problema. O tipo de entrevistador é o
Co-expert.
36 4.1.2.1 Processo das Entrevistas
Baseado nas indicações de Bogner foi elaborado um processo para
realização das entrevistas:
a) Desenvolver conjuntos de questões;
b) Selecionar os entrevistados;
c) Realizar entrevistas:
• Explicar ao entrevistado o âmbito de aplicação da entrevista;
• Explicar como você vai lidar com informações confidenciais;
• Apresentar no final da entrevista as respostas descritas pelo
entrevistador, com âmbito de receber o feedback do
entrevistado;
Baseado nesse processo foi criado um checklist contendo o planejamento das
entrevistas, conforme mostra Apêndice B.
4.1.2.2 Elaboração das Questões
Foram elaboradas 33 questões que envolvem riscos no processo de teste de
software, separadas por categorias de risco, conforme visto no capítulo 2, categorias
de riscos, questões essas baseadas nos riscos encontrados na literatura e checklist
elaborado a partir do modelo TMMi. As questões encontram-se no Apêndice C.
4.1.2.3 Seleção dos Entrevistados
Segundo Bogner, entrevistar diretamente pessoas com maior cargo nem
sempre é uma boa estratégia, pois podem ter boa visão, mas não ter tão bons
conhecimentos técnicos detalhados; visando obter tais conhecimentos foram
selecionados 15 profissionais de teste de software, conforme apresentado no
capítulo 5, perfil entrevistados.
37 4.1.2.4 Realização das Entrevistas
As entrevistas realizadas durante os meses de Abril a Julho de 2009. Foram
informados aos entrevistados os objetivos, o sigilo quanto ao nome das empresas e
nome dos projetos aos quais os entrevistados fazem parte. O tempo médio das
entrevistas foi em média de 00h: 40m e, por fim foram apresentadas as respostas ao
entrevistado para que pudesse verificar se as anotações do entrevistador estavam
de acordo com o expresso durante a entrevista.
4.1.3 Brainstorming
Brainstorming - traduzido para língua portuguesa "tempestade cerebral".
Conforme Moraes, (2007) “É uma técnica para geração de idéias, que consiste em
uma ou várias reuniões que permitem que as pessoas sugiram e explorem idéias”. O
autor sugeriu etapas a serem seguidas quando aplicada a técnica, são elas:
• Seleção dos participantes: Os participantes devem ser selecionados em função
das contribuições diretas que possam dar durante a sessão.
• Explicar a técnica e as regras a serem seguidas: O líder da sessão explica os
conceitos básicos de brainstorming e as regras a serem seguidas durante a
sessão;
• Produzir uma boa quantidade de idéias: Os participantes geram tantas idéias
quantas forem exigidas pelos tópicos que estão sendo o objeto do brainstorming.
Foram realizadas duas sessões com os seguintes perfis dos participantes
(VEENENDAAL, 2007):
• Líderes de Teste de Software: esses profissionais são responsáveis por liderar e
planejar o projeto de teste;
• Analistas de testes: que são responsáveis pela modelagem e elaboração dos
casos de teste e scripts de teste;
• Testadores: esses profissionais são habilitados e envolvidos no teste de um
componente ou sistema;
38 • Gerentes de Teste de Software: profissional que gerencia projetos de teste de
software.
As sessões ocorreram durante o mês de Agosto de 2009. Cada sessão teve a
participação de um líder de teste, um Analista de qualidade e um Analista / Testador
de software e um Gerente de teste.
39 5 COMPARAÇÃO ENTRE RISCOS IDENTIFICADOS
Após aplicar as técnicas descritas na sessão anterior, foi então pesquisado os
riscos encontrados na literatura, e em fim comparados com os riscos identificados
durante a aplicação das técnicas selecionadas.
O quadro 2 apresenta os principais riscos em processo de teste de software
citados na literatura, e comparados entre os autores: (RIOS, 2005), (BARTIÊ,2002),
(VEENENDAAL, POL 1997) e (QAI, 2007).
CAT. RISCOS CBOK
(QAI) E. RIOS A.BARTIE
TMAP
Ambiente de Testes instável X X X X
Mesmo ambiente de Testes ambiente de desenvolvimento
X
X
Funcionalidade nunca antes testada X
Massa de Teste com dados incorretos X X
Ausência de Teste automatizado X X
Software com número excessivo de erros X
Falta do uso de Ferramentas de Teste X
Não uso de padrões de registro de defeitos
X
TÉ
CN
ICO
Foco testes progressivos X X X
Orçamento de teste limitado X
Baixa Produtividade X
Número insuficiente de profissionais de teste
X
OR
GA
NIZ
AC
ION
AL
Falta de Treinamento em Ferramentas X
Falta de métricas adequadas
X X X
Testadores Inexperientes X X X
Gestão do conhecimento imperfeito X
Falta de documentação X
GE
RE
NC
IAM
EN
TO
DE
PR
OJE
TO
S
Cronograma de Teste Enxugados
X X X X
40
Mudança contínua de requisitos X X X X E
XT
ER
NO
Ausência teste de aceitação durante desenvolvimento
X
Quadro 2 - Riscos Encontrados na Literatura Fonte: Autoria própria, 2009.
No quadro 3, está a comparação entre os riscos teóricos, já citados no quadro
2, e, os riscos negativos e positivos identificados através técnicas de Checklist,
Expert Interview e Brainstorming. (1 – TEORICO, 2 – TMMI, 3 – EXPERT
INTERVIEW, 4 – BRAINSTORMIG).
CAT. RISCOS 1 2 3 4
Ausência de técnica de revisão no processo de teste X X X Baixa qualidade da massa de dados (dados errados, triggers inválidas, ausência de grants nas tabelas).
X X
Ausência de ferramentas para teste X X X X Ausência de gestão configuração X X Ausência técnicas de casos de teste a serem utilizados a cada nível do teste
X X X
Ausência de tipos de teste a serem realizados em cada nível de teste
X X X
Ausência de critérios de entrada e de saída para cada nível de teste
X X
Ausência de padrões de teste X X X Ausência da abordagem de automação em cada nível de teste X X Ausência de testes de regressão X X X X Ausência de testes manuais (sistema de qualidade) X X Ausência de indicadores de desempenho dos profissionais de teste
Ausência de indicadores de processo de teste Ausência de disponibilidade de um ambiente de acordo com os requisitos
X X X X
Ausência de ferramentas de planejamento do projeto e cronograma;
X X X
Ausência de ferramentas de estimativas; X X Ausência de ferramentas de avaliação de risco X X Mesmo ambiente de testes e desenvolvimento X X Funcionalidade nunca antes testada X X X Ausência de teste automatizado X X Mudança contínua de requisitos X X X Ausência teste de usabilidade X Ausência de causa e efeito no planejamento de teste X
TÉ
CN
ICO
Utilizar somente peer review como técnica de revisão quando demanda for muito complexa
X
41
Scripts de testes não serem atualizados X Scripts de testes não serem reutilizados X X Ausência de integrador/ arquiteto dentro do processo de teste X Ausência ferramenta de apoio à decisão X X Utilizar tecnologia muito antiga que não permite testes mais avançados, utilização de logs
X
Conter dados no registro de defeito que não é de conhecimento dos usuários (testadores) ou ter dados que não são utilizados
Dependência da equipe de testes com a gestão de configuração. X Quantidade excessiva de documentações de teste X Ausência de build versão X Equipe de testes identificar número excessivo de erros X X Ausência teste de aceitação durante desenvolvimento X X Orçamento de teste limitado X X X Rotatividade na equipe de testes X X Ausência de contrato com regras definidas a respeito da qualidade do software
X
Divulgar informações verbalmente X Ausência de painel processos de teste X X Ausência de feedback para o esclarecimento das políticas e objetivos de teste necessários
X X
Profissionais de testes sem qualificação X X X OR
GA
NIZ
AC
ION
AL
Número insuficiente de profissionais de teste X X X Não haver reuniões somente da equipe de testes X Existência de processo e não ser seguido X X Ausência treinamento de teste (teoria, conceito do processo) X X Baixa produtividade da equipe de teste X Falta de comunicação com membros de outra equipe X X Líder de teste depender de membros de outras equipes para tomar decisões
X
Dificuldade de acesso a documentações de projeto X Equipes de teste estar longe da de desenvolvimento X Ausência de reunião de kickoff X X Excesso de trabalho (equipe de testes absorver mais esforço que pode)
X
Falta de comunicação com o cliente X Ausência de status da revisão com gerência de mais alto nível X Cronograma de teste “enxugado” X X X Falta de comprometimento da equipe X X Ausência de reunião de “post-mortem" X Gerente de testes gerencia diversos projetos ao mesmo tempo X Ausência de apresentações no projeto e/ou em reuniões departamentais
X X
Ausência de análise de riscos produto X X X Ausência de análise de riscos processo X X X Ausência de avaliação e aderência do processo X X Ausência de processo definido X X Envolvidos não terem conhecimento no processo X X
GE
RE
NC
IAM
EN
TO
DE
PR
OJE
TO
S
Ausência de coleta de informações para melhoria processo X X
42
Ausência de nível de independência da equipe de teste X X Apenas utilizar instruções diretas como forma de repassar conhecimento
X
Ausência de análise das melhorias implantadas X Ausência de uma base de conhecimento X X Ausência de treinamentos presenciais X X Ausência de estimativa de teste X X X Ausência de porcentagem de detecção de defeitos X X Ausência de análise dos resultados dos indicadores de desempenho no processo de teste
X X
Ausência de relatório com indicadores de desempenho para as partes interessadas numa base periódica
X X
Ausência de utilização de lições aprendidas em versões de qualidade do projeto
X
Ausência de responsáveis para executar o processo X X Ausência de treinamento de pessoal X X X Ausência do plano de teste comitado X Ausência de disponibilidade de um relatório sumário do teste aprovado;
Ausência de definição dos critérios de suspensão e recomeço X X A disponibilidade da documentação, por exemplo, nota de liberação do teste, manual do usuário, manual de instalação, etc.
X X
Ausência de nível de prioridade nos defeitos X X Ausência de na porcentagem de cobertura de cada item do teste, por exemplo, cobertura do código ou cobertura dos requisitos;
X X
Não uso de padrões de registro de defeitos X X Falta de treinamento em ferramentas X X Gestão do conhecimento imperfeito X Falta de documentação X Não armazenar lições aprendidas X X Falta de estimativas elaboradas pela equipe de testes X X Falta de estimativas de planejamento de teste (Casos de Testes) X X Falta de estimativas para execução dos testes X X Falta de análise de métricas X Ausência de relatórios de testes X Ausência de melhorias contÍnuas no processo X Excesso de métricas, documentações e não utilização das mesmas.
X X
Ausência de monitoramento do processo de testes X X X Número excessivo de métricas X X Excesso de artefatos de teste X Terceirizar os testes X Distância do cliente nos testes X O cliente não ter ciência do processo de testes X X Ausência de contato com cliente para tirar dúvidas quanto regras de negócio.
X
Massa de dados ficarem no domínio do cliente X X EX
TE
RN
O
Proximidade do cliente nos testes X Quadro 3 - Comparação Riscos Identificados
Fonte: Autoria própria, 2009.
43
Como pode ser vizualizado nos quadros 2 e 3, os riscos apresentados através
das técnicas selecionadas na prática em projetos de teste tem um número
expressivo diante dos riscos citados na literatura.
Na prática se pode mostrar com detalhamento quais são os riscos enfrentados
no dia-a-dia e a eminência de problemas no processo.
A figura 7 apresenta a relação da quantidade de riscos encontrados na literatura,
através da técnica de checklist, expert Interview e brainstorming.
Riscos identificados através das técnicas:
0
20
40
60
80
100
Téoricos CheckList Expert Interview Brainstorming
Núm
ero
de R
isco
s
Figura 7 - Riscos Identificados Através das Técnicas.
Fonte: Autoria própria, 2009.
Foram identificados:
• 193 riscos durante a pesquisa, destes 89 riscos foram repetidos em
mais de uma técnica. Logo, foram econtrados 104 riscos, conforme
quadro 3.
No próximo capítulo, é descrito onde foram aplicadas as técnicas,
apresentando perfil das empresas, projeto e entrevistados envolvidos na pesquisa.
44 6 PERFIL DAS EMPRESAS, PROJETOS E ENTREVISTADOS
Para se obter participação das empresas e profissionais da área de teste,
realizou-se contato via telefone, e-mail e/ou pessoalmente com os especialistas na
área, buscou-se também apoio junto a entidades ASSESPRO (2009) e SEPROGRS
(2009).
Este contato teve por objetivo apresentar a pesquisa e verificar o perfil da
empresa contatada. Foram realizadas entrevistas preliminares onde tinham sido
selecionados 11 projetos com o perfil para participar da pesquisa. Nas primeiras
entrevistas técnicas observou-se que 4 projetos não se adaptavam à pesquisa
proposta.
Assim, foi realizado um novo processo de entrevistas, onde finalmente
conseguiu-se definir os projetos mais adequados para a pesquisa em questão; logo,
ficaram definidos 15 projetos, de 10 empresas, sendo que 3 são da empresa A, 2 da
B, 2 da empresa C, 2 da empresa D e 1 das empresas E, F, G H, I e J (os nomes
das empresas foram utilizados letras, pois os mesmos serão mantidos em sigilo).
Como já citado no capítulo anterior, no Apêndice C se apresentam as
questões utilizadas nas entrevistas desta pesquisa sendo que, a mesma foi dividida
em duas partes. A primeira parte é de identificação para fins de caracterização dos
profissionais e empresas participantes desta amostra. A segunda parte é de
questões elaboradas a partir do checklist do TMMi. As questões estão separas por
categorias de risco: técnico, organizacional, gerenciamento de projetos, e externo
(PMI, 2008).
6.1 Perfil das Empresas
Segundo Bastos (2009), co-fundador e atual diretor de projetos da Alats, “não
existem dados específicos quanto ao mercado de teste de software no Brasil,
estima-se que gire em torno dos 250 milhões de dólares (outsourced e in-house)”.
Foram levantados dados quanto às perspectivas do setor, por porte de
projeto, ramos de atividade, certificações, terceirização de serviços de teste de
45 software. A seguir descreve-se o resultado dos dados coletados das dez empresas
da amostra.
A figura 8 apresenta a distribuição das empresas da amostra por porte
considerando o número de funcionários (força de trabalho efetiva: sócios, dirigentes
e empregados efetivos), que corresponde ao critério de classificação para o setor de
Comércio/Serviços definido pelo SEBRAE (2009).
Porte das Empresas
50%
20%
30%
Grande
Média
pequena
Figura 8 - Porte Empresas Pesquisadas.
Fonte: Autoria própria, 2009.
Quanto ao ramo de atividades das empresas, 80% são empresas de TI, 20%
são do ramo de atividades em outras áreas.
Ramo Atividade
80%
20%
TI
Outros
Figura 9 - Ramo das Atividades
Fonte: Autoria própria, 2009.
46
Quanto a certificações das empresas, 60% tem alguma certificação de
modelo de desenvolvimento de software, conforme é demonstrado na figura 10.
Empresas Certificadas
40%
60%
Sim
Não
Figura 10 - Número de Empresas Certificadas.
Fonte: Autoria própria, 2009.
Quanto à terceirização da área de testes das empresas, para Bastos (2009),
“O setor de OOT (Offshore Outsourcing Testing) vem crescendo mais de 50% a
cada ano”, bastos comenta que se continuar com esse ritmo o Brasil passará a
configurar como um forte player, pois o país apresenta importantes vantagens
quando comparado aos seus concorrentes, tais como cultura e conhecimento de
negócios, mão-de-obra qualificada, mercado interno de TI forte e diversificado, fuso
horário e ausência de desastres naturais. Baseado nessa perspectiva de
crescimento, foram levantadas informações sobre outsourcing na área de teste,
como pode-se verificar na figura 11, mas através da amostra pode verificar que
apesar do crescimento em OOT é ainda relativamente baixo, pois apenas 20% das
empresas pesquisadas terceirizam serviços de teste de software. Porém
confirmando os dados citados por (BASTOS, 2009) 70% das empresas pretendem
investir na área de teste e terceirizar o serviço.
47
Terceiriza Área de Teste
20%
80%Sim
Não
Figura 11 - Terceirização da Área de Teste.
Fonte: Autoria própria, 2009.
6.2 Perfil dos Projetos
Quanto a metodologias utilizadas nas empresas, 60% dos projetos utilizam
metodologia tradicional e 40% dos projetos utilizam metodologia ágil.
Metodologia Utilizada
40%
60%
Ágil
Tradicional
Figura 12 - Metodologia Utilizada
Fonte: Autoria própria, 2009.
Todos os projetos que utilizam metodologia ágil utilizam o SCRUM, que
segundo Schwaber (2004), tem por objetivo definir um processo para projeto e
48 desenvolvimento de software seja focado nas pessoas e que seja indicado para
ambientes em que os requisitos surgem e mudem com rapidez. Assim, 100% dos
projetos que utilizam metodologia ágil são de projetos que automatizam teste de
software. Conforme podemos verificar na figura 13.
Para Projetos que Automatizam os Teste, todos Utili zam SCRUM
100%
Figura 13 - Projetos que Utilizam SCRUM.
Fonte: Autoria própria, 2009.
Quanto a projetos que automatizam os testes; Automatizar a execução dos
testes é a Utilização de um software, ex. ferramentas de captura/recuperação, para
controlar a execução de testes, a comparação entre os resultados reais e os
esperados, o estabelecimento de pré-condições e outras funções de controle de
teste e de relato (VEENENDAAL, 2007).
A partir dos projetos pesquisados conforme podemos observar na figura 14,
apenas 33% dos projetos automatizam a execução dos testes e os são mesmos que
executam a técnica de teste estruturado.
49
Automatizam e Utilizam Técnicas de Teste
67%
33%
Funcional
Estruturado /Automatizado
Figura 14 - Automatizam e Utilizam Técnicas de Teste.
Fonte: Autoria própria, 2009.
Quanto aos tipos de teste utilizados, ver figura 15, todos os 16 projetos
pesquisados realizam testes funcionais, 6 de usabilidade, 3 de regressão e
performance, 2 de carga e 1 de segurança.
Tipos de Teste
02468
10121416
Perfo
rmanc
e
Funcio
nal
Usabil
idade
Regres
sao
Stress
Segur
ança
Carga
Núm
ero
Pro
jeto
s
Figura 15 - Tipos de Teste.
Fonte: Autoria própria, 2009.
Para o uso de técnicas de revisão, conforme Std IEEE 1028 (IEEE, 2008), é a
avaliação sistemática de um produto de software por uma equipe de pessoal
qualificado que analisa a adequação do produto de software para o uso pretendido e
identifica discrepâncias em relação às especificações e normas. Revisões técnicas
50 também podem fornecer recomendações de alternativas e exame de várias
alternativas. Na figura 16 é apresentado a existência de revisão nos processos e
quais as técnicas utilizadas.
Existência de Técnicas de Revisão no Processo
67%
33%
Sim
Não
Figura 16 - Existência de Técnicas de Revisão no Processo.
Fonte: Autoria própria, 2009.
A partir dos 67% dos projetos que tem algum método de revisão no processo,
90% utilizam a técnica de Peer Review – For Eyes, consiste em uma revisão do
trabalho de um produto de software, no caso produto de testes de software feita por
colegas do produtor do produto, com a finalidade de identificar defeitos e apontar
melhorias (VEENENDAAL, 2007).
Técnica de Revisão no Processo
90%
10%
Peer Review
Outras Técnicas
Figura 17 - Técnica de Revisão
Fonte: Autoria própria, 2009.
51
Foi questionada a utilização de ferramentas de apoio à decisão no processo
de teste, os resultados estão expressos na figura 18.
Projetos têm Ferramenta De Apoio a Decisão
27%
73% Sim
Não
Figura 18 - Projetos têm Ferramenta de Apoio à Decisão.
Fonte: Autoria própria, 2009.
A partir dos 73% dos projetos que têm ferramenta de apoio à decisão no
processo de teste de software, apenas 50% utilizam na prática, logo, os projetos que
de fato utilizam alguma ferramenta de apoio à decisão em projetos de teste de
software são apenas 13%, ver gráfico 19.
Utilizam na prática ferramenta de Apoio a decisão
13%
87% Utilizam
Não Utilizam
Figura 19 - Utilizam na Prática essa Ferramenta.
Fonte: Autoria própria, 2009.
52
O ultimo estudo de benchmarking em gerenciamento de projetos divulgados
pelo PMI apresenta um gráfico com a abordagem para gerenciamento de riscos,
como pode ser visualizado na figura 20.
Podemos identificar que apenas 8% dos projetos não tratavam riscos nas
organizações.
Figura 20 - Abordagem para Gerenciamento de Riscos
Fonte: PMI, 2008.
O tratamento de riscos em projetos de teste de software é citado para na
literatura de teste em geral, como o TMMI, CBOK, porém a partir da amostra
realizada neste trabalho identificou que diferentemente da pesquisa apresentada
pelo PMI, para projetos de diversos setores de economia, em projetos de teste não é
uma prática tratada na grande maioria dos projetos, como pode ser visualizado nas
figuras 21 e 22.
53
Realizam Análise Riscos no Produto de Teste de Soft ware
9%
91%Utilizam
Não Utilizam
Figura 21 - Realização de Análise de Risco no Produto de Teste de Software.
Fonte: Autoria própria, 2009.
Realizam Análise Risco no Processo de Teste de Soft ware
0%
100% Utilizam
Não Utilizam
Figura 22 - Realização de Análise de Risco no Processo de Teste de Software.
Fonte: Autoria própria, 2009.
Apenas 9% dos projetos pesquisados utilizam a prática de analisar risco no
produto de software, e não foi identificado nenhum caso de projetos que utilizam
análise de risco no processo de teste.
54 6.3 Perfil dos Entrevistados
Dentre as pesquisas realizadas, desatacam-se alguns dados relevantes que
precisam ser expressos antes de analisarmos os resultados, dados esses a respeito
do perfil dos profissionais que participaram da técnica do Expert Interview,
caracterizado através dos critérios de qualificação profissional, tempo de atuação na
área de testes e formação acadêmica. A seguir, apresenta-se a caracterização dos
quinze profissionais da amostra de acordo com os critérios citados acima.
Quanto ao perfil dos entrevistados, 40% são Analistas de teste, 33% Líder ou
Gerente de teste, 20% de Testadores e 7% de Analista de qualidade, conforme
apresentado na figura 23.
Perfil dos Entrevistados
20%
40%7%
33%
Testador
Analista de Teste
Analista de Qualidade
Lider/Gerente de Teste
Figura 23 - Perfil dos Entrevistados
Fonte:Autoria Própria, 2009.
Quando ao tempo de experiência dos profissionais entrevistados no mercado,
verificou-se que a grande parte tem entre 3 a 5 anos de experiência, ver figura 24.
55
Número de Participantes X Tempo de atuação na área de teste de software
0
2
4
6
8
10
12
Até 3 anos Entre 3 e 5 anos Maior 5 anos
Núm
ero
Par
ticip
ante
s
Figura 24 - Número de Participantes X Tempo de Atuação na Área de Teste.
Fonte: Autoria própria, 2009.
Quanto a certificações na área de teste, no Brasil há a Certificação Brasileira
de teste de Software (CBTS), internacionalmente as mais procuradas são a CSTE
(Certified Software Tester) juntamente com a Internation Software Testing
Qualifications Board (ISTQB). Existem também certificações especificas para
conhecimento de ferramentas de automação de teste de software como a IBM
Rational.
Durante as entrevistas foi questionado aos entrevistados sobre tais
certificações, os resultados estão expressos na figura 25.
Certificação dos Profissionais
80%
20%
Não Cerificados
Certificados
Figura 25 - Profissionais de Teste Certificados.
Fonte: Autoria própria, 2009.
56
Na identificação dos entrevistados foi questionado o grau de instrução, que
pode ser visualizado no quadro 4.
Nível e Área
Engenharia de SW
Ciência da Computação/Informática
Outras Áreas
Total
Mestrado 0 0 1 1 Especialização 3 0 1 4 Graduação Completa
0 5 1 6
Graduação em Andamento
0 3 1 4
Total 3 8 4 15 Quadro 4 - Grau de Instrução dos Profissionais Entrevistados
Fonte: Autoria própria, 2009.
Após a apresentação do perfil das empresas e entrevisados; a seguir se
apresenta o protótipo desenvolvido para autmatizar a análise de riscos no processo
de teste.
57 7 PROTÓTIPO
O Protótipo de Analisador de Riscos em RBC foi implementado em C#,
utilizando SGBD Microsoft SQL Server 2005. Como mencionado no capitulo 2,
referencial teórico, o protótipo atende à utilização da ferramenta FORMA,
desenvolvida por Marco Gonzalez, onde aplica a normalização lingüística
(lematização) e etiquetagem das palavras com suas classes gramaticais. O processo
de classificação é iniciado após o termino do processo lingüístico e o seu objetivo é
obter a resposta adequada da base de conhecimento através da utilização de dois
métodos de recuperação tipicamente utilizados em sistemas de RBC: a recuperação
de padrões e o algoritmo de vizinhança.
Para exemplificar o uso da ferramenta, apresenta-se na figura 26 a saída do
sistema FORMA para a frase contendo um risco “Ausência de Técnica de Revisão
no Processo”. Nota-se na saída abaixo que o texto processado pela ferramenta é
formatado em três colunas. Na primeira coluna está o token original; na segunda
está o token processado, em caixa baixa e sem acentuação; e na terceira, a sua
etiqueta gramatical.
Figura 26 - Saída do Sistema FORMA
Fonte: Autoria própria, 2009.
58 7.1 Base de Conhecimento
A base de conhecimento é implementada através de banco de dados, onde
são armazenados os riscos (descrição), mitigação e contingência (soluções) e sua
classificação, correspondentes em linguagem natural e elementos-chave.
Assim como foi utilizado por Ramos (2008), referenciado no capitulo 3,
trabalhos relacionados, foram definidas cinco categorias de elementos-chave. Cada
uma destas categorias armazena os tokens que fazem parte de um grupo de classes
gramaticais similares. A seguir são apresentados cinco categorias de elementos-
chave e os rótulos gramaticais que o token deve receber para ser armazenado na
respectiva categoria:
• Verbos: _VA,_AP,_VB;
• Substantivos: _SU;
• Pronomes: _PL,_PD,_PI
• Adjetivos: _AJ
• Advérbios: _AV
A figura 27 apresenta exemplos de casos e a forma como os mesmos são
armazenados na base de conhecimento.
59
Figura 27 - Base de Casos
Fonte: Autoria própria, 2009.
Os pesos inseridos na base foram definidos a partir dos pesos dados por
Ramos (2008), após validar os pesos definidos pelo autor houve uns pequenos
ajustes de valores conforme os valores implementados abaixo:
• Verbos = 08
• Substantivos = 10
• Pronomes = 07
• Adjetivos = 05
• Advérbios = 03
7.2 Recuperação de Padrões
Para recuperação de padrões foi realizada uma query. A descrição do risco
deve possuir um conjunto mínimo de elementos-chave para retornar uma resposta,
sendo este conjunto formado por: substantivos e verbos e adjetivo e advérbios ou
pronomes. Esta definição parte da premissa que uma descrição de risco, para ser
válida, deve possuir no mínimo um substantivo como elemento-chave para ser
aceita.
(Indexação) Pronome: Advérbio: Substantivo : ausencia, tecnica, revisao, processo. Adjetivo: Verbo: (Resposta) Mitigação - Aplicar treinamentos de métodos de revisão a toda equipe de teste, para que assim todos tenham conhecimento. Contingência - Criar um checklist com os pontos mais importantes a serem realizados. Classificação - BAIXA
(Indexação) Pronome: Advérbio: Substantivo : dado, dominio, cliente. Adjetivo: Verbo: massa, ficar.
(Resposta)
Mitigação -Utilizar backup com massa de dados
Contingência - Criar nova massa de dados. Classificação - ALTA
CASO 1 CASO 2
Risco: Massa de dados ficar no domínio do cliente
Risco: Ausência de Técnica de Revisão no Processo
60
Sendo os outros elementos-chave, como: adjetivo, verbo, advérbio e pronome
opcionais, além desse conjunto de elementos-chave, filtram-se também para a
recuperação de padrões a categoria de risco (técnico, organizacional, gerenciamento
de projetos e externo) e o projeto em que utilizou tais informações.
Este tipo de recuperação vai reduzir a quantidade de casos para serem
trabalhados na próxima etapa, adicionando um ganho considerável em
processamento, já que o número de casos candidatos foi reduzido.
7.3 Telas do Protótipo
Como já citado, dentre o reconhecimento de padrão deste trabalho há o
cadastro de projetos, onde posteriormente nas consultas será possível filtrar os
riscos de diversos projetos, assim como armazenar na base de casos lições
aprendidas de projetos passados que ficaram armazenados, conforme figura 28.
Figura 28 - Tela de Cadastro de Projetos
Fonte: Autoria própria, 2009.
61
O cadastramento dos casos deve ser realizado por um especialista,
apresentado na figura 29. São informados o projeto e a categoria ao qual o risco se
adequar melhor.
Para a classificação de risco, o especialista deve informar qual a
probabilidade e o impacto do risco, o protótipo irá calcular com base na análise
qualitativa do PMI, a classificação na tela.
No momento em que o especialista clicar no botão gravar casos, o caso
passa por todo processo descrito neste capítulo, para melhor entendimento,
consultar o caso de uso e o diagrama de caso de uso no Apêndice F.
Figura 29 - Tela Cadastro de Casos
Fonte: Autoria própria, 2009.
Para recuperação dos casos, implementou-se uma tela para pesquisa, onde
serão informados: o projeto, a categoria e risco, ao clicar no botão recupera caso, o
protótipo irá executar o processo de recuperação do risco descrito (possível
problema), buscando na base de casos o risco mais similar (possível solução),
conforme figura 30. Para melhor entendimento, consultar o caso de uso no apêndice
F.
62
Figura 30 - Tela Recuperação de Casos na Base
Fonte: Autoria própria, 2009.
São gerados também dois tipos de relatórios, um sobre os riscos encontrados
por projeto e outro para os riscos por categorias, ver figura 31 e 32.
Figura 31 - Relatório de Projetos
Fonte: Autoria própria, 2009.
63
Figura 32 - Relatório de Categoria de Riscos
Fonte: Autoria própria, 2009.
Neste capítulo podemos ver o protótipo desenvolvido para automação da
análise de riscos em testes de software, a seguir estão descritos; as estratégias e as
ferramentas de avaliação qualitativa e quantitativa da pesquisa.
64 8 ESTRATÉGIAS E FERRAMENTAS DE AVALIAÇÃO
Neste trabalho foi desenvolvido um protótipo de uma ferramenta de apoio à
decisão baseada na técnica de RBC para análise em riscos no processo de teste; a
partir da utilização desse protótipo será realizada a avaliação quantitativa utilizando
a abordagem Goal, Question, Metric (GQM), no português, objetivos, perguntas e
métricas, onde a meta é gerar questões para obter métricas.
Seguindo os conceitos de avaliação citados pelo PMI para riscos identificados
podem ser avaliados qualitativamente ou quantitativamente. Será expressa da forma
qualitativa, pois o foco da análise quantitativa de risco visa custo do projeto, assim
não se aplica à pesquisa em questão.
A análise qualitativa, conforme PMI, tem como objetivo priorizar as causas dos
riscos com base na prioridade de ocorrência. A avaliação é realizada através de sua
probabilidade de ocorrência e impacto. A seguir são citados os conceitos sobre as
avaliações que serão utilizadas nesta pesquisa.
8.1 Avaliação Qualitativa
• Avaliação de Probabilidade: Investiga a probabilidade de cada risco
específico ocorrer.
• Avaliação de Impacto: Investiga o efeito potencial sobre um objetivo do
projeto, inclusive os efeitos negativos das ameaças e os efeitos positivos das
oportunidades.
A probabilidade e o impacto são avaliados para cada risco identificado. Os
critérios utilizados na priorização de tratamento dos riscos são os seguintes:
• Maior resultado da pontuação;
• Maior resultado de Impacto, e;
• Maior resultado de Probabilidade.
65 8.1.1 Avaliação e Resultado Qualitativo dos Riscos Identificados
Conforme recomendação do PMI, os riscos identificados deverão ser
analisados e classificados através de uma ponderação entre a probabilidade de
ocorrência e o impacto que irão causar ao processo e ou projeto, caso eles ocorram.
O resultado dessa ponderação é formado utilizando-se a probabilidade de ocorrência
do risco multiplicada pelo impacto de ocorrência do mesmo. Abaixo segue a fórmula:
impactoadeprobabilidpontuação ×=
Os quadros 5, 6 e 7 foram desenvolvidos com base nos exemplos citados por
Salles Junior et al. (2006), Pereira (2007) e PMI (2008).
No quadro 5 são listadas as ações a serem tomadas de acordo com a
pontuação.
Pontos Classificação do risco Ações a serem tomadas
Inferior a 0,05
Muito Baixa Serão classificados com graduação “Muito Baixa”.
Não necessita análise de mitigação nem contingência.
Entre 0,05 e 0,08
Baixa Serão classificados com graduação “Baixa”.
Planos de contingência e mitigação devem atuar de forma a preveni-los.
Entre 0,09 e 0,12
Média Serão classificados com graduação “Média”, tendo a necessidade de controle e monitoramento periódico.
Planos de contingência e mitigação devem atuar de forma a preveni-los.
Superior a 0,12
Alta Serão classificados com graduação “Alta” e requerem atenção especial para controle e monitoramento constante.
Estratégias de contingência e mitigação devem procurar prevenir eficientemente estes riscos.
Quadro 5 - Classificação da Pontuação. Fonte: Autoria própria, 2009.
66
No quadro 6, estão listadas as classificações para a probabilidade de
ocorrência dos riscos.
Probabilidade Fator %
Muita Baixa 0,1 20%
Baixa 0,2 40%
Média 0,3 60%
Alta 0,4 80% Quadro 6 - Classificação da Probabilidade.
Fonte: Autoria Própria, 2009.
No quadro 7, as classificações para o impacto de ocorrência dos riscos.
Impacto Fator
Muito Baixo 0,1
Baixo 0,2
Médio 0,3
Alto 0,4 Quadro 7 - Classificação do Impacto.
Fonte: Autoria Própria, 2009.
8.1.2 Matriz de Probabilidade e Impacto
Os riscos podem ser priorizados para análise quantitativa, com base na sua
classificação. As classificações são atribuídas aos riscos com base em sua
probabilidade e impactos avaliados.
A avaliação da importância de cada risco, a prioridade da atenção é
normalmente realizada usando em um quadro de pesquisa ou uma matriz de
probabilidade e impacto (Quadro 8). Essa matriz especifica as combinações de
probabilidade e impacto que levam à classificação dos riscos como de prioridade
baixa, moderada ou alta. Podem ser usados termos descritivos ou valores numéricos
(PMI, 2008).
67
As combinações de probabilidade e impacto resultam em uma classificação
de risco alto (“condição vermelha”), risco moderado (“condição amarela”) e risco
baixo (“condição verde”), (PMI, 2008).
No quadro 8, é apresentada a matriz de probabilidade e impacto realizada
para demonstrar os resultados das pesquisas.
Probabilidade Ameaças Oportunidades
0,4 0,04 0,08 0,12 0,16 0,16 0,12 0,08 0,4
0,3 0,03 0,06 0,09 0,12 0,12 0,09 0,06 0,3
0,2 0,02 0,04 0,06 0,08 0,08 0,06 0,04 0,2
0,1 0,01 0,02 0,03 0,04 0,04 0,03 0,02 0,1
0,1 0,2 0,3 0,4 0,4 0,3 0,2 0,1 Quadro 8 - Matriz de Probabilidade e Impacto.
Fonte: Autoria própria, 2009.
A análise de probabilidade e impacto foi realizada de forma qualitativa, através
da frequência dos eventos identificados nas entrevistas realizadas. Como por
exemplo:
• Risco Identificado: Ausência de Técnica de Revisão no processo;
• 46% dos projetos pesquisados não utilizam técnicas de revisão no
processo;
Ou seja; a possibilidade de ocorrer esse risco é de 46%, conforme a faixa
estipulada no quadro 9, de probabilidade, classifica-se esse risco como BAIXO.
Abaixo, o quadro com a priorização dos riscos que resultaram na classificação
como baixa, média ou alta:
Cat ID Risco 1 Ausência de técnica de revisão no processo 2 Ausência técnicas de casos de teste a serem utilizados a cada
nível do teste 3 Ausência de tipos de teste a serem realizados em cada nível de
teste 4 Ausência de critérios de entrada e de saída para cada nível de
teste 5 Ausência de padrões de teste 6 Ausência da abordagem de automação em cada nível de teste 7 Ausência de testes de regressão 8 Ausência de indicadores de desempenho dos profissionais de teste 9 Ausência de indicadores de processo de teste
TÉ
CN
ICO
10 Ausência de disponibilidade de um ambiente de acordo com os
68
requisitos 11 Ausência de ferramentas de planejamento do projeto e
cronograma; 12 Ausência de ferramentas de estimativas 13 Ausência de ferramentas de avaliação de risco 14 Mesmo ambiente de testes e desenvolvimento 15 Funcionalidade nunca antes testada 16 Ausência de teste automatizado 17 Mudança continua de requisitos 18 Ausência teste de usabilidade 19 Scripts de testes não serem atualizados 20 Scripts de testes não serem reutilizados 21 Ausência ferramenta de apoio à decisão 22 Dependência da equipe de testes com a gestão de configuração. 23 Ausência teste de aceitação durante desenvolvimento 24 Equipe de testes identificarem número excessivo de erros 25 Número excessivo de métricas 26 Orçamento de teste limitado 27 Rotatividade na equipe de testes 28 Ausência de contrato com regras definidas a respeito da qualidade
do software 29 Divulgar informações verbalmente 30 Ausência de painel de processo
OR
GA
NIZ
AC
ION
AL
31 Não haver reuniões somente da equipe de testes
32 Ausência treinamento de teste (teoria, conceito do processo). 33 Ausência de reunião de kickoff 34 Excesso de demandas (equipe de testes absorverem mais esforço
que pode) 35 Ausência de status da revisão com gerência de mais alto nível 36 Cronograma de teste “enxugados” 37 Ausência de reunião de post-mortem 38 Ausência de análise de riscos produto 39 Ausência de análise de riscos processo 40 Ausência de avaliação e aderência do processo 41 Ausência de processo definido 42 Envolvidos não terem conhecimento no processo 43 Ausência de coleta de informações para melhoria processo 44 Ausência de nível de independência da equipe de teste 45 Apenas utilizar instruções diretas como forma de repassar
conhecimento 46 Ausência de análise das melhorias implantadas 47 Ausência de uma base de conhecimento 48 Ausência de estimativa de teste 49 Ausência de porcentagem de detecção de defeitos
GE
RE
NC
IAM
EN
TO
DE
PR
OJE
TO
50 Ausência de análise dos resultados dos indicadores de desempenho
69
51 Ausência de relatório com indicadores de desempenho para as partes interessadas numa base periódica
52 Ausência de utilização de lições aprendidas em versões de qualidade do projeto
53 Ausência de disponibilidade de um relatório sumário do teste aprovado
54 Ausência de definição os critérios de suspensão e recomeço 55 A disponibilidade da documentação, por exemplo, nota de
liberação do teste, manual do usuário, manual de instalação, etc. 56 Ausência de na porcentagem de cobertura de cada item do teste,
por exemplo, cobertura do código ou cobertura dos requisitos; 57 Falta de documentação 58 Falta de estimativas elaboradas pela equipe de testes 59 Falta de análise de métricas 60 Excesso de métricas, documentações e não utilização das
mesmas. 61 Ausência de contato com cliente para retirar dúvida quanto a
regras de negócio 62 Massa de dados ficarem no domínio do cliente
EX
TE
RN
O
63 Cliente não ter ciência do processo de teste Quadro 9 - Riscos Classificados em Baixo/ Médio e Alto.
Fonte: Autoria própria, 2009.
No quadro 10 apresenta-se o detalhamento do calculo de pontuação para
classificação dos riscos que foram apresentados no quadro 9.
ID Probabilidade Impacto Pontuação
(p x i) Classificação
do risco
1 0.2 0.3 0.06 Baixa
2 0.4 0.4 0.16 Alta
3 0.2 0.3 0.06 Baixa
4 0.4 0.4 0.16 Alta
5 0.2 0.4 0.08 Baixa
6 0.2 0.2 0.08 Baixa
7 0.2 0.4 0.08 Baixa
8 0.4 0.3 0.12 Média
9 0.3 0.3 0.09 Média
10 0.4 0.2 0.08 Baixa
11 0.2 0.3 0.06 Baixa
12 0.2 0.3 0.06 Baixa
70
13 0.4 0.3 0.12 Média
14 0.3 0.3 0.09 Média
15 0.4 0.3 0.12 Média
16 0.3 0.3 0.09 Média
17 0.4 0.4 0.16 Alta
18 0.3 0.3 0.09 Média
19 0.2 0.4 0.08 Baixa
20 0.2 0.3 0.06 Baixa
21 0.4 0.2 0.08 Baixa
22 0.3 0.4 0.12 Média
23 0.4 0.3 0.12 Média
24 0.4 0.4 0.16 Média
25 0.2 0.4 0.08 Baixa
26 0.4 0.3 0.12 Média
27 0.2 0.4 0.08 Baixa
28 0.2 0.3 0.06 Baixa
29 0.2 0.4 0.08 Baixa
30 0.4 0.2 0.08 Baixa
31 0.3 0.2 0.06 Baixa
32 0.2 0.4 0.08 Baixa
33 0.4 0.2 0.08 Baixa
34 0.3 0.4 0.12 Média
35 0.4 0.2 0.08 Baixa
36 0.2 0.4 0.08 Baixa
37 0.4 0.2 0.08 Baixa
38 0.4 0.4 0.16 Alta
39 0.4 0.3 0.12 Média
40 0.3 0.3 0.09 Média
41 0.2 0.4 0.08 Baixa
42 0.2 0.4 0.08 Baixa
43 0.4 0.3 0.12 Média
44 0.2 0.4 0.08 Baixa
45 0.2 0.3 0.06 Baixa
46 0.4 0.2 0.08 Baixa
71
47 0.2 0.4 0.08 Baixa
48 0.2 0.4 0.08 Baixa
49 0.2 0.3 0.06 Baixa
50 0.2 0.3 0.06 Baixa
51 0.2 0.3 0.06 Baixa
52 0.4 0.4 0.16 Alta
53 0.3 0.4 0.12 Média
54 0.4 0.4 0.16 Alta
55 0.3 0.4 0.12 Média
56 0.4 0.2 0.08 Baixa
57 0.2 0.4 0.08 Baixa
58 0.2 0.3 0.06 Baixa
59 0.2 0.3 0.06 Baixa
60 0.2 0.3 0.06 Baixa
61 0.2 0.4 0.08 Baixa
62 0.4 0.4 0.16 Alta
63 0.2 0.4 0.08 Baixa Quadro 10 – Análise Qualitativa
Fonte: Autoria própria, 2009.
Para o planejamento dos riscos identificados (mitigação e contingência) foi
retirado da técnica de Expert Interview e das sessões de Brainstorming realizadas.
Identificou-se que problemas que ocorrem em certo projeto não ocorrem em outro
que tem a mesma situação.
Como por exemplo: no projeto “A”, ocorre o risco de “ausência de contato com
cliente para retirar dúvida quanto a regras de negócio (requisitos de domínio)”, é um
risco ou problema que ocorreu nesse projeto, mas no projeto “B” que requeria
também retirar dúvidas com cliente sobre regras de negócio não havia esse risco,
pois outro projeto mitigou essa situação criando padrões de comunicação com
cliente. Ou seja,
• Risco: Ausência de contato com cliente para retirar dúvida quanto a regras de
negócio.
• Mitigação: Criar padrões de comunicação com cliente.
72
Conforme quadro 5, todos os riscos que foram classificados como baixo,
médio ou alto tem de ser mitigados e contigênciados, riscos estes apresentados no
quadro 9, que podemos verificar o planejamento no Apêndice D.
8.2 Avaliação Quantitativa
Faz-se a utilização da abordagem GQM. Conforme Solingen et al. (2001) as
primeiras idéias de GQM foram publicadas pela primeira vez em 1984 por Vic Basili
e os seus colegas na Universidade de Maryland, desde então, muita experiência
industrial tem sido adquirida e teorias têm sido desenvolvidas para apoiar a
abordagem.
Segundo Basili et al. (1981), em qualquer disciplina de engenharia de
desenvolvimento de software requer uma medição mecanismo de feedback e
avaliação.
Para Solingen et al. (2001) o principal objetivo da medição é aprender sobre a
qualidade do software e identificar se a medição realmente valeu a pena.
De acordo com Basili, a idéia fundamental é simples e consiste em três
etapas, que estão sendo apresentadas na figura 33:
Figura 33 - Etapas GQM
Fonte: Basili, 1984.
Aná
lise
e In
terp
reta
ção
Def
iniç
ão
Objetivo
Objetivo
Nível Conceitual Mensurar objetivos envolvendo produtos, processo e / ou recursos.
Nível Operacional Uns conjuntos de questões são utilizados para definir modelos para caracterizar a avaliação ou realização de um objetivo.
Nível Quantificavél Associa conjunto de métricas, associado com todas as questões, a fim apresentar resultados de forma mensurável.
Q1 Q2
Q3
Q4 Q5
M1 M2 M3 M4 M5 M6
73
Basili, 1984, sugere etapas para utilização do GQM, são elas: elaborar
planejamento, identificar objetivos, elaborar questões, coletar e validar dados, e,
finalmente analisar os resultados.
8.2.1 Avaliação e Resultado Quantitativo da Melhoria no Processo de teste através Protótipo Apoio à decisão
Tendo como base a abordagem GQM, foi elaborado o quadro 10:
Objetivo Propósito Melhoria Aspecto Quantitativo Objetivo Melhorar processo de teste Ponto de Vista Líder/Gerente de teste
Q1 Os riscos contidos no protótipo condiziam com a realidade de seu projeto?
Q2 A utilização dos riscos auxiliou no planejamento de testes?
Q3 As soluções (mitigações e contingências) contidas no protótipo auxiliaram para melhoria do processo?
Q4 A automação da análise de risco melhorou o processo?
Questão
Q5 O protótipo influenciou a tomada de decisões no projeto?
Métricas
nQ Média Aritmética
nQ Desvio Padrão
Quadro 10 - Questões GQM Fonte: Autoria própria, 2009.
Foram selecionados 6 projetos em 3 empresas, esta seleção se deu através
da necessidade de quantificar a melhoria do processo de testes em projetos novos e
projetos de manutenção.
Sendo, 3 projetos novos e o restante são de manutenção. No período de 20
dias úteis, a partir no dia 12 de outubro a 06 de novembro de 2009, os usuários
utilizaram o protótipo para a automação da análise de riscos em seus processos de
teste de software.
74
A geração de métricas se obteve através das questões (Quadro 10). Foi
enviado aos usuários o formulário que se encontra no Apêndice E. Assim, se definiu
para cada questão respondida, que o usuário atribuísse um valor de 0 a 5. (zero
para nada a cinco para tudo). A partir dessa pontuação se fez uma média aritmética
das questões por responsável de cada projeto de teste. O quadro 11 apresenta os
resultados.
Questões Projeto1 Projeto2 Projeto3 Projeto4 Projeto5 Projet o6
1 3 5 4 5 5 3
2 4 5 5 5 5 3
3 4 4 5 4 5 5
4 4 5 5 5 4 4
5 4 5 5 5 4 4 Quadro 11 - Resultado das Questões
Fonte: Autoria própria, 2009.
Na figura 34 é apresentada a média aritmética dos projetos baseados nos
pesos das 5 questões. O desvio padrão quantifica a dispersão dos eventos sob
distribuição normal, é a média da variação dos resultados obtidos. (LARSON,
FARBER, 2007), também encontra-se na figura abaixo.
Média Melhoria do Processo
0.6324555
3.6
4.8
5
4.6
4.8
3.6
0 1 2 3 4 5 6
Desvio Padrão
Projeto 6
Projeto 5
Projeto 4
Projeto 3
Projeto 2
Projeto 1
Figura 34 - Média da Melhoria no Processo de Teste.
Fonte: Autoria própria, 2009.
75
Como pode ser visualizado na figura 34, todos os projetos apresentaram
melhoria no processo de teste de software.
Outra análise realizada foi, comparar o resultado da questão 1, ”Os riscos
contidos no protótipo condiziam com a realidade de seu projeto?”, com as questões
5, 2 e 3. Pois, tal comportamento pode ser comprovado considerando os projetos
que tiveram respostas com valor 5, conforme sinalizado no quadro 11, ou seja, se
os riscos contidos na base refletiam fortemente com a realidade, o protótipo foi
utilizado influenciando na tomada de decisão.
As soluções contidas na base foram utilizadas também, logo as soluções de
mitigações e contigências auxiliaram no planejamento de teste. Ver figura 35.
Comparação de Questões
0
1
2
3
4
5
6
Projeto 2 Projeto 4 Projeto 5
Núm
ero
de Q
uest
ões Questão 1
Questão 5
Questão 2
Questão 3
Figura 35 - Comparação dos Valores Atribuídos .
Fonte: Autoria própria, 2009.
Notou-se que em projetos novos, onde a análise de riscos foi realizada no
início no projeto, a melhoria foi maior se comparado com os projetos que era de
baseline, conforme pode ser vizualizado na figura 36.
76
Comparativo entre Projetos
3.6 3.6
4.64.80 4.8 5
0
1
2
3
4
5
6
1 2 3
Núm
ero
de Q
uest
ões
Projetos Manutenção
Projetos Novos
Figura 36 - Comparação Projetos. Fonte: Autoria própria, 2009
Outro fator a ser ressaltado é o fato dos projetos de baseline ter nível de
maturidade, ou seja, o impacto da ausência de análise de risco no processo é baixo.
Por outro lado, para projetos novos o uso da análise de risco se mostra um fator
importante para melhoria do processo.
77 9 CONCLUSÃO
Atualmente, o tema riscos em processo de teste vem sendo cada vez mais
citado na literatura, porém não se identificou o detalhamento dos riscos, se buscou
investigar quais eram os principais riscos dentro do processo, e se os mesmos eram
utilizados na prática nas diversas organizações.
Sabemos que processos de teste que não são bem executados, ou seja, que
existem problemas ou falhas podem acarretar problemas futuros, como entregar um
produto sem qualidade, gerando maior custo.
Como forma de sanar parte deste problema, foi pesquisado primeiramente
técnicas de identificação de riscos, comparou-se, definiram-se as técnicas que mais
se adaptavam a realidade e aplicou-se em 15 projetos de teste de software.
Antes de aplicar as técnicas foi realizado um estudo dos riscos em processo
de testes encontrados na literatura, se pode concluir que não eram abrangentes, que
não possuíam detalhamento e não se encontraram possíveis soluções (mitigações e
contingências).
A partir dos riscos teóricos identificados, as técnicas foram aplicadas, e então
gerado uma lista dos principais riscos encontrados em diversas organizações e
comparados novamente.
Os riscos foram avaliados e classificados de forma qualitativa, para os riscos
com classificação baixa, média e alta foram gerados mitigações e contingências
extraídas das próprias técnicas de identificação de riscos.
Para avaliação da melhoria no processo de teste através da análise de riscos,
o protótipo foi desenvolvido para automatizar o processo visando sua melhoria.
O resultado da avaliação quantitativa foi positivo, conclui-se que a listagem
dos riscos condiziam com a realidade na maioria dos projetos, e isso trouxe
benefícios quanto a melhoria no processo de testes. Os riscos influenciaram o
planejamento de teste e à tomada de decisão.
Logo, pode-se demonstrar a todos os envolvidos o quanto se fala de riscos
em teste, a sua importância, e o quanto essa prática pode melhorar seu trabalho.
Trata-se de uma mudança principalmente cultural e necessária para o bom uso de
uma ferramenta de apoio a tomada de decisão, quando seu conteúdo é condizente
com a realidade do projeto.
78
Diversas ferramentas de apoio à decisão estão no mercado e ainda estão
sendo desenvolvidas, o uso dessas ferramentas tem a tendência de aumentar em
processos de desenvolvimento de software, no mercado em geral, tendo em vista
que é um pré-requisito para certificação CMMI, área de processo (DAR), onde
diversas empresas devem obter uma ferramenta, seja ela desenvolvida em Excel ou
em poderosas linguagens de programação.
Foi identificado através das pesquisas realizadas que poucos projetos se
preocupam em como e onde essas ferramentas devem ser utilizadas para que, de
fato, melhorem o processo, onde o objetivo é entregar um software com qualidade.
Após o uso do protótipo para analisar riscos no processo de teste foi
concluído através do GQM, que de fato a utilização de uma ferramenta de apoio à
decisão com conteúdo coerente com a realidade de projetos de teste, quando
utilizada durante a fase de planejamento e monitoramento de teste melhora o
processo, e quando executada no início podem trazer melhorias ainda mais
significativas.
Assim, a partir da comprovação da melhoria do processo, surgem
naturalmente algumas idéias para trabalhos futuros. O protótipo desenvolvido foi
aceito pelos usuários (especialistas), onde nesse momento pode-se verificar a
necessidade de desenvolver o sistema, onde a quantidade de casos será maior
devido o fato da possibilidade de não ser utilizado apenas para processo de teste,
mas também para produto, ou até mesmo para qualquer outro problema, isso
aumentará de forma considerável o número de casos na base, logo será necessário
aplicar mais algoritmos de similaridade, no caso algoritmos locais e globais a fim de
melhorar a precisão da busca de casos na base.
Realizar mais amostragens do uso de análise de risco no processo, como
utilizar métricas a partir da remoção de defeitos do projeto, é um ponto interessante
a ser pesquisado.
Outra idéia foi realizar investigações sobre risco do produto de teste de
software, em que momento deve–se entregar produto de software com algum
defeito? qual o risco e o impacto que terá no projeto? vale ou não a pena? terá mais
benefícios que problemas? São questões a serem pensadas em pesquisas futuras.
79
REFERÊNCIAS
ABEL, Mara. Raciocínio Baseado em Casos – CBR. 2005. Disponível em: <http://inf.ufrgs.br/gpesquisa/bdi>. Acesso em: 14 jun 2009. ASSESPRO. Associação das Empresas Brasileiras de Tecnologia da Informação, Software e Internet/RS. Disponível em: http://www.assespro-rs.org.br>. Acesso em: mar. 2009. BARTIE, Alexandre. Garantia Da Qualidade De Software. São Paulo: Campus, 2002. BASTOS, Anderson. Potencial Do Mercado De Testes De Software . In: Magazine, São Paulo, 29 abr. 2009. Disponível em: <http://www.b2bmagazine.com.br/web/interna.asp?id_canais=4&id_subcanais=19&id_noticia=23895&colunista=1>. Acesso em: 25 out. 2009. BASILI, V. R. Data Collection, Validation, and Analysis , in Tutorial on Models and Metrics for Software Management and Engineering, IEEE Catalog No. EHO-167-7, 1981. BOGNER, A., LITTIG, B., MENZ, W. (ed.) Das Experten-interview Theorie, Methode, Anwendung . Auflage, Wiesbaden, Verlag für Sozialwissenschaften, 2005. GONZALEZ, M, Lima, Termos e relacionamentos em evidência na recuperaçã o de informação .Tese (Doutorado), Universidade Federal do Rio Grande do Sul, 2005. GONZALEZ, M.; Lima, V. L. S. de; Lima, J. V. de. Tools for Nominalization: an Alternative for Lexical Normalization. In: Workshop on comp. proc. of the Portuguese lang. - Written and spoken, 7; Propor, 2006. Proceedings… [S.l.]: Springer-Verlag, 2006. GUSMÃO, C. Revista Engenharia Software Magazine, Soluções para Gerenciamento de Riscos de Projetos, 2008. GUSMÃO, C. Revista Engenharia Software Magazine. Tendências na área de Gestão de Riscos em Ambientes de Desenvolvimento de Software, 2008. IEEE Std 1028, Standard for software reviews and audits . 2008. IEEE Std 1540, IEEE Standard for Software Life Cycle Processes-Ris co Gestão, 2001. KOLODNER, Janet. Case Based Reasoning . San Mateo: Morgan Kaufmann, 1993. LARSON, Ron; FARBER, Elizabeth. Estatística aplicada . 2. ed. São Paulo: Pearson Prentice Hall, 2007.
80 LEE, R. W. CBR Course Home Page , 1996. Disponível em:<[http://www.eps.ufsc.br/~martins/fuzzy/cbr.html]>Acesso em: 20 jun. 2009. MENDES, F., OLIVEIRA, J. GOMES, F Análise de Riscos na Implantação de Melhorias de Processo de Software, 2007. MENEGAZZO, C. Raciocínio Baseado em Casos Aplicado a Diversos Dom ínios de Problema , Dissertação de mestrado Ciência da Computação, UFRGS. 2001. MORAIS, Janiana Berdani Dixon. Técnicas para levantamento de requisitos. Dvmedia Engenharia de Software. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=9151&hl=*brainstorming*>. Acesso em: 24 out. 2009. MYERS, Glenford J. The art of software testing. Revised and updated by Tom. John Wiley & Sons 2. ed. Hoboken, New Jersey: Jonh Wiley & Sons, Inc., 2004. PEREIRA, Reginaldo Souza. Projeto Gestão de Entregas. 2007. Monografia de Especialização em Gerenciamento de Projetos, ESPM, Porto Alegre, 2007. PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge . 4. ed. Pennsylvanya, 2008. QUALITY ASSURANCE INSTITUTE (QAI), 2006, Dallas. CBOK - Guide to the CSTE Common Body of Knowledge. 6.2 e.d, 2006. RAMOS, Josion Neves, FAQBOT - Um Sistema De Raciocínio Baseado Em Casos Com Processamento Linguístico, Monografia graduação do Curso Ciência da Computação, ULBRA, 2008. RIOS, Emerson; Análise de Riscos em projetos de Teste de Software . Alta Books, Rio de Janeiro, 2001. RUSSELL, Stuart; Norvig, Peter. Inteligência Artificial . 2.ed. – Rio de Janeiro. Elsevier, 2004. SALLES JUNIOR, Carlos Alberto Corrêa et al. Gerenciamento de Riscos em projetos. Rio de Janeiro: FGV, 2006. SEBRAE. CRITÉRIOS DE CLASSIFICAÇÃO DE EMPRESAS - ME - EPP. Disponível em: <http://www.sebrae-sc.com.br/leis/default.asp?vcdtexto=4154&%5E%5E>. Acesso em: 24 out. 2009. SOFTWARE ENGINEERING INSTITUTE (SEI). CMMI for development v. 1.2 Technical report, Carnegie Mellon University, Pittsburgh – PA, 2006. SEPRORGS. Sindicato das Empresas de Informática do Rio Grande do Sul. 2009 Disponível em: < http://www.seprorgs.org.br>. Acesso em: mar. 2009.
81 SILVA, Jaine J, HelpDesk com sistema de RBC para as Gerências de Aplicativos da Tecnologia do Banco do Brasil. Especialização em Desenvolvimento Segurança e Qualidade na Internet UFRGS, 2004. TMMi FONDATION, Modelo de Maturidade de Testes Integrado (TMMi). Produzido por TMMi Fundation, 2009. Disponível em: <http://www.tmmifoundation.org> Acesso em: set. 2009. VEENENDAAL, Erik van, POL, Martin, Published in Achieving Software Product Quality, A test Management approach for structured testing , UTN publishers, Den Bosh, The Netherlans, 1997. VEENENDAAL, Erik van, Glossário Padrão De Termos Utilizados Em Teste De Software. International Software Testing Qualification Board, Versão 1.3br, 2007.
82
APÊNDICE A – Checklist Riscos TMMi
ID Risco Check 1. Profissionais de testes não qualificados ���� 2. Ausência de controle e monitoramento do processo ���� 3. Técnicas de revisão não serem realizadas ���� 4. Ausência de comunicação entre as equipes do projeto ���� 5. Ausência de ferramentas apropriadas ���� 6. Ausência de responsáveis para executar o processo ���� 7. Ausência de treinamento de pessoal ���� 8. Ausência de gestão configuração ���� 9. Ausência de avaliação e aderência do processo ���� 10. Ausência de status da revisão com gerência de mais alto nível ���� 11. Ausência de tem processo definido ���� 12. Envolvidos não terem conhecimento no processo ���� 13. Ausência de coleta de informações para melhoria processo ���� 14. Ausência de nível de independência da equipe de teste ���� 15. Ausência de análise de riscos produto ���� 16. Ausência de análise de riscos processo ���� 17. Ausência técnicas de casos de teste a serem utilizados a cada nível do teste ���� 18. Ausência de tipos de teste a serem realizados em cada nível de teste ���� 19. Ausência de critérios de entrada e de saída para cada nível de teste ���� 20. Ausência de padrões de teste ���� 21. Ausência da abordagem de automação em cada nível de teste ���� 22. Ausência de testes de regressão ���� 23. Ausência de manuais (sistema de qualidade) ���� 24. Ausência de apresentações no projeto e/ou em reuniões departamentais ���� 25. Ausência de painel de processos ���� 26. Ausência de um repositório de dados ���� 27. Ausência de indicadores de desempenho do teste ���� 28. Ausência de indicadores de processo de teste ���� 29. Ausência de feedback para o esclarecimento das políticas e objetivos de teste
necessários ����
30. Ausência de estimativa de teste ���� 31. Ausência de número de defeitos encontrados ���� 32. Ausência de porcentagem de detecção de defeitos ���� 33. Ausência de análise dos resultados dos indicadores de desempenho ���� 34. Ausência de Relatório com os indicadores de desempenho para as partes
interessadas numa base periódica
����
35. Ausência de lições aprendidas em versões de qualidade do projeto ���� 36. Ausência de disponibilidade de um ambiente de acordo com os requisitos ���� 37. A disponibilidade da documentação, por exemplo, nota de liberação do teste,
manual do usuário, manual de instalação, etc. ����
38. Um teste de entrada bem sucedido ���� 39. Ausência de nível de prioridade nos defeitos ���� 40. Ausência de na porcentagem de cobertura de cada item do teste, por exemplo,
cobertura do código ou cobertura dos requisitos; ����
41. Ausência de disponibilidade de um relatório sumário do teste aprovado; ���� 42. Ausência de definição os critérios de suspensão e recomeço ���� 43. Ausência do plano de teste comitado ���� 44. Ausência de ferramentas de planejamento do projeto e cronograma; ���� 45. Ausência de ferramentas de estimativas; ���� 46. Ausência de ferramentas de avaliação de risco; ����
83
APÊNDICE B – CheckList Expert Interview
ID Passos Expert Interview Check 1. Desenvolvimento de conjuntos de perguntas. ����
2. Desenvolver lista de entrevistados. ����
3. Determinar calendário. ����
4. Criação checklist de questões a serem questionadas (apêndice A) ����
5. Fazer anotações, palavras chaves durante entrevista. ����
6. Fazer rascunho do documento entrevista. ����
7. Apresentar tudo que foi escrito pelo entrevistador para entrevistado ler e dar feedback.
����
8. Apresentar ao entrevistado os dados coletados. ����
84
APÊNDICE C – Entrevistas
IDENTIFICAÇÃO
Porte Empresa:
Projeto:
Ramo da Atividade:
Terceiriza alguma área de desenvolvimento SW: Qua l?
Entrevistado: Cargo:
Grau Instrução:
Entrevistado Possui certificação? Qua l?
Empresa Possui certificação? Qual?
Automatiza Testes?
Tecnologias Utilizadas:
QUESTÕES
Técnico
1- Qual modelo de processo de teste é utilizado? Qu al?
2- Quais técnicas e tipos de testes são aplicados?
3- Existem estimativas para execução dos testes? Ut iliza Ferramenta? Qual?
4- Existem estimativas para planejamento de teste? Utiliza Ferramenta? Qual?
85 5- Como são utilizados resultados desses dados? Qua l ação é tomada a partir resultados obtidos? 6- É utilizada análise de métricas de teste? Como e la é utilizada? 7- Existe padrão registro de defeito? Qual padrão? Como é feito? 8- Utiliza ferramenta para controle do processo de teste? Qual?
9- São documentados os resultados do teste? Utiliza ferramenta? Qual?
10- É realizada a análise de causa e efeito? Qual a nálise é feita? Como é feita? Qual resultado dessa ação?
11 - É realizada a análise de impacto e cobertura d e teste? Como é feita? Utiliza ferramenta? Se analisado qual a ação tomada? 12- É feita alguma técnica de revisão? Qual? Utiliz a a técnicas em Casos de teste? Planos de teste? Algum outro artefato? 13- São realizadas implementações de melhorias no p rocesso? Se sim, é feita análise do retorno das implantações?Quais foram os retornos? 14- Há existência de um repositório de documentaçõe s do projeto de teste? 14.1 - Como é feita a divulgação dessas documentaçõ es? 14.2- Existe uma base de conhecimento? 15- Utiliza alguma ferramenta especifica para gestã o do conhecimento? Qual? 16- Existe uma equipe para fazer configuração do am biente de teste? 17-O ambiente de teste é separado do ambiente de de senvolvimento?
86 18- Há massa de dados para teste? É gerada massa de dados para cada versão /release? 18.1- Como é armazenada massa de dados? 18.2-A base tem restore ? Se a massa de teste é excluída depois carregada novamente? Atualizada? 19- Ambiente de teste costuma ficar disponível na d ata prevista? 20- O ambiente de teste é próximo ou igual ao ambie nte de produção? 21- Costuma ter problemas com cumprimento dos prazo s estabelecidos? 21.1- Quais problemas? 21.2- Como são resolvidos esses problemas? 22- É utilizada alguma ferramenta de automação de t estes? Se sim, qual? 22.1- Todos os scripts desenvolvidos são utilizados ? 22.2 - A atualização dos scripts é realizada? 22.3 - Há reutilização dos scripts? Organizacional 23- Existe treinamento para profissionais de testes ? 23.1- Os profissionais de teste são treinados na pr ópria empresa? Que tipo de treinamento é feito? 23.2- A empresa busca profissionais especializados no mercado ou a empresa treina? 24- Há rotatividade na equipe de teste? Qual tempo médio de duração desses recursos no projeto?
87 25- Algum membro da equipe de teste detém concentra ção de conhecimento? Gerenciamento de Projetos 26- São armazenadas lições aprendidas de projetos p assados? 26.1- Onde são armazenadas? 26.2-Como são utilizadas? 27- A organização utiliza alguma ferramenta de apoi o à decisão? Qual ferramenta? Qual ação é tomada? 28- É feita reunião periódica da equipe de teste? 29- O líder de teste tem contato com os lideres das outras equipes? 29.1- Em que momento é feito esse contato? 29.2-Para tomar decisões? Que tipo? 29.3-Que ações são tomadas? 30- Analista de teste tem acesso às documentações d o projeto? Externo 31- As equipes do projeto estão alocadas no mesmo e spaço geográfico? 32- Nota-se algum benefício ou dificuldade nesta pr oximidade? Quais? 33- A organização utiliza alguma ferramenta para ge renciamento de riscos?
88
APÊNDICE D – Planejamento Riscos Classificados
Risco Mitigação Contingência
1 Ausência de Técnica de Revisão no processo
Aplicar treinamentos de métodos de revisão a toda equipe de teste, para que assim todos tenham conhecimento.
Criar um checklist com os pontos mais importantes a serem realizados.
2 Ausência técnicas de casos de teste a serem utilizados a cada nível do teste
Criar treinamentos sobre técnicas, estratégias e escopo de testes para cada nível de teste.
No início de cada ciclo, discutir com o gerente ou analista responsável o escopo, e os principais objetivos do ciclo, para depois reforçar com testes exploratórios.
3 Ausência de tipos de teste a serem realizados em cada nível de teste
Reforçar a importância da definição do escopo do teste, visando os riscos para o negócio e sua prioridade.
Reforçar os testes exploratórios com base nos riscos para o negócio.
4 Ausência de critérios de entrada e de saída para cada nível de teste
Definir critérios de entrada e saída de cada nível de teste durante o planejamento.
Definir que cada nível de teste, por si só, já pré-estabelece entradas e saídas, mesmo q faltem informações sobre o negócio.
5 Ausência de padrões de teste Realizar reuniões com a
equipe para saber quais as necessidades, ou deficiências, e assim levantar as tarefas e colocar prazo para a criação de padrões.
Definir e aplicar um padrão mínimo de testes que satisfizesse os requisitos mais importantes de padronização a ser utilizada no processo.
6 Ausência da abordagem de automação em cada nível de teste
Avaliar a real necessidade de automatizar teste e que nível deve ser automatizado.
Executar testes automatizados funcionais.
7 Ausência de testes de regressão Analisar se demanda
necessita teste de regressão, se precisar, inserir no planejamento a execução desse teste.
Aplicar testes automatizados.
8 Ausência de indicadores de desempenho dos profissionais de teste
Utilizar ferramentas para obter números de desempenho do profissional.
Realizar reuniões de acompanhamento.
9 Ausência de indicadores de processo de teste
Criar métricas para desempenho do teste.
Utilizar métricas existentes para medir quantidade de defeito.
10 Ausência de disponibilidade de um ambiente de acordo com os requisitos
Obter gerência de configuração, onde um responsável garantirá que o ambiente esteja de acordo com os requisitos.
Validar o ambiente antes de execução os testes.
11 Ausência de ferramentas de planejamento do projeto e
Analisar ferramentas no mercado que mais se
Utilizar ferramenta de planejamento free ou utilizar
89
cronograma; adaptem aos projetos da empresa, e implantar ferramenta escolhida.
Excel.
12 Ausência de ferramentas de estimativas
Analisar ferramentas no mercado que mais se adapte aos projetos da empresa, e implantar ferramenta escolhida.
Utilizar planilha Excel para realizar estimativas de teste.
13 Ausência de ferramentas de avaliação de risco
Utilizar/ criar ferramenta que auxilie na avaliação
Utilizar um checklist para avaliar riscos.
14 Mesmo ambiente de testes e desenvolvimento
Utilizar servidor somente para testes
Construtores comunicarem ao responsável da equipe de teste as alterações que está inserindo na versão.
15 Funcionalidade nunca antes testada
Realizar reuniões de kick off, revisar documentação de teste.
Alocar membro mais experiente da equipe para testar.
16 Número excessivo de métricas Realizar levantamento das necessidades de métricas no processo.
Verificar todas as métricas existentes e selecionar as mais importantes.
17 Ausência de Teste automatizado Analisar qual a real necessidade de automatizar e que benefícios isso traria ao processo.
Alocar número maior de recursos.
18 Equipe de testes identificar número excessivo de erros
Realizar planejamento de teste para utilização de diversas técnicas de teste.
Automatizar funções mais usuais de teste, pois estas podem ser utilizadas nos testes de regressão fazendo com que a equipe de teste possa identificar problemas com maior velocidade.
19 Mudança contínua de requisitos Permanentes verificações de documentos de teste
Permanentes validações no sistema.
20 Ausência teste de usabilidade Realizar planejamentos
de tipos e técnicas de testes que devem ser utilizadas a cada nível de teste
Intensificar os testes funcionais
21 Scripts de testes não serem atualizados
A cada demanda de testes, revisar os scrips e avaliar se podem ser atualizados e reutilizados.
Testar com os scripts existentes e executar testes manuais.
22 Scripts de testes não serem reutilizados
A cada demanda de teste, revisar os scripsts existentes e verificar a real necessidade de criar um script.
Criar bases para esses scripts serem revisados para analisar possíveis reaproveitamentos.
90
23 Ausência ferramenta de apoio à decisão
Levantar informações com base no conhecimento da equipe e no histórico de métricas de projetos anteriores e implementar reuniões de apoio às decisões.
Levantar questões pertinentes em reuniões da equipe, anotando os itens discutidos para depois aplicar as decisões.
24 Dependência da equipe de testes com a gestão de configuração.
Dar autonomia à equipe de testes para manipular os dados e o ambiente.
Responsável pela equipe de teste manter contato com pessoa responsável pela gestão de configuração.
25 Ausência teste de aceitação durante desenvolvimento
Inserir no processo o aceite do cliente na fase de desenvolvimento (envio de protótipo).
Esclarecer todas as dúvidas com o cliente e documentá-las.
26 Orçamento de teste limitado Utilizar ferramentas free e pessoal experiente (se possível), enfatizar revisões (mesmo que informais) e os testes unitários.
Definir um escopo de teste baseado em riscos do negócio, e criar documentos genéricos para testar as principais funcionalidades do sistema.
27 Rotatividade na equipe de testes Envolver e motivar a equipe, discutir sobre treinamentos ou algum outro fator, como por exemplo, horário flexível, com a equipe do RH. Incentivar a disseminação de conhecimento para minimizar possíveis faltas de pessoas importantes. Criar um processo de feedback mais frequente sobre desempenho ou dúvidas, sugestões, reclamações individualmente ou em equipe.
Possuir outros recursos com boa experiência, possíveis de suprir eventuais perdas de integrantes da equipe.
28 Ausência de contrato com regras definidas a respeito da qualidade do software
Fazer contrato SLA com as definições de qualidade do software.
Criar documentos de esclarecimentos de dúvidas quanto à qualidade e enviar ao cliente.
29 Divulgar informações verbalmente
Definir padrões de comunicação (solicitações de especificações aos fornecedores), (preenchimento de documentos).
Enviar e-mail com as informações que foram passadas verbalmente.
30 Ausência de painel processos Realizar apresentação do painel de processos à equipe e deixar em um
Imprimir painel de processo e distribuir entre equipe.
91
lugar visível de toda a equipe.
Inserir imagem do painel como papel de parece de cada computador dos integrantes da equipe de teste.
31 Não haver reuniões somente da equipe de testes
Planejar reuniões da equipe para discutir sobre demandas e processo.
Começar a realizar reuniões.
32 Ausência treinamento de teste (teoria, conceito do processo)
Elaborar treinamentos e grupo de estudos na equipe.
Instruções diretas aos envolvidos.
33 Ausência de reunião de kickoff Inserir a reunião no processo.
Realizar uma reunião de alinhamento do projeto, mostrando cronograma atualizado, entregáveis, metas e prazos.
34 Excesso de pontos de função (equipe de testes absorver mais esforço que pode)
Planejar demandas criar back log de demandas.
Utilizar mais recursos, executar testes automatizados.
35 Ausência de status da revisão com gerência de mais alto nível
Inserir no processo revisões de documentos de processo para gerência.
Aplicar Peer Review entre analistas de testes.
36 Cronograma de Teste Enxugados Sempre que possível utilizar ferramentas de processo e execução de teste.
Alocar mais recursos.
37 Ausência de reunião de “post-mortem"
A cada término de projeto ou demanda, reunir os participantes para discutir o que teve de bom e ruim.
Armazenadas lições aprendidas da demanda.
38 Ausência de análise de riscos produto
Coletar informações diretamente com o cliente, sobre o tipo de usuários do sistema, sobre o próprio negócio, etc., depois de feito isso, criar um documento para o cliente validar se procedem aos riscos identificados, e a partir desse aceite por parte do cliente, deve-se fazer a priorização.
Criar checklist e realizar reuniões p/ levantamento de possíveis riscos no produto e inclusão nos testes.
39 Ausência de análise de riscos processo
Identificar os riscos no início do projeto, a partir de lições aprendidas em projetos passados.
Criar um checklist com possíveis riscos do projeto.
40 Ausência de avaliação e aderência do processo
Contratar um QA.
Nomear responsável que avalie aderência do processo.
41 Ausência de processo definido Definir processo.
Estudar sobre processo de teste.
92
42 Envolvidos não terem conhecimento no processo
Realizar treinamentos do processo de teste.
Dar instruções diretas sobre processo de teste.
43 Ausência de coleta de informações para melhoria processo
Realizar pesquisas com equipe de teste.
Questionar a equipe de testes sobre processo nas reuniões.
44 Ausência de nível de independência da equipe de teste
Definição de papéis e responsabilidades da equipe de teste.
Reponsável pela equipe de teste deve passar a tomar decisões, agilizando o processo.
45 Apenas utilizar instruções diretas como forma de repassar conhecimento
Realizar treinamentos à distancia ou presenciais.
Utilizar manuais existentes no processo.
46 Ausência de análise das melhorias implantadas
Após implantação de melhoria, obter feedback das pessoas impactadas pela melhoria.
Fazer reunião com a equipe para falar sobre o assunto, obter opinião das melhorias realizadas.
47 Ausência de uma base de conhecimento
Armazenar conhecimento adquirido em uma base de dados.
Utilizar manuais existentes no processo.
48 Ausência de estimativa de teste Analisar ferramentas e métricas e implantá-las ao projeto.
Se utilizar ferramenta de teste, utilizar métricas da própria ferramenta. Medir tempo através do tempo de construção do software.
49 Ausência de Percentagem de detecção de defeitos
Utilização ferramenta de testes.
Responsável pela equipe de teste deve avaliar manualmente os defeitos encontrados.
50 Ausência de análise dos resultados dos indicadores de desempenho
Utilizar ferramenta de teste.
Nomear responsável para realizar análise dos resultados.
51 Ausência de relatório com indicadores de desempenho para as partes interessadas numa base periódica
Analisar relatórios de indicadores de desempenho baseados nas métricas estabelecidas no processo.
Utilizar ferramentas que gerem automaticamente relatórios de indicadores de desempenho.
52 Ausência de utilização de lições aprendidas em versões de qualidade do projeto
Analisar lições aprendidas e comunicar a todos os membros do projeto o local armazenamento desses dados
Comunicar aos membros do projeto a existência desses dados.
53 Ausência de disponibilidade de um relatório sumário do teste aprovado
Planejar relatórios com os testes aprovados.
Responsável pela equipe de teste verificar demanda a ser testada antes da execução dos testes.
54 Ausência de definição os critérios de suspensão e recomeço
Aplicar critérios de suspensão e recomeço de testes seguindo
Informar no plano de teste os critérios de suspensão e recomeço.
93
padrões como IEEE 829.
55 A disponibilidade da documentação, por exemplo, nota de liberação do teste, manual do usuário, manual de instalação, etc.
Inserir no processo tipos de documentação que devem ser geradas e local que está disponível.
Criar relatório e armazenar base de dados.
56 Ausência de na porcentagem de cobertura de cada item do teste, por exemplo, cobertura do código ou cobertura dos requisitos;
Planejar o uso de ferramentas de teste que gerem porcentagem de cobertura de teste automaticamente.
Utilizar ferramentas de teste que gerem porcentagem de cobertura de teste automaticamente.
57 Falta de documentação Analisar o processo e identificar documentos que devem ser gerados durante o processo.
Entrar em contato com outros lideres de equipe e com cliente.
58 Falta de estimativas elaboradas pela equipe de testes
Equipe de testes estudar métricas que melhor se adaptem ao processo e testá-las
Responsável pela equipe de teste revisar as métricas geradas antes de iniciar a execução dos testes.
59 Falta de análise de métricas Realizar uma análise das métricas necessárias para tipo de projeto de teste.
Utilizar ferramenta que gere métricas dos testes.
60 Excesso de métricas, documentações e não utilização das mesmas.
Reavaliar as métricas e documentações existentes e definir o conjunto que mais se adequar para a utilização.
Realizar uma reunião para escolher as melhores e mais importantes e utilizar o mínimo possível sem comprometer o projeto e o processo de teste.
61 Ausência de contato com cliente para retirar dúvidas quanto a regras de negócio.
Criar padrões de comunicação com cliente, mandar e-mail, telefone, teleconferência, MSN, etc.
Deslocar-se até cliente.
62 Massa de dados ficarem no domínio do cliente
Utilizar backup com massa de dados.
Criar nova massa de dados.
63 Cliente não ter ciência do processo de teste
Manter no cronograma com os stakeholders, reuniões semanais e ciclo de treinamento.
Agendar o quanto antes um treinamento presencial com o cliente(s) sobre processo de teste (importância dos testes para garantir a qualidade software, estimativas teste, teste de regressão, métricas de remoção de defeitos).
94
APÊNDICE E – Questionário Verificação Melhoria Processo de Teste
Marque as questões com um X a nota de 0 a 5 para a melhoria no processo de teste em seu projeto após a utilização do protótipo contendo base de conhecimento em riscos no processo de teste de software. 1- Os riscos contidos no protótipo condiziam com a realidade de seu projeto?
0 1 2 3 4 5
2- A utilização dos riscos auxiliou no planejamento de testes?
0 1 2 3 4 5
3- As soluções (mitigações e contingências) contidas no protótipo auxiliaram
para melhoria do processo?
0 1 2 3 4 5
4- A automação da análise de risco melhorou o processo?
0 1 2 3 4 5
5- O protótipo influenciou a tomada de decisões no projeto?
0 1 2 3 4 5
Comentários:
_______________________________________________________________________________________________________________________________________________________________________________________________________
95
APÊNDICE F – Caso de Uso
Descrição da situação O estudo de caso é sobre protótipo de um sistema RBC (Raciocínio baseado em casos) – Um analisador de risco para utilização em processo de teste de software. Este ciclo irá compreender as fases de cadastro dos casos na base de dados, busca pelos casos mais similares da base, edição do caso e impressão de relatórios. R1. O protótipo deve permitir o cadastro de projeto. R2. O protótipo deve permitir o cadastro do caso por um especialista. R3. O protótipo deve permitir buscar listagem dos casos mais similares na base de caso. R4. O protótipo deve permitir que especialista possa alterar a descrição do caso. R5. Um caso deve conter: descrição do risco, descrição da mitigação, descrição da contingência e a classificação do risco. R6. O protótipo deve permitir a impressão de dois relatórios, um por categoria e outro por projeto.
96 Regras do negócio-Inclusão de Projeto Projeto (RN01): Descrição Botão Inclui Projeto (RN02): Descrição Deverá incluir o projeto na tabela Projetos Regras do negócio-Inclusão dos Casos na Base Categoria do Risco (RN03) Descrição A categoria de risco foi definida de acordo com sugestão do PMI, (Categorias: Técnica, gerenciamento de projeto, organizacional e externo). Estas descrições de categorias devem estar em uma combo na tela de inclusão dos casos, deve ser incluída na tabela categoria, ser carrega no evento load da tela de inclusão dos casos. Projeto (RN04) Descrição O Campo projeto foi inserido, assim como a categoria, para recuperar padrões na base de casos, o objetivo deste campo é selecionar em uma combo com nome do projeto. Deve ser incluído pela tabela projeto (Inclusão de projetos), deve carregar no evento load da tela de inclusão de casos. Risco (RN05) Descrição O campo risco deve utilizar uma textbox, onde o usuário (especialista) vai informar a descrição do risco que quer armazenar na base de casos. Mitigação (RN06) Descrição O Campo mitigação deve utilizar uma txtbox, onde o usuário (especialista) irá informar, a mitigação serve para que o especialista possa tentar diminuir o impacto do risco ou até mesmo evitar a ocorrência. Contingência (RN07) Descrição O Campo contingência deve utilizar uma txtbox, onde o usuário (especialista) irá informar, a contingência serve para que em determinada ação de recuperação quando da concretização de um risco ou ocorrência de um determinado problema. Será sempre acionado quando o risco se transformar em um problema. Probabilidade (RN08) Descrição
97 O campo probabilidade deve utilizar uma combo, onde o usuário (especialista) irá selecionar as opções (Alta, média, baixa). Deve ser incluída pela tabela de casos. Alta deve ter peso 0,4, média 0,3 e baixa 0,2. Impacto (RN09) Descrição O campo Impacto deve utilizar uma combo, onde o usuário (especialista) irá selecionar as opções ( Alta, média, baixa). Deve ser incluída pela tabela de casos. Alta deve ter peso 0,4, média 0,3 e baixa 0,2. Classificação (RN10) Descrição O campo classificação deve utilizar uma label, onde o protótipo deve calcular a seleção (cboPorbabilidade x CboImpacto) – buscando os pesos selecionados pelo usurário ( especialista), e apresentar a classificação.Conforme quadro abaixo.
Entre 0,05 e 0,08 Baixa
Serão classificados com graduação “Baixa”. Planos de contingência e mitigação devem atuar de forma a preveni-los.
Entre 0,09 e 0,12
Média
Serão classificados com graduação “Média”, tendo a necessidade de controle e monitoramento periódico. Planos de contingência e mitigação devem atuar de forma a preveni-los.
Superior a 0,12
Alta
Serão classificados com graduação “Alta” e requerem atenção especial para controle e monitoramento constante. Estratégias de contingência e mitigação devem procurar prevenir eficientemente estes riscos.
Botão Inclui Caso (RN11): Descrição Deve executar o sistema FORMA (Lematização) e após incluir o caso da na base de casos. Criar uma classe pública para o FORMA. Etiquetas (RN12): Descrição Somente validar as seguintes etiquetas:
• Verbos: _VA, _AP, _VB; • Substantivos: _SU; • Pronomes: _PL, _PD, _PI; • Adjetivos: _AJ • Advérbios: _AV.
Regras do negócio-Busca dos Casos na Base Executar RN3 e RN4 para recuperação de padrões
98 Risco (RN13) Descrição O campo risco, deve utilizar uma textbox, txtBuscaRisco, onde o usuário (especialista) vai informar a descrição do risco que quer buscar na base de casos. Botão Busca Caso (RN14): Descrição Deve chamar a classe FORMA (Lematização) e após clicar no botão busca Caso. - Ainda para recuperar padrões, executar consulta SQL - Utilizar Algoritmo de similaridade (Técnica vizinho mais próximo), validado conforme RN10.
- Os pesos para cada token são inseridos diretamente na tabela de casos, o usuário na poderá alterar esses pesos para que assim seja possível avaliar de forma igualitárias todos os projetos. Os pesos a serem inseridos são:
• Verbos: _VA, _AP, _VB =08 • Substantivos: _SU = 10 • Pronomes: _PL, _PD, _PI = 07 • Adjetivos: _AJ = 05 • Advérbios: _AV = 03
- A busca deve ser realizada em área de memória e não diretamente na base, isto deve manter a performance do protótipo. - Deve apresentar os 10 casos mais similares encontrados, ordenados pelo mais similar, devem ser apresentados em uma grid. Menu sobre (RN15): Deve conter informações sobre risco, mitigação e contingência. Regras do negócio-Editar os Casos na Base Executar RN1, RN2, (RN10 a RN12). – Busca caso similar Grid (RN16): Descrição Deve conter os 10 casos mais similares, no evento doble_click na grid o protótipo deve enviar o código do caso para tela de inclusão de casos, o usuário (especialista) poderá editar os campos. Se editado - Remover as etiquetas e executar (RN11)
99
CASOS DE USO Sumário : Entrar | Cadastra | Risco (Ctrl + R)
Entrar | Cadastra | Projeto (Ctrl + P) Entrar | Consulta | Risco (Ctrl + C) Entrar | Sobre (Ctrl + S) Descrição para este caso de uso: Analisador riscos em processo de teste. Regras de Negócio envolvidas: Para inclusão Projeto: (RN1 a RN2) Para inclusão: (RN3 a RN12) Para Busca: RN3, RN4, (RN10 a RN12). Para Editar: RN3, RN4, (RN10 a RN12), RN14 Para Informações: RN15 Ator : Usuário (Especialista) Pré-condições: O usuário entrar no sistema. Fluxo Principal: O usuário deve cadastrar caso na base E / OU O usuário deve buscar caso na base. Fluxo Alternativo: Se o projeto ainda não estiver sido cadastrado no sistema, o responsável deve entrar no banco de dados e cadastrá-lo. Fluxo de Exceção: Se o usuário não informou todos os campos, deve mostrar msgbox solicitando preenchimento.