Questão 770548

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2012
• Provas: CESPE - 2012 - Banco da Amazônia - Técnico Científico - Governança em TI
• Disciplina: Governança de TI
• Assuntos: ITIL; ITIL v. 3

Julgue os próximos itens, referentes ao gerenciamento de serviços
(ITIL versão 3).

Em uma organização com grau de maturidade alto é esperado que o número de problemas seja igual ou superior ao número de incidentes e, da mesma forma, é esperado que a quantidade de pacotes de release seja maior que o número de problemas.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Segundo a definição da Itil, os problemas sao a causa de um ou mais incidentes. Logo, o numero de incidentes nunca pode ser inferior ao numero de problemas. Podemos ter 1000 registros de incidentes, e apenas um problema.
  Quanto a segunda afirmativa da questao, não sei justificar. Alguem pode ajudar??
• A segunda parte da questão parece ter sido incluída apenas para confundir, pois não faz sentido. O Gerenciamento da Liberação e Entrega (release and deployment) é um processo do volume Transição do Serviço. A quantidade de releases ser maior que o número de problemas pode ser um bom indicador de qualidade. Isso pode ser deduzido facilmente, pois indica releases derivados de manutenções aditivas e não corretivas, mas não encontrei nenhuma documentação falando a respeito.
• Dentre os diversos processos de negócio tratados pelo ITIL, existem dois, que apesar de parecerem semelhantes, tem objetivos diferentes: Gerenciamento de Incidentes e Gerenciamento de Problemas.
  O Gerenciamento de Incidentes têm por objetivo restaurar a operação normal do serviço o mais rápido possível e garantir, desta forma, os melhores níveis de qualidade e disponibilidade do serviço.
  O Gerenciamento de Problemas tem por objetivo identificar e remover erros do ambiente de TI, através da busca da causa raiz dos incidentes registrados no Gerenciamento de Incidentes, a fim de garantir uma estabilidade máxima dos serviços de TI.
  Segundo o ITIL, incidente é qualquer evento que não faz parte da operação padrão de um serviço e que causa, ou pode causar, uma interrupção do serviço ou uma redução da sua qualidade; enquantoproblema é a causa desconhecida de um ou mais incidentes, ou seja, um incidente que não tem sua causa raiz identificada acaba se tornando um problema.
• Roger,
  
   entendi sua explicação que o número de problemas é sempre inferior ao de incidentes. No entanto, um problema pode ser encontrado preventivamente sem que tenha havido um incidente, certo? Nesse caso, se muitos problemas forem encontrados e nenhum incidente for aberto, o número de problemas será maior. Faz sentido? Abs.
• Faz sentido o que o Gabriel Montesinos disse! Entretanto isso não é o esperado em uma organização com alto grau de maturidade.
• Boa noite,
  Em uma organizacao com alto grau de maturidade, a tendencia é o numero de problemas ser baixo, uma vez que eles serao atacados e resolvidos. Já os incidentes sao altos em qualquer organizacao, com qualquer grau de maturidade, uma vez que os incidentes sao decorrentes, entre outras coisas, de sistemas que podem falhar e de hardware que falha, além do proprio treinamento dos usuarios.
  Obrigado.
  
• Problemas são falhas de infraestrutura e/ou projeto e/ou procedimento, que podem vir a gerar incidentes. Por exemplo, um servidor proxy mal configurado pode tirar o acesso à internet de toda a instituição e ser a causa-raiz de dezenas de reclamações ou, melhor dizendo, incidentes.
  Assim, a relação problema x incidente pode ser pensada como "um pra muitos".
  
  Uma vez que o problema é detectado e entendido, ele é "conhecido". Ser conhecido não signfica que o problema será imediatamente tratado; quando for, será feito por uma requisição de mudanças (ou um conjunto delas), que será estudada pelo CAB e, se aprovada, gera um pacote de mudanças (que varia de tamanho e impacto), uma release. Numa única release, diversos problemas problemas podem ser devidamente sanados, conforme oportunidade e conveniência da instituição.

• Roger, creio que se espera que um release resolva mais de um problema identificado, por isso, pelo que eu entendi e me recordo, o número de releases deve ser menor que o número de problemas, não tem como liberar um release para cada problema identificado, ah não ser que a organização tenha uma alta maturidade e problemas quase nunca sejam identificados, justificando assim que a cada problema haja um release, mas mais de um release para cada problema não faz sentido, exceto quando a própria instituição implementa melhorias de segurança, etc.