25
Gestão do Risco e da Qualidade no Desenvolvimento de Software Técnicas de Identificação e Avaliação de Riscos António Miguel

Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

  • Upload
    others

  • View
    6

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

Gestão do Risco e da Qualidade

no Desenvolvimento de

Software

Técnicas de Identificação e

Avaliação de Riscos

António Miguel

Page 2: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

1. Agrupamento de Riscos por Afinidade

1.1. Descrição

O método de agrupamento por afinidade tem como objectivo a agregação de itens (por exemplo, riscos) que estão naturalmente relacionados, identificando de seguida qual o conceito que liga cada agrupamento1. O agrupamento por afinidade organiza grandes quantidades de dados através do agrupamento baseado nas relações naturais entre cada item, e define os grupos de itens.

O agrupamento por afinidade pode ser feito por um indivíduo, ou por um grupo. Se realizado por grupos, uma pessoa será o facilitador e registará os resultados podendo, ou não, participar igualmente nas discussões.

1.2. Quando Utilizar

Usar este método:

§ para classificar riscos, quando não se possui uma estrutura predefinida;

§ quando é necessário pensamento inovador;

§ quando se necessita identificar questões / temas latos;

§ quando se tem uma grande lista de itens que necessita ser compreendida

Evitar o uso deste método quando se trata de coisas simples, ou que necessitem de acção rápida.

1.3. Benefícios

Este método

§ fornece um modo eficiente de ordenação de grandes quantidades de informação;

§ permite que novos padrões de informação sejam trazidos à superfície;

§ exige uma participação activa de todos os participantes no processo;

§ ajuda a identificar riscos duplicados.

1.4. Condução de um Agrupamento por Afinidade

O Quadro 1 descreve o procedimento para conduzir um agrupamento por afinidade. Este procedimento é um subconjunto dos passos descritos no capítulo Diagrama de Afinidade do The Memory Jagger +TM [Brassard 1994].

1 [Brassard 1994]: Brassard, M., The Memory Jogger +™ II: A Pocket Guide of Tools for Continuous Improvement & Effective

Planning, Methuen, MA, GOAL/QPC, 1989.

Page 3: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

Passo Acção Descrição

1 Revisão dos itens, para compreensão O facilitador assegura que todos os participantes compreendem os itens da lista.

2 Registo dos itens em cartões O facilitador regista cada item num cartão separado.

3 Exibição dos cartões e seu arranjo em grupos relacionados

O facilitador entrega os cartões aos participantes, de forma aleatória. Todos os participantes olham para dois cartões que parecem, de

algum modo, relacionados, e colocam-nos de parte. Olham igualmente para outros cartões que, ou se relacionam entre si, ou com os dois

cartões postos de parte. Os participantes repetem o processo até que todos os cartões tenham sido colocados em 7 ± 2 grupos.

4 Classificação dos grupos Os participantes olham para um cartão, em cada grupo, que exprima a ideia central que presidiu ao respectivo agrupamento. Se não existir

um cartão desses, o grupo cria um novo, que será o rótulo desse grupo.

Quadro 1 – Regras para conduzir reuniões de agrupamento por afinidade

1.5. Exemplo de Diagrama de Afinidade

Figura 1– Exemplo de diagrama de afinidade

Riscos do projecto

Riscos dosubcontratado

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos daFunção X

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos deIntegração

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

l l l

Descriçãodos itens

Títulosdos cartões

Itens

Riscos do projectoRiscos do projecto

Riscos dosubcontratado

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos dosubcontratado

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos dosubcontratado

Riscos dosubcontratado

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos daFunção X

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos daFunção X

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos daFunção XRiscos daFunção X

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos deIntegração

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos deIntegração

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Riscos deIntegraçãoRiscos deIntegração

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

Descriçãodo risco

l l l

Descriçãodos itens

Títulosdos cartões

Itens

Page 4: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

1.6. Orientações e Sugestões

} Registar os itens num meio que seja fácil de mover – Post-it ou cartões de dimensão semelhante.

} Os participantes devem mover os cartões à sua vontade, sem falar. Isto encoraja o pensamento criativo e desencoraja os argumentos sobre as específicas palavras utilizadas.

} Encorajar os participantes a reagir ao que vêem, em vez de se angustiarem sobre a colocação “certa” de um cartão. O objectivo é a rapidez do processo.

} Se um participante não gostar do sítio onde está um cartão, deve movê- lo. Eventualmente, todo o grupo chegará a um consenso.

} Não forçar a inclusão de cartões em grupos a que não pertencem. Criar uma nova categoria. Um cartão isolado pode formar um grupo próprio.

} Evitar calão, quando se escrevem os títulos dos grupos. Os títulos devem ser suficientemente claros, de modo que uma pessoa exterior ao grupo possa compreender a essência e o detalhe dos itens. O título deve conter mais que uma palavra.

} As equipas podem “produzir e organizar mais de 100 ideias, em 30 – 35 minutos [Brassard 1994].

Page 5: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

2. Técnica de Representação de Riscos por Gráficos de Barras

2.1. Descrição

Os gráficos de barras comparam um conjunto de dados, pertencentes a múltiplas categorias, mediante a respectiva representação gráfica por barras cujos comprimentos são proporcionais às medidas dos dados. Na gestão do risco, por exemplo, os gráficos podem ser usados para representar graficamente categorias de riscos e o número de riscos em cada categoria.

É um modo conveniente para dispor grandes quantidades de dados, que são de difícil interpretação na forma tabular. Esta técnica ilustra igualmente a distribuição subjacente dos dados. Por exemplo, à medida que os riscos são avaliados, são agrupados em classes de riscos relacionados. Estes dados são graficamente representados num gráfico de barras, com o objectivo de monitorização e controlo. Os gráficos são utilizados para evidenciar tendências em categorias ou classes individuais.

2.2. Exemplo

Uma equipa técnica examinou o gráfico de barras patente na Figura 2 e notou que existe, no projecto, um grande número de riscos relacionados com a actividade de testes. À medida que a codificação prossegue, os problemas com os testes vêem à superfície; contudo, a codificação ainda não se iniciou neste projecto. A análise dos riscos relacionados com os testes mostrou que os planos de testes eram inadequados. O plano de mitigação para estes riscos exigiu que o pessoal do projecto recebesse mais treino na área dos testes de software. O pessoal recebeu o treino e os riscos foram mitigados com sucesso.

Categoria

Requisitos

Recursos

Integração e Testes

Processo de Gestão

Interfaces do projecto

Desenvolvimento Número de Riscos| |

5 10

Figura 2 – Gráfico de barras de riscos

Page 6: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

3. Técnica de Avaliação Binária dos Atributos dos Riscos

3.1. Descrição

A avaliação binária de atributos é um método simples, usado para avaliar o impacto, a probabilidade e a data de ocorrência de um risco, que fornece um nível básico de análise quantitativa para os riscos. Os valores dos atributos para cada risco são determinados em definições e respostas específicas para questões relacionadas. Os valores dos atributos dos riscos são:

§ Impacto – significativo ou insignificante.

§ Probabilidade – provável ou improvável.

§ Data de ocorrência – curto prazo ou longo prazo.

A avaliação binária de atributos pode ser levada a efeito por um indivíduo, ou por um grupo. Se for realizada por um grupo, uma pessoa deverá fazer o papel de facilitador e registar as conclusões.

3.2. Quando Usar

Usar este método:

§ como um primeiro passo da análise,

§ quando é necessário discriminar um grande número de riscos,

§ na sequência das entrevistas de preenchimento do Questionário Taxinómico.

3.3. Limitações

Este método não é quantitativo. Usa uma abordagem binária qualitativa. Muitos riscos podem ter a mesma avaliação, embora o grau de cada atributo possa ser diferente. Não consegue distinguir os riscos, quando ocorrem.

Exemplo:

O Risco A e o Risco B podem ser ambos avaliados como tendo um impacto significativo, de ocorrência provável e com data de curto prazo. Contudo, para o Risco A o impacto é um atraso de 2 meses no prazo, enquanto que para o Risco B o impacto é que falha a integração e testes.

3.4. Benefícios

Este método:

§ é simples. Todos os passos são directos e expeditos.

Page 7: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

§ não exige actividades consumidoras de recursos. O método trabalha com o conhecimento que os participantes possuem,

§ é rápido. A avaliação pode ser feita numa única sessão.

3.5. Condução de uma Avaliação Binária de Atributos

3.5.1. Definições dos Atributos e Critérios

§ Um risco é significativo quando o seu impacto causa uma séria disrupção do processo, degrada o produto, ou ameaça o sucesso do projecto.

§ Um risco é de ocorrência provável, se for mais provável que improvável.

§ Um risco é curto prazo, se exigir uma acção a curto prazo.

3.5.2. Procedimento para Avaliação Individual

Passo Acção Descrição

1 Rever os riscos para compreensão

Assegurar que se compreende a definição e o contexto de cada risco.

2 Rever a definição dos atributos e as questões

Garantir que compreende as definições de • impacto significativo • ocorrência provável • data de ocorrência de curto prazo

3 Avaliar o impacto do risco Assinalar o impacto do risco como significativo, se a resposta a qualquer das seguintes questões for SIM:

• Algum utilizador verá o impacto deste risco, em termos de desempenho? funcionalidade? qualidade?

• O projecto / empresa verá o impacto deste risco, em termos de orçamento? prazo?

4 Avaliar a probabilidade do risco

Assinalar a probabilidade do risco como de ocorrência provável, se a resposta a qualquer das seguintes questões for SIM:

• já viu isto acontecer em circunstâncias similares? • existem condições, ou circunstâncias, que façam com que seja mais

provável este risco acontecer, do que não? 5 Avaliar a data de ocorrência

do risco Assinalar a data de ocorrência do risco como de curto prazo, se a resposta a

qualquer das seguintes questões for SIM: • projecto sofrerá o impacto em breve? • o projecto deve agir rapidamente?

6 Repetir os passos 3 – 5 para os restantes riscos

Quadro 2 – Procedimento de avaliação binária individual de atributos

Page 8: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

3.5.3. Procedimento para Avaliação em Grupo

Passo Acção Descrição

1 Explicar o procedimento da avaliação individual

O facilitador descreve aos participantes o modo como devem avaliar os riscos

2 Conduzir uma avaliação individual Cada participante avalia, individualmente, cada risco.

3 Seleccionar a avaliação extrema Cada participante terá seleccionado um de oito possíveis combinações para os valores dos atributos. Seleccionar a avaliação mais extrema

de cada participante (ver Quadro A4 – avaliação extrema) 4 Registar a avaliação extrema O facili tador regista / documenta a avaliação extrema, juntamente com

a descrição e o contexto do risco.

Quadro 3 – Procedimento de avaliação binária de atributos, em grupo

3.5.4. Avaliação Extrema

A ordem dos atributos é importante. Na avaliação dos riscos, os valores dos atributos agem como uma série de filtros. Os riscos avaliados como significativos, são mais importantes que os considerados insignificantes. Os riscos significativos e prováveis são mais importantes que os insignificantes, ou significativos e improváveis, etc. O Quadro 4 ilustra os valores possíveis da avaliação, que estão listados da mais extrema (em cima) para a menos extrema (em baixo).

Significativo? Provável? Curto Prazo? Valores da Avaliação

Sim Sim Sim Significativo, provável, curto prazo Não Significativo, provável, longo prazo Não Sim Significativo, improvável, curto prazo Não Significativo, improvável, longo prazo

Não Sim Sim Insignificante, provável, curto prazo Não Insignificante, provável, longo prazo Não Sim Insignificante, improvável, curto prazo Não Insignificante, improvável, longo prazo

Quadro A4.4 – Valores possíveis para a avaliação binária de atributos dos riscos

3.5.5. Ferramentas de Avaliação Binária de Atributos

No quadro seguinte mostra-se um exemplo de um formulário de avaliação que cada participante deve preencher.

Riscos Impacto Significativo Ocorrência Provável Curto Prazo

Risco A 4 4 Risco B 4 4 Risco C 4

...

Page 9: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

3.5.6. Uso de Números Binários para Seleccionar a Avaliação Extrema

Considerando os três atributos da avaliação (impacto, probabilidade e data) como números binários, a selecção da avaliação extrema pode ser simplificada. Considerando, a folha de avaliação extrema, os seguintes significados:

e

Para um risco que é avaliado, por um participante, como:

§ impacto significativo (22)

§ improvável (01)

§ data de curto prazo (20),

o número binário resultante será = 101, ou, em decimal, 22 + 01 + 20 = 5

Se outro participante avaliou o mesmo risco como:

§ impacto significativo (22)

§ provável (21)

§ data de longo prazo (00),

o número binário correspondente será = 110, ou, em decimal, 22 + 21 + 00 = 6

A avaliação extrema, atribuída por um destes participantes, é facilmente seleccionada como “6”, a qual é interpretada como “impacto significativo, provável e data de longo prazo”.

3.6. Orientações e Sugestões

} Enquanto primeira tentativa de análise, a avaliação binária de atributos é eficaz, sobretudo quando se tem um grande número de riscos. Requer poucos recursos e ajuda a evidenciar os riscos que necessitam de uma análise mais detalhada.

} Os resultados serão mais úteis se o projecto refinar os critérios com questões que façam sentido para o projecto. Quando mais específicos forem os critérios, mais fácil se tornará para os participantes avaliarem os riscos.

} Para aplicações em grupo, a disponibilidade de um software (uma folha de MS Excel é suficiente) que seleccione automaticamente a avaliação extrema, permite poupar tempo e reduzir os erros.

02 01 00

Insignificante(impacto) Improvável

(probabilidade)

Longo prazo(data)

02 01 00

Insignificante(impacto) Improvável

(probabilidade)

Longo prazo(data)

22 21 20

Significativo(impacto) Provável

(probabilidade)

Curto prazo(data)

22 21 20

Significativo(impacto) Provável

(probabilidade)

Curto prazo(data)

Page 10: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

4. Técnica de Análise de Causa e Efeito

4.1. Descrição

A análise de causa e efeito é um método de representação esquemática das relações e inter-relações entre um risco e os múltiplos factores que podem estar na sua origem. Pode ser igualmente usado para um conjunto de riscos relacionados, para determinação do conjunto colectivo de factores causais.

O processo da análise de causa e efeito é mostrado esquematicamente na Figura 3.

Figura 3 – Inputs e outputs da análise de causa e efeito

4.2. Quando Usar

A análise de causa e efeito pode ser usada

§ para identificar e verificar os factores que estão na origem de um risco, ou conjunto de riscos,

§ para identificar os factores necessários a uma estratégia de mitigação bem sucedida.

4.3. Limitações

Uma vez que o método usa o brainstorming para ajudar a identificar os factores a incluir no diagrama, aplicam-se as mesmas limitações que foram enunciadas para essa técnica.

Este método deve

§ ser usado com um grupo pequeno (menos que 9 pessoas),

§ requer um líder com boas aptidões de facilitador, de modo a poder lidar com o conflito e as emoções negativas que podem vir à superfície e que necessitam ser controladas; com as personalidades dominadoras que podem tomar o controlo;

Descrição do risco

Contexto_____________________

Análise de Causa e Efeito

Lista de causassignificativasverificadas

Diagrama deEspinha de Peixe

das causasDescrição do risco

Contexto_____________________

Análise de Causa e Efeito

Lista de causassignificativasverificadas

Diagrama deEspinha de Peixe

das causas

Page 11: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

pessoas envergonhadas que necessitam ser encorajadas, para poderem contribuir; questões e tópicos laterais e improdutivos.

4.4. Benefícios

Este método

§ documenta o conhecimento de um grupo de pessoas relativamente àquilo que provoca o risco, ou aos factores necessários ao sucesso de um plano de mitigação,

§ é um gráfico de fácil compreensão, mais significativo que uma simples lista,

§ pode ser facilmente efectuado por um indivíduo, bem como por um grupo.

4.5. Processo da Análise de Causa e Efeito

O Quadro 5 descreve o processo de condução de uma sessão de análise de causa e efeito, com um grupo.

Passo Acção Descrição

1 Discussão do item a analisar O facilitador apresenta o risco, ou a estratégia de mitigação, para o qual se pretende identificar as causas e assegura a compreensão de todos os

participantes.

2 Explicação do processo O facilitador explica o processo de causa e efeito.

3 Construção da estrutura em espinha de peixe

O facilitador traça a estrutura básica do diagrama de espinha de peixe, com o risco ou a estratégia de mitigação no lado direito do papel, e os principais factores nas “nervuras” principais (ver Figura A7.2). Os principais factores

podem incluir os seguintes: ­ pessoas ­ equipamento ou instrumentos ­ ambiente ­ material ­ métodos, processos, procedimentos ­ gestão

4 Adição de factores de causa, à estrutura de espinha de peixe

Em cada uma das principais “nervuras”, o facilitador escreve os factores que os participantes consideram ser as causas. Pode ser usado o brainstorming,

ou outro método de recolha de dados, para a identificação das causas.

5 Identificação das causas mais significativas (ou combinações)

Determinar as causas, ou combinações de causas, que contribuem de forma mais significativa para o risco e assinalá-las com círculos (por exemplo, através de discussão e votação). Recolher a informação adicional, para

verificar a relação causal, se necessário.

Quadro 5 – Processo da análise causa e efeito

4.6. Ferramentas da Análise de Causa e Efeito

Os diagramas de espinha de peixe podem ser facilmente desenhados em quadros e flip-charts, ou serem gerados por computador. A estrutura é simples: uma “cabeça” (o risco a ser analisado) e as “nervuras” (principais factores).

A Figura 4 mostra o exemplo de um risco e as causas que a ele conduziram. A causas significativa estão envoltas por um círculo.

Page 12: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

Figura 4 – Exemplo de diagrama em espinha de peixe

4.7. Recomendações e Sugestões

} Um uso menos disciplinado do método (podem ser adicionadas ao diagrama ideias e questões relacionadas, bem como causas), pode suportar uma discussão estruturada do risco ou da estratégia.

} Assinalar quaisquer causas que possam estar sob a jurisdição de outra organização. Nesses casos, pode ser necessária uma mitigação conjunta do risco.

Atraso potencialdo

subsistema ABC

Processo/Política

Ferramentas/Ambiente de SW

Hardware

PessoalTreino inadequado

Curva de aprendizagemdemasiado alta

Reutilizaçãoabaixo doplaneado

Inadequadosuporte do Hw

Contençãode custos

Estimativa originalexcedida

Planeamentode Hw & Swseparado

Testes do Hwinadequados

Contençãode custos

Pessoal chaveindisponível

Saíram apóstreino

Noutroprojecto

Problemasno compilador

Problemasno editor

Utilizadorbeta

Atraso potencialdo

subsistema ABC

Processo/Política

Ferramentas/Ambiente de SW

Hardware

PessoalTreino inadequado

Curva de aprendizagemdemasiado alta

Reutilizaçãoabaixo doplaneado

Inadequadosuporte do Hw

Contençãode custos

Contençãode custos

Estimativa originalexcedida

Planeamentode Hw & Swseparado

Testes do Hwinadequados

Contençãode custos

Contençãode custos

Pessoal chaveindisponível

Saíram apóstreino

NoutroprojectoNoutro

projecto

Problemasno compilador

Problemasno editor

Utilizadorbeta

Page 13: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

5. Técnica de Análise de Custo/Benefício

5.1. Descrição

A análise de custos/benefício, como descrita aqui, é um método simples para comparação de estimativas de custos e benefícios totais de uma estratégia de mitigação, enquanto meio de análise e de suporte à decisão, durante o planeamento dos riscos. Não é um método para calcular, de forma precisa, custos e benefícios; o seu objectivo é suportar uma decisão entre duas ou mais estratégias alternativas.

Nota: Este tipo de análise é geralmente utilizado por chefes de projecto. O Construtive Cost Model (COCOMO) de Boehm [Boehm 1981] é uma referência clássica para a estimativa dos custos do software. Quase todas as referências para gestão de projecto, tratam de métodos de estimação de custos.

O diagrama da Figura 5 mostra os inputs e os outputs da análise de custo/benefício.

Figura 5 – Inputs e outputs da análise de custo / benefício

Este método deve ser usado quando existe a necessidade de avaliar e decidir entre estratégias, ou um conjunto de acções, com base nos custos e nos benefícios do projecto.

5.2. Limitações

A análise de custo / benefício baseia-se na existência de práticas aceites de estimativas de custos (por ex., COCOMO, custos gerais por hora de empregado, custos padrão de equipamento, etc.). Se os participantes não estiverem familiarizados com o modo como a organização calcula os custos, as estimativas derivadas podem não possuir o desejado grau de rigor. Nesse caso, pode ser útil identificar os tipos de custos e benefícios (por

Estratégiaou acções

Restriçõesdo projecto

Orçamento,factores de custo,

prazo

Custos

Benefícios

Projecções

_______________

_______________

_______________

_______________

Análise decusto / benefício

Estratégiaou acções

Restriçõesdo projecto

Orçamento,factores de custo,

prazo

Custos

Benefícios

Projecções

_______________

_______________

_______________

_______________

Análise decusto / benefício

Page 14: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

ex., pessoal, PCs, ferramentas de software, etc.), até se ter à disposição peritos em custeio.

5.3. Benefícios

Este método

§ Dá, a quem decide, uma perspectiva quantitativa das alternativas,

§ ajuda quem decide a compreender o âmbito das alternativas,

§ pode não exigir muito tempo (dependendo do grau de precisão desejado).

5.4. Processo de Realização da Análise de Custo / Benefício

5.4.1. Procedimento

Passo Acção Descrição

1 Explicação da estratégia, ou conjunto de acções

O facilitador apresenta um estratégia, ou um conjunto de acções, para as quais devem ser estimados os custos e benefícios e assegura a compreensão de todos

os participantes.

2 Explicação do processo O facilitador explica o processo de análise de custo / benefício.

3 Estimação dos factores de custo

Os participantes identificam e estimam os factores de custo (todos os aspectos da estratégia que resultam em custos). As estimativas podem ser feitas numa

base resumida, ou periódica (por ex., custo por mês, ano, etc.). Os custos variáveis devem ser especificados ao longo do período de tempo relevante.

Identificar quaisquer custos intangíveis, que não possam ser estimados mas que terão um impacto na decisão.

4 Estimação dos factores de benefício

Os participantes identificam e estimam os factores de benefício. Pode ser necessário assumir pressupostos sobre os benefícios da estratégia; se for o caso,

documentar esses pressupostos. Os benefícios variáveis devem ser especificados ao longo do período de tempo relevante. Identificar quaisquer

benefícios intangíveis, que não possam ser estimados, mas que terão um impacto na decisão.

5 Revisão das estimativas de custos e benefícios

Os participantes revêem as estimativas para os custos e para os benefícios, de modo a terem resultados completos e precisos. Alterar as estimativas que se

revelem necessárias. Usar os dados para suportar a comparação entre estratégias, ou para suportar decisões.

Quadro 6 – Processo a seguir na análise de custo / benefício

5.4.2. Tipos de Custos

Os custos devem incluir tudo o que é necessário à total implementação da estratégia. Devem incluir igualmente os custos ou impactos no projecto, advindos da estratégia. Os custos podem incluir:

§ salários e benefícios sociais do pessoal

§ custos de capital em equipamento

§ acessórios/equipamento de escritório

§ ferramentas de suporte – software e documentação

Page 15: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

§ custos de formação e treino

§ atrasos na entrega/acabamento do produto

§ alterações ao plano do projecto – pontos chave, prazo, alterações aos processos (gestão ou desenvolvimento), atribuição de recursos, mudanças no pessoal

§ penalidades, ou perda de contratos

§ alterações ao sistema – requisitos, desenho, interfaces

5.4.3. Tipos de Benefícios

Os principais benefícios de uma estratégia são a redução do risco para o projecto, ou para a

organização. Existem igualmente benefícios intangíveis a considerar. Por exemplo, o custo do

treino do pessoal no projecto A, para redução de um risco, pode ser recuperado em futuros

projectos, na medida em que se dispõe agora de pessoal mais apto e competente. Os benefícios

de uma estratégia podem incluir:

§ redução da probabilidade ou do impacto de um risco

§ redução dos custos de desenvolvimento de longo prazo

§ aumento da eficiência do pessoal

§ diminuição dos prazos

§ manutenção do contrato (não o perder)

§ satisfação do cliente – o que pode conduzir a outros contratos

§ cliente ou fornecedor mais informado (e mais cooperante)

§ processos de gestão e desenvolvimento mais eficazes

§ melhoria da atribuição de recursos

§ requisitos mais realistas

§ melhoria das operações do sistema

5.5. Recomendações e Sugestões

} Os custos e benefícios podem aparecer de muitas formas; considerar todas as possibilidades.

} Muitos custos (ou benefícios) pequenos, podem conduzir a valores significativos.

} Recordar que pode haver maior benefício para a organização, do que para o projecto.

Page 16: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

} A descrição da estratégia, ou das acções, deve ser suficientemente detalhada, de modo a permitir utilizar técnicas de estimação conhecidas (as usadas pela organização), com um grau de precisão aceitável2.

} Embora os benefícios possam ser, muitas vezes, intangíveis, podem, apesar de tudo, produzir um efeito final consideráve l3.

2 Por exemplo, a estratégia “melhorar o moral dos empregados” é, em si, muito vaga. Com um objectivo mensurável, como

“reduzir a rotação do pessoal em 50%”, pode ser tomado um conjunto de acções mais detalhado, como aumentar todo o pessoal em 5%, ou eliminar o trabalho aos fins de semana.

3 Por exemplo, pode ser difícil medir as melhorias alcançadas no moral do pessoal, mas o impacto negativo de empregados

insatisfeitos pode ser severo.

Page 17: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

6. Técnica do Diagrama de Inter-relações

6.1. Descrição

O método do diagrama de inter-relações é usado para identificar as relações de causa e efeito entre um conjunto de itens. Este método é utilizado durante a fase de planeamento da gestão do risco, em que esses itens podem ser:

§ áreas de risco/mitigação: os riscos, ou conjunto de riscos, a serem mitigados,

§ estratégias: estratégias seleccionadas para um conjunto de áreas de mitigação,

§ actividades: actividades evidenciadas, num plano de mitigação, para uma área de mitigação particular.

O diagrama da Figura 6 mostra os inputs e os outputs deste método.

Figura 6 – Inputs e outputs do método do diagrama de inter-relações

Este método é usado para:

§ identificar as relações de causa e efeito, as causas raiz, etc., entre um conjunto de itens,

§ aumentar a compreensão sobre um conjunto de riscos – encontrar ciclos de dependências, ou causas raiz e identificar os riscos críticos dentro de um conjunto (quais os que devem ser mitigados),

§ determinar as inter-relações e dependências entre um conjunto de acções, ou estratégias, como suporte ao planeamento da resolução de problemas,

§ determinar quais as áreas de risco que se devem tratar primeiro.

6.2. Limitações

O resultado só pode ser tão bom quanto o conhecimento que os participantes trazem. É importante seleccionar os participantes “certos”, pois eles necessitam estar familiarizados com os itens. De acordo com Brassard [Brassard 1994, p.77], os participantes devem possuir “um conhecimento profundo do assunto em discussão”.

Itens

A

C

E

B

D

F

Diagrama de inter-relações

C

E

B

D

F

AItens

A

C

E

B

D

F

Diagrama de inter-relações

C

E

B

D

F

A

Page 18: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

6.3. Benefícios

Este método encoraja os participantes a pensar em múltiplas direcções, em vez de linearmente, isto é, permite aos participante pensar para além do óbvio, ao tentar identificar as inter-relações.

6.4. Construção de um Diagrama de Inter-relações

6.4.1. Passos a Seguir no Processo

Passo Acção Descrição

1 Revisão dos itens Rever os itens da lista, para melhor compreensão.

2 Definição da questão/ problema

Elaborar uma afirmação que resume o problema ou questão em torno dos itens. Exemplo: Estratégia seleccionada independentemente, para mitigar um conjunto de

riscos.

3 Registar os itens em cartões

Registar cada item num cartão separado.

4 Dispor os cartões Dispor os cartões de modo a que haja espaço suficiente par desenhar setas entre cartões.

5 Desenhar as setas de relações entre cartões

Olhar cada par de itens e determinar, por consenso, se existe uma relação entre eles. O item X causa, ou influencia, o item Y? Se sim, desenhar uma seta de X para Y.

Nota: Uma variação deste passo é a aplicação de um coeficiente de peso, à seta, evidenciando a força da relação.

6 Rever e corrigir, se necessário

Após comparar todos os itens, rever as relações e fazer quaisquer correcções necessárias.

7 Calcular a informação das setas

Contar e registar o número de setas que entram e saem em cada item. Se foi usado um coeficiente de peso, calcular o peso total para cada item.

8 Selecção dos itens chave

Usar a informação computada das setas, a experiência e o julgamento, para alcançar um consenso sobre os itens chave a serem trabalhados.

Quadro 7 – Processo de construção de um diagrama de inter-relações

Ao olhar para um par de itens, é possível que cada um tenha um efeito causal, ou influência, sobre o outro. Neste casos, evitar a utilização de duas setas. Reter apenas a relação que for mais forte.

Para distinguir a força relativa de uma relação, pode aplicar-se um coeficiente de peso à seta. A força de uma relação pode ser [Brassard 1994]:

§ significativa = 9

§ média = 3

§ fraca = 1

Se for utilizado o coeficiente de peso, pode computar-se um peso total para cada item, através da soma dos pesos individuais associados com cada seta que entra e que sai do item. Isto pode apontar para “itens que têm o efeito mais forte no maior número de questões” [Brassard 1994, p.81].

Um grande número de setas que saem de um item indica que ele tem um efeito causal, ou influencia um conjunto de outros itens. Isto pode sugerir que se trata de uma causa

Page 19: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

raiz, ou que esse item deve ser tratado em primeiro lugar. Este item é designado por “Causa”.

Um grande número de setas que entram num item, indica que ele é afectado, ou influenciado, por um conjunto de outros itens. Este item é designado por “Resultado”.

6.4.2. Exemplo de Cálculo do Peso Total

O exemplo abaixo, representado na Figura 7, ilustra o modo como os pesos poderão ser aplicados ao diagrama de inter-relações.

Itens N.º de setas que

saem N.º de setas que

entram Peso Total

A 2 1 13 B 1 1 6 C 1 0 1 D 0 2 12

Figura 7 – Exemplos de pesos no diagrama de inter-relações

6.5. Ferramentas para Construção do Diagrama de Inter-Relações

6.5.1. Matriz de Registo de Inter-relações

A Figura A4.8 abaixo constitui um exemplo de uma matriz para registar as inter-relações entre um conjunto de itens [Brassard 1994].

A B C D E N.º de

Causas ⇑

Nº de Resultados

Peso Total

A •

B •

C •

D •

E •

Figura 8 – Exemplo de matriz de registo de inter-relações

C B

D

A1 3

3

9

SignificativoMédio Fraco

= 9= 3= 1

ChaveC B

D

A1 3

3

9

SignificativoMédio Fraco

= 9= 3= 1

Chave

SignificativoMédio Fraco

= 9= 3= 1

SignificativoMédio Fraco

= 9= 3= 1

Chave

Page 20: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

A Figura 9 a seguir indica o modo de preencher as células da matriz, por uma pessoa, ou por consenso de um grupo.

SE ENTÃO

O item A tem um efeito causal, ou influencia o item B

O item B tem um efeito causal, ou influencia o item A

Não existe qualquer relação causal ou influência entre os itens A e B

Figura 9 – Preenchimentos das células da matriz

Nota: Caso se utilize um coeficiente de peso, ele deve ser adicionado à célula. Por exemplo, se o item A foi classificado como tendo um efeito significativo (valor = 9) sobre o item B, a célula da matriz deverá indicar o seguinte:

6.5.2. Exemplo de Matriz

Um projecto seleccionou os seus riscos e classificou-os em seis áreas para mitigação. O chefe de projecto quer determinar as dependência entre as áreas e, dada a escassez de recurso, quais as áreas que devem ser mitigadas em primeiro lugar.

Item Área de Risco

A Requisitos B Testes C Engenharia de sistemas D Gestão da configuração E Pessoal

Item B

Item A ⇑

Item B

Item A

Item B

Item A ⇐

Item B

Item A

Item B

Item A –

Item B

Item A

9 ⇑

Item B

Item A 9 ⇑

Item B

Item A

F

E

B

D

C

A

93

3

9

9

9

3

1

9

SignificativoMédio Fraco

= 9= 3= 1

ChaveF

E

B

D

C

A

93

3

9

9

9

3

1

9

SignificativoMédio Fraco

= 9= 3= 1

Chave

Page 21: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

A B C D E F N.º de

Causas ⇑

N.º de Resultados

Peso Total

A • 3 ⇑ 9 ⇑ 3 ⇑ − 9 ⇐ 3 1 24

B 3 ⇐ • 1 ⇐ 3 ⇐ 9 ⇐ 1 ⇐ 0 5 17

C 9 ⇐ 1 ⇑ • − 9 ⇐ − 1 2 19

D 3 ⇐ 3 ⇑ − • 9 ⇐ − 1 2 15

E − 9 ⇑ 9 ⇑ 9 ⇑ • − 3 0 27

F 9 ⇑ 1 ⇑ − − − • 2 0 10

Figura 10 – Exemplo de preenchimento de uma matriz de inter-relação

Da matriz acima pode-se ver que, quer os requisitos, quer o pessoal, têm o maior número de setas de saída, indicando que estes itens afectam um conjunto de outras áreas de risco, sendo então considerados itens chave. A área de testes tem o maior número de setas que entram e não tem setas que saem, indicando que é influenciada por outras áreas de risco, mas não afecta, por si, outras áreas de risco. O pessoal recebeu o peso maior, com os requisitos em segundo lugar, mas muito perto. Com base nesta informação e na experiência do chefe de projecto, os planos de mitigação serão implementados, em primeiro lugar, para as áreas de risco dos requisitos e do pessoal.

6.6. Observações e Sugestões

6.6.1. De Âmbito Geral

} Registar os itens num meio que seja fácil de mover.

} Usar 10-20 itens, para permitir uma eficácia máxima; usar um mínimo de 5 itens.

} Navegar entre os cartões de uma forma estruturada, para garantir que são feitas todas as comparações.

} limitar o número de participantes a 6.

6.6.2. Informação de Suporte

} Quando se usa este método como parte do planeamento dos riscos, é importante manter a visão global e o contexto do se pretende. Por exemplo, quando se tratam áreas de risco, é importante compreender os riscos subjacentes a cada área, bem como o seu contexto, antes de determinar relações.

} O facto de se saber que só existem recursos para mitigar uma área, em detrimento de todas as áreas, pode influenciar a escolha da área a mitigar.

} A seta e a informação sobre o peso fornecem um bom resumo das relações entre os itens, mas devem ser usados somente como input para a selecção dos itens chave. Não deixar que alguns membros ditem decisões – usar a sabedoria da equipa, como um todo.

Page 22: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

6.6.3. Cartões versus Matriz

} Usar ambas as abordagens, em paralelo. Ter alguém que registe a informação na matriz, à medida que são desenhadas as relações entre os cartões.

} Quando se trabalha com um grupo, parece melhor começar por escrever os itens em cartões, e dispô- los sobre uma superfície grande. Esta representação visual ajuda a pensar nas relações entre itens (os pesos podem ser evidenciados com números, com diferentes cores ou diferentes espessura das linhas).

} Ao olhar para itens chave, a utilização da matriz tem demonstrado ser melhor para organizar os dados, e mostrar informação comparativa entre itens.

Page 23: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

7. Técnica de Brainstorming para Geração de Ideias

7.1. Descrição

A técnica de brainstorming4 é um método de trabalho em grupo para geração de ideias, que podem depois servir em outros métodos de agrupamento, ordenação, ou avaliação de itens da mais variada natureza. Os participantes identificam verbalmente ideias, à medida que pensam nelas, dando oportunidade a todos de construir sobre as ideias uns dos outros, ou de as rejeitar.

Descreve-se aqui o brainstorming verbal clássico, embora se resumam outras variações.

O brainstorming pode ser realizado por um indivíduo, ou por um grupo. Neste caso, deve existir um facilitador que regista as informações.

7.2. Restrições

Este método:

§ deve ser utilizado em pequenos grupos (isto é, com menos de 9 pessoas),

§ exige um facilitador experiente, para lidar com o conflito e com as emoções negativas que podem surgir e que necessitam ser controladas; com as personalidades dominadoras que podem tomar o controlo; pessoas envergonhadas que necessitam ser encorajadas, para poderem contribuir; questões e tópicos laterais e improdutivos.

7.3. Benefícios

Este método:

§ não exige treino dos participantes,

§ é um exercício agradável,

§ gera muitas ideias, num curto espaço de tempo.

4 A técnica de brainstorming foi introduzida por Alex Osborn em 1953.

Energiacriativa

Lista deideias

BrainstormingEnergiacriativa

Lista deideias

Brainstorming

Page 24: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

7.4. Condução de uma Sessão de “Brainstorming”

O Quadro 9 descreve o processo de condução de uma sessão de brainstorming, com um grupo e um facilitador. A aplicação individual segue os mesmos passos básicos, embora todos eles sejam realizados pela mesma pessoa.

Passo Acção Descrição

1 Discutir a questão ou o risco O facilitador apresenta a questão ou o risco para o qual se devem gerar ideias, assegurando-se que é compreendida por todos.

2 Explicação do processo O facilitador explica o processo do “braistorming” e reitera as regras: • Não julgar nem criticar as ideias de quem está a falar. • Encorajar “ideias loucas”, ou o pensamento “fora da caixa”. • Construir sobre as ideias dos outros. • Procurar exprimir o máximo de ideias.

3 Geração de ideias As ideias são geradas pelos participantes, mediante o uso de uma das seguintes variações [Xerox 1992]:

• não-estruturada: levantar ideias espontaneamente • à vez: cada participante exprime a sua ideia, quando chegar a sua

vez

4 Registo das ideias O facilitador regista as ideias num meio visual que possa ser visto por todos os participantes (flip-chart, quadro, etc.).

5 Revisão da lista Todos os participantes revêem a lista, para adquirirem clareza e compreensão.

Quadro 8– Procedimentos do “brainstorming”

O agrupamento e a ordenação da lista de ideias, podem ser efectuadas com o auxílio de métodos de análise, como o Agrupamento por Afinidade ou a Votação Múltipla.

O Quadro 9 resume as vantagens e desvantagens das duas variações usadas na submissão de ideais (passo 3 do procedimento, no Quadro 8).

Variação Vantagens Desvantagens

Não-estruturada ú Espontânea ú Criativa ú Fácil de construir sobre as ideias dos

outros

ú As personalidades dominantes tomam o controlo ú Demasiados participantes em simultâneo, pode

conduzir à perda de ideias

À vez ú Difícil o domínio por uma pessoa ú Permite uma discussão mais

concentrada ú Todos são encorajados a participar

ú Difícil esperar pela vez ú Possível perda de energia ú Relutância em dar a vez ú Não é tão fácil construir sobre as ideias dos outros

Quadro 9 – Vantagens e desvantagens das variações ao “brainstorming”

7.5. Sugestões e Recomendações

} Manter a sessão curta (15 – 45 minutos), mas dar tempo a que todos contribuam com as suas ideias.

} Decidir quando deve parar. Existem três regras possíveis a seguir:

Page 25: Gestão do Risco e da Qualidade no Desenvolvimento de Softwareltodi.est.ips.pt/es/index_files/pdf/Riscos - Ferramentas de Avaliao.pdf · Todos os participantes olham para dois cartões

} Parar se passarem 30 – 60 segundos sem aparecerem contribuições (bom para sessões curtas).

} Estabelecer um limite de tempo (30 – 45 minutos) e fixar-se a ele, a não ser que as ideias ainda estejam a fluir livremente. Neste caso dar mais 5 minutos.

} Definir um número de “rondas” para as contribuições, e depois estabelecer um período de tempo para as contribuições abertas.