Embed Size (px)
Citation preview
UNIVERSIDADE METODISTA DE PIRACICABA FACULDADE DE CIÊNCIAS MATEMÁTICAS, DA NATUREZA E
TECNOLOGIA DA INFORMAÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GERENCIAMENTO DE RISCO DE SOFTWARE: UM MODELO DE PROCESSO E UMA FERRAMENTA
ENCARNAÇÃO DE LOURDES BASSOLI ANDREO GONÇALVES
ORIENTADORA: PROFª DRª TEREZA GONÇALVES K IRNER
PIRACICABA, SP 2006
UNIVERSIDADE METODISTA DE PIRACICABA FACULDADE DE CIÊNCIAS MATEMÁTICAS, DA NATUREZA E
TECNOLOGIA DA INFORMAÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GERENCIAMENTO DE RISCO DE SOFTWARE: UM MODELO DE PROCESSO E UMA FERRAMENTA
ENCARNAÇÃO DE LOURDES BASSOLI ANDREO GONÇALVES
ORIENTADORA: PROFª DRª TEREZA GONÇALVES K IRNER
Dissertação apresentada ao Mestrado em Ciência da Computação, da Faculdade de Ciências Exatas e da Natureza, da Universidade Metodista de Piracicaba – UNIMEP, como requisito para obtenção do Título de Mestre em Ciência da Computação.
PIRACICABA 2006
Gonçalves, Encarnação de Lourdes B. Andreo. Gerenciamento de Risco de Software: Um Modelo de Processo e Uma Ferramenta. Piracicaba, 2006. 140p. Orientadora: Profa. Dra. Gonçalves Kirner. Dissertação (mestrado) – Programa de Pós-Graduação em Ciência da Computação – Universidade Metodista de Piracicaba 1-Gerenciamento de Risco. 2-Risco. 3-Controle de Projetos.
AGRADECIMENTOS
A DEUS, por seus ensinamentos e
orientações, capacitando-me no entendimento dos assuntos estudados.
Ao meu querido marido Cláudio Xavier
Gonçalves pelo apoio, ajuda e incentivo, principalmente nas horas difíceis.
Aos meus filhos Tahiana, Raul e Laura pela
compreensão e paciência.
À professora Dra. Tereza Gonçalves Kirner pela orientação, compreensão e incentivo dispensado em todas as etapas de desenvolvimento deste trabalho.
À equipe de profissionais que participou com sua avaliação dos riscos das fases e atividades no desenvolvimento de projetos.
“Por isso o Senhor esperará, para ter misericórdia de vós; e por isso se
levantará, para se compadecer de vós; porque o Senhor é um Deus de
eqüidade; bem-aventurados todos os que por ELE esperam”.
Isaías 30:18
RESUMO
Atualmente muitas organizações, envolvidas com a produção de software, se
voltam para o Gerenciamento de Riscos como forma de antecipar e minimizar o
efeito de eventos que possam impactar negativamente nos objetivos dos
projetos de software.
O objetivo desse trabalho é apresentar um modelo de gerenciamento de risco
contendo um conjunto de informações sobre riscos, divididos em classes de
riscos, alocados na fase de elaboração de proposta e nas fases do ciclo de
vida de desenvolvimento de software. As informações foram obtidas através de
estudo das pesquisas realizadas, de experiências de profissionais da área
coletadas através de reuniões de levantamentos e validações. Objetivando
manter a estrutura do modelo, sempre atualizada e fornecer um instrumento
para auxiliar o gerenciamento de risco, se desenvolveu uma ferramenta. A
ferramenta contém informações do modelo e também disponibiliza um módulo
para o gerenciamento de risco de projetos em desenvolvimento no qual serão
registrados os riscos, impactos e controles das fases e das atividades do
respectivo projeto, mantendo assim a estrutura do modelo sempre atualizada
formando uma base de conhecimento que serve de orientações para os
projetos futuros. Cria-se assim um histórico organizado que auxilia a resolução
de problemas semelhantes.
PALAVRAS CHAVES: Gerenciamento de Riscos; Gerência de Projetos de Software; Riscos de Software.
ABSTRACT
Nowadays many organizations involved with software building process, are
looking at Risk Management as a way to forecast and minimizing event effects
that can negatively impact the software projects objectives. In the process of
software development turn themselves to the management of risks as a way of
forestalling and minimizing occurrence which can negatively impact the
objectives of software projects.
The aim of this research is to present a Risk Management Model enclosing a
bunch of risk information, divided in classes of risks, assigned in the building
proposal phase and in the life cycle phases of software development. The
information were gotten through a study taken at researches made, experiences
of professionals in the area or collected through meetings for picking up and
through validations. Aiming to keep the structure of the model, ever up dated
and proposing an instrument to help the management of risk, a tool was
developed. The tool has information on the model and also provides a module
for management of risks of projects in development in which will be registered
the risks, the impacts and the controls of the phases and of the activities in the
very project, keeping this way the structure of the model ever updated
composing a base of knowledge working as marks for future projects. So, a
organized history is created to help solving similar troubles.
KEYWORDS: Risks Management; Software Projects Management; Risks of Software.
VII
SUMÁRIO
LISTA DE FIGURAS ...........................................................................................................IX
LISTA DE TABELAS ..........................................................................................................XI
LISTA DE ABREVIATURAS E SIGLAS ...............................................................................XII
CAPÍTULO 1 - INTRODUÇÃO..............................................................................................1
1.1 CONSIDERAÇÕES INICIAIS .......................................................................................1 1.2 OBJETIVOS DO TRABALHO.......................................................................................3 1.3 METODOLOGIA ADOTADA........................................................................................3 1.4 ORGANIZAÇÃO DO TRABALHO .................................................................................4
CAPÍTULO 2 – REVISÃO BIBLIOGRÁFICA .........................................................................5
2.1 FUNDAMENTOS DE GERENCIAMENTO DE RISCO ......................................................5 2.2 PRINCÍPIOS PARA GERENCIAMENTO DE RISCO........................................................6 2.3 AVALIAÇÃO DE RISCO DE SOFTWARE ....................................................................11 2.3.1 A TÉCNICA DE CHECKLIST NA AVALIAÇÃO DE RISCO ...............................................12 2.3.2 IMPACTO, PROBABILIDADE E EXPOSIÇÃO DO RISCO. ...............................................13 2.3.3 ANÁLISE E PRIORIZAÇÃO DOS RISCOS ..................................................................15 2.3.4 MÉTODO DA SEI PARA AVALIAÇÃO DE RISCOS DE SOFTWARE..................................16 2.3.5 OUTROS MÉTODOS PARA AVALIAÇÃO DE RISCOS DE SOFTWARE..............................18 2.3.6 CLASSIFICAÇÃO DE RISCOS ..........................................................................21 2.3.7 BENEFÍCIOS DA AVALIAÇÃO DOS RISCOS DE SOFTWARE ...............................27 2.4 CONTROLE, RESOLUÇÃO E MONITORAMENTO DOS RISCOS. ..................................27 2.5 RISCO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ...............................30 2.5.1 MODELO CASCATA............................................................................................31 2.5.2 MODELO ESPIRAL .............................................................................................31 2.5.3 MODELO INCREMENTAL .....................................................................................32 2.5.4 MODELO EVOLUCIONÁRIO ..................................................................................32 2.5.5 MODELO DE PROTOTIPAGEM ..............................................................................33 2.6 FERRAMENTAS DE AVALIAÇÃO DE RISCO ..............................................................33 2.6.1 FERRAMENTA ARMOR......................................................................................33 2.6.2 A FERRAMENTA RAMP .....................................................................................34 2.6.3 A FERRAMENTA SERIM.....................................................................................36
CAPÍTULO 3 – MODELO DE GERENCIAMENTO DE RISCO ..............................................37
3.1 CONSIDERAÇÕES INICIAIS .....................................................................................37 3.2 CICLO DE VIDA ADOTADO......................................................................................38 3.3 CLASSES DE RISCOS ............................................................................................38 3.4 GERENCIAMENTO DE RISCO..................................................................................39 3.4.1 IDENTIFICAR RISCOS .........................................................................................40 3.4.1.1 TÉCNICA DELPHI...............................................................................................41 3.4.2 ANALISAR E PRIORIZAR OS RISCOS......................................................................42 3.4.3 CONTROLAR OS RISCOS ....................................................................................43 3.5 RISCOS NAS FASES E ATIVIDADES NOS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE .......................................................................................................................44 3.5.1 PROPOSTA – ASPECTOS COMERCIAIS ..................................................................45
VIII
3.5.2 ENGENHARIA DE REQUISITOS .............................................................................51 3.5.3 PROJETOS .......................................................................................................57 3.5.4 DESENVOLVIMENTO ..........................................................................................60 3.5.5 TESTES ...........................................................................................................63 3.5.6 INSTALAÇÃO E LIBERAÇÃO..................................................................................68 3.5.7 OPERAÇÃO......................................................................................................70 3.5.8 MANUTENÇÃO..................................................................................................72
CAPÍTULO 4 – FERRAMENTA DE GERENCIAMENTO DE RISCO ......................................79
4.1 OBJETIVO .............................................................................................................79 4.2 DESCRIÇÃO GERAL ...............................................................................................79 4.3 FUNCIONALIDADES DA FERRAMENTA.....................................................................82 4.3.1 EFETUAR CONTROLE DE ACESSO ........................................................................82 4.3.2 CADASTRAMENTO DAS INFORMAÇÕES BÁSICAS .....................................................82 4.3.3 BASE DE CONHECIMENTO ..................................................................................83 4.3.4 GERENCIAMENTO DE RISCO ...............................................................................84 4.4 DIAGRAMA DE FLUXO DE DADOS DA FERRAMENTA................................................85 4.4.1 DFD – ANÁLISE GLOBAL....................................................................................85 4.4.2 DFD – NÍVEL 1.................................................................................................87 4.4.2.1 BASE DE CONHECIMENTO ..................................................................................87 4.4.2.2 OCORRÊNCIA DE RISCO .....................................................................................88 4.4.2.3 ALIMENTA BASE DE CONHECIMENTO....................................................................89 4.5 MODELO DE DADOS ..............................................................................................90 4.6 PROTOTIPAGEM....................................................................................................91 4.7 ESPECIFICAÇÃO TÉCNICA ...................................................................................106 4.8 AVALIAÇÃO DA FERRAMENTA ..............................................................................107
CAPÍTULO 5 - CONCLUSÃO.......................................................................................... 108
CAPÍTULO 6 – REFERÊNCIAS BIBLIOGRÁFICAS.......................................................... 110
APÊNDICE A................................................................................................................. 115
IX
LISTA DE FIGURAS
FIGURA 1 – ABRANGÊNCIA DO GERENCIAMENTO DE RISCO – BOEHM (1991)...............9
FIGURA 2 – PARADIGMA DE GERENCIAMENTO DE RISCO – WILLIANS (1999)..............11
FIGURA 3 – ETAPAS DO PROCESSO DE AVALIAÇÃO DE RISCO – WILLIANS (1999) .....17
FIGURA 4 - TAXONOMIA DA ENGENHARIA DE RISCO – PETERS E PEDRYCZ (2001).....29
FIGURA 5 - CULTURA EQUIPE DE GESTÃO DE RISCO – PETERS E PEDRYCZ (2001)...30
FIGURA 6 – ARQUITETURA DA FERRAMENTA ARMOR - LYU E OUTROS (1995)..........34
FIGURA 7 – VISÃO GERAL DA FERRAMENTA RAMP – GARVEY E OUTROS (1997)........35
FIGURA 8 – VISÃO GERAL DA FERRAMENTA GRISK ......................................................80
FIGURA 9 - DFD NÍVEL 0. ...............................................................................................86
FIGURA 10 – BASE DE CONHECIMENTO .........................................................................87
FIGURA 11 – OCORRÊNCIA DE RISCO............................................................................88
FIGURA 12 – ALIMENTA BASE DE CONHECIMENTO........................................................89
FIGURA 13 – MODELO DE DADOS DA FERRAMENTA......................................................90
FIGURA 14 – TELA DE ABERTURA DO SISTEMA .............................................................91
FIGURA 15 – TELA DE MENU PRINCIPAL........................................................................92
FIGURA 16 – TELA DE MENU DA OPÇÃO MANUTENÇÃO................................................93
FIGURA 17 – TELAS DE CADASTRO DE USUÁRIOS.........................................................94
FIGURA 18 – TELAS DE CADASTRO DE FASES...............................................................95
FIGURA 19 – TELAS DE CADASTRO DE ATIVIDADES DAS FASES...................................96
FIGURA 20 – TELAS DE CADASTRO DE CLASSES DE RISCOS........................................97
FIGURA 21 – TELAS DE CADASTRO DE RISCOS .............................................................98
X
FIGURA 22 – TELAS DE CADASTRO DE MODELOS DE FORMULÁRIOS. ..........................99
FIGURA 23 – TELA DE CADASTRO DE PROBABILIDADE ............................................... 100
FIGURA 24 – TELA DE CADASTRO DE FREQÜÊNCIA. .................................................. 101
FIGURA 25 – TELA DE CADASTRO DE IMPACTOS DE RISCOS..................................... 101
FIGURA 26 – TELA DE MENU DO GERENCIAMENTO DE RISCOS................................. 102
FIGURA 27 – TELA DE CADASTRO DE CLIENTES......................................................... 103
FIGURA 28 – TELA DE CADASTRO DE CONTATOS DE CLIENTES. ............................... 103
FIGURA 29 – TELA DE CADASTRO DE PROJETOS....................................................... 104
FIGURA 30 – TELA DE CADASTRO DE PROFISSIONAIS................................................ 105
FIGURA 31 – TELA DE CADASTRO DA BASE DE CONHECIMENTO............................... 105
FIGURA 32 – EXECUÇÃO DA FERRAMENTA GRISK ..................................................... 106
XI
LISTA DE TABELAS
TABELA 1–TÉCNICA CHECKLIST DE AVALIAÇÃO DE RISCOS–BOEHM 1991)...............12
TABELA 2 – PROBABILIDADE E IMPACTO DOS RISCOS– BOEHM (1991).......................14
TABELA 3 – FATORES DE EXPOSIÇÃO DE RISCO – BOEHM (1991)...............................16
TABELA 4 – COMPARAÇÃO DE AVALIAÇÕES DE RISCOS - MOYNIHAN (1997)..............19
TABELA 5 – CLASSIFICAÇÃO DE RISCO - APPENDIX H (2000). .....................................22
TABELA 6 – COMPONENTES DE RISCO – SHERER (1995). ...........................................24
TABELA 7 – DIMENSÕES DE RISCO DE SOFTWARE – SHERER (1995). ........................25
TABELA 8 – TÉCNICAS DE GERENCIAMENTO DE RISCO – SHERER (1995). .................26
TABELA 9 – CONTROLE DE RISCO - APPENDIX H (2000) ..............................................28
TABELA 10 - TABELA GERAL DOS RISCOS DA FASE DE PROPOSTA..............................51
TABELA 11 - TABELA GERAL DOS RISCOS DA FASE – ENGENHARIA DE REQUISITOS. .56
TABELA 12 - TABELA GERAL DOS RISCOS DA FASE DE PROJETOS ..............................59
TABELA 13 - TABELA GERAL DOS RISCOS DA FASE DE DESENVOLVIMENTO ................62
TABELA 14 - TABELA GERAL DOS RISCOS DA FASE DE TESTES ...................................67
TABELA 15 - TABELA GERAL DOS RISCOS DA FASE DE INSTALAÇÃO E LIBERAÇÃO .....70
TABELA 16 - TABELA GERAL DOS RISCOS DA FASE DE OPERAÇÃO..............................72
TABELA 17 - TABELA GERAL DOS RISCOS DA FASE DE MANUTENÇÃO.........................77
XII
LISTA DE ABREVIATURAS E SIGLAS
AIE ARQUIVOS DE INTERFACE EXTERNA
ALI ARQUIVOS LÓGICOS INTERNOS
CE CONSULTAS EXTERNAS
CRM CONTINUOUS RISK MANAGEMENT
CVS CICLO DE VIDA DE SOFTWARE
EE ENTRADAS EXTERNAS
ER ENGENHARIA DE REQUISITOS.
MCVS MODELO DE CICLO DE VIDA DE SOFTWARE
SE SAÍDAS EXTERNAS
SEI SOFTWARE ENGINEERING INSTITUTE
SRE SOFTWARE RISK EVALUATION
TI TECNOLOGIA DA INFORMAÇÃO
1
CAPÍTULO 1
INTRODUÇÃO
1.1 CONSIDERAÇÕES INICIAIS
Várias abordagens de gerenciamento de risco de software têm sido propostas
e utilizadas, desde que Boehm (1988, 1989) e Charette (1989, 1990)
introduziram o tema e sua importância no contexto da engenharia de software.
No entanto, apesar dos vários relatos divulgados acerca do uso de modelos de
gerenciamento de risco, com várias experiências bem sucedidas, a indústria de
software, de maneira geral, não parece utilizar um modelo para analisar e
gerenciar o risco ao longo das etapas do desenvolvimento dos produtos.
Particularmente no Brasil, as evidências indicam que a maioria das fábricas de
software, mesmo admitindo a importância de se identificar, analisar e prevenir
riscos, ainda não faz uso de um processo sistemático de gerenciamento de
risco ao longo da produção dos softwares.
Kontio e Basili (1997) destacam três razões principais que levam à baixa taxa
de uso de modelos de gerenciamento de risco:
(a) apesar das informações disseminadas em conferências e periódicos, os
métodos e técnicas de gerenciamento de risco não atingem os profissionais
que atuam efetivamente na área.
(b) os métodos e técnicas existentes possuem limitações de ordem prática e
teórica que dificultam a sua utilização no dia-a-dia dos profissionais. As
principais limitações são:
• Alto grau de quantificação dos riscos; uso de formalismos que
comprometem a usabilidade do modelo;
2
• Uso de um número muito reduzido de métricas e/ou regras, relacionadas
principalmente à cronograma e a custo alocado às etapas e atividades do
desenvolvimento de software, o que desestimula os profissionais a
adotarem o modelo;
• Falta de definições claras dos tipos de riscos possíveis de ocorrer em cada
etapa do processo de desenvolvimento.
(c) Há poucos estudos empíricos sobre o emprego de gerenciamento de risco
no ambiente das empresas produtoras de software, destacando-se aqui um
estudo pioneiro realizado por Basili e Tori (1995) que identificou o baixo índice
de emprego de abordagens sistemáticas de gerenciamento de risco nas
empresas desenvolvedoras de software.
A necessidade de se investir em estratégias de gerenciamento de risco, ao
longo do processo de desenvolvimento de software, é plenamente justificada
(Padayachee, 2002; Tiwana, 2004; Wallace, 2004).
Conforme Klein e Jiang (2001), estudos continuam a indicar que cerca de 85%
de todos os projetos culminam em falhas. Além disso, foi identificado que
31.1% dos projetos são cancelados antes de serem finalizados, Boehm (2000).
Tais problemas poderiam ser minimizados com a adoção, pelas empresas
desenvolvedoras de software, de um processo sistemático de gerenciamento
de risco. Se, adicionalmente, as empresas dispuserem de uma ferramenta de
software que apóie o processo de gerenciamento de risco, a prevenção e o
tratamento adequado dos riscos inerentes às diferentes etapas do ciclo de vida
do software deverão ser viabilizados.
Esta pesquisa abrange dois objetivos: O primeiro objetivo é apresentar um
modelo de processo de gerenciamento de risco (GRisk-Model), que cobre
todas as etapas do processo de desenvolvimento de software. O segundo
objetivo é apresentar uma ferramenta (GRisk-Tool), que dá suporte à utilização
do modelo. O GRisk-Model foi desenvolvido com base na literatura da área e a
partir da experiência de diretores, gerentes e analistas de sistemas seniores de
fábricas brasileiras de software. A GRisk-Tool implementa o modelo de
3
gerenciamento de risco e foi avaliada por profissionais da área quanto aos seus
aspectos funcionais de usabilidade e de benefícios proporcionados.
1.2 OBJETIVOS DO TRABALHO
O objetivo do trabalho é apresentar um modelo de Gerenciamento de Risco,
GRisk-Model, que será apresentado detalhadamente no Capitulo 3 para os
processos de desenvolvimento de software com um conjunto de informações
que auxiliam no gerenciamento de riscos em projetos de software e obtidas
através do estudo bibliográfico, experiências de profissionais da área e
históricos de projetos. O modelo indica possíveis riscos nas fases e atividades
dos processos de desenvolvimento de software. Os riscos apresentados foram
indicados e validados por um grupo de profissionais compostos por gerente
comercial, gerente de fábrica de software, coordenadores de fabrica de
software e analistas de sistemas.
Como suporte ao modelo GRisk-Model, desenvolveu-se uma ferramenta, a
GRisk-Tool, que será apresentada detalhadamente no Capítulo 4, para controle
de gerenciamento de risco, contendo as informações do modelo GRisk-Model.
O objetivo final da ferramenta é auxiliar e orientar as equipes em sua tarefa de
gerenciamento de riscos, indicando os prováveis riscos nos processos de
desenvolvimento de software obtidos no GRisk-Model, possibilitando o registro
de riscos que ocorrem durante o processo de desenvolvimento de software,
alimentando e mantendo a base de conhecimento produzida pelo modelo
GRisk-Model.
1.3 METODOLOGIA ADOTADA
É inquestionável a importância da pesquisa científica em todos os ramos da
ciência e a obtenção do conhecimento científico não é simplesmente a
identificação da verdade, mas um processo de interpretação e aprendizado
sobre o obje to de estudo.
4
A metodologia adotada neste trabalho está fundamentada no paradigma
qualitativo , conforme Lima (2003), ou seja, adotou-se um enfoque investigativo
cuja preocupação principal foi o entendimento do objeto pesquisado.
Entendimento é a interpretação associada à realidade do contexto onde o
objeto é aplicado. A metodologia adotada neste trabalho está fundamentada
em uma estrutura cíclica com os seguintes passos:
• Escolha do projeto a ser trabalhado;
• Formulação dos questionamentos;
• Resumo da informação;
• Elaboração de um registro;
• Análise da informação;
• Redação das informações efetuadas.
1.4 ORGANIZAÇÃO DO TRABALHO
O Capítulo 2 apresenta os principais fundamentos teóricos que embasaram o
modelo e a construção da ferramenta.
O Capítulo 3 detalha o GRisk-Model, destacando os riscos nas fases e
atividades do ciclo de vida de desenvolvimento de software.
O Capítulo 4 apresenta a GRisk-Tool, enfatizando suas funcionalidades em
criar e manter uma base de conhecimento para auxiliar no gerenciamento de
riscos durante o processo de desenvolvimento de software.
O Capítulo 5 apresenta as conclusões finais do trabalho, destacando as
potencialidades, limitações e direções futuras do trabalho.
O Capítulo 6 apresenta a bibliografia.
5
CAPÍTULO 2
REVISÃO BIBLIOGRÁFICA
2.1 FUNDAMENTOS DE GERENCIAMENTO DE RISCO
Conforme o dicionário da língua portuguêsa escrito por Mattos (1996), risco é
a “possibilidade de acontecer alguma coisa ruim, um problema”.
“Gerenciamento é a ação de administrar um determinado processo”. Portanto,
Gerenciamento de Risco é o ato de administrar as possíveis causas dos
problemas que poderão ocorrer.
Gerenciamento de risco é um processo da engenharia de software com
métodos e ferramentas para administrar riscos em um projeto. Isto fornece um
ambiente disciplinado para tomadas de decisões com informações de
quantidades de riscos que podem ocorrer, determinação sobre quais riscos são
importantes e que devem ser tratados, além de informações relacionadas ao
desenvolvimento de estratégias para lidar com risco.
De acordo com Mattos (1996), falha é algo que prejudica o funcionamento ou a
utilização de alguma coisa, é um defeito, uma imperfeição.
Baseado em Sherer (1995), Risco de Software é a perda esperada que pode
ocorrer no desenvolvimento, na utilização ou na manutenção do software. Com
a evolução tecnológica, os riscos de hardware foram minimizados, ficando o
software como a maior fonte de problemas que podem resultar em perdas
financeiras substanciais. Além de que os softwares estão em constante
evolução e manutenção.
6
Risco, por si só, não é ruim. Risco é essencial para a evolução do projeto, e
falha é freqüentemente uma parte chave de aprendizagem, mas é necessário
aprender a avaliar as conseqüências negativas associadas aos riscos.
Todo projeto apresenta algum nível de risco associado ao produto em
desenvolvimento ou manutenção. Riscos podem aparecer em áreas como:
alteração do pessoal de desenvolvimento, mudanças de condições de mercado
e de expectativas do cliente e mudanças de condições de negócio.
Quanto mais cedo se compreende o risco, o Gerenciamento de Risco nos
projetos será mais bem efetuado.
Conforme relatório técnico da SEI, elaborado por Willians e outros (1999),
identificar e controlar riscos, durante a fase de elaboração de proposta e no
processo de desenvolvimento de software, têm impacto significativo no
sucesso global desse software. O relatório define seis áreas de riscos
significativos: Financeiro, Técnico, Operacional, Legal, Contratual e
Organizacional.
Conforme Charette (1996), é grande a importância do gerenciamento de risco,
principalmente em projetos grandes e complexos. O modelo Espiral criado por
Barry Boehm em 1988 foi o primeiro maior esforço na tarefa de efetuar o
gerenciamento de risco nos processos de desenvolvimento de software. É
utilizado, com muito sucesso, por diversas empresas, principalmente as
indústrias aeroespaciais. Baseado em suas experiências, Charette conclui que
o sucesso dos projetos, principalmente os grandes e complexos, depende da
atividade de gerenciamento de risco.
2.2 PRINCÍPIOS PARA GERENCIAMENTO DE RISCO
O relatório técnico da SEI, elaborado por Willians e outros (1999), apresenta
sete princípios que fornecem uma estrutura para gerenciamento efetivo de
risco. Os princípios são apresentados a seguir.
7
• Perspectiva global. Visualiza o desenvolvimento de software no contexto
da definição de sistemas em um nível maior que o desenvolvimento do
projeto. Reconhece o valor potencial de oportunidade e o provável impacto
de efeitos adversos.
• Visão futurista. Pensa no amanhã, identifica incertezas, antecipa
potenciais resultados. Administra recursos e atividades de projeto enquanto
antecipa incertezas.
• Comunicações abertas. Encoraja a comunicação das informações entre
todos os níveis de projeto. Habilita comunicação informal e formal. Usa
processos de valorização ao indivíduo, traz conhecimento e visão única
para identificar e gerenciar risco.
• Gerenciamento integrado. Faz do gerenciamento de risco uma parte vital
e integrada da administração de projeto, adaptando métodos de
gerenciamento de risco e ferramentas à infra-estrutura e à cultura de um
projeto.
• Processo contínuo. Sustenta vigilância constante. Identifica e gerencia
rotineiramente os riscos através de todas as fases do ciclo de vida do
projeto.
• Compartilhamento da visão do produto. Visão única do produto baseada
em um propósito comum, compartilhando a comunicação coletiva e com
enfoque em resultados.
• Equipe de trabalho. Trabalhando cooperativamente para alcançar uma
meta comum. É um conjunto de talentos, habilidades, e conhecimento.
Os princípios especificados acima são importantes para o gerenciamento de
risco, pois evidenciam a necessidade de se estabelecer uma linha mestra para
identificação de riscos em projetos de software e a necessidade de criar e
desenvolver um processo contínuo de gerenciamento efetivo de risco. Além
disso, determina a abrangência total desse gerenciamento nas etapas de
desenvolvimento de software.
8
Charette (1996) criou uma nova postura, definida a seguir, que enfatiza a
necessidade de sensibilidade a gerentes de projetos nas atividades de
gerenciamento de risco.
• O sucesso é efetuar as avaliações, sobre os riscos, mesmos os muito
grandes, com inteligência;
• O risco não é algo a ser temido ou evitado, mas algo do qual se pode obter
vantagem;
• As mudanças não devem ser temidas, mas enfrentadas;
• Com o domínio dos detalhes se consegue dominar os riscos também.
Boehm (1991) definiu que a atividade de gerenciamento de risco envolve duas
etapas, cada qual com três subdivisões, como apresentado na Figura 1.
A Avaliação de Risco é a primeira etapa no gerenciamento de risco e é
composta por:
• Identificação de risco. Produz lista de itens de riscos específicos que
provavelmente comprometem o sucesso do projeto. Técnicas típicas de
identificação de risco compreendem checklist, análises, comparações com
experiências anteriores e decomposição do risco.
• Análise de risco. Avalia a probabilidade e o valor da ocorrência de cada
item de risco identificado. Técnicas típicas incluem modelos de
desempenho e de custos, análise de rede, análises estatísticas para
tomada de decisão e análise de qualidade (confiabilidade, disponibilidade e
segurança).
• Priorização de risco. Produz uma lista de riscos identificados e analisados.
As técnicas típicas incluem a análise da probabilidade do risco, a análise do
impacto do risco (que envolve particularmente a análise custo beneficio) e
as técnicas de consenso do grupo.
9
FIGURA 1 – ABRANGÊNCIA DO GERENCIAMENTO DE RISCO – BOEHM (1991).
O Controle de Risco é a segunda etapa no gerenciamento de risco e é
composta por:
• Plano de gerenciamento de risco. Ajuda a direcionar cada item de risco,
por exemplo, através de informações de compras, remoção, transferência
ou redução do risco, incluindo o plano do risco individual e relacionando-o
com todo o projeto. As técnicas típicas incluem listas de verificação das
Controle de Risco
Identificação de Risco
Análise de Risco
Priorização de Risco
Plano de Gerenciamento do Risco
Resolução de Risco
Monitoramento de Risco
Checklist Análise Dirigida à Decisão Análise de Aceitação Decomposição
Avaliação de Risco
Modelos de Desempenho
Modelos de Custo Análise de Rede Análise de Decisão Análise Fator de Qualidade
Probabilidade do Risco Impacto do Risco Redução do Risco Composto
Informação de Compra Remoção do Risco Transferência do Risco Redução do Risco Plano Individual de Risco Plano Integrado de Risco
Protótipos Simulações Bench marks Análises Equipe
Pontos de Monitoramento
Os 10 mais críticos Reavaliação do Risco Ação de Correção
Gerenciamento de Risco
10
definições dos riscos, análise de custo/benefício e esboço de um plano de
gerenciamento de risco descrito em formulário.
• Resolução de risco. Produz uma situação em que os itens de risco são
eliminados ou resolvidos de outra maneira (por exemplo, a minimização do
risco através do relaxamento das exigências). As técnicas típicas incluem
protótipos, simulações, pontos de controle, análises dos objetivos, acordos
com os principais envolvidos, avaliações dos custos dos projetos.
• Monitoramento de risco. Envolve a resolução dos riscos durante a
evolução do desenvolvimento do projeto fazendo monitoramento e ação
corretiva. As técnicas típicas incluem a determinação dos pontos de
controle de riscos (marcos) e a elaboração de uma lista dos 10 itens de
riscos mais destacados para o monitoramento.
A SEI, através do relatório técnico de Willians e outros (1999), enfatizam o
aspecto contínuo do gerenciamento de risco. Daí o nome Gerenciamento de
Risco Contínuo (CRM).
Quando o Gerenciamento de Risco Contínuo é utilizado, os riscos são
identificados continuamente em todas as fases do projeto. Os riscos
identificados são analisados, ou são resolvidos, ou eles se transformam em
problemas e são tratados como tais.
Em alguns projetos, os riscos são verificados uma única vez durante o
planejamento inicial do projeto onde os maiores riscos são identificados e
minimizados, mas dessa forma os riscos nunca são totalmente identificados. O
Gerenciamento de Risco envolve um processo sistemático e contínuo que pode
ser mais bem entendido pelo paradigma representado na Figura 2.
Os elementos do paradigma de gerenciamento de risco, ilustrado na Figura 2,
são descritos a seguir. As atividades são seqüenciais, porém devem ocorrer
continuamente, ou seja, enquanto alguns riscos são monitorados outros e
novos riscos são identificados durante o processo de desenvolvimento de
software.
11
FIGURA 2 – PARADIGMA DE GERENCIAMENTO DE RISCO – WILLIANS E OUTROS (1999)
• Identificar. Os riscos do projeto devem ser identificados e conhecidos antes
que se tornem problemas.
• Analisar. Transforma os riscos em dados, para tomada de decisão, durante
o desenvolvimento do projeto.
• Planejar. Planejar e incluir ações para resolver ou minimizar riscos do
presente e do futuro.
• Acompanhar. Monitorar as indicações de riscos e acompanhar as ações de
minimização.
• Controlar. Corrigir os defeitos do planejamento de minimizar os riscos.
• Comunicação. Habilitar e compartilhar toda a informação do projeto.
2.3 AVALIAÇÃO DE RISCO DE SOFTWARE
A Avaliação de Risco de Software é utilizada para identificar, analisar,
classificar e priorizar os riscos oriundos dos projetos de software.
Identificar
Analisar
Planejar
Controlar
Acompanhar
Comunicação
12
Os profissionais que compõem as equipes do projeto participam na
identificação e análise dos riscos.
Uma Avaliação de Risco de Software fornece ao gerente do projeto um aviso
antecipado e estruturado sobre riscos identificados no projeto.
2.3.1 A TÉCNICA DE CHECKLIST NA AVALIAÇÃO DE RISCO
Boehm (1991) apresenta o Checklist como a principal técnica para avaliação de
risco. O checklist pode ser utilizado para ajudar gerentes e desenvolvedores a
identificar os riscos mais importantes do projeto.
Na Tabela 1 é mostrado um checklist com riscos de alto nível identificados
como as primeiras 10 mais importantes fontes de riscos em projetos do
software. Essa tabela foi preparada a partir de um levantamento com vários
gerentes de projetos. Os gerentes e coordenadores de projetos podem usar o
checklist para ajudar a identificar e resolver os riscos mais sérios do projeto. Na
Tabela 1 é apresentada também uma relação das técnicas mais bem
sucedidas na resolução da fonte do risco.
TABELA 1–TÉCNICA CHECKLIST DE AVALIAÇÃO DE RISCOS–BOEHM 1991)
Itens de Risco Abordagens de Gerenciamento de Risco Equipe não qualificada ou pouco qualificada
§ Equipe qualificada § Trabalho organizado em equipe § Acordos estabelecidos § Treinamentos
Cronogramas e orçamentos irreais
§ Detalhamento do custo e da estimativa de prazos. § Desenvolvimento incremental § Reutilização de software § Requisitos claros
Desenvolvimento das funções e propriedades erradas
§ Análise da Organização e dos objetivos § Exposição sistemática dos conceitos operacionais § Exames e acompanhamentos de usuários § Prototipagem § Antecipação do manual do usuário § Análise de desempenho e fatores de qualidade
Desenvolvimento das interfaces de usuários erradas
§ Prototipagem § Cenários § Análise das tarefas § Participação dos usuários
Acabamentos § Requisitos claros § Análise de custos e benefícios § Determinação dos custos
13
Tabela 1–Técnica Checklist de Avaliação de Riscos – Boehm (1991) -Continuação
Itens de Risco Abordagens de Gerenciamento de Risco Mudanças contínuas de requisitos correntes
§ Grandes mudanças no início das atividades § Informações escondidas não declaradas § Adiando mudanças para as próximas etapas
Falhas na finalização de componentes
§ Bench marking § Inspeção § Verificação das referências § Análises de compatibilidade
Falhas no desempenho das atividades
§ Verificação das referências § Auditoria de pré-concessão § Contratos com taxas de concessão § Projetos competitivos ou prototipagem § Formação da equipe
Falhas de desempenho de processos de tempo real
§ Simulações § Bench marking § Modelagem § Prototipagem § Instrumentação § Ajustes
Aumentar a capacidade da ciência de computação
§ Análises técnicas § Análise de custo-benefício § Prototipagem § Verificação das referências
2.3.2 IMPACTO, PROBABILIDADE E EXPOSIÇÃO DO RISCO.
É importante identificar o impacto (influência do risco) e a probabilidade
(possibilidade de ocorrência do risco) dos riscos em um determinado projeto. O
resultado desta identificação determina, como mostra Boehm (1991), qual o
fator de risco ou qual a exposição do risco para o projeto, utilizando a formula
especificada a seguir.
RE = P * L (2.1)
Sendo:
RE é a exposição (grau de ocorrência) ao risco.
P é a probabilidade da ocorrência do risco.
L é o impacto quando da ocorrência do risco.
Para se efetuar o cálculo da exposição do risco, é necessária a definição da
probabilidade e do impacto da ocorrência do risco. No entanto, esta definição é
14
controversa, já que a equipe do projeto é composta por desenvolvedores e por
usuários. Na Tabela 2, descrita por Boehm (1991), é apresentado um checklist
de probabilidade e de impacto para projetos com orçamentos insuficientes ou
ultrapassados.
TABELA 2 – PROBABILIDADE E IMPACTO DOS RISCOS– BOEHM (1991)
Quantificação da Probabilidade e Impacto de Custos
Aplic. dos
Custos
Probab./Improb.(0.0 – 0.3)
Provável (0.4 – 0.6) Freqüência (0.7 – 1.0)
Requisitos Quantidade de requisitos
§ Pequena quantidade
§ Requisitos simples, não complexos.
§ Fácil decomposição
§ Requisitos de complexidade moderada
§ Requisitos possíveis de se decompor
§ Grande quantidade de requisitos § Requisitos de alta complexidade § Requisitos impossíveis de se
decompor
Restrições de recursos
§ Pequenas restrições de recursos
§ Sem imposição de hardware
§ Algumas imposições de hardware
§ Significativas imposições de hardware
Aplicação § Aplicação com utilização sem ser em tempo real
§ Pouca interdependência
§ Embutido § Aplicação com alguma
interdependência
§ Aplicação em tempo real § Embutido § grande interdependência
Tecnologia § Tecnologia madura
§ Tecnologia existente
§ Possui experiência na empresa
§ Tecnologia existente § Possui alguma
experiência na empresa
§ Tecnologia nova ou nova aplicação
§ Possui pouca experiência na empresa
Estabilidade dos Requisitos
§ Pequena ou nenhuma mudança no estabelecido da linha básica
§ Algumas mudanças na linha básica esperada
§ Muitas mudanças e nenhuma linha básica
Pessoal Disponibilidade
§ Local § Pequena troca de
pessoal esperada
§ Disponível § Alguma troca de pessoal
esperada
§ Não disponível § Grande troca de pessoal
esperada
Experiência § Alta experiência § Media experiência § Pouca experiência Gerenciamento de Ambiente
§ Forte aproximação da gerência
§ Boa aproximação da gerência
§ Fraca aproximação da gerência
Reutilização de Software Disponibilidade
§ Compatíveis com as datas necessárias
§ Datas de entrega em discussão
§ Datas necessárias incompatíveis
Modificações § Pequenas ou sem modificações
§ Algumas modificações § Modificações extensas §
Linguagens § Compatível com os requisitos
§ Parcialmente compatível com os requisitos
§ Incompatível com os requisitos
Certificações § Desempenho verificado
§ Aplicação compatível
§ Alguma aplicação compatível
§ Dados de teste disponíveis
§ Sem verificação § Pequenos dados de teste
disponíveis
15
Tabela 2 – Probabilidade e Impacto dos Riscos– Boehm (1991) – Continuação.
Quantificação da Probabilidade e Impacto de Custos Aplic. dos
Custos
Probab./Improb.(0.0 – 0.3)
Provável (0.4 – 0.6) Freqüência (0.7 – 1.0)
Ferramentas e Ambientes Facilidades § Pequena ou sem
modificações § Algumas modificações § existentes
§ Grandes modificações § Inexistentes
Disponibilidades
§ No local e nas datas necessárias
§ Alguma disponibilidade nas datas necessárias
§ Não existentes
Corretos § Compatível com desenvolvimento e manutenção do plano
§ Parcialmente compatível com o desenvolvimento e manutenção do plano
§ Incompatível com o desenvolvimento e manutenção do plano
Gerenciamento de Configuração
§ Inteiramente controlado
§ Algum controle § Sem controle
Impacto § Suficientes
recursos financeiros
§ Alguma falta de recursos financeiros
§ Possibilidade de ultrapassar o orçamento
§ Significativa falta de recursos financeiros
§ Provavelmente o orçamento será ultrapassado
Conforme apresentado, os dados da Tabela 2 podem auxiliar na determinação
da freqüência e impacto de riscos. Através de um checklist, apresenta riscos
divididos em riscos de requisitos, riscos das pessoas que participam do projeto,
riscos técnicos e finalmente riscos de ferramentas e ambientes. No final da
tabela são apresentados os impactos desses riscos para o projeto.
2.3.3 ANÁLISE E PRIORIZAÇÃO DOS RISCOS
Para se evitar que a fase da identificação e análise de riscos se torne inviável,
em decorrência do longo tempo necessário para investigação e avaliação de
todos os riscos identificados, é extremamente necessário e essencial a
priorização dos riscos como primeira ação.
A técnica mais eficaz para a priorização do risco envolve a probabilidade e o
impacto do risco. Na Tabela 2 é fornecida alguma ajuda, porém não contém
todas as informações para a análise e priorização dos riscos. Para facilitar a
determinação da prioridade deve-se calcular a exposição de riscos e então,
através do resultado, determinar as prioridades. Para facilitar o entendimento,
16
na Tabela 3 é apresentado um exemplo de cálculo de exposição de risco de
um software exemplo.
TABELA 3 – FATORES DE EXPOSIÇÃO DE RISCO – BOEHM (1991).
Fatores de Exposição de Risco
Resultado Insatisfatório
Probabilidade
Impacto
Exposição Do Risco
O erro do software impede a utilização do sistema
3-5 10 30-50
O erro do software perde os dados principais 3-5 8 24-40 Desempenho inaceitável das características de tolerância às falhas
4-8 7 28-56
Relatório de Monitoramento do Software apresenta situação insegura
5 9 45
Os valores da Exposição do Risco são calculados multiplicando-se a
Probabilidade pelo Impacto.
Após a determinação da exposição do risco, conforme indicado na Tabela 3,
deve-se efetuar uma análise dos riscos mais relevantes e então determinar sua
prioridade.
2.3.4 MÉTODO DA SEI PARA AVALIAÇÃO DE RISCOS DE SOFTWARE
O método da SEI para avaliação de risco é o SRE – Software Risk Evaluation –
Avaliação de Riscos de Software, descrito no relatório técnico de Willians e
outros (1999), e se divide em cinco fases: Contratação, Identificação e Análise
de Riscos, Relatório Intermediário dos Riscos Identificados, Plano Estratégico
de Minimização dos Riscos e o Relatório Final dos Riscos com informações do
plano estratégico e controles, conforme ilustrado na Figura 3, apresentada a
seguir.
17
FIGURA 3 – ETAPAS DO PROCESSO DE AVALIAÇÃO DE RISCO – WILLIANS E OUTROS (1999)
As etapas do método de implantação da avaliação de riscos de software
apresentadas na Figura 3 são resumidas a seguir.
• Contratação. A fase Contratação consiste das atividades de identificar as
necessidades e objetivos do projeto. Determina os recursos para o seu
desenvolvimento.
• Identificação e análise do risco. Nessa fase, a equipe do projeto de
Avaliação de Risco de Software conduz entrevistas com a equipe do projeto
e com os usuários para identificar os Riscos.
Os riscos são analisados e priorizados considerando o impacto no projeto e
agrupados dentro das áreas de risco. Os itens referentes às incertezas,
experiências anteriores, preocupações e questões a resolver serão úteis na
identificação dos riscos. Várias fontes podem ser utilizadas nesta fase, tais
como:
Identificação e Análise de Riscos
Relatório Intermediário dos Riscos
identificados
Contratação
Plano Estratégico de Minimização dos
Riscos
Relatório Final de Riscos
e Controles
18
Pessoas: clientes, integrantes da equipe, organizações envolvidas,
disponibilidade, capacidade, experiência, etc.
Produto e Processo: abrangem requisitos, prazos, estimativas, receitas,
despesas, orçamento, restrições de natureza legal, estilo de gerenciamento,
tamanho e escopo do projeto, etc.
Tecnologia: inclui mudanças, inovação, adoção e uso, integração e
interfaces, experiência específica, segurança, arquitetura, distribuição na
escala, etc.
• Relatório intermediário. Nesta fase os riscos são relacionados por área,
com uma recomendação para que na próxima fase seja efetuado o plano
estratégico para sua solução ou minimização de impacto no projeto.
• Planejamento da estratégia de minimização. O Planejamento da
Estratégia de Minimização é a fase que seleciona as áreas de riscos com
maior impacto para o projeto. A equipe do projeto e da avaliação do risco
trabalha em conjunto para determinar metas, estratégias e atividades que
vão minimizar os assuntos identificados dentro das áreas de risco.
• Relatório final. As informações dos planos de estratégia da minimização de
riscos e as ações tomadas são mostradas no relatório final e apresentadas
ao gerente do projeto.
2.3.5 OUTROS MÉTODOS PARA AVALIAÇÃO DE RISCOS DE SOFTWARE
Moynihan (1997) descreve um estudo de como gerentes experientes avaliam
riscos. No estudo, ele apresenta um esquema para apurar as ações dos
gerentes, em relação aos riscos, produzindo uma tabela dos temas de riscos
relacionados pelos gerentes participantes. Utiliza a tabela para efetuar uma
comparação dos temas levantados pelas diversas literaturas sobre riscos e de
questões de riscos apresentadas pela SEI. Essa comparação está apresentada
na Tabela 4, descrita a seguir.
19
TABELA 4 – COMPARAÇÃO DE AVALIAÇÕES DE RISCOS - MOYNIHAN (1997).
Temas Variáveis de Riscos de Barki SEI O problema a ser resolvido é o conhecimento, a clareza e a compreensão do cliente em relação às suas solicitações.
• Não consta • Ocorrem mudanças durante o desenvolvimento das solicitações, quando ficam mais claras?
Comprometimento do patrocinador do projeto.
• Falta sustentação da alta gerência.
• Não consta
Competência e conhecimento sobre IT, dos clientes e usuários .
• Falta de conhecimento do usuário sobre IT
• O cliente compreende o software? O cliente compreende os aspectos técnicos do sistema?
Necessidade de integração/interface com outros sistemas
• Quantidade de integrações com os sistemas existentes
• Quantidade de integrações com sistemas futuros; Extensão da integração do sistema a outras organizações.
• As relações externas são definidas completamente?
Complexidade da coordenação do projeto (necessidade de compartilhar recursos, necessidade de sub-contratação e assim por diante)
• Quantidade de: fornecedores de hardware
• Fornecedores do software • Pessoas na equipe • Tamanho do projeto. Diversidade
da equipe.
• As especificações exigem um produto maior, mais complexo ou requerem uma equipe maior do que a existente?
Fonte principal de controle sobre o projeto (desenvolvedor versus o cliente versus terceiros)
• Não consta • O programa tem alguma dependência em produtos externos/serviços?
Nível da mudança a ser experimentada pelo cliente (aos procedimentos, fluxo, estruturas, e assim por diante).
• Extensão das mudanças (às tarefas do usuário, estrutura de organização, e assim por diante).
• Grau de informatização do sistema atual.
• Não consta
A necessidade em satisfazer a múltiplos grupos de usuários diferentes contra a necessidade de satisfazer a um grupo de usuários similares
• Número dos usuários fora da organização
• Número dos usuários dentro da organização
• O número dos departamentos envolvidos
• Número dos níveis hierárquicos ocupados por usuários.
• Não consta
Com quem se trabalha: usuários versus departamento de IT, indivíduos versus comitês.
• Não consta • Há relacionamentos pobres com os clientes, terceiros ou outros profissionais?
• Todos estão envolvidos em alcançar os objetivos?
Familiaridade dos desenvolvedores com a plataform a, ambiente e métodos.
• Falta da perícia da equipe (a respeito da plataforma, dos métodos, das ferramentas).
• Há experiência prévia da companhia ou de pessoas do projeto com o desenvolvimento do sistema solicitado?
20
Tabela 4 – Comparação de avaliações de Riscos - Moynihan (1997).- Continuação
Temas Variáveis de Riscos de Barki SEI
Experiência precedente dos desenvolvedores com a aplicação
• Falta de experiência da equipe com a aplicação
• Falta de experiência da equipe com a tarefa a ser informatizada.
• As exigências especificam algo geralmente nunca feito antes ou nunca feito por sua companhia?
• Falta conhecimento do domínio para a equipe de funcionários?
Nível do entusiasmo, sustentação, "energia" para o projeto na organização do cliente.
• Falta de suporte do usuário • Não consta
Complexidade lógica da aplicação
• Complexidade da tarefa • Não consta
Facilidade da validação da solução (tal como a possibilidade de prototipagem )
• Não consta • Há algum problema com desenvolvimento de cenários e dados de teste realísticos para demonstrar a efetivação das exigências?
• É o produto difícil ou impossível de testar?
Voluntariedade do cliente, capacidade para segurar o desenvolvimento.
• Não consta • Não consta
Liberdade da escolha da plataforma do ambiente de desenvolvimento.
• Não consta • Não consta
Criticas do sistema desde o inicio de seu funcionamento (atividades desconhecidas e novas)
• Não consta • Não consta
Maturidade da tecnologia a ser usada
• Necessidade para o novo hardware; necessidade para o software novo.
• Alguma exigência para tecnologias, linguagens, hardware e assim por diante?
Conhecimento do desenvolvedor sobre o país, cultura e língua.
• Não consta • Não consta
Estabilidade do ambiente do empreendimento do cliente Conhecimento do desenvolvedor do setor do empreendimento do cliente
• Não consta • Não consta
A consideração mais importante, identificada pelos gerentes participantes do
processo, se relaciona com o entendimento e o conhecimento do que será
desenvolvido, tanto da parte dos usuários solicitantes como dos
desenvolvedores. É importante observar que Moynihan (1997) elaborou itens
que não constavam nos riscos identificados por Barki e também na relação da
SEI.
21
2.3.6 CLASSIFICAÇÃO DE RISCOS
Com base no Appendix H (2000), a seguir apresentam-se definições de classes
de riscos financeiros, técnicos, operacionais, riscos de cronogramas, legais e
contratuais e organizacionais.
• Riscos financeiros. São quaisquer riscos que podem causar gastos
financeiros não planejados.
• Riscos técnicos. São causados pela inabilidade de uma proposta, para
atendimento das necessidades de previsão dos ciclos de vida dos projetos.
Os Riscos técnicos podem ser determinados por quatro fatores: tamanho do
projeto, estrutura do projeto, experiência da equipe do projeto com
tecnologia ou área de negócio e experiência do grupo de usuários com
desenvolvimento de projetos.
• Riscos operacionais. É o grau em que o projeto proposto soluciona os
problemas de negócios. Informação de como o projeto proposto afetará os
procedimentos e a estrutura organizacional.
• Riscos cronogramas. É o grau entre a expectativa de té rmino e a data de
conclusão do projeto. Pode ser necessário considerar outsourcing ou
mudanças no ambiente técnico de desenvolvimento para atingir o objetivo
da data de conclusão do projeto.
• Riscos legais e contratuais. Referem-se às ramificações de um projeto,
quando do seu desenvolvimento. Relacionados às licenças de software,
número de cópias e outros. Os riscos são acentuados quando empresas
estrangeiras são envolvidas.
• Riscos organizacionais. É determinado por usuários chaves dentro da
organização. A redistribuição de poder é o maior elemento para aumento do
risco organizacional.
Na Tabela 5, apresentada a seguir, contem estas classes de riscos.
22
TABELA 5 – CLASSIFICAÇÃO DE RISCO - APPENDIX H (2000).
Descrição / Fatores
Exemplo
Classe Riscos Financeiros
São quaisquer riscos que podem causar gastos financeiros não planejados.
§ Over run custos § Outlays para disputas legais § Informações / dados perdidos § Falha e reposição de hardware ou software § Falhas de alimentação de dados § Espionagem § Crimes § Empregados insatisfeitos § Empregados “doentes” § Empregados desonestos § Vandalismo § Terrorismo § Erros dos usuários § Roubos § Alta rotatividade de funcionarios § Gerentes sem experiências
Classe Riscos Técnicos
São causados pela inabilidade de uma proposta, para atendimento das necessidades de previsão do projeto.
§ Estimativa de custo do projeto imprecisa § Estimativa de duração do projeto imprecisa § Falhas em alcançar níveis de performance adequados § Falhas na integração com hardware e software existentes § Falhas na integração de procedimentos organizacionais ou
processos. Tamanho do Projeto
§ Número de elementos da equipe § Duração do projeto § Número de departamentos organizacionais envolvidos no
projeto § Dimensionamento de esforço para a programação, ex.
Horas. Estrutura do Projeto § Sistema novo ou manutenção de sistemas existentes
§ Mudanças da organização, procedimentos, estruturas ou de pessoas.
§ Percepção e compromisso do usuário para participação no projeto
§ Gerenciamento contínuo do projeto § Adição das informações do usuário no esforço de
desenvolvimento do projeto Experiência da equipe do projeto com tecnologia ou área de negócio
§ Familiaridade com proposta ou área de negócio da aplicação
§ Familiaridade com hardware, ambiente de desenvolvimento de software, ferramentas e sistemas operacionais.
§ Familiaridade no desenvolvimento de sistemas parecidos Experiência do grupo de usuários com o desenvolvimento de projetos
§ Familiaridade no processo de desenvolvimento de software
§ Familiaridade com propostas ou áreas de negócios § Familiaridade com sistemas ou projetos similares
Classe Riscos Operacionais
É o grau em que o projeto proposto soluciona os problemas de negócios.
§ Informação de como o projeto proposto afetará a estrutura organizacional e os procedimentos
23
Tabela 5 – Classificação de Risco - Appendix H (2000) – Continuação.
Descrição / Fatores
Exemplo
Classe Riscos Scheduler
É o grau onde a expectativa de tempo da data de conclusão do projeto seja a esperada
§ Prazos finais de regulamentos governamentais § Disponibilidade de recursos dentro do escopo de tempo
desejado § Pode ser necessário considerar outsourcing ou mudanças
no ambiente técnico de desenvolvimento. Classe Riscos Legais e Contratuais
Referem-se às ramificações de um projeto, quando do seu desenvolvimento em relação a número de cópias de software, licenças de software, contratos com clientes e outros.
§ Inflações quanto à copias não autorizadas § Leis trabalhistas § Falta de confiança (limitando ou compartilhando
informações) § Regulamentos para comercialização § Más práticas. § Padrão de desenvolvimento inadequado § Relatórios financeiros padrões § Acordos para uso de licenças § Os riscos são acentuados quando empresas estrangeiras
são envolvidas. Classe Riscos Organizacionais
É determinado por usuários chaves dentro da organização.
§ A redistribuição do PODER é o maior elemento para aumento do risco organizacional
Sherer (1995) classifica riscos de software em três dimensões: Técnica,
Organizacional e de Ambiente.
• Dimensão técnica. Historicamente a dimensão técnica dos componentes
de risco de software tem sido a mais estudada pela comunidade de
software. Os procedimentos de gerência de risco têm sido desenvolvidos
para essa dimensão porque esta dimensão significa a evolução dos
softwares. Os riscos da dimensão técnica é a administração dos
procedimentos específicos para planejar e concluir os diferentes processos
envolvidos em desenvolver o software
• Dimensão organizacional. A dimensão organizacional deve administrar os
riscos relacionados aos relacionamentos interpessoais envolvidos no
desenvolvimento, no uso e na manutenção do software. A administração da
dimensão organizacional é focada, em técnicas utilizadas por grupos que
desenvolvem e usam sistemas.
24
• Dimensão de ambiente. A dimensão de risco ambiental está se tornando a
maior fonte de risco para sistemas de hoje. Há duas razões para este fato: a
primeira é que os sistemas que as organizações desenvolvem hoje são
sistemas estratégicos que devem mudar o ambiente exterior e a segunda é
que mais sistemas são desenvolvidos em conjunto com entidades externas,
parcerias. Esta dimensão afeta todo componente de risco de
desenvolvimento, uso e manutenção de softwares.
Sherer (1995) apresenta três tabelas, onde conceitua as dimensões citadas
acima, sendo que na Tabela 6 são apresentados os Componentes de Risco de
Software, na Tabela 7 são apresentados os exemplos das três dimensões de
riscos de software e na Tabela 8 são apresentadas as técnicas de
gerenciamento de risco.
TABELA 6 – COMPONENTES DE RISCO – SHERER (1995).
Componentes de Risco de Software Desenvolvimento Pessoal § Falta potencialidade na equipe para desenvolvimento de
software Cronogramas / Custos § O software não pode ser desenvolvido no tempo ou dentro do
orçamento Processo § A organização não tem um processo eficaz para produzir o
software de qualidade
Uso Funcionalidade § O software não atende aos requisitos dos usuários
Desempenho § O software não possui desempenho de tempo real necessário Confiabilidade § Falha no sistema devido a pouca qualidade
Segurança § Parte superior do formulário § A falha de sistema provoca morte, ferimento, ou doença
ocupacional, danos ou a perda de propriedade, ou dano ambiental.
§ Falha de segurança quanto ao acesso de pessoas não autorizadas. Parte inferior do formulário
Proteção § O software não é protegido de divulgação, de modificação, ou de destruição desautorizada.
Financeira § O sistema não gera os retornos previstos no investimento porque os benefícios são demais baixos e/ou os custos são demais elevados
Manutenção Correção § O software não pode facilmente ser corrigido quando os erros
são encontrados. Adaptação § O software não pode ser adaptado aos ambientes em
mudança. Portabilidade § O software não é portátil a outras instalações.
25
TABELA 7 – DIMENSÕES DE RISCO DE SOFTWARE – SHERER (1995).
Dimensões de Riscos de Software
Técnica Organizacional Ambiente Pessoal § A equipe
não possui habilidades técnicas necessárias
§ Relacionamentos interpessoais atrapalham o desenvolvimento
§ Desenvolvimento externo sem controle eficaz
Cronogramas / Custos § Não pode estimar exatamente os prazos ou o custo
§ Não se podem determinar marcos de controle devido às dificuldades de gerenciamento e organizacionais
§ A competição altera o cronograma.
§ Colaboradores externos não cumprem os prazos das atividades
Processo § Planos ou Processos inadequados
§ Controles atrasados por dificuldades operacionais
§ Alterações nos processos de tecnologia
Funcionalidade § Requisitos mal entendidos
§ Comunicação errada dos requisitos
§ Alterações nos requisitos
Desempenho § Inadequadas ferramentas de simulação
§ Problemas de comunicação, atenção ou conflito dos requisitos.
§ Alterações nos requisitos ou capacidades
Confiabilidade § Medidas inadequadas
§ Habilidade inadequada de medição
§ Alterações de uso do sistema
§ Vendedores não confiáveis
Segurança § Ferramentas de avaliação inadequadas
§ Desenvolvimento de medidas de seguranças pobre
§ Mudanças no ambiente
Proteção § Falta de planos e procedimentos
§ Acessos não autorizados pelo pessoal interno
§ Acessos não autorizados pelo pessoal externo
Financeira § Sem eficácia para estimar custo benefício
§ Pouco uso e operação do sistema
§ Mudanças no ambiente
Manutenção § Projeto, código e procedimentos de manutenção pobres.
§ Controles de configuração e documentações pobres
§ Perda de controle dos desenvolvedores externos
§ Mudanças de ambiente e tecnologia
26
TABELA 8 – TÉCNICAS DE GERENCIAMENTO DE RISCO – SHERER (1995).
Técnicas de Gerenciamento de Risco
Técnica Organizacional Ambiente Pessoal § Suporte e
treinamento. § Outsourcing e
compras.
§ Gerência do projeto de software
§ Apoio da alta gerência
§ Equipes de programação.
§ Gerenciamento dos relacionamentos
Cronogramas / Custos
§ Modelos de Estimativa
§ Modularização § Ferramentas de
gerenciamento de projetos
§ Reutilização de software.
§ Habilidades superiores de gerenciamento
§ Equipe com habilidade na construção de projetos
§ Desenvolvimento modular
§ Modelo Espiral § Equipe flexível § Gerenciamento do
relacionamento
Processo § Planos de controle
de processos § Desenvolvimento de
processos de controle
§ Processos flexíveis
Funcionalidade § Análises dos requisitos
§ Prototipação § Participação do
usuário.
§ Flexibilidade § Reutilização de
código § Linguagem de
programação avançada
§ Avaliação de riscos. Desempenho § Modelos de
simulação § Bench marking
§ Políticas de engenharia de desempenho
§ Flexibilidade.
Confiabilidade § Modelos § Reutilização do
código.
§ Processo de medição de falhas
§ Evolução contínua de avaliação de risco
§ Testes para os softwares comprados.
Segurança § Modelos tolerantes às falhas
§ Análise do sistema de Segurança.
§ Análises dos fatores humanos
§ Certificações.
§ Análises de risco de segurança
§ Realidade virtual § Modelo
organizacional.
Proteção § Controle dos dados
§ Independente auditoria interna dos controles dos processos
§ Auditoria externa de dados e informações
Financeira § Análise completa dos custos
§ Reorganização § Desenvolvimento modular
Manutenção § Avaliação competitiva dos benefícios
§ Gerenciamento de configuração e documentação
§ Flexibilidade § Gerenciamento do
relacionamento.
27
Conforme apresentada acima, na Tabela 6 contém uma relação de riscos
associados às atividades do processo de desenvolvimento de software. Na
Tabela 7 são apresentas as três dimensões de riscos de software relacionadas
com objetivos a serem atingidos e também com atividades do processo de
desenvolvimento de software. Entretanto na Tabela 8 são apresentadas as
dimensões da Tabela 7 relacionadas com objetivos a serem atingidos e com
atividades do processo de desenvolvimento de software, com técnicas para o
gerenciamento de risco.
2.3.7 BENEFÍCIOS DA AVALIAÇÃO DOS RISCOS DE SOFTWARE
Os principais benefícios da avaliação dos riscos de software no processo de
desenvolvimento de softwares conforme SEI (1993), são:
• Obtém uma visão compartilhada de riscos do projeto para que toda a
equipe possa conhecê-los.
• Produz uma estrutura comum para falar sobre os riscos e como minimizá-
los.
• Fornece a habilidade para a identificação e a minimização do risco
sistematicamente com orientações de cálculo de exposição do risco,
identificação de prioridades. Fornece motivação para melhorar o nível do
projeto. Produz informação para tomada de decisão do gerente do projeto.
2.4 CONTROLE, RESOLUÇÃO E MONITORAMENTO DOS RISCOS.
Depois de estabelecidos os itens de riscos e suas prioridades, torna-se
necessário formular um plano de controle para resolver ou minimizar e
monitorar os riscos.
A atividade de controlar os riscos considera os riscos identificados dentro do
ambiente em que se apresenta. Alguns autores, conforme descrito a seguir,
apresentam uma relação de itens com seus respectivos controles. O próximo
28
passo após a indicação do controle do risco é o planejamento da resolução e o
acompanhamento ou monitoramento do risco controlado, até que seja
eliminado ou minimizado.
Na Tabela 9 são apresentados os riscos divididos em classes de riscos e
sugestões de controle.
TABELA 9 – CONTROLE DE RISCO - APPENDIX H (2000)
Classe de
Risco
Controle
Riscos Financeiros
§ Efetuar análise de custo–benefício e análise econômica § Desenvolver um programa de administração de investimento
rigoroso § Adquirir seguro de respons abilidade por parte do contratante § Estabelecer benefícios claros que sejam compreendidos § Formalizar as solicitações de incremento no desenho do projeto,
através de documento de aprovação. § Desenvolver revisões de investimentos
Riscos Técnicos
§ Utilizar o modelo de ciclo de vida como metodologia de desenvolvimento
§ Efetuar planejamento e desenvolvimento dos projetos de software § Fornecer apropriadamente treinamento para a equipe § Dividir o projeto em fases § Planejar as fases do projeto § Definir um gerente do projeto
Riscos Operacionais
§ Utilizar estrutura de administração de informação estratégica § Obter e documentar requisitos claros e objetivos § Efetuar programa de gerenciamento de mudanças para minimizar
impactos § Estabelecer métricas de desempenho e relatórios para monitorar
essas métricas Riscos scheduler
§ Determinar penalidades contratuais para garantir a data de término do projeto
§ Utilizar software de gerenciamento de projetos § Definir expectativas realistas que gerenciem essas expectativas § Efetuar outsourcing para aumentar recursos
Riscos Legais e Contratuais
§ Criar procedimentos para controlar licenças de software § Rever todas as leis aplicáveis § Manter boa comunicação com pessoal contratado para evitar
disputas contratuais § Definir múltiplas oportunidades para encerramento do contrato.
Riscos Organizacionais
§ Obter comprometimento da alta gerência desde o início do projeto § Trabalhar estreitamente com usuários finais para estabelecer
requisitos para o novo sistema § Manter boa comunicação
Peters e Pedrycz (2001) definem a atividade de Controle sendo a fase de
prevenção dos riscos identificados como de maior importância, apresentando
29
uma Taxonomia da Engenharia de Risco. Na Figura 4 é mostrada a taxonomia
proposta.
FIGURA 4 - TAXONOMIA DA ENGENHARIA DE RISCO – PETERS E PEDRYCZ (2001)
Os autores incluem também mais uma atividade, no final do processo,
chamada de Recrutamento. Esta atividade trata da seleção da equipe que irá
implantar as recomendações de prevenção de riscos.
O grau de conhecimento da equipe pode ser julgado em função das
necessidades do gerenciamento de risco. Quanto mais maduro for o
gerenciamento de risco, maior será o conhecimento dos profissionais que
atuam na equipe, com ações pro ativas, prevenções de problemas e estudos
para viabilizar as prevenções.
A cultura (conhecimento técnico com experiências anteriores) da equipe está
representada na Figura 5
Engenharia de Risco
Análise de Risco Gerenciamento de Risco
•Identificação dos Riscos •Estimativa dos Riscos •Avaliação dos Riscos
Identificar fontes de riscos: custos, segurança, etc.
•Planejamento De Riscos •Controle de Riscos •Monitoração de Riscos •Direcionamento De Riscos •Recrutamento
Avaliar a probabilidade e a gravidade dos riscos
Avaliar, priorizar e recomendar condutas prevenção de riscos
Recomendar mudanças na prevenção de riscos
Observar a eficácia da prevenção de riscos
Garantir que a prevenção seja cumprida
30
FIGURA 5 - CULTURA DA EQUIPE DE GESTÃO DE RISCO – PETERS E PEDRYCZ (2001).
Na Figura 5 é mostrado que quanto maior o grau de conhecimento da equipe
de desenvolvimento, mais organizado e estável é o processo de gerenciamento
de risco.
2.5 RISCO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
O gerenciamento de risco deve ser aplicado durante todas as etapas do
processo de desenvolvimento de software, desde sua solicitação, proposta, até
a manutenção.
No processo de desenvolvimento de software, se utiliza uma metodologia
conhecida por Ciclo de Vida de Software (CVS). Peters e Pedrycz (2001)
definem CVS como sendo o período de tempo que se inicia com o conceito de
um produto de software e acaba sempre quando o software é disponibilizado
para utilização. Refere-se ao período de tempo durante o qual a sua existência
tem significado, desde o surgimento da idéia inicial para a realização do
software até a retirada de utilização.
Culturas de Gerenciamento de Riscos
Maior Maturidade Menor maturidade
Estimativa de Erros
Transição ao estilo pró-ativo
Antecipação das Falhas
Gerenciamento De Mudanças
Prevenção
Minimização Dos Riscos
Correção Da Falha
Gerenciamento De Crise
Gerenciamento de Riscos Pró-Ativo
Gerenciamento de Riscos Reativos
31
O Modelo de Ciclo de Vida de Software (MCVS) representa as atividades,
entradas e saídas, documentos, tabelas, medições e suas interações durante o
CVS. Alguns modelos de Ciclo de Vida de Software são rapidamente
apresentados a seguir, como por exemplo:
• Modelo Cascata
• Modelo Espiral
• Modelo Incremental
• Modelo Evolucionário
• Modelo de Prototipagem
2.5.1 MODELO CASCATA
O modelo em Cascata ou Clássico é o mais antigo dos modelos. Tem como
fase inicial o levantamento das informações, o conhecimento do assunto que
será alvo de desenvolvimento do sistema. Termina com a fase de manutenção,
cujas atividades são ajustes e melhorias aplicadas ao sistema ao longo de sua
existência e por fim a necessidade de um novo desenvolvimento para substituir
o sistema atual.
As Fases são: Exploração do Conceito – Efetuada pela Engenharia de
Requisitos, Projeto, Desenvolvimento , Testes, Instalação e Liberação,
Operação e Manutenção.
2.5.2 MODELO ESPIRAL
O modelo Espiral foi desenvolvido por Barry Boehm em 1988 e abrange as
melhores características do modelo em Cascata acrescido de uma nova
atividade que é a análise de Risco. Possui todas as atividades do modelo em
Cascata considerando quatro grupos:
• Planejamento. Determinação dos objetivos, alternativas e restrições.
• Análise de Riscos. Análise de alternativas e identificação e resolução dos
riscos.
32
• Engenharia. Desenvolvimento do produto no próximo passo da espiral.
• Avaliação feita pelo cliente. Validação dos resultados da Engenharia.
2.5.3 MODELO INCREMENTAL
O modelo incremental é semelhante ao modelo Cascata. Os requisitos e os
conceitos do software são as primeiras atividades a serem desenvolvidas e
identificadas. Em seguida, as demais atividades do desenvolvimento do
software são repetidas cada vez que há uma nova versão do software. Baseia-
se no conceito de que requisitos de software permanecem estáveis e tendem a
evoluir devido às mudanças na tecnologia e na experiência.
2.5.4 MODELO EVOLUCIONÁRIO
O modelo consiste no desenvolvimento planejado de múltiplas versões de um
produto de software, causando a evolução deste produto. Utiliza cinco
propriedades de sistemas de software para motivar os modelos evolucionários.
• Mudança contínua e degradação. Os sistemas de software sofrem
mudanças e se degradam continuamente, tornando-se cada vez menos
úteis.
• Complexidade crescente. Devido às mudanças contínuas a complexidade
do software aumenta.
• Evolução do programa. Os programas, os processos de programação, as
medidas de projeto e os atributos de sistema são estatisticamente auto-
reguladores.
• Taxa de trabalho invariável. A taxa de atividade em grandes projetos de
software é estatisticamente a mesma.
• Limite de crescimento incremental. Durante a vida de um grande projeto
de software, o volume das modificações em sucessivas versões é
estatisticamente o mesmo.
33
2.5.5 MODELO DE PROTOTIPAGEM
O modelo tem como principal objetivo demonstrar rapidamente o produto do
software. São produzidos com funcionalidades e desempenho limitados, de
forma a permitir que os desenvolvedores e clientes verifiquem as funções dos
desenvolvimentos preliminares dos modelos de sistemas antes de se
comprometerem com um sistema final.
2.6 FERRAMENTAS DE AVALIAÇÃO DE RISCO
Os benefícios propiciados por ferramentas que auxiliam no desenvolvimento de
software, são inquestionáveis.
O objetivo das ferramentas que auxiliam no gerenciamento de risco é fornecer
informações dos principais riscos e informações de como controlá-los.
Entre as ferramentas destinadas a apoiar o gerenciamento de risco,
apresentadas na literatura, destacam-se as Ferramentas ARMOR [Lyu, 1995],
a RAMP de Garvey e outros (1997) e SERIM, Karolak (2002).
2.6.1 FERRAMENTA ARMOR
A Ferramenta ARMOR (Analizer for Reducing Module Operacional Risk)
propõe-se a detectar e avaliar riscos de software, utilizando recursos baseados,
principalmente, em modelos estatísticos. A execução da ferramenta inclui as
seguintes funções, disponíveis a partir de seu menu principal:
(a) operações de arquivo
(b) seleção de escopo
(c) seleção de métricas
(d) definição e execução de modelos
(e) avaliação de riscos
34
(f) validação de modelos
(g) ajuda
Estas funções viabilizam acesso a dados que forem pertinentes às
características do software, uso de métricas aplicadas ao produto, avaliação
sistemática de métricas aplicadas ao software. Fornecendo informação para o
estabelecimento de modelos de risco, avaliação de riscos de desempenho,
identificação, validação, cálculo e apresentação de riscos relacionados a cada
módulo do software, com indicação de diretrizes para a redução dos riscos.
Na Figura 6 é mostrada a arquitetura da Ferramenta ARMOR.
FIGURA 6 – ARQUITETURA DA FERRAMENTA ARMOR - LYU E OUTROS (1995).
2.6.2 A FERRAMENTA RAMP
A Ferramenta RAMP - Risk Assessment and Management Program (programa
de gerenciamento e avaliação de riscos) possui um conjunto de informações de
Histórico
Dados de Falhas
Resultado da Avaliação
Métricas
Seleção de Critérios
Controle da Avaliação
Exposição
Tomando Decisões
Validação
Esforço de Revisão de riscos
Avaliação
Prevenção
Diretório do Projeto
Realimentação
Modelo de validação
Seleção
Modelagem de Riscos
Módulo de Avaliação
35
gerenciamento de risco que fornece uma estrutura interativa para identificar,
analisar, e compartilhar experiências do gerenciamento de risco.
Contém uma base de dados de riscos de projeto de sistemas e de estratégias
de engenharia relacionadas ao gerenciamento de risco com mais de 1.000 links
relevantes de riscos.
Os usuários podem, através do browse, obter informações de peritos do
domínio do risco específico e das áreas da tecnologia desejada, de projetos
similares e de estratégias de gerenciamento do risco.
Os usuários podem perguntar a RAMP sobre vários tipos de informação de
risco, como: Quais são os riscos de ocorrência mais freqüentemente em
desenvolvimentos de grande escala do software? Que estratégias da redução
do risco foram bem sucedidas?
Na Figura 7 é mostrado um overview da Ferramenta RAMP que tem seu
funcionamento e operação através da Internet. Os usuários de RAMP podem
examinar as informações de riscos através de consultas em projetos similares.
FIGURA 7 – VISÃO GERAL DA FERRAMENTA RAMP – GARVEY E OUTROS (1997).
informações
RAMP administração
Servidor RAMP
usuários
corporativo
Serviços
Interfaces
pesquisa Dados pesquisa consulta
WEB
36
2.6.3 A FERRAMENTA SERIM
A Ferramenta SERIM (Software Engineering Risk Management) auxilia a
identificação de um caminho mais seguro para desenvolvimento do software
considerado com base na identificação dos riscos potenciais e das etapas ou
atividades do projeto que necessitam maior atenção. Após a identificação dos
riscos, a ferramenta auxilia a elaboração de planos no sentido de mitigar os
riscos latentes. SERIM baseia-se em um modelo de gerenciamento de risco
que engloba a identificação de riscos relativos ao desenvolvimento técnico do
sistema, os custos envolvidos e os prazos estipulados.
37
CAPÍTULO 3
MODELO DE GERENCIAMENTO DE RISCO
3.1 CONSIDERAÇÕES INICIAIS
Das várias pesquisas realizadas sobre gerenciamento de risco, como as
citadas no capítulo anterior, existem lacunas entre as pesquisas e as atividades
profissionais em relação à forma de aplicação, identificação dos benefícios e
outros.
Com o intuito de unir o mundo da pesquisa às opiniões de profissionais,
baseados em suas experiências e históricos de desenvolvimentos de software,
idealizou-se a criação de um modelo (GRisk-Model) que se utiliza das
metodologias de desenvolvimento de sistemas de softwares, associando as
informações das pesquisas.
A definição do GRisk-Model contou com a participação de uma equipe de
profissionais formada por 1 gerente comercial, 1 gerente de fábrica de
software, 3 coordenadores de fábrica de software e 3 analistas de sistemas
sênior.
O modelo apresenta inicialmente uma definição de gerenciamento de riscos a
ser realizada nas etapas do processo de desenvolvimento de software. Esta se
divide em identificação, análise e priorização e controle dos riscos. O objetivo
do modelo de gerenciamento de risco é descrever, com base nos conceitos do
Capítulo 2, um processo a ser utilizado durante o desenvolvimento de um
projeto. Como complemento e auxílio ao gerenciamento, o modelo possui uma
estrutura com uma base de conhecimento dos possíveis riscos a serem
38
encontrados nas fases e atividades do ciclo de vida de desenvolvimento do
projeto.
Para a criação do modelo GRisk-Model, foram elaboradas descrições e
indicadas classes e riscos associados às fases e atividades do processo de
desenvolvimento do software.
Periodicamente, reuniões foram realizadas, nas quais o grupo efetuou uma
avaliação das classes e dos riscos correspondentes.
Ao final do trabalho, obteve-se tabela de riscos, classificadas em classe para
todas as fases do ciclo de vida de desenvolvimento do software.
3.2 CICLO DE VIDA ADOTADO
Utiliza-se neste trabalho o paradigma de ciclo de vida em cascata. A opção
pelo ciclo de vida em cascata foi em função deste, ser a origem dos demais, ou
seja, todos os demais ciclos de vida possuem sua origem nas fases e
atividades do ciclo de vida em cascata.
3.3 CLASSES DE RISCOS
Com base no Appendix H (2000), a equipe de trabalho definiu que os riscos
apresentados são agrupados por classes de riscos. As classes de riscos
utilizadas no modelo referem-se a: Riscos de Relacionamento; Riscos
Organizacionais; Riscos Financeiros; Riscos Gerenciais; Riscos Técnicos e
Riscos Legais. Essas classes de riscos são caracterizadas a seguir.
• Riscos de Relacionamento (RR). São riscos que envolvem os
relacionamentos entre desenvolvedores e usuários, entre usuários e
usuários superiores quando da definição de funcionalidades. Podem
também existir riscos de relacionamentos entre área comercial e área
técnica na definição de escopos e valores das propostas.
39
• Riscos Organizacionais (RO). São riscos que envolvem a empresa.
Empresa pode ser a solicitante do sistema ou a empresa responsável pelo
desenvolvimento do sistema. Envolvem mudanças organizacionais que
afetam o sistema em questão como, por exemplo, organogramas,
mudanças na área usuária, demissão do responsável pelos sistemas.
• Riscos Financeiros (RF). São riscos que causam gastos financeiros além do
planejado. Podem ocorrer em todas as fases do modelo. Iniciam com os
valores de propostas mal elaborados até custos de equipamentos não
planejados para a operacionalização do sistema.
• Riscos Gerenciais (RG). São riscos que envolvem gerenciamento do
desenvolvimento dos sistemas. Determinação de metodologias, critérios,
métricas, definições de profissionais que formarão a equipe de trabalho,
ambiente de desenvolvimento e os recursos necessários para o
desenvolvimento .
• Riscos Técnicos (RT). É a classe de risco mais abrangente. Define o
conjunto de riscos que envolvem a parte técnica dos processos. É o
conjunto de riscos causados pela falta de experiência dos profissionais.
• Riscos Legais (RL). São riscos que envolvem leis como, por exemplo,
exigências fiscais, licenças de cópias de software, mudanças de leis
tributárias durante ou após o desenvolvimento do sistema.
3.4 GERENCIAMENTO DE RISCO
O gerenciamento de risco no projeto tem por objetivo evidenciar os resultados
positivos e minimizar os riscos. Conforme PMI (2002) e Campbell e Cavalieri
(2003) Gerenciamento de Risco é a ação de planejar, identificar, analisar,
priorizar e controlar riscos. Nesta ação também estão contidas atividades de
planejamento e acompanhamento de atividades que reduzem a probabilidade
de ocorrências que venham a impactar no processo de desenvolvimento de
software. Os riscos não são simplesmente identificados, eles devem ser
40
identificados para que sejam previstos e diminuídos, se possível, ou para que
sejam controlados quando houver poucas estratégias para a sua diminuição.
O Gerenciamento de Risco descreve as tarefas que serão executadas, as
responsabilidades atribuídas e quaisquer recursos adicionais necessários para
a atividade. Em um projeto menor, esta atividade pode ser incorporada ao
Plano de Desenvolvimento de Software.
O segredo do gerenciamento de risco é não esperar até que ocorra risco (e
isso passe a ser um problema ou uma falha) para decidir o que fazer em
relação a ele.
O gerenciamento de risco sugerido neste trabalho, baseado no PMI (2002) e
Campbell e Cavalieri (2003), dividem-se nas etapas descritas a seguir:
• Identificar Riscos;
• Analisar e priorizar riscos;
• Controlar Riscos.
3.4.1 IDENTIFICAR RISCOS
Identificar riscos é a ação de determinar quais os riscos que poderão causar
problemas no projeto e documentar suas características. Para a identificação
dos riscos é necessário ter conhecimento sobre os escopos e objetivos do
projeto, qualidade, prazos e custos.
Esta atividade deverá ser realizada em todas as etapas do processo de
desenvolvimento de software, sendo que a primeira identificação deverá ser
efetuada pela equipe de gerência do projeto, onde os riscos que envolvem todo
o processo deverão ser identificados, ainda na fase inicial, para determinação
de prazos e custos do projeto. Esta lista inicial de riscos deverá ser utilizada
como referência para as demais.
Em cada fase é definida uma equipe que identificará os possíveis problemas.
Esta equipe deverá ser composta principalmente pelos líderes das atividades e
sempre pelo gerente do projeto.
41
Cada elemento da equipe deverá utilizar a base de conhecimento do modelo
GRisk-Model, registrada na ferramenta GRisk-Tool, para obter os históricos dos
possíveis riscos em cada fase do processo de desenvolvimento de software
como orientação à sua análise e identificação de risco do projeto e fase que
estão sendo avaliados.
Deverá preencher os respectivos formulários, apresentados no Apêndice A,
com os riscos identificados em cada fase do processo. Para cada fase
atividade serão utilizados formulários específicos, conforme apresentado a
seguir, no item A do Apêndice A.
A equipe da fase correspondente deverá se reunir para discutir sobre os riscos
identificados individualmente. A equipe poderá usar técnicas Delphi,
apresentada no tópico a seguir, e outras técnicas de elicitação, onde cada
componente poderá efetuar perguntas e esclarecimentos a respeito dos riscos
apresentados. É importante esclarecer aos participantes que os riscos
apontados podem, ainda, não possuir solução. É comum, os integrantes da
equipe, se inibirem no apontamento de riscos quando não possuem a solução
para os mesmos.
O grande objetivo é produzir uma lista de riscos de consenso da equipe e
efetuar uma junção dos riscos de mesma finalidade, eliminando possíveis
repetições. Os riscos identificados representam as barreiras para o sucesso de
cada fase do ciclo de vida trabalhado. O Produto final desta ação é uma Tabela
de Riscos de consenso geral, agrupados por classes de riscos.
Os riscos identificados em um processo novo poderão ser registrados na
ferramenta de risco GRisk-Tool, produzindo assim novos históricos de riscos.
3.4.1.1 TÉCNICA DELPHI
Conforme Campbell e Cavalieri (2003), a técnica baseia-se na consolidação de
documentos preenchidos pelo grupo responsável buscando um consenso para
todos os riscos identificados.
42
Um responsável conduz a aplicação da técnica que consiste na formação de
uma equipe, conhecida, responsável pela identificação de risco. A equipe
preenche os formulários com sua opinião mantendo anonimato. Uma rodada
inicial, para obtenção das informações é realizada. O responsável tabula,
consolida e reduz as informações obtidas em um único formulário. Através
destas informações efetuam-se classificações, médias e priorizações. Novas
rodadas são executadas com as informações consolidadas em formulário
único. Solicitam-se, a cada participante, suas opiniões, avaliações e
informações adicionais.
O processo é repetido até que se obtenha uma relação com alto grau de
consenso.
3.4.2 ANALISAR E PRIORIZAR OS RISCOS
Para cada risco na Lista de Riscos, a equipe de gerenciamento de riscos
deverá definir a estratégia a ser usada para verificar o risco e como corrigir a
situação (um plano de contingência). As abordagens de gerenciamento de
riscos incluem prevenção, transferência, aceitação e diminuição.
Os riscos serão priorizados baseados na sua análise qualitativa e quantitativa
PMI (2002).
Como na Identificação de Riscos, nesta fase, a indicação dos fatores
qualitativos e quantitativos serão consensos da equipe.
Fatores Qualitativos
Probabilidade de Ocorrência: deve ser classificada em muito alta (5),
alta (4), moderada (3), baixa (2) e muito baixa (1). A probabilidade de um
risco é a probabilidade de que um determinado risco venha a acontecer.
Impacto do Risco: deve ser classificado em muito alto (5), alto (4),
moderado (3), baixo (2) e muito baixo (1). É o efeito nos objetivos do
projeto, se o risco vier a acontecer.
43
Fatores Quantitativos
Freqüência: deve ser classificada em muito alta (5), alta (4), moderada
(3), baixa (2) e muito baixa (1). É a análise numérica da probabilidade
de ocorrência de um risco.
Exposição do Risco: utiliza-se neste trabalho a conceituação de Boehm
(1991), ou seja, a exposição do risco é o produto da probabilidade de
ocorrência e do impacto. Portanto tem-se a fórmula:
ER = PR * IP
Sendo:
ER = Exposição do Risco
PR = Probabilidade do Risco
IP = Impacto do Risco.
Portanto, quanto maior forem a freqüência e o impacto, maior será à exposição
ao risco.
Após a avaliação e a finalização da análise qualitativa e quantitativa dos riscos,
a equipe tem a responsabilidade de indicar a prioridade de cada um dos riscos
da Tabela de Riscos.
Como produto final tem-se a Tabela de Riscos, acrescentada de mais 3
colunas: prioridade, freqüência e exposição do risco.
3.4.3 CONTROLAR OS RISCOS
Conforme Boehm (1991) existem três estratégias principais que auxiliam no
controle de riscos:
Prevenção de riscos. Efetuar ajustes no projeto para que ele não possa ser afetado por um risco.
Transferência de risco
44
Reorganização do projeto para alguém ou algo assumir o risco (o cliente, o
fornecedor, o banco, um outro elemento etc.). Repassar os custos do risco a
alguém. Esta é uma estratégia específica de prevenção de riscos.
Aceitação do risco Aceitar e conviver com o risco como uma contingência. É necessário o
acompanhamento sobre as conseqüências do risco e definição de ações de
contingência que orientem sobre o procedimento a ser tomado em caso de
risco. Pode ser possível diminuir o risco tomando alguma ação para reduzir seu
impacto.
As Tabelas de riscos devem ser revistas periodicamente para avaliar a eficácia
das estratégias de diminuição de riscos e, conseqüentemente, orientar as
próximas ações.
O gerenciamento de riscos será mais eficaz se for considerado um processo
contínuo. O Gerenciamento de Riscos deverá definir uma programação para a
emissão de relatórios freqüentes de status de riscos, bem como reuniões para
a revisão de riscos. Também deverá identificar as condições que determinam
reuniões não programadas para a revisão de riscos. Com a utilização da
Ferramenta GRisk-Tool, pode-se efetuar um acompanhamento dos riscos
identificados no projeto.
3.5 RISCOS NAS FASES E ATIVIDADES NOS PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE
O maior objetivo do modelo é indicar, para cada fase e atividade dos processos
de desenvolvimento de software, os riscos conhecidos e se possível uma
sugestão de controle. Com estas informações gera-se a base de
conhecimento.
As fases que se utiliza neste modelo são:
• Aspectos comerciais;
• Engenharia de Requisitos;
45
• Projetos;
• Desenvolvimento;
• Testes;
• Instalação e Liberação;
• Operação;
• Manutenção.
A seguir, descreve-se sucintamente cada fase com suas atividades indicando,
pela equipe composta para a definição do modelo GRisk-Model e uma tabela
de riscos correspondente a cada fase.
3.5.1 PROPOSTA – ASPECTOS COMERCIAIS
A proposta é um documento oficial enviado para aprovação do Cliente com a
identificação técnica e comercial do sistema.
Para se efetuar um gerenciamento de risco na fase “Proposta” deve-se
considerar os aspectos:
• Análise dos Custos Iniciais de levantamento ;
• Avaliação e Definição do escopo;
• Preparação da Proposta;
• Evolução dos Negócios com análise de riscos e benefícios;
• Especificação para Preenchimento da Proposta Técnica.
Para se obter regras e diretrizes a respeito de cada um desses itens,
considera-se altamente o conhecimento adquirido e as experiências anteriores.
As informações históricas, experiências e técnicas de avaliações de
complexidade, como por exemplo, análise de ponto de função que permite criar
regras e métodos cada vez mais eficientes.
3.5.1.1 ANÁLISE DOS CUSTOS INICIAIS DE LEVANTAMENTO
Uma análise criteriosa de viabilidade do projeto-proposta deve ser efetuada
para estabelecer o esforço necessário da fase de pré-venda / pré-elaboração.
46
Nesta avaliação é interessante ter-se uma idéia do orçamento do cliente.
Muitas vezes o cliente só quer especular.
3.5.1.2 AVALIAÇÃO E DEFINIÇÃO DO ESCOPO
Para se elaborar uma proposta , torna-se necessário um levantamento das
necessidades do cliente, sendo esta muitas vezes superficial, causando uma
distorção no escopo e nos valores. É aconselhável que a elicitação dos
requisitos seja efetuada por um profissional experiente e conhecedor do
empreendimento do cliente. Técnicas devem ser utilizadas para que este
profissional forneça as informações necessárias ao gerente que irá elaborar a
proposta para identificar o objetivo do empreendimento, objetivo do sistema,
características do sistema, macro fluxo do projeto, módulos do sistema,
necessidades do sistema, ambiente operacional etc.
Quantificar os arquivos que serão mantidos pelo sistema. Quantificar as
funções identificadas para atender às necessidades do sistema e dos arquivos
externos. Quantificar os arquivos de integração do sistema com outros
sistemas (exportação e importação).
Estimar o projeto (tamanho, esforço, custo e prazo) através da qualificação e
quantificação dos arquivos e funcionalidades do sistema.
Elaborar o Cronograma Físico Financeiro observando-se o seguinte:
• O Cronograma deverá ser elaborado com base nas informações resultantes
dos levantamentos iniciais, verificação de parâmetros, infra-estrutura
necessária e avaliação dos SLAs (acordos de níveis de serviços);
• No formato do cronograma devem constar as principais fases do projeto
com os esforços e custos previstos para cada fase e para cada atividade;
• Consultar a base histórica de cronogramas já elaborados para os casos de
similaridade de fábrica de programas;
• A alteração do Cronograma Físico Financeiro deverá ocorrer sempre que
for alterado o escopo da Proposta Técnica/ Comercial.
47
3.5.1.3 PREPARAÇÃO DA PROPOSTA
Para a elaboração da proposta, utiliza-se das informações da fase anterior:
Objetivos, Escopos, Necessidades, Quantidades de Pontos de Função, Custos
de Desenvolvimento, Cronogramas. Também é necessário estabelecer a
equipe técnica qualificada para o desenvolvimento do projeto e redigir um texto
de fácil interpretação. Como são muitos os itens que envolvem esta fase, e às
vezes o tempo utilizado não foi suficiente para um levantamento detalhado, o
ideal é a definição de uma proposta até a fase de prototipagem e após essa
então elaborar a proposta definitiva do projeto. No caso dessa opção não ser
aceita pelo usuário, deve-se utilizar profissionais com muita experiência para
com seu conhecimento elaborar o escopo, pois este será o fator de sucesso ou
de fracasso da proposta. Quanto menor ou imprecisas forem as informações
obtidas maior deve ser considerado o risco financeiro e, portanto, uma margem
de segurança deve ser acrescentada à proposta.
3.5.1.4 EVOLUÇÃO DOS NEGÓCIOS
Nesta etapa consideram-se os riscos e benefícios presentes e futuros,
relacionados ao cliente. A definição de uma proposta é sempre uma decisão
subjetiva elaborada por gerentes comerciais, baseados nas informações da
etapa Avaliação e Definição do Escopo.
Uma análise da avaliação do cliente é essencial para tomadas de decisões
quanto a custo e lucro e deve ser feita considerando o Capital e o cumprimento
dos compromissos financeiros.
3.5.1.5 ESPECIFICAÇÃO PARA PREENCHIMENTO DA PROPOSTA TÉCNICA
Os campos relacionados a seguir, contêm as informações básicas para a
composição de uma proposta.
TÍTULO DO PROJETO. Inserir o nome do projeto.
LOGOTIPO DO CLIENTE. Inserir o logotipo do cliente.
48
CLIENTE. Preencher a Razão Social do Cliente, o nome do projeto, o nome,
telefone e e-mail dos gerentes de negócios e de fábrica de software.
OBJETIVO DO PROJETO. É a definição que o projeto visa alcançar com o
desenvolvimento da solução. Transferir as informações levantadas.
BENEFÍCIOS DO PROJETO. São identificadas as vantagens que o Cliente
terá com o desenvolvimento da solução.
REFERÊNCIAS ESPECÍFICAS. Preencher com o logo da empresa, o nome da
empresa e o título de serviços similares prestados anteriormente.
ESTUDO DE CASO. Descrição sobre a situação atual, antes do
desenvolvimento da solução proposta. Transferir as informações levantadas.
BENEFÍCIOS ESPERADOS. São identificados outros benefícios que o Cliente
terá com o desenvolvimento da solução.
MACRO FLUXO DO PROJETO. Desenho que demonstra as fronteiras do
sistema que será desenvolvido e os outros sistemas já existentes. Transferir as
informações levantadas.
REQUISITOS DE QUALIDADE. Requisitos de Qualidade oferecidos ao cliente
pela equipe de desenvolvimento.
SOLUÇÃO PROPOSTA. Descrição da solução proposta, com base nas
especificações fornecidas pelo cliente em documento ou reunião de
levantamento.
TABELAS ENVOLVIDAS. Quantificação dos arquivos internos da solução
proposta, inclusive com seu respectivo nível de complexidade (simples, médio
e complexo). Transferir as informações levantadas sobre os arquivos
necessários.
ARQUIVOS EXTERNOS. Quantificação dos arquivos externos (exportação e
importação de dados) à solução proposta. Transferir as informações
levantadas - Lista de Arquivos de Interfaces Externas.
49
FUNÇÕES ENVOLVIDAS. Quantificação das funcionalidades da solução
proposta, inclusive com seu respectivo nível de complexidade (simples, médio
e complexo). Transferir as informações levantadas - Lista das funcionalidades.
ITENS NÃO INCLUSOS. Identificação dos itens que não estão sendo
contemplados na proposta.
RECURSOS CRÍTICOS. Descrição das Necessidades de infra-estrutura,
Equipamentos e Ferramentas, Espaço Físico e Instalações e Pessoal Crítico,
Qualificado e Treinado. Este item se refere aos equipamentos de alta
capacidade tecnológica, de grande armazenamento, etc. São recursos que
serão necessários ao desenvolvimento do projeto que estão fora do padrão.
HARDWARE RECOMENDADO. Descrição de sugestão do hardware utilizado
para a solução proposta.
GERÊNCIAMENTO DO PROJETO. Descrição de definições de
responsabilidades de gerenciamento do projeto tanto pelo desenvolvedor
quanto pelo Cliente.
EQUIPE DE DESENVOLVIMENTO. Descrição dos perfis e quantidade de
profissionais envolvidos na execução do projeto.
AMBIENTE DE DESENVOLVIMENTO. Descrição do ambiente de
desenvolvimento: linguagens, banco de dados, sistema operacional, gerador de
relatórios, servidor de aplicativos etc.
LOCAL DE TRABALHO. Descrição da definição de onde será executado o
desenvolvimento da solução proposta.
INÍCIO DO PROJETO. Descrição do prazo em dias úteis para o início da
solução proposta.
CRONOGRAMA. Cronograma inicial previsto para desenvolvimento da solução
proposta.
50
MUDANÇAS DE ESCOPO. Considerações sobre alterações do escopo da
solução proposta. Não será necessário o preenchimento (item padrão da
proposta, conforme Modelo de Proposta).
VALIDAÇÃO. Considerações sobre as atividades de validação da solução
proposta.
IMPLANTAÇÃO. Descrição do prazo em dias úteis e custo hora de profissional
para horas adicionais da solução proposta.
TREINAMENTO. Descrição do treinamento dos sistemas e da quantidade de
pessoas envolvidas no treinamento.
GARANTIA. Descrição do prazo de garantia da solução proposta e as
condições em que a garantia pode ser acionada.
SUPORTE. Considerações sobre o suporte da solução proposta.
PRODUTOS GERADOS. Descrição dos produtos, fase a fase, que serão
entregues ao Cliente conforme a solução proposta.
COMPOSIÇÃO DO INVESTIMENTO. Descrição do prazo em dias úteis e do
custo total da solução proposta. Informação a ser complementada pelo Gerente
Comercial.
CRONOGRAMA E DESEMBOLSO. Descrição das condições de pagamento.
Informação a ser complementada pelo Gerente Comercial
VALIDADE. Descrição da data de validade da proposta. Informação a ser
complementada pelo Gerente Comercial.
DIREITOS DE PROPRIEDADE. Descrição dos diretos de propriedade.
RESPONSABILIDADES. Descrição das responsabilidades mútuas da
proposta, do fornecedor para com o cliente e do cliente para com o fornecedor.
ACEITE DA PROPOSTA. Formalizar o Aceite da proposta.
51
ANEXOS. Documentos Anexos à proposta (se houver).
3.5.1.6 TABELA GERAL DOS RISCOS DA FASE DE PROPOSTA
A Tabela 10, a seguir, apresenta os riscos da fase de proposta agrupados por atividades.
TABELA 10 - TABELA GERAL DOS RISCOS DA FASE DE PROPOSTA
Atividade Risco Associado Classe Análise dos Custos Iniciais de levantamento
• Cliente com Orçamento Inadequado • Custo de pré-venda inviável
RF RF
Avaliação e Clareza do escopo
• Falta de profissionais experientes no empreendimento do cliente
• Técnicas de elicitação mal empregadas • Análise de ponto de função mal elaborada • Clientes sem objetivos claros • Clientes com objetivos divergentes • Recurso do Produto viola patentes • Licenças não disponíveis dos produtos a serem utilizados
RT
RT RT RF RF RL RL
Preparação da Proposta
• Pouco tempo para levantamento • Profissionais com pouca experiência • Textos com várias interpretações ou interpretações dúbias • Gerente Comercial com pouca experiência. • Escopos mal elaborados • Determinação de prazos mal definida
RG RT RT RT RF RF
Evolução dos Negócios, com análise de riscos e benefícios.
• Avaliação relacionada ao cliente mal elaborada, devido a pouca ou nenhuma analise das informações sobre o cliente.
RF
Especificação para Preenchimento da Proposta Técnica
• Avaliação do Escopo mal elaborada ou mal escrita • Não estabelecimento dos direitos de propriedade e sigilos • Não formalização do aceite da proposta • Cronograma mal elaborado
RF RL RL RG
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.2 ENGENHARIA DE REQUISITOS
Zave (1997) apresenta uma definição clara da RE, Engenharia de Requisitos. É
um ramo da Engenharia de Software preocupada com as metas do mundo-real
para funções e restrições dos sistemas de softwares e também o que
corresponde no relacionamento desses fatores para uma especificação precisa
do comportamento do software e para sua evolução ao longo do tempo e
famílias de softwares.
52
Para se efetuar um gerenciamento de risco na fase Engenharia de Requisitos,
deve-se considerar os aspectos:
a) Processo de efetuar o levantamento das informações necessárias para o
desenvolvimento do sistema e para efetuar o cálculo de ponto de função.
b) Fatores relevantes para este processo é a definição dos papéis que os
usuários e os desenvolvedores desempenham e a consideração de que as
necessidades sempre mudam com o tempo.
c) Evolução dos recursos tecnológicos é constante e o processo de extração
de requisitos deve ser contínuo.
As etapas que devem ser efetuadas são:
• Entendimento do empreendimento do cliente;
• Extração e análise de requisitos com a técnica de entrevistas;
• Especificação e documentação dos levantamentos, através da escrita, de
representações simbólicas ou gráficas;
• Validação, através da confirmação com o usuário, das informações obtidas
e apresentadas na documentação efetuada;
• Cálculo de Ponto de Função;
• Prototipagem;
• Acompanhamento do Usuário.
3.5.2.1 ENTENDIMENTO DO EMPREENDIMENTO DO CLIENTE
O entendimento do empreendimento do cliente, objeto do desenvolvimento que
está se iniciando, forma a primeira atividade a ser executada. As informações
obtidas nessa atividade devem ser interpretadas, analisadas, modeladas e
validadas. É nessa etapa que as funcionalidades são entendidas, que o objeto
do desenvolvimento é explicado. É onde o cliente solicita e explica suas
necessidades.
53
3.5.2.2 EXTRAÇÃO E ANÁLISE DE REQUISITOS COM A TÉCNICA DE ENTREVISTAS
Conforme Pressman (2002) e Peters e Pedrycs (2001), a fase de Extração e
Análise de Requisitos são atividades onde o engenheiro de requisitos ou
analista discute o sistema com diferentes usuários e obtém um entendimento
das funcionalidades desejadas e requeridas pelo projeto.
As entrevistas acontecem através de uma série de encontros com os usuários.
Requer uma habilidade de saber ouvir e habilidades sociais gerais.
Passos para a realização de uma entrevista:
• Identificação dos entrevistados;
• Preparação de agenda com lista de perguntas;
• Determinação dos objetivos;
• Identificação dos assuntos abordados;
• Confirmação da resposta obtida (repetir resumidamente a resposta do
entrevistado, para confirmar seu entendimento);
• Conclusão da entrevista.
3.5.2.3 ESPECIFICAÇÃO E DOCUMENTAÇÃO DOS LEVANTAMENTOS
Conforme Pressman (2002) e Peters e Pedrycs (2001), especificação e
documentação dos levantamentos são efetuados através da escrita, de
representações simbólicas ou gráficas.
Atividade onde os levantamentos efetuados são documentados de forma
descritiva, de forma gráfica utilizando técnicas de modelagem de funções e de
dados.
Nesta atividade podem ser utilizados diagramas de fluxo de dados para a
análise estruturada ou casos de uso para a análise orientada a objetos.
3.5.2.4 VALIDAÇÃO DO USUÁRIO
54
Conforme Yourdon (1990), a validação do usuário é efetuada através da
confirmação do usuário sobre as informações apresentadas na documentação
efetuada.
Etapa onde a participação do usuário é fundamental. Ele efetuará análise
sistemática das funcionalidades relacionadas nas documentações e nos
modelos gráficos, observando as funcionalidades requeridas. Aprova ou não o
trabalho desenvolvido pela equipe de desenvolvimento de sistemas de
software.
3.5.2.5 CÁLCULO DE PRAZOS
Os prazos podem ser estabelecidos por diversas métricas. Neste trabalho
serão utilizadas as métricas de Pontos de Função.
Pontos de Função representam uma métrica utilizada para definir o tamanho e
complexidade do software e então obter o tempo de desenvolvimento.
A métrica dos pontos de função foi definida por Allan J. Albrecht (IBM, White
Plains) em 1979. Esta técnica mede um sistema a partir da visão externa que
se tem dele, tornando-se fácil sua compreensão pelo cliente. É independente
da linguagem ou hardware utilizado, permitindo a estimativa do esforço que
será utilizado.
Em 1986 foi criado o International Function Point User Group (IFPUG),
destinado a divulgar informações da técnica de novos desenvolvimentos a
todos os seus associados.
Atualmente, 2005, esta técnica é utilizada por grandes empresas como a
AT&T, GENERAL ELECTRIC, EXXON, FUJITSU, IBM, e outras.
A técnica baseia-se na visão externa que se pode ter do sistema e por isso a
visão do cliente deve prevalecer. Para os cálculos, devem-se levantar,
inicialmente através de entrevistas com o usuário, os seguintes elementos:
• Quantidade e complexidade dos arquivos lógicos internos (ALI) ;
55
• Quantidade e complexidade dos arquivos de interface externa (AIE);
• Quantidade e complexidade das entradas externas (EE);
• Quantidade e complexidade das saídas externas (SE);
• Quantidade e complexidade das consultas externas (CE).
Segundo a definição do IFPUG (2000), com as informações obtidas, é efetuado
o processo de cálculo do tamanho de um sistema, que envolve as atividades
descritas a seguir:
• Identificar os Arquivos Lógicos Internos (ALI), Arquivos de Interface Externa
(AIE), Entradas Externas (EE), Saídas Externas (SE) e Consultas Externas
(CE);
• Classificar cada função quanto à complexidade funcional relativa como:
simples, média ou complexa;
• Calcular os Pontos de Função Brutos através da aplicação dos pesos de
acordo com uma tabela específica;
• Efetuar avaliação das 14 Características Gerais do Sistema calculando o
fator de ajuste;
• Calcular os Pontos de Função ajustados.
3.5.2.6 PROTOTIPAGEM
Conforme Bernstein (1998), a prototipagem de sistemas de software é utilizada
principalmente, para animar e demonstrar os requisitos de um sistema,
buscando ajudar os clientes e os responsáveis pelo desenvolvimento do
projecto a testar e a melhorar o sistema antes mesmo de este estar finalizado.
A prototipagem é utilizada para gerar protótipos de interfaces com o utilizador
em conjunto com cenários, facilitar a compreensão, por parte dos clientes, do
sistema de software a ser desenvolvido, no levantamento e validação de
requisitos, reduzir a ambiguidade, inconsistência e falta de compreensão. A
prototipagem vem sendo usada com um sucesso incrível, permitindo desde o
inicio do projeto que se ganhe uma melhor percepção dos requisitos do
sistema.
56
3.5.2.7 ACOMPANHAMENTO DO USUÁRIO
Conforme Pressman (2002) e Peters e Pedrycs (2001), o acompanhamento do
usuário durante a fase de Engenharia de Requisitos é parte fundamental para o
sucesso e evolução do projeto. O usuário deverá efetuar uma análise
sistemática das funcionalidades relacionadas nas documentações e nos
modelos gráficos, observando as solicitações requeridas. Aprovar ou não o
trabalho desenvolvido pela equipe de desenvolvimento de sistemas de
software.
3.5.2.8 TABELA GERAL DOS RISCOS DA FASE DE ENGENHARIA DE REQUISITOS
Na Tabela 11, a seguir, são apresentados os riscos da fase de Engenharia de
Requisitos, agrupados por atividade.
TABELA 11 - TABELA GERAL DOS RISCOS DA FASE – ENGENHARIA DE REQUISITOS.
Atividade Risco Associado Classe Entendimento do empreendimento do cliente
• Pouca ou nenhuma disponibilidade de tempo para entendimento • Profissionais com pouca ou nenhuma experiência em
relacionamento com pessoas e sem experiência com relacionamento sem objetividade.
• Profissionais sem experiência no tipo de desenvolvimento requerido
• Profissionais sem conhecimento das atividades da empresa. • Pouca ou nenhuma documentação das atividades e objetivos
identificados.
RO RR
RT
RO
RT
Extração e análise de requisitos
• Usuários com pouca ou nenhuma objetividade • Profissionais com pouco ou nenhum conhecimento da técnica de
Entrevistas • Interpretação errada das necessidades do cliente • Problemas de relacionamento entre cliente e profissional • Dificuldade de agenda, pelo cliente. • Resistência a mudanças • Falta de colaboração, por parte do cliente, na identificação das
funcionalidades do sistema.
RO RT
RT RR RO RO RO
Especificação e documentação dos levantamentos
• Profissionais com pouco ou sem experiência em documentação dos levantamentos efetuados
• Profissionais com pouco ou sem experiência de técnicas de modelagem
• Falta de previsão desta atividade • Desenvolvimento incompleto ou fraco desta atividade
RT
RT
RG RG
Tabela 11 - Tabela Geral dos Riscos da Fase – Engenharia de Requisitos – Continuação
Atividade Risco Associado Classe
57
Validação com usuário • Pouca ou nenhuma disponibilidade de tempo do usuário • Falta de conhecimento do usuário relacionado às
funcionalidades requeridas e às que os softwares oferecem • Dificuldade na tomada de decisão por parte do usuário • Falta de definição dessa fase dentro das etapas • Comunicação inadequada entre desenvolvedores e usuários • Funcionalidades não ou mal definidas pelos usuários • Falta de conhecimento pelo desenvolvedor do domínio do
problema e das funcionalidades identificadas no processo de extração de requisitos
RO RO
RO RG RR RO RT
Calcular prazos
• Falta de conhecimento técnico para utilização da metodologia • Levantamentos mal elaborados, causando falta de informações
para a determinação do Calculo dos prazos. • Problemas de orçamentos pela falta de planejamento de
atividades de apoio: ambiente, instalação de rede, gestão, etc. • Problemas de orçamentos por não definição de ações
relacionadas às atividades dependentes do cliente: agenda de reuniões para determinação de funcionalidades, prazos de validações de atividades e documentos, prazos de definição de homologações.
• Falta de elaboração de cronograma com registros dos prazos calculados
RG RT
RF
RF
RG
Prototipagem • Não determinação dessa fase no projeto • Pouco ou nenhum conhecimento sobre a Prototipagem • Desenvolvimento do protótipo muito demorado • Falta de consenso entre profissional e usuário • Usuário exige o desenvolvimento imediato do protótipo
RG RG RT RF RR
Acompanhamento Usuário
• Não determinação dessa fase no projeto • Comunicação inadequada entre desenvolvedores e usuário • Dificuldade na tomada de decisão por parte do usuário • Indisponibilidade do usuário • Falta de conhecimento do usuário: das funcionalidades
requeridas e do que o software pode lhe oferecer
RG RR RO RO RO
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.3 PROJETOS
Conforme Pressman (2002) e Peters e Pedrycs (2001), a fase Projetos ocupa-
se da determinação da especificação técnica, dos processadores apropriados
para execução das tarefas do sistema em desenvolvimento.
Desenvolve a hierarquia apropriada de módulos de programa e interfaces entre
esses módulos para atender as funcionalidades solicitadas.
Efetua a transformação de modelos de dados de entidades em relação a um
projeto de banco de dados e determina a infra-estrutura necessária tanto de
hardware como de software.
58
É importante conhecer o projeto de sistemas principalmente em sistemas de
pequeno e médio porte, pois é normal a mesma pessoa documentar os
requisitos do usuário e desenvolver o projeto.
No final de tudo, a equipe de projeto terá de decidir que combinação de
hardware, sistema operacional, recursos de telecomunicação, linguagens de
programação e estratégia de projeto atenderão melhor aos requisitos
solicitados.
Nesta fase desenvolvem-se planos de testes e especificações dos casos de
testes.
Na fase Projetos serão efetuados as etapas:
• Especificação Técnica;
• Especificação de Programa;
• Elaboração de Planos de Testes;
• Especificação de Casos de Testes.
3.5.3.1 ESPECIFICAÇÃO TÉCNICA
Para dar início ao desenvolvimento , é necessária a preparação dos
“ambientes” de software e hardware.
Descrição das características de software, processos e métodos de produção.
Pode incluir exigências aplicáveis a um determinado produto, processo ou
método de produção ou operacionalização.
Etapa onde serão criados os bancos de dados com as tabelas, instalação dos
drivers necessários para acesso ao banco, configuração do ambiente com
instalações de softwares, enfim, toda a estrutura necessária para possibilitar a
equipe de desenvolvimento dar início à codificação e testes dos programas.
3.5.3.2 ESPECIFICAÇÃO DE PROGRAMA
59
Elabora as especificações dos programas identificados no Protótipo. Fornece
uma descrição detalhada do programa a ser desenvolvido. Tal descrição
poderá ser feita da seguinte forma: especificação descritiva, pseudocódigo ou
diagrama modular. Considerar sempre os itens tempos de resposta,
visualização de dados, capacidade de armazenamento (volumes), lógica e
seqüência do processo, dependências e interfaces externas.
3.5.3.3 ELABORAÇÃO DE PLANOS DE TESTES
É necessário que algumas questões importantes para o projeto tenham sido
especificadas e bem definidas para se iniciar a atividade de teste propriamente
dita, além da preocupação com os custos e recursos do teste. A estratégia
propõe que o plano de teste contenha os seguintes itens: identificação dos
requisitos através de caso de uso, identificação dos tipos de teste, técnicas e
critérios, revisão do plano de trabalho quanto aos recursos humanos e revisão
do plano de trabalho quanto ao ambiente.
3.5.3.4 ESPECIFICAÇÃO DE CASOS DE TESTES
A partir dos casos de uso e requisitos podem ser extraídos casos de teste e,
posteriormente, dependendo do critério e da técnica selecionados, adicionados
casos de teste mais adequados, pois cada critério e tipo de teste determinam
como são gerados os casos de teste e indicam coberturas. Quanto mais
próximo da fase de desenvolvimento , mais casos de teste podem ser
adicionados para cobrir os critérios selecionados. Devem ser especificados os
critérios de satisfação para cada tipo de teste (critérios de cobertura) quando
não estiverem implícitos.
3.5.3.5 TABELA GERAL DOS RISCOS DA FASE DE PROJETOS
Na Tabela 12, a seguir, são apresentados os riscos da fase de Projetos,
agrupados por atividade.
TABELA 12 - TABELA GERAL DOS RISCOS DA FASE DE PROJETOS
60
Atividade Risco Associado Classe Especificação Técnica
• Cronograma mal ou não elaborado • Falta de metodologia e não acompanhamento do cronograma • Definição de infra-estrutura (servidores, estações de trabalho,
impressoras) mal dimensionada ou não considerada no projeto. • Hardware inadequado ao projeto • Especificação de rede ou rede atual incompatível com as
necessidades do sistema • Especificação incompleta ou mal elaborada • Modelagem de dados incompleta ou mal elaborada • Falta de um profissional especifico para banco de dados • Softwares necessários sem licença ou inexistentes • Quantidade de licenças insuficientes
RG RG RT
RT RT
RT RT RL RL RL
Especificação de Programa
• Falta de definição de métricas no estabelecimento de prazo • Cronograma mal ou não elaborado, com prazos inadequados. • Não acompanhamento do cronograma estabelecido • Equipe pouco ou mal qualificada para a criação do documento de
especificação. Criação de especificação dúbia e com falta de detalhamento.
RG RG RG RT
Elaboração de Planos de Testes
• Não determinação dessa fase no projeto • Problemas no produto, causados por erros. • Insatisfação do usuário quando da validação do sistema • Problemas de confiança técnica entre o cliente e a área de
desenvolvimento • Falta de conhecimento dos procedimentos de testes • Planos de teste mal elaborados ou não elaborados • Falta ou pouca documentação • Sistemas sem testes adequados • Testes sem abrangências • Testes de unidades dependentes da experiência do programador • Falta de teste de ambiente, integrado e testes de stress.
RG RG RG RG
RT RT RT RT RT RT RT
Especificação de Casos de Testes
• Falta de definição de métricas para estabelecimento de prazos • Cronograma mal ou não elaborado, com determinação de prazos
inadequados. • Não acompanhamento do cronograma estabelecido • Equipe pouco ou mal qualificada para a criação do documento de
especificação dos casos de teste. Criação de especificação dúbia
RG RG
RG RT
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.4 DESENVOLVIMENTO
Conforme Pressman (2002) e Peters e Pedrycs (2001), a fase desenvolvimento
inclui a codificação e a integração de módulos em um resumo
progressivamente mais completo do sistema final. Desse modo, inclui a
programação e o desenvolvimento top-down .
A programação envolve a escrita de instruções em linguagem de programação
para desenvolver o que o analista de sistemas especificou. Os testes envolvem
a experimentação do sistema para ver se ele produz as saídas corretas e
apresenta o comportamento correto para um grande número de entradas.
61
A fase do desenvolvimento divide-se nas atividades descritas a seguir:
• Desenvolvimento dos programas – programação;
• Testes de Unidade;
• Marcos de acompanhamento do Usuário.
3.5.4.1 DESENVOLVIMENTO DOS PROGRAMAS
Atividade onde as especificações do sistema são transformadas em comandos
de linguagem de programação, ou seja, atividade de codificação. As
especificações de sistemas são subdivididas em especificações de programas
e cada uma é distribuída conforme a qualificação dos profissionais da equipe.
É também nesta atividade onde se monta o help on line do sistema, para poder
ajudar os usuários em seu uso e esclarecer eventuais dúvidas de como utilizar
uma determinada função do sistema.
3.5.4.2 TESTES DE UNIDADE
Os testes de unidade são aplicados para validar os menores elementos
testáveis do software, as classes básicas e os componentes no modelo de
desenvolvimento . Onde se verifica se os fluxos de dados e de controle estão
funcionando como esperados.
Trata-se de uma atividade exercida pelo programador que utiliza a descrição do
projeto e a definição do programa como guia. O principal objetivo é se efetuar
testes nos caminhos de controle para descobrir erros. A complexidade dos
testes e dos erros descobertos é limitada pelo escopo estabelecido para o teste
de programa.
Os testes de unidade podem ser conduzidos em paralelo para diversos
componentes.
3.5.4.3 ACOMPANHAMENTO DO USUÁRIO
62
Onde é efetuada a apresentação parcial do sistema ao usuário. Esta atividade
é executada com o objetivo de se evitar surpresas desnecessárias ao usuário e
antecipar problemas relacionados às funcionalidades mal interpretadas ou
mesmo obter a aprovação do usuário quanto à apresentação (navegação, etc.)
do sistema.
Deve ser planejada e indicada em cronograma.
Esta atividade deverá ser executada por usuário com poder de decisão e pleno
conhecimento das funcionalidades requeridas para o sistema. Deverá ser
acompanhado por um profissional da equipe de desenvolvimento de sistemas
que também possua pleno conhecimento, das funcionalidades que estão sendo
incorporadas, no sistema em desenvolvimento.
3.5.4.4 TABELA GERAL DOS RISCOS DA FASE DE DESENVOLVIMENTO
Na Tabela 13, a seguir, são apresentados os riscos da fase de
desenvolvimento , agrupados por atividade.
TABELA 13 - TABELA GERAL DOS RISCOS DA FASE DE DESENVOLVIMENTO
Atividade Risco Associado Classe Desenvolvimento dos programas – programação
• Pouco acompanhamento das atividades desenvolvidas • Não acompanhamento do cronograma estabelecido • Demissão de profissionais no decorrer do desenvolvimento do
projeto • Não definição de procedimentos para documentação dos fontes. • Não definição de padrão de qualidade para codificação de
programas • Não determinação de inspeções dos códigos produzidos • Falta o controle sobre o gerenciamento de configuração –
versões e locais de desenvolvimento dos programas • Base de dados inexistente ou em construção • Software com pouca qualidade e sem documentação. • Prazos não cumpridos • Equipe pouco ou não qualificada • Recursos insuficientes • Especificação de programa mal elaborada ou inexistente • Pouca ou nenhuma documentação de código fonte • Falta de licenças para os softwares de desenvolvimento • Licenças desatualizadas • Local físico inadequado ou sem nenhuma estrutura para a
equipe de programação. • Equipamentos obsoletos causando demora no desenvolvimento.
RG RG RG
RG RG
RG RG
RT RT RT RT RT RT RT RL RL RO
RO
Tabela 13 - Tabela Geral dos Riscos da Fase de Desenvolvimento – Continuação
63
Atividade Risco Associado Classe Testes Individuais • Não determinação dessa fase no projeto
• Metodologia sem considerar especificação de casos de testes • Procedimentos de testes individuais não especificados • Pouco ou nenhum conhecimento da metodologia de teste
adotada. • Pouco ou nenhum conhecimento sobre testes individuais • Testes individuais mal elaborados • Falta de ou pouca documentação dos planos de teste • Casos de testes mal elaborados não atingindo os objetivos
desejados. • Base de dados, para teste, mal elaborada, não atingindo todas
as situações requeridas.
RG RG RG RT RT RT RT
RT
RT
Marcos de Acompanhamento do Usuário
• Não determinação dessa fase no projeto • Cronograma sem considerar essa atividade • Pouco interesse do usuário na identificação de problemas e
mesmo de erros • Usuário designado para atividade não conhece detalhes do
projeto • Profissional sem dados para a validação com usuário • Testes anteriores mal elaborados causando paradas constantes
e descrédito no usuário
RG RG RO
RO RT RT
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.5 TESTES
Esta atividade tem como objetivo garantir que tanto o processo de
desenvolvimento de software quanto o produto de software atinjam níveis de
qualidade especificados através do uso de metodologias durante as etapas de
desenvolvimento do software e o uso de ferramentas para automatizar os
métodos.
Conforme Pressman (2002) e Peters e Pedrycs (2001), Teste é um conjunto de
atividades que podem ser planejadas antecipadamente e conduzidas
sistematicamente. Para se obter um bom resultado dos testes torna-se
necessário efetuar algumas atividades fundamentais como descrever
detalhadamente os objetivos do teste .
As atividades da fase de Testes apresentadas nesse trabalho são:
• Testes de Integração;
• Testes de Validação / Funcionalidades;
• Testes de Sistemas;
• Avaliação e Liberação ao Usuário;
64
• Ajustes e Acertos Gerais.
3.5.5.1 TESTES DE INTEGRAÇÃO
O objetivo dessa atividade é juntar os programas testados em unidades e
construir teste da estrutura do sistema e descobrir erros relacionados às
interfaces internas e entre sistemas.
Os testes de integração são executados para garantir que os componentes do
modelo de desenvolvimento funcionem apropriadamente quando combinados
para executar.
Abrange as seguintes atividades:
• Componentes de software que foram traduzidos para código são integrados
em um sistema (arquivo de dados, bibliotecas, módulos reusáveis e
componentes);
• Uma série de testes é projetada para expor erros que impeçam o sistema
de desempenhar adequadamente a sua função;
• O sistema é integrado com outros sistemas e o produto inteiro passa pelo
teste.
3.5.5.2 TESTES DE VALIDAÇÃO / FUNCIONALIDADES
Tem inicio no final do teste de Integração.
Uma definição simples para o teste de validação é que a validação se torna
bem-sucedida quando o software funciona de um modo que pode ser
razoavelmente esperado pelo cliente.
É a atividade que permite ao engenheiro de software derivar conjuntos de
condições de entrada que vão exercitar plenamente todos os requisitos
funcionais de um programa.
Atividade onde o Plano de teste será executado para garantir:
• Que todos os requisitos funcionais sejam satisfeitos
65
• As características funcionais sejam satisfeitas
• Os requisitos de desempenho sejam alcançados
• Documentação esteja correta
É a atividade que permite ao cliente validar todos os requisitos solicitados.
3.5.5.3 TESTES DE SISTEMAS
Denota os aspectos de teste para um subsistema da aplicação. É
tradicionalmente feito quando o software está funcionando como um todo. Seu
objetivo é a funcionalidade do sistema final.
Atividade onde os elementos dos sistemas são testados como um todo em uma
série de diferentes testes cuja finalidade principal é exercitar por completo o
sistema.
Tipos de teste de sistema:
Teste de Recuperação - É um teste que força o software a falhar, de diversos
modos e verifica se a recuperação é adequadamente realizada. Normalmente
as seguintes situações são abordadas:
• Falta de energia no ambiente do cliente;
• Falta de energia no servidor;
• Perda da comunicação cliente-servidor;
• Problemas no sistema operacional;
• Problemas de endereçamento de memória.
Ou qualquer outra falha que faça o sistema abortar de forma abrupta sua
execução. Nestes casos, devem ser garantidos as consistências das
informações e o retorno do sistema ao ponto exato em que estava.
Teste de Segurança - Tenta verificar se os mecanismos de proteção
incorporados a um sistema vão de fato protegê-lo de invasão imprópria.
Verifica se os dados e o sistema não serão indevidamente acessados.
66
Teste de estresse - Executa um sistema de um modo que demanda recursos
em quantidade, freqüência ou volumes anormais. Estresse no sistema pode
significar excessiva carga de trabalho, insuficiência de memória e serviços ou
hardware não disponível. Esse teste é freqüentemente realizado para se obter
um melhor entendimento de como está funcionando e que áreas do sistema
não estão funcionando bem. Com isso, os planos de contingência e
manutenção podem ser previstos com antecedência.
Teste de desempenho - É projetado para testar o desempenho do software
durante a execução. Monitora o perfil do tempo, incluindo execução de fluxo,
acesso a dados, funcionalidade e chamadas ao sistema para identificar o
gargalo e processos ineficazes.
3.5.5.4 AVALIAÇÃO E LIBERAÇÃO PARA O USUÁRIO
Teste realizado pelo cliente. Esse teste tem por objetivo a aceitação ou não do
sistema por parte do cliente. Depois de realizado com sucesso, o sistema
estará pronto para ser implantado no ambiente de produção.
Após os testes realizados, deverá ser produzido um relatório documentando a
liberação e aprovação do usuário.
3.5.5.5 AJUSTES E ACERTOS GERAIS
Fase de correção e pequenos ajustes nos programas e se necessário em
funcionalidades, identificados na fase de Avaliação e Liberação para o Usuário,
descrita no Item 3.5.5.4 .
Deve ocorrer em paralelo com a avaliação pelo usuário.
67
3.5.5.6 TABELA GERAL DOS RISCOS DA FASE DE TESTES
Na Tabela 14, a seguir, são apresentados os riscos da fase de teste,
agrupados por atividade.
TABELA 14 - TABELA GERAL DOS RISCOS DA FASE DE TESTES
Atividade Risco Associado Classe Testes de Integração
• Não determinação dessa fase no projeto • Cronograma sem considerar essa atividade • Não existência de ambiente para simulação de testes
integrados • Pouco ou nenhum conhecimento para criação do ambiente
necessário para testes integrados • Não previsão de hardware e software para a montagem de
ambiente de teste • Erros durante a implantação ou utilização do sistema por
falta de teste integrado
RG RG RT
RT
RO
RF
Inspeções
• Não determinação dessa fase no projeto • Metodologia sem considerar regras e procedimentos e
padrões para a confecção do sistema, banco de dados e programação. Regras, procedimentos e padrões mal elaborados.
• Não determinação de profissional para a elaboração da inspeção.
• Profissional designado para a inspeção com pouca ou nenhuma experiência.
• Inspeções mal elaboradas ou incompletas • Pouco ou nenhum conhecimento ou utilização das regras,
procedimentos e padrões definidos pela metodologia. • Metodologia pouco ou não divulgada.
RG RO
RG
RT
RT RT
RT
Testes de Funcionalidades
• Não determinação dessa fase no projeto • Cronograma sem considerar essa atividade • Falta de plano de teste ou plano de teste desatualizado • Falta da existência de ambiente para teste. • Profissionais com pouco ou nenhum conceito sobre as
funcionalidades do sistema • Plano de testes com pouca ou sem divulgação • Usuários sem disponibilidade para execução dos testes • Pouco interesse do usuário na identificação de problemas
e mesmos erros • Desenvolvedor sem material suficiente para a validação do
usuário • Testes anteriores mal elaborados causando paradas
constantes e descrédito no usuário • Profissionais com pouco ou nenhum conceito sobre testes
funcionais • Base de dados mal elaborada para teste das
funcionalidades • Usuários designados para teste de funcionalidade com
pouca objetividade utilizando tempo excessivo na execução desta atividade.
RG RG RG RG RO
RO RO RO
RT
RT
RT
RT
RT
68
Tabela 14 - Tabela Geral dos Riscos da Fase de Testes – Continuação
Atividade Risco Associado Classe Testes de Sistemas
• Não determinação dessa atividade no projeto • Cronograma sem considerar essa atividade • Falta de plano de teste ou plano de teste desatualizado • Testes efetuados sem a utilização do plano de teste • Profissionais com pouco ou nenhum conceito sobre testes
de sistemas • Base de dados com poucos dados para a elaboração dos
testes de desempenho e stress • Testes de segurança mal elaborados podem causar perda
de dados ou mesmo corrupção dos dados, quando da queda de energia ou mesmo defeitos de equipamentos.
• Testes de segurança mal elaborados podem causar acessos indevidos ao sistema
RG RG RG RG RT
RT
RT
RT
Avaliação e Liberação para o Usuário
• Não determinação dessa atividade no projeto • Usuário não disponível em tempo hábil para efetuar a
avaliação • Pouco interesse do usuário • Usuário designado para atividade não conhece os
detalhes do projeto • A não validação do usuário antes da implantação poderá
gerar duplo trabalho. • Desenvolvedor sem material suficiente para a validação do
usuário
RG RO
RO RO
RF
RT
Ajustes e Acertos Gerais
• Não determinação dessa atividade no projeto • Falta de previsão de horas para execução da atividade • Profissionais designados para essa atividade com baixa
produtividade • Profissionais diferentes dos que desenvolveram o sistema.
RG RG RT
RT
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.6 INSTALAÇÃO E LIBERAÇÃO
Conforme Pressman (2002) e Peters e Pedrycs (2001), as fases Instalação e
Liberação são onde o sistema é instalado nas máquinas de produção
(servidores e usuários) e liberado ao usuário para uso.
As atividades da fase de Instalação e Liberação abordadas nesse trabalho são:
• Instalação nos equipamentos de produção;
• Avaliação final e aceite do produto;
• Finalização dos manuais de usuários e técnicos;
• Treinamento.
69
3.5.6.1 INSTALAÇÃO NOS EQUIPAMENTOS DE PRODUÇÃO
Fase de instalação das ferramentas necessárias para o funcionamento do
sistema e do sistema em si com o banco de dados e produto final. Esta fase é
parecida e utiliza os procedimentos já elaborados para a montagem do
ambiente de testes.
Devem ter sido definidos, no projeto, as necessidades de equipamentos, rede,
softwares e acessórios necessários para a instalação do sistema.
3.5.6.2 AVALIAÇÃO FINAL E ACEITE DO PRODUTO
Fase de aceite final dos usuários responsáveis pelo sistema. É fundamental um
teste final do sistema em seu ambiente de produção. Após o teste deve ser
produzido um documento de aceite onde o cliente assina oficializando a
entrega do sistema com todas as funcionalidades solicitadas.
3.5.6.3 FINALIZAÇÃO DOS MANUAIS DE USUÁRIOS E TÉCNICOS
Fase de verificação e finalização dos manuais de usuários e técnicos. Os
manuais dos usuários serão utilizados para se efetuar os treinamentos. Os
manuais técnicos deverão conter instruções de instalações e dados técnicos do
sistema tais como necessidades para operação, necessidades de hardware e
software.
3.5.6.4 TREINAMENTO
Fase onde os usuários são treinados para utilização do sistema. Nessa etapa o
manual do usuário será utilizado e validado.
3.5.6.5 TABELA GERAL DOS RISCOS DA FASE DE INSTALAÇÃO E LIBERAÇÃO
Na Tabela 15, a seguir, são apresentados os riscos das fases de instalação e
liberação, agrupados por atividades.
70
TABELA 15 - TABELA GERAL DOS RISCOS DA FASE DE INSTALAÇÃO E LIBERAÇÃO
Atividade Risco Associado Classe Instalação nos equipamentos de produção
• Não determinação dessa atividade no projeto • Não acompanhamento do desenvolvimento do projeto. Portanto
não tomou as ações necessárias para suprir as necessidades de hardware e software desta atividade.
• Falta de previsão de horas para execução da atividade • Falta de previsão de valores para atender às necessidades de
hardwares e softwares desta atividade. • Técnico(s) designado(s) para essa atividade com pouco ou
nenhum conhecimento • Não existência total ou parcial dos hardwares e softwares
necessários quando da execução da atividade. • Hardwares inadequados para a instalação do sistema • Pouca ou nenhuma licença dos softwares necessários.
RG RG
RF RF
RT
RT
RT RL
Avaliação final e aceite do produto
• Não determinação dessa atividade no projeto • Questionamentos de diretores e gerentes sobre a finalização do
sistema • Dificuldade de relacionamento com cliente após a instalação
devido a problemas causados no ambiente de produção. • Desligamento da empresa do usuário responsável pelo aceite do
sistema poderá causar duvidas quanto à entrega correta do sistema.
• Ambiente de produção instável causando erros sem conseguir identificar se os erros são do sistema ou de outros serviços do ambiente de produção.
RG RG
RR
RF
RT
Finalização dos manuais de usuários e técnicos
• Não determinação dessa atividade no projeto • Sem previsão de horas para elaboração desta atividade • Sem a documentação necessária o usuário terá dificuldades em
caso de nova instalação. • Desligamento do usuário responsável pelo treinamento de outros
funcionários na empresa do cliente • Profissionais com pouca ou nenhuma experiência em produzir
manual. • Manual sem objetividade e difícil de ser interpretado
RG RG RG
RF
RT
RT
Treinamento
• Não determinação dessa atividade no projeto • A falta de treinamento oficial poderá causar erros de utilização
do sistema causando um stress no relacionamento entre fornecedor e cliente
• Usuários sem informação de utilização do sistema poderão causar danos ou subutilização.
• Profissionais sem ou com pouca experiência em ministrar treinamentos podem não motivar usuários ou mesmo causar problemas quanto ao uso futuro do sistema.
RG RG
RF
RT
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.7 OPERAÇÃO
Conforme Pressman (2002) e Peters e Pedrycs (2001), é a fase onde o sistema
será utilizado e garantido a sua utilização através de controles da infra-
estrutura.
As atividades da fase de Operação abordadas nesse trabalho são:
71
• Atendimento de Help-desk;
• Administração da base de dados;
• Administração dos hardwares e softwares utilizados no uso do sistema.
3.5.7.1 ATENDIMENTO DE HELP DESK
Atividade responsável pelo atendimento de solicitações de usuários em relação
a esclarecimentos de dúvidas de utilização do sistema.
Toda solicitação deverá ser registrada e após o seu atendimento será efetuado
registro com informações do atendimento.
3.5.7.2 ADMINISTRAÇÃO DA BASE DE DADOS
Atividade responsável por manter a base de dados íntegra através de
acompanhamentos de sua evolução. Responsável por cópias de segurança e
recuperação dos dados.
3.5.7.3 ADMINISTRAÇÃO DOS HARDWARES E SOFTWARES UTILIZADOS NO USO DO
SISTEMA.
Atividade responsável por manter, através de monitoramento da rede, o
sistema em funcionamento , os servidores e os equipamentos utilizados pelos
usuários.
Responsável pela segurança dos dados, bem como efetuar os backup´s e
restore´s, das diversas bases de dados existentes, utilizando-se e controlando
periféricos como fitas e outros locais para copia dos dados.
Executa tarefas administrativas relacionadas ao banco de dados, tais como
carregar e transportar bancos de dados, utilizando os utilitários empregados na
realização destas atividades.
3.5.7.4 TABELA GERAL DOS RISCOS DA FASE DE OPERAÇÃO
72
Na Tabela 16, a seguir, são apresentados os riscos da fase de operação,
agrupados por atividade.
TABELA 16 - TABELA GERAL DOS RISCOS DA FASE DE OPERAÇÃO
Atividade Risco Associado Classe Atendimento de Help-desk
• Não determinação dessa atividade no projeto. • Não acompanhamento da execução desta atividade.
Portanto não tomou as ações necessárias para corrigir problemas de utilização ou mesmo a identificação de deficiências na área ou no sistema.
• Falta de previsão de horas para execução da atividade. • Falta de previsão de valores para atender às necessidades
de hardwares e softwares desta atividade. • Técnico(s) designado(s) para essa atividade com pouco ou
nenhum conhecimento. • Não existência total ou parcial dos hardwares e softwares
necessários quando da execução da atividade.
RG RG
RF RF
RT
RT
Administração da base de dados
• Não determinação dessa atividade no projeto. • Não acompanhamento da execução desta atividade.
Portanto não tomou as ações necessárias para corrigir problemas de utilização ou mesmo a identificação de deficiências na área ou no sistema.
• Não definição de procedimentos para execução dessa atividade.
• Falta de previsão de horas para execução da atividade. • Falta de previsão de valores para atender às necessidades
de hardwares e softwares, seja na atualização ou expansão em decorrência do aumento da base de dados.
• Falta de previsão de verbas e horas para controle de atualização de versões de softwares de administração de banco de dados
• Falta de previsão de verbas e horas para controle e backups e restores, unidades de backup, fitas necessárias, etc.
• Técnico(s) designado(s) para essa atividade com pouco ou nenhum conhecimento
RG RG
RG
RF RF
RF
RF
RT
Administração dos hardwares e softwares utilizados no desempenho do sistema
• Não determinação dessa atividade no projeto • Não acompanhamento do desenvolvimento da atividade.
Portanto não tomou as ações necessárias para suprir as necessidades de hardware e software utilizados nesta atividade.
• Falta de previsão de horas para execução da atividade • Falta de previsão de valores para atender às necessidades
de atualizações ou substituições de hardwares e softwares utilitários desta atividade.
• Técnico(s) designado(s) para essa atividade com pouco ou nenhum conhecimento
RG RG
RF RF
RT
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
3.5.8 MANUTENÇÃO
73
Conforme Pressman (2002) e Webster, Oliveira e Anquetil (2005), a
manutenção de software é a atividade durante a qual ocorrem modificações em
um ou mais artefatos resultantes do desenvolvimento de um software (ou de
manutenções anteriores) buscando mantê-lo disponível, corrigir suas falhas,
melhorar seu desempenho e adequá-lo aos requisitos novos ou modificados,
conforme as necessidades de seus usuários, considerando as constantes
evoluções. Novas leis são promulgadas, novas oportunidades de negócio
devem ser desenvolvidas, novas funcionalidades devem ser acrescentadas
para acompanhar a concorrência, etc.
As atividades da fase de Manutenção abordadas nesse trabalho são:
• Processo de manutenção de software;
• Identificação e classificação da necessidade de manutenção;
• Especificação;
• Desenvolvimento da atividade;
• Testes;
• Avaliação e Aceite;
• Documentação;
• Gerenciamento de Configuração;
• Implantação.
3.5.8.1 PROCESSO DE MANUTENÇÃO DE SOFTWARE
Esta atividade envolve o planejamento de atividades, recursos humanos,
ferramentas e hardwares necessários à condução da manutenção de
softwares. É uma atividade em que se definem os procedimentos a serem
adotados para todas as ações na manutenção de software.
3.5.8.2 IDENTIFICAÇÃO E CLASSIFICAÇÃO DA NECESSIDADE DE MANUTENÇÃO
A manutenção de software é bem mais complexa e envolve diversos
procedimentos. Após o recebimento de uma solicitação de manutenção de
software é necessário classificá-la considerando o tipo da atividade. A seguir
descrevem-se quatro tipos.
74
Correção de erros
Durante o uso do sistema podem surgir falhas de desenvolvimento resultantes
de erros não identificados na fase de testes. Estes erros devem ser corrigidos
imediatamente, pois provavelmente impedem a continuidade de utilização do
software. A rapidez da correção do erro indicado é um fator decisivo para
manter a confiança do usuário no sistema e garantir a aceitação do mesmo.
Novas funcionalidades ou funcionalidades não previstas na fase de
desenvolvimento
É uma atividade muito importante porque mantém o software atualizado em
relação às necessidades do usuário e ao crescimento de novos negócios da
empresa. Esta manutenção é identificada durante a utilização do sistema e
quando os usuários possuem a oportunidade de identificar as funções
necessárias relacionadas às atividades do dia a dia. Para esta manutenção, as
fases e atividades do desenvolvimento do software poderão ser utilizadas.
Esta atividade da manutenção praticada com eficiência mantém o software com
aperfeiçoamento e evolução permanente proporcionando aos usuários maior
eficácia no desenvolvimento de suas atividades.
Adaptações
É a atividade que modifica o software em relação às atualizações tecnológicas
e à melhoria de desempenho. Em decorrência das rápidas mudanças
tecnológicas, como o lançamento de novas gerações de hardware e softwares
de desenvolvimento (linguagens e banco de dados), novos
sistemas operacionais e novos equipamentos periféricos, entre outros, torna-se
necessária uma adaptação do sistema para proporcionar ao usuário um melhor
desempenho do sistema e a manutenção dele. Com esta atividade pode-se
prolongar a vida útil do sistema.
Manutenções Legais
75
São as manutenções oriundas de mudanças de leis fiscais, contábeis,
trabalhistas, entre outras. São as modificações para adaptação às novas regras
estabelecidas por leis e normas governamentais.
3.5.8.3 ESPECIFICAÇÃO
A atividade de especificação de uma manutenção segue os mesmos passos
que foram abordados na especificação do desenvolvimento.
Os objetivos são a especificação e documentação das novas funcionalidades
ou da alteração de funcionalidades já existentes bem como a especificação
para a correção de um erro. As informações para as especificações são obtidas
através de levantamentos e testes de identificação de erros no próprio
software. As especificações serão produzidas através da escrita, de
representações simbólicas ou gráficas e se for necessária, também será
desenvolvida a atividade de prototipagem. A especificação dos programas
para efetuar correções nos programas já existentes ou programas novos e
ajustes na base de dados também fazem parte do escopo desta atividade.
3.5.8.4 DESENVOLVIMENTO DAS ATIVIDADES
Nesta atividade serão desenvolvidas as ações necessárias para correção de
erro ou desenvolvimento de melhorias e novas necessidades, conforme
definições na atividade Especificação, Correções ou Inclusões de
funcionalidades em programas existentes, Criação de novos programas e
Ajustes na base de dados.
3.5.8.5 TESTES
Um plano de teste deverá ser produzido para testes desta atividade. Testes de
unidades e de sistemas deverão ser elaborados da mesma forma como foram
definidos nas fases de desenvolvimento de software.
Serão elaborados testes de validação em ambiente de teste e de homologação.
76
3.5.8.6 AVALIAÇÃO E ACEITE
A avaliação e o aceite são determinados pelo usuário, após a realização de
testes. Se o usuário indicar o sucesso dos testes, uma nova versão do sistema
deverá ser produzida e então estará pronta para ser implantada no ambiente
de produção.
3.5.8.7 DOCUMENTAÇÃO
A documentação para a fase Manutenção deverá abranger todos os pontos
onde foram necessárias ações, tais como telas, bancos de dados, relatórios,
consultas, novos cálculos ou nova fórmula de efetuar um cálculo. A
documentação desenvolvida durante o desenvolvimento do software deverá ser
acrescida da documentação da manutenção, ficando assim um histórico dos
processos de manutenção realizados.
Deve-se criar, para cada nova versão gerada, um documento com as
manutenções realizadas.
3.5.8.8 GERENCIAMENTO DE CONFIGURAÇÃO
Identificação e controle dos itens do software. Isso Inclui controle de
armazenamento, liberações, manipulação, distribuição e modificação de cada
um dos itens que compõem o software.
Gerenciamento de Configuração é a atividade que gerencia e controla a
evolução de um software através, basicamente, de controle formal de versão e
solicitação de mudanças. Esta atividade permite que a equipe de gerentes,
analistas, programadores, testadores e usuários entendam o sistema não
apenas em seu estado atual, mas também em seus estados anteriores e,
devido às mudanças em curso, em um estado futuro.
Inicialmente, deve-se elaborar o Plano de Gerência de Configuração. O
ambiente de projeto definido no Plano de Gerência de Configuração é então
77
criado em um repositório. Após estas atividades, pode-se, portanto,
acompanhar as manutenções do sistema.
3.5.8.9 IMPLANTAÇÃO
Atividade onde uma nova versão deverá substituir a versão atual. Nesta
atividade um plano de substituição deverá ser elaborado de forma a não
produzir impacto quanto à utilização do sistema. O plano deverá indicar qual o
melhor dia e hora para a substituição. Um backup da situação atual deverá ser
produzido como contingência.
3.5.8.10 TABELA GERAL DOS RISCOS DA FASE DE MANUTENÇÃO
Na Tabela 17, a seguir, são apresentados os riscos da fase de manutenção,
agrupados por atividade.
TABELA 17 - TABELA GERAL DOS RISCOS DA FASE DE MANUTENÇÃO.
Atividade Risco Associado Classe Processo de Manutenção de software
• Falta da previsão desta atividade. • Modelos, processos, padrões, métodos, métricas e
ferramentas de apoio inexistentes ou inadequadas para o processo de manutenção de software.
• Inexistência de suporte para reengenharia do software • Grandes mudanças de softwares de apoio. • Grandes mudanças de hardware. • Sistemas muito antigos e desatualizados. • Softwares não atendendo às expectativas do usuário. • Não conhecimento ou inexistência de padrões e
documentação dos softwares a serem mantidos. • Falta de planejamento do processo de manutenção. • Falta de previsão de custos para manutenção de software.
RG RG
RG RT RT RO RO RG
RG RF
Identificação e classificação da necessidade de manutenção
• Falta de metodologia para registro e classificação das solicitações de manutenção.
• Falta de registro e controle das manutenções solicitadas como processo de geração de históricos para novos sistemas.
RG
RG
Especificação
• Novas funcionalidades incompletas ou mal elaboradas. • Novas funcionalidades mal entendidas. • Pouco conhecimento do sistema a ser mantido. • Alto nível de complexidade da funcionalidade a ser
mantida. • Dificuldade na identificação do erro relatado. • Pouca informação sobre novas leis. • Impacto em outros sistemas ou módulos.
RT RO RG RF
RT RT RO
78
Tabela 17 - Tabela Geral dos Riscos da Fase de Manutenção – Continuação.
Atividade Risco Associado Classe Desenvolvimento da atividade
• Hardware utilizado com pouca confiabilidade. • Desenvolvimento da funcionalidade solicitada fora dos
padrões estabelecidos e já utilizados no desenvolvimento do software.
• Código do programa a ser mantido complexo e desestruturado.
• Estrutura corrompida do software a ser mantido. • Profissional com pouco ou nenhum conhecimento do
sistema.
RO RG
RT
RT RT
Testes
• Falta de plano de testes. • Tempo insuficiente para elaboração de testes
abrangentes. • Dados insuficientes e imprecisos. • Situação real não atende às necessidades das novas
funcionalidades durante a elaboração dos testes. • Alto custo para efetuar testes.
RG RO
RG RL
RF
Documentação
• Falta de previsão de horas para execução da atividade. • Pouca ou nenhuma documentação oriunda do
desenvolvimento do software. • Documentação da manutenção sem integração com a
manutenção do desenvolvimento do software. • Não identificação das manutenções relacionadas com a
versão produzida.
RG RO
RG
RG
Avaliação e Aceite
• Não determinação dessa atividade. • Desligamento da empresa do usuário responsável pela
aceitação da manutenção do sistema. • Avaliação considerando somente as manutenções
efetuadas. • Ambiente de produção instável causando erros sem
conseguir identificar se os erros são do sistema ou de outros serviços do ambiente de produção.
• Pouca disponibilidade para a avaliação dos profissionais envolvidos no processo de manutenção.
• Não estabelecimento do aceite formal da manutenção.
RG RO
RT
RT
RG
RG Gerenciamento de Configuração
• Não determinação dessa atividade no projeto. • Sem previsão de horas para elaboração desta atividade. • Falta da elaboração do plano de gerenciamento de
configuração. • Inexistência de controle de versão. • Perda de versão. • Inexistência de ferramenta de suporte para o controle de
versões dos programas e documentos do software. • Falta de treinamento dos profissionais de manutenção em
relação ao plano de gerenciamento de configuração e a ferramenta de controle de versões.
RG RG RG
RG RG RO
RG
Implantação
• Não determinação dessa atividade no projeto. • Conflitos com sistemas já existentes. • Falta de plano de implantação poderá causar problemas
de utilização do sistema. • Falta de backup de contingência poderá causar problemas
se houver necessidade de retornar à versão anterior.
RG RO RG
RG
Classes de Risco: RO: Risco Organizacional; RR: Risco de Relacionamento; RT: Risco Técnico; RG: Risco de Gerenciamento; RF: Risco Financeiro; RL: Riscos Legais.
79
CAPÍTULO 4
FERRAMENTA DE GERENCIAMENTO DE RISCO
4.1 OBJETIVO
A Ferramenta de Gerenciamento de Risco (Grik-Tool) tem dois objetivos: O
primeiro objetivo é a criação de uma base de conhecimento com informações
obtidas no modelo (GRisk-Model) e que será utilizada como roteiro nos
gerenciamentos de riscos de projetos futuros. O segundo objetivo é o registro,
acompanhamento e controle de ocorrências de riscos identificados ao longo do
desenvolvimento de novos projetos. Com este registro, objetiva-se atualizar a
base de conhecimento e gerar informações para se definir métricas de
impactos significativos para os principais riscos relatados.
Procurou-se desenvolver uma ferramenta flexível e configurável, procurando
atender às diversas situações e necessidades de seus usuários.
A ferramenta, apresentada a seguir, baseia-se no ciclo de vida em cascata,
entretanto seu desenvolvimento foi realizado de forma a atender quaisquer
paradigmas, já que as fases e atividades são cadastráveis.
4.2 DESCRIÇÃO GERAL
A ferramenta está estruturada nos seguintes módulos: Criação da Base de
Conhecimento, Controle de Gerenciamento de Riscos, Acompanhamento e
Controle dos Riscos, Manutenção da Base de Conhecimento, Relatórios e
Consultas. Na Figura 8 são apresentados os módulos com seus
relacionamentos.
80
FIGURA 8 – VISÃO GERAL DA FERRAMENTA GRISK
Os módulos da ferramenta, apresentados na Figura 8 são explanados a seguir.
Criação da Base de Conhecimento. Neste módulo, são cadastradas as
informações geradas pela estrutura do modelo, dividas por fase e atividades do
processo de desenvolvimento de software. É composto pelos seguintes
submódulos:
• Cadastramentos básicos. Este submódulo disponibiliza o cadastramento
das informações das fases, atividades, classes, riscos;
• Criação da Base de Conhecimento de Risco. Neste submódulo o usuário
efetuará a criação da base de conhecimento relacionando os cadastros
básicos, ou seja, efetua-se o relacionamento de fase, atividade, classe de
Acompanhamento dos Riscos
Criação da Base de Conhecimento
Formulários Orientações
Projetos
Manutenção da Base de
Conhecimento
Clientes
Controle do Gerenciamento do Risco
Follow-up
Ocorrência de Riscos
Relatórios e Consultas
Base de Conhecimento
81
risco, risco, e seu controle, sugerido como roteiro para os próximos
gerenciamentos de riscos;
• Consulta à Estrutura de Risco. Este módulo disponibiliza consultas da
base de conhecimento criada.
Controle do Gerenciamento de Risco. Neste módulo, são registradas as
informações de ocorrências de risco identificadas nos processos de
desenvolvimento de software. É composto pelos seguintes submódulos:
• Cadastramentos básicos. Este submódulo disponibiliza o cadastramento
das informações de clientes, projetos, equipe do projeto, probabilidade,
freqüência e impacto do risco;
• Registro de Ocorrência de Risco. Neste submódulo o usuário efetuará o
registro da ocorrência de risco, por cliente, projeto, fase, atividade, classe
de risco e risco. Determinará o controle do risco identificado, com indicação
de seu impacto dentro do sistema;
• Consulta à Ocorrência de Risco. Este submódulo disponibiliza consultas
dos registros sobre as ocorrências de riscos identificadas, através de
seleções por cliente, por projeto ou fase.
Manutenção da Base de Conhecimento. Neste módulo, é atualizada a base
de conhecimento através do registro de ocorrências de riscos. Se o risco
registrado não existir na base de conhecimento, esse é agrupado com as
informações da base de conhecimento.
Acompanhamento dos Riscos. Este módulo disponibiliza ao usuário o
registro dos acompanhamentos realizados para uma determinada ocorrência
de risco. Para cada acompanhamento de ocorrência de risco realizada pode-se
efetuar o registro com indicação de data, formulário e responsável.
Relatórios e Consultas. Este módulo disponibiliza ao usuário diversos
relatórios e consultas, podendo servir para a base de conhecimento,
gerenciamento de risco e acompanhamento de ocorrências de risco.
82
4.3 FUNCIONALIDADES DA FERRAMENTA
Após estudos através de pesquisa bibliográfica, apresentada no Capítulo 2, da
avaliação de ferramentas de risco existentes e de reuniões com profissionais
da área, incluindo gerentes, coordenadores de fábrica de software e analistas
seniores, concluiu-se que a ferramenta dará suporte às realizações das
atividades descritas a seguir.
4.3.1 EFETUAR CONTROLE DE ACESSO
A função controle de acesso determinará as autorizações de utilização do
sistema, quais usuários poderão consultar as informações e quais usuários
terão acesso ao cadastramento das informações.
A função trata dois tipos de usuários, conforme descrito a seguir.
• Usuários que acessam e manuseiam todas as informações;
• Usuários só para consultas as informações.
4.3.2 CADASTRAMENTO DAS INFORMAÇÕES BÁSICAS
Esta funcionalidade é a responsável pelo cadastramento das informações
necessárias para a execução da ferramenta, a seguir apresentam-se os
cadastros que compõem esta funcionalidade.
Cadastros básicos que formam a estrutura da base de conhecimento.
• Cadastros de Usuários;
• Cadastro de Fases do Ciclo de Vida de Desenvolvimento de software;
• Cadastro das Atividades das Fases;
• Cadastro das Classes de Risco;
• Cadastro dos Riscos;
• Cadastros dos Modelos de Formulários de Riscos.
Cadastros básicos que formam a estrutura da avaliação de riscos.
83
• Cadastros de Probabilidades de ocorrência do risco;
• Cadastros da Freqüência com que pode ocorrer o risco;
• Cadastro do Impacto que o risco causará no sistema.
4.3.3 BASE DE CONHECIMENTO
É a funcionalidade responsável pela criação das informações que compõem a
base de conhecimento.
Nesta funcionalidade são cadastradas as informações sobre riscos,
apresentadas no Capítulo 3, criando-se assim uma base de conhecimento que
define riscos no processo de desenvolvimento de software.
4.3.3.1 CRIAÇÃO DA BASE DE CONHECIMENTO
É a funcionalidade que efetua o agrupamento das informações: fase, atividade,
classe de risco, risco e controle do risco. Indica o modelo de formulário
apropriado para o gerenciamento de risco no processo de desenvolvimento de
software. Para cada fase, associam-se as atividades correspondentes. Para o
conjunto fase e atividade atribuem riscos agrupados por classes.
4.3.3.2 CONSULTA À BASE DE CONHECIMENTO
A consulta à base de conhecimento é uma função que oferece ao usuário
informações de riscos e seus controles para as diversas fases e atividades
definidas na base de conhecimento. Essas consultas podem ser efetuadas por
fase, por atividade e por classe de risco.
4.3.3.3 MODELOS DE FORMULÁRIOS
Para as fases do processo de desenvolvimento de software foram definidos
modelos de formulários para o gerenciamento de risco. Esta funcionalidade
disponibiliza ao usuário o cadastramento do endereço onde estão os modelos
destes formulários.
84
4.3.4 GERENCIAMENTO DE RISCO
É a Funcionalidade onde se registram as atividades efetuadas no
gerenciamento de risco efetuadas nos sistemas em desenvolvimento .
Quando um novo desenvolvimento de sistema se inicia, inicia-se também o
gerenciamento de risco. Após cadastrar o novo sistema com informações de
cliente e equipe de trabalho inicia-se a identificação dos riscos. Neste processo
os modelos de formulários são utilizados e reuniões são elaboradas obtendo-se
uma relação de riscos. Estes riscos são cadastrados divididos nas cada fase e
atividade do processo de desenvolvimento de software.
Para o registro, algumas informações deverão ser cadastradas
antecipadamente, como por exemplo: cliente, projeto, equipe do projeto, etc.
4.3.4.1 CADASTRAMENTO DA OCORRÊNCIA DE RISCO
É a funcionalidade onde são registrados, separados por projetos, os riscos
identificados e analisados.
Para os riscos registrados cálculos são efetuados para determinação dos
impactos. O cálculo é baseado na probabilidade de ocorrência e na freqüência.
4.3.4.2 ACOMPANHAMENTO DE RISCO NOS PROJETOS
É a funcionalidade que permite o registro da atividade de acompanhamento
dos riscos.
4.3.4.3 CADASTROS BÁSICOS QUE FORMAM A ESTRUTURA PARA REGISTROS DAS
OCORRÊNCIAS DE RISCOS
É a funcionalidade responsável pela criação das informações que compõe o
gerenciamento de risco.
85
Nesta funcionalidade são cadastradas as informações sobre clientes,
profissionais que atuam em projetos e demais informações conforme
apresentado a seguir.
• Cadastro de Clientes: Contém informações dos clientes que solicitam
propostas ou projetos;
• Cadastro de Contatos no Cliente: Contém informações dos contatos, ou
usuários do cliente;
• Cadastro de Projetos: Contém informações do projeto do sistema de
software e da proposta que o originou;
• Cadastro de Profissionais: Descreve os profissionais que atuam no
desenvolvimento de sistemas de software.
4.3.4.4 CONSULTAS
É a funcionalidade que disponibiliza consultas sobre as ocorrências de risco
registrado, por projeto, por equipe de desenvolvimento, por exposição de risco
e por probabilidade.
4.4 DIAGRAMA DE FLUXO DE DADOS DA FERRAMENTA
Para representar graficamente um sistema de informação, podemos utilizar
diagramas, tal como o DFD (Diagrama de Fluxo de Dados).
Conforme Pressman (2002), o diagrama DFD utiliza símbolos gráficos para
representar o mundo real. O mundo real, no caso de sistemas de informação,
são os componentes e podem ser: entidades/agentes externos ao sistema,
processos (tarefas ou atividades do sistema) do sistema, repositórios ou
depósitos (de informações ou materiais) e fluxos de materiais ou de
informações.
4.4.1 DFD – ANÁLISE GLOBAL
86
O DFD – Diagrama de Fluxo de Dados, apresentado pela Figura 9 representa o
funcionamento global da ferramenta.
FIGURA 9 - DFD NÍVEL 0.
A seguir descrevem-se as funções indicadas na Figura 9.
Alimenta a Base de Conhecimento: Esta função tem o objetivo de criar todas
as informações que compõem a base de conhecimento. Ela apresenta, nas
fases e atividades, os possíveis riscos e sugestões de controle.
Consulta à Base de Conhecimento: Esta função disponibiliza acesso à base
de conhecimento, previamente cadastrada, embasando os profissionais
desenvolvedores de software a efetuarem planejamentos de controles de risco,
e também auxiliar em processo de desenvolvimento de software com
informações dos prováveis riscos das diversas fases de desenvolvimento.
Registra a Ocorrência de Risco: Esta função registra o gerenciamento de
risco efetuado aos projetos em desenvolvimento. O usuário poderá efetuar
registros dos riscos nas fases e atividades de desenvolvimento de software,
bem como alimentar a base de conhecimento com novos controles e riscos
identificados.
Consulta a Base de
Conhecimento
Base de Conhecimento de Risco
Ocorrência de Riscos
Registra Ocorrência de
Risco
Riscos por fase de projeto de software, controles e formulários.
Riscos por fase de projeto de software, controles e formulários.
Riscos por fase de projeto de software, controles e formulários.
Riscos por fase de projeto de software, controles e formulários.
Usuário
Alimenta a Base de
Conhecimento
87
4.4.2 DFD – NÍVEL 1
4.4.2.1 BASE DE CONHECIMENTO
Na Figura 10, esta representado, o funcionamento da funcionalidade base de
conhecimento.
FIGURA 10 – BASE DE CONHECIMENTO
Este DFD representa a função:
Gera Base de Conhecimento. Com base nas informações das fases e
atividades do ciclo de vida, das classes de riscos e riscos já cadastrados, a
função Gera Base de Conhecimento gera a Base de Conhecimento. As
informações contidas na base de conhecimento serão utilizadas como base
para futuros gerenciamentos de riscos em projetos em desenvolvimento.
Fases do Ciclo de Vida
Usuário
Atividades
Classe de Risco
Riscos
Modelos de Formulários
Base de Conhecimento
Consulta
Código Descrição Status
Código da Atividade Código Fase Descrição Status
Código Risco Código Classe Risco Descrição Definição Status
Código Modelo Status
Código Descrição Status
Fase Etapa Classe de Risco Risco Controle Formulário Status
Gera Base Conhecimento
88
4.4.2.2 OCORRÊNCIA DE RISCO
O DFD apresentado pela Figura 11 representa o modelo de função da
ocorrência de risco da ferramenta.
FIGURA 11 – OCORRÊNCIA DE RISCO
Este DFD representa duas funções:
Gera Ocorrência de Risco. Esta função representa a criação da tabela de
projetos, de clientes e seus contatos. Representa também o cadastramento das
ocorrências de riscos identificadas durante o processo de desenvolvimento de
software.
Efetua Follow-up. Esta função representa o registro do acompanhamento dos
riscos identificados.
Projetos
Usuário
Clientes
Contatos Clientes
Probabilidade
Follow-up Ocorrência de Risco
Código Projeto Código Proposta Descrição Data de Início e Fim Gerente Comercial, de Fábrica, Status
Código, nome, endereço, bairro, cidade, estado, cep, país. cod. postal CNPJ Status
Código Risco Código Classe Risco Cód. Probabilidade Valor da Freqüência Probabilidade de Ocorrência Status
Código do Cliente Código do Contato Nome Telefones Status
Projeto Fase, etapa Classe de Risco, risco Código da Ocorrência Controle Exposição Risco Responsável Influência no Projeto Status
Efetua Follow-up Código ocorrência
Código Follow-up Descrição Responsável Status
Gera Ocorrência de Risco
89
4.4.2.3 ALIMENTA BASE DE CONHECIMENTO
O DFD apresentado pela Figura 12 representa o modelo que armazena
informações da ocorrência de risco para a base de conhecimento.
FIGURA 12 – ALIMENTA BASE DE CONHECIMENTO
Este DFD representa a função:
Alimenta Base de Conhecimento. Esta função representa a manutenção da
base de conhecimento. Ocorre durante o desenvolvimento de novos projetos,
quando riscos novos são identificados.
Alimenta Base de Conhecimento
Usuário
Projeto Fase, etapa, Classe de Risco, risco, Código Ocorrência Controle Exposição Risco Responsável Influência no Projeto Status
Base de Conhecimento.
Fase Etapa Classe de Risco Risco Controle Formulário Status
Ocorrências de Risco.
90
4.5 MODELO DE DADOS
Na Figura 13 esta representado o modelo de dados da ferramenta GRisk-Tool.
Figura 6 – Modelo de Dados
3.1.1 TABELAS
3.2
FIGURA 13 – MODELO DE DADOS DA FERRAMENTA
O modelo de dados da Ferramenta GRisk_Tool foi projetado para proporcionar
flexibilidade de uso aos seus usuários. As informações do ciclo de vida adotado
serão cadastradas nas tabelas fases e atividades. As classes de riscos podem
ser ampliadas ou totalmente remodeladas, conforme a necessidade do usuário.
Os riscos serão individualmente informados à ferramenta, através da tabela de
riscos, podendo proporcionar aos usuários flexibilidade em sua definição e
posterior utilização. Este conjunto de informações representa a base do
sistema. Com este conjunto de informações produz-se a base de
conhecimento.
Para os projetos em desenvolvimento, o modelo proporciona ao usuário efetuar
o registro de riscos identificados e analisados em seu processo de
gerenciamento de risco. Para isto oferece tabelas onde serão armazenadas
91
informações do projeto, tais como, cliente e profissionais. Os riscos serão
registrados e acompanhados utilizando-se da tabela com as informações de
gerenciamento de risco e de registro dos acompanhamentos e monitoramentos
dos riscos identificados.
4.6 PROTOTIPAGEM
A seguir apresentam-se os modelos das telas que representam os módulos da
ferramenta.
Tela Abertura do Sistema
Na Tela Abertura do Sistema, representada pela Figura 14, é efetuada a ação
de início de utilização da ferramenta. Para se ter acesso ao sistema o usuário
deverá preencher seu nome e sua senha. Em seguida optar pelo botão de
login.
FIGURA 14 – TELA DE ABERTURA DO SISTEMA
A Figura 14 representa a tela que atende aos requisitos de Controle de Acesso
e apresenta as funções de acesso ao sistema.
92
Usuário: local onde se informa o nome do usuário que deseja acesso ao
sistema. Necessário um cadastro prévio.
Senha: local onde se informa a senha do usuário que deseja acesso ao
sistema. Necessário um cadastro prévio
Tela de Menu Principal
Na Tela de Menu Principal, representada pela Figura 15, tem-se as
funcionalidades da ferramenta , dividida em módulos descritos a seguir:
Função Ajuda. É a função responsável por fornecer as orientações de uso da
ferramenta.
Função Manutenção. É a função responsável pela criação dos cadastros
básicos para os outros módulos da ferramenta.
Módulo Gerenciamento de Risco. É o módulo responsável pelo registro e
acompanhamento do gerenciamento de riscos para os projetos em
desenvolvimento.
Módulo Base de Conhecimento. É o módulo responsável pela criação e
consulta da base de conhecimento de riscos por fase e atividade do ciclo de
vida de sistemas de software.
FIGURA 15 – TELA DE MENU PRINCIPAL
93
A Figura 15 representa a tela que atende aos requisitos de Cadastramento das
informações básicas; Base de Conhecimento; Ocorrência do Risco; Formulário.
Tela de Menu da Opção Manutenção
É o módulo responsável pela criação dos cadastros básicos para os outros
módulos da ferramenta.
Na Figura 16 são apresentadas as opções para cadastramento das fases e das
atividades do ciclo de vida suportado pela ferramenta. É apresentada a opção
para cadastramento de classes de riscos e riscos associados a essas classes.
Os cadastros de probabilidades, freqüências e impactos de riscos são bases
para se determinar quando o risco irá afetar o desenvolvimento do sistema de
software. A opção modelos de formulários indica para o sistema onde estão
armazenados. A opção usuários determina os acessos dentro do sistema.
FIGURA 16 – TELA DE MENU DA OPÇÃO MANUTENÇÃO
A Figura 16 representa a tela que atende aos requisitos de Cadastramento das
informações básicas com as opções:
§ Cadastro de Fase;
§ Cadastro de Atividade;
§ Cadastro de Classes de Riscos;
§ Cadastros de Riscos;
94
§ Cadastro de Probabilidade;
§ Cadastro de Freqüência;
§ Cadastro de Impacto de Risco;
§ Modelo de Formulários;
§ Cadastros de Usuários.
Tela de Cadastro de Usuários
Na Figura 17 é apresentada à opção de cadastro de usuários, que determina
os acessos no sistema. Determina se o usuário poderá efetuar a criação de
cadastros ou se terá somente acesso às informações através das consultas e
relatórios oferecidos.
FIGURA 17 – TELAS DE CADASTRO DE USUÁRIOS
95
A Figura 17 representa a telas que atendem ao requisito de Efetuar Controle de
Acesso.
Tela de Cadastro de Fases
Na Figura 18 é apresentada à opção de cadastro de fases, que apresenta as
fases já cadastradas, com opção de nova inclusão, alteração ou exclusão. Para
se obter acesso ao cadastro das fases posiciona-se o cursor em cima do
campo Descrição.
FIGURA 18 – TELAS DE CADASTRO DE FASES
96
A Figura 18 representa a tela que atende ao requisito de Cadastramento das
informações básicas do cadastro de Fases do ciclo de vida de desenvolvimento
de software.
Tela de Cadastro das Atividades das Fases
Na Figura 19 é apresentada à opção de cadastro das atividades das fases que
apresenta as Fases com as suas respectivas atividades já cadastradas, com
opção de nova inclusão, alteração ou exclusão. Para se obter acesso ao
cadastro das atividades posiciona-se o cursor em cima do campo Descrição
FIGURA 19 – TELAS DE CADASTRO DE ATIVIDADES DAS FASES
97
A Figura 19 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Atividade das Fases.
Tela de Cadastro das Classes de Riscos
Na Figura 20 é apresentada à opção de cadastro das classes de risco que
apresenta as Classes de Riscos e suas descrições já cadastradas, com opção
de nova inclusão, alteração ou exclusão. Para se obter acesso ao cadastro das
Classes de Riscos posiciona-se o cursor em cima do campo Descrição.
FIGURA 20 – TELAS DE CADASTRO DE CLASSES DE RISCOS
A Figura 20 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Classes de Riscos.
98
Tela de Cadastro de Riscos
Na Figura 21 é apresentada à opção de cadastro de risco. O cadastramento
dos riscos apresenta os riscos agrupados por classes de riscos. Cada risco
cadastrado esta associado a uma classe de risco especifica. Apresenta opções
de nova inclusão, alteração ou exclusão de novos riscos. Para se obter acesso
ao cadastro dos Riscos posiciona-se o cursor em cima do campo Descrição.
FIGURA 21 – TELAS DE CADASTRO DE RISCOS
A Figura 21 representa as telas que atendem ao requisito de Cadastramento
das informações básicas do Cadastro de Riscos.
99
Tela de Cadastro de Modelos de Formulários
Na Figura 22 é apresentada à opção de cadastro de modelos de formulários
que apresenta os Modelos de Formulários já cadastrados com seus respectivos
endereços, com opção de nova inclusão, alteração ou exclusão. Para se obter
acesso ao cadastro dos Modelos de Formulários, posiciona-se o cursor em
cima do campo Descrição.
FIGURA 22 – TELAS DE CADASTRO DE MODELOS DE FORMULÁRIOS.
A Figura 22 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Modelos de Formulários.
100
Tela de Cadastro de Probabilidade
Na Figura 23 é apresentada à opção de cadastro de probabilidade que
apresenta as Probabilidades de ocorrência de riscos já cadastrados, com
opção de nova inclusão, alteração ou exclusão. Para se obter acesso ao
cadastro das Probabilidades posiciona-se o cursor em cima do campo
Descrição.
FIGURA 23 – TELA DE CADASTRO DE PROBABILIDADE .
A Figura 23 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Probabilidades.
Tela de Cadastro de Freqüência de Risco
Na Figura 24 é apresentada à opção de cadastro de freqüência de risco que
apresenta as Freqüências de ocorrência de riscos já cadastrados, com opção
de nova inclusão, alteração ou exclusão. Para se obter acesso ao cadastro das
Freqüências posiciona-se o cursor em cima do campo Descrição.
101
FIGURA 24 – TELA DE CADASTRO DE FREQÜÊNCIA.
A Figura 24 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Freqüências.
Tela de Cadastro de Impacto de Risco
Na Figura 25 é apresentada à opção de cadastro de impacto de risco que
apresenta o cadastro dos possíveis Impactos que um risco pode causar, com
opção de nova inclusão, alteração ou exclusão. Para se obter acesso ao
cadastro de Impactos posiciona-se o cursor em cima do campo Descrição.
FIGURA 25 – TELA DE CADASTRO DE IMPACTOS DE RISCOS.
102
A Figura 25 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro básico de Impacto de Risco.
Tela de Menu do Gerenciamento de Risco
Na Figura 26 é apresentada a tela de menu de gerenciamento de risco que
contém os cadastros básicos para registro das ocorrências de riscos do
sistema. O menu apresenta a opção de registro da ocorrência de risco,
cadastramento de cliente, de contatos de clientes, projetos, profissionais e
acompanhamento das ocorrências de riscos, registrando seus controles e
ações.
FIGURA 26 – TELA DE MENU DO GERENCIAMENTO DE RISCOS.
A Figura 26 representa a tela que atende aos requisitos de Gerenciamento de
Risco, Cadastramento da Ocorrência de Risco, Acompanhamento de Risco nos
Projetos, Cadastros de clientes e seus contatos, projetos, profissionais e
Consultas.
Tela de Cadastro de Clientes
Na Figura 27 é apresentada a tela de cadastro de clientes que contém as
informações dos clientes que possuem projetos, com opção de nova inclusão,
alteração ou exclusão. Para se obter acesso ao cadastro de clientes posiciona-
se o cursor em cima do campo Descrição.
103
FIGURA 27 – TELA DE CADASTRO DE CLIENTES.
A Figura 27 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Clientes.
Tela de Cadastro de Contatos de Clientes
Na Figura 28 é apresentada a tela de cadastro de contatos de clientes que
contém as informações das pessoas de contatos nos clientes, com opção de
nova inclusão, alteração ou exclusão. Para se obter acesso ao cadastro de
clientes posiciona-se o cursor em cima do campo Descrição.
FIGURA 28 – TELA DE CADASTRO DE CONTATOS DE CLIENTES.
104
A Figura 28 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Contatos de Clientes. Os contatos dos
clientes serão os profissionais responsáveis por determinados projetos do
cliente.
Tela de Cadastro de Projetos
Na Figura 29 é apresentada a tela de cadastro de projetos que contém as
informações dos projetos, com opção de nova inclusão, alteração ou exclusão.
Para se obter acesso ao cadastro de projetos posiciona-se o cursor em cima do
campo Descrição.
FIGURA 29 – TELA DE CADASTRO DE PROJETOS.
A Figura 29 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Projetos, indicando a qual cliente ele
pertence e qual o profissional de contato no cliente.
Tela de Cadastro de Profissionais
Na Figura 30 é apresentada a tela de cadastro de profissionais que contém as
informações dos recursos da equipe de desenvolvimento do projeto, podendo
também ter recursos do cliente que atuarão no projeto. Apresenta opção de
nova inclusão, alteração ou exclusão. Para se obter acesso ao cadastro de
profissionais posiciona-se o cursor em cima do campo Descrição.
105
FIGURA 30 – TELA DE CADASTRO DE PROFISSIONAIS.
A Figura 30 representa a tela que atende ao requisito de Cadastramento das
informações básicas do Cadastro de Profissionais.
Tela de Base de Conhecimento
Na Figura 31 é apresentada a tela de cadastro da Base de Conhecimento que
contém tela de base de conhecimento e proporciona o agrupamento de
informações das fases, atividades, classe de riscos, riscos e controle do risco
com opção de nova inclusão, alteração ou exclusão. Para se obter acesso às
informações da base de conhecimento posiciona-se o cursor em cima do
campo Descrição.
FIGURA 31 – TELA DE CADASTRO DA BASE DE CONHECIMENTO.
106
A Figura 31 representa a tela que atende ao requisito de Cadastramento das
informações básicas da Base de Conhecimento.
4.7 ESPECIFICAÇÃO TÉCNICA
A ferramenta foi desenvolvida utilizando modelagem estruturada, o modelo de
ciclo de vida em cascata, técnicas de engenharia de requisitos. A linguagem
empregada é JAVA – J2EE 1.4, utilizando servidor web Apache Tomcat 5.5 e o
banco de dados ORACLE 9i. Será executado em ambiente web.
É importante destacar que, no projeto considerado, a elicitação de requisitos foi
realizada com base em entrevistas; a especificação dos requisitos foi elaborada
através de descrições textuais, representações simbólicas e diagramas
gráficos; e a avaliação dos requisitos foi conduzida por meio de confirmação
com usuário das informações obtidas e apresentadas na documentação
efetuada.
Na Figura 32 é esquematizada a execução da GRisk-Tool.
FIGURA 32 – EXECUÇÃO DA FERRAMENTA GRISK
Ocorrência de Risco
Base de Conhecimento de Risco
Atualiza Base de Conhecimento
USUÁRIO
Consulta Base de Conhecimento
Registra Ocorrência
107
4.8 AVALIAÇÃO DA FERRAMENTA
Para se verificar as potencialidades da ferramenta definiu-se uma atividade de
avaliação.
Para esta atividade foi elaborado um formulário de avaliação, conforme
apresentado no Apêndice A.
A metodologia adotada para o processo de avaliação da ferramenta consistiu
em apresentar o formulário ao avaliador, com explicação dos itens a serem
preenchidos e fornecer um equipamento com a ferramenta instalada.
Procurou-se incluir, na avaliação, profissionais que participaram da equipe que
elaborou o modelo GRisk-Model e profissionais que não participaram da
equipe. Os profissionais que não participaram foram selecionados em função
de experiências com gerenciamento de risco e controle de projetos.
Os documentos gerados e uma breve descrição de quatro profissionais que
participaram do processo de avaliação estão apresentados no Apêndice C.
108
CAPÍTULO 5
CONCLUSÃO
Este trabalho apresentou um modelo de processo de gerenciamento de risco
(GRisk-Model) e uma ferramenta (GRisk-Tool). O GRisk-Model foi desenvolvido
com base na literatura da área e a partir da experiência de diretores, gerentes e
analistas de sistemas seniores de fábricas de software brasileiras. A GRisk-
Tool implementa o modelo de gerenciamento de risco e foi avaliada pela
equipe de profissionais envolvidos na definição do modelo.
O modelo apresentado caracteriza-se por incorporar uma base de
conhecimento acerca do processo de desenvolvimento de software, construída
gradativamente a partir dos produtos desenvolvidos no dia-a-dia de uma
empresa de desenvolvimento de software. A Ferramenta GRisk-Tool suporta
este modelo, e também oferece condições para que a base de conhecimento
produzida possa ser atualizada e acrescida com informações de novos
gerenciamentos de riscos em projetos monitorados pela ferramenta.
Como os impactos dos riscos são determinados para cada projeto, espera-se
que com os históricos registrados na ferramenta obtenham-se métricas para
determinação de padrões dos impactos, suprimindo assim a falta de
informação desta funcionalidade da ferramenta e da base de conhecimento
gerada pelo modelo.
Como resultado esperado com o uso da Ferramenta GRisk-Tool pode-se ter,
antecipadamente mapeados, problemas que poderão advir nas etapas de
desenvolvimento do software, seus impactos perante o projeto e seus custos.
O mapeamento destes problemas é possível de ser obtido a partir de um
roteiro de ações a serem tomadas e que contenham um conjunto de
informações sobre diferentes classes de riscos concernentes a todas as etapas
109
e atividades do ciclo de desenvolvimento de software, conforme mostrado no
GRisk-Model.
Espera-se também que a Ferramenta GRisk-Tool seja mais um mecanismo de
controle para auxiliar o desenvolvimento de software no âmbito da empresa.
Por ser uma ferramenta que utiliza uma base de conhecimento, obtida através
das tabelas produzidas pela GRisk-Model, previamente estabelecidas por
profissionais da área. A Ferramenta GRisk-Tool oferece ao gerenciamento de
risco um roteiro e informações de ações a serem tomadas em todas as etapas
de desenvolvimento de software, evitando assim que os profissionais,
responsáveis por esta atividade, necessitem de conhecimentos mais
aprofundados sobre o assunto, sendo esta característica um grande diferencial
perante outras ferramentas de controle de riscos. Com a atualização dinâmica
da base de conhecimento, essa característica torna-se fator imprescindível
para o gerenciamento de risco e o sucesso do projeto em desenvolvimento.
Como os impactos dos riscos são determinados para cada projeto , espera-se
obter, com os históricos registrados na ferramenta, informações para
determinação de padrões realísticos referentes a estes impactos. Com as
informações coletadas deseja-se estabelecer métricas para previsão de
impactos relacionados ao tempo, custos e recursos utilizados nos processos de
desenvolvimento de software.
Tal métrica e padrão serão incorporados gradativamente ao modelo e à
ferramenta, à medida que forem sendo definidos.
Um outro trabalho a ser produzido com as informações coletadas é o
estabelecimento de controles de riscos comuns a projetos de softwares,
produzindo assim mecanismos para que a engenharia de software possa
atender com maior eficiência e eficácia aos riscos do processo de
desenvolvimento de produtos de software e controlá-los.
110
CAPÍTULO 6
REFERÊNCIAS BIBLIOGRÁFICAS
APPENDIX H - V. A. Information Technology Capital Investment Guide, Risk
Analysis (2000) - http://www.va.gov/oirm/ITplanning/
IT_Capital_Investment_Guide.asp. Accessed in Oct/2003.
BERNSTEIN, Larry. Importance of Software Prototyping
http://www.dacs.dtic.mil/awareness/newsletters/technews2-1/prototyping.html.
Accessed in Feb/2005.
BOEHM, Barry W. A Spiral Model of Software Development and
Enhancement. IEEE Computer, Volume 21, Number 5, p. 61-72, May 1988.
BOEHM, Barry W. Tutorial: Software Risk Management, IEEE Computer
Society Press, 1989.
BOEHM, Barry W. Software Risk Management: Principles and Practices. IEEE
Software, Volume 8, Number 1, January 1991, p. 32-41.
BOEHM, Barry W. Project Termination doesn't equal project Failure. IEEE
Computer, Volume 33, Number 9, September 2000, p. 94-96.
CARR, Marvin J; KONDA, Suresh; MONARK, Ira; ULRICH, F. Carol;
WALTER, Clay F. Taxonomy-Based Risk Identification. Pittsburgh, Pa:
Software Engineering Institute, Carnegie Mellon University, Technical Report
CMU/SEI-93-TR-6, 1993.
CAVALCANTI, Marcos; GOMES, Elisabeth. A nova riqueza das organizações:
Os capitais do conhecimento. Revista TN Petróleo. Rio de Janeiro,
COPPE/UFRJ, n. 16. Ano III, 2000.
111
CAMPBELL, Paul D., CAVALIERI, Adriane. Gerenciamento de Projetos. Rio
de Janeiro: Qualitymark, 2003. ISBN: 85-7303-447-5.
CHARETTE, Robert N. Software Engineering Risk Analysis and Management,
New York: McGraw-Hill, 1989.
CHARETTE, Robert N. Large-Scale Project Management is Risk
Management. IEEE Software, Volume 13, Number 4, July 1996, p. 110-117.
GARVEY, Paul R; PHAIR, Douglas J; WILSON, John A. An Information
Architecture for Risk Assessment and Management. IEEE Software, Volume
14, Number 3, May/June 1997, p. 25-34.
GELPERIN, David; HETZEL, Bill. The Growth of Software Testing.
Communications of the ACM, 1988.
IFPUG – International Function Points Users Group – “Counting Practices
Manual – Release 4.1.1, April 2000.
KAROLAK, Dale Walter. Software Engineering Risk Management, Wiley-IEEE
Computer Society Press, 2002.
KLEIN, G. AND JIANG, J.J. Seeking Consonance in Information Systems.
Journal of Systems and Software, Volume 56, Number 2, March 2001, p. 195-
202.
KONTIO, J., BASILI, V. Empirical Evaluation of a Risk Management Method.
SEI Conference on Risk Management, 1997, Atlantic City, NJ.
KONTIO, Jyrki, GETTO, Gerhard, LANDES, Dieter. Experiences in Improving
Risk Management Processes using the Concepts of the RISKIT Method. ACM
International Symposium on Software Engineering - SIGSOFT 98, Florida,
USA, November 1998, p. 163-174.
KONTIO, J. IWSED-95 Web pages, vol. 1995. University of Maryland.
http://www.cs.umd.edu/projects/SoftEng/ESEG/iwsed/iwsed95/. Accessed in
112
May/2004.
LIMA, Paulo Gomes. Tendências Paradigmáticas na Pesquisa Educacional.
Artur Nogueira – São Paulo: Amil Editora, 2003. ISBN 85-903478-1-8.
LYU, Michael R, YU, Jinsong S, KEROMIDAS, Elaine, DALAL, Siddhartha.
ARMOR: Analyzer for Reducing Module Operational Risk. 25th Symposium on
Fault-Tolerant Computing, IEEE Computer Society Press, 1995, p. 137-142.
MATTOS, Geraldo. Dicionário da Língua Portuguesa. São Paulo: FTD, 1996.
ISBN 85-322-1707-9.
MOYNIHAN, Toni. How Experienced Project Manages Assess Risk. IEEE
Software, Volume 14, Number 3, May/June 1997, p. 35-41.
NUSEIBEH, Bashar; EASTERBROOK, Steve. Requirements Engineering: A
Roadmap. Future of Software Engineering , Limerick Ireland, copyright ACM,
2000, p.37-46.
OSTRAND, Thomas J; BALCER, Marc J. The Category-Partition Method for
Specifying and Generating Functional Tests. Communications of the ACM,
1988, n. 6, v. 31.
PADAYACHEE, Keshnee. An Interpretative Study of Software Risk
Management Perspectives. SAICSIT 2002, South Africa, 2002, p. 118-127.
PAUL, Raymond; SHINAGAWA, Y; KHAN, M. F; GHAFOOR, Arif. Object-
Oriented Framework for Metrics Guided Risk Management. In COMPSAC -
20th IEEE Computer Software and Applications Conference, 1996.
PETERS, James F, PEDRYCS, Witold. Software Engineering: An Engineering
Approach. John Wiley and Sons, 2000.
PETERS, James F; PEDRYCS, Witold. Engenharia de Software – Teoria e
Prática. Rio de Janeiro: Campus, 2001. ISBN: 85-352-0746-5. Tradução de
Ana Patrícia de Machado de Pinho Garcia.
113
PMI - Project Management Institute. PMBOK - Um Guia do Conjunto de
Conhecimentos de Gerenciamento de Projetos. Edição 2000. New Square.
PA.: Four Campus Boulevard, 2002, cap. 11, p. 127-146.
PRESSMAN, Roger. Engenharia de Software. 5ª Edição. Rio de Janeiro.
Makron-Hill, 2002.
PRESSMAN, Roger. Software Engineering – A Practitioner's Approach. 4th
ed. McGraw-Hill, New York, 1997.
SHAW, Michael; GENTRY, James. Inductive Learning for Risk Classification.
IEEE Expert, 1990.
SHERER, Susan A. Three Dimensions of Software Risk: Technical,
Organizational, and Environmental. 28th IEEE Hawaii International Conference
on System Sciences - HICSS 95, 1995, p. 369-378.
TIWANA, Amrit, KEIL, Mark. The One-Minute Risk Assessment Tool.
Communications of the ACM, Volume 47, Number 11, November 2004, p. 73-
77.
WALLACE, Linda, KEIL, Mark. Software Project Risks and their Effect on
Outcomes. Communications of the ACM, Volume 47, Number 4, April 2004, p.
68-73.
WEBSTER, Kênia P. B.; OLIVEIRA, Kathia e ANQUETIL, Nicolas. Taxonomia
de Risco para Manutenção de Softwares. IV Simpósio Brasileiro de Qualidade
de Software. 2005.
WILLIANS, Ray C; PANDELLOS, George J; BEHRENS, Sandra G. Software
Risk Evaluation SER Method Description. Pittsburgh, 1999. Technical Report,
version 2.0. CMU/SEI-99-TR-029.
YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus,
1990. Tradução Dalton Conte de Alencar.
114
ZAVE, Pamela. Classification of Research Efforts in Requirements
Engineering. ACM Computing Surveys, 1997. p. 315–321. ISSN: 0360-0300.
115
APÊNDICE A
A. FORMULÁRIOS
Durante as etapas de identificação de riscos dos processos de
desenvolvimento de software, foram desenvolvidos formulários para captação
dos possíveis riscos, identificados em cada fase. A seguir, segue modelo com
informações de cada formulário.
A.1 AVALIAÇÃO DE RISCO – PROPOSTA
A seguir apresenta-se o formulário de avaliação de riscos da fase - Proposta
CÓDIGO TÍTULO 040901 AVALIAÇÃO DE RISCO
FASE - PROPOSTA Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Análise dos custos iniciais de levantamento Avaliação e Definição do escopo Preparação da Proposta Evolução dos Negócios
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade (PR): 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Freqüência 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Impacto (IR) 1 - Muito Baixo 2 - Baixo 3 - Moderado 4-Alto 5 - Muito Alto Exposição de Risco = Probabilidade * Impacto (PR * IR)
ELABORADO POR: APROVADO: VALIDADO:
116
A.2 AVALIAÇÃO DE RISCO – ENGENHARIA DE REQUISITOS
A seguir apresenta-se o formulário de avaliação de riscos da fase – Engenharia
de Requisitos.
CÓDIGO TÍTULO 040902 AVALIAÇÃO DE RISCO
FASE – ENGENHARIA DE REQUISITOS Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Entendimento do Empreendimento do Cliente Extração e análise de requisitos com a técnica de entrevistas Especificação e documentação dos levantamentos Validação do usuário Cálculo de Prazos Prototipagem
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade (PR): 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Freqüência 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Impacto (IR) 1 - Muito Baixo 2 - Baixo 3 - Moderado 4-Alto 5 - Muito Alto Exposição de Risco = Probabilidade * Impacto (PR * IR)
ELABORADO POR: APROVADO: VALIDADO:
117
A.3 AVALIAÇÃO DE RISCO – PROJETOS
A seguir apresenta-se o formulário de avaliação de riscos da fase – Projetos.
CÓDIGO TÍTULO 040903 AVALIAÇÃO DE RISCO
FASE – PROJETOS Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Especificação Técnica Especificação de Programa Elaboração de Planos de Testes Especificação de Casos de Testes
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade (PR): 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Freqüência 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Impacto (IR) 1 - Muito Baixo 2 - Baixo 3 - Moderado 4-Alto 5 - Muito Alto Exposição de Risco = Probabilidade * Impacto (PR * IR)
ELABORADO POR: APROVADO: VALIDADO:
118
A.4 AVALIAÇÃO DE RISCOS – DESENVOLVIMENTO
A seguir apresenta-se o formulário de avaliação de riscos da fase –
Desenvolvimento.
CÓDIGO TÍTULO 040904 AVALIAÇÃO DE RISCO
FASE – DESENVOLVIMENTO Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Desenvolvimento dos programas Testes Individuais Acompanhamento Usuário
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade (PR): 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Freqüência 1 - Muito Baixa 2 - Baixa 3 - Moderada 4-Alta 5 - Muito Alta Impacto (IR) 1 - Muito Baixo 2 - Baixo 3 - Moderado 4-Alto 5 - Muito Alto Exposição de Risco = Probabilidade * Impacto (PR * IR)
ELABORADO POR: APROVADO: VALIDADO:
119
A.5 AVALIAÇÃO DE RISCOS – TESTES
A seguir apresenta-se o formulário de avaliação de riscos da fase – Testes.
CÓDIGO TÍTULO 040905 AVALIAÇÃO DE RISCO
FASE – TESTES Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Testes de Integração Inspeções Testes de Funcionalidades Testes de Sistemas Avaliação e Liberação ao Usuário Ajustes e Acertos Gerais
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade : ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Freqüência ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Impacto ( ) 1-Muito Baixo ( ) 2-Baixo ( ) 3-Moderado ( ) 4-Alto ( ) Muito Alto Exposição de Risco (PR * IR): _______
ELABORADO POR: APROVADO: VALIDADO:
120
A.6 AVALIAÇÃO DE RISCOS – INSTALAÇÃO E LIBERAÇÃO
A seguir apresenta-se o formulário de avaliação de riscos da fase – Instalação
e Liberação.
CÓDIGO TÍTULO 040906 AVALIAÇÃO DE RISCO
FASE – INSTALAÇÃO E LIBERAÇÃO Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Instalação nos Equipamentos de Produção Avaliação Final e Aceite do Produto Finalização dos Manuais de Usuários e Técnicos Treinamento
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade : ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Freqüência ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Impacto ( ) 1-Muito Baixo ( ) 2-Baixo ( ) 3-Moderado ( ) 4-Alto ( ) Muito Alto Exposição de Risco (PR * IR): _______
ELABORADO POR: APROVADO: VALIDADO:
121
A.7 AVALIAÇÃO DE RISCOS – OPERAÇÃO
A seguir apresenta-se o formulário de avaliação de riscos da fase – Operação.
CÓDIGO TÍTULO 040907 AVALIAÇÃO DE RISCO
FASE – OPERAÇÃO Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Atendimento de Help Desk Administração da base de dados Administração dos hardwares e softwares utilizados no uso do sistema
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade : ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Freqüência ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Impacto ( ) 1-Muito Baixo ( ) 2-Baixo ( ) 3-Moderado ( ) 4-Alto ( ) Muito Alto Exposição de Risco (PR * IR): _______
ELABORADO POR: APROVADO: VALIDADO:
122
A.8 AVALIAÇÃO DE RISCOS – MANUTENÇÃO
A seguir apresenta-se o formulário de avaliação de riscos da fase -
Manutenção.
CÓDIGO TÍTULO 040908 AVALIAÇÃO DE RISCO
FASE – MANUTENÇÃO Data: Projeto: Responsável: Atividade Priori
dade Classe de Risco
Risco Exposição do Risco
Controle
Atividades Classe de Riscos
Processo de Manutenção de Software Identificação/Classificação da Necessidade de Manutenção Especificação Desenvolvimento das Atividades Testes Avaliação e Aceite Documentação Gerenciamento de Configuração Implantação
RO: Risco Organizacional RR: Risco de Relacionamento RT: Risco Técnico RG: Risco de Gerenciamento RP: Risco de Planejamento RF: Risco Financeiro RL: Riscos Legais
Probabilidade : ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Freqüência ( ) 1-Muito Baixa ( ) 2-Baixa ( ) 3-Moderada ( ) 4-Alta ( ) Muito Alta Impacto ( ) 1-Muito Baixo ( ) 2-Baixo ( ) 3-Moderado ( ) 4-Alto ( ) Muito Alto Exposição de Risco (PR * IR): _______
ELABORADO POR: APROVADO: VALIDADO:
123
B. AVALIAÇÃO DA FERRAMENTA
Em função da atividade de avaliação da ferramenta GRisk-Tool, criou-se um
formulário, conforme modelo apresentado a seguir, onde os avaliadores
pudessem expor sua opinião de forma direcionada e possibilitando análise dos
principais itens da ferramenta.
B.1 AVALIAÇÃO DA FERRAMENTA - FORMULÁRIO
A seguir apresenta-se o formulário utilizado na avaliação da ferramenta GRisk-
Tool.
CÓDIGO TÍTULO 041001 AVALIAÇÃO DA FERRAMENTA – GRISK-TOOL
Data: Projeto: Avaliador: Funcionalidades:
Facilidade de Uso:
Navegação: Utilidade:
124
C. PROCEDIMENTOS DE INSTALAÇÃO DA FERRAMENTA
A seguir são apresentados os procedimentos para a instalação da ferramenta
GRisk-Tool.
1.1 INSTALAÇÃO DO PORTAL DE GERENCIAMENTO DE RISCO
1.1.1 INSTALE O ORACLE 9I;
1.1.2 EFETUE O LOGON NO SQL PLUS COMO “SCOTT” ;
1.1.3 CRIE UMA INSTÂNCIA COM O STRING DO HOST IGUAL A “RISCO”;
1.1.4 EXECUTE OS SCRIPTS BD.SQL E PARÂMETROS DEFAULT.SQL .
§ BD.sql § Parâmetros Default.sql.
Comandos no sql plus.
@ C:\GerenciaRisco\documentos\scriptsBanco\BD.sql @ C:\GerênciaRisco\documentos\scriptsBanco\ Parâmetros Default.sql
1.1.4.1 BD.SQL - PARA CRIAÇÃO DAS TABELAS E CAMPOS
DROP TABLE Acompanhamento CASCADE CONSTRAINTS; CREATE TABLE Acompanhamento ( acp_codigo NUMBER(3) NOT NULL, ocr_codigo NUMBER(8) NOT NULL, acp_data DATE NOT NULL, acp_descricao VARCHAR2(255) NOT NULL,
125
acp_responsavel VARCHAR2(255) NOT NULL ); ALTER TABLE Acompanhamento ADD ( PRIMARY KEY (acp_codigo) ) ; DROP TABLE Profissionais_projeto CASCADE CONSTRAINTS; CREATE TABLE Profissionais_projeto ( ppj_codigo NUMBER(5) NOT NULL, prf_codigo NUMBER(5) NOT NULL, prj_codigo NUMBER(5) NOT NULL, ppj_status NUMBER(1) NOT NULL ); ALTER TABLE Profissionais_projeto ADD ( PRIMARY KEY (ppj_codigo) ) ; DROP TABLE Formularios_Base CASCADE CONSTRAINTS; CREATE TABLE Formularios_Base ( bac_codigo NUMBER(7) NOT NULL, mdf_codigo NUMBER(3) NOT NULL ); ALTER TABLE Formularios_Base ADD ( PRIMARY KEY (bac_codigo, mdf_codigo) ) ; DROP TABLE Usuario CASCADE CONSTRAINTS; CREATE TABLE Usuario ( usu_codigo NUMBER(5) NOT NULL, usu_nome VARCHAR2(100) NOT NULL, usu_login VARCHAR2(25) NOT NULL, usu_senha VARCHAR2(25) NOT NULL, usu_nivel_acesso VARCHAR2(1) NULL, usu_status VARCHAR2(1) NOT NULL ); ALTER TABLE Usuario ADD ( PRIMARY KEY (usu_codigo) ) ; DROP TABLE Formularios CASCADE CONSTRAINTS; CREATE TABLE Formularios ( fol_codigo NUMBER(3) NOT NULL, ocr_codigo NUMBER(8) NOT NULL, for_nome_arquivo VARCHAR2(255) NOT NULL );
126
ALTER TABLE Formularios ADD ( PRIMARY KEY (fol_codigo, ocr_codigo) ) ; DROP TABLE Modelo_formulario CASCADE CONSTRAINTS; CREATE TABLE Modelo_formulario ( mdf_codigo NUMBER(3) NOT NULL, mdf_nome VARCHAR2(50) NOT NULL, mdf_nome_arquivo VARCHAR2(255) NULL, mdf_descricao VARCHAR2(500) NULL, mdf_status NUMBER(1) NOT NULL ); ALTER TABLE Modelo_formulario ADD ( PRIMARY KEY (mdf_codigo) ) ; DROP TABLE Ocorrencia_de_Risco CASCADE CONSTRAINTS; CREATE TABLE Ocorrencia_de_Risco ( ocr_codigo NUMBER(8) NOT NULL, ocr_descricao VARCHAR2(500) NOT NULL, ocr_controle NUMBER(1) NULL, ris_codigo NUMBER(6) NULL, clr_codigo NUMBER(3) NULL, frq_codigo NUMBER(3) NULL, prj_codigo NUMBER(5) NULL, imp_codigo NUMBER(3) NULL, prb_cod NUMBER(3) NULL, bac_codigo NUMBER(7) NULL, ocr_exposicao_risco NUMBER(1) NULL, ocr_data_registro DATE NOT NULL, ocr_data_fim DATE NOT NULL, fas_codigo NUMBER(1) ocr_status NUMBER(1) NOT NULL, ati_codigo NUMBER(1) NOT NULL ); ALTER TABLE Ocorrencia_de_Risco ADD ( PRIMARY KEY (ocr_codigo) ) ; DROP TABLE Base_de_Conhecimento CASCADE CONSTRAINTS; CREATE TABLE Base_de_Conhecimento ( bac_codigo NUMBER(7) NOT NULL, ati_codigo NUMBER(4) NULL, fas_codigo NUMBER(3) NULL, ris_codigo NUMBER(6) NULL,
127
clr_codigo NUMBER(3) NULL, bac_observacao VARCHAR2(50) NOT NULL, bac_controle VARCHAR2(500) NULL, bac_status NUMBER(1) NOT NULL ); ALTER TABLE Base_de_Conhecimento ADD ( PRIMARY KEY (bac_codigo) ) ; DROP TABLE Atividades CASCADE CONSTRAINTS; CREATE TABLE Atividades ( ati_codigo NUMBER(4) NOT NULL, fas_codigo NUMBER(3) NOT NULL, ati_descricao VARCHAR2(50) NOT NULL, ati_definicao VARCHAR2(500) NULL, ati_status NUMBER(1) NOT NULL ); ALTER TABLE Atividades ADD ( PRIMARY KEY (ati_codigo) ) ; DROP TABLE Fases CASCADE CONSTRAINTS; CREATE TABLE Fases ( fas_codigo NUMBER(3) NOT NULL, fas_descricao VARCHAR2(50) NOT NULL, fas_status NUMBER(1) NOT NULL, fas_definicao VARCHAR2(500) NULL ); ALTER TABLE Fases ADD ( PRIMARY KEY (fas_codigo) ) ; DROP TABLE Risco CASCADE CONSTRAINTS; CREATE TABLE Risco ( ris_codigo NUMBER(6) NOT NULL, clr_codigo NUMBER(3) NOT NULL, ris_descricao VARCHAR2(50) NOT NULL, ris_controle VARCHAR2(500) NULL, ris_status NUMBER(1) NOT NULL ); ALTER TABLE Risco ADD ( PRIMARY KEY (ris_codigo, clr_codigo) ) ; DROP TABLE classe_de_risco CASCADE CONSTRAINTS;
128
CREATE TABLE classe_de_risco ( clr_codigo NUMBER(3) NOT NULL, clr_definicao VARCHAR2(500) NULL, clr_status NUMBER(1) NOT NULL, clr_descricao VARCHAR2(50) NOT NULL ); ALTER TABLE classe_de_risco ADD ( PRIMARY KEY (clr_codigo) ) ; DROP TABLE Projetos CASCADE CONSTRAINTS; CREATE TABLE Projetos ( prj_codigo NUMBER(5) NOT NULL, prj_nome VARCHAR2(50) NOT NULL, prj_data_inicio DATE NULL, prj_data_fim DATE NULL, prj_caminho_proposta VARCHAR(255) NULL, prj_status NUMBER(1) NOT NULL, cli_codigo NUMBER(5) NULL, prj_gerente_comercial VARCHAR2(100) NULL, ccl_codigo NUMBER(5) NULL ); ALTER TABLE Projetos ADD ( PRIMARY KEY (prj_codigo) ) ; DROP TABLE Contatos_Clientes CASCADE CONSTRAINTS; CREATE TABLE Contatos_Clientes ( ccl_codigo NUMBER(5) NOT NULL, cli_codigo NUMBER(5) NOT NULL, ccl_nome VARCHAR2(20) NOT NULL, ccl_email VARCHAR2(50) NULL, ccl_telefone VARCHAR2(15) NULL, ccl_celular VARCHAR2(15) NULL, ccl_status NUMBER(1) NOT NULL ); ALTER TABLE Contatos_Clientes ADD ( PRIMARY KEY (ccl_codigo) ) ; DROP TABLE Clientes CASCADE CONSTRAINTS; CREATE TABLE Clientes ( cli_cnpj VARCHAR2(20) NOT NULL, cli_codigo NUMBER(5) NOT NULL, cli_nome VARCHAR2(50) NOT NULL, cli_endereco VARCHAR2(100) NULL, cli_numero NUMBER(4) NULL,
129
cli_bairro VARCHAR2(40) NULL, cli_cep VARCHAR2(10) NULL, cli_cidade VARCHAR2(50) NULL, cli_estado VARCHAR(2) NULL, cli_pais VARCHAR2(30) NULL, cli_telefone VARCHAR2(15) NULL, cli_posicao_financeira VARCHAR2(50) NULL, cli_status NUMBER(1) NOT NULL ); ALTER TABLE Clientes ADD ( PRIMARY KEY (cli_codigo) ) ; DROP TABLE Profissionais CASCADE CONSTRAINTS; CREATE TABLE Profissionais ( prf_codigo NUMBER(5) NOT NULL, prf_nome VARCHAR2(50) NOT NULL, prf_funcao VARCHAR2(50) NULL, prf_status NUMBER(1) NOT NULL ); ALTER TABLE Profissionais ADD ( PRIMARY KEY (prf_codigo) ) ; DROP TABLE probabilidade CASCADE CONSTRAINTS; CREATE TABLE probabilidade ( prb_codigo NUMBER(3) NOT NULL, prb_descricao VARCHAR2(50) NOT NULL, prb_qtd NUMBER(3) NOT NULL, prb_status NUMBER(1) NOT NULL ); ALTER TABLE probabilidade ADD ( PRIMARY KEY (prb_codigo) ) ; DROP TABLE Frequencia CASCADE CONSTRAINTS; CREATE TABLE Frequencia ( frq_codigo NUMBER(3) NOT NULL, frq_descricao VARCHAR2(50) NOT NULL, frq_qtd NUMBER(3) NOT NULL, frq_status NUMBER(1) NOT NULL ); ALTER TABLE Frequencia ADD ( PRIMARY KEY (frq_codigo) ) ;
130
DROP TABLE impacto CASCADE CONSTRAINTS; CREATE TABLE impacto ( imp_codigo NUMBER(3) NOT NULL, imp_descricao VARCHAR2(50) NOT NULL, imp_qtd NUMBER(3) NOT NULL, imp_status NUMBER(1) NOT NULL ); ALTER TABLE impacto ADD ( PRIMARY KEY (imp_codigo) ) ; DROP TABLE Param_config CASCADE CONSTRAINTS; CREATE TABLE Param_config ( id_param NUMBER(5) NOT NULL, par_nome VARCHAR2(50) NOT NULL, par_descricao VARCHAR2(500) NULL, par_tipo NUMBER(1) NOT NULL, par_valor VARCHAR2(500) NULL ); ALTER TABLE Param_config ADD ( PRIMARY KEY (id_param) ) ; ALTER TABLE Profissionais_projeto ADD ( FOREIGN KEY (prj_codigo) REFERENCES Projetos ) ; ALTER TABLE Profissionais_projeto ADD ( FOREIGN KEY (prf_codigo) REFERENCES Profissionais ) ; ALTER TABLE Formularios_Base ADD ( FOREIGN KEY (mdf_codigo) REFERENCES Modelo_formulario ) ; ALTER TABLE Formularios_Base ADD ( FOREIGN KEY (bac_codigo) REFERENCES Base_de_Conhecimento ) ; ALTER TABLE Formularios ADD ( FOREIGN KEY (fol_codigo, ocr_codigo) REFERENCES Followup ) ; ALTER TABLE Followup ADD ( FOREIGN KEY (ocr_codigo) REFERENCES Ocorrencia_de_Risco ) ;
131
ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (ris_codigo, clr_codigo) REFERENCES Risco ) ; ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (frq_codigo) REFERENCES Frequencia ) ; ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (prj_codigo) REFERENCES Projetos ) ; ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (imp_codigo) REFERENCES impacto ) ; ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (prb_cod) REFERENCES probabilidade ) ; ALTER TABLE Ocorrencia_de_Risco ADD ( FOREIGN KEY (bac_codigo) REFERENCES Base_de_Conhecimento ) ; ALTER TABLE Base_de_Conhecimento ADD ( FOREIGN KEY (fas_codigo) REFERENCES Atividades ) ; ALTER TABLE Base_de_Conhecimento ADD ( FOREIGN KEY (ris_codigo, clr_codigo) REFERENCES Risco ) ; ALTER TABLE Atividades ADD ( FOREIGN KEY (fas_codigo) REFERENCES Fases ) ; ALTER TABLE Risco ADD ( FOREIGN KEY (clr_codigo) REFERENCES classe_de_risco ) ; ALTER TABLE Projetos ADD ( FOREIGN KEY (cli_codigo) REFERENCES Clientes ) ; ALTER TABLE Contatos_Clientes ADD ( FOREIGN KEY (cli_codigo) REFERENCES Clientes ) ;
132
1.1.4.2 PARÂMETROS DEFAULT.SQL PARA INICIALIZAR AS TABELAS:
USUÁRIOS E PERMISSÕES.
/****************************************************************** * * Adicionar aqui todos os parâmetros default do sistema * ******************************************************************/ -- Criação de usuário default insert into usuário(usu_código, usu_nome, usu_login, usu_senha, usu_nível_acesso, usu_status) values(1, 'Administrador do sistema', 'admin', 'admin', 'A', '1') / insert into param_config(id_param, par_nome, par_descrição, par_tipo, par_valor) values(1, 'PATH_MODELO_FORM', 'Caminho dos modelos de formulários', 1, 'C:\sistemas\GerênciaRisco\páginas\GerênciaRisco\arquivos\modeloFormulário\') / insert into param_config(id_param, par_nome, par_descrição, par_tipo, par_valor) values(2, 'URI_MODELO_FORM', 'Endereço para download do modelo de formulário', 1, 'arquivos/modeloFormulário/') / 1.1.5 INSTALE O JSDK 1.5
1.1.6 INSTALE O TOMCAT 5.5
1.1.7 ESCOLHA A PORTA 8081.
133
1.1.8 APONTE PARA O JSDK 1.5.
1.1.9 COPIE A PASTA GERÊNCIA RISCO PARA C:
1.1.10 EDITE O ARQUIVO PARÂM CONEXAO.XML QUE SE ENCONTRA NA
PASTA C:\GERÊNCIARISCO\PÁGINAS\GERÊNCIARISCO,
ESPECIFICANDO USUÁRIO, SENHA, IP DO SERVIDOR DO BANCO,
PORTA E O NOME DA INSTÂNCIA CRIADA
paramConexao.xml <Configurações> <Conexão>
134
<GerênciaRisco usuário="scott" senha="tiger" ip="127.0.0.1" porta="1521" instância="risco"/> </Conexão> </Configurações>
1.1.11 COPIE O ARQUIVO GERÊNCIAR ISCO.XML QUE ESTÁ NA PASTA RAIZ
C:\GERÊNCIARISCO DO PORTAL PARA C:\PROGRAM FILES\APACHE
SOFTWARE FOUNDATION\TOMCAT 5.5\CONF\CATALINA\LOCALHOST
1.1.12 REINICIE O TOMCAT.
1.1.13 ACESSE O PORTAL PELO ENDEREÇO
HTTP://LOCALHOST:8081/GERÊNCIAR ISCO
135
D. AVALIAÇÃO DA FERRAMENTA GRISK_TOOL
D.1 AVALIADORES
AVALIADOR 1
Formação em Gerenciamento de Risco pela The George Washington
University 2002.
AVALIADOR 2
Analista de Sistemas – Verano Engenharia de Sistemas. Atua em Sistemas de
Controle e Gerenciamento de Projetos
AVALIADOR 3
Formado em Administração com ênfase em Análise de Sistemas e pós-
graduado em Análise de Sistemas com ênfase em arquitetura cliente-servidor
pela PUC Campinas e especialista MCP em Microsoft Visual Basic.
Atualmente é professor de Informática Aplicada pela Faculdade Mater Amábilis
e consultor em desenvolvimento de sistemas.
AVALIADOR 4
Formado em Administração. Desde 1990 atua na área de Gerenciamento de
Projetos, com PMBOK.
136
D.2 AVALIAÇÃO DA FERRAMENTA – PARECER 1
CÓDIGO TÍTULO 041001 AVALIAÇÃO DA FERRAMENTA – GRISK-TOOL
Data: 25/10/2005 Projeto: Avaliador: Avaliador 1 Funcionalidades: As funcionalidades da ferramenta de risco contemplam os riscos das grandes
atividades de Gerenciamento de Riscos, conforme os conceitos
apresentados a seguir:
Gerenciamento das Incidências – Muitos problemas aparecem e são
resolvidos rapidamente. Entretanto, uma "incidência" é quando um problema
aparece e impede o progresso do projeto. O gerente do projeto e sua equipe
também não conseguem resolvê-lo sozinhos a não ser com ajuda externa.
Gerenciamento de Incidências é um dos processos mais importantes.
Gerenciamento do Escopo – Escopo é a maneira como se descreve os
limites de cada projeto. O gerente de projetos e seu patrocinador devem
concordar no escopo do projeto antes de começar o próprio projeto. O
propósito do gerenciamento de mudanças do escopo é assegurar que o
patrocinador aprove qualquer mudança feita após a concordância do escopo
inicial.
Gerenciamento da Comunicação – A Comunicação de forma efetiva é um
fator crítico para o sucesso do gerenciamento das expectativas dos clientes e
os Stakeholders.
Gerenciamento da Qualidade – O propósito é primeiramente entender quais
são as expectativas atuais do cliente em termos qualificativos. Coloque estas
expectativas em plano pró-ativo de processos que possam alcançar e
superar estas expectativas.
Gerenciamento das Métricas – Métricas são usadas para coletar dados
quantitativos para auxiliar nas decisões, e também para lhe informar se suas
expectativas estão sendo superadas. Métricas também são guardadas com o
137
tempo para fornecer algumas indicações de tendência que possam impedir
que o projeto tenha o sucesso esperado.
Facilidade de Uso: A Ferramenta possui como característica a facilidade de manipulação das
telas. Devido a sua flexibilidade poderão ser utilizados quaisquer tipos de
paradigmas de desenvolvimento, apesar do cadastro atual se basear no
modelo em cascata.
Navegação: Fácil, os títulos são alto explicativos.
Utilidade: Se a equipe for disciplinada, a ferramenta trará grande benefício ao processo
de gerenciamento de risco de projetos em desenvolvimento.
138
D.3 AVALIAÇÃO DA FERRAMENTA – PARECER 2
CÓDIGO TÍTULO 041001 AVALIAÇÃO DA FERRAMENTA – GRISK-TOOL
Data: 31/12/2005 Projeto: Avaliador: Avaliador 2 Funcionalidades: Manutenção, Gerenciamento de Risco, Base de Conhecimento As funcionalidades possuem tópicos para cadastramento básico, tais como
cadastro de atividades, fases, risco, projetos, clientes e seus contados, os
profissionais, etc. Módulos como: Ocorrência de Risco e Acompanhamento
do risco foram criados para ter um controle maior dos riscos ocorridos em
projeto de engenharia de software. Base de conhecimento mantém a relação
das atividades cadastradas com os riscos e suas respectivas classes. Logo
em um próximo projeto, o padrão de execução definido para aquela atividade
especifica será modificado de acordo com a base de conhecimento a fim de
minimizar o risco para aquela atividade em futuros projetos.
Facilidade de Uso: O portal mostra uma forma de cadastramento simples, com links visíveis a
cada tipo de cadastramento.
Navegação: Inicia-se o portal com um a tela de login que somente validará o usuário e a
senha. Após logado, o portal divide-se em três funcionalidades, onde dentro
de cada uma, seguem-se seus respectivos tópicos, que possuem títulos
coerentes com sua funcionalidade/contexto. Em qualquer tela do portal é
possível estar retornando a tela inicial para escolha de outra funcionalidade.
Utilidade: O portal registra os riscos ocorridos em projetos de engenharia de software
e relaciona-os, em uma base de conhecimento, com uma classe de risco,
fase e atividade, podendo sugerir um controle a esse risco, controlando sua
ocorrência, gerando um acompanhamento.
139
D.4 AVALIAÇÃO DA FERRAMENTA – PARECER 3
CÓDIGO TÍTULO 041001 AVALIAÇÃO DA FERRAMENTA – GRISK-TOOL
Data: 03/11/2005 Projeto: Avaliador: Avaliador 3 Funcionalidades: As funcionalidades oferecidas são suficientes para atenderem os requisitos
básicos de análise de riscos. Oferece maneiras de se realizar desde o
cadastro de projetos a personalização das métricas a serem utilizadas.
Dessa forma, traz uma estrutura flexível o suficiente para se adaptar a vários
ambientes de negócio.
Facilidade de Uso: A operação do software se mostrou simples e bastante intuitiva. É possível
acessar qualquer módulo pelo seu menu inicial. Como foram utilizados um
número reduzido de botões e links a cada um de seus formulários, não traz
nenhum problema a quem estiver operando o software.
Navegação: A navegação se mostrou bastante inteligente e padronizada. A mesma forma
de acesso é utilizada a todos os itens do software, tornando-o conciso e
confiável, alem é claro, da interface limpa e agradável.
Utilidade: A análise de risco é ferramenta fundamental para o gerenciamento de
projetos. Com ele podem-se encontrar os pontos críticos e suscetíveis à
falhas. O software traz uma interface de gerenciamento tecnológica
interessante ao tabular os dados e possibilitar consultas a sua base de
conhecimento.
140
D.5 AVALIAÇÃO DA FERRAMENTA – PARECER 4
CÓDIGO TÍTULO 041001 AVALIAÇÃO DA FERRAMENTA – GRISK-TOOL
Data: 03/11/2005 Projeto: Avaliador: Avaliador 4 Funcionalidades: As funcionalidades atendidas pela ferramenta, suportam uma estrutura
flexível, proporcionando aos usuários, um roteiro para gerenciamento de
risco. Pode-se utilizar qualquer fase e atividade dos diversos paradigmas de
desenvolvimento de software e associar a eles riscos, subdivididos em
classes.
Facilidade de Uso: Fácil entendimento quanto ao uso.
Navegação: Navegação amigável, com boa padronização.
Utilidade: Os benefícios de uma ferramenta estão diretamente relacionados com seu
uso. O uso de qualquer ferramenta deve ser suportado por um
acompanhamento contínuo ate que seus usuários sintam os benefícios. A
utilidade do uso da ferramenta, esta associada às duvidas relacionadas aos
passos e riscos em cada fase do processo de desenvolvimento, pois fornece
relação dos possíveis riscos nas fases e atividades. Outra grande
funcionalidade é o acompanhamento dos riscos dos projetos.
Como sugestão, incluir mais relatórios e meios de consultas.
