departamento de computaÇÃo curso de …pratica é vedada pela lei de direitos autorais nº...
TRANSCRIPT
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA DE SOFTWARE COM UML
“LATO-SENSU”
Marcos Carneiro Andreata
GERENCIAMENTO DE RISCOS DE SOFTWARE COM PMBOK E RUP 7.0
Londrina
2012
MARCOS CARNEIRO ANDREATA
GERENCIAMENTO DE RISCOS DE SOFTWARE COM PMBOK E RUP 7.0
Monografia apresentada à banca examinadora do
Curso de Pós-Graduação em Engenharia de
Software com UML, do Centro Universitário
Filadélfia de Londrina – UniFil, como requisito
parcial para obtenção do grau de Especialista em
Engenharia de Software, sob a orientação do
Professor MSc. Sergio Akio Tanaka.
LONDRINA
2012
MARCOS CARNEIRO ANDREATA
GERENCIAMENTO DE RISCOS DE SOFTWARE COM PMBOK E RUP 7.0
Monografia apresentada à banca examinadora do
Curso de Pós-Graduação em Engenharia de
Software com UML, do Centro Universitário
Filadélfia de Londrina – UniFil, em cumprimento
como requisito parcial para obtenção do título de
Especialista em Engenharia de Software.
APROVADA PELA COMISSÃO EXAMINADORA
EM LONDRINA, 05 DE ABRIL DE 2012
Prof. MSc. Sergio Akio Tanaka (Unifil) - Orientador
Profa. MSc. Simone Sawasaki Tanaka (Unifil) - Examinadora
Londrina, 5 de Abril de 2012.
Ao Aluno Marcos Carneiro Andreata
Prezado(a) Senhor(a):
Tem a presente a finalidade de NOTIFICAR-LHE nos termos do art. 867 e
seguintes do Código de Processo Civil com vistas a prevenir responsabilidades, provendo a
conservação e ressalva de direitos.
A “Unifil” em razão da apresentação recorrente de trabalhos onde se tem
efetuado a cópia de trechos e até capítulos ou trabalhos inteiros, vem notificá-lo que tal
pratica é vedada pela Lei de Direitos Autorais nº 9.610/98 em seus artigos 1º, 5º incisos VI e
X, 7º, 22º, 24º inciso IV, 29º e 41º, cumulados com a nova redação dos artigos 184 e 186 do
Código penal dados pela lei 10.695/2003, que prevê não apenas a proibição de cópia total ou
parcial sem atribuição da devida autoria como inclusive pena de detenção de até quatro anos
mais multa para quem assim proceder.
Assim sendo, considera-se o aluno: Marcos Carneiro Andreata, da Pós-
Graduação em Engenharia de Software com UML, Linha de Formação: Engenharia de
Software, ciente de previsão legal que veda tal prática e se mesmo assim optar por fazê-lo
deverá arcar sozinho com o ônus de tal ato, quer seja ele penal, cível ou administrativo, não
podendo a Instituição de Ensino ser responsabilizada por opção do aluno sem seu
consentimento ou anuência.
Na esfera administrativa desde já ficam, também devidamente notificados,
que os trabalhos copiados na íntegra ou que apresentem cópia parcial, serão sumariamente
reprovados; bem como estarão sujeitos a outras medidas cabíveis. Conforme Regulamento da
instituição no qual relata o seguinte: “Na constatação de procedimentos ilícitos para a
elaboração dos trabalhos de estágio, caracterizando cópias parciais ou integrais (plágio), será
atribuído a média 0,0 (zero) ao aluno no bimestre em curso, não cabendo recurso”.
Sem mais para o momento.
Atenciosamente.
Assinaturas: Prof. Orientador: _______________________________
Aluno:________________________________________
Dedico este trabalho a Deus, que me guia e me
orienta nos caminhos da vida.
AGRADECIMENTOS
Agradeço a Deus pela vida!
Agradeço ao meu orientador, Prof. Msc. Sérgio Akio Tanaka, pelo apoio e pelos
ensinamentos passados que, com certeza, me ajudarão muito profissionalmente.
Agradeço aos professores que ministraram o curso Engenharia de Software com
UML, do Centro Universitário Filadélfia de Londrina – UniFil.
A todos, meus agradecimentos.
“Toda a nossa ciência comparada com a realidade é primária e infantil, e, no entanto,
é a coisa mais preciosa que temos” (ALBERT EINSTEIN).
ANDREATA, Marcos Carneiro. Gerenciamento de Risco de Software com PMBOK e
RUP 7.0. Londrina, 2012. 74f. Monografia (Especialização em Engenharia de Software com
UML) - Centro Universitário Filadélfia de Londrina - UniFil, Londrina, 2012.
RESUMO
O risco em projetos é constante e inevitável, sendo assim, é imprescindível o seu gerenciamento,
visando minimizar e mitigar ao máximo os problemas. Com base nesse reconhecimento, este trabalho busca
apresentar um estudo de caso da identificação, monitoramento e resposta aos riscos, usando técnicas e conceitos
do Project Management Body Of Knowledge (PMBOK) e Rational Unified Process (RUP), também será
utilizado uma ferramenta free para o seu gerenciamento, TRIMS, da Best Manufacturing Practices (BMP) com o
propósito de exemplificar sua aplicabilidade e sua contribuição para a compreensão do que há no mercado em
matéria de controle de gerenciamento de risco.
Palavras-chave: Riscos. PMBOK. Gerência de Projetos. RUP.
ABSTRACT
The risk in projects is constant and inevitable, so their management is essential in order to
minimize and mitigate the most problems. Based on this recognition, thisstudy aims to present a case
study of the identification, monitoring and addressing risks, using techniques and concepts of
the Project Management Body OfKnowledge (PMBOK) and Rational Unified Process (RUP), a tool will
also be usedfor free its management, TRIMS, the Best Manufacturing Practices (BMP) in order to
demonstrate the applicability and its contribution to the understanding of what ison the market in terms
of risk management control.
Key words: RUP; PMBOK; UML.
LISTA DE FIGURAS E TABELAS
FIGURA 1 – TRÍPLICE RESTRIÇÃO......................................................................................3
FIGURA 2 – ARQUITETURA GERAL DO RUP 7.0..............................................................5
FIGURA 3 – FASES E ITERAÇÕES DO RUP.........................................................................6
FIGURA 4 – OS GRUPOS DE PROCESSOS DO GERENCIAMENTO DE PROJETOS....10
FIGURA 5 – ÁREAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS...12
FIGURA 6 – VISÃO DO PROCESSO PLANEJAMENTO DO GERENCIAMENTO DE
RISCOS.....................................................................................................................................13
FIGURA 7 – VISÃO DO PROCESSO IDENTIFICAÇÃO DE RISCOS...............................14
FIGURA 8 – VISÃO DO PROCESSO ANÁLISE QUALITATIVA DE RISCOS.................15
FIGURA 9 – VISÃO DO PROCESSO ANÁLISE QUANTITATIVA DE RISCOS..............16
FIGURA 10 – VISÃO DO PROCESSO PLANEJAMENTO DE RESPOSTAS A RISCOS..17
FIGURA 11 – VISÃO DO PROCESSO MONITORAMENTO E CONTROLE DE
RISCOS.....................................................................................................................................17
FIGURA 12 – ENTRADAS E SAÍDAS DO PLANO DE GERENCIAMENTO DE
RISCOS.....................................................................................................................................19
FIGURA 13 - QUADRO DE SEQUÊNCIA DE PRODUÇÃO POR SEMANA DA
FERRAMENTA SCHEDULER...............................................................................................21
FIGURA 14 - QUADRO DE SEQUÊNCIA DE PRODUÇÃO GERAL DA FERRAMENTA
SCHEDULER...........................................................................................................................22
FIGURA 15 - DIAGRAMA DE ATIVIDADES DO GERENCIAMENTO DE RISCOS
PARA O PROJETO SCHEDULER.........................................................................................23
FIGURA 16 - BASELINING PROJETO SCHEDULER…….……………………………....24
FIGURA 17 - DEFINIÇÃO AS DATAS DE CADA FASE....................................................25
FIGURA 18 - DEFINIÇÃO DE NOMES E FUNÇÕES.........................................................26
FIGURA 19 - MATRIZ DE RISCOS......................................................................................27
FIGURA 20 - RISCOS DO PROCESSO.................................................................................28
FIGURA 21 - DETERMINANDO RESPONSABILIDADES ..............................................29
FIGURA 22 - RESPONDENDO AOS RISCOS .....................................................................30
FIGURA 23 - DEFININDO UM RISCO DE PRODUTO.......................................................31
FIGURA 24 - GRÁFICO DE RESPOSTAS JUNTO ÀS QUESTÕES DE RISCOS DO
PROJETO..................................................................................................................................32
TABELA 1 – AVALIAÇÃO DAS FUNCIONALIDADES DA FERRAMENTA TRIMS X
PMBOK....................................................................................................................................33
LISTA DE ABREVIATURAS E SIGLAS
UML Linguagem de Modelagem Unificada
RUP Rational Unified Process
PMBOK Projeto Management Body Of Knowledge
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 1
2 REVISÃO DA LITERATURA ............................................................................................ 2
2.1 GERÊNCIA DE PROJETOS ............................................................................................ 2
2.2 GERÊNCIA DE RISCOS .................................................................................................. 3
2.3 GERÊNCIA DE PROJETOS UTILIZANDO O RUP .................................................... 5
2.4 GERÊNCIA DE PROJETOS UTILIZANDO O PMBOK ............................................. 8
2.4.1 ESTRUTURA DO PMBOK ........................................................................................... 9
2.4.2 GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS ................ 10
2.4.3 ÁREAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS ........ 11
2.4.4 GERENCIAMENTO DE RISCOS DO PROJETO ................................................... 12
2.4.5 CONSIDERAÇÕES FINAIS ........................................................................................ 18
3 ESTUDO DE CASO .................................................................................................... 19
3.1 A EMPRESA ..................................................................................................................... 19
3.2 PROJETO DE ESTUDO DE CASO ............................................................................... 19
3.3 ESCOPO DO PROJETO ................................................................................................ 19
3.4 O PROJETO ..................................................................................................................... 21
3.4.1 USANDO A FERRAMENTA TRIMS ......................................................................... 22
3.4.2 CONSIDERAÇÕES FINAIS ........................................................................................ 32
4 CONCLUSÕES E TRABALHOS FUTUROS .................................................................. 33
REFERÊNCIAS ..................................................................................................................... 35
APÊNDICES ........................................................................................................................... 36
APÊNDICE A – OUTRAS FERRAMENTAS DE GERENCIAMENTO DE RISCO .... 36
ANEXOS ................................................................................................................................. 37
ANEXO A – TRADUÇÃO QUESTIONÁRIO FERRAMENTA TRIMS ........................ 37
1
1 INTRODUÇÃO
No gerenciamento de um projeto, os riscos são inevitáveis e, conforme a sua
gravidade, a não importância interfere, de forma considerável, no resultado deste. Por isso,
zelar por este aspecto no andamento do projeto faz a diferença.
O gerenciamento de risco é um processo no qual o gerente de projetos e a sua equipe
analisam e classificam os riscos de um projeto determinando quais ações devem ser tomadas
para impedir ou mitigar essas ameaças, que poderiam comprometer o cumprimento dos
objetivos do projeto. Associado a esse processo estão os custos, o tempo e as questões de
qualidade do projeto, provocados pelas soluções para esses riscos.
Abordando o Project Management Body Of Knowledge (PMBOK) e também o
Rational Unified Process (RUP) o estudo apresenta as possíveis alternativas para o
gerenciamento de risco do projeto.
A justificativa para o desenvolvimento deste trabalho é entender e conhecer os
conceitos existentes do PMBOK e RUP no que se diz respeito ao gerenciamento de risco, de
forma a controlar e administrar melhor este ponto, resultando, assim, não só em uma melhor
qualidade e preparo, quando o desvio natural do processo for quebrado por riscos
identificados, mas também em um gerenciamento mais eficaz, quando eles aparecerem.
O principal objetivo deste trabalho é entender o gerenciamento de riscos do projeto
de software no contexto do PMBOK e do RUP usando um estudo de caso e aplicando
algumas ferramentas disponíveis para o gerenciamento de riscos. Alguns dos objetivos
específicos são:
estudar a conceituação e apresentar os pontos de gerenciamento de riscos do PMBOK
e RUP;
demonstrar forma que favoreçam o aprimoramento da identificação dos possíveis
riscos, contribuindo, assim, para a prevenção e classificação destes;
analisar a ferramenta Trims <www.bmpcoe.org>, da Best Manufacturing Practices
(BMP), no que tange ao gerenciamento de riscos;
apresentar um estudo de caso com o intuito de identificar os diversos riscos no
andamento do projeto, de forma a qualificar e responder com as soluções oferecidas
ou, até mesmo, mitigá-los por completo.
2
2 REVISÃO DA LITERATURA
Este capítulo apresenta os principais conceitos utilizados neste trabalho.
2.1 GERÊNCIA DE PROJETOS
O ato de gerenciar projetos é algo que a humanidade executa desde o início de seus
tempos. Podemos constatar essa afirmação na própria história, na organização e objetivo de
construir ou fazer algo, como abrigos, plantações, leis, formas de transportes (VICENTINO,
1997).
O gerenciamento de projeto é importante pois envolve custos e está relacionado às
estratégias e necessidades do investidor, cujo projeto poderá ter inesperados. Assim, a
característica principal do gerenciamento de projetos são os riscos, positivos ou negativos,
para o investimento aplicado.
A confiança na apresentação do produto, maior clareza no planejamento do trabalho
e no processo de execução, melhor definição e comunicação dos próprios requerimentos,
confiança na entrega no prazo e com o custo especificado, são benefícios possíveis com a
gestão de projetos, que traz maior segurança não só para o cliente ou investidor do projeto,
mas também para a organização que se utiliza de um processo de gestão de de projetos, pois,
com essa prática, aumenta-se a produtividade, reduz-se o desperdício, aprimora-se a
competitividade no mercado e a integração do projeto na organização, resultando em uma
maior credibilidade e confiança dos envolvidos (DINSMORE e CAVALIERI, 2003; PMI,
2011).
Projeto é um esforço temporário, elaborado de maneira progressiva e realizado por
pessoas com a finalidade de entregar um produto ou um serviço. Está sempre sujeito à
restrições, planejamento, execução e controle (PMI, 2011).
Em uma época de mudanças, os projetos são constantes e certamente ocorrem para
que algo seja melhorado (DINSMORE e CAVALIERI, 2003). O gerente de projetos tem um
papel muito importante, o qual envolve o controle e monitoramento de maneira pró-ativa.
Gerentes de projeto reconhecem a existência da chamada tríplice restrição, conforme
mostrado na Figura 1.
3
Figura 1 – Tríplice Restrição
Diante do crescimento e da necessidade do aprimoramento dos projetos, o Project
Management Institute (PMI) especificou um conjunto de procedimentos que visa padronizar a
teoria associada à gerência de projetos, registrado em um documento denominado Project
Management Body of Knowledge (PMBOK) (MARTINS, 2007, p. 3).
O PMBOK é um guia baseado em experiências, selecionadas entre as melhores
práticas dentro da área de projetos, e que padroniza conhecimentos utilizados na gerência de
projetos. É um guia muito interessante e, por ser um material genérico, pode ser utilizado em
todos os tipos de projetos.
2.2 GERÊNCIA DE RISCOS
O surgimento de riscos em projetos é inevitável e suas origens são variadas: podem
ser humanas, ambientais, financeiras, podem estar relacionadas a acidentes, ao tempo. A
finalidade do gerenciamento de riscos é, então, diminuir o impacto dos eventos adversos ao
projeto, aumentando os eventos positivos, permitindo uma melhor qualidade e
desenvolvimento do projeto (DINSMORE e CAVALIERI, 2003; PMI, 2011).
O gerenciamento de riscos surge logo no início do projeto, estendendo-se até o seu
fim. Assim, já na primeira interação, na discussão inicial do projeto, na qual busca-se
esclarecer o que se almeja, os riscos já podem ser identificados.
Escopo
Custo Tempo
4
Por isso, é determinante a atenção a essas informações, pois elas fazem parte da
identificação dos riscos, ou seja, tudo que se refere à incerteza, às preocupações e questões a
serem resolvidas, são itens que merecem atenção e que devem ser agrupados conforme sua
ocorrência e impacto na análise destes riscos. Após essa identificação, alguns dados devem
ser esmiuçados: a probabilidade da sua manifestação, a perda no seu acontecimento e a fonte
causadora. Com estes dados em mãos, o estudo da melhor alternativa para uma solução
definitiva, ou construção de planos de ação - também conhecidos como plano de contingência
-, é elaborado com mais propriedade, minimizando, assim, futuras surpresas (POSSI, 2006,
p.13).
O monitoramento é um trabalho constante, com o objetivo de identificar o
surgimento ou a incidência de riscos, identificados anteriormente. Neste papel, há dois
destinos para o risco:
a) a resposta e solução de um caso já previsto, provomendo ajustes na execução do
plano apenas quando for necessário;
b) deparar-se com um risco novo, que deverá passar por uma análise até a resposta
da sua solução.
Neste contexto, é preciso lembrar que o risco deve ser tratado de forma adequada,
isto é, não deve ser subestimado. Além disso, é importante ressaltar que ele não é
necessariamente um ponto negativo, pode ser uma oportunidade positiva, um ponto positivo
diante do quadro atual da sua ocorrência e que, conforme a destreza do gerente do projeto,
poderá ajudar no impulsionamento do projeto, resultando em efeitos positivos além dos
esperados.
Nos tempos atuais, o uso de ferramentas que permitem o gerenciamento de riscos é
imprescindível, pois, diante do volume de informações que surgem em um projeto, é quase
impossível o seu gerenciamento, ou seja, na tempestade de informações referentes ao projeto,
o aparecimento dos riscos é certo e, com ele, a necessidade de um controle (PMI, 2011).
Um gerenciamento de risco deve seguir uma metodologia, ter ferramentas para
auxiliar em seu gerenciamento, possuir sincronismo na execução dos processos durante o
ciclo do projeto e ter definido as funções e responsabilidades para cada tipo de ação descrita
no plano. Além disso, o orçamento destinado a gerência de risco também é importante, pois
exige tempo, trabalho e mão de obra para a sua aplicação e desenvolvimento.
5
2.3 GERÊNCIA DE PROJETOS UTILIZANDO O RUP
O Rational Unified Process (RUP) é uma metodologia para gerênciar projetos de
desenvolvimento de software que usa o Unified Modeling Language (UML) como ferramenta
para especificação de sistemas (MARTINS, 2007 p. 192). É dividida em fases e cada fase
contém disciplinas, em um processo iterativo na vida do projeto. A Figura 2 demonstra esta
arquitetura.
Figura 2 – Arquitetura Geral do RUP 7.0
Fonte: Rational Software Corporation, 2011
Essa metodologia é totalmente configurável. Além de ser baseada em padrões e boas
práticas de mercado, é regularmente atualizada, podendo ser utilizada tanto no
desenvolvimento de projetos grandes ou pequenos, como também em desenvolvimentos não
caracterizados como projetos.
6
Percebe-se que ela possui quatro fases, com nove disciplinas, promovendo um
processo iterativo de desenvolvimento.
As fases são sequências denominadas Iniciação, Elaboração, Construção e Transição,
separadas por marco principal que determina o início e o fim de cada fase. Esses marcos se
resumem na avaliação e na análise da concretização dos objetivos (se eles foram alcançados
para o início da próxima fase). Conforme a necessidade, uma fase pode possuir N iterações,
com marcos menores, estabelecendo o ciclo de vida do RUP. Tal ambiente é mostrado na
Figura 3.
Figura 3 – Fases e iterações do RUP
Fonte: Rational Software Corporation, 2011
O objetivo na fase "Inciação" é levantar e especificar o produto. Pode-se observar
que a modelagem de negócios e requisitos são pontos fortes desta fase, caracterizada pelas
definições dos stakeholders, pela metodologia a ser seguida para condução do projeto, pelos
custos, pelas funcionalidades principais do sistema e, também, pelos riscos que já podem
determinar o início ou não do projeto.
O foco na fase "Elaboração" é analisar os requisitos, identificar funcionalidades
funcionais e não funcionais, avaliar os riscos significativos ao projeto, apresentar soluções e
elaborar uma arquitetura estável, que tenha a aprovação dos envolvidos e, principalmente, dos
investidores.
Na fase “Construção”, focaliza-se a implementação. Busca-se, então, o
desenvolvimento dos componentes que irão fazer parte da aplicação, seguido de testes junto
aos stakeholders, otimizações de custos, programações e qualidade.
7
A fase "Transição" representa os testes finais do produto. Nesta etapa, busca-se
acertar os pequenos erros, realizar treinamentos e obter as aprovações finais dos envolvidos.
Além disso, a gerência de configuração que tem um crescimento considerável na fase anterior,
ainda é muito presente nesta fase, devido aos ajustes de configuração e instalação.
As disciplinas ao todo são nove: Modelagem de Negócios, Requisitos, Análise e
Design, Implementação, Teste, Implantação, gerenciamento de Configuração e Mudanças,
gerenciamento de Projetos e Ambiente (RUP, 2007).
Na Modelagem de negócio é efetuado o trabalho de entendimento da estrutura na
qual o sistema será implantado. Analisam-se os problemas atuais e as possíveis melhorias,
gerando a sustentação necessária para o bom andamento do projeto.
A disciplina Requisitos tem como objetivo efetuar o levantamento dos processos
existentes, as necessidades e metas dos usuários, delimitando as fronteiras do sistema. É
responsável por apresentar aos desenvolvedores não só uma compreensão melhor do sistema,
mas também o tempo e os custos necessários para o seu desenvolvimento.
A análise e design fazem a transformação dos requisitos em um design do sistema a
ser criado. Desenvolvem, assim, uma arquitetura para o sistema, adaptam o design para que
corresponda ao ambiente de implementação, projetando-o para fins de desempenho.
Na implementação é definida a organização do código em camadas e subsistemas.
Realiza-se a implementação das classes e objetos em componentes e busca-se integrar os
resultados produzidos por implementadores ao sistema final.
A fase de testes está ligada a qualidade do produto. Nesta fase, deve-se localizar e
documentar erros que afetem a qualidade do software, confrontando o realizado com o
solicitado, através das especificações de projeto e requisitos. Além disso, é preciso verificar se
o software funciona conforme o projeto e garantir que os requisitos sejam implementados de
forma adequada.
A implantação descreve as atividades que devem ser realizadas para a garantia da
disponibilidade do produto de software para os usuários finais.
É na configuração e gerenciamento de mudança que se tem o controle dos artefatos
criados, permitindo um controle de versão que evita conflitos nas constantes alterações de
documentos e códigos do sistema desenvolvido.
8
O gerenciamento do projeto requer grande responsabilidade e disciplina, pois, como
o próprio nome diz, tem como objetivo planejar o projeto, coordenar a equipe, monitorar o
progresso do projeto e gerenciar os riscos. De tal modo, são tarefas do coordenador do
projeto:
identificar os riscos em potenciais, gerando uma lista do que pode dar errado;
analisar e priorizar os riscos, classificando-os quanto ao impacto no projeto, ou
seja, distribuindo-os de forma que consigamos visualizá-los do maior para o
menor impacto;
criar estratégias de contenção de riscos, permitindo a reorganização do projeto;
mitigar os riscos desenvolvendo planos para sua diminuição, reduzindo o seu
impacto;
gerar contingências e ou planos alternativos;
manter uma rotina de revisão constante dos riscos durante as iterações e produzir
uma lista de riscos atualizada ao longo do projeto.
O resultado deste trabalho é o artefato lista de riscos, contendo todos os riscos
identificados e classificados em ordem decrescente de importância. Esse artefato será
utilizado para desenvolver o plano de gerenciamento de riscos do projeto, que, por sua vez, já
fora concebido na fase de iniciação, tendo como base as informações adquiridas e sua
evolução no andar do projeto.
O plano de gerenciamento de riscos descreve como os riscos serão identificados e
analisados (qualitativa e quantitativamente) e como serão monitorados e controlados durante o
ciclo de vida do projeto (MARTINS, 2007, p. 114).
2.4 GERÊNCIA DE PROJETOS UTILIZANDO O PMBOK
O PMBOK é um guia, com conhecimentos e melhores práticas em gerência de
projetos, que fornece uma visão geral de todo o tipo de projeto, inclusive de software.
Tornou-se um padrão americano pela American National Standards Institute (ANSI),
padrão Institute of Eletrical and Eletronic Engineers (IEEE), sendo utilizado pela
9
International Standards Organization (ISO) e por empresas que desenvolvem sua própria
metodologia de gerenciamento de projetos (SEIBERT, 2004, p. 29).
2.4.1 ESTRUTURA DO PMBOK
O PMBOK está dividido em três seções, sendo elas:
Estrutura de gerenciamento de projetos, que possibilita o entendimento da
atividade de gerenciamento de projetos, a definição de termos-chave e a descrição do
ambiente de projeto.
A norma de gerenciamento de projetos, que especifica os processos da atividade
de gerenciamento de projetos. Esses processos se resumem a cinco grupos: processos de
iniciação, processos de planejamento, processos de execução, processos de monitoramento e
controle e grupo de processos de encerramento.
Nove áreas de conhecimento em gerenciamento de projetos que organizam
quarenta e quatro processos dos grupos de processos de geranciamento de projetos, definidos
em: gerenciamento de integração do projeto, gerenciamento do escopo do projeto,
gerenciamento de tempo do projeto, gerenciamento de custos do projeto, gerenciamento da
qualidade do projeto, gerenciamento de recursos humanos do projeto, gerenciamento das
comunicações do projeto, gerenciamento de riscos do projeto e gerenciamento de aquisições
do projeto. A Figura 4 apresenta este modelo.
10
Figura 4 – Os grupos de processos do gerenciamento de projetos.
Fonte: PM Tech Capacitação em Projetos, 2006.
2.4.2 GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS
Um processo é um conjunto de ações e atividades inter-relacionadas, realizadas para
obter um conjunto pré-especificado de produtos, resultados ou serviços (PMBOK, 2004, p.
38). O gerenciamento de projetos é realizado através de processos bem definidos, que são as
entradas e saídas com resultados esperados.
grupo de processos de iniciação: é a autorização do projeto ou uma fase dele.
grupo de processos de planejamento: define e refina os objetivos, planeja a
ação necessária para alcançar os objetivos e o escopo para os quais o projeto
foi realizado.
grupo de processos de execução: integra pessoas e outros recursos para realizar
o plano de gerenciamento do projeto.
grupo de processos de monitoramento e controle: mede e monitora
regularmente o progresso para identificar variações em relação ao plano de
11
gerenciamento do projeto de forma que possam ser tomadas ações corretivas,
quando necessário, para atender aos objetivos do projeto.
grupo de processos de encerramento: formaliza a aceitação do produto, serviço
ou resultado e conduz o projeto, ou uma fase do projeto, a um final ordenado.
2.4.3 ÁREAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS
O PMBOK classifica e organiza as áreas de conhecimento em: gerenciamento de
projetos, gerenciamento de integração do projeto, gerenciamento do escopo do projeto,
gerenciamento de tempo do projeto, gerenciamento de custos do projeto, gerenciamento da
qualidade do projeto, gerenciamento de recursos humanos do projeto, gerenciamento das
comunicações do projeto, gerenciamento de riscos do projeto e gerenciamento de aquisições
do projeto. Essa classificação é demonstrada na Figura 5:
12
Figura 5 - Áreas de conhecimento em gerenciamento de projetos
Fonte: PMBOX (2004, p.11)
2.4.4 GERENCIAMENTO DE RISCOS DO PROJETO
A área de gerenciamento de riscos tem como objetivo aumentar a probabilidade e o
impacto dos eventos positivos, diminuindo a probabilidade e o impacto dos eventos adversos
ao projeto. Para concretizar tal fim, realiza alguns processos: planejamento do gerenciamento
de riscos, identificação de riscos, análise qualitativa de riscos, análise quantitativa de riscos,
planejamento de respostas a riscos e monitoramento e controle de riscos (PMBOK, 2004, p.
237).
13
No planejamento do gerenciamento de riscos são abordados e tratados todos os riscos
possíveis que podem ocorrer durante o projeto. A Figura 6 descreve as etapas que controlam
esse processo:
Figura 6 - Visão do processo planejamento do gerenciamento de riscos
Fonte: PMBOK (2004, p. 242)
Através de reuniões, os riscos são identificados e discutidos entre o gerente de
projetos e os responsáveis de cada área. Esses riscos são dispostos na visão entrada e as saídas
representam as conclusões, formando um relatório chamado de plano de gerência de riscos , o
qual possui planos de execução de atividades de gerenciamento, incluindo metodologia,
funções, responsabilidades, orçamento, tempo, impacto e probabilidade de riscos.
A identificação de riscos determina o que pode afetar o projeto. Esse processo é
iterativo porque riscos podem ser identificados em qualquer momento durante a vida do
projeto. A Figura 7 demonstra uma visão deste processo.
Técnicas como: brainstorming, delphi, entrevistas, identificação da causa-raiz e
análise dos pontos fortes e fracos, ameaças e oportunidades.
Brainstorming - sob a liderança de um facilitador, pessoas geram ideias sobre risco
de projeto. São identificadas as fontes de risco em um escopo amplo e, durante a reunião, elas
são colocadas para todos examinarem (POSSI, 2006, p. 13).
14
Técnica delphi - um facilitador usa um questionário para solicitar ideias sobre os
riscos importantes do projeto. As respostas são submetidas individualmente e, posteriormente,
circulam entre os participantes para comentários adicionais (POSSO, 2006, p. 13).
Figura 7 - Visão do processo identificação de riscos
Fonte: PMBOK (2004, p.246)
Entrevistas - os riscos podem ser identificados por entrevistas com experimentados
gerentes de projeto ou especialistas no assunto (POSSI, 2006, p. 13).
Identificação da causa-raiz - é uma investigação das causas essenciais dos ricos de
um projeto. Muitas vezes, uma causa-raiz é a causa de muitos riscos, por isso, uma única ação
sobre ela elimina muitos problemas (POSSO, 2006, p 13).
A análise qualitativa de riscos classifica e prioriza os riscos pela sua probabilidade de
ocorrência, impacto, prazo de tolerância, custo, cronograma, escopo e qualidade do projeto.
Nesta análise, documentos como plano de gerenciamento de riscos e registros de riscos fazem
parte do material avaliado. Algumas técnicas podem ser utilizadas nesta análise como:
avaliação de probabilidade, impactos de riscos e matriz de probabilidade de impacto. A Figura
8 mostra esta organização.
15
Figura 8 - Visão do processo análise qualitativa de riscos
Fonte: PMBOK (2004,p.250)
O trabalho realizado na análise quantitativa de riscos é atribuir uma classificação
numérica aos riscos priorizados na análise qualitativa de riscos. Quantifica-se, assim, os
possíveis resultados de suas probabilidades de ocorrência, identificam-se os riscos que exigem
uma maior atenção e determina-se a melhor decisão de gerenciamento para resultados e
condições incertas. A Figura 9 apresenta uma visão deste processo.
Como o próprio nome propõe, o planejamento de respostas a riscos apresenta ações a
serem tomadas com o objetivo de reduzir as ameaças aos objetivos do projeto. Essas ações
devem ser claras e adequadas, e, nessa etapa, as pessoas devem assumir responsabilidades
sobre cada resposta. Além disso, são necessárias algumas estratégias como: prevenção através
de bom entendimento dos requisitos cercando todas as possibilidades da ocorrência de riscos;
transferir à outra parte a responsabilidade do gerenciamento de um determinado risco;
mitigação aos riscos desde o início do projeto reduzindo a probabilidade e impacto dos riscos.
A Figura 10 apresenta uma visão geral deste processo.
16
Figura 9 - Visão do processo análise quantitativa de riscos
Fonte: PMBOK (2004,p.254)
O monitoramento e controle de riscos é uma ação contínua que busca a identificação
de novos riscos ou mudanças. Segundo Possi (2006, p. 272), ¨é o subprocesso de
acompanhamento da evolução dos riscos durante o ciclo de vida do projeto e da
implementação dos planos de respostas aos riscos”.
Garantir não só que as premissas do projeto continuem válidas, mas que as
modificações de riscos e os procedimentos de gerenciamento continuem a serem seguidos, são
alguns dos objetivos deste processo. As entradas, saídas, ferramentas e técnicas são
apresentadas na Figura 11.
17
Figura 10 - Visão do processo planejamento de respostas a riscos
Fonte: PMBOK (2004, p.260)
Figura 11 - Visão do processo monitoramento e controle de riscos
Fonte: PMBOK (2004,p.265)
A reavaliação de riscos, auditorias de riscos, análise das tendências e da variação,
medição do desempenho técnico, análise das reservas e reuniões de andamento são
ferramentas e técnicas utilizadas no monitoramento e controle de riscos. Como resultado,
obtém-se a atualização do registro de riscos, formando o plano de gerenciamento de riscos,
conforme podemos visualizar na Figura 12.
18
Figura 12 – Entradas e saídas do plano de gerenciamento de riscos
Fonte: PMBOK (2004, p. 53)
Isso não significa que o conhecimento, as habilidades e os processos descritos devam
ser sempre aplicados uniformemente em todos os projetos. O gerente de projetos, com a
colaboração da equipe do projeto, é sempre responsável pela determinação dos processos
apropriados e do grau adequado de rigor de cada processo, e isso para qualquer projeto
específico (PMBOK, 2004, p. 37).
2.4.5 CONSIDERAÇÕES FINAIS
As metodologias são essenciais para o gerenciamento de riscos de um projeto.
Independente da grandeza deste, a aplicação e a utilização de técnicas de gerenciamento de
riscos permitem uma melhor qualidade e confiabilidade no trabalho realizado, pois propõem
não só uma organização em todos os aspectos, mas também uma linha de ataque aos pontos
que podem cooperar de forma negativa para o resultado do trabalho. Percebe-se que
constantemente o gerenciamento de risco vem evoluindo, e isso ocorre através das
ferramentas e formas de gerenciá-lo, que sempre buscam fechar todos os pontos críticos que
podem comprometer o resultado final do trabalho.
19
3 ESTUDO DE CASO
Este capítulo apresenta um estudo de caso na aplicação do gerenciamento de risco
em um projeto.
3.1 A EMPRESA
A organização na qual foi feito o estudo de caso é uma fábrica multinacional de
embalagens, denominada neste documento de empresa X. Seus produtos fabricados podem ser
vistos em vários supermercados e nos mais diferenciados itens como: sabonetes, sabão em pó,
creme dental e outros produtos de marcas conhecidas.
3.2 PROJETO DE ESTUDO DE CASO
Para um maior controle e organização da fila de produtos que devem ser fabricados,
a empresa X realizou um projeto para implantação de um software de gerenciamento de
sequenciamento de máquina, software este que, ao final de sua implantação, permitiu aos seus
usuários obterem informações como: em qual máquina será fabricado determinado produto, a
data e horário de início e finalização do mesmo, resultando em um aprimoramento da exatidão
no que concerne às respostas e prazos de entrega do produto aos seus clientes.
3.3 ESCOPO DO PROJETO
A implantação do software, inicialmente, contempla apenas uma única unidade do
grupo, onde serão definidos padrões para posterior implantação nas demais fábricas. Esta
unidade possui uma carteira de 60 clientes e uma produção mensal de aproximadamente 60
toneladas de embalagens, concebida por 20 máquinas, que operam por 24 horas diárias. Cada
cliente possui um tipo de embalagem, que são chamadas flexíveis, como: embalagens de
sabonetes, rótulos para garrafas pets, vidros, latas, potes de margarinas, maioneses, sacos de
ração e arroz, laminados utilizados em sacos para achocolatados e outros.
20
O software visa o controle do gerenciamento do que será colocado em cada máquina
para ser produzido, baseando-se na data do pedido do cliente; na matéria prima em estoque
ou, no caso da entrega da mesma, quando não houver quantidade suficiente para a produção;
e, também, no melhor encaixe das lacunas não preenchidas por pedidos de outros clientes.
Destaca-se, também, a necessidade do software permitir a mudança desta proposta de
produção, colocando, por exemplo, uma produção para outra data e horário quando a
necessidade de atendimento a um pedido é muito urgente. As Figuras 13 e 14 mostram como
ficará o resultado deste trabalho. Essas figuras representam uma parte do que a ferramenta
vem a oferecer para o atendimento da necessidade dos usuários.
Figura 13 – Quadro de sequência de produção por semana da ferramenta Scheduler
21
Figura 14 – Quadro de sequência de produção geral da ferramenta Scheduler
3.4 O PROJETO
Na primeira reunião deste projeto, intitulado Projeto Scheduler, foram nomeados os
stakeholders, analistas, gerentes do projeto e seu objetivo. Com base na UML, foi
desenvolvido um diagrama de atividades de gerenciamento de riscos para esse projeto,
demonstrado na Figura 15.
22
Figura 15 – Diagrama de atividades do gerenciamento de riscos para o projeto
Scheduler
3.4.1 USANDO A FERRAMENTA TRIMS
A ferramenta TRIMS <www.bmpcoe.org>, da Best Manufacturing Practices (BMP),
oferece uma Baselining que permite a introdução dessas informações. A Figura 16 apresenta
as possíveis parametrizações, onde são definidas as datas de conclusão das fases, as pessoas
envolvidas e suas responsabilidades e, principalmente, a lista de riscos.
23
Figura 16 – Baselining Projeto Scheduler
Fonte: Ferramenta de gerenciamento de risco TRIMS
Colocando em prática os ciclos do RUP pode-se, a partir dessa ferramenta, já iniciar
a sua aplicação, determinando as datas de entrega de cada fase. Tais datas também são a base
de definição do grau dos riscos identificados. A Figura 17 apresenta a disposição e a data de
conclusão de cada fase.
24
Figura 17 – Definição das datas de cada fase
Fonte: Ferramenta de gerenciamento de risco TRIMS
A lista dos integrantes do projeto, demonstrada na Figura 18, com suas respectivas
funções, contempla os responsáveis por responder aos riscos identificados, contribuindo para
o bom gerenciamento dos riscos.
25
Figura 18 – Definição de nomes e funções
Fonte: Ferramenta de gerenciamento de risco TRIMS
A aplicação das categorias de riscos é baseada em uma espécie de plano cartesiano,
que considera a Probabilidade de Ocorrência X Impacto medido de 1 a 5. Sua
representatividade a esta numeração indica: 1-Muito Baixa, 2-Baixa, 3-Moderada, 4-Alta e 5-
Muito Alta. Esses números são informados a cada risco e, com isso, a ferramenta consegue
calcular automaticamente a situação do risco quando respondido. Apenas o risco
caracterizado como “Desconhecido” é desconsiderado na avaliação pela ferramenta.
Os valores desta matriz permitem alteração mediante a experiência em gerenciamento
de riscos. Apesar de trazer valores padronizados, para este projeto foi necessário um pequeno
ajuste no item “Riscos do processo”, devido a não-padronização do uso da fila do que seria
colocado em produção, e isto já constatava uma certa resistência. A Figura 19 apresenta a
edição dessa matriz de valores dos riscos.
26
Figura 19 – Matriz de Riscos
Fonte: Ferramenta de gerenciamento de risco TRIMS
O questionário utilizado por essa ferramenta é o mesmo questionário utilizado pelo
Software Enginneering Instituite (SEI), que é um dos órgãos mais competentes da área de
Engenharia de Software. Este cenário, visto na Figura 20, é dividido em categorias que
abrangem requerimentos, design, código e teste de unidade, integração e teste, especialidade
de engenharia, desenvolvimento de processos, desenvolvimento do sistema, processo de
gestão, métodos de gestão, contrato, interfaces de programas e métodos de qualidade. Cada
categoria também tem divisões, chamadas de risco de processo, e podem ter de uma a nove
questões. Este quadro estabelece o nível de risco do modelo utilizado. As respostas às
perguntas podem ser vistas no anexo A.
27
Figura 20 – Riscos do Processo
Fonte: Ferramenta de gerenciamento de risco TRIMS
Para cada item foi determinado o início da atividade e os respectivos responsáveis
permindo um controle de acompanhamento em resposta e solução a cada risco. Conforme a
evolução das respostas aos riscos, foi possível observar na ferramenta aqueles que exigiam
uma maior atenção, pois, mediante as parametrizações, a ferramenta, através de cores,
mostrava os riscos e seus níveis (baixos, médios ou altos) que podiam comprometer o projeto.
A Figura 21 demonstra como foi definido o impacto e responsáveis sobre cada risco nesta
ferramenta.
28
Figura 21 – Determinando responsabilidades
Fonte: Ferramenta de gerenciamento de risco TRIMS
Analisando a Figura 21, notamos as questões relacionadas ao item de risco A-01
Estabilidade e, conforme as respostas, é perceptível como a ferramenta implementa o nível
deste risco no plano Probabilidade X Impacto, definindo o seu grau e possibilitando o
conhecimento sobre quais riscos devem ser priorizados.
Na Figura 22 é possível observar a resposta ao risco e também a disponibilização de
um link com a documentação gerada, o que facilita o acesso à documentação do projeto,
possibilitando uma melhor organização.
29
Figura 22 – Respondendo aos Riscos
Fonte: Ferramenta de gerenciamento de risco TRIMS
Foi possível também efetuar o controle de riscos do produto, porém, em qualquer
modelo escolhido, este quadro vem em branco, pois não existe um padrão de risco, uma vez
que cada produto possui características distintas e, consequentemente, riscos diferentes. Nota-
se na Figura 23 a abertura do campo probabilidade, que, no quadro riscos de processos, tem o
seu cálculo baseado nas respostas aos riscos. Neste campo, informa-se as possibilidades de
riscos, pois o foco é a ação a ser tomada.
A mudança da barra de riscos é alterada conforme a alteração da probabilidade,
perdendo-se o histórico da informação anterior. O mesmo esquema de controle ocorre com o
quadro Problemas.
30
Figura 23 – Definindo um risco de produto
Fonte: Ferramenta de gerenciamento de risco TRIMS
A Figura 24 apresenta um gráfico com resultados (em percentual) das respostas das
280 questões de riscos identificadas no processo. Diante dessas informações é possível fazer
uma analogia: as questões cuja resposta foi a palavra Sim, podemos afirmar que o risco é
representado como baixo; as questões com respostas igual a não, o risco é representado como
alto; as questões cuja resposta foi a palavra parcialmente, o risco é apresentado como médio;
já as questões que tiveram como resposta desconhecido e não aplicável, a ferramenta
desconsiderou em sua análise, não resultando em nenhum nível de risco.
31
66%
9%
20%
0%
5%
Sim
Não
Parcialmente
Desconhecido
Não aplicável
Figura 24 – Gráfico de respostas junto as questões de riscos do projeto
Com a aplicação do PMBOK junto a esta ferramenta, foi possível fazer o controle de
riscos em cada fase do ciclo de vida do projeto: conceitual, planejamento, execução e
conclusão, permitindo desempenhar o controle de entradas e saídas o qual o processo prove
em gerenciamento de risco.
A forma proposta se encaixa bem na análise qualitativa e quantitativa dos riscos e, por
valer-se do planejamento de respostas aos riscos e de seu monitoramento, possibilita a análise
dos pontos fortes e fracos, permitindo não só a observação da parte vunerável, mas
principalmente a tomada de ações, preparando-se para possíveis ameaças ao longo do projeto.
A forma de priorização dos riscos é muito interessante diante da pré-parametrização
realizada, realizada, que, além de automatizar a priorização dos riscos, define sua
probabilidade de ocorrência e impacto, permitindo definir o nível do risco.
Na utilização da ferramenta juntamente ao RUP o processo iterativo é muito bem
aceito, já que nos permite incluir novos riscos identificados e repassar por eles a cada
passagem pelas fases. No próprio modelo utilizado é possível observar questões que abordam
as noves disciplinas apresentadas pelo ciclo do RUP. Na ferramenta estas fases são nomeadas
como elemento. A tabela 1 avalia as funcionalidades da ferramenta perante os processos de
gerenciamento dos riscos abordados pelo PMI através do PMBOK.
32
Tabela 1. Avaliação das funcionalidades da ferramenta TRIMS X PMBOK
TRIMS
Processos
PMI
Planejar Riscos Atendido
Identificar Riscos Atendido
Análise Qualitativa Atendido
Análise Quantitativa Atendido
Respostas Atendido
Monitorar e Controlar Atendido
3.4.2 CONSIDERAÇÕES FINAIS
A ferramenta TRIMS <www.bmpcoe.org>, possui muitas vantagens: além de ser um
software gratuito, é uma ferramenta simples e intuitiva, que traz alguns modelos pré-
configurados prontos para serem utilizados. Outra vantagem desta ferramenta são os
questionários dos modelos pré-configurados, utilizados no Software Enginneering Institute
(SEI), que permitem acrescer outros riscos identificados, apesar do questionário ser amplo e
abranger as diversas situações em que um projeto possa apresentar riscos. Neste trabalho foi
possível efetuar sua avaliação em relação à usabilidade e também em relação às
funcionalidades disponíveis.
33
4 CONCLUSÕES E TRABALHOS FUTUROS
Pela utilização de um estudo de caso real, no qual buscou-se implementar as melhores
práticas de geranciamento de riscos, foi possível estabelecer uma linha de raciocínio e
também vivenciar a aplicabilidade dos conceitos do PMBOK juntamento ao desenvolvimento
incremental e iterativo do RUP 7.
O PMBOK é caracterizado por tratar, em cada processo, das entradas (informações
para que o fato ocorra), das ferramentas e técnicas (para processamento das entradas) e das
saídas (identificando o resultado do processamento), abrangendo como um todo qualquer
trabalho, favorecendo, assim, seu uso em vários projetos, sejam eles de software ou não.
O RUP, que traz o seu modelo em fases e iterações com seus processos pré-
estabelecidos e organizados em disciplinas, é totalmente configurável, podendo ser utilizado
em projetos de grandes ou pequenas proporções. A denominação de marcos para seguir para
as próximas etapas ou fases favorece o esclarecimento do objetivo daquele momento e o
acompanhamento do projeto em relação ao seu planejamento original.
É claro neste trabalho o controle sobre os riscos do projeto, proporcionando maior
segurança e confiabilidade ao trabalho realizado. A organização e respostas rápidas aos casos
de possíveis riscos são possíveis devido a existência de respostas previamente elaboradas,
evitando surpresas que venham a prejudicar o andamento do projeto.
A aplicabilidade dos conceitos aqui vistos usando uma ferramenta voltada para
gerenciamento de riscos propocionou um maior controle sobre a lista de informações, isto é,
permitiu gerar uma base de conhecimentos necessários para o auxílio na tomada de decisões,
para o gerenciamento dos riscos de forma a respondê-los, para a medição dos riscos que
poderiam afetar o resultado do projeto, para quantificar o número de riscos que o projeto
poderia obter e, até mesmo, para mitigar os riscos por completo.
O resultado deste trabalho mostra quão importante é o gerenciamento de riscos em
um projeto, pois essa ação aumenta expressivamente a probabilidade de sucesso, favorecendo,
ao máximo, o alcance do planejado em termos de custos, tempo, qualidade e escopo do
projeto. Esse sucesso é adquirido com a utilização de técnicas de coleta de informações como:
brainstorming, delphi, entrevistas, análise dos pontos fortes e fracos, análise qualitativa e
quantitativa dos riscos, que permitem identificar os fatores de probabilidade de impacto e
prioridade.
34
A implantação da gerência de riscos na empresa implica em mudanças de
paradgimas que nem sempre são muito aceitas, principalmente por profissionais antigos, os
quais mostram certa resistência a novos conceitos ou formas diferentes de levar um projeto.
Porém, após ver os resultados e também participar desta nova visão sobre riscos, pôde-se
mostrar e obter resultados que, comparados a forma como se levava um projeto anteriormente,
se apresentaram muito mais surpreendentes e positivos.
A utilização deste estudo de caso com o gerenciamento de risco apontou vários
pontos críticos que não apareceriam nas formas de projeto sem nenhum controle. Essas
formas sem controle, por não utilizarem nenhum tipo de técnica e ferramenta específicas para
o gerenciamento de risco, não permitem a visualização de tais pontos, que, certamente, viriam
a tona após sua implantação, resultando em pontos negativos para o projeto, para a sua
produção - coração da empresa.
Temos que considerar que o uso da ferramenta e de suas técnicas traz ótimos
resultados, porém exige recurso e tempo. Sabemos que em projetos a entrega do produto final
sempre gerou muita expectativa e que algumas ações como preparar, planejar, integrar, treinar
e, finalmente, implantar sempre tiveram seu tempo reduzido. Por causa disso muitos
profissionais deixam alguns controles de lado, ocasionando um problema pós-entrega do
produto. Essa é, então, a principal diferença entre o uso do gerenciamento de risco e o não
uso: tempo de gerenciamento e entrega com maior qualidade, pois, ao optar pelo seu não uso,
a entrega pode até ser realizada em menos tempo, porém poderá ter vários riscos após entrega
do produto. Se o cliente final estiver com a lista de riscos, poderá entender melhor o porquê
de um maior tempo, devido as respostas aos riscos identificados.
Neste trabalho foi possível mensurar itens, como o uso de boas práticas e também o
uso de ferramentas de controle com projeto que não adotaram tais critérios. Espera-se que a
abordagem aqui feita seja utilizada em futuros trabalhos que tenham como objetivo:
Buscar formas de como desenvolver um banco de dados com informações
voltadas aos riscos de projeto para consultas futuras, possibilitando saber se o
risco foi identificado em outros projetos e como foi tratado.
Aprofundar a pesquisa de software para realização do gerenciamento de riscos
em projetos.
35
REFERÊNCIAS
BOOCH, Grady; RUMBAUCH, James; JACOBSON, Ivar. UML: Guia do Usuário. 2.ed.
Rio de Janeiro: Editora Campus, 2005. 474 p.
DINSMORE, C.; CAVALIERI, A.; Como se tornar um Profissional em Gerenciamento de
Projetos: Livro-Base de “Preparação para certificação PMP - Project Management
Professional”. Rio de Janeiro: QualityMark, 2003.
FOINA, Paulo Rogério. Tecnologia de informação, Planejamento e Gestão. 2.ed. São
Paulo: Editora Atlas S.ª, 2006. 339 p.
MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software
com PMI, RUP e UML. 4 ed. Rio de Janeiro: Brasport, 2007, 325p.
MENEZES, Luis César de Moura. Gestão de Projetos. 1.ed. São Paulo: Editora Atlas, 2001.
211p.
@RISK, Versão 5.7. Disponível em: <http://www.palisade-br.com>. Acesso em: 10 jul.
2011.
POSSI, Marcus; LOUZADA, Dalton; BORGES, Elizabeth; SENRA, Paulo; LIMA, Ricardo.
Gerenciamento de projetos guia do profissional, fundamentos técnicos. Vol. 3. Rio de
Janeiro: Brasport, 2006. 322 p.
PMBOK, Project Management Institute (PMI). PMBOK – Project Management Body of
Knowledge. 3ed. 2004. Disponível em <http://www.pmimg.org.br>. Acesso em: 07 jul. 2011.
Rational Focal Point, Versão 0.0.0, Disponível em <http://www-
142.ibm.com/software/products/br/pt/ratifocapoin/>. Acesso em: 07 jul. 2011.
RiskFree, Versão 1.0, Disponível em <http://www.inf.pucrs.br/~rafael/RiskFree/>. Acesso
em: 10 jul. 2011.
RISKTRAK. Versão não disponível. Disponível em <http://risktrak.com/>. Acesso em: 10
jul. 2011.
RUP 7, Rational Unified Process, Versão 7.0.1, CD-ROM. Rational Software Corporation,
Cupertino, California, 2007.
SEI, Software Enginneering Instituite, Disponível em: <www.sei.cmu.edu/>. Acesso em: 14
fev. 2012.
TRIMS, Software Risk Management, Versão 4.2.1, Disponível em <www.bmpcoe.org>.
Acesso em: 07 jul. 2011.
VIEIRA, Marconi Fábio. Gerenciamento de Projetos de tecnologia da Informação. 1ed.
Rio de Janeiro: Editora Campus, 2003. 294p.
VICENTINO, C. História Geral. São Paulo: Editora Scipione, 1997.
36
APÊNDICES
APÊNDICE A – OUTRAS FERRAMENTAS DE GERENCIAMENTO DE
RISCO
FocalPoint – Ferramenta de gerenciamento de projetos da IBM que abrange o
gerenciamento de riscos.
Riskfree – Ferramenta de apoio e gerenciamento de riscos em projetos de software
desenvolvida por alunos da disciplina Engenharia de Software II, do curso de Ciência da
Computação, da PUCRS.
RKSTRAK – Ferramenta de gerenciamento de riscos com suporte desenvolvida pela
RiskTrak International Corporate.
@RISK – Ferramenta para análise de risco desenvolvida pela Palisade Corporation.
37
ANEXOS
ANEXO A – TRADUÇÃO QUESTIONÁRIO FERRAMENTA TRIMS
Texto em Ingles Texto em Português Possíveis
Respostas
(Sim, Não,
Parcialmente
,
Desconhecido
e Não
Aplicável
(A) Process Risks (A) Riscos do processo ---
A-1.0 Requirements A-1.0 Requisitos ---
A-01 Stability A-01 Estabilidade ---
A-01.1 Have requirements that
thoroughly and accurately
describe all the system functions
been identified?
A-01.1 Os requisitos estão completos e
descrevem com precisão todas as funções
do sistema identificados?
Sim
A-01.2 Are the external
interfaces defined in sufficient
detail to complete the design?
A-01.2 As interfaces externas estão
defindas em detalhes suficientes para
completar o projeto?
Sim
A-01.3 Have the interfaces been
coordinated with, and approved
for use, with all the
interconnecting systems?
A-01.3 As interfaces estão de acordo e
aprovadas para a utilização com todos os
sistemas de interligação ?
Sim
38
A-01.4 Have possible conflicts
between requirements been
addressed and resolved?
A-01.4 Os possíveis conflitos estão entre
os requisitos abordados e resolvidos ?
Parcialmente
A-02 Completeness A-02 Plenitude ---
A-02.1 Are all the users'
expectations for the system
formally documented as
requirements?
A-02.1 Todas as expectativas dos
usuários para o sistema estão
formalmente documentadas como
requisitos?
Parcialmente
A-02.2 Is there a process to
document any missing
requirements identified once the
software development begins?
A-02.2 Existe um processo para
documentar todos os requisitos
identificados uma vez que o
desenvolvimento de sobftware inicie?
Sim
A-02.3 Have all specification
TBDs been replaced by actual
information and/or discrete
values?
A-02.3 Todas as especificaçoes TBDs
estão sido substituida por informação real
e / ou valores discretos?
Sim
A-02.4 Are all immediate and
projected requirements detailed
in the specification?
A-02.4 Todas as necessidades imediatas
estão projetadas detalhadamente na
especificação?
Parcialmente
A-02.5 Is there time to
incorporate all missing
requirements into the system
design?
A-02.5 Existe tempo para incorporar
todos os requisitos ausentes na concepção
do sistema?
Não
A-02.6 Are the external
interfaces completely defined?
A-02.6 Estão as interfaces externas
completamente definidas?
Sim
A-03 Clarity A-03 Clareza ---
A-03.1 Can the requirements be
readily understood as
A-03.1 Os requisitos podem ser
facilmente compreendidos conforme
Sim
39
documented? documentado?
A-03.2 Is there a satisfactory
method to resolve requirements
ambiguities?
A-03.2 Existe um método satisfatório
para resolver ambiguidades de requisitos?
Parcialmente
A-03.3 Were models utilizing
the Unified Modeling Language
(UML) developed as
appropriate?
A-03.3 Foram utilizados modelos Unified
Modeling Language (UML) conforme o
desenvolvimento de caso ?
Não
A-04 Validity A-04 Validade ---
A-04.1 Has there been a review
to verify that the documented
requirements specify what the
customer (users) really wants?
A-04.1 Houve uma revisão para verificar
se os requisitos documentados,
especificão o que o cliente (usuários)
realmente quer?
Sim
A-04.2 Is there an active plan to
revise any specifications that do
not address user needs?
A-04.2 Existe um plano ativo de revisar
quaisquer especificações que não
atendem as necessidades do usuário?
Sim
A-04.3 Is there a formal process
to ensure that the developer and
the customer (users) have a
common understanding of the
requirements?
A-04.3 Existe um processo formal para
garantir que o desenvolvedor e o cliente
(usuários têm um entendimento comum
dos requisitos?
Sim
A-04.4 Is there a written and
agreed-to plan to validate the
product to the requirements?
A-04.4 Existe uma escrita e um plano de
acordo, validando o produto com os
requisitos?
Sim
A-05 Feasibility A-05 Viabilidade ---
A-05.1 Are there feasibility
studies to verify the
requirements are achievable with
A-05.1 Há estudos de viabilidade para
verificar se os requisitos são atingiveis
com a tecnologia atual?
Sim
40
current technology?
A-05.2 Are potential technical
difficulties identified and
prioritized?
A-05.2 As dificuldades técnicas em
potenciais são priorizadas?
Parcialmente
A-05.3 Is management confident
of the assumptions made in
feasibility studies?
A-05.3 É a gestão confiante das
premissas adotadas nos estudos de
viabilidade?
Sim
A-06 Precedent A-06 Precedente ---
A-06.1 Have requirements, more
advanced than current state-of-
the-art, been avoided when
possible?
A-06.1 Existem requerimentos, mais
avançados do que a corrente state-of-the-
art, foram evitadas quando possível?
Sim
A-06.2 Does the developer have
sufficient knowledge in the
requirements areas?
A-06.2 O desenvolvedor teve
conhecimento suficiente nas áreas de
requisitos?
Sim
A-06.3 Is there a plan for
acquiring needed requisite
knowledge in the requirements
areas?
A-06.3 Existe um plano para adquirir
conhecimentos necessários nas áreas de
requisitos ?
Sim
A-07 Project Scale A-07 Escala de Projeto ---
A-07.1 Does the development
organization have experience
developing a system of this size
and complexity
A-07.1 A organização de
desenvolvimento têm experiência no
desenvolvimento de um sistema deste
porte e complexidade?
Sim
A-07.2 Has the
contractor/developer
successfully completed a project
of this size and complexity
A-07.2 O contrante/desenvolvedor
completaram com sucesso um projeto
desta dimensão e complexidade antes?
Sim
41
before
A-07.3 Is the current
organization large enough to
perform the work for this project
A-07.3 A atual organização é grande o
suficiente para relizar o trabalho para este
projeto?
Sim
A-08 Development Documents A-08 Documentos de Desenvolvimento ---
A-08.1 Has a Software
Requirements Specification
(SRS) been developed and
reviewed?
A-08.1 Existe uma especificação de
requisitos de Software (SRS) onde foi
desenvolvido e revisto?
Sim
A-08.2 Has a Software
Development Plan (SDP) been
developed and reviewed?
A-08.2 Existe um plano de
desenvolvimento de software (SDP) onde
foi desenvolvido e revisto?
Sim
A-08.3 Is the SDP coordinated
with the hardware
development/delivery schedule?
A-08.3 As cordenadas SDP com o
desenvolvimento de
hardware/cronograma foi entregue?
Sim
A-08.4 Have the appropriate
models describing system
functions been developed and
reviewed?
A-08.4 Já os modelos apropriados que
descrevem as funções do sistema foi
desenvolvido e revistos?
Sim
A-2.0 Design A-09 Design ---
A-09 Functionality A-09 Funcionalidade ---
A-09.1 Is there a defined process
to determine the feasibility of
algorithms and design?
A-09.1 Existe um processo definido para
determinar a viabilidade de algorítmos e
de design?
Não
A-09.2 Are the algorithms and
design verified against the
requirements?
A-09.2 Estão os algoritmos e desgin
verificados em relação aos requisitos?
Sim
42
A-09.3 Does the design utilize
component-based logical
architecture?
A-09.3 O projeto utiliza arquitetura
baseada em componentes lógicos?
Não
A-09.4 Does the design support
software reuse wherever
feasible?
A-09.4 O software de suporte de design
foi sempre reutilisável quando possível?
Parcialmente
A-09.5 Have algorithms been
validated by a proven method or
other prior usage?
A-09.5 Os algorítmos foram validados
por um método comprovado ou outro já
usado?
Sim
A-10 Difficulty A-10 Dificuldade ---
A-10.1 Is the design based on
realistic and conservative
assumptions?
A-10.1 É o design baseado em
pressopostos realistas e conservadores?
Sim
A-10.2 Are there workable
solutions available for all
requirements?
A-01.2 Existem soluções viáveis
disponíveis para todos os requisitos?
Parcialmente
A-10.3 Are requirements and
functions practical to design and
implement?
A-10.3 Os requisitos e funções práticas
de desgin foram implementados?
Sim
A-11 Interfaces A-11 Interfaces ---
A-11.1 Is there a process for
defining internal interfaces?
A-11.1 Existe um processo para a
definição de interfaces internas?
Parcialmente
A-11.2 Are the internal
interfaces (software-to-software
and software-to-hardware) well
defined?
A-11.2 As interfaces internas (de
software para software e para hardware)
foram bem definidas?
Sim
A-11.3 Is there a formal, A-11.3 Existe uma forma, processo de Não
43
documented change control
process for internal interfaces?
controle de mudanças documentados para
interfaces internas?
A-11.4 Have hardware
specifications been finalized
before software design begins?
A-11.4 As especificações de hardware
foram finalizados antes que o design de
software começasse?
Parcialmente
A-11.5 Will all software
interfaces be designed before
coding begins?
A-11.5 Será que todas as interfaces de
software serão projetadas antes do inínio
da codificação?
Sim
A-11.6 Are there engineering
design models that can be used
to test the software?
A-11.6 Existem modelos de design que
podem ser usados para testar o software?
Sim
A-11.7 Do the interfaces meet
the open system standards
A-11.7 As interfaces estão atendendo aos
padrões de sistemas abertos?
Parcialmente
A-12 Performance A-12 Execução ---
A-12.1 Has a performance
analysis been performed to
verify objectives will be met?
A-12.1 A análise de desempenho foi
realizada para verificar se os objetivos
forma atingidos?
Parcialmente
A-12.2 Is there a high level of
confidence in the performance
analysis?
A-12.2 Existe um alto nível de confiança
na análise de desempenho?
Parcialmente
A-12.3 Have performance issues
been resolved?
A-12.3 Os problemas de desempenho
existentes foram resolvidos?
Parcialmente
A-12.4 Is there a model
available to track performance
through design and
implementation?
A-12.4 Existe um modelo disponível para
acompanhar o desempenho através da
concepção e implementação?
Não
A-13 Testability A-13 testabilidade ---
44
A-13.1 Have studies been
performed to determine if the
software design will be testable
against requirements?
A-13.1 Já foram realizados estudos para
determinar se o projeto de software será
testada contra os requisitos?
Não
A-13.2 Does the software design
include features to aid testing?
A-13.2 O design de software inclui
recursos para ajudar os testes?
Não
A-13.3 Are the testers involved
in analyzing requirements to
produce test plans?
A-13.3 Os testes envolvidos na análise de
requisitos tiveram planos de testes?
Sim
A-14 Hardware Constraints A-14 Restrições de Hardware ---
A-14.1 Does the hardware
support all requirements (e.g.,
architecture, capacity, RMA)?
A-14.1 Será que o hardware suporta
todos os requisitos (exemplo a
arquitetura, capacidade, RMA)?
Parcialmente
A-15 COTS and NDI Software A-15 COTS e NDI Software ---
A-15.1 Are resources allocated
to support reuse or re-
engineering of software NOT
developed on the project?
A-15.1 Os recursos alocados para apoiar
a reutilização ou engenharia de software
não foram desenvolvidos no projeto ?
Não aplicável
A-15.2 Has an analysis been
performed to determine the trade
off to make or buy the
functionality provided by
COTS/NDI software?
A-15.2 Existe uma análise que foi
desenvolvida para determinar o trade-off
para fazer ou comprar a funcionalidade
fornecida pelo COTS/NDI software?
Não aplicável
A.-15.3 Are issues of
COTS/NDI documentation,
customization, performance,
functionality, timely delivery,
testing, maintainability
A.-15.3 As questões de COTS/NDI
documentação, personalização,
performance, funcionalidade e prazo de
entrega, testes, manutenção (incluindo
suporte do fornecedor) foram resolvidos?
Não aplicável
45
(including vendor support)
resolved?
A-15.4 Has the process for
integrating COTS software
updates or revisions been
defined?
A-15.4 O processo de integração de
atualializações de software COTS ou
revisões foram definidos?
Não aplicável
A-3.0 Code & Unit Test A-3.0 Código e teste de unidade ---
A-16 Feasibility A-16 Viabilidade ---
A-16.1 Is the product
implementation completely
defined by the design
specification?
A-16.1 A implementação do produto foi
completamente definida pela
especificação do projeto?
Parcialmente
A-16.2 Are the selected
algorithms and designs
structured so they are clear and
easy to implement?
A-16.2 Os algorítmos selecionados e
projetos estruturados estão de modo
claros e fáceis de implementar?
Parcialmente
A-16.3 Was a formal Design
Review held with the
programming team before
coding began?
A-16.3 A revisão formal do projeto foi
realizado com a equipe de programação
antes da codificação iniciar?
Não
A-17 Code Implementation A-17 Implementação de código ---
A-17.1 Is the design sufficiently
completed for coding to start?
A-17.1 O design é suficientemente
completo para codificação iniciar?
Sim
A-17.2 Do the design
specifications provide sufficient
detail to write the code?
A-17.2 As especificações de projeto
fornecem detalhes suficientes para
escrever o código?
Parcialmente
A-17.3 Are system constraints A-17.3 As restrições do sistema (tempo, Parcialmente
46
(timing, memory, external
storage) adequately defined to
support coding?
memória, armazenamento, externo) estão
definidas adequadamente para apoiar a
codificação?
A-17.4 Is the programming
language suitable for producing
the software on this program?
A-17.4 A liguagem de programação é
apropriada para produzir o sotware deste
programa?
Sim
A-17.5 Is a single language to be
used on the program?
A-17.5 A linguagem é única para ser
usada no programa?
Não
A-17.6 If more than one
language is used, is there
interface compatibility between
the code produced by the
different compilers?
A-17.6 Se mais de um idioma é usado, há
compatibilidade de interface entre o
código produzido pelos diferentes
compiladores?
Sim
A-17.7 Is the development
computer the same as the target
computer?
A-17.7 O computador de
desenvolvimento é o mesmo que o
compudator de destino?
Não
A-17.8 If development and
target computers are different,
do both have the same support
tools (IDE, compiler, etc.)?
A-17.8 Se os computadores de
desenvolvimento são diferentes, ambos
não têm as mesmas ferramentas de
suporte (IDE, compilador, etc)?
Sim
A-17.9 If development hardware
is being used, are the hardware
specifications adequate to code
the software?
A-17.9 Se o hardware de
desenvolvimento está sendo usado, as
especificações de hardware são
adequadas para codificar o software?
Sim
A-18 Unit Testing A-18 Testes unitários ---
A-18.1 Has a code walk through
or other code peer review been
performed on all code elements?
A-18.1 Foi repassado o código ou feita
uma revisão passando por todos os
elementos do código?
Parcialmente
47
A-18.2 Is unit testing to begin
only after code is verified with
respect to the design?
A-18.2 O início da unidade de teste, foi
somente depois de verificado no que diz
respeito a concepção ?
Parcialmente
A-18.3 Has sufficient unit
testing been planned to verify all
code functions?
A-18.3 O teste de unidade foi
suficientemente planejado para verificar
todas as funções de código?
Parcialmente
A-18.4 Is sufficient time
scheduled to perform all unit
testing that must be completed?
A-18.4 O tempo agendado foi suficiente
para executar todos os testes de unidade a
ser concluida?
Parcialmente
A-18.5 Are there plans in place
to ensure that unit testing will be
completed if there are schedule
problems?
A-18.5 Há planos para assegurar que os
testes de unidade será concluida se
houver problemas de programação?
Sim
A-04 Integration & Teste A-04 Integração e teste ---
A-19 Environment A-19 Ambiente ---
A-19.1 Has there been a walk
through of the test plans and
procedures?
A-19.1 Houve uma revisão através dos
planos de testes e procedimentos?
Sim
A-19.2 Are sufficient realistic
scenarios and test data
developed to demonstrate
requirements (e.g., specified data
traffic, real-time response,
asynchronous event handling,
user and multi-user interaction)?
A-19.2 Os cenários e dados de ensaios
desenvolvidos são suficientes para
demonstrar os requisitos (por exemplo, o
tráfego de dados especificado, resposta
em tempo real, manipulação de eventos
assíncronos, usuário e multi-interação do
usuário)?
Não
A-19.3 Are there sufficient
facilities (computers, equipment,
space, personnel) to do adequate
A-19.3 Existem instalações suficientes
(computadores, equipamentos, espaço,
pessoal,) para fazer a interação adequada
Sim
48
integration and testing? e testes?
A-19.4 Is it possible to verify
performance at the integration
facility?
A-19.4 É possível verificar o desempenho
na unidade de integração?
Não
A-19.5 Is there hardware and
software instrumentation to
facilitate testing?
A-19.5 Existe hardware e software de
instrumentação para facilitar os testes?
Não
A-19.6 Are the facility and
instrumentation sufficient for all
testing?
A-19.6 A facilidade e instrumentação são
suficiente para todos os testes?
Parcialmente
A-20 Product Integration A-20 Integração do produto ---
A-20.1 Is the target computer to
be available as needed?
A-20.1 O compudador de destino está
disponível quando necessário
Sim
A-20.2 Is there a formal
acceptance criteria agreement for
all requirements?
A-20.2 Existe uma aceitação formal de
acordo aos critérios para todas as
necessidades?
Sim
A-20.3 Are the external
interfaces at the integration site
defined, documented, and
baselined?
A-20.3 Existe interfaces externas no sítio
de integração definido, documentado e
com baseline?
Sim
A-20.4 Is adequate time
allocated for product integration
and test?
A-20.4 O tempo é suficiente na alocação
para integração e testes?
Parcialmente
A-20.5 Is sufficient product
integration specified to exercise
the total system?
A-20.5 A integração do produto
especificado é suficiente para exercer a
totalização do sistema?
Sim
A-20.6 Is it possible to test all A-20.6 É possível testar todos os Parcialmente
49
requirements using the test plan
and procedures?
requisitos, utilizando o plano de teste e
procedimentos?
A-20.7 If COTS software is
being used, are independent tests
to be made that verify vendor
data for requirements allocated
to those products?
A-20.7 Se o software COTS está sendo
usado, os testes feitos de forma
independentes foram verificados pelos
requisitos alocados para esses produtos?
Não aplicável
A-20.8 Is the COTS contract
clear on the integration and test
requirements?
A-20.8 O contrato é claro sobre COTS a
integração de requisitos de teste?
Não aplicável
A-21 System Integration A-21 Integração do sistema ---
A-21.1 Is sufficient system
integration specified to include
all requirements?
A-21.1 A especificação de integração do
sistema é suficiente para incluir todos os
requisitos ?
Sim
A-21.2 Is adequate time
allocated for system integration
and test?
A-21.2 O tempo alocado para integração
de sistemas e testes é suficiente?
Parcialmente
A-21.3 Are developers part of
the integration team?
A-21.3 Parte do time de integração são
desenvolvedores?
Sim
A-21.4 Are there user
representatives on the
integration team?
A-21.4 Há representantes de usuários na
equipe de integração:
Sim
A-21.5 If the product is being
integrated into an existing
system, is there a parallel
cutover period?
A-21.5 Se o produto está sendo integrado
a um sistema existente, há um período de
transição paralela?
Sim
A-21.6 If there is no parallel
cutover, is there a formal plan to
A-21.6 Se não houver transição paralela,
existe um planoformal para garantir que o
Não aplicável
50
ensure the product will work
correctly when integrated?
produto irá funcionar corretamente
quando integrado?
A-21.7 Is the system integration
site a true representation of the
installation site?
A-21.7 Existe um site de integração do
sistema verdadeiro representando o local
de instalação?
Sim
A-22 Test Reporting A-22 Relatórios de teste ---
A-22.1 Is there a Problem
(Trouble) Report system for
users and testers to report and
review problems?
A-22.1 Existe um problema (Trouble)
sistema de relatório para os usuários e
testadores para relatar e analisar os
problemas?
Sim
A-22.2 Is there a documented
process to track Problem Reports
to resolution?
A-22.2 Existe um processo documentado
para acompanhar relatórios de problemas
para resolução?
Sim
A-22.3 Are unresolved Problem
Reports reviewed regularly?
A-22.3 Relatórios de problemas não são
revisados regularmente?
Não
A-22.4 Is a formal Test Report
to be generated and submitted
for review?
A-22.4 Existe um relatório de teste
formal para ser produzidos e
apresentados para revisão?
Sim
A-5.0 Engineering Specialty A-5.0 Especialidade de engenharia ---
A-23 Maintainability A-23 Manutenibilidade ---
A-23.1 Is the architecture,
design, and code sufficient to
address maintainability issues?
A-23.A arquitetura, design e código são
suficiente para tratar de questões de
manutenibilidade?
Sim
A-23.2 Are maintainability
people involved early in the
design?
A-23.2 As pessoas de manutenibilidade
estão envolvidas desde o início do
projeto?
Sim
51
A-23.3 Does the product
documentation allow
maintenance by an organization
other than the developer?
A-23.3 A documentação do produto
permite a manutenção por um outra
organização que não seja o
desenvolvedor?
Sim
A-23.4 Does the design meet the
open systems criteria as
specified in the OACE?
A-23.4 O design satisfez os critérios de
sistemas abertos, tal como especificado
na OACE?
Parcialmente
A-24 Reliability & Availability A-24 Confiabilidade e Disponibilidade ---
A-24.1 Is the architecture,
design, and code sufficient to
address maintainability issues?
A-24.1 É a arquitetura, design e código
suficiente para tratar de questões de
manutenibilidade?
Sim
A-24.2 Are maintainability
people involved early in the
design?
A-24.2 As pessoas estão envolvidos no
inicio da manutenibilidade do projeto?
Sim
A-24.3 Does the product
documentation allow
maintenance by an organization
other than the developer?
A-24.3 A documentação do produto
permite a manutenção por uma outra
organização que não o desenvolvedor?
Sim
A-24.4 Does the design meet the
open systems criteria as
specified in the OACE?
A-24.4 O design satisfaz a concepção dos
critérios de sistemas abertos, tal como
especificado na OACE
Parcialmente
A-25 Safety A-25 Segurança ---
A-25.1 Are safety requirements
addressed in the design and
allocated to the software where
applicable?
A-25.1 Os requisitos de segurança
abordados no projetos e alocados para o
software são aplicáveis ?
Sim
A-25.2 Are safety requirements
completely specified in the
A-25.2 Os requisitos de segurança estão
completamente especificados nos
Sim
52
requirements and included in test
plans?
requisitos e incluídos nos planos de teste?
A-25.3 Is the integration facility
suitable for and capable of
testing safety requirements?
A-25.3 A facilidade de integração é
adequada e capaz para o testes de
requisitos de segurança?
Sim
A-26 Security A-26 Segurança ---
A-26.1 Are security
requirements for this system
addressed in the design and
allocated to the software?
A-26.1 Os requisitos de segurança para
este sistema foram abordados no projeto e
alocados para o software?
Sim
A-26.2 Are the security
requirements built into the test
plan and procedures?
A-26.2 Os requisitos de segurança foram
incorporados ao plano de teste e
procedimentos?
Sim
A-26.3 Is the integration facility
suitable for and capable of
testing security issues
A-26.3 A facilidade de integração esta
adequada e capaz de testar problemas de
segurança?
Sim
A-27 Human Factors A-27 Fatores Humanos ---
A-27.1 Is a human factors
engineer involved in the design?
A-27.1 Existe um engenheiro de fatores
humanos envolvido no projeto?
Sim
A-27.2 Does the design ensure
the system displays operator
information in an understandable
manner?
A-27.2 O projeto garante que o sistema
exibe informações de operação de uma
forma compreensível?
Parcialmente
A-27.3 Are actual users and/or
operators to participate in the
integration and test?
A-27.3 Os atuais usuários e/ou
operacores paticipam na integração e
teste?
Sim
A-27.4 Is operator and user A-27.4 Existe uma operação e Sim
53
documentation available for test
and integration?
documentação do usuário disponível para
teste e integração?
A-27.5 If operator
documentation is not complete
are valid interim versions
available?
A-27.5 Se a documentação não está
completa, existem operações para versões
provisórias disponíveis?
Não
A-27.6 Does the user/operator
documentation revision process
comply with change control
procedures?
A-27.6 O usuário/operador de processo
de revisão de documentação está em
conformidade com os procedimentos de
controle de mudanças?
Parcialmente
A-28 Specifications A-28 Especificações ---
A-28.1 Is the software
requirements specification
adequate to design the system?
A-28.1 A especificação de requisitos de
software está adequada para projetar o
sistema?
Sim
A-28.2 Is the hardware
specification adequate to design
and implement the software?
A-28.2 A especificação de hardware está
adequada para conceber e implementar o
software?
Sim
A-28.3 Are the design
specifications adequate to
implement the system?
A-28.3 As especificações de projeto estão
adequadas para implementar o sistema?
Sim
A-28.4 Are the external interface
requirements specified in
sufficient detail to implement the
system?
A-28.4 Os requisitos de interface externa
estão especificados com detalhe
suficiente para implementar o sistema?
Sim
A-28.5 Are the test
specifications adequate to fully
test the system?
A-28.5 As especificações de testes estão
adequadas para testar completamente o
sistema?
Sim
A-28.6 Do the specifications A-28.6 As espcificações identificam Parcialmente
54
identify all applicable open
systems requirements?
todos os requisitos de sistema aberto?
A-6.0 Development Process A-6.0 Processo de Desenvolvimento ---
A-29 Formality A-29 Formalidade ---
A-29.1 Is there an overall
development plan that is
available to the entire
development team?
A-29.1 Existe uma plano de
desenvolvimento global que está
disponível para toda a equipe de
desenvolvimento?
Sim
A-29.2 Is only one development
model (e.g., spiral, waterfall,
incremental) being used?
A-29.2 Está sendo usado um único
modelo de desenvolvimento(Por
Exemplo, em espiral, cachoeira,
imcremental)?
Sim
A-29.3 If a combination of
models is being used, is there a
formal plan for coordination
between them?
A-29.3 Se uma combinação de modelos
está sendo usada, existe um plano formal
de coordenação entre eles?
Parcialmente
A-29.4 Are there formal,
conFiguration controlled plans
for all development activities?
A-29.4 As configurações de controle de
planos para todas as atividades de
desenvolvimento são formais?
Sim
A-29.5 Are the plans reviewed
and updated as appropriate to
show changed direction at each
level?
A-29.5 Os planos estão revistos e
atualizados conforme apropriado para
mostrar a direção a mudança em cada
nível?
Parcialmente
A-30 Process Control A-20 Controle de Processo ---
A-30.1 Is the development
process for this project based on
prior experience?
A-30.1 Existe um processo de
desenvolvimento para este projeto com
base na experiência anterior?
Sim
55
A-30.2 Is the development
process supported by a
compatible set of procedures,
methods and tools?
A-30.2 Existe um processo de
desenvolvimento apoiado por um
conjunto compátivel de procedimentos,
métodos e ferramentas?
Sim
A-30.3 Is there a documented
process to ensure that all
personnel follow the
development procedures?
A-30.3 Existe um processo documentado
para assegurar que todo o pessoal segue
os procedimentos de desenvolvimento?
Sim
A-30.4 Are there regular reviews
to ensure that the development
process is meeting productivity
and quality goals?
A-30.4 As revisões regulares para
assegurar que o processo de
desenvolvimento estão cumprindo metas
de qualidade e produtividade?
Parcialmente
A-30.5 If necessary is there
adequate coordination among
distributed development sites?
A-30.5 Se necessário, há uma
coordenação adequada entre os locais de
desenvolvimento distribuídos?
Não Aplicável
A-31 Product Control A-31 Controle de Produto ---
A-31.1 Is there a requirements
traceability mechanism that
tracks requirements from the
source specification through test
cases?
A-31.1 Existe um mecanismo de
rastreabilidade de requisitos que rastreia
os requisitos da especificação da fonte
por meio de casos de teste?
Parcialmente
A-31.2 Is the traceability
mechanism used in analyzing
and evaluating requirements
change impact?
A-31.2 Existe um mecanismo de
rastreabilidade utilizado na análise e
avaliação das necessidades de impacto da
mudança?
Sim
A-31.3 Is there a formal change
control process that goes to the
lowest levels necessary?
A-31.3 Existe um processo formal de
controle de mudança que vai para os
níveis mais baixos se necessário?
Parcialmente
56
A-31.4 Does change control
cover all changes to baselined
requirements, design, code, and
documentation?
A-31.4 O controle de mudança controla
todas a baseline de mudanças de
requisitos, design, código e
documentação?
Sim
A-31.5 Are changes at any level
mapped up to the system level
and down through the test level?
A-31.5 As mundanças estão mapeadas até
o nível mais alto e mais baixo através de
testes?
Parcialmente
A-31.6 Is there a process to
ensure an adequate analysis
when new requirements must be
added to the system?
A-31.6 Existe um processo para garantir
uma análise adequada para novos
requirimentos a serem adicionados ao
sistema?
Parcialmente
A-31.7 Is there a mechanism to
track changes to both internal
and external interfaces?
A-31.7 Existe um mecanismo para
controlar alterações em ambas as
interfaces internas e externas?
Sim
A-31.8 Are the test plans and
procedures updated as part of the
change process?
A-31.8 Os planos de teste e
procedimentos estão atualizados como
parte do processo de mudança?
Sim
A-7.0 Development System A-7.0 Sistema de desenvolvimento ---
A-32 Capacity A-32 Capacidade ---
A-32.1 Are there enough
workstations and processing
capacity to support all the
development staff?
A-32.1 Há estações de trabalho
suficientes e capacidade de
processamento para suportar toda a
equipe de desenvolvimento?
Sim
A-32.2 Is there sufficient
resource capacity to support
overlapping phases, such as
coding, integration and test if
necessary?
A-32.2 Existe capacidade de recursos
suficientes para suportar as fases que se
sobrepoêm, como codificação, integração
e teste se necessário?
Sim
57
A-32.3 Does the development
system infrastructure support all
aspects of the project?
A-32.3 A infra-estrutura de sistema de
desenvolvimento suporta todos os
aspectos do projeto?
Sim
A-33 Usability A-33 Usabilidade ---
A-33.1 Is the development
system accessible and easy to
use, and does it provide
necessary tools?
A-33.1 O sistema de desenvolvimento
está acessível e fácil de usar, e é provido
de ferramentas necessárias?
Sim
A-33.2 Is there complete, easily
accessed documentation of the
development system?
A-33.2 Existe uma documentação
completa, de fácil acesso do sistema de
desenvolvimento?
Sim
A-33.3 Are the tools and
methods familiar to the
development team?
A-33.3 As ferramentas e métodos são
familiares á equipe de desenvolvimento?
Parcialmente
A-34 System Support A-34 Suporte ao sistema ---
A-34.1 Is the development
system considered reliable?
A-34.1 O sistema de desenvolvimento é
considerado confiável?
Sim
A-34.2 Are the people trained in
use of the development tools?
A-34.2 As pessoas estão treinadas no uso
das ferramentas de desenvolvimento?
Sim
A-34.3 Is there available, easily
accessible expertise in use of the
development system?
A-34.3 Existe disponibilidade e fácil
acessibilidade em uso do sistema de
desenvolvimento?
Sim
A-34.4 Are the development
system vendors able and willing
to respond to problems rapidly?
A-34.4 Os desenvolvedores do sistema
são capazes e dispostos a responder
problemas rapidamente?
Sim
A-35 Deliverability A-35 Entregabilidade ---
58
A-35.1 If the development
system is a deliverable, is its
content described in the project
plan?
A-35.1 Se o sistema de desenvolvimento
é um produto, existe um contéudo seu
descrito no plano de projeto?
Sim
A-35.2 If the development
system is a deliverable, is there
adequate budget, schedule, and
resources allocated for it?
A-35.2 Se o sistema de desenvolvimento
é um produto, existe um orçamento
adequado, cronograma e recursos
alocados para ele?
Sim
A-8.0 Management Process A-8.0 Processo de Gestão ---
A-36 Planning A-36 Planejamento ---
A-36.1 Is the project managed
according to the development
plan?
A-36.1 O projeto é gerido de acordo com
o plano de desenvolvimento?
Sim
A-36.2 Is re-planning done when
disruptions occur that affect cost
or schedule?
A-36.2 O re-planejamento é feito quando
ocorrem interrupções que afetam o custo
da agenda?
Sim
A-36.3 Is the workforce stable
and not impacted by outside
work activities?
A-36.3 As força de trabalho é estável e
não é impactada por atividades de
trabalho fora?
Sim
A-36.4 Are people at all levels
included in the planning of their
own work?
A-36.4 As pessoas estão em todos os
níveis incluidas no planejamento de seu
próprio trabalho?
Sim
A-36.5 Are there contingency
plans for known potential
problems?
A-36.5 Existem planos de contingência
para os problema em potenciais
conhecidos?
Sim
A-36.6 Are there established
criteria to determine when to
activate these contingency
A-36.6 Foram estabelecidos critérios para
determiar quanto ativar esses planos d
Sim
59
plans? contigência?
A-36.7 Are long term issues
adequately addressed by
management?
A-36.7 As questões de longo prazo são
adequadamente gerenciadas?
Sim
A-37 Project Organization A-37 Organização do Projeto ---
A-37.1 Has the project
organization been reviewed by
an outside activity to determine
effectiveness?
A-37.1 A organização do projeto foi
revista por uma atividade para determinar
sua eficácia?
Não
A-37.2 Do people understand
their own and others' roles in the
project?
A-37.2 As pessoas se entendem e
entendem os outros papéis no projeto?
Sim
A-37.3 Do people know who has
authority for what?
A-37.3 As pessoas conhecem quem tem
autoridade sobre o que?
Sim
A-38 Management Interfaces A-38 Interfaces de gerenciamento ---
A-38.1 Does the project have
experienced managers for
software management?
A-38.1 O projeto teve experiência com
gerenciamento de gestão de software?
Sim
A-38.2 Does project
management communicate
problems up and down the line?
A-38.2 O gerenciamento de projetos
comunica problemas na linha cima e
baixo?
Sim
A-38.3 Are issues with the
customer documented and
resolved in a timely manner?
A-38.3 Problemas com o cliente são
documentados e resolvidos em tempo
hábil?
Parcialmente
A-38.4 Does management
involve appropriate project
members (e.g., technical leaders,
A-38.4 A gerência envolvem membros do
projetos de forma adequada(por exemplo,
líderes técnicos, designers,
Sim
60
designers, programmers) in
customer meetings when
appropriate?
programadores) em reuniões com os
clientes quando apropriado?
A-38.5 Does management work
to ensure that all organizational
elements are aware of decisions
regarding system functionality
and operation?
A-38.5 A administração trabalha para
garantir que todos os elementos
organizacionais das decições sobre a
funcionalidade do sistema e operação?
Sim
A-38.6 Is it required practice to
present a realistic or
conservative status picture to
senior management and the
customer?
A-38.6 É necessária a prática de
apresentar uma imagem de status realista
ou conservadora para a gerência sênior e
o cliente?
Sim
A-9.0 Management Methods A-9.0 Métodos de Gestão ---
A-39 Monitoring A-39 Monitoramento ---
A-39.1 Is there a firm
requirement for periodic,
structured status reports from the
development team?
A-39.1 Existe uma exigência firme para
peródicos, relatórios de status
estruturadas a partir da equipe de
desenvolvimento?
Parcialmente
A-39.2 Is there a policy to
respond to status reports?
A-39.2 Existe uma política para
responder a relatórios de status?
Sim
A-39.3 Does appropriate
information get reported to the
right organizational levels?
A-39.3 A informação adequada é
reportada para os níveis certos da
organização?
Sim
A-39.4 Is actual progress tracked
versus the plan?
A-39.4 O progresso real é monitorado em
relação ao plano?
Sim
A-39.5 Does management
require reports that give a clear
A-39.5 A gerência exige relatórios que
dão uma imagem clara do progresso do
Sim
61
picture of project progress and
issues?
projeto e as questões?
A-39.6 Are meeting agendas and
meeting minutes posted for
access by the project team?
A-39.6 As agendas de reuniôes e atas de
reuniões são publicadas para acesso pela
equipe do projeto?
Sim
A-39.7 Does an action item
tracking system exist and is it
visible to the team?
A-39.7 As ações de rastreamento de itens
do sistema é visível para a equipe?
Sim
A-39.8 Is there a repository of
informal technical notes and
correspondence and is it
available to the team?
A-39.8 Existe um repositório de notações
informais de técnicas e correspondência e
está disponível para a equipe?
Parcialmente
A-40 Personnel Management A-40 Gestão de pessoas ---
A-40.1 Is it part of the project
plan (including cost and
schedule) to train the staff in
skills required for the project?
A-40.1 Existe parte do plano do projeto
(Incluindo o custo e cronograma) para
formar o pessoal em habilidades
necessárias para o projeto?
Sim
A-40.2 Are there experience
profiles for various areas of the
work effort?
A-40.2 Eles já experimentarão perfirs
para diversas áreas do esforço de
trabalho?
Não
A-40.3 Are people assigned to
project work areas only if they
match the requisite experience
profile?
A-40.3 As pessoas aceitam o projeto de
trabalho apenas se corresponder ao perfil
de experiência necessária?
Parcialmente
A-40.4 Is it easy for people to
get access to management when
necessary for project decisions?
A-40.4 É fácil para as pessoas a ter
acesso á gestão quando necessário para as
decisões do projeto?
Parcialmente
A-40.5 Are project team A-40.5 Os membros da equipe do projeto Sim
62
members at all levels aware of
their status versus plan?
em todos os níveis são conscientes do seu
estado versos o plano?
A-40.6 Is the team briefed on
and do they know the
importance of keeping to the
plan?
A-40.6 A equipe é informada sobre a
importância de manter seus planos?
Sim
A-40.7 Does management
inform the staff when important
decisions are made affecting
their work?
A-40.7 A gerência informa quando
decisões importantes são tomadas
afetando seu trabalho?
Sim
A-40.8 Are people encouraged
to work cooperatively across
functional boundaries and
toward common goals?
A-40.8 As pessoas são incentivadas a
trabalhar em cooperação além das
fronteiras funcionários e em direção a
objetivos comuns?
Sim
A-40.9 Is there a specific
process to obtain team inputs
and evaluate team morale?
A-40.9 Existe um processo específico de
obtenção de insumos da equipe e
avaliação da moral da equipe?
Não
A-40.10 Are impediments to
high morale promptly identified
and corrected?
A-40.10 Impedimentos para o alto moral
são prontamento identificados e
corrigidos?
Sim
A-41 Communication A-41 Comunicação ---
A-41.1 Are there formal
communication paths used
among the project team
members?
A-41.1 Há caminhos formais de
comunicação utilizados entre os membros
da equipe do projeto?
Sim
A-41.2 Is there a formal
communication path between
management and the project
A-41.2 Existe um caminho de
comunicação formal entre a
administração e a equipe do projeto?
Sim
63
staff?
A-41.3 Does staff feel free to
ask management for help?
A-41.3 O pessoal não hesita em perguntar
para pedir ajuda?
Sim
A-41.4 Are team members able
to raise risk issues without
having a solution in hand?
A-41.4 Os membros da equipe são
capazes de levantar questões de risco sem
ter uma solução na mão?
Sim
A-41.5 Do the project members
get timely, formal notification of
events which may affect their
work?
A-41.5 Os membros do projeto obtem
notificações em tempo, formal de eventos
que podem afetar o seu trabalho?
Sim
A-42 Quality Assurance A-42 Garantia da qualidade ---
A-42.1 Are there well-defined
and documented mechanisms in
the project plan for quality
assurance?
A-42.1 Existem mecanismos bem
definidos e documentados no plano de
projeto para a garantia de qualidade?
Sim
A-42.2 Is the project's Software
Quality Assurance function
adequately staffed?
A-42.2 O projeto de software tem a
função de garantia da qualidade com
pessoal adequado?
Sim
A-42.3 Are all project areas and
phases covered by the quality
procedures?
A-42.3 Todas as áreas e fases do projeto
estão sido abrangidas pelos
procedimentos de qualidade?
Sim
A-42.3 Has the staff been trained
and oriented toward quality
procedures?
A-42.3 Será que o pessoal foi treinado e
orientado para os procedimentos de
qualidade?
Sim
A-42.4 Is the entire project team
briefed on and required to work
with the quality procedures?
A-42.4 A equipe de projeto está
interiamente informada sobre a
necessidade a trabalhar com os
procedimentos de qualidade?
Sim
64
A-42.5 Do quality issues have
priority over schedule?
A-42.5 As questões da qualidade têm
prioridade sobre programação?
Sim
A-43 ConFiguration
Management
A-43 Gerenciamento de Configuração ---
A-43.1 Is there a formal
ConFiguration Management
(CM) system for the project?
A-43.1 Existe um compromisso formal
do sistema de configuração de mudanças
(CM) para o projeto?
Parcialmente
A-43.2 Have the CM Plan and
the processes been reviewed by
an independent agent?
A-43.2 Já o plano CM e os processos
foram revistos por um agente
independente?
Não aplicável
A-43.3 Is the conFiguration
management function adequately
staffed?
A-43.3 Existe a pessoal com a função de
gerenciamento de configuração?
Não
A-43.4 If development is taking
place at multiple sites does the
conFiguration management
system coordinate remote site
changes?
A-43.4 Se o desenvolvimento está
ocorrendo em vários sites, o sistema de
gerenciamento de configuração coordena
as alterações locais e remotos?
Não aplicável
A-43.5 If there are multiple
installation sites, does the
conFiguration management
system provide for them?
A-43.5 Existem vários locais de
instalação que o sistema de
gerenciamento de configuração fornece
para eles?
Não aplicável
A-43.6 Does the conFiguration
management system synchronize
all work with site changes?
A-43.6 O sistema de gerenciamento de
configuração sincroniza todo o trabalho
com as mudanças do site?
Sim
A-10.0 Resources A-10.0 Recursos ---
A-44 Schedule A-44 Programação ---
65
A-44.1 Is the schedule based on
a realistic estimate or proven
tools?
A-44.1 A programação está baseada em
uma estimativa realista ou ferramentas
comprovadas?
Sim
A-44.2 Is the estimation method
based on or checked against
historical data?
A-44.2 O método de estimativa foi
baseado ou verificado com dados
históricos?
Sim
A-44.3 Is the estimating method
proven to have worked well for
this type and size of project?
A-44.3 Existe um método de estimativa
comprovada de ter trabalhado bem para
este tipo e tamanho do projeto?
Parcialmente
A-44.4 Has the schedule been
reviewed for realism by an
independent agent?
A-44.4 Existe um cronograma revisto
para o realismo por um agente
independente ?
Não
A-44.5 Does schedule planning
account for external as well as
internal events?
A-44.5 O planejamento de calendário de
eventos externos bem como internos são
levados em contas ?
Sim
A-44.6 Is the schedule evaluated
periodically to determine
accuracy and stability?
A-44.6 A programação é avaliada
periodicamente para determinar a
precisão e estabilidade ?
Parcialmente
A-45 Budget A-45 Orçcamento ---
A-45.1 Is the budget based on a
realistic estimate or proven
tools?
A-45.1 O orçamento é baseado em uma
estimativa realista ou ferramentas
comprovadas?
Sim
A-45.2 Is the estimation method
based on or checked against
historical data?
A-45.2 Existe um método de estimativa
com base em ou verificado com os dados
históricos?
Sim
A-45.3 Has the budgeting
method worked well in the past
A-45.3 O método utilizado para o
orçamento funcionou bem no passado
Sim
66
for this type and size of project? para esse tipo e tamanho de projeto?
A-45.4 Has the budget been
reviewed for realism and
accuracy by an independent
agent?
A-45.4 O orçamento foi revisto para o
realismo e precisão por um agente
independente?
Não aplicável
A-45.5 Are adequate budget
allocations provided throughout
the program ?
A-45.5 Os orçamentos adotados, foram
adequados para todo o programa?
Sim
A-45.6 Do budget changes
accompany requirement
changes?
A-45.6 As alterações orçamentais
acompanharam as mudanças de
requisitos?
Sim
A-45.7 Is there a budget review
response as a standard part of the
change control process?
A-45.7 Existe uma resposta de revisão de
orçamento como parte normal do
processo de controle de mudanças?
Sim
A-45.8 Is the budget evaluated
periodically by a systematic
process (e.g., EVMS)?
A-45.8 O orçamento foi avaliado
periodicamente por um processo
sistemático(por exemplo, EVMS)?
Não aplicável
A-46 Staff A-46 Pessoal ---
A-46.1 Are there adequate
personnel to staff the program?
A-46.1 Há pessoal suficiente para o
exigencia do programa?
Sim
A-46.2 Are required skills
adequately staffed in all areas?
A-46.2 São necessárias habilidades com
pessoal adequado em todas as áreas?
Parcialmente
A-46.3 Is the staffing level
evaluated periodically to ensure
adequacy and stability?
A-46.3 O nível do pessoal é avaliado
periodicamente para garantir a adequação
e estabilidade?
Sim
A-46.4 Does the project have
access to correctly experienced
A-46.4 O projeto tem acesso as pessoas
corretamente experientes quando
Sim
67
people when needed? necessário?
A-46.5 Have > 60% of program
members implemented other
systems of this type, size, and
complexity?
A-46.5 Tenho > 60% dos membros do
programa implementado em outros
sistemas deste tipo, tamanho,
complexidade ?
Não
A-46.6 Is there back-up staff
available to substitute for key
project people?
A-46.6 Existe back-up de pessoal
disponível para substituir as pessoas
chave do projeto?
Não
A-46.7 Are adequate levels of
cleared people available?
A-46.7 Os níveis apurados de pessoas são
disponíveis?
Sim
A-47 Facilities A-47 Instalações ---
A-47.1 Are the development
work facilities adequate?
A-47.1 As instalações de trabalho de
desenvolvimento são adequadas?
Sim
A-47.2 Are test facilities
adequate for all planned tests?
A-47.2 As instalações de teste são
adequadas para todos os testes
planejados?
Parcialmente
A-47.3 Is the integration
environment adequate to
complete all integration steps?
A-47.3 O ambiente de integração é
adequado para completar todas as etapas
de integração?
Sim
A-11.0 Contract A-11.0 Contrato ---
A-48 Type of Contract A-48 Tipo de contrato ---
A-48.1 Is the contract type
appropriate to the program in all
respects?
A-48.1 O tipo de contrato é adequado ao
programa em todos os aspectos?
Sim
A-48.2 Are the required
customer furnished
documentation and resources
A-48.2 O cliente exigido mobilado tem
documentação e recursos adequados?
Parcialmente
68
suitable?
A-49 Restrictions A-49 Restrições ---
A-49.1 Are data rights provided
for properly?
A-49.1 Os direitos de dados são previsto
corretamente?
Sim
A-50 Dependencies A-50 Dependências ---
A-50.1 Are dependencies on
external products or services
which can adversely affect the
product, budget, or schedule
avoided as much as possible?
A-50.1 As dependências de produtos ou
serviços externos que podem afetar o
produto, tem orçamento ou agenda
evitado quando possível?
Sim
A-50.2 Are there contingency
plans in the event that external
products or services are not
available as needed?
A-50.2 Existem planos de contingência
no caso de produtos ou serviços externos
que não estejam disponíveis quando
necessários?
Sim
A-12.0 Program Interfaces A-12.0 Interfaces de programas ---
A-51 Customer A-51 Cliente ---
A-51.1 Is customer interaction
for decisions and approvals a
formally defined process?
A-51.1 A interação com o cliente para as
decições e aprovações de um processo foi
formalmente definida?
Sim
A-51.2 Is the customer approval
cycle timely?
A-51.2 O ciclo de aprovação do cliente
foi feito a tempo?
Sim
A-51.3 Are there policies in
place to proceed if customer
approval is not received on
time?
A-51.3 Existem políticas em lugar de
proceder a aprovação do cliente se não
for recebido a tempo?
Sim
A-51.4 Does the customer
understand the technical aspects
A-51.4 O cliente entende bem os aspectos
técnicos o suficiente para responder-los
Parcialmente
69
of the system well enough to
respond as necessary?
quando necessário?
A-51.5 Does project
management present a realistic
or conservative picture to the
customer?
A-51.5 O gerenciamento de projetos
apresentam um quadro realista ou
conservadora para o cliente?
Parcialmente
A-51.6 Does the customer avoid
interfering with processes or
people?
A-51.6 O cliente interage com os
processos ou as pessoas?
Sim
A-51.7 Does management work
with the customer to reach
mutually agreeable decisions
(e.g., requirements, test,
schedule) in a timely manner?
A-51.7 O trabalho de gerenciamento com
o cliente para alcançar decições são
mutuamente aceitáveis(por exemplo,
requisitos, cronograma de teste) em
tempo hábil?
Sim
A-51.8 Are mechanisms for
reaching agreements with the
customer evaluated periodically
for effectiveness?
A-51.8 Existem mecanismos para chegar
a acordos com o cliente avaliados
periodicamente para a eficácia?
Sim
A-51.9 Are all appropriate and
required customer personnel
involved in reaching
agreements?
A-51.9 Todos os funcionários dos cliente
apropriados e necessários são envolvidos
em chegar a acordos?
Sim
A-52 Associate Contractors A-52 Empreiteiros associados ---
A-52.1 Do external system
interfaces change only after
adequate notification,
coordination, or formal change
procedures with team ?
A-52.1 Interfaces de sistemas externos
são alteradas somente após notificação
adequada da coordenação ou
procedimentos de mudança formal com a
equipe ?
Sim
70
A-52.2 Is there an adequate
transition plan for incorporating
team member products?
A-52.2 Existe um plano de transição
adequado para a incorporação de
produtos de membros da equipe?
Sim
A-52.3 Is the transition
supported by all contractor and
site personnel?
A-52.3 A transição foi apoiada por todos
contrantes e pessoal do site?
Sim
A-52.4 Is there a contractual
requirement for the project
manager to get schedules and
interface data from team
member contractors?
A-52.4 Existe uma exigência contratual
para o gerente de projeto para obter
horários e interface de dados de
contratantes dos membros da equipe?
Sim
A-52.5 Is there a process to
review associate contractor data
for accuracy?
A-52.5 Existe um processo para analisar
dados associados ao contrante com
precisão?
Parcialmente
A-53 Subcontractors A-53 Sub-empreiteiros ---
A-53.1 Is there a formal process
to task subcontractors?
A-53.1 Existe um processo formal aos
subcontratantes de tarefas?
Sim
A-53.2 Are ambiguities in
subcontractor task definitions
resolved in a timely manner?
A-53.2 As ambiguidades nas definições
de tarefas ao subcontrante foram
resolvidas em tempo hábil?
Sim
A-53.3 Are subcontractor
reporting and monitoring
procedures compatible with
project reporting requirements?
A-53.3 Existem relatório de
monitoramento de subcontrantes dos
procedimentos compatíveis com os
requisitos de informação do projeto?
Sim
A-53.4 Are subcontractor
administration and technical
management done by the same
organization?
A-53.4 A adminstração do subcontratante
e gestão técnica foi feita pela mesma
organização?
Sim
71
A-53.5 Is the project
independent of subcontractor
expertise in critical areas?
A-53.5 O projeto é independente da
experiência subcontratante em áreas
críticas?
Sim
A-53.6 Is there a formal process
to transfer subcontractor
knowledge to the project?
A-53.6 Existe um processo formal para
transferir conhecimento subcontratante
para o projeto?
Sim
A-53.7 Is there a formal process
to relay to and obtain from
subcontractors necessary
schedules and interface data?
A-53.7 Existe um processo formal de
transmitir e obter horários de
subcontratados e dados necessários da
interface?
Sim
A-53.8 Are task definitions from
the prime to subcontractor clear
and well understood?
A-53.8 Existe um processo formal para
transmitir e obter defnições de tarefas
claras do sobcontratado?
Sim
A-53.9 Do the subcontractor
tasks avoid dependency on the
prime for administration and
technical management?
A-53.9 As tarefas dos subcontratantes
envitam dependência da adminstração
principal e gestão técnica?
Sim
A-54 Corporate Managemente A-54 Gestão empresarial ---
A-54.1 Does project
management effectively
communicate problems to senior
management?
A-54.1 O gerenciamento de projetos tem
uma comunicação com eficácia de
problemas para a gerência sênior?
Sim
A-54.2 Does project
management present a realistic
and conservative picture to
senior management?
A-54.2 O gerenciamento de projetos
apresentam um quadro realista e
conservador para a gerência sênior?
Sim
A-54.3 Does corporate
management give timely support
A-54.3 A gestão empresarial tem suporte
em tempo hábil na resolução de
Parcialmente
72
in solving problems? problemas?
A-54.4 Does corporate
management avoid micro-
management?
A-54.4 A gestão coorportativa evita
micro-gestão?
Sim
A-54.5 Does project
management present a realistic
or conservative picture to senior
management?
A-54.5 O gerenciamento de projetos
apresentam um quadro realista ou
conservadora para a gerência sênior?
Não aplicável
A-13.0 Quality Methods A-13.0 Métodos de qualidade ---
A-55 Requirements A-55 Requisitos ---
A-55.1 Are all non-applicable
requirements deleted from the
specifications and SOW?
A-55.1 Todos os requisitos não aplicáveis
são excluidos das especificações e
disseminados?
Sim
A-55.2 Are software coding
standards defined to include
format, naming, and presentation
style?
A-55.2 O sobtware de codificação tem
padrões definidos para incluir formato,
nomes, e estilo de apresentação?
Sim
A-55.3 Is there a process to
update documentation, code,
testing, and software
development files based on test
results?
A-55.3 Existe um processo para atualizar
a documentação, código, testes,e arquivos
de desenvolvimento de software com
base nos resultados do teste?
Parcialmente
A-55.4 Is there documentation to
provide transition plans for
customer regeneration of code
using available (or delivered)
support software and hardware?
A-55.4 Existe uma documentação para
fornecer planos de transição para a
regeneração de código usando o software
de suporte disponível(ou entregues) e
hardware?
Sim
A-55.5 Does the Software A-55.5 A biblioteca de desenvolvimento Sim
73
Development Library contain
the software, documentation,
tools, and procedures necessary
for proper software development
and subsequent support?
de software contém o software,
documentação, ferramentas e
procedimentos necessários para o
desenvolvimento de software adequado e
apoio subsequente?
A-55.6 Is the source code for
each successfully tested and
evaluated software unit placed
under conFiguration control?
A-55.6 O código fonte para cada unidade
de software testado e avaliado com
sucesso é colocado sob controle de
configuração?
Sim
A-56 Verification A-56 Verificação ---
A-56.1 Are Final Qualification
Test plans documented in the
Software Test Plan (STP) and
conducted by independent
activities?
A-56.1 Os planos de teste final de
qualificação são documentadas no plano
de teste do software (STP) e conduzido
por atividaddes indendentes?
Sim
A-56.2 Does the corrective
action process contain
documentation of a closed-loop
system that includes problem
reports as inputs and trend
analyses?
A-56.2 O processo de ação corretiva
contém, documentação de um sistema de
loop fechado que inclui os relatórios de
problemas como entradas e análises de
tendências?
Sim
A-56.3 Are problem reports
classified by category (i.e.,
software, documentation, or
design) and priority?
A-56.3 Os relatórios de problemas são
classificados por categoria (isto é,
software, documentação ou design) e
prioridade?
Sim
A-56.4 Is Formal Qualification
Testing conducted to specified
limits for each CSCI?
A-56.4 O teste de qualificação formal foi
conduzido aos limites especificados para
cada CSCI?
Sim
A-56.5 Are deliverable products A-56.5 Os produtos disponvíveis foram Sim
74
evaluated using formal, defined
criteria?
avaliados e utilizaram critérios formais e
definidos?
A-56.6 Does each version of the
deliverable software include and
identify all changes since the
previous release?
A-56.6 A cada versão de software a ser
entregue, inclui e identifica todas as
mudanças desde a versão anterior?
Parcialmente
A-57 Controls A-57 Controles ---
A-57.1 Does the Software
Quality Plan define the resources
and skills necessary to
implement software quality?
A-57.1 O plano de qualidade de software
define os recursos e competências
necessárias para implementar a qualidade
do software?
Sim
A-57.2 Prior to its intended use,
does objective evidence exist
that each deliverable software
item performs its required
functions?
A-57.2 Antes da sua utilização
pretendida, não existem evidências
objetivas de que cada item de software
disponível desempanha suas funções
necessárias?
Não
A-57.3 Are corrective actions
evaluated to verify that
appropriate results are achieved?
A-57.3 As ações corretivas são avaliadas
para verificar se os resultados
apropriados foram alcançados?
Sim