Um estudo sistem atico sobre ferramentas de … · iii. Lista de Figuras ... [Adler et al., 1998]...
Transcript of Um estudo sistem atico sobre ferramentas de … · iii. Lista de Figuras ... [Adler et al., 1998]...
UNIVERSIDADE FEDERAL DE GOIAS – UFG
CAMPUS CATALAO – CaC
DEPARTAMENTO DE CIENCIA DA COMPUTACAO – DCC
Bacharelado em Ciencia da Computacao
Projeto Final de Curso
Um estudo sistematico sobre ferramentas degerenciamento de riscos para Projetos de Software
Autor: Marcia Ribeiro dos Santos
Orientador: Luanna Lopes Lobato
Co-orientador: Thiago Jabur Bittar
Catalao - 2011
Marcia Ribeiro dos Santos
Um estudo sistematico sobre ferramentas de gerenciamento de riscos para
Projetos de Software
Monografia apresentada ao Curso de
Bacharelado em Ciencia da Computacao da
Universidade Federal de Goias Campus Catalao
como requisito parcial para obtencao do tıtulo de
Bacharel em Ciencia da Computacao
Area de Concentracao: Engenharia de Software
Orientador: Luanna Lopes Lobato
Co-orientador: Thiago Jabur Bittar
Catalao - 2011
R. dos Santos, Marcia
Um estudo sistematico sobre ferramentas de gerenciamento de riscos
para Projetos de Software/Luanna Lopes Lobato- Catalao - 2011
Numero de paginas: 51
Projeto Final de Curso (Bacharelado) Universidade Federal de Goias, Campus
Catalao, Curso de Bacharelado em Ciencia da Computacao, 2011.
Palavras-Chave: 1. Linha de produto de software. 2. Ferramentas. 3. Riscos.
Marcia Ribeiro dos Santos
Um estudo sistematico sobre ferramentas de gerenciamento de riscos para
Projetos de Software
Monografia apresentada e aprovada em de
Pela Banca Examinadora constituıda pelos professores.
Thiago Jabur Bittar – Presidente da Banca
Professor 1
Professor 2
AGRADECIMENTOS
Agradeco primeiramente a Deus, por me guiar e dar a forca e determinacao para poder
concluir mais uma etapa da minha vida. Agradeco tambem meus pais e familiares por
acreditar e me encorajar em cada dificuldade.
Agradeco ao meu namorado Jean pelo incentivo, paciencia e ajuda para conclusao do
meu trabalho.
Aos meus amigos de turma, que se tornaram para mim uma famılia.
Aos meus orientadores Luanna e Thiago, que me guiaram com seus conhecimentos e
experiencias para que eu fizesse um bom trabalho e a todos os outros professores do curso
de Ciencia da Computacao que colaboraram com a minha formacao.
Obrigada.
”Voce pode encarar um erro como uma besteira a ser esquecida, ou como um resultado
que aponta uma nova direcao”
Steve Jobs
RESUMO
dos Santos, M. Um estudo sistematico sobre ferramentas de gerenciamento
de riscos para Projetos de Software. Curso de Ciencia da Computacao, Campus
Catalao, UFG, Catalao, Brasil, 2011, 51p.
As atividades de gerenciamento de riscos tornaram-se cada vez mais necessarias du-
rante as etapas que compoem o desenvolvimento de software. Tal fato tem se mostrado
real devido a complexidade dos sistemas de softwares, em que funcionalidades complexas
tem sido impostas pelo mercado. No entanto, nem todas as organizacoes tem adotado
praticas especıficas para executar o gerenciamento de riscos em seus projetos, em vezes
porque tal necessidade e desconhecida pelos gerentes e em outras por nao encontrarem
ferramentas que possam os apoiar nessa tarefa. Dessa forma, este trabalho tem como
objetivo fornecer um maior conhecimento sobre gerencia de riscos, apresentando praticas
que devem ser executadas durante o desenvolvimento de software. Assim sendo, foi de-
senvolvida uma revisao sistematica sobre ferramentas de gerenciamento de riscos para
projetos de software, de modo a identificar os artigos disponıveis na literatura e verificar
a qualidade dos mesmos. A revisao foi realizada buscando-se por estudos no contexto de
Desenvolvimento de Sistemas Individuais e Linha de Produto de Software, como meio de
alinhar os interesses da Engenharia de Software no que tange as tecnicas de desenvolvi-
mento de software. Como resultados sao apresentadas caracterısticas relevantes para o
desenvolvimento de uma nova ferramenta de gerenciamento de risco, com base nas carac-
terısticas identificadas na literatura.
Palavras-Chaves: Linha de produto de software, Ferramentas, Riscos.
i
Sumario
1 Introducao 1
1.1 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Metodologias de Desenvolvimento 3
2.1 Sistemas Individuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Ferramentas de Gerenciamento de Riscos 8
3.1 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Metodo Sistematico 11
4.1 Descrevendo o Metodo Sistematico . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Estrategia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Strings de busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Selecao de Estudos . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Questoes de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Estudo de Avaliacao da Qualidade . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Conducao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Rodadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.2 Extracao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Divulgacao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.1 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Resultados 19
5.1 Criterios de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Respostas as questoes de pesquisa . . . . . . . . . . . . . . . . . . . . . . . 20
6 Discussao 38
6.1 Principais Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1.1 O que deve ser considerado . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ii
6.3 Licoes Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4 Limitacoes do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Conclusao 42
7.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Referencias 43
Apendices 45
A Fontes 45
B Estudos 48
C Fatores de Risco 51
iii
Lista de Figuras
2.1 Comparacao de custos e numeros de sistemas desenvolvidos em SSD e SPL
- Figura adaptada da original por [Pohl et al., 2005]. . . . . . . . . . . . . 5
2.2 Framework da Engenharia de linha de produto de software - Figura adap-
tada da original por [Pohl et al., 2005]. . . . . . . . . . . . . . . . . . . . 6
3.1 Modelo de Ferramenta FMEA - Figura adaptada da original por Toledo,
J.C. e Amaral, D.C. (2006). . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Strings de busca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Questoes de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Rodadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Criterios de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Etapas da Gestao de Riscos do Software - Figura adaptada da original por
Barry W. Boehm (1991). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Matriz de analise do nıvel de risco - Figura adaptada da original por
[Adler et al., 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
iv
Lista de Tabelas
4.1 Criterios de Inclusao e Exclusao . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Resultado de avaliacao dos estudos em relacao as questoes de qualidade. . . 34
5.2 Artigos Selecionados pela SR . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1 Maquinas de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2 Conferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.3 Journals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.1 Artigos Selecionados pela SR . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.1 Resultado de avaliacao dos estudos em relacao as questoes de qualidade. . . 51
v
Capıtulo 1
Introducao
Com a crescente demanda de mercado em se produzir mais em menor tempo e o
aumento das exigencias de qualidade por parte dos usuarios dos sistemas, ve-se a neces-
sidade em utilizar meios onde o conhecimento e o trabalho possam ser reutilizados. A
complexidade nos sistemas aumenta a possibilidade de riscos surgirem, decorrentes do
desenvolvimento de software, e interferirem no andamento do projeto, tornando cada vez
mais importante a pesquisa sobre gerenciamento de riscos.
Ferramentas de gestao de riscos (Risk Management - RM) sao criadas de modo a
solucionar problemas encontrados nos projetos de software e sao criadas no contexto de
projetos de desenvolvimento de software unico. No entanto, para Linha de Produto essas
nao sao tao abordadas.
Por isso a pesquisa voltada para desenvolvimento individual se torna importante para
o desenvolvimento de linha de produtos de software porque muitas etapas do desenvolvi-
mento de projetos sao geridas da mesma forma, com adicao da particularidade do reuso
e a variabilidade abordados na Linha de Produto de Software (Software Product Line -
SPL).
1.1 Objetivos do Trabalho
O objetivo deste trabalho e capturar, de uma maneira sistematica, o cenario atual
das ferramentas de gerenciamento de riscos para desenvolvimento de projetos de software
visto as caracterısticas apresentadas pelas metodologias de desenvolvimento de software,
e a necessidade de pesquisas e projetos, com a magnitude de uma revisao sistematica,
voltados a gerencia de riscos, seja em Desenvolvimento de Sistemas Individuais (Single
System Development - SSD) ou em SPL.
O resultado da Revisao Sistematica (Systematic Review - SR) ajudara os profissionais
da area a trabalhar e lidar com diversas situacoes de risco que podem ocorrer durante o
desenvolvimento de um projeto de software. Poucos estudos e trabalhos focam na gestao
1
de riscos, principalmente voltados a SPL, tornando necessario considerar o estudo de
diferentes metodologias para desenvolvimento de software. SPL e SSD sao revisados de
modo a orientar na construcao de ferramentas que atendam as necessidades impostas
por uma SPL e ainda contemple as principais necessidades do mercado. Dessa forma, a
proposta da nova ferramenta deve englobar as particularidades de uma SPL, de modo que
a gestao dos riscos atinja seu objetivo na metodologia SPL, que e gerenciar e reduzir os
riscos de forma que estes nao atrapalhem o cronograma e qualidade do produto final.
Este trabalho esta organizado da seguinte forma, no capıtulo 2 sao apresentados os
conceitos relacionados as metodologias de desenvolvimento de software em estudo neste
trabalho. No capıtulo 3 sao descritos os conceitos sobre gerenciamento de riscos em
projetos de software. No capıtulo 4, e apresentado as fases seguidas para realizacao da
revisao sistematica sobre ferramentas de gerenciamento de riscos em desenvolvimento
de software. Nos capıtulos 5 e 6, sao mostrados os resultados obtidos com a revisao
sistematica, bem como uma discussao sobre o trabalho desenvolvido. E, por fim, no
capıtulo 7, a conclusao e apresentada.
2
Capıtulo 2
Metodologias de Desenvolvimento
Uma metodologia de desenvolvimento de software tem o intuito de detalhar os pas-
sos do processo a serem seguidos, utilizando um padrao como objetivo pre-estabelecido,
no qual se garante a qualidade nos produtos gerados, bem como cumprimento de prazos,
suprindo as necessidades impostas pelo cliente. A seguir, sao apresentadas duas metodolo-
gias importantes para o estudo de desenvolvimento de softwares, que sao a base para o
desenvolvimento desta pesquisa.
2.1 Sistemas Individuais
Metodologia de sistemas individuais e o metodo tradicional de desenvolvimento de
projetos de software, sendo baseado na utilizacao de processos para desenvolvimento de
sistemas individuais, com foco nas necessidades de um unico cliente.
Segundo [Pressman, 2006], toda organizacao de engenharia de software deveria descr-
ever um conjunto de atividades de arcabouco para seus processos. Mas a caracterıstica
principal das metodologias atuais e que elas sao divididas em etapas ou fases bem definidas
e documentadas apos seu termino, e independente do modelo a ser seguido, os engenheiros
de software tem tradicionalmente escolhido um arcabouco generico que inclui atividades
como: comunicacao, planejamento, modelagem, construcao e implantacao, que sao com-
plementadas por atividades auxiliares como acompanhamento e controle do projeto de
software, gestao de riscos, revisoes tecnicas, gestao de reuso e outros.
O embasamento maior em metodologias tradicionais e feito na analise e no projeto
que mantem tudo em documentos, tornando esta metodologia mais lenta para mudancas.
Para Pressman, a engenharia de software e dividida em camadas:
• Ferramentas: fornecem apoio automatizado ou semi-automatizado para o processo
e para os metodos.
3
• Metodos: fornecem a tecnica para construcao do software. Abrange tarefas como
comunicacao, analise de requisitos, modelagem do projeto, e outros;
• Processos: alem de alicerce da engenharia de software, formam a base para controle
gerencial de projetos de software e estabelece o contexto no qual os metodos tecnicos
sao aplicados, os produtos de trabalho como modelos, os documentos e outros, sao
produzidos, a qualidade e assegurada e as modificacoes sao adequadamente geridas;
• Foco na qualidade: qualquer abordagem de engenharia deve se apoiar no compro-
misso de qualidade. Gestao de qualidade leva ao desenvolvimento de abordagens
cada vez mais efetivas para engenharia de software.
O foco principal das metodologias tradicionais, que sao as de desenvolvimento unico,
e a previsibilidade dos requisitos do sistema, que traz a grande vantagem de tornar os
projetos completamente planejados, facilitando a gerencia do mesmo, caracterizando o
processo como bastante rigoroso, [Oliveira et al., 2004]. Como exemplos de modelos de
processo de software, podem ser citados:
• Modelo em cascata: sugere uma abordagem sistematica e sequencial para o desen-
volvimento de softwares, comecando pela comunicacao com o cliente, planejamento,
modelagem, construcao e implantacao do sistema;
• Modelo incremental: dividido em modelo incremental, que combina elementos do
modelo em cascata de forma iterativa, e modelo RAD (Rapid Application Develop-
ment), que enfatiza um ciclo de desenvolvimento curto;
• Modelos evolucionarios: sao iterativos e caracterizados de forma a permitir aos
engenheiros de software desenvolver versoes cada vez mais completas do software,
sendo subdividido em prototipagem, espiral, desenvolvimento concorrente;
• Modelo especializado de processo, que tem caracterısticas de um ou mais mode-
los convencionais, alem de ser subdividido em modelo baseado em componentes e
metodos formais.
2.2 Linhas de Produto de Software
“Uma linha de Produto de Software e um conjunto de sistemas que usam soft-
ware intensivamente, compartilhando um conjunto de caracterısticas comuns
e gerenciadas, que satisfazem as necessidades de um segmento particular de
mercado ou missao e que sao desenvolvidos a partir de um conjunto comum de
ativos principais e de uma forma preestabelecida” [Clements e Northrop, 2001].
4
Baseado em reutilizacao dos artefatos, os pontos comuns e variaveis da SPL sao estab-
elecidos, alem das variaveis internas e externas definidas pela equipe de desenvolvimento,
sendo que variabilidade externa e a variabilidade visıvel ao cliente que pode escolher as
variaveis que ele precisa, e a variabilidade interna e a variabilidade do conjunto de obje-
tos que e invisıvel ao cliente, ja que se tratam de razoes tecnicas ou relacoes de artefatos
variaveis, como exemplo, testes, implementacao e instalacao.
A documentacao destes e feita, e assim sao verificados os possıveis produtos a serem
gerados a partir da linha. Com isso, possibilita-se o desenvolvimento em larga escala,
o que garante o ganho em relacao ao tempo na entrega e maior qualidade dos produtos
(sistemas). Consequentemente se aumenta a lucratividade, pois reusando partes definidas
na arquitetura da linha para varios produtos, o desenvolvimento de produtos e facilitado,
a medida que aumenta o numero de produtos instanciados da linha [Pohl et al., 2005].
Na figura 2.1 e mostrado o grafico da comparacao entre os custos e numeros de sistemas
desenvolvidos em SPL e SSD. SPL e uma abordagem que se concentra na reutilizacao
combinando conceitos de plataformas e customizacao em massa [Pohl et al., 2005].
A vantagem de SPL sobre a metodologia SSD e percebida a partir do terceiro desen-
volvimento de software a diante, pois, o custo inicial para o desenvolvimento de uma SPL
e elevado em comparacao a SSD, por conta do tempo e investimentos necessarios inicial-
mente para isso. O tempo de entrega dos sistemas desenvolvidos acaba se tornando menor
devido a facilidade de desenvolvimento usando os componentes comuns a toda linha de
produtos. Alem dos custos com manutencao e esforcos serem reduzidos [Pohl et al., 2005].
Figura 2.1: Comparacao de custos e numeros de sistemas desenvolvidos em SSD e SPL -
Figura adaptada da original por [Pohl et al., 2005].
Para garantir que a partir da SPL se desenvolva produtos de qualidade e que aten-
5
dam os compromissos de escopo, prazo e custo e necessario evitar os riscos que podem
acontecer durante todo o desenvolvimento do projeto, maximizar a probabilidade e as con-
sequencias de eventos positivos e minimizar a probabilidade e consequencias que eventos
adversos possam trazer aos objetivos do projeto [PMI, 2004]. Na figura 2.2 e apresentado
o framework para a engenharia de linha de produto de software, onde sao destacadas as
etapas de engenharia de domınio e engenharia de aplicacao, proposto por Weiss e Lai.
Figura 2.2: Framework da Engenharia de linha de produto de software - Figura adaptada
da original por [Pohl et al., 2005].
Na etapa de engenharia de domınio (letra B na figura 2.2), sao definidos os artefatos
comuns e variaveis que estarao presentes na linha de produto, os quais constituirao os
produtos que serao gerados. A engenharia de aplicacao (letra A na figura 2.2) reusa os
artefatos gerados na engenharia de domınio produzindo artefatos da aplicacao. A partir
da engenharia da aplicacao e possıvel instanciar esses artefatos gerando os produtos que
estao presentes ao domınio da linha de produto. Segundo [Pohl et al., 2005], entre as
razoes da utilizacao de SPL, podem se destacar:
• Reducao de custos de desenvolvimento;
• Melhoria da qualidade;
• Reducao do tempo para entrega do produto;
• Reducao do esforco de manutencao;
6
• Melhorar a estimativa de custo;
• Mais facil lidar com a evolucao da linha de produto;
• Maior satisfacao do cliente.
O Objetivo deste trabalho e verificar, de uma maneira sistematica, qual o cenario atual
das ferramentas de gerenciamento de riscos para desenvolvimentos de projetos de software
visto as caracterısticas apresentadas pelas metodologias de desenvolvimento de software
e baseado na necessidade em se ter gerenciamento de riscos durante o desenvolvimento de
projetos, seja em SSD ou em SPL.
7
Capıtulo 3
Ferramentas de Gerenciamento de
Riscos
“O risco de um projeto e um evento ou condicao incerta que, se ocorrer, tera
um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como
tempo, custo, escopo ou qualidade.” [PMI, 2004].
Tanto na metodologia SSD quanto na SPL, o risco e um evento negativo que afeta o
processo de desenvolvimento, bem como os produtos que sao gerados. E importante que
haja um controle dos mesmos, para isso existem os softwares de gerenciamento de riscos
que consistem em avaliar e controlar esses riscos, para se ter uma medida da probabilidade
de ocorrencia e das perdas que podem ser causadas por esses. A melhor maneira de
descobrir os riscos e definir inicialmente, os objetivos e metas do projeto [Aguiar, 2002]
O fato de se construir uma SPL ja e considerado um risco, segundo [Schmid, 2001],
pois o objetivo dessa e reuso em grande escala, reducao de cronograma e esforcos, alem
da melhoria de qualidade. E como SPL envolve grandes investimentos, antes de sua
elaboracao e necessaria a realizacao de um estudo sobre seus riscos e benefıcios. Apesar
de importante, muitas organizacoes ainda nao sao adeptas a um processo de gerencia
de riscos em seus projetos de software. Isso porque ainda sao grandes as dificuldades
para compreensao e implantacao da gerencia de riscos, alem da falta de ferramentas ou
dificuldade de acesso a elas, devido a custo e outros fatores.
Entao, ha uma necessidade, segundo [Odzaly et al., 2009], de demonstrar que um es-
forco acrescido na gestao de risco leva a resultados melhores no desempenho do projeto.
Como relatado no Project Management Body of Knowledge - [PMI, 2004], o gerencia-
mento de riscos tem como objetivo aumentar a probabilidade de ocorrencia e os impactos
de eventos positivos e diminuir probabilidade de ocorrencia e impactos de eventos nega-
tivos, alem de ser um processo sistematico de identificacao, analise e respostas aos riscos
dos projetos.
8
Sao destacados os seguintes processos que compoem o gerenciamento de riscos:
• Planejamento do gerenciamento dos riscos,
• Identificacao de riscos,
• Analise qualitativa e quantitativa de riscos,
• Planejamento de resposta a riscos,
• Monitoracao,
• Controle de riscos.
Para consolidar estes processos dentro de um projeto de software, se faz necessario o
uso de uma ferramenta para este fim. Assim, este trabalho e justificado pela necessidade
em investigar o que tem sido desenvolvido, com o uso da SR, de modo a identificar
caracterısticas relevantes para se propor uma solucao de sucesso, sendo essa a proposta
de ferramenta.
3.1 Trabalhos Relacionados
Um dos precursores da area de gestao de risco e Barry W. Boehm, que definiu a gestao
de riscos como um processo composto por duas fases: 1) Avaliacao de risco, que inclui a
identificacao, analise e a priorizacao dos riscos, e 2) Controle do risco, que inclui um plano
de gestao, a resolucao, e o monitoramento dos riscos. Varios outros modelos de gestao
de riscos foram construıdos inspirados no modelo criado por Boehm, ou utilizado de tal
forma como foi criado [Kirner e Goncalves, 2007].
Trabalhos focados na gerencia de riscos e um tema que deve ser considerado nos pro-
jetos de software, ja que a gestao de risco e considerada uma disciplina basica em projetos
de desenvolvimento de software. Como poucas pesquisas a respeito foram encontradas,
fez-se necessario a construcao de tal revisao sistematica sobre o tema, e como o foco da
SR e ferramentas de gestao de risco, a seguir sao mostradas algumas ferramentas que ja
foram desenvolvidas para este fim, das quais tres destas sao apresentadas.
A ferramenta RiskFree e uma ferramenta de gerenciamento de riscos baseada no PM-
BOK (Project Management Body of Knowledge) e aderente ao CMMI (Capability Matu-
rity Model Integration). Esse embasamento se confirma na definicao do seu processo de
gerencia de riscos que traz as etapas de planejamento da gerencia, identificacao e analise
dos riscos, planejamento de resposta destes riscos, alem da monitoracao e controle destes
[Knob et al., 2006].
9
Outro exemplo de ferramenta para gerenciamento de riscos e o software TRIMS, o qual
contem o questionario proposto pelo Software Engineering Institute (SEI) para avaliacao
de riscos de software, para utilizacao em projetos de software e que foi desenvolvido pelo
BMP (Best Manufacturing Practices) Center of Excellence, uma organizacao patrocinada
pela Marinha e pelo departamento do Comercio Norte-americano, e a Universidade de
Maryland [Aguiar, 2002].
Outra ferramenta e a FMEA (Failure Model and Effect Analysis) que busca, em
princıpio por meio da analise de falhas potenciais e propostas de acoes de melhoria,
evitar que ocorram falhas no projeto do produto ou do processo. Tal ferramenta pode ser
usada para diminuir a probabilidade da ocorrencia de falhas potenciais (que ainda nao
ocorreram), diminuir a probabilidade de falha em projetos novos, aumentar confiabilidade
de produtos ou processos ja em operacao, diminuir riscos e erros e aumentar qualidade
em procedimentos administrativos [Toledo e Amaral, 2006].
Na figura 3.1 e possıvel ver o modelo da ferramenta FMEA com a descricao dos campos
para preenchimento.
Figura 3.1: Modelo de Ferramenta FMEA - Figura adaptada da original por Toledo, J.C.
e Amaral, D.C. (2006).
As ferramentas de gestao de riscos podem ser complexas ou simples. Depende do
interesse e do foco da organizacao que a realiza, pois so agora esse tipo de gerenciamento
vem sendo adotada como importante etapa do desenvolvimento de software. Como al-
gumas ferramentas dao suporte a apenas determinadas fases do ciclo de um projeto, e
alguns estudos abordam tambem somente algumas dessas fases, o objetivo da SR e reunir
caracterısticas e metodos de gestao de riscos em todas as fases de um projeto de software
visando atender e suprir as necessidades da gerencia de riscos em projetos de SPL.
10
Capıtulo 4
Metodo Sistematico
Uma SR e um meio de identificar, avaliar e interpretar toda pesquisa disponıvel e
relevante sobre uma questao de pesquisa, um tıpico ou um fenomeno de interesse. A
revisao tradicional utiliza metodos informais e subjetivos de coleta e interpretacao dos
estudos, nao descrevendo sistematicamente a pesquisa, selecao e avaliacao desses, ja a
revisao sistematica e calcada pela definicao de um protocolo, no qual sao descritos alguns
pontos chaves que sao relevantes para a correta execucao de uma SR [Kitchenham, 2007].
Assim sendo, uma estrategia de busca e definida, tudo e documentado, criterios de
inclusao e exclusao sao estipulados, alem da especificacao da informacao a ser obtida de
cada estudo, dentre outros.
4.1 Descrevendo o Metodo Sistematico
Segundo [Kitchenham, 2007], o processo de revisao sistematica e divido nas fases de
planejamento, conducao e documentacao da revisao. E dentre as razoes para realizacao
de uma SR pode-se citar:
• Resumir evidencias existentes em relacao a um tratamento ou tecnologia;
• Identificar lacunas na pesquisa atual, a fim de sugerir areas de investigacao mais
aprofundadas;
• Fornecer um framework/background adequado as novas atividades de investigacao.
Segundo [Junior, 2007], no planejamento, sao identificados a necessidade de uma re-
visao sistematica e o protocolo a ser seguido. A estrutura de um protocolo e dividida em:
motivacao, questionamento sobre a pesquisa (parte que questiona os efeitos da tecnologia,
seus custos e riscos), metodos de busca (termos, fontes) e os criterios de selecao adotados.
Ja a conducao trata da identificacao das fontes de busca. Todas as buscas devem
ser documentadas, inclusive os resultados nao aprovados. A selecao dos estudos deve
11
passar sobre os criterios de inclusao e exclusao, e a extracao desses deve ser projetada em
formularios, a documentacao da revisao sistematica e feita pelo fato de ser importante
transmitir os resultados obtidos por ela.
Se uma pesquisa nao e completa e justa, ela tera pouco valor cientıfico. O que justifica
a principal razao de se realizar uma SR, que requer maior esforco comparado a uma
pesquisa comum, pois deve fornecer informacoes sobre efeitos de algum fenomeno em
uma ampla gama de configuracoes e metodos empıricos, alem de ser possıvel combinar
dados usando tecnicas de meta-analise, o que aumenta a probabilidade de detectar efeitos
reais que os estudos menores sao incapazes de detectar [Kitchenham, 2007].
4.2 Estrategia de Busca
Para realizar uma busca exaustiva dos estudos, a estrategia de revisao sistematica con-
siste de uma busca manual em importantes e relevantes pesquisas on-line em conferencias,
journals e maquinas de busca, (ver Apendice A).
Como etapas seguidas pelo modelo sistematico, primeiramente definiu-se as palavras-
chave (strings) de busca, os criterios de exclusao e inclusao dos estudos a serem pesquisa-
dos e posteriormente realizou-se as fases de busca por strings, selecao por leitura de tıtulo
dos trabalhos, leitura do abstract e depois de selecionados os trabalhos viaveis a pesquisa,
a leitura total do trabalho foi feita coletando dados e informacoes relevantes ao objetivo
da pesquisa, juntamente com a analise dos criterios de inclusao e exclusao.
4.2.1 Strings de busca
Nesta pesquisa, as strings selecionadas sao usadas para a sua primeira etapa. Elas
foram definidas atraves de reunioes, a fim de selecionar somente estudos relacionados ao
tema de pesquisa.
Os termos sao combinados por expressoes booleanas “AND” e “OR” para formar
sequencias de pesquisa. Conferencias, journals (revistas) e maquinas de busca ligados
a Engenharia de Software sao selecionados como fontes de pesquisa, referenciados no
apendice A. Assim que reunidos, os estudos selecionados por meio da pesquisa por strings
foram avaliados seguindo as fases de rodadas, como explicado na secao 4.4.1.
Esta e a unica etapa que a pesquisa nao e feita de forma manual, pois as maquinas
de busca contem os campos de pesquisa avancada, e os journals e conferencias feitos em
pesquisas on-line utilizam o campo “Localizar” dos navegadores para encontrar os estudos
segundo as sequencias de strings de busca selecionadas.
12
Na figura a seguir, sao apresentadas as sequencias de strings de busca.
Figura 4.1: Strings de busca.
4.2.2 Selecao de Estudos
Os criterios de inclusao e exclusao baseiam-se no tema da pesquisa. E sao criados com
a finalidade de garantir que eles possam ser interpretados de forma confiavel e classificar
estudos relevantes [Kitchenham, 2007].
Na tabela a seguir, sao apresentados os criterios de inclusao e exclusao selecionados
para a SR em questao.
Tabela 4.1: Criterios de Inclusao e Exclusao
Criterios de Inclusao
Ferramentas que suportam gerenciamento de risco em SPL e SSD;
Ferramentas disponıveis gratuitamente;
Documentacao clara e util;
Criterios de Exclusao
Ferramentas que nao lidam com riscos;
Documentacao incompleta;
Documentacao com menos de duas paginas.
Os estudos considerados apropriados para inclusao na SR sao os que apresentaram
dados sobre gestao de risco em SPL e SSD, sobretudo que apresentam ferramentas que sao
de uso gratuito e/ou usam de uma documentacao clara e util sobre a gestao de riscos em
projetos de software. Ja estudos que relatam sobre gestao de projetos, mas nao detalham
13
ou se quer abordam a gestao de riscos, sao descartados pelos criterios de exclusao, alem
daqueles tambem que trazem documentacao incompleta e menor que duas paginas, pois
documentos assim nao comprovam a concisao do estudo.
4.2.3 Questoes de Pesquisa
O objetivo principal da SR e responder a seguinte pergunta: “Como as ferramentas
gerenciam os riscos durante o desenvolvimento de software”. Assim, esta secao
tem como objetivo explicar essa questao principal em mais detalhes com as seguintes sub-
questoes definidas a seguir que identificam e mostram as principais caracterısticas das
ferramentas descritas em estudos selecionados.
Q1. A ferramenta da suporte a processos especıficos ou genericos?
Essa questao visa a ideia de nao se focar em um processo da analise especıfico, o
que aumenta as chances de adotar uma ferramenta de RM em uma organizacao sem a
necessidade de se adotar um novo processo apenas para usar a ferramenta. Mas como a
maioria dos estudos selecionados nao aborda ferramentas, mas sim abordagens ou tecnicas
de RM, esses foram utilizados para responder a algumas perguntas por apresentarem
alguma funcionalidade que possa ser implementada por uma ferramenta de gestao de
riscos.
Q2. Quais as principais funcionalidades da ferramenta?
Essa questao se preocupa com a forma como a ferramenta suporta orientacoes do
processo, e como caracterısticas RM sao identificadas por ferramentas. O objetivo da
analise foi comparar as ferramentas (por exemplo, detalhes de que forma os riscos sao
recolhidos por cada ferramenta) e uma analise da funcionalidade que elas oferecem. A
analise nao se concentra em seus pontos fortes individuais ou fraquezas.
Q3. Onde as ferramentas foram desenvolvidas e utilizadas?
Essa questao identifica onde as ferramentas, no caso tambem as abordagens e tecnicas
de RM, foram desenvolvidas, seja na academia ou industria, bem como seu uso. Ao
responder essa pergunta, pode ser possıvel mapear a adaptacao atual das ferramentas.
Q4. Quais itens de risco sao identificados no SPL?
Esta questao descreve os riscos identificados por ferramentas de gestao de risco.
Q5. Como estao agrupados os riscos identificados em ferramentas de RM?
Esta questao visa identificar classificacoes adotadas pelas ferramentas para representar
as categorias de riscos. Ela tambem investiga a fase de desenvolvimento em que sao
identificados (por exemplo, riscos de cronograma, na fase de domınio de SPL ou SSD).
Q6. Que estrategias de gestao de risco (ou tecnicas) sao aprovadas pelas
ferramentas?
Esta questao tem como objetivo identificar as estrategias de RM adotadas. Seu ob-
14
jetivo e resumir maneiras (em termos de tecnicas utilizadas) para gerenciar, controlar e
resolver os riscos no desenvolvimento de software.
Q7. Que medidas foram utilizadas para avaliar os riscos identificados?
Esta questao investiga as metricas usadas para avaliar os riscos e procedimentos de
gestao de risco na ferramenta. Tambem mede os riscos, o seu impacto sobre o projeto e
probabilidade de ocorrencia. As estrategias de mitigacao e de contingencia para os riscos
sao tambem capturadas por esta questao.
Q8. A ferramenta permite a realizacao de RM em todo o processo de
desenvolvimento?
Esta pergunta verifica se a RM e realizada em todas as fases do processo de desen-
volvimento ou nao. Ao usar RM continuamente, os riscos sao avaliados e utilizados para
tomada de decisoes em todas as fases de um projeto, se nao, os riscos sao avaliados ape-
nas uma vez ou ocasionalmente, durante o planejamento do projeto inicial ou final. Os
principais riscos sao identificados e mitigados, mas os riscos nunca serao explicitamente
“olhados” novamente.
As questoes sao organizadas de modo a formar um guia para as respostas serem es-
truturadas de forma clara e compreensıvel.
4.3 Estudo de Avaliacao da Qualidade
Avaliacao de qualidade e feita para avaliar os estudos primarios. Dois tipos destes
estudos sao encontrados em nossa busca: abordagens e pesquisas. No entanto, os criterios
de qualidade sao aplicados em comum a estes dois tipos, principalmente como uma pratica
para orientar a interpretacao de resultados para os dados de analise e sıntese.
O procedimento de pontuacao depende das respostas obtidas para cada pergunta: 1
para “Sim”, 0,5 para “Em parte” e 0 para “Nao”. E assim como os criterios de inclusao
e exclusao fazem parte da analise de dados, os criterios de qualidade sao incluıdos da
mesma forma, avaliando a contribuicao que os trabalhos dao em relacao a ferramentas de
riscos, ja que alguns trabalhos que nao relatam sobre ferramentas apresentam metodos e
abordagens de gerenciamento desses.
Na figura 4.2 sao apresentados as questoes de qualidade para as abordagens rela-
cionadas a RM para SPL e SSD.
Como o escopo da RM aborda tambem gerenciamento de riscos na metodologia SSD, a
questao 1 permite identificar quais trabalhos selecionados abordam esta metodologia, que
servem tambem como base para a metodologia SPL. A questao 2 identifica se a ferramenta
foi descrita em detalhes sobre as suas funcionalidades e a 3 como ela foi desenvolvida.
15
Figura 4.2: Questoes de Qualidade
A questao 4 verifica se as abordagens de gestao de riscos tratam das etapas de avaliacao
e controle destes conforme estabelecido por Barry W. Boehm e a questao 5 avalia se os
riscos foram identificados de acordo com suas caracterısticas, ou seja, se houve algum
criterio de classificacao ou se foram apenas reunidos em forma de listas, por exemplo.
ja a questao 6 tem a finalidade de especificar se a ferramenta apresenta o estado em
que se encontra o risco no seu processo de gerenciamento, como por exemplo, mitigado,
transferido, resolvido e outros.
A questao 7 avalia se a ferramenta ou metodo de gestao de riscos abordado tem a
preocupacao de construir um historico sobre o gerenciamento de riscos, seja ela na forma
de listas de riscos, formas de mitigacao, formas de testes, dentre outros. A questao 8
aborda se a ferramenta limita o seu acesso a usuarios, ja que o trabalho de gestao de riscos
deve ser feito por uma equipe dedicada com papeis e responsabilidades, caso contrario, e
necessario estabelecer papeis e tipos de acessos a esta ferramenta.
4.4 Conducao do Trabalho
Para a conducao da pesquisa, as fontes, datas, tıtulos e autores dos estudos seleciona-
dos sao registrados e os metodos criados na fase de planejamento sao agora aplicados. Ou
seja, para os estudos serem coletados, as strings sao associadas as maquinas de busca e seus
resultados sao analisados, conforme os criterios de inclusao. Alem disso, para conferencias
e revistas um processo manual de pesquisa e feito analisando abordagens interessantes a
SR, selecionando estudos por tıtulo.
16
4.4.1 Rodadas
Para selecionar estudos que correspondam ao escopo da SR, foi feito o que e chamado
de “rodadas”, ou seja, para cada rodada um aspecto de estudo foi verificado. Primeira-
mente, os estudos sao selecionados atraves das strings, depois a exclusao dos mesmos e
feita pela leitura de tıtulo, ou seja, se o tıtulo nao tem algo relacionado com o tema de
pesquisa o estudo e entao descartado. Dos 184 artigos selecionados, 105 foram consider-
ados relevantes a SR.
Posteriormente, e feita a analise de trabalhos duplicados, ou seja, se um mesmo tra-
balho aparece em diferentes conferencias, journals ou maquinas de busca, desta rodada
5 artigos foram descartados. Logo depois, uma leitura parcial dos trabalhos, abstract, e
feita para identificar quais trabalhos sao pertinentes a proposta do trabalho, eliminando
33 estudos. Dos 33 estudos eliminados, 5 nao foram lidos por falta de acesso (pessoal e
pela UFG - Universidade Federal de Goias).
Assim, os estudos que tem seu resumo inicial indicando que se tratam do assunto em
questao da revisao, sao selecionados para a proxima fase que e a de leitura completa do
artigo e analise dos criterios de exclusao. Dos 67 estudos selecionados para essa fase, 4
nao foram lidos tambem por falta de acesso e outros 10 foram eliminados pela leitura total
ou criterios de exclusao. Durante a leitura dos artigos, as questoes definidas sao respon-
didas e outras informacoes sao coletadas, as quais sao necessarias para o levantamento de
caracterısticas que uma ferramenta de gerenciamento de risco em SPL deve apresentar.
Na Figura 4.3, e apresentado o numero de estudos como entrada e saıda em cada ro-
dada. O resultado final das rodadas quantifica os estudos selecionados para a SR aos quais
passaram pelos criterios de qualidade, para verificar sua contribuicao para ferramentas de
gerenciamento de riscos.
Figura 4.3: Rodadas.
17
4.4.2 Extracao de Dados
A etapa de extracao de dados registra informacoes obtidas por meio dos estudos sele-
cionados pela SR. Logo, formas de extracoes de dados sao definidas e seguidas para evitar
redundancia e facilitar o trabalho do pesquisador [Kitchenham, 2007].
Para reunir estas informacoes sao utilizadas planilhas eletronicas, por serem mais faceis
de visualizar os resultados da SR. E para cada fonte de pesquisa foram organizados em
planilhas, os estudos de acordo com seu tıtulo, ano de publicacao, autores e local de
publicacao. O documento tem a funcao de orientar o pesquisador durante as etapas de
selecao do estudo.
Cada estudo e relacionado a um identificador (ID), junto aos seus dados como tıtulo,
ano de divulgacao e autor principal, conforme mostrado na tabela do apendice B.
4.5 Divulgacao dos Resultados
A analise e discussao sobre os resultados obtidos serao feitos no proximo capıtulo.
4.5.1 Discussao
A fase final envolve a escrita e os resultados da SR, e a divulgacao destes resultados
aos interessados. E importante a comunicacao dos resultados ser feita de forma eficaz. E e
importante definir como sera a divulgacao destes resultados. Embora haja um numero de
formas diferentes de divulgacao de resultados quando estes sao destinados a profissionais
influentes como pagina web, revistas e etc.
A divulgacao dos resultados da SR em questao e feita inicialmente a comunidade
academica. Mas tambem outros profissionais ligados a engenharia de software e gestao
de riscos sao bem-vindos a acessar o conteudo da pesquisa.
18
Capıtulo 5
Resultados
Este capıtulo apresenta os principais resultados obtidos por meio das atividades de
revisao estabelecidas.
5.1 Criterios de Qualidade
A pontuacao da qualidade dos estudos foi baseada nas respostas as perguntas de
criterios de qualidade. As pontuacoes disponıveis (1.0 para “sim”, 0.5 para “Em Parte”
e 0.0 para “nao”) foram definidas aos estudos de acordo com a sua contribuicao para a
revisao. Estudos que levam “sim” como resposta sao aqueles que respondem claramente
o criterio de qualidade em questao, ja estudos que levam “em parte” e “nao” respondem
parcialmente ou nao o criterio de qualidade, respectivamente.
Na figura 5.1, e mostrado o grafico do ındice de criterio de qualidade para cada estudo
selecionado. O calculo foi feito estabelecendo a porcentagem de qualidade de cada estudo
como contribuicao a pesquisa.
Figura 5.1: Criterios de Qualidade
Na tabela 5.1, no final desse capıtulo, e mostrada a pontuacao de cada estudo em
relacao as questoes de qualidade.
19
A pontuacao possıvel a cada estudo varia de 0 a 8. Um estudo com pontuacao 8
representa um estudo que responde a todas as questoes de qualidade por conter assunto
referente ao escopo de pesquisa. Apenas os estudos selecionados apos as rodadas passaram
pela avaliacao dos criterios de qualidade. Na tabela 5.2 sao apresentados os valores que
representam o percentual de qualidade para cada estudo coletado.
Todos os estudos, por serem selecionados, nao significam lidar com ferramentas de
gerenciamento dos riscos em SPL. A grande maioria relata pesquisas e abordagens sobre
gestao de risco abordando a metodologia SSD utilizada na industria.
5.2 Respostas as questoes de pesquisa
Esta secao apresenta a resposta as questoes de pesquisa da SR, lembrando que os
artigos citados antes de cada funcionalidade ou caracterıstica serviram de referencia para
suas definicoes:
Q1. A Ferramenta apresenta suporte a processos especıficos ou genericos?
A grande maioria dos estudos nao respondem a questao, pois nao se tratam de ferra-
mentas de RM e sim de tecnicas, estrategias e modelos alem das abordagens, pesquisas e
entrevistas voltadas a gerencia de riscos. Alguns ainda tratam apenas de algumas fases
do processo de desenvolvimento de software orientados a riscos como testes, requisitos e
arquitetura.
Apenas 4 artigos relatam sobre ferramentas de RM [S2] [S3] [S8] [S20] (ver Apendice
B), que utilizam formula matematica para calcular o impacto do risco, ou os avalia pre-
cocemente, ou os armazenam e trabalham de forma a realizar uma analise qualitativa e
quantitativa utilizadas sobre quaisquer escopos de projetos.
Q2. Quais as principais funcionalidades da ferramenta?
Todos os estudos responderam a esta questao trazendo nao so ferramentas mas abor-
dagens, experiencias, descricoes de ferramentas, focados na gestao de riscos. A seguir
sao apresentadas as principais funcionalidades ou caracterısticas abordadas pelos estudos
selecionados.
• [S4][S10][S15]Avaliacao de riscos e benefıcios do desenvolvimento:
Como a SPL e um campo novo dentro de reuso de software que visa reutilizacao,
reducao do tempo de entrega de produtos e esforcos, melhoria da qualidade, alem de
envolver grandes investimentos iniciais, se faz necessario uma avaliacao de benefıcios
20
e riscos do seu desenvolvimento. Esse tipo de avaliacao se destina a resolver o
problema da quantificacao de riscos de reutilizacao alem de suprir a necessidade
de avaliacao e planejamento de gestao dos riscos antes de se iniciar o projeto. O
levantamento de requisitos tambem e importante, pois por meio da sua analise
pode-se identificar e definir o risco geral de produzir o produto.
• [S15] [S21] [S35] [S36] [S44] avaliacao precoce dos riscos:
A gestao de projeto deve lidar com tratamento de riscos antes mesmo de se inicia-
la, e nesta fase que se identificam os riscos e suas consequencias junto ao cliente
que deve estar ciente de tudo. Alguns testadores de software utilizam a avaliacao
precoce de riscos para se ter uma ideia do que testar e confirmar o impacto de
determinados riscos. [S36] Outra forma de fazer uma avaliacao precoce dos riscos
e montar um quadro de avaliacao com os campos de identificacao e descricao dos
riscos para poder planejar melhor a forma de geri-los.
• [S21] [S27] [S32] [S33] [S45] Requisitos baseados em riscos;
Esta funcionalidade e muito abordada porque se o projeto nao sai conforme o cliente
deseja, conclui-se que o conjunto de requisitos expresso nao representa as suas ne-
cessidades ou a selecao de reutilizacao foi impropria. Os requisitos levantados sao
importantes para futuras decisoes sobre o projeto, e e nesta fase que os componentes
de reutilizacao sao selecionados, por isso os riscos sao documentados e claramente
definidos para que as organizacoes possam lidar com os requisitos de forma mais
eficaz.
A utilizacao de modelos de requisitos e considerada um risco, ja que este pode
nao representar necessariamente o objetivo do projeto. E importante tambem ter
em mente que novas tecnologias surgem e que a SPL devera estar apta a aceitar
mudancas, logo, este e um risco a ser considerado na etapa de levantamento de
requisitos.
• [S9] [S27] [S43] [S45] Documentacao e Comunicacao dos riscos;
A documentacao e uma forma importante de comunicacao, dessa forma os riscos
sao devidamente descritos para depois serem atendidos adequadamente. O contato
com o cliente tambem e uma fonte de comunicacao importante, ate quando se e
permitido, pois deve-se levar em conta a variabilidade interna a SPL.
A comunicacao dos riscos, independente de sua forma, deve ser feita de forma clara
e durante todo o processo, pois riscos podem surgir ao longo das etapas de desen-
volvimento e devem ser registrados.
21
• [S5] [S8] [S12] [S17] [S18] [S19] [S21] [S22] [S23] [S24] [S25] [S27] [S30]
[S36] [S38] [S42] [S43] [S44] [S47] [S48] [S50] [S53] Identificacao do risco:
A identificacao e considerada importante para todos os artigos citados. Ela e re-
alizada em todas as etapas de desenvolvimento do software, mas deve ser feita de
preferencia antes de se iniciar o projeto alem de ser documentada, para se ter uma
boa comunicacao dos riscos, como explicado nos topicos anteriores. A identificacao
nao e somente dos riscos em si, mas tambem dos fatores de riscos (ou grupos de
riscos) que o projeto pode ter e o estado dos riscos, ou seja, se eles foram mitigados,
monitorados, dentre outros estados que o processo de RM utilizado tenha adotado.
• [S1] [S5] [S7] [S11] [S12] [S14] [S18] [S19] [S22] [S23] [S24] [S25] [S34] [S38]
[S39] [S42] [S44] [S45] [S46] [S48] [S53]Analise:
A analise do risco avalia a exposicao dos riscos relacionado a probabilidade e frequencia
de ocorrencia, impacto, perda e gravidade relacionadas a cada risco identificado.
• [S2] [S7] [S11] [S12] [S29] [S40] [S42] [S43] [S47] [S51] [S52] Priorizacao:
Apos a analise, as exposicoes sao priorizadas para identificar os riscos que repre-
sentam maior ameaca ao projeto. Geralmente uma lista ordenada e produzida de
acordo com a decisao do gerente de projeto sobre os elementos considerados de
maior risco ao projeto. Alem disso, algumas organizacoes realizam a priorizacao de
recursos, ou seja, quais recursos sao mais importantes para o desenvolvimento do
projeto.
• [S1] [S5] [S6] [S7] [S8] [S11] [S12] [S15] [S16] [S17] [S18] [S19] [S22] [S23]
[S27] [S30] [S33] [S36] [S43] [S44] [S47] [S48] [S50] [S53] [S26] [S44] Plane-
jamento:
O planejamento da gestao de riscos prepara e elabora acoes de carater preventivo a
cada risco priorizado incluindo tambem transferencia, mitigacao e aceitacao destes
riscos. A atencao foca sobre os fatores de alto risco para minimizar a probabilidade
de sua ocorrencia e/ou amplitude de impacto.
• [S5] [S9] [S12] [S23] [S24] [S27] [S30] [S38] [S53] Definir:
No processo de definir (ou tambem chamado de Resolucao) o risco produz-se uma
situacao na qual os itens de risco sao eliminados ou resolvidos utilizando estrategias,
documentando os resultados no plano de risco.
• [S1] [S8] [S14] [S17] [S22] [S26] [S37] [S38] [S44] [S46] [S47] [S48] Moni-
torar:
22
Esta etapa envolve o acompanhamento do status de cada risco do projeto com
intuito de escolher medidas certas para resolve-los. Os riscos devem ser monitorados
progressivamente, pois assim pode-se garantir que os riscos estao sob controle e se
preciso utilizar o plano de gestao de risco, caso algum se materialize.
• [S6] [S14] [S27] [S28] [S35] [S47] [S49] [S50] Testes de software baseados
em riscos:
Alguns projetos utilizam os riscos como base de planejamento de testes para poder
minimiza-los, o que requer a identificacao e exploracao dos riscos decorrentes dos
varios tipos de falha. E recomendado deixar disponıvel o resultado de todos os
testes para projetos futuros.
A aplicacao da tecnica de simulacao de dados analisa os dados do projeto e identifica
fatores que sao susceptıveis para impactar a produtividade da equipe e afetar a
capacidade de atingir o objetivo programado. Alguns modelos de simulacao tem a
intencao de prever o comportamento esperado do projeto com base nas praticas de
gestao.
• [S1] [S8] [S9] [S12] [S14] [S15] [S16] [S17] [S19] [S20] [S23] [S24] [S27] [S30]
[S38] [S41] [S46] [S48] Listas de verificacao de riscos;
Algumas ferramentas ou abordagens defendem a criacao de uma especie de repositorio
de dados que serve como base de conhecimento para futuros projetos. Cabe ao
gestor do projeto decidir o que colocar de informacao nessas listas e a quem permi-
tir o acesso a elas. Algumas empresas divulgam suas experiencias com riscos para
empresas de desenvolvimento terem acesso, ja outras preferem manter a informacao
somente disponıvel para a equipe de gestao de riscos interna. A avaliacao de risco
baseada em listas prontas tambem pode ser tendencioso, o que e um risco.
Outros artigos tem foco principal em demonstrar a influencia do risco [S39], mostrar
as barreiras a gestao de risco [S31], demonstrar tecnicas de RM [S42], compreensao de
riscos e incertezas [S15], integracao de RM em processos ageis [S25] e identificacao de
processos de RM para integracao a gestao de projetos [S30].
O risco pode ser usado para orientar decisoes sobre o projeto. O raciocınio baseado
em riscos permite aos engenheiros e gerentes de software fazerem escolhas de arquitetura
e desenvolvimento de modo que satisfaca os criterios de requisitos do sistema e limitacoes
de recursos.
Q3. Onde as ferramentas foram desenvolvidas e utilizadas?
23
Dos 53 estudos coletados, apenas 27 responderam a esta questao, relatando nao so
as ferramentas mas tambem onde as pesquisas, tecnicas, abordagens e outros, foram
desenvolvidos e utilizados. Sendo que 18 destes 27, responderam apenas parte da questao,
[S2] [S3] [S5] [S9] [S11] [S13] [S15] [S20] [S24] [S25] [S36] [S39] [S40] [S41] [S45] [S46] [S47]
[S51]. Alguns davam a informacao de onde foram desenvolvidos [S11] [S36] [S41] [S45]
[S51], e nao relatavam onde foram utilizados e vice-versa.
Dentre os 27 artigos que deram essa informacao, apenas tres trabalhos tiveram par-
ticipacao de universidades, onde [S12] foi desenvolvido e usado na University of Southern
California/ Department of Computer Science, [S8] foi desenvolvido pelo Instituto de Tec-
nologia da California, e [S49] onde foi desenvolvido e usado uma pesquisa sobre gestao de
riscos em duas Universidades Canadenses cujos nomes nao foram ditos.
Q4. Quais itens de risco sao identificados no SPL?
Referente a esta questao, varios trabalhos apresentam uma resposta abordando os
riscos encontrados nas pesquisas, abordagens ou tecnicas em que e utilizada a gestao de
riscos. 23 estudos nao abordam expressamente a questao de riscos identificados [S3], [S4],
[S5], [S7], [S8], [S9], [S11], [S14], [S16], [S17], [S19], [S23], [S25], [S28], [S30], [S33], [S37],
[S39], [S41], [S44], [S45], [S47], [S53] mas foram selecionados como estudos validos a SR
por abordarem tecnicas, experiencias, pesquisas e abordagens sobre a gestao de riscos.
Existem muitos modelos prontos de listas de riscos possıveis em desenvolvimento de
software e muitas organizacoes se baseiam nessas listas para lidar com a gerencia de riscos.
Entre esses modelos e possıvel citar o nome de Boehm, Addison e Vallabh e o Capability
Maturity Model Integration (CMMI) que definiram suas listas de riscos possıveis.
Na tabela apresentada no apendice C sao apresentados os fatores de riscos de maior
potencial avaliados na SR, com a categoria a qual pertence e sua identificacao.
Q5. Como estao agrupados os riscos identificados em ferramentas de RM?
14 estudos nao respondem a questao [S4], [S7], [S9], [S10], [S11], [S12], [S14], [S24],
[S29], [S32], [S33], [S37], [S41], [S49], pois nao relatavam como eram agrupados os riscos
ou simplesmente nao realizavam essa tecnica de agrupamento, alguns processos de gestao
de risco simplesmente montam uma lista de riscos sem priorizacao destes.
17 estudos [S2] [S3] [S5] [S17] [S18] [S19] [S22] [S23] [S26] [S27] [S31] [S36] [S42] [S43]
[S45] [S50] [S51] tratam a classificacao dos riscos seguindo o modelo de Boehm [S23] [S51],
ou seja, classificando os riscos entre os nıveis “Alto”, “Medio” e “Baixo”, de acordo com
sua probabilidade e severidade
O assunto apresentado nos outros artigos apresenta um agrupamento de riscos mais
24
detalhado, como:
• [S1] [S19] [S20] [S21] [S36] [S39] [S40] Riscos relacionados a requisitos e
clientes:
Os requisitos do software sao muito importantes no processo de desenvolvimento,
pois sem sua clara definicao o produto final nao satisfazera as necessidades do cliente,
que por sua vez deve estar comprometido e ciente do impacto de mudancas no
escopo, em termos de custos, cronograma e a funcionalidade que e desejavel e a
que e necessaria. Muitos riscos que ameacam os projetos envolvem ambiguidades
e incertezas, para isso e preciso definir o que esta ou nao no escopo do projeto e
qual funcionalidade e essencial para este. A preocupacao com o que o cliente espera
como: confiabilidade, desempenho, seguranca, robustez e facilidade de uso devem
ser levadas em conta nessa etapa de definicao de riscos, pois sao eles que definem o
nıvel de qualidade que se precisa para facilitar a tomada de decisoes, fornecer uma
base para acompanhar progresso alem de servir como base de testes.
Dos estudos selecionados, oito apresentam um grupo de riscos especificamente rela-
cionados a clientes [S1] [S18] [S20] [S21] [S36] [S38] [S39] [S40], isso porque os clientes
devem se comprometer nao somente na fase de requisitos, mas em todo o processo
de desenvolvimento.
• [S1] [S31] [S36] [S38] [S39] [S48] Riscos relacionados a Gestao de riscos:
Planejar a gestao de riscos, definindo equipe e responsabilidades, qual metodologia
a ser usada, o ambiente de desenvolvimento, recursos necessarios, entre outros tipos
de decisoes, sao consideradas neste grupo de risco. A complexidade de tratar os
riscos, custos com a sua gestao, compreensao e falta de motivacao se tornam bar-
reiras a gestao de riscos. O processo de gestao de riscos deve se adaptar com as
caracterısticas do projeto, auxiliando a customizacao do processo de software. O
gestor tem que lidar ainda, com riscos de controle e informacao, onde ele deve ter
autoridade suficiente para fazer e influenciar decisoes no processo e estar ciente que
as informacoes adotadas do processo sao adequadas e precisas para poder basear
suas decisoes.
• [S1] [S16] [S18] [S19] [S20] [S30] [S34] [S36] [S38] [S39] [S40] [S46] [S48]
[S53] Riscos relacionados a Gestao de projetos ou a Execucao:
Alguns estudos [S1] [S18] [S36] [S39] classificam riscos de execucao, ou seja, aqueles
relacionados a qualidade, custos, falhas e cronograma. Ja outros relacionam essas
e outras categorias de riscos como, por exemplo, ambiente, riscos legais, desem-
penho e comprometimento dos gestores e desenvolvedores de software, como sendo
25
relacionados a gestao de projetos como um todo. Os riscos organizacionais en-
volvem mudancas na organizacao que podem afetar o desenvolvimento do sistema,
como alteracoes de escopo e consequentemente mudanca no cronograma, despesas
financeiras alem da planejada, demissao de profissionais, area do usuario, custo de
equipamento e outros, o que acarreta nos riscos de nıvel empresarial, ou seja, aqueles
riscos que de alguma forma atrapalham o desempenho e sucesso de uma empresa.
• [S6] [S16] [S19] [S25] [S38] Riscos tecnicos e de desenvolvimento:
A possibilidade da teoria estudada na engenharia de software, tecnicas e princıpios
nao produzam o software desejado [Scoy, 1992].
Esta e uma classe de riscos que podem ser causados por uso de tecnicas e metodolo-
gias inadequadas, falta de profissionais com experiencia, que podem fazer o produto
sair caro, com atraso ou inaceitavel pelo cliente. Envolve tambem riscos relacionados
a instalacao de softwares, ou parte deles.
• [S42] Riscos genericos, especıficos, voluntarios e involuntarios:
Os riscos genericos e especıficos sao os melhores aplicaveis a SPL, ja que a metodolo-
gia produz produtos customizados, mas todos partindo de um mesmo padrao. Os
riscos genericos sao aqueles comuns a todos os projetos de software, como requi-
sitos, perda de profissionais, tempo, cronograma e outros. Ja os riscos especıficos
sao aqueles que resultam de uma particularidade do software, ja que a medida que
vao se integrando componentes no software customizado de acordo com as vontades
do cliente, os riscos vao aumentando, como por exemplo, incompatibilidade, e para
isso existem os testes para detecta-los e solicitar ao plano de acao uma medida para
corrigi-los.
Os riscos voluntarios sao aqueles que ocorrem pelo resultado de alguma acao da
gestao de risco estando ciente que ele poderia acontecer, como por exemplo, usar
uma linguagem de programacao nao confiavel. Os riscos involuntarios sao os riscos
que ocorrem sem esperar que poderiam ocorrer, como exemplo, um risco devido a
escolha de uma nova linguagem de programacao confiavel.
• [S28] [S50] Testes:
Existem metodos de gestao de riscos baseados em testes. Os riscos podem ser
separados por sub-domınios e depois de testados sao agrupados em relacao ao seu
custo e consequencias de fracasso. A cada sub-domınio e atribuıdo o numero de
falhas mais o custo associado a cada uma. Ou elaborar um esquema de classificacao
de riscos que os relacionam em classes de testes diferentes, de acordo com o seu
26
resultado, ou seja, se o resultado e alarmante, marginal ou insignificante para o
projeto, certas acoes sao tomadas para mitiga-los.
Q6. Que estrategias de gestao de risco (ou tecnicas) sao aprovadas pelas
ferramentas?
Alem dos estudos que relatam sobre ferramentas de gerenciamento de riscos, outros
que relatam abordagens, tecnicas ou experiencias, respondem a questao sobre diferentes
tecnicas de gerencia de risco. A seguir sao apresentadas as tecnicas cabıveis a metodologia
SPL.
• 3 estudos apresentam a importancia de se realizar a gestao de riscos antes
mesmo de se comecar um projeto de software [S4] [S10] [S15], pois a
SPL envolve grande investimento inicial e por isso precisa de uma analise dos riscos
e benefıcio de seu desenvolvimento. Assim, para resolver esta questao, foram pro-
postas pelos trabalhos referenciados tres etapas dessa analise que consistia em fazer
um mapeamento da linha de produto, execucao de entrevistas e julgamento final
dos riscos e benefıcios.
O mapeamento serve como base de comunicacao para avaliacao e visa desenvolver
um modelo de referencia especıfico para a SPL, ja que as unidades funcionais es-
pecıficas de outras linhas de produtos podem ser diferentes e nao sao mapeadas de
forma abstrata. O mapeamento vai servir para identificar a estrutura de alto nıvel
da SPL e como as suas principais funcionalidades se relacionam. Primeiramente,
identificam-se os possıveis e ja existentes sistemas relevantes a SPL elaborando um
plano de visao geral destes, assim fica mais facil identificar os principais domınios
da SPL e como eles se relacionam. Finalmente, desenvolve-se uma matriz inicial de
produtos e suas funcoes.
Os questionarios e comentarios individuais de cada gestor de projetos semelhantes
entrevistados ajudam no julgamento final do que pode ser risco e benefıcio para o
desenvolvimento da SPL.
• Outra tecnica utilizada e a avaliacao precoce dos riscos [S15] [S21] [S35] [S36]
[S44], ou seja, e possıvel prever quais riscos podem surgir no projeto, por meio das
listas de verificacao ou analise dos riscos e benefıcios do desenvolvimento do software.
• Para a gestao de risco ser eficaz, todos da equipe devem entender os riscos que sao
identificados e suas descricoes. O que exige uma boa comunicacao destes [S1] [S9]
[S15] [S25] [S27] [S29], que pode ser feita em forma de documento, reunioes e foruns
[S5] [S6] [S9] [S12] [S13] [S15] [S17] [S27] [S28] [S30] [S37] [S41] [S43] [S45] [S49].
As praticas de gestao de riscos precisam ser documentadas, assim como os riscos,
27
relatorio de acompanhamento do projeto e relatorio de avaliacao final. Podem ter
forma de historico (por determinadas datas, por exemplo, 30 dias [S14]), formularios
(contendo sua descricao textual, probabilidade de ocorrencia, perda e suas acoes de
controle) e tambem em forma de cenarios. E importante ter sempre documentado
a informacao especıfica e geral de um risco e o grupo em que ele se enquadra alem
das acoes a serem tomadas nos dois casos [S41].
• [S21] [S27] [S32] [S33] [S45] Requisitos baseados em riscos;
Falhas encontradas no final do processo sao mais caras para resolver do que encon-
trados no comeco. Alinhar requisitos com os objetivos do cliente e identificar as
possıveis fases que o projeto ira passar ajuda a documentar e prever o que pode
dar errado. Uma forma mais clara de fazer e entender esta documentacao sao usar
abordagens textuais e graficas para identificar e avaliar os riscos, conforme explicado
nos topicos seguintes.
Depois de reunir com o cliente e definir os requisitos, apontando o que e possıvel
ou nao de se realizar e o que realmente e necessario para ele, o gestor de requisitos
deve evitar ao maximo que esses sejam mudados.
• Avaliacao( identificacao, analise e priorizacao);
um quadro de gestao de risco muito utilizado e formado pela Avaliacao e controle
dos riscos, por Barry Boehm, conforme mostrado na figura a seguir.
Avaliacao e composta pelas etapas de identificacao, analise e priorizacao dos riscos,
o controle contem as etapas de planejamento, definicao (ou resolucao) e monitora-
mento dos riscos, como e mostrado na figura a seguir, explicados nos proximos
topicos.
• A identificacao de riscos [S5] [S8] [S12] [S17] [S18] [S19] [S21] [S22] [S23]
[S24] [S25] [S27] [S30] [S36] [S38] [S42] [S43] [S44] [S47] [S48] [S50] [S53]
Esta tecnica produz uma lista dos itens de riscos que podem comprometer o sucesso
do projeto que pode ser feita atraves de seminarios, listas de riscos, questionarios,
entrevistas, grupos de trabalho, conhecimento de experiencias passadas e documen-
tadas, informacoes historicas ou alinhando os requisitos com as necessidades do
cliente para identificar as fases que o projeto vai passar e montar casos de uso (ou
qualquer outra forma de documentacao) com o que pode dar errado.
• As listas de riscos projeto [S1] [S8] [S9] [S12] [S14] [S15] [S16] [S17] [S19]
[S20] [S23] [S24] [S27] [S30] [S38] [S41] [S46] [S48]
28
Figura 5.2: Etapas da Gestao de Riscos do Software - Figura adaptada da original por
Barry W. Boehm (1991).
Tambem chamadas de repositorios de informacoes ou ainda, listas de verificacao,
elas contem os fatores de riscos mais comuns, sua descricao e o peso de seus im-
pactos. Mais caracterısticas sao adicionadas a elas, como por exemplo, acao de
controle e custo de mitigacao, caso for permitido fornecer este tipo de informacao
pela organizacao. Elas podem ser de forma textual, grafica ou armazenada em banco
de dados.
• A analise de riscos [S1] [S5] [S7] [S11] [S12] [S14] [S18] [S19] [S22] [S23]
[S24] [S25] [S34] [S38] [S39] [S42] [S44] [S45] [S46] [S48] [S53]
Segundo o modelo utilizado por [BOEHM, 1991], descreve e atribui valores aos
riscos em termos de probabilidade de ocorrencia (Muito Provavel, Provavel e Pouco
Provavel) e a perda caso ele ocorra (Crıtico, Marginal, Insignificante).
• [S2] [S7] [S11] [S12] [S29] [S40] [S42] [S43] [S47] [S51] [S52] A priorizacao
A priorizacao dos riscos ajuda a decidir quais riscos prejudicam mais os objetivos
do projeto. Estes sao classificados de forma a sugerir estrategias de mitigacao. Usar
listas ou cenarios para separar os riscos priorizados pode ser uma tecnica adotada, o
uso de cores tambem ajuda por ser mais facil de entender, principalmente por parte
do usuario.
29
Algumas abordagens separam os riscos em grupos de Alta, Media e Baixa im-
portancia. Mas outros [S1] [S6] [S13] [S16] [S18] [S19] [S20] [S21] [S23] [S25] [S28]
[S30] [S31] [S34] [S35] [S36] [S38] [S39] [S45] [S46] [S47] [S53] utilizam dos valores
atribuıdos aos riscos na fase de analise para classifica-los em grupos mais especıficos,
facilitando a documentacao, pesquisa, tratamento e controle destes. A forma como
sao avaliados e os grupos de riscos mais usados sao apresentados nas respostas as
questoes 7 e 5 respectivamente.
• Controle (planejamento, definir e monitorar);
Controlar os riscos significa elaborar um plano de resolucao dos riscos, monitorar
constantemente seu status e implementar planos de resolucao destes, a fim de corrigir
desvios do plano.
• [S1] [S5] [S6] [S7] [S8] [S11] [S12] [S15] [S16] [S17] [S18] [S19] [S22] [S23]
[S27] [S30] [S33] [S36] [S43] [S44] [S47] [S48] [S50] [S53] [S26] [S44] Plane-
jamento:
Nesta fase sao realizados os planejamentos de acoes para cada risco e sua integracao
ao plano de gestao de risco geral de modo a enderecar e eliminar os riscos antes de
se tornarem ameacas reais, designacao de papeis aos seus responsaveis, definicao dos
marcos a ser alcancados, orcamentos, cronograma, funcoes de controle dos riscos,
tudo isso pensando no processo, na organizacao e na tecnologia, documentado clara-
mente.
Algumas organizacoes montam uma especie de diagrama de tratamento dos riscos,
mantendo de forma grafica todas as decisoes tomadas no plano de gestao de riscos.
• [S5] [S9] [S12] [S23] [S24] [S27] [S30] [S38] [S53] Definicao (Resolucao):
Na elaboracao de acoes preventivas aos riscos priorizados, a prevencao do risco
tem por objetivo evitar ou minimizar um efeito ou impacto negativo ao projeto.
Ja a transferencia de um risco implica transferir a responsabilidade de um risco a
terceiros. A acao nao vai eliminar a ameaca, mas vai passar a responsabilidade
a uma pessoa mais capaz de gerir o risco transferido. Mitigar o risco reduz sua
probabilidade e/ou impacto antes de ser realizado. Seu objetivo e que o risco nao
ocorra, caso aconteca, o impacto pode ser reduzido. Aceitar o risco envolve respostas
ativas e passivas ao risco. A equipe de gerenciamento pode aceitar a sua existencia
e optar por nao fazer nada por ser um risco de baixa ameaca. Por outro lado, pode
existir uma ameaca maior caso o risco ocorra, mas ha pouco a ser feito para evitar
ou minimizar seus efeitos.
30
• [S1] [S8] [S14] [S17] [S22] [S26] [S37] [S38] [S44] [S46] [S47] [S48] Moni-
torar:
O monitoramento acompanha o andamento do projeto para resolucao de seus itens e
realizacao de atividades corretivas, caso seja necessario. O documento de monitora-
mento de riscos pode ser feito de forma textual, grafica, matriz ou como o gestor de
riscos considerar mais facil de visualizar e entender o status dos riscos monitorados.
As organizacoes variam o intervalo de tempo em que atualizam o status dos riscos
(que deve acontecer desde a sua identificacao ate a sua resolucao) e sua comunicacao
deve ser satisfatoria, podendo ser feita atraves de reunioes [S5] [S15] [S27] [S37] onde
sao discutidos quais riscos surgiram, quais foram mitigados, o que mudou em relacao
a projeto, custos, cronograma e pessoal, novidades e feedbacks, o que garante um
bom trabalho da gestao de riscos. Um documento com os status dos riscos pode
ser feito a cada reuniao e usado para acompanhar e comparar os riscos, alem de
comunicar os topicos aos clientes e departamento de vendas que deve estar ciente
do produto que estao a vender.
• [S6] [S14] [S17] [S27] [S28] [S35] [S47] [S49] [S50] Testes de software basea-
dos em riscos;
O objetivo dos testes e o de encontrar erros para correcao. Muitos fracassos sao
causados nao por itens individuais de software, mas pelas interacoes entre os itens.
Assim fica mais facil encontrar as falhas relevantes. Para projetos se utilizam de um
software padrao, esse e sempre testado para garantir que funcione adequadamente.
Quando as novas unidades sao desenvolvidas, elas sao integradas aos poucos ao
nucleo e testados. Se o software nao pode ser testado exaustivamente, ele deve ser
testado de forma seletiva. Entender e testar os componentes comuns melhora a
manutencao e confiabilidade do projeto.
Um modo muito utilizado de testes e a simulacao de dados [S11] [S17] [S24] [S37]
[S47] [S53]. Essa tecnica e utilizada para avaliar os processos e agentes alem de
permitir a avaliacao do comportamento dos modelos.
A documentacao de alguns projetos e feita em forma de cenarios de riscos, pois,
combinacoes desses cenarios ajudam na avaliacao do risco dentro de um projeto
particular.
O uso de classes de riscos determina que acoes tomar e as formas de testes aplicadas
sobre os itens de falha. O nıvel de confianca pode ser usado para classificar o risco
e sua acao, ou seja, quando a confianca e baixa (Classe A) a acao a ser tomada e
devolver o sistema aos desenvolvedores, quando a confianca e mais elevada (Classe
31
B) e adequado aplicar o programa de testes e quando a confianca e muito alta
(Classe C) o programa de testes pode ser reduzido.
Utilizando o conceito de falha, que e o desvio entre a saıda real e a especificada para
uma dada entrada, para realizar os testes e importante a implantacao de medidas de
eficacia como probabilidade de descobrir pelo menos uma falha, o numero esperado
e o numero de falhas descobertas durante os testes, o tempo medio entre as falhas
ou ate a ocorrencia da primeira delas ajuda na sua classificacao. Assim pode-se
estimar a probabilidade de que o software ira falhar apos sua implantacao, ja que
algumas falhas podem tornar a ocorrer.
Q7. Que medidas foram utilizadas para avaliar os riscos identificados?
18 estudos nao responderam como foram avaliados os riscos durante o seu gerencia-
mento [S4] [S7] [S9] [S10] [S11] [S12] [S13] [S14] [S24] [S25] [S29] [S32] [S33] [S37] [S41]
[S44] [S49] [S53]. Estas abordagens relatavam as possıveis tecnicas e ate mesmo como
eram agrupados os riscos durante a sua gestao, mas nao se preocuparam no aspecto de
avaliacao do risco, ou seja, quais riscos se encaixavam em determinados grupos de risco.
A tecnica de avaliar o risco consiste nas fases de identificacao, analise e priorizacao,
como ja mencionado na resposta a questao 2. Mas a questao 7 se preocupa em responder
como foram priorizados os riscos identificados e analisados. Algumas organizacoes utilizam
listas prontas de riscos ja priorizados em forma de experiencias passadas [S2] [S19] [S22]
[S23] [S35] ou montam a sua propria lista [S30] para servir de referencia a trabalhos
futuros, outras utilizam formulas matematicas para prioriza-los [S23] [S47], e ainda tem
aqueles, [S5] [S8] [S15] [S16] [S19] [S20] [S26] [S27] [S28] [S35] [S36] [S38] [S42] [S43]
[S46] [S47] [S40], que atribuem valores de priorizacao multiplicando valores caracterısticos
do risco como probabilidade e frequencia de ocorrencia, impacto do risco no projeto,
gravidade e causas, determinando assim o seu grau de importancia.
Na figura a seguir e mostrada a matriz de analise de riscos seguindo o modelo criado
por Boehm, onde cada risco e classificado por meio da combinacao entre probabilidade de
ocorrencia dos riscos e a perda causada por eles. A partir desta analise podem-se combinar
os resultados de todos os riscos para obter uma media geral e obter a porcentagem de
riscos do projeto [S3].
Os testes [S6] [S14] [S17] [S27] [S28] [S35] [S47] [S49] [S50] tambem sao meios de
atribuir valores aos riscos, pois atraves do resultado deles pode-se ter uma nocao de qual
risco e mais importante a ser tratado dentro do projeto. Os requisitos tambem ajudam a
priorizar os riscos, ja que o objetivo do projeto e atender as necessidades do cliente, logo,
uma forma de avaliar os riscos associados a um programa, e distinguir as falhas de acordo
32
Figura 5.3: Matriz de analise do nıvel de risco - Figura adaptada da original por
[Adler et al., 1998]
com a sua importancia.
Priorizar os riscos depois de eles acontecerem, para medir sua probabilidade e impacto
tambem e uma forma de separa-los, e matrizes que servem como repositorio para analise
ou modelo de matrizes para classificacao, tambem sao muito utilizados [S15] [S18]. Alem
da utilizacao de planilhas [S20] e frameworks [S39]. A classificacao dada para cada risco
como a sua probabilidade de ocorrencia, impacto, gravidade, dentre outras caracterısticas,
sao pontuadas de acordo com o projeto em que e aplicada a RM e a experiencia do gestor
do projeto entende ser mais importante ou nao.
Tentar prever os riscos que podem aparecer [S26] e fazer pesquisas [S48] sobre outros
projetos semelhantes sao tecnicas adotadas para priorizacao dos riscos que e considerada
tao importante porque influencia a forma como os riscos sao comunicados e compreendi-
dos pelos participantes de um projeto. Sem uma avaliacao de risco fica difıcil construir
um sistema de alta qualidade e custo-benefıcio.
Q8. A ferramenta permite a realizacao de RM em todo o processo de de-
senvolvimento?
Apenas 4 estudos relatam sobre ferramentas de RM [S2] [S3] [S8] [S20], que utilizam
formula matematica para calcular o impacto do risco, os avalia precocemente, os ar-
mazenam e trabalham de forma a os analisar qualitativa e quantitativamente [S8].
O outro grupo de estudos que nao relatam sobre ferramentas apontam tecnicas e abor-
dagens de RM em todo o processo [S1] [S6] [S7] [S13] [S14] [S15] [S18] [S19] [S22] [S23]
[S24] [S26] [S27] [S30] [S31] [S37] [S38] [S40] [S42] [S44] [S45] [S46] [S47] [S51] [S53] ou ape-
nas uma tecnica que deve ser utilizada no processo todo, como exemplo, o monitoramento
dos riscos.
Alguns abordavam somente parte do processo de desenvolvimento, como o levanta-
mento de requisitos [S21] [S33] [S34] e testes [S28] [S35] [S50] orientados a riscos.
33
Tabela 5.1: Resultado de avaliacao dos estudos em relacao as questoes de qualidade.
Numeros de Estudos
Questao de
Qualidade
Respostas Artigos Total
QC1
Sim S1,S2,S3,S5,S7,S8,S9,S11,S12,S13,S14,S15,S16,
S17,S18,S19,S20,S21,S22,S23,S24,S25,S26,S27,S28,
S29,S30,S31,S32,S33,S34,S35,S36,S37,S38,S39,S40,
S41,S42,S43,S44,S45,S46,S47,S48,S49,S50,S51,S52,
S53
50
Em Parte S6 1
Nao S4,S10 2
QC2
Sim S1,S14,S38,S42 4
Em Parte S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S13,S15,S16,S17,
S18,S19,S22,S23,S24,S26,S27,S28,S30,S33,S35,S36,
S37,S39,S43,S44,S45,S46,S47,S48,S51,S52,S53
37
Nao S12,S20,S21,S25,S29,S31,S32,S34,S40,S41,S49,S50 12
QC3
Sim 0
Em Parte S3,S4,S5,S6,S7,S8,S9,S13,S14,S15,S16,S18,S22,S23,
S24,S27,S28,S30,S35,S38,S39,S42,S43,S45,S46,S47,
S48,S50,S51,S52,S53
31
Nao S3,S4,S5,S6,S7,S8,S9,S13,S14,S15,S16,S18,S22,S23,
S24,S27,S28,S30,s35,S38,S39,S42,S43,S45,S46,
S47,S48,S50,S51,S52,S53
22
QC4
Sim S1,S2,S5,S6,S7,S8,S9,S14,S15,S16,S17,S18,S19,S20,
S22,S23,S24,S25,S26,S27,S30,S31,S36,S37,S38,S39,
S40,S41,S42,S43,S44,S46,S47,S48,S49,S51,S52
37
Em Parte S3,S4,S10,S11,S29,S34,S35,S45,S50,S53 10
Nao S12,S13,S21,S28,S32,S33 6
Continua na proxima pagina
34
Questao de
Qualidade
Respostas Artigos Total
QC5
Sim S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S12,S13,S14,S16,
S17,S18,S19,S20,S22,S23,S24,S25,S26,S27,S28,S29,
S30,S31,S32,S33,S34,S35,S36,S37,S38,S39,S40,S41,
S42,S43,S44,S46,S47,S48,S49,S51,S52,S53
48
Em Parte S15,S50 2
Nao S11,S21,S45 3
QC6
Sim S2,S5,S6,S7,S8,S9,S14,S15,S17,S18,S19,S20,S22,
S24,S25,S26,S27,S28,S30,S31,S35,S36,S37,S38,S39,
S40,S42,S46,S47,S48,S49,S51
32
Em Parte S1,S12,S16 3
Nao S3,S4,S10,S11,S13,S21,S23,S29,S32,S33,S34,S41,
S43,S44,S45,S50,S52,S53
18
QC7
Sim S1,S5,S6,S9,S15,S23,S30,S32,S33,S34,S35,S36,S37,
S38,S39,S41,S42,S46
18
Em Parte S4,S10,S11,S17,S27,S31,S14,S21 8
Nao S2,S3,S7,S8,S12,S13,S16,S18,S19,S20,S22,S24,S25,
S26,S28,S29,S40,S43,S44,S45,S47,S48,S49,S50,S51,
S52,S53
27
QC8
Sim S8,S14,S17,S28,S29,S41,S45,S46 8
Em Parte S5,S15,S16 3
Nao S1,S2,S3,S4,S6,S7,S9,S10,S11,S12,S13,S17,S18,S19,
S20,S21,S22,S23,S24,S25,S26,S27,S30,S31,S32,S33,
S34,S35,S36,S37,S39,S40,S42,S43,S44,S47,S48,S49,
S50,S51,S52,S53
42
35
Tabela 5.2: Artigos Selecionados pela SR
ID Tıtulo Pontuacao
S1 Usando GQM para Gerenciar Riscos em Projetos de Software. 5.5
S2 A Bayesian Belief Network Model And Tool To Evaluate Risk And
Impact In Software Development Projects.
4.5
S3 Architectural Level Risk Assessment Tool Based on UML Speci-
fications.
3.5
S4 An Assessment Approach To Analyzing Benefits And Risks of
Product Lines.
3
S5 An Industrial Case Study of Implementing Software Risk Man-
agement.
6.5
S6 A Strategy for Managing Risk in Component-based Software De-
velopment.
5.5
S7 BBM-Based Software Project Risk management. 5
S8 Combining the Best Attributes of Qualitative and Quantitative
Risk Management Tool Suport.
6
S9 Communicating Risk Information in Agile and Traditional Envi-
ronments.
6
S10 Developing, Validating and Evolving an Approach to Product Line
Benefit and Risk Assessment.
2.5
S11 Decision and Risk Analysis for process evolution. 2.5
S12 Educating Software Engineering Students to Manage Risk. 2.5
S13 Evolution of the Use and Risks of Commercial Software Compo-
nents.
3
S14 Development and application of a Risk Assessment Tool. 7
S15 Insight into Risk Management in Five Software Organizations. 6
S16 Intelligent Risk Management Tools for Software Development. 5
S17 Supporting risks in software Project management. 5
S18 Risk management for IT in the large. 5.5
S19 Risk and risk management in software projects a reassessment. 4.5
S20 The one-minute Risk Assessment Tool. 4
S21 The Top Risks of Requirements Engineering. 1
S22 Software Risk Management: Principles and practices. 5
S23 The Influence of Checklists and Roles on Software Practitioner
Risk Perception and Decision-Making.
5
S24 The Role of Software Process Simulation Modeling in Software
Risk Management: a Systematic Review.
5
S25 Outlining a Model Integrating Risk Management and Agile Soft-
ware Development.
4
Continua na proxima pagina
36
ID Tıtulo Pontuacao
S26 The Intertwining Between Risk and Project Management. 4.5
S27 Managing a Man-Rated Software Development Program via Risk
Mitigation.
5.5
S28 Theory and practice of risk-based testing. 5
S29 Risk assessment on distributed software projects. 3.5
S30 Putting risk management into practice. 6
S31 Software Risk Management barriers an empirical Study. 4.5
S32 Risk Management during requeriments. 3
S33 Requirements, Architectures and Risks. 3.3
S34 A Lightweight Technique for Assessing Risks in Requirements
Analysis.
3.3
S35 Exploring risk based testing and its implications. 5.5
S36 A Framework Identifying Software Project Risk. 5.5
S37 Risk management in challenging business software projects. 5.5
S38 Software Risk Management Process Model Tool. 6.5
S39 Software project risks and their effect on outcomes. 6
S40 Software development risks to project effectiveness. 4
S41 An Information Architecture for Risk Assessment and Manage-
ment.
5
S42 Risky business: What we have yet to learn about software risk
management.
6.5
S43 A Graphical Approach to Risk Identification, Motivated by Em-
pirical Investigations.
4
S44 A State-of-the-Practice Survey on Risk Management in Develop-
ment with Off-The-Shelf Software Components.
3.3
S45 Adapting Secure Tropos for Security Risk Management in the
Early Phases of Information Systems Development.
2.5
S46 Analise do tratamento de riscos em projetos de desenvolvimento
de software de uma organizacao.
7
S47 Risk management for sofware projects. 5
S48 Components of Software Development Risk: How to Address
Them - A Project Manager Survey.
5
S49 Dealing with Risk in Scientific Software Development. 4
S50 Testing software to detect and reduce risk. 2.5
S51 Improving risk management: moving from risk elimination to risk
avoidance.
5
S52 Model-Based Performance Risk Analysis. 4
S53 Stochastic simulation of risk factor potential effects for software
development risk management.
3.5
37
Capıtulo 6
Discussao
Apesar de existir varios artigos sobre gestao de riscos, nem todos apresentam a sua
gerencia em projetos da metodologia SPL. Alguns abordam apenas metodos ou etapas
para realizacao deste gerenciamento sem relatar sobre algum tipo de ferramenta que faca
esse trabalho.
Depois de estudar os principais aspectos sobre revisao sistematica e a metodologia
SPL, a escolha do escopo de pesquisa foi feita visando a falta de publicacoes referentes ao
tema e ferramentas que auxiliem esse processo.
O processo da revisao foi demorado e complexo devido ao numero de fontes existentes
ligadas a engenharia de software. O controle e documentacao da SR foi feito usando
planilhas, por ser mais facil de usar e visualizar o estado e resultados da pesquisa.
6.1 Principais Resultados
Gestao de riscos em desenvolvimento de software ainda e uma etapa difıcil a se adotar
pelas organizacoes (tanto industrial quanto academica) porque elas ainda nao conhecem
seu valor, nao entendem como realiza-la, por acharem difıcil colocar a teoria estudada em
pratica, ou acham o seu custo elevado [Odzaly et al., 2009].
Varios estudos sobre gestao de riscos nao explicam em detalhes como realiza-la, pois
apresentam somente um aspecto geral da gestao como identificacao, priorizacao, analise e
monitoramento. Algumas organizacoes aplicam parte ou nenhum tipo de gestao de riscos.
Na figura 5.1 e mostrado o criterio de qualidade dos artigos sobre a utilizacao de
ferramentas de risco. Alguns oferecem quase que nenhuma ajuda neste aspecto, mas
apresentam de forma geral ou em partes o modo adotado de gerenciamento de riscos.
38
6.1.1 O que deve ser considerado
O primeiro passo para a RM e calcular os benefıcios e riscos do desenvolvimento de
um projeto de software, assim pode-se prever os possıveis riscos a surgir e verificar se
e viavel ou nao o desenvolvimento de uma SPL. Os passos mais relevantes a gestao de
riscos sao a avaliacao e controle destes que englobam a identificacao, analise e priorizacao
e planejamento, resolucao e monitoramento, consecutivamente.
Outras estrategias utilizadas na gestao de riscos sao os questionarios e listas de riscos
para avaliacao. Para facilitar este trabalho, existem as ferramentas de simulacao de
dados, monitoramento, avaliacao e diferentes tipos de documentacao, planilhas ou simples
editores de texto.
Os riscos da fase de levantamento de riscos devem ser levados em conta, pois sao
eles que descrevem o desejo do cliente. Deixar o cliente ciente de orcamentos, prazos e
riscos e necessario e difıcil de realizar, porque ele pode nao entender dos termos tecnicos
utilizados no processo alem de utilizar tempo do pessoal da equipe para reunioes. Ter um
bom relacionamento com cliente e importante para melhor entender suas necessidades e
desenvolver as funcionalidades de maneira correta.
A industria e a que mais estuda e utiliza a gestao de riscos, como visto na resposta a
questao 3 no capıtulo 5, logo, sempre tem o seu foco voltado para o sucesso e cronograma
do negocio, ja que ele deve garantir ao cliente a entrega no prazo planejado. Independente
do ambiente de trabalho, a gestao de riscos inclui o monitoramento desses durante todo o
projeto de desenvolvimento, pois e necessario acompanhar as fases do risco e decidir quais
acoes a tomar.
6.2 Riscos
Apesar das abordagens SPL e SSD descreverem maneiras diferentes de desenvolvi-
mento de software, e possıvel identificar caracterısticas relacionadas a ambas. De acordo
com [Wijnstra, 2002], ha pouca pesquisa sobre gestao de riscos em SPL.
O estagio de domınio do projeto deve ser cuidadosamente definido, a fim de minimizar
falhas no futuro, pois o custo de reparacao de um erro de reconhecimento de domınio
pode ser caro na metodologia SPL. As estrategias de identificacao de domınio diferem
nas duas metodologias pelo fato da SPL conter as disciplinas de engenharia de domınio e
aplicacao, que a SSD nao apresenta da mesma forma.
Ja as principais tecnicas como, identificar, analisar, priorizar e relatar os riscos sao
semelhantes as duas metodologias. Foi considerada nas duas abordagens a importancia de
identificar corretamente os riscos e calcular sua probabilidade de ocorrencia combinado ao
seu impacto. O que precisa ser considerado em especial a SPL e o mecanismo em relacao
39
as disciplinas.
A definicao de papeis tambem e importante para uma boa gestao em ambas as
metodologias. Para a SPL e importante a gestao de riscos lidar com a reutilizacao de
artefatos bem como garantir a documentacao e mapeamento da linha de produtos. Re-
utilizacao carrega um nıvel maior de complexidade, logo, desenvolver artefatos reusaveis
e lidar com eles representa uma categoria suscetıvel a riscos.
Itens comuns de riscos as duas metodologias podem ser: atraso de entrega, ma gestao
de riscos, problemas com pessoal, custo de desenvolvimento. Metodos sao definidos de
modo a alcancar objetivos particulares, e devido a concorrencia, atrasos sao inaceitaveis.
Os problemas de pessoal como, por exemplo, motivos emocionais podem interferir nisso
tambem.
6.3 Licoes Aprendidas
Uma vez que a revisao foi realizada, foi possıvel identificar as principais atividades de
gestao de riscos colocadas em pratica nas organizacoes e o uso de ferramentas para isso.
E importante observar os seguintes aspectos ao executar atividades de gerenciamento de
risco para um projeto de software:
• Previsao e avaliacao dos riscos:
E importante avaliar os riscos e benefıcios de se desenvolver um projeto, para isso
e preciso prever os riscos que podem ocorrer e avalia-los. Mas muitos aspectos
contribuem para os riscos do projeto nas tomadas de decisoes como a emocao, cultura
e maturidade.
• Considerar modelos de RM ja prontos:
Metodo Riskit e FMEA sao exemplos de modelos de gestao de riscos bastante uti-
lizados pelas organizacoes. Criar cenarios de riscos ou documenta-los em detalhes
ajuda os profissionais de software a lidar com o processo de gerenciamento de riscos
do projeto. Mas e importante estar ciente que modelos prontos podem nao garantir
eficacia na gestao de riscos por nao abrangirem todos os aspectos.
• Stakeholders:
Cada parte interessada pode definir os riscos e seus impactos de formas diferentes.
E necessario considerar cada definicao e deixar claro a todos o entendimento so-
bre cada risco. Reunioes entre as partes interessadas sao necessarias para decidir
as tomadas de decisao, acompanhar status do processo de RM, definir papeis e
responsabilidades, analisar estado de cronograma e custos, e outros.
40
• Etapas da RM:
Cada organizacao e livre para escolher como aplicar a gestao de riscos. A forma
como ela sera desenvolvida e realizada deve ser definida por gestores de projetos e
de riscos da equipe de desenvolvimento. A forma como a ferramenta ira facilitar
esse trabalho e um dos pontos a serem discutidos, pois, percebe-se que por meio dos
resultados da SR, algumas ferramentas realizam parte da gestao de riscos, como o
monitoramento e calculo probabilidade e gravidade do risco, por exemplo, deixando
algumas etapas nas maos da equipe, como a escolhas das acoes a se tomar caso um
risco ocorra.
6.4 Limitacoes do Projeto
As limitacoes da revisao devem ser discutidas a fim de avaliar a validade do trabalho.
• Processo de Busca:
Todo o processo de coleta foi executado manualmente, exceto a primeira etapa das
rodadas, que e a busca por estudos por meio de strings. Uma analise cuidadosa foi
feita sobre uma serie de estudos interessantes a RM que poderiam ser perdidos caso
fosse feita uma pesquisa casual.
• Subjetividade
Os resultados da SR podem ser interpretados de diferentes formas por outros pesquisadores,
pois para cada estudo selecionado sao realizadas as respostas as questoes de pesquisa
e avaliacao da qualidade, a fim de chegar a um consenso sobre ferramentas de geren-
ciamento de riscos.
• Avaliacao de Qualidade
Os criterios de qualidade, questoes de pesquisa, fontes de dados, strings e respostas
foram criados para recolhimento de resultados de qualidade, mesmo alguns artigos
nao abordando necessariamente o tema da SR, e sim assuntos referentes a gestao de
riscos.
41
Capıtulo 7
Conclusao
O principal motivo para construcao do trabalho foi a preocupacao em adotar a gerencia
de riscos como parte da gestao de desenvolvimento de software e o uso de ferramentas
que auxiliem nesse processo. Assim, reunir caracterısticas e metodos de gestao de riscos
em todas as fases de um projeto de software visa atender e suprir essas necessidades da
gerencia de riscos em projetos de SPL.
O estudo oferece uma visao sobre gestao de riscos em duas metodologias (SSD e SPL)
visando auxiliar profissionais da area a adotarem esta etapa em seu trabalho de gestao de
projetos de software, ja que os riscos e suas categorias sao analisados e documentados assim
como as diversas tecnicas, como o uso de ferramentas, adotadas para o gerenciamento
destes. A pesquisa e realizada sobre fontes relevantes a engenharia de software e seus
resultados apontam o quao importante a RM e para a elaboracao e sucesso de um projeto.
O gerenciamento de riscos auxilia na avaliacao de riscos e benefıcios de se realizar
um projeto, na deteccao de riscos antes deles acontecerem, na mitigacao destes e no
monitoramento durante todo o processo de desenvolvimento.
Assim, este trabalho fornece medidas e ideias uteis tanto a industria quanto a academia
sobre o gerenciamento de riscos, suas vantagens e tecnicas para realiza-la.
7.1 Trabalhos Futuros
Para complementar os resultados da revisao sistematica, seria interessante analisar
e comparar resultados de outras revisoes do tipo com o mesmo foco do trabalho em
questao, que e ferramentas de gerenciamento de riscos em projetos de software. Uma
outra proposta interessante aos resultados do trabalho seria encaminha-los as pessoas
interessadas na tentativa de aplicar as tecnicas e abordagens de gestao de riscos nos
metodos de gerenciamento de projetos das empresas.
42
Referencias
Adler, T. R., Leonard, J. G., e Nordgren, R. K. (1998). Improving risk management:
moving from risk elimination to risk avoidance. Information and Software Technology.
Aguiar, M. (2002). Gerenciando riscos nos projetos de software. Developers Magazine.
BOEHM, B. W. (1991). Software risk management: Principles and practices. IEEE
Software.
Clements, P. e Northrop, L. (2001). Software product lines: Practices and patterns.
Addison-Wesley, Reading, Massachusetts.
Junior, E. A. O. (2007). O processo de revisao sistematica.
Kirner, T. G. e Goncalves, L. E. (2007). Software risk management: a process model and
a tool. Graduate Program in Computer Science Methodist University of Piracicaba -
SP, Brasil.
Kitchenham, B. (2007). Guidelines for performing systematic literature reviews in soft-
ware engineering. Software Engineering Group, School of Computer Science and Math-
ematics, Keele University, Keele, Staffs. ST5 5BG, UK. And Department of Computer
Science, University of Durham, Durham, UK.
Knob, F., Silveira, F., Orth, A. I., e Prikladnicki, R. (2006). Riskfree uma ferramenta de
gerenciamento de riscos baseada no pmbok e aderente ao cmmi. Simposio Brasileiro de
Qualidade de Software - Vila Velha (ES).
Odzaly, E. E., Greer, D., e Sage, P. (2009). Software risk management barriers: an
empirical study. Third International Symposium on Empirical Software Engineering
and Measurement.
Oliveira, S. R. B., Rocha, T. A., e Vasconcelos, A. M. L. (2004). Critical factors for a
successful platform-based product family approach. Anais do Simposio Internacional
de Melhoria de Processos de Software - SIMPROS, Sao Paulo (SP).
PMI (2004). Project management institute - a guide to the project management body of
knowledge. 3a edition. PMBOK Guide.
Pohl, K., Bockle, G., e Linden, F. V. (2005). Software product line engineering - founda-
tions, principles, and techniques. Springuer - Verlag, New York, USA.
Pressman, R. (2006). Engenharia de software. 6a edicao. McGraw-Hill.
43
Schmid, K. (2001). An assessment approach to analyzing benefits and risks of product
lines. Computer Software and Applications Conference, 2001. COMPSAC 2001. 25th
Annual International. Chicago, Illinois (USA).
Scoy, R. L. V. (1992). Software development risk : Opportunity, not problem. SEI,
CMU/SEI-92-TR- 30.
Toledo, J. e Amaral, D. (2006). Fmea - analise do tipo e efeito de falha. GEPEC - Grupo
de Estudos e Pesquisa em Qualidade, DEP - UFSCar.
Wijnstra, J. G. (2002). Adequacao de processos para fabricas de software. IProceedings
of the Second international Conference on Software Product Lines.
44
Apendice A
Fontes
Tabela A.1: Maquinas de Busca
Maquinas de Busca
ISI web Knowledge (www.isiknowledge.com)
Info Scopus (info.scopus.com)
ACM (portal.acm.org/dl.cfm)
IEEE Xplore (ieeexplore.ieee.org/Xplore)
IEEE Computer (www2.computer.org/portal/web/csdl)
SpringerLink (www.springerlink.com)
ScienceDirect (www.sciencedirect.com)
Elsevier (www.elsevier.com)
45
Tabela A.2: Conferencias
Conferencias
International Conference on Software Engineering (ICSE)
International Computer Software and Applications Conference (COMPSAC)
European Software Engineering Conference (ESEC)
Foundations of Software Engineering (SIGSOFT FSE)
Automated Software Engineering (ASE)
Conference on Advanced Information Systems Engineering (CAiSE)
Software Engineering and Knowledge Engineering (SEKE)
Fundamental Approaches to Software Engineering (FASE)
Software Engineering and Advanced Applications (SEAA)
ACM Symposium on Applied Computing (SAC)
Symposium on Code Generation and Optimization (CGO)
International Conference on Model Transformation (ICMT)
Model Driven Engineering Languages and Systems (MoDELS)
Generative Programming and Component Engineering (GPCE)
Conference on Object-Oriented Programming Systems, Languages, and Applications (OOP-
SLA)
Technology of Object-Oriented Languages and Systems (TOOLS)
Empirical Software Engineering and Measurement (ESEM)
IEEE International Software Metrics Symposium (METRICS)
International Conference on the Software Process (ICSP)
International Conference on Quality Software (QSIC)
International Conference/Workshop on Program Comprehension (IWPC)
Working Conference on Reverse Engineering (WCRE)
IEEE International Conference on Software Maintenance (ICSM)
Conference on Software Maintenance and Reengineering (CSMR)
Requirements Engineering (RE)
Software Product Lines (SPLC)
International Conference on Software Reuse (ICSR)
Component-Based Software Engineering (CBSE)
International Conference on Software Testing, Verification, and Validation (ICST)
International Symposium on Software Testing and Analysis (ISSTA)
Working IEEE/IFIP Conference on Software Architecture (WICSA)
European Conference on Software Architecture (ECSA)
Quality of Software Architectures (QoSA)
Simposio Brasileiro de Qualidade de Software (SBQS)
Congresso Brasileiro de Software: Teoria e Pratica (CBSoft)
Simposio Brasileiro de Engenharia de Software (SBES)
46
Tabela A.3: Journals
Journals
ACM Transactions on Software Engineering and Methodology (TOSEM)
Communications of the ACM (CACM)
IEEE Computer
IEEE SOFTWARE
Journal IEEE Transaction on Software Engineering (TSE)
IET Software Journal
Information & Software Technology (INFSOF)
Journal of Software Maintenance and Evolution: Research and Practice (SMR)
Journal of Systems and Software (JSS)
Software Practice and Experience (SPE)
Software Process: Improvement and Practice (SOPR)
Software Quality Journal (SQJ)
Automated Software Engineering (ASE)
Requirements Engineering (RE)
Journal of Object Technology (JOT)
Journal of Software (JSW)
IBM Journal of Research and Development
Journal of the Brazilian Computer Society (JBCS)
International Journal of Software Engineering and Knowledge Engineering (IJSEKE)
Empirical Software Engineering (ESE)
ACM SIGSOFT Software Engineering Notes (SIGSOFT)
Software Testing, Verification & Reliability Journal (STVR)
ACM Computing Surveys (CSUR)
47
Apendice B
Estudos
Tabela B.1: Artigos Selecionados pela SR
ID Artigo Ano Principal Autor
S1 Usando GQM para Gerenciar Riscos em Projetos de Software. 2004 Lisandra Fontoura
S2 A Bayesian Belief Network Model And Tool To Evaluate Risk And
Impact In Software Development Projects.
2004 Hui, AKT
S3 Architectural Level Risk Assessment Tool Based on UML Speci-
fications.
2003 T. Wang
S4 An Assessment Approach To Analyzing Benefits And Risks of
Product Lines.
2001 Klaus Schmid
S5 An Industrial Case Study of Implementing Software Risk Man-
agement.
2001 Bernd G. Freimut
S6 A Strategy for Managing Risk in Component-based Software De-
velopment.
2001 Gerald Kotonya
S7 BBM-Based Software Project Risk management. 2004 Chin-Feng Fan
S8 Combining the Best Attributes of Qualitative and Quantitative
Risk Management Tool Suport.
2000 Martin S. Feather
S9 Communicating Risk Information in Agile and Traditional Envi-
ronments.
2007 Jaana Nyfjord
S10 Developing, Validating and Evolving an Approach to Product Line
Benefit and Risk Assessment.
2002 Klaus Schmid
Continua na proxima pagina
48
ID Artigo Ano Principal Autor
S11 Decision and Risk Analysis for process evolution. 2001 Sami Beydeda
S12 Educating Software Engineering Students to Manage Risk. 2001 Barry W. Boehm
S13 Evolution of the Use and Risks of Commercial Software Compo-
nents.
2002 Paivi Kallio
S14 Development and application of a Risk Assessment Tool. 2008 Aref Majdara
S15 Insight into Risk Management in Five Software Organizations. 2009 Mira Kajko-
Mattsson
S16 Intelligent Risk Management Tools for Software Development. 2009 John Dhlamini
S17 Supporting risks in software Project management. 2004 Marcio de Oliveira
Barros
S18 Risk management for IT in the large. 1999 Denis Verhoef
S19 Risk and risk management in software projects a reassessment. 2008 Paul L. Bannerman
S20 The one-minute Risk Assessment Tool. 2004 Amrit Tiwana
S21 The Top Risks of Requirements Engineering. 2001 Brian Lawrence
S22 Software Risk Management: Principles and practices. 1991 Barry W. Boehm
S23 The Influence of Checklists and Roles on Software Practitioner
Risk Perception and Decision-Making.
2008 Mark Keil
S24 The Role of Software Process Simulation Modeling in Software
Risk Management: a Systematic Review.
2009 Dapeng Liu
S25 Outlining a Model Integrating Risk Management and Agile Soft-
ware Development.
2008 Jaana Nyfjord
S26 The Intertwining Between Risk and Project Management. 2001 Karol Fruhauf
S27 Managing a Man-Rated Software Development Program via Risk
Mitigation.
2008 Julia F. Varnell-
Sarjeant
S28 Theory and practice of risk-based testing. 2005 Felix Redmill
S29 Risk assessment on distributed software projects. 2010 Adailton Mag-
alhaes Lima
S30 Putting risk management into practice. 1997 Raymond C.
Williams
S31 Software Risk Management barriers an empirical Study. 2009 Edzreena Edza
Odzaly
S32 Risk Management during requeriments. 2003 Tom DeMarco
S33 Requirements, Architectures and Risks. 2003 James D. Kiper
S34 A Lightweight Technique for Assessing Risks in Requirements
Analysis.
2008 K. Boness
S35 Exploring risk based testing and its implications. 2004 Felix Redmill
S36 A Framework Identifying Software Project Risk. 1998 Mark Keil
S37 Risk management in challenging business software projects. 2002 Frank Schoenthaler
S38 Software Risk Management Process Model Tool. 2007 Tereza G. Kirner
S39 Software project risks and their effect on outcomes. 2004 Linda Wallace
S40 Software development risks to project effectiveness. 2000 James J. Jiang
Continua na proxima pagina
49
ID Artigo Ano Principal Autor
S41 An Information Architecture for Risk Assessment and Manage-
ment.
1997 Paul R. Garvey
S42 Risky business: What we have yet to learn about software risk
management.
2000 Shari Lawrence
Pfleeger
S43 A Graphical Approach to Risk Identification, Motivated by Em-
pirical Investigations.
2006 Ida Hogganvik
S44 A State-of-the-Practice Survey on Risk Management in Develop-
ment with Off-The-Shelf Software Components.
2008 Jingye Li
S45 Adapting Secure Tropos for Security Risk Management in the
Early Phases of Information Systems Development.
2008 Raimundas Matule-
vicius
S46 Analise do tratamento de riscos em projetos de desenvolvimento
de software de uma organizacao.
2005 Viviane Dias Mal-
heiros de Pinho
S47 Risk management for sofware projects. 1994 Richard E. Fairley
S48 Components of Software Development Risk: How to Address
Them? A Project Manager Survey.
2000 Janne Ropponen
S49 Dealing with Risk in Scientific Software Development. 2008 Rebecca Sanders
S50 Testing software to detect and reduce risk. Phyllis G. Frankl
S51 Improving risk management: moving from risk elimination to risk
avoidance.
1999 Terry R. Adler
S52 Model-Based Performance Risk Analysis. 2005 Vittorio Cortellessa
S53 Stochastic simulation of risk factor potential effects for software
development risk management.
2001 Dan X. Houston
50
Apendice C
Fatores de Risco
Tabela C.1: Resultado de avaliacao dos estudos em relacao as questoes de qualidade.
Categoria Identificacao Fatores de Risco
Cliente
1. Ausencia de participacao
2. Resistencia a mudancas
3. Falta de comprometimento
4. Conflito entre clientes
5. Condicoes irrealizaveis
6. Perder cliente
Requisitos
7. Nao representam a necessidade do cliente
8. Usar modelos prontos
9. Mudanca de requisitos
10. Requisitos nao sao claros
11. Nao atender requisitos legais
Gestao e tecnicos
12. Equipe nao familiarizada com ferramentas
13. Equipe nao familiarizada com processo e metodos
de ES
14. Membros da equipe em varios projetos
15. Rotatividade
16. Desenvolver funcao errada
17. Deficit de desempenho
18. Falta de inspecao e revisao
19. Conflito entre cliente e equipe de desenvolvimento
Continua na proxima pagina
51
Categoria Identificacao Fatores de Risco
Gestao e tecnicos
20. Membros inexperientes
21. Equipe nao saber o objetivo do projeto
22. Atraso na entrega
23. Falta de experiencia com ambiente de desenvolvi-
mento
24. Falta de conformidade dos padroes de desenvolvi-
mento
25. Insercao de novas tecnologias
26. Nao dominar o conhecimento sobre variabilidade
27. Diferentes culturas
28. Nao saber distribuir competencias
29. Mudanca
30. Depender de fornecedor
31. Alto nıvel de complexidade tecnica
32. Novos projetos sem relacao com anteriores
33. Inexperiencia em gestao de projetos de software
34. Concentrar no conhecimento de apenas uma pes-
soa
35. Deficiencia no uso de sub-contratacao
36. Orcamento irrealista e/ou imprevisto
37. Burocracia excessiva
38. Padroes, polıticas e metodologia inadequados
39. Falta de compromisso
40. Recursos desnecessarios
Gestao de Riscos
41. Pouca documentacao
42. Comunicacao ineficiente
43. Nao padronizacao de metodos
44. Incapaz de minimizar ou evitar riscos
45. Falta de apoio
46. Ao remover um risco acabar adicionando outro
47. Falta de experiencia com gestao de riscos
Testes 48. Testes nao encontram o erro
52