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

Dedico esse trabalho a minha famılia.

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