Pco01 Cespe 2010 Mpu Cargo25 Parteiv1

http://rogerioaraujo.wordpress.
com
Srie Provas Comentadas
Cargo 25 Analista de Desenvolvimento de Sistemas
MPU 2010
CESPE
Parte Parte IV IV PMBoK PMBoK Rogrio Arajo
http://rogerioaraujo.wordpress.com
Srie Provas Comentadas
CESPE
Cargo 25 Analista de Desenvolvimento de Sistemas
MPU 2010
Parte III ITIL Rogrio Arajo
CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas
Sumrio
O homem aquilo que ele prprio faz. Andr Malraux
PARTE I AS QUESTES OBJETIVAS DA PROVA .................................................................... 3 Captulo 1 Governana de TI .............................................................................................. 4 1.1 Conceitos .................................................................................................. 4 1.2 Escritrio de projetos ................................................................................. 4 1.3 CobiT 4.1 ................................................................................................... 4 1.4 ITIL verso 3 .............................................................................................. 5 1.5 PMBoK 4 Edio ........................................................................................ 6 1.6 CMMi ......................................................................................................... 6 1.7 MPS.BR ....................................................................................................... 7 Captulo 2 Contratao de Bens e Servios de TI ................................................................. 8 2.1 IN04 .......................................................................................................... 8 Captulo 3 Ingls ............................................................................................................... 9 Captulo 4 Desenvolvimento de Sistemas ......................................................................... 10 4.1 Lgica de programao ............................................................................ 10 4.2 Programao Orientada a Objetos ............................................................ 10 4.3 Java ......................................................................................................... 11 4.4 Linguagens e tecnologias de programao ............................................... 12 Captulo 5 Engenharia de Software ................................................................................... 14 5.1 Engenharia de requisitos .......................................................................... 14 5.2 Qualidade de Software ............................................................................. 14 5.3 Padres de Projetos ................................................................................. 15 5.4 Processo Unificado ................................................................................... 15 5.5 UML ......................................................................................................... 15 5.6 Testes de Software ................................................................................... 15 Captulo 6 Banco de Dados .............................................................................................. 17 6.1 SQL .......................................................................................................... 17 6.2 MySQL ..................................................................................................... 18 Captulo 7 Gabarito preliminar ......................................................................................... 19 PARTE II A REDAO ..................................................................................................... 20 Captulo 1 Comando da redao ...................................................................................... 21 1.1 Texto de apoio ......................................................................................... 21
Rogrio Arajo rogerioaraujo.wordpress.com 1
1.2 Itens a serem abordados .......................................................................... 21 PARTE III OS COMENTRIOS DAS QUESTES OBJETIVAS .................................................. 22 Captulo 1 Governana de TI ............................................................................................ 23 1.1 Conceitos ................................................................................................ 23 1.2 Escritrio de projetos ............................................................................... 25 1.3 CobiT 4.1 ................................................................................................. 27 1.4 ITIL verso 3 ............................................................................................ 34 1.5 PMBoK 4 Edio ...................................................................................... 39 1.6 CMMi ........................................................................................................... 1.7 MPS.BR ......................................................................................................... Captulo 2 Contratao de Bens e Servios de TI ................................................................... 2.1 IN04 ............................................................................................................ Captulo 3 Ingls ................................................................................................................. Captulo 4 Desenvolvimento de Sistemas ............................................................................. 4.1 Lgica de programao ................................................................................ 4.2 Programao Orientada a Objetos ................................................................ 4.3 Java ............................................................................................................. 4.4 Linguagens e tecnologias de programao ................................................... Captulo 5 Engenharia de Software ....................................................................................... 5.1 Engenharia de requisitos .............................................................................. 5.2 Qualidade de Software ................................................................................. 5.3 Padres de Projetos ..................................................................................... 5.4 Processo Unificado ....................................................................................... 5.5 UML ............................................................................................................. 5.6 Testes de Software ....................................................................................... Captulo 6 Banco de Dados .................................................................................................. 6.1 SQL .............................................................................................................. 6.2 MySQL ......................................................................................................... PARTE IV OS COMENTRIOS DA REDAO ......................................................................... Captulo 1 Comentrios da Redao .....................................................................................
Rogrio Arajo
rogerioaraujo.wordpress.com
PARTE I
AS QUESTES OBJETIVAS DA PROVA
Rogrio Arajo
Captulo 1
Governana de TI
A melhor maneira de melhorar o padro de vida est em melhorar o padro de pensamento. U. S. Andersen
1.1 Conceitos
Acerca de conceitos relacionados governana de tecnologia da informao (TI), julgue os itens a seguir.
61 As ferramentas GUT (gravidade, urgncia e tendncia), o Diagrama de Pareto e a Curva de

Tendncia fornecem suporte atividade do planejamento estratgico de filtrar informaes de interesse da organizao.
62 Um dos objetivos da governana de TI possibilitar o alinhamento das atividades da equipe de

TI com as prioridades das demais reas de negcios da empresa. segurana da informao so fatores que motivam o uso da governana de TI nas organizaes.
63 Os marcos de regulao, o ambiente de negcios, a transparncia da administrao e a
1.2 Escritrio de projetos para Governana de TI

Julgue os prximos itens no que se refere a escritrio de projetos para governana de TI.
64 Entre as dificuldades encontradas na implantao de um escritrio de projetos, incluem-se as 65 Um escritrio de projetos pode se implantado em qualquer tipo de estrutura organizacional
relacionadas mensurao e ao acompanhamento dos benefcios de um projeto, presso por resultados em curto prazo e definio da metodologia a ser utilizada. funcional, matricial ou por projeto e ele pode ter autoridade para supervisionar e cancelar projetos.
66 O escritrio de projetos de uma organizao tem, entre outras, as seguintes atribuies:
padronizao de processos de suporte a projetos, treinamento de pessoal, gerenciamento de recursos e elaborao do plano estratgico da organizao.
1.3 CobiT 4.1

Com relao ao modelo COBIT 4.1, julgue os itens a seguir.
67 O emprego sistemtico do COBIT como modelo de gesto da organizao pode gerar, entre
outros benefcios, a reduo dos riscos a que est exposta a organizao e a melhoria de sua imagem perante os clientes.
Rogrio Arajo
68 No modelo COBIT, o conceito de agregao de valor diz respeito proposio de valor no

tempo e garante que a TI entregue os benefcios prometidos com a otimizao de custos. recursos humanos envolvidos nesse processo.
69 A estrutura do COBIT foi idealizada para controlar, nas organizaes, os recursos de TI e os

Acerca de domnios, processos e objetivos de controle do modelo COBIT 4.1, julgue os itens subsequentes.
70 No mencionado modelo, possvel haver controles especficos vinculados a aplicaes e 71 No COBIT, um dos processos do domnio Entrega e Suporte o de assegurar conformidade
com requisitos externos.
integrados aos processos de negcio, que os suportam por meio de procedimentos relacionados, por exemplo, s interfaces do sistema.
72 No modelo em apreo, o domnio Planejamento e Organizao envolve identificao, 73 Alguns requisitos de controle genricos so aplicveis a todos os processos do COBIT, tais
como a definio e a divulgao de polticas, os procedimentos e planos relativos ao processo, e o desempenho do processo medido em relao s respectivas metas.
desenvolvimento e(ou) aquisio de solues para a execuo de sistemas de TI especficos, assim como a sua implementao e integrao junto a processos de negcio.
1.4 ITIL v3
Julgue os itens que se seguem a respeito de conceitos da ITIL v.3.
74 Estratgia de servio a publicao do ncleo da ITIL v.3 que contm orientaes acerca do
projeto e desenvolvimento dos servios e dos processos de gerenciamento de servios. Essa publicao apresenta, em detalhes, aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade, da disponibilidade e da segurana da informao.
75 No que diz respeito ao desenvolvimento da estratgia de servio na organizao, necessrio

considerar o estilo de gesto organizacional dominante na empresa, o qual pode apresentar os seguintes estgios ou nveis de maturidade: rede, diretivo, delegao, coordenao e colaborao. obteno dos resultados desejados e minimizar os custos e riscos especficos.
76 Servio a denominao dada ao meio de se entregar valor aos clientes para facilitar a 77 A orientao complementar ITIL v.3 consiste em um conjunto de publicaes que so
destinadas a adaptar a implementao e a utilizao das prticas do ncleo da ITIL para diferentes setores empresariais, tipos de empresas e plataformas tecnolgicas.
78 Entre as extenses que a ITIL v.3 traz em relao a sua verso anterior, esto estratgias de
servios para modelos de sourcing e de compartilhamento de servios e abordagens de retorno de investimento para servios. Acerca dos processos e funes da ITIL v. 3, julgue os itens subsequentes.
79 O processo de gerenciamento da continuidade de servio de TI do estgio desenho de servio
abrange um desdobramento do processo de gerenciamento da continuidade do negcio, com o objetivo de assegurar que os recursos tcnicos e os servios de TI necessrios sejam recuperados dentro de um tempo preestabelecido.
80 Monitorao e controle, gerenciamento do mainframe, gerenciamento de redes e 81 Do escopo da estratgia de servio constam os processos de gerenciamento financeiro, o de
gerenciamento do portflio de servios e o de gerenciamento da demanda.
armazenamento de dados so atividades tcnicas altamente especializadas do estgio operao de servio.
1.5 PMBoK 4 Edio

Julgue os itens que se seguem com relao 4. edio do PMBOK.
82 A estimativa anloga, tambm denominada estimativa topdown, pode ser usada para prever o
custo e o tempo de um projeto e leva em considerao informaes do histrico de projetos semelhantes e anteriores. um programa.
83 Programas so grupos de projetos relacionados e um projeto, seja ele qual for, ser parte de 84 Em uma organizao do tipo matricial forte, os gerentes de projeto tm o mais alto nvel de
autoridade e poder. Acerca de processos e reas de conhecimento da 4.a edio do PMBOK, julgue os itens seguintes.
85 A rea de conhecimento do gerenciamento do escopo do projeto abrange os seguintes
processos: coletar os requisitos, definir o escopo, desenvolver o cronograma, verificar escopo e controlar o escopo. de um para o outro reciprocamente.
86 Os grupos de processos de planejamento e de monitoramento e controle servem como entrada 87 A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo
realizar a anlise qualitativa de riscos, com o uso da atribuio de probabilidades numricas. extino.
88 As quatro possibilidades de trmino de projeto so absoro, integrao, esgotamento e 89 Os riscos desconhecidos podem representar uma ameaa ou uma oportunidade, por isso, o
gerente de projeto deve manter reserva dos seus recursos para control-los quando necessrio.
90 Opinio especializada, auditorias de aquisies, acordos negociados e sistema de

gerenciamento de registros so recursos e tcnicas empregados no processo encerrar as aquisies.
1.6 CMMi
A respeito de CMMI (capability maturity model integration), julgue os itens que se seguem.
121 Validao, verificao e integrao do produto so processos que integram a disciplina de

suporte ao processo de software.
122 O CMMI, que surgiu do esforo de integrao de diversos modelos que estavam sendo
propostos no mercado, como, por exemplo, o SW-CMM, compatvel e consistente com o previsto em norma ISO a respeito desse assunto.
123 Os nveis de maturidade do CMMI variam de 0 incompleto a 5 otimizado , que

mostram o grau de implementao dos processos da referida metodologia.
1.7 MPS.BR
Acerca de MPS.BR, julgue os itens de 124 a 128.
124 O plano de avaliao deve conter o roteiro para realizao da anlise de conformidade de um
processo de criao de software empresarial com o modelo MPS.BR; esse plano prega que nenhum dos processos envolvidos nessa criao deve estar fora do escopo de anlise para que se diagnostique o nvel de maturidade existente.
125 O nvel de maturidade C nvel definido do MPS.BR, alm de conter todos os processos
dos nveis anteriores, engloba tambm os processos desenvolvimento para reutilizao, gerncia de decises e gerncia de riscos.
126 Uma das principais bases tcnicas para a criao do modelo de referncia do MPS.BR foi uma
norma ISO/IEC, a qual estabeleceu uma arquitetura para o ciclo de vida dos processos de software. software durante todo o ciclo de vida deste, tendo sido desenvolvido para atender complexidade dessa atividade em organizaes de grande porte, no sendo, portanto, indicada a sua utilizao por micro ou pequenas empresas.
127 O modelo MPS.BR prev atividades, processos, produtos e equipes de desenvolvimento de
128 O MPS.BR formado por trs componentes e respectivos guias. O modelo de referncia
formado pelos guias geral, de aquisio e de implementao.
Rogrio Arajo
Captulo 2
Contratao de Bens e Servios de TI

Os homens que tentam fazer algo e falham so infinitamente melhores do que aqueles que tentam fazer nada e conseguem. Lloyd Jones
2.1 IN04
Julgue os prximos itens, segundo a Instruo Normativa n. 4/2008, do MPOG, que dispe acerca do processo de contratao de servios de tecnologia da informao (TI) pela administrao pblica federal direta, autrquica e fundacional.
91 O plano diretor de tecnologia da informao (PDTI) um instrumento de diagnstico e gesto

dos recursos e processos de TI, que visa a atender s necessidades de informao de um rgo ou entidade para determinado perodo, sem considerar aspectos de planejamento.
92 A gesto de processos de TI, incluindo a gesto de segurana da informao, no pode ser

objeto de contratao.
93 rea de TI considerada como uma unidade setorial ou seccional do sistema de administrao
dos recursos de informao e informtica, bem como rea correlata, responsvel por gerir a TI do rgo ou entidade.
94 Software pode ser entendido como um sistema ou componente constitudo por um conjunto 95 Requisitos um conjunto de especificaes necessrias para definir a soluo de TI a ser
de programas, procedimentos e documentao, desenvolvido para o atendimento de necessidades especficas do rgo ou entidade. contratada. Critrios de aceitao so parmetros objetivos, mas nem sempre mensurveis, utilizados para verificar um servio ou produto quanto conformidade aos requisitos especificados.
Rogrio Arajo
Captulo 3
Ingls
A transformao pessoal requer substituio de velhos hbitos por novos. W. A. Peterson
Julgue se os itens a seguir, escritos em lngua inglesa, esto tcnica e gramaticalmente corretos. immediately for its own safe.
96 Whenever a new release of a software package is announced, the organization needs to buy it 97 Data warehousing technology affords types of functionality such as consolidation, aggregation,
and summarization of data, which let to view the same information along multiple dimensions. that a translator program works like a middleware.
98 A middleware system is one that serves as interface between other systems, so we could say 99 An attribute is a special characteristic related to an entity, but not to an object. 100 Information technology people know the importance of periodical backup to make possible
to restore non important information.
Rogrio Arajo
Captulo 4
Desenvolvimento de Sistemas
Somos o que fazemos repetidamente. Por isso o mrito no est na ao e sim no hbito. Aristteles
4.1 Lgica de programao

No que se refere lgica de programao, julgue os itens a seguir.
101 Em um algoritmo, uma expresso geralmente considerada vlida quando as suas variveis
e constantes respeitam o nmero e os tipos de argumentos das operaes envolvidas. quanto para a organizao fsica de tabelas.
102 O mtodo de pesquisa binria de clculo de endereo empregado tanto para a pesquisa 103 A instruo x %= y, em que o operador matemtico representa uma operao aritmtica
seguida de uma operao de atribuio, equivalente a x = x % y, sendo que o operador % somente pode ser utilizado com um operando do tipo inteiro.
104 Se um trecho de algoritmo tiver de ser executado repetidamente e o nmero de repeties

for indefinido, ento correto o uso, no incio desse trecho, da estrutura de repetio Enquanto.
105 A funo predefinida fopen( ) pode ser utilizada para abrir um arquivo apenas quando esse
arquivo j exista no diretrio em uso; caso contrrio, necessrio inicialmente criar o arquivo por meio da funo fcreate ( ).
106 O mtodo recursivo que utiliza pilhas para executar um procedimento geralmente
automtico, de modo que os compiladores podem acionar os procedimentos pr-programados para manipular essas pilhas. com a chave de cada entrada, ter o desempenho reduzido se a tabela for ordenada a partir do valor da chave.
107 A pesquisa sequencial de uma tabela, ou seja, pela comparao do argumento da pesquisa
4.2 Programao Orientada a Objetos

A respeito da hierarquia de classes, um conceito de relevncia na programao orientada a objetos, julgue os itens que se seguem.
129 Considere que uma classe C1 implemente determinado mtodo M1 e tenha duas subclasses:
C2 e C3. Nessa situao, o comportamento de um objeto de C2 ou C3 que receba uma mensagem invocando o mtodo M1 ser obrigatoriamente idntico ao comportamento de um objeto de C1 que receba a mesma mensagem.
130 Se a classe C2 uma subclasse da classe C1, todas as caractersticas que so herdadas por
C2 foram definidas na classe C1 ou em alguma de suas superclasses. herana mltipla em uma hierarquia de classes.
Rogrio Arajo
131 Um objeto , necessariamente, instncia de apenas uma classe, mesmo quando existe
10
4.3 Java
Os programas em geral manipulam, alm de nmeros e strings, itens de dados mais complexos, que representam mais precisamente entidades no mundo real. Com relao linguagem Java, usada para projetar e manipular itens de dados complexos (objetos), julgue os itens de 137 a 139.
137 No cdigo em Java mostrado a seguir, as classes Conta e Poupanca implementam o

polimorfismo dinmico. class Conta { float saldo; public float getSaldo(int i) { float saldo = 0f; if (i == 1 ) saldo = this.saldo * 1.03f; return saldo; } public void setSaldo (float saldo) { this.saldo = saldo + 20f; } } class Poupanca extends Conta { public float getSaldo() { return saldo; } }
138 No cdigo em Java apresentado a seguir, a tentativa de execuo da classe Principal resultar
em erro, porque o objeto p1 foi criado utilizando como tipo a classe abstrata Conta. abstract class Conta { protected float saldo; public abstract float saldoConta (); public void setSaldo (float saldo) { this.saldo = saldo + 50f; } } class Poupanca extends Conta {
public float saldoConta() { return saldo; } } public class Principal { public static void main (String args[]) { Conta p1 = new Poupanca(); ((Poupanca)p1).setSaldo(450f); System.out.println("saldo : " +((Poupanca)p1).saldoConta()); } }
139 A tentativa de execuo do programa em Java mostrado a seguir pode resultar na indicao
de uma exceo do tipo InputMismatchException. import java.util.*; public class Excecao { public int calculo(int n1, int n2) throws ArithmeticException { return n1/n2; } public static void main (String [] args) { Scanner sc = new Scanner(System.in); int n1, n2, res; Excecao ex = new Excecao(); System.out.print("Entre o valor 1: "); n1 = sc.nextInt(); System.out.print("Entre o valor 2: "); n2 = sc.nextInt(); res = ex.calculo(n1,n2); System.out.println("Resultado: " + res); } }
4.4 Linguagens e tecnologias de programao

Quanto s linguagens e tecnologias de programao, julgue os itens subsequentes. do usurio que so organizados em um ou mais projetos.
140 Na arquitetura do Eclipse, verso 3.1, o workbench responsvel por administrar os recursos
Rogrio Arajo
12
141 JavaScript uma linguagem de criao de scripts de uso geral, projetada para ser embutida
em aplicativos que executam em um navegador Web. Os aplicativos Ajax so escritos em JavaScript.
142 O uso de Realms no servidor de aplicao Tomcat obriga a implementao de uma poltica de
segurana nesse servidor, por isso, no necessrio escrever, na aplicao, um cdigo especfico para autenticao e autorizao.
143 O modelo de componentes do JBoss Seam tem como caracterstica o uso direto de
componentes Enterprise JavaBeans como beans acoplados s pginas JavaServer Faces.
Rogrio Arajo
13
Captulo 5
Engenharia de Software
As oportunidades tm tamanho para qualquer tipo de capacidade. Walter Grando
5.1 Engenharia de requisitos

Acerca de engenharia de requisitos, julgue os itens subsequentes.
108 Embora a criao de uma sequncia ilustrada de telas por meio de programas de desenho
grfico seja til para a identificao de alguns requisitos do software, ela no considerada uma atividade de prototipao por no envolver o uso de uma linguagem de programao. se definir, junto aos envolvidos no processo, quais so as premissas bsicas para o incio do entendimento das funcionalidades desejadas.
109 O levantamento de requisitos realizado ao final da primeira verso de um prottipo, para 110 A verificao de requisitos tem por objetivo analisar se os modelos construdos esto de
acordo com os requisitos definidos. Por sua vez, a validao de requisitos visa assegurar que as necessidades do cliente esto sendo atendidas por tais requisitos.
111 A especificao de requisitos permite, em determinado momento, revelar o que o sistema ir
realizar no que se refere s funcionalidades, sem definir, nesse momento, como as funcionalidades sero implementadas.
112 Na validao de requisitos parte integrante da especificao desses requisitos , correto

o uso de diagramas da UML, tais como diagrama de classes, de casos de uso e de interao.
113 Os requisitos normativos, geralmente oriundos da anlise das regras de negcio a que est
submetido um sistema, nunca podem ser considerados requisitos funcionais, por estarem fora do sistema, ou seja, do domnio do negcio.
5.2 Qualidade de Software

Julgue os seguintes itens a respeito de qualidade de software.
114 O nvel mximo de qualidade de um software atingido quando os stakeholders esto
satisfeitos com os resultados que ele apresenta; para tanto, essencial que todos os envolvidos no processo de criao desse software faam parte da reviso de qualidade.
115 Na anlise por pontos de funo (APF), as funes podem ser do tipo transao e do tipo
dados. Nas funes do tipo transao, so manipulados os arquivos de interface externa (AIE) bem como os arquivos lgicos internos (ALI).
116 Na fase de elaborao do RUP, so desenvolvidas as funcionalidades do sistema e

implementados os requisitos identificados na fase de concepo.
117 Extreme programming (XP) embasado em requisitos conhecidos, definidos de antemo,
que no sofram muitas alteraes, devendo ser usado por equipes de pequeno porte, formadas por representantes de todos os stakeholders.
118 Produto da metodologia Scrum, o documento product backlog contm os requisitos

definidos a partir da viso do cliente e utilizado novamente no final do sprint para reviso ou modificaes dos requisitos inicialmente definidos.
119 O plano de garantia de qualidade de software, os documentos, padres e guias a serem
utilizados, as ferramentas, tcnicas e metodologias de apoio e quem deve exercer o controle dessa qualidade esto normatizados pela ISO.
120 A reviso de um projeto de software, tendo em vista a qualidade do processo de codificao,
inclui, entre outros aspectos, verificar a ocorrncia de erros de ortografia, o uso adequado das convenes da linguagem e se as constantes fsicas esto corretas. Um processo de desenvolvimento de software contm a descrio de uma abordagem para a construo de sofware. A UML (unified modeling language) uma linguagem visual para especificar, documentar e construir os artefatos de sistemas orientados a objetos. Quanto ao ambiente de desenvolvimento de sistemas orientados a objetos, julgue os itens a seguir.
5.3 Padres de Projetos

132 GRASP (general responsibility assignment software patterns) consiste em um conjunto de
sete padres bsicos para atribuir responsabilidades em projeto orientado a objetos: information expert, creator, controller, low coupling, high cohesion, polymorphism e pure fabrication.
5.4 Processo Unificado

133 O processo unificado (PU) um processo iterativo para a anlise de projetos orientados a
objetos, no qual o trabalho e as iteraes so organizados em trs fases principais: concepo, elaborao e construo.
134 No PU, a elicitao de requisitos do sistema de software inicia-se na fase de concepo.
5.5 UML
135 Na UML, um diagrama de atividades oferece uma notao para mostrar uma sequncia de
atividades, inclusive atividades paralelas. Ele pode ser aplicado em qualquer perspectiva ou propsito, no entanto, normalmente mais utilizado para a visualizao de fluxos de trabalho, processos de negcios e casos de uso. representada no diagrama de sequncia por meio de seta cheia (no pontilhada).
136 Na conveno de notao usada na UML, a chamada por mensagens assncronas
5.6 Testes de Software

No processo de teste de software, uma das metas consiste em demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos, e outra, em descobrir falhas ou defeitos no software que apresenta comportamento incorreto. Quanto aos processos de teste de software, julgue os prximos itens.
Rogrio Arajo
15
144 O Junit um conjunto de classes em Java que pode ser estendido para se criar um ambiente
de testes de regresso automatizado.
145 O teste de integrao geralmente um processo de teste de caixa-preta no qual os testes
so derivados da especificao do sistema, cujo comportamento pode ser determinado por meio do estudo de suas entradas e sadas. componentes so definidos por suas interfaces e podem ser reusados em combinao com outros componentes em diferentes sistemas. Nesse caso, o teste de interfaces particularmente til, porque erros de interface em componentes compostos (formados pela combinao de componentes) no podem ser detectados por meio de testes de objetos ou componentes individuais.
146 No desenvolvimento orientado a objetos embasados em componentes, os objetos e os
Rogrio Arajo
16
Captulo 6
Banco de Dados
Depois do fim ainda existe a possibilidade do alm. Walter Grando
Considerando o modelo E-R e as tabelas acima, que representam um grupo de auditores que realizam auditorias em empresas, julgue os itens seguintes.
6.1 SQL
147 A execuo do comando apresentado a seguir permite listar os nomes dos auditores que
auditaram mais de uma empresa. Select nome from auditor where id_aud in (select id_aud from auditoria group by id_aud having count(*) > 1)
150 A execuo do comando mostrado abaixo permite listar os nomes dos auditores que
auditaram todas as empresas com oramento superior a 4.000. where a.id_aud = b.id_aud and b.id_emp = c.id_emp and c.orcamento > 4000 select distinct a.nome from auditor a, auditoria b, empresa c
Rogrio Arajo
17
6.7 MySQL
148 O script a seguir permite criar, corretamente, as tabelas, no MySql 5.1, em conformidade
com o modelo E-R apresentado. create table auditor ( id_aud int not null primary key, nome varchar (40)); create table empresa ( id_emp int not null primary key, nome_emp varchar(30), orcamento float); create table auditoria ( id_audit int not null primary key, id_aud int, id_emp int, dt_aud date);
149 O tipo InnoDB, no MySql 5.1, permite estabelecer, nas tabelas, o controle de transaes para
possibilitar o uso dos comandos COMMIT e ROLLBACK. Nesse caso, considerando a existncia das tabelas apresentadas em um banco de dados, a execuo dos comandos a seguir habilitar corretamente a transao nas tabelas. Alter table empresa engine=innodb; Alter table auditoria engine=innodb; Alter table auditor engine=innodb;
Rogrio Arajo
18
Captulo 7
Gabarito preliminar
Nada na vida est realmente em nossas mos... mas tudo est diante das nossas possibilidades. Walter Grando
Algumas questes da prova foram posta fora de ordem neste material para que houvesse uma melhor organizao dos assuntos. Verifique com cuidado o gabarito com as questes que voc est respondendo.
61 C 76 C 91 E 106 C 121 E 136 E
62 C 77 C 92 C 107 E 122 C 137 E
63 C 78 C 93 C 108 E 123 E 138 E
64 E 79 C 94 E 109 E 124 E 139 C
65 C 80 C 95 E 110 C 125 C 140 E
66 E 81 C 96 E 111 C 126 C 141 C
67 C 82 C 97 C 112 C 127 E 142 C
68 C 83 E 98 C 113 E 128 C 143 C
69 E 84 E 99 E 114 E 129 E 144 C
70 C 85 E 100 E 115 E 130 E 145 E
71 E 86 E 101 C 116 E 131 C 146 C
72 E 87 E 102 E 117 E 132 E 147 C
73 C 88 C 103 C 118 C 133 E 148 E
74 E 89 C 104 C 119 E 134 E 149 C
75 C 90 E 105 E 120 C 135 C 150 E
Rogrio Arajo
19
PARTE II
A REDAO
Rogrio Arajo
20
Captulo 1
Comando da redao
A primeira condio para se realizar algum coisa, no querer fazer tudo ao mesmo tempo. Tristo de Atade
1.1 Texto de apoio

A gesto de processos demanda a viso e o contnuo monitoramento de indicadores de desempenho para a constante avaliao do alcance das metas estabelecidas de eficcia, eficincia e efetividade. Esses indicadores tambm podem ser utilizados nos processos de desenvolvimento de software. Para a mensurao de qualidade na engenharia de software, as empresas dispem de dois modelos de nveis de maturidade, o CMMI e o MPS.BR, que definem um patamar de evoluo de processo e estabelecem uma forma de prever o desempenho futuro da organizao com relao a uma ou mais disciplinas.
1.2 Itens a serem abordados

Considerando que o texto acima tem carter unicamente motivador, elabore um texto dissertativo a respeito dos modelos de maturidade CMMI e MPS.BR. Ao elaborar seu texto, atenda, necessariamente, s seguintes determinaes: defina o modelo CMMI, apresentando suas dimenses e abordagens; defina o MPS.BR, apresentando mtodo, nveis de maturidade e respectivas dimenses; compare os dois os modelos.
Rogrio Arajo
21
PARTE III
OS COMENTRIOS DAS QUESTES OBJETIVAS
Rogrio Arajo
22
Captulo 1
Governana de TI
O entusiasmo a maior fora da alma. Conserva-o e nunca te faltar poder para conseguir o que desejas. Napoleon Hill
1.1 Conceitos
Acerca de conceitos relacionados governana de tecnologia da informao (TI), julgue os itens a seguir.
61 As ferramentas GUT (gravidade, urgncia e tendncia), o Diagrama de Pareto e a Curva de

Tendncia fornecem suporte atividade do planejamento estratgico de filtrar informaes de interesse da organizao. Comentrios Em [1], temos que ferramentas GUT so usadas para ... definir prioridades dadas as diversas alternativas de ao. As ferramentas GUT aplicam-se quando necessrio priorizar aes dentro de um leque de alternativas. O Diagrama de Pareto [2] ... um recurso grfico utilizado para estabelecer uma ordenao nas causas de perdas que devem ser sanadas. Vilfredo Pareto calculou matematicamente que 80% da riqueza estava em mos de 20% da populao. Juran trouxe isso para a realidade da qualidade e disse que Poucas causas levam maioria das perdas, ou seja, poucas so vitais, a maioria trivial. No achei alguma referncia para embasar a Curva de Tendncia. Concluindo, essas ferramentas sero teis para o planejamento estratgico de uma organizao, portanto, a questo est certa. Gabarito preliminar: CERTO. Referncias: [1] Ferramentas GUT: novosolhos.com.br/site/arq_material/13369_14428.doc [2] Diagrama de Pareto: www.brasilacademico.com/maxpt/links_goto.asp?id=1015
62 Um dos objetivos da governana de TI possibilitar o alinhamento das atividades da equipe de

TI com as prioridades das demais reas de negcios da empresa. Comentrios Acreditei que essa questo estava ERRADA e Entrei com recurso com o seguinte texto: A questo em tela fala de um alinhamento de um nvel operacional (atividades de TI) com
um nvel estratgico (prioridades das demais reas de negcios da empresa). Segundo o modelo de governana CobiT 4.1, cita-se as cinco reas de foco da Governana de TI e uma delas o Alinhamento Estratgico que foca em garantir a ligao entre os planos de negcios e de TI, definindo, mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes da organizao. Pode-se perceber pela rea acima que claramente existem o alinhamento estratgico (ligao entre os planos de negcios e de TI) e o alinhamento operacional (operaes de TI com as operaes da organizao). A questo em tela no traz essa distino, induzido o candidato ao erro, portanto, pede-se ANULAO da questo. Resumindo, a questo, no meu entendimento, trouxera um alinhamento operacional (atividades de TI) com alinhamento estratgico (prioridades das demais reas de negcio da empresa). Isso, para mim, est errado por conta que temos o alinhamento estratgico entre os planos da TI e da organizao e o alinhamento operacional entre as operaes de TI e operaes da organizao. Entretanto, com ajuda de um colega que comentou o material, Eliziomar, ele citou o seguinte trecho do livro do Aragon [2]: Alinhar e priorizar as iniciativas de TI com a estratgica do negcio: Isto significa que o que foi planejado para acontecer deve priorizado, tendo em vista as prioridades do negcio e as restries de capital de investimento; A priorizao gera um portflio de TI, que faz a ligao entre a estratgia e as aes do dia-dia. Ou seja, as aes do dia a dia da TI est ligada estratgia do negcio por meio de um portflio de TI que ... um instrumento para priorizao dos investimentos de TI com base no retorno de projetos e ativos para a organizao, e no seu alinhamento com os objetivos estratgicos do negcio. Portanto, a questo realmente est certa. Gabarito preliminar: CERTO. Referncia: [1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41portuguese.pdf [2] Implantando a Governana de TI, 2 Edio.
63 Os marcos de regulao, o ambiente de negcios, a transparncia da administrao e a

segurana da informao so fatores que motivam o uso da governana de TI nas organizaes. Comentrios Em [1], os fatores que motivam a Governana de TI so: Ambiente de Negcios; Marcos Reguladores; Segurana da Informao
Dependncia do Negcio em relao TI; e Integrao Tecnolgica. Aragon [2] cita mais um alm dos que esto em cima: TI como prestadora de servios. Fiquei com dvida no fator transparncia da administrao, pois no encontrei nenhuma fonte para confirm-lo como fator de motivao da Governana de TI. Gabarito preliminar: CERTO. Referncias: [1] Mapeamento dos processos baseado em controle para Governana de Tecnologia da Informao: http://www.bibliotecadigital.puc-campinas.edu.br/tde_busca/arquivo.php? codArquivo=240 [2] Implantando a Governana de TI, 2 Edio.
1.2 Escritrio de projetos para Governana de TI

Julgue os prximos itens no que se refere a escritrio de projetos para governana de TI.
64 Entre as dificuldades encontradas na implantao de um escritrio de projetos, incluem-se as
relacionadas mensurao e ao acompanhamento dos benefcios de um projeto, presso por resultados em curto prazo e definio da metodologia a ser utilizada. Comentrios A questo trouxe algumas dificuldades na implantao de um PMO. Dificuldades essas relacionadas: mensurao e ao acompanhamento dos benefcios de um projeto; presso por resultados em curto prazo; e definio da metodologia a ser utilizada. Em [1], h algumas dificuldades parecidas com as da questo: Baixa Credibilidade; Resistncia a Mudanas; Dificuldade de mensurao e acompanhamento dos benefcios em um projeto (valor agregado); Necessidade de formalizao; e Presso por resultados em curto prazo. O examinador colocou a definio da metodologia a ser utilizada como uma dificuldade na implantao de um PMO, entretanto no uma dificuldade e sim uma atribuio de um escritrio de projeto. No Guia PMBoK (4 Edio) [2], existem algumas atribuies para um PMO (sigla de Escritrio de Gerenciamento de Projetos em ingls), tais como: Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO; Identificao e desenvolvimento de metodologia, melhores prticas e padres de gerenciamento de projetos;
Orientao, aconselhamento, treinamento e superviso; Monitoramento da conformidade com as polticas, procedimentos e modelos padres de gerenciamento de projetos por meio de auditorias do projeto; Desenvolvimento e gerenciamento de polticas, procedimentos, formulrios e outras documentaes compartilhadas do projeto (ativos de processos organizacionais) e Coordenao das comunicaes entre projetos. Gabarito preliminar: ERRADO. Referncias: [1] Escritrio de Projetos: www.amcham.com.br/download/informativo2005-05-20a_arquivo [2] Guia PMBoK (4 Edio).
65 Um escritrio de projetos pode se implantado em qualquer tipo de estrutura organizacional
funcional, matricial ou por projeto e ele pode ter autoridade para supervisionar e cancelar projetos. Comentrios Esse verbo PODER que o CESPE utiliza pode tudo. Brincadeiras parte, essa questo est correta [1]: Um PMO poder auxiliar o gerente de projetos na garantia do atendimento aos quesitos acima e tambm poder contribuir na busca pela excelncia em gerenciamento de projetos, mesmo o instituto apresentando uma estrutura matricial fraca, uma vez que um PMO pode ser implantado em qualquer estrutura organizacional. (Grifo meu) Fiquei com dvida sobre a autoridade do escritrio de projeto para supervisionar e cancelar projetos dentro de uma estrutura funcional, marcando assim errado na questo. Entretanto, pesquisando para sanar a dvida, encontrei [2] que Um PMO pode existir em qualquer uma das estruturas organizacionais, inclusive nas que apresentam uma organizao funcional... (Grifo meu). E para fechar a dvida, ainda no [2]: A funo de um PMO em uma organizao pode variar de uma assessoria, limitada recomendao de polticas e procedimentos especficos sobre projetos individuais, at uma concesso formal de autoridade pela gerncia executiva. Gabarito preliminar: CERTO. Referncias: [1] O apoio de um PMO na gesto de manuteno de software: http://www.ici.curitiba.org.br/Multimidia/Documento/Artigos/ArtigoMBA_Ursula.pdf [2] Influncias organizacionais: http://www.tenstep.com.br/br/TenStepPB/open/2.3.htm
66 O escritrio de projetos de uma organizao tem, entre outras, as seguintes atribuies:
padronizao de processos de suporte a projetos, treinamento de pessoal, gerenciamento de recursos e elaborao do plano estratgico da organizao.
Rogrio Arajo
26
Comentrios Diferentemente da questo 64 que citava algumas dificuldades na implantao de um PMO, a questo em tela trouxe algumas atribuies desse tipo de escritrio. Nosso trabalho, como sempre, analisar cada item para encontrar algum erro. Iremos ento fazer um paralelo entre as atribuies trazidas nesta questo com as atribuies j descritas na questo 64: Padronizao de processos de suporte a projetos: atribuio certa, pois bate com a Identificao e desenvolvimento de metodologia, melhores prticas e padres de gerenciamento de projetos; Treinamento de pessoal: bate com a atribuio Orientao, aconselhamento, treinamento e superviso; Gerenciamento de recursos: acredito que aqui teria um erro, pois existe o gerenciamento de recurso DE UM NICO PROJETO, gerenciamento esse feito pelo gerente de projetos, e o gerenciamento de recursos ENTRE PROJETOS, feito pelo escritrio de projetos (Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO); e Elaborao do plano estratgico da organizao: outro erro, pois um escritrio de projeto no ser responsvel pelo planejamento estratgico da organizao. Gabarito preliminar: ERRADO. Referncia: [1] Guia PMBoK (4 Edio).
1.3 CobiT 4.1

Com relao ao modelo COBIT 4.1, julgue os itens a seguir.
67 O emprego sistemtico do COBIT como modelo de gesto da organizao pode gerar, entre
outros benefcios, a reduo dos riscos a que est exposta a organizao e a melhoria de sua imagem perante os clientes. Comentrios Essa questo sai muito por tabela. Com uma viso superficial dos conceitos do CobiT, podemos chegar concluso de que a questo est certa. Em [1], cita-se que o CobiT oferece boas prticas utilizando um modelo de domnio (Planejar e Organizar; Adquirir e Implementar; Entregar e Suportar e Monitorar e Avaliar) e processos (ao todo, so 34 processos). Essas boas prticas iro ajudar a organizao a: Otimizar os investimentos em TI; Assegurar a entrega dos servios; e Prover mtricas para julgar quando as coisas saem erradas. Outro ponto importante tambm descrito em [1] que pode corroborar a questo fato de que o CobiT um modelo e uma ferramenta de suporte que permite aos gerentes suprir as deficincias com respeito aos requisitos de controle, questes tcnicas e riscos de negcios, comunicando esse nvel de controle s partes interessadas.
Aragon [2] (depois dos comentrios dessa prova, vou cobrar dele um percentual de indicao do seu livro, se ainda houver no mercado ) traz alguns benefcios ao se utilizar sistematicamente o CobiT, entre os quais, existem os seguintes: Reduo de exposio a riscos; Melhoria da imagem perante os clientes, atravs do aumento do grau de satisfao e da confiabilidade em relao aos servios de TI. Portanto, sem menor dvida da fonte da questo, ela est certa. Aproveitando, gostaria de trazer tambm os benefcios citados em [1] que so alcanados ao implementar o CobiT como modelo de governana de TI: Um melhor alinhamento baseado no foco do negcio; Uma viso clara para os executivos sobre o que TI faz; Uma clara diviso das responsabilidades baseada na orientao para processos; Aceitao geral por terceiros e rgos reguladores; Entendimento compreendido entre todas as partes interessadas, baseado em uma linguagem comum; Cumprimento dos requisitos do COSO para controle do ambiente de TI. Gabarito preliminar: CERTO. Referncias: [1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41portuguese.pdf [2] Implantando a Governana de TI, 2 Edio.
68 No modelo COBIT, o conceito de agregao de valor diz respeito proposio de valor no

tempo e garante que a TI entregue os benefcios prometidos com a otimizao de custos. Comentrios Existem cinco reas de foco na governana de TI [1]: Alinhamento estratgico: foca em garantir a ligao entre os planos de negcios e de TI, definindo, mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes da organizao; Entrega de valor: a execuo da proposta de valor de IT atravs do ciclo de entrega, garantindo que TI entrega os prometidos benefcios previstos na estratgia da organizao, concentrado-se em otimizar custos e provendo o valor intrnseco de TI; Gesto de recursos: refere-se melhor utilizao possvel dos investimentos e o apropriado gerenciamento dos recursos crticos de TI: aplicativos, informaes, infraestrutura e pessoas. Questes relevantes referem-se otimizao do conhecimento e infraestrutura; Gesto de risco: requer a preocupao com riscos pelos funcionrios mais experientes da corporao, um entendimento claro do apetite de risco da empresa e dos requerimentos de conformidade, transparncia sobre os riscos significantes para a organizao e insero do gerenciamento de riscos nas atividades da companhia; Mensurao de desempenho: acompanha e monitora a implementao da estratgia, trmino do projeto, uso dos recursos, processo de performance e entrega dos servios,
usando, por exemplo, balanced scorecards que traduzem as estratgias em aes para atingir os objetivos, medidos atravs de processos contbeis convencionais. A questo citou Agregao de Valor ao invs de Entrega de Valor, como visto acima. A soluo da questo vem (adivinhem!) do Aragon [2]. O autor tambm cita as cinco reas, porm chama a rea Entrega de valor como Agregao de Valor e diz o seguinte sobre essa rea: execuo de proposio de valor atravs do tempo, assegurando que a TI entregue os benefcios prometidos de acordo com a estratgia, concentrando-se em otimizar custos e em comprovar o valor intrnseco da TI. Com base no pargrafo anterior, confirmamos que a questo est correta. Gabarito preliminar: CERTO. Referncias: [1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41portuguese.pdf [2] Implantando a Governana de TI, 2 Edio.
69 A estrutura do COBIT foi idealizada para controlar, nas organizaes, os recursos de TI e os

recursos humanos envolvidos nesse processo. Comentrios Para sabermos um pouco sobre a histria do CobiT, acompanhem a tabela abaixo [1]:
Ano 1994 1998 2000 2005 2007
Edio Primeira Verso Segunda Verso Terceira Verso Quarta Verso Verso 4.1
Evoluo A ISACA (Information System Audit and Control Association www.isaca.org) lana um conjunto de objetivos de controle para as aplicaes de negcio. Inclui uma ferramenta de suporte implementao e a especificao de objetivos de controle de alto nvel e detalhados. Inclui normas e guias associadas gesto. O ITGI (IT Governance Institute - www.itgi.org) torna-se o principal editor do framework. Melhoria dos controles para assegurar a segurana e a disponibilidade dos ativos de TI na organizao. Segundo Aragon [2], o foco dessa verso foi ... orientado a uma maior eficcia dos objetivos e dos processos de verificao e divulgao de resultados. Tabela 1: Evoluo do CobiT.
Importante destacar que em 2002 foi lanada a lei Sarbanes-Oxley Act. Este acontecimento teve um impacto significativo na adoo do CobiT nos EUA e nas empresas globais que l atuam. Portanto, a questo est errada porque a verso original do modelo de governana em tela era um conjunto de objetivos de controle para aplicaes de negcios. Gabarito preliminar: ERRADO.
Referncias: [1] Gesto de Portaflio e Gerncia de Projetos no CobiT: http://www.pmidf.org/encontrogp/palestras/joaosouza.pdf [2] Implantando a Governana de TI, 2 Edio.
70 No mencionado modelo, possvel haver controles especficos vinculados a aplicaes e
integrados aos processos de negcio, que os suportam por meio de procedimentos relacionados, por exemplo, s interfaces do sistema. Comentrios Esse modelo, como dito antes, oferece boas prticas e essas so fortemente focadas mais nos controles e menos na execuo [1]. CobiT possui quatro principais caractersticas e uma delas justamente ser Baseado em controles. As outras caractersticas so: Focado em negcios; Orientado a processos; e Orientado por medies. Cada processo de TI citado no CobiT possui uma descrio de processo e vrios objetivos de controle detalhados. Tambm temos requisitos de controle genricos (veremos esses requisitos de na questo 73) aplicveis a todos os processos. Alm desses, temos os controles de aplicativos que so controles inseridos nos aplicativos de processos de negcios: AC1 Preparao e Autorizao de Dados Originais; AC2 Entrada e Coleta de Dados Fontes; AC3 Testes de Veracidade, Totalidade e Autenticidade; AC4 Processamento ntegro e Vlido; AC5 Reviso das Sadas, Reconciliao e Manuseio de Erros; AC6 Autenticao e Integridade das Transaes. Pelo texto da questo, o examinador novamente utilizou o Aragon [2]. Esse autor diz que o AC 6 se refere Interface apenas, no informando ser interface com o usurio ou entre aplicativos. Entrei com recurso nessa questo com o seguinte texto: No CobiT, existe o controle de aplicao AC6 que diz: AC6 Autenticao e Integridade das Transaes Antes de transportar os dados das transaes entre os aplicativos e as funes de negcios/operacionais (internas ou externas organizao), verifica endereamento adequado, autenticidade da origem e integridade do contedo. Mantm a autenticidade e integridade durante a transmisso ou transporte. O AC6 fala do transporte os dados das transaes entre os aplicativos e as funes de negcios/operacionais, o que podemos induzir que o termo interfaces que o autor [ARAGON, 2008] cita seria interfaces ENTRE sistemas e funes. A questo em tela fala interfaces DO sistema, o que no certo, pois esse termo est diferente do que o AC6 prope. Portanto, pela concluso acima, pede-se ANULAO ou mudana do gabarito para ERRADO.
Rogrio Arajo
30
http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf [ARAGON, 2008] Implantando a Governana de TI, 2 Edio - 2008. No sei se fui muito precioso nessa questo. Vamos esperar o gabarito definitivo. Gabarito preliminar: CERTO. Referncias: [1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41portuguese.pdf [2] Implantando a Governana de TI, 2 Edio.
71 No COBIT, um dos processos do domnio Entrega e Suporte o de assegurar conformidade

com requisitos externos. Comentrios Essa uma das questes que no podemos mais perder, at porque a forma da pergunta (se um processo pertence a um determinando domnio) corriqueira nas provas atuais do CESPE. A questo citou o processo ME3 Assegurar a Conformidade com Requisitos Externos. Esse processo do domnio Monitorar e Avaliar. Os demais processos do domnio citado esto na figura 1. Galera, apenas peo pacincia pela imagem do processo ME3. Procurei muito por uma figura que pudesse se encaixar no nome do processo, entretanto, no encontrei nada. Ento, como vi essa imagem de uma mo segurando uma casa, pensei em us-la para lembrar da palavra Assegurar. Nota 1: O porqu do uso da imagem para o processo ME Assegurar a Conformidade com Requisitos Externos.
Rogrio Arajo
31
Figura 1: Processos do Domnio Monitorar e Avaliar. Gabarito preliminar: ERRADO.
72 No modelo em apreo, o domnio Planejamento e Organizao envolve identificao,

Comentrios No disse que est ficando corriqueiro esse tipo de questo?
desenvolvimento e(ou) aquisio de solues para a execuo de sistemas de TI especficos, assim como a sua implementao e integrao junto a processos de negcio.
O que est descrito na questo muito voltado para o domnio de Adquirir e Implementar (figura 2).
Rogrio Arajo
32
Figura 2: Processos do domnio Adquirir e Implementar. Gabarito preliminar: ERRADO.
73 Alguns requisitos de controle genricos so aplicveis a todos os processos do COBIT, tais

como a definio e a divulgao de polticas, os procedimentos e planos relativos ao processo, e o desempenho do processo medido em relao s respectivas metas. Comentrios Como vimos na questo 70, cada processo de TI citado no CobiT possui uma descrio de processo e vrios objetivos de controle detalhados. Tambm temos requisitos de controle genricos aplicveis a todos os processos, identificados por PC(n): PC1 Metas e Objetivos do Processo; PC2 Propriedade dos Processos; PC3 Repetibilidade dos Processos; PC4 Papis e Responsabilidades; PC5 Polticas Planos e Procedimentos; e PC6 Melhoria do Processo de Performance. A questo citou alguns da lista de cima: Definio e a divulgao de polticas, os procedimentos e planos relativos ao processo: PC5 que trata da definio e comunicao de como todas as polticas, planos e procedimentos que direcionam os processos de TI so documentados, revisados, mantidos, aprovados, armazenados, comunicados e utilizados para treinamento; e Desempenho do processo medido em relao s respectivas metas: PC6 que trata da identificao de um conjunto de mtricas que fornecem direcionamento para os resultados e performance dos processos.
Rogrio Arajo
33
Gabarito preliminar: CERTO.
1.4 ITIL v3
Julgue os itens que se seguem a respeito de conceitos da ITIL v.3.
74 Estratgia de servio a publicao do ncleo da ITIL v.3 que contm orientaes acerca do
projeto e desenvolvimento dos servios e dos processos de gerenciamento de servios. Essa publicao apresenta, em detalhes, aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade, da disponibilidade e da segurana da informao. Comentrios O examinador quis deixar a questo errada ao jogar a descrio da publicao de Desenho de Servio para a de Estratgia de Servio. Resumidamente, as publicaes do ITIL v3 so formadas pela sigla ED TOM [1]: Estratgia de Servio: orienta sobre como as polticas e processos de gerenciamento de servio podem ser desenhados, desenvolvidos e implementados como ativos estratgicos ao longo do ciclo de vida de servio; Desenho de Servio: fornece orientao para o desenho e desenvolvimento dos servios e dos processos de gerenciamento de servios, detalhando aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade da disponibilidade, da continuidade, da segurana da informao e dos fornecedores, alm de mudanas e melhorias necessrias para manter ou agregar valor aos clientes ao longo do ciclo de vida de servio; Transiro de Servio: orienta sobre como efetivar a transio de servios novos e modificados para operaes implementadas, detalhando os processos de planejamento e suporte transio, gerenciamento de mudanas, gerenciamento da configurao e dos ativos de servio, gerenciamento de liberao e da distribuio, teste e validao de servio, avaliao e gerenciamento do conhecimento; Operao de Servio: descreve a fase do ciclo de vida do gerenciamento de servios que e responsvel pelas atividades do dia-a-dia, orientando sobre como garantir a entrega e o suporte a servios de forma eficiente e eficaz, e detalhando os processos de gerenciamento de eventos, incidentes, problemas, acesso e de execuo de requisies; e Melhoria de Servio Continuada: orienta, atravs de princpios, prticas e mtodos do gerenciamento da qualidade, sobre como fazer sistematicamente melhorias incrementais e de larga escala na qualidade dos servios, nas metas de eficincia operacional, na continuidade dos servios etc., com base no modelo PDCA preconizado pela ISO/IEC 20000. Para finalizar, a tabela 2 mostra a publicaes e seus os processos e funes, esses se houver. Utilizei o material do Thiago Fagury [2] como referncia.
Rogrio Arajo
34
Publicao
Processos
Funes
Gerenciamento Financeiro de TI Estratgia de Gerenciamento de Portflio de Servios Servio Gerenciamento de Demanda Gerao da Estratgia Gerenciamento do Catlogo de Servios Gerenciamento de Nvel de Servio Gerenciamento da Disponibilidade Desenho de Gerenciamento da Capacidade Servio Gerenciamento da Continuidade de Servio Gerenciamento de Segurana da Informao Gerenciamento de fornecedor Gerenciamento de Mudana Gerenciamento da Configurao e de Ativo de Servio Transio de Gerenciamento do Conhecimento Servio Planejamento e Suporte da Transio Gerenciamento de Liberao e Implantao Validao de Servio e Testes Avaliao Gerenciamento de Incidente Central de Servios Gerenciamento de Eventos Gerenciamento Tcnico Operao de Cumprimento de Requisies Gerenciamento de Aplicaes Servio Gerenciamento de Acesso Gerenciamento de Operaes Gerenciamento de Problemas de TI Melhoria de Melhoria em 7 passos Servio Mensurao de Servios Continuada Elaborao de relatrios de servios Tabela 2: Publicaes, Processos e Funes do ITIL v3. Sobre os processos e funes acima: H processos corretamente citados pelo Thiago e os quais no esto no livro do Aragon: Gerao da Estratgia da Estratgia de Servio; Planejamento e Suporte da Transio da Estratgia de Servio; e Melhoria em 7 passos da Melhoria de Servio Continuada. Segundo o Thiago, na Transio de Servio h processos que permeiam todo o ciclo de vida: Gerenciamento de Mudana; Gerenciamento da Configurao e de Ativo de Servio; e Gerenciamento do Conhecimento. Apenas na publicao Operao de Servios existem funes. Observao 1: Itens importantes a serem considerados na tabela 2. Gabarito preliminar: ERRADO.
Rogrio Arajo
35
Referncias: [1] Implantando a Governana de TI, 2 Edio. [2] Apostila Itil V3 (Primeira content/uploads/2010/09/apostila-itil-v3-3.pdf Verso): http://fagury.com.br/sys/wp-
75 No que diz respeito ao desenvolvimento da estratgia de servio na organizao, necessrio

considerar o estilo de gesto organizacional dominante na empresa, o qual pode apresentar os seguintes estgios ou nveis de maturidade: rede, diretivo, delegao, coordenao e colaborao. Comentrios Aragon [1] cita que o desenvolvimento da estratgia deve levar em considerao o estilo de gesto organizacional mais adequada para o servio. Os estilos podem ser representados em estgio, algo parecido com nveis de maturidade: Estgio 1 (Rede): entrega de servio rpida, informal e sob demanda. O desafio a Liderana; Estgio 2 (Diretivo): equipe habilidosa em gesto para dirigir a estratgia e gerente com responsabilidades funcionais. O desafio a Autonomia; e Estgio 3 (Delegao): mais poder aos gerentes. O desafio o Controle; Estgio 4 (Coordenao): uso de sistemas formais para melhorar a coordenao. O desafio o Burocracia; Estgio 5 (Colaborao): forte sintonia com o negcio, maior flexibilidade, com gerentes altamente habilitados em trabalho de equipe e resoluo de controle. A figura 3 [2] mostra graficamente os estgios acima.
Figura 3: Estgios do desenvolvimento organizacional.

Gabarito preliminar: CERTO. Referncias: [1] Implantando a Governana de TI, 2 Edio. [2] Office of Government Commerce (OGC). ITIL Version 3 - Service Strategy. Editora: Stationery Office BO. Ano: 2007. Edio: 1. http://www.best-management-practice.com/officialsite.asp? FO=1245521&ProductID=9780113310456&Action=Book
76 Servio a denominao dada ao meio de se entregar valor aos clientes para facilitar a
obteno dos resultados desejados e minimizar os custos e riscos especficos. Comentrios Supondo irmos a um restaurante, ns vamos pela comida e pelo atendimento (Servio). Ao chegarmos, somos bem atendidos e recebemos um cardpio (Catlogo de Servios). Fazemos nosso pedido e esperamos. O chefe da cozinha (Pessoa) saber como fazer nosso prato (Habilidade), utilizando os ingredientes necessrios na medida certa (Recursos). Tudo isso acontece sem nos envolvermos nesse processo. Ora, se temos que nos envolver, por que vamos sair de casa para ter trabalho e ainda pagar por isso? Exemplo 1: Analogia da definio de Servio do curso de ITIL v3 do TI Exames [1]. Ento o que seria um servio? Em [2], um servio um meio de entregar valor aos clientes, facilitando o alcance nos resultados que eles querem SEM que esses participem dos custos e riscos especficos. A questo citou a minimizao dos custos e riscos especficos, entretanto, ela est errada ao dizer isso, pois, mesmo com a minimizao, ainda existem esses custos e riscos. O gabarito preliminar foi dado como certo, porm, vamos esperar pelo definitivo. Gabarito preliminar: CERTO. Referncias: [1] Fundamentos no Gerenciamento de Servios de TI com base na ITIL v3: http://tiexames.com.br/curso_itil_v3_foundation.php [2] Office of Government Commerce (OGC). ITIL Version 3 - Service Strategy. Editora: Stationery Office BO. Ano: 2007. Edio: 1. http://www.best-management-practice.com/officialsite.asp? FO=1245521&ProductID=9780113310456&Action=Book
77 A orientao complementar ITIL v.3 consiste em um conjunto de publicaes que so
destinadas a adaptar a implementao e a utilizao das prticas do ncleo da ITIL para diferentes setores empresariais, tipos de empresas e plataformas tecnolgicas. Comentrios A ITIL possui dois componentes: Ncleo da ITIL que composto pelas 5 publicaes ED TOM e Orientao Complementar ITIL. Aragon [1] cita:
Orientao Complementar ITIL: Conjunto de publicaes complementares destinadas a especializar a implementao e a utilizao das prticas do Ncleo para diferentes setores empresariais, tipos de empresas, plataformas tecnolgicas etc., concebido para ser uma biblioteca dinmica de contedo relacionado, podendo receber contribuies de toda a comunidade. Gabarito preliminar: CERTO. Referncias: [1] Implantando a Governana de TI, 2 Edio.
78 Entre as extenses que a ITIL v.3 traz em relao a sua verso anterior, esto estratgias de
servios para modelos de sourcing e de compartilhamento de servios e abordagens de retorno de investimento para servios. Comentrios Novamente, como referncia, cita-se o Aragon [1] que diz que entre as extenses que a ITIL V3 traz em relao verso anterior esto: Estratgias de servios para modelos de sourcing e de compartilhamento de servios; Abordagens de retorno sobre o investimento (ROI) para servios; Prticas de desenho de servios; Um sistema de gerenciamento de conhecimento sobre os servios; e Gerenciamento de requisies. Gabarito preliminar: CERTO. Referncias: [1] Implantando a Governana de TI, 2 Edio. Acerca dos processos e funes da ITIL v. 3, julgue os itens subsequentes.
79 O processo de gerenciamento da continuidade de servio de TI do estgio desenho de servio
abrange um desdobramento do processo de gerenciamento da continuidade do negcio, com o objetivo de assegurar que os recursos tcnicos e os servios de TI necessrios sejam recuperados dentro de um tempo preestabelecido. Comentrios Ao responder essa questo, temos que ter cuidado em dois pontos: Se o processo de Gerenciamento da Continuidade de Servio de TI se encontra na publicao do Desenho de Servio; e Se a descrio mesmo desse processo. O primeiro ponto est certo. Basta ver a tabela 2 da questo 74. Agora, vamos ver se o segundo ponto est ok. A quem podemos recorrer para conferir esse ponto? Isso! Aragon [1]! Ele descreve que o Gerenciamento de Continuidade de Servio de TI ... visa assegurar que todos os recursos tcnicos e servios de TI necessrios .... possam ser
recuperados dentro de um tempo preestabelecido. Gabarito preliminar: CERTO. Referncias: [1] Implantando a Governana de TI, 2 Edio.
80 Monitorao e controle, gerenciamento do mainframe, gerenciamento de redes e
armazenamento de dados so atividades tcnicas altamente especializadas do estgio operao de servio. Comentrios Aragon [1] fala sobre Atividades comuns da Operao de Servio. A publicao de Operao de Servio, alm de processos e funes, h um conjunto de atividades tcnicas que so altamente especializados. O objetivo dessas atividades garantir que a tecnologia requerida para a entrega e o suporte aos servios esteja funcionando em perfeito estado. Como exemplo dessas atividades, temos: Monitorao e controle; Gerenciamento do mainframe; Gerenciamento de redes; e Armazenamento de dados. Gabarito preliminar: CERTO. Referncias: [1] Implantando a Governana de TI, 2 Edio.
81 Do escopo da estratgia de servio constam os processos de gerenciamento financeiro, o de

gerenciamento do portflio de servios e o de gerenciamento da demanda. Comentrios Para responder essa questo, basta ver a tabela 2 da questo 74. Lembrando que, como dissemos na questo 74, o processo Gerao da Estratgia tambm faz parte da publicao de Estratgia de Servio. Gabarito preliminar: CERTO.
Rogrio Arajo
39
1.5 PMBoK 4 Edio

Julgue os itens que se seguem com relao 4. edio do PMBOK.
82 A estimativa anloga, tambm denominada estimativa top-down, pode ser usada para prever o
custo e o tempo de um projeto e leva em considerao informaes do histrico de projetos semelhantes e anteriores. Comentrios Dois pontos podem levar o candidato ao erro nessa questo: A estimativa anloga tambm pode ser denominada top-down? Essa tcnica pode ser usada para prever o custo e tempo de um projeto? Quanto ao primeiro ponto, o Guia do PMBok 4 Edio no diz nada sobre a outra forma de denominao. Fui encontrar a resposta na verso do ano 2000 do mesmo Guia: Estimativas por analogia. Nas estimativas por analogia, tambm chamadas de estimativas de cima para baixo (top-down), usam-se os valores reais de duraes de projetos anteriores ou similares para estimar a durao de uma atividade futura. Ela freqentemente utilizada para estimar a durao do projeto quando existe uma quantidade limitada de informaes detalhadas sobre ele (por exemplo, nas fases iniciais do projeto). Estimativas por analogia so uma forma de avaliao especializada. (Grifo meu) Essa questo bem que poderia ser anulada pelo fato de que a verso mais atual do Guia no haver essa denominao top-down. Agora vamos ao segundo ponto! Prever o custo e o tempo de um projeto! Antes de irmos ao embate do prever versus estimar, quero informar que a tcnica citada pela questo usada tanto no processo de Estimar custos do Gerenciamento de Custos quanto no processo de Estimar as duraes das atividades do Gerenciamento de Tempo. Beleza! Voltamos ao embate. Pesquisando pelo significado de cada termo, temos: Prever [1]: ver com antecipao; antever; prognosticar; e Estimar [2]: determinar o valor de uma coisa, avaliar, calcular (o preo, a quantidade). Na minha opinio, a questo deveria vir com estimar e no prever. Ao usar esse termo, tem-se a impresso de que a tcnica citada dar ao gerente o poder de antever com preciso o custo e o tempo de um projeto, o que nem sempre se consegue. Como diz o prprio Guia do PMBoK: um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Mesmo que um gerente j tenha feito uma casa de um conjunto habitacional (um projeto de produto exclusivo), por exemplo, fazer outra do mesmo conjunto (outro projeto de projeto exclusivo) pode no ter o mesmo custo e tempo do projeto anterior, pois o terreno pode ser diferente, podem no existir mo-de-obra disponvel, os preos dos itens de construo podem ter aumentado de preos, etc. Ento mais fcil estimar do que prever, penso eu, humildemente. Gabarito preliminar: CERTO. Referncias: [1] Significado de Prever: http://www.dicio.com.br/prever/ [2] Significado de Estimar: http://www.dicio.com.br/estimar/
83 Programas so grupos de projetos relacionados e um projeto, seja ele qual for, ser parte de
um programa. Comentrios No mundo dos projetos, temos [1]: Projeto: esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo; Programa: grupo de projetos relacionados gerenciados de modo coordenado para a obteno de benefcios e controle que no estariam disponveis se eles fossem gerenciados individualmente; e Portflio: conjunto de projetos ou programas e outros trabalhos, agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos de negcios estratgicos. Os projetos ou programas do portflio podem no ser necessariamente interdependentes ou diretamente relacionados. Como vemos, no todo projeto que pode fazer parte de um programa. Um projeto ter que ser NECESSARIAMENTE relacionado com os outros contidos no programa. J em um portflio, podem existir projetos que no so necessariamente relacionados. Talvez o examinador pensou nessa diferena entre programas e portflios para pregar-nos a famosa pegadinha do malandro! R! Outro ponto interessante sobre programas e portflios que aqueles, os programas, tero apenas projetos enquanto esses podero ter de projetos ou programas e outros trabalhos. Gabarito preliminar: ERRADO. Referncias: [1] Guia do PMBok 4 Edio.
84 Em uma organizao do tipo matricial forte, os gerentes de projeto tm o mais alto nvel de
autoridade e poder. Comentrios De acordo com a estrutura organizacional, a autoridade e poder de um gerente de projetos podero variar. O Guia do PMBok 4 Edio traz cinco tipos de estruturas conforme a tabela 3.
Rogrio Arajo
41
Estruturas organizacionais Caractersticas do projeto Autoridade do gerente de projetos Disponibilidade dos recursos Quem controla o oramento do projeto
Funcional Pouca ou nenhuma Pouca ou nenhuma Gerente funcional
Matricial Fraca Limitada Limitada Gerente funcional Balanceada Baixa a moderada Baixa a moderada Misto Forte Moderada a alta Moderada a alta Gerente de projetos Tempo integral Tempo integral projetos.
Projetizada Alta a quase total Alta a quase total Gerente de projetos Tempo integral Tempo integral
Funo do gerente de Tempo Tempo Tempo projetos parcial parcial integral Equipe administrativa Tempo Tempo Tempo do gerenciamento de parcial parcial parcial projetos Tabela 3: Influncias da estrutura organizacional nos
Constatamos ento que o mais alto nvel de autoridade e poder de um gerente de projetos se encontra na estrutura projetizada. Para finalizar, gostaria de trazer uma analogia da tabela 3 com a histria do Goku, do Dragon Ball [1]. Quem f de mangas e animes vai entender rapidinho. Quem no o conhece pode perguntar para seu filho adolescente que ele ir explicar ! A figura 4 traz essa analogia.
Figura 4: Goku e as estruturas organizacionais.

Gabarito preliminar: ERRADO. Referncias: [1] Dragon Ball: http://pt.wikipedia.org/wiki/Dragon_Ball Acerca de processos e reas de conhecimento da 4.a edio do PMBOK, julgue os itens seguintes.
85 A rea de conhecimento do gerenciamento do escopo do projeto abrange os seguintes
processos: coletar os requisitos, definir o escopo, desenvolver o cronograma, verificar escopo e controlar o escopo. Comentrios Essa questo uma daquelas que temos que ter muito cuidado (alis, qual questo do CESPE que no temos que ter cuidado? ). Nesse caso, o que quero enfatizar que, em uma lista de processos como essa, pode haver a possibilidade de passar batido algum que seja estranho, pois podemos j estar cansados pelo tempo da prova ou podemos no ter ateno redobrada para checar cada item da lista. Beleza? Ento a dica sair procurando algum intrometido (ou alguns), se houver, e risc-lo. Ento, vamos questo. Ela trouxe processos para saber se so da rea de conhecimento do Gerenciamento do Escopo. Os processos dessa rea so [1]: Coletar os requisitos: definio e documentao das necessidades das partes interessadas para alcanar os objetivos do projeto; Definir o escopo: desenvolvimento de uma descrio detalhada do projeto e do produto; Criar a EAP: subdiviso das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciveis; Verificar o escopo: formalizao da aceitao das entregas terminadas do projeto; e Controlar o escopo: monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanas feitas na linha de base do escopo. Porm, no meio da listagem citada pela questo, h um estranho no ninho: Desenvolver o cronograma. Esse carinha da rea de conhecimento do Gerenciamento de Tempo [1]: Definir as atividades: identificao das aes especficas a serem realizadas para produzir as entregas do projeto; Sequenciar as atividades: identificao e documentao dos relacionamentos entre as atividades do projeto; Estimar os recursos da atividade: estimativa dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que sero necessrios para realizar cada atividade; Estimar as duraes da atividade: estimativa do nmero de perodos de trabalho que sero necessrios para terminar atividades especficas com os recursos estimados; Desenvolver o cronograma: anlise das sequncias das atividades, suas duraes, recursos necessrios e restries do cronograma visando criar o cronograma do projeto; e Controlar o cronograma: monitoramento do andamento do projeto para atualizao do seu progresso e gerenciamento das mudanas feitas na linha de base do cronograma. Gabarito preliminar: ERRADO.
Referncias: [1] Guia do PMBok 4 Edio.
86 Os grupos de processos de planejamento e de monitoramento e controle servem como entrada

de um para o outro reciprocamente. Comentrios Para responder a questo, temos que entender a figura 5 [1].
Figura 5: Interaes nos processos de gerenciamento de projetos.

As setas escuras representam os relacionamento entre os grupos de processos e as setas claras, itens externos aos grupos. Observao 2: Esclarecimento sobre as setas da figura 5. Pela figura, percebemos que: Existe uma seta escura saindo do Grupo de Planejamento para de Monitoramento e Controle. Essa seta representa o fluxo do PGP (Plano de Gerenciamento de Projeto); e No existe uma seta escura fazendo o percurso contrrio do item acima. Com isso, conclumos que a questo est errada. Gabarito preliminar: ERRADO. Referncias: [1] Guia do PMBok 4 Edio.
87 A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo

realizar a anlise qualitativa de riscos, com o uso da atribuio de probabilidades numricas. Comentrios Podemos dividir a questo em duas perguntas: A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo realizar a anlise qualitativa de riscos? Essa avaliao faz uso da atribuio de probabilidades numricas? Vamos responder a primeira pergunta! A rea de conhecimento do Gerenciamento de Riscos possui os seguintes processos [1]: Planejar o gerenciamento dos riscos: definio de como conduzir as atividades de gerenciamento dos riscos de um projeto; Identificar os riscos: determinao dos riscos que podem afetar o projeto e de documentao de suas caractersticas; Realizar a anlise qualitativa dos riscos: priorizao dos riscos para anlise ou ao adicional atravs da avaliao e combinao de sua probabilidade de ocorrncia e impacto; Realizar a anlise quantitativa dos riscos: analisar numericamente o efeito dos riscos identificados, nos objetivos gerais do projeto; Planejar as respostas aos riscos: desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto; Monitorar e controlar os riscos: implementao de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao de novos riscos e avaliao da eficcia dos processos de tratamento dos riscos durante todo o projeto. Verificando o conceito do processo Realizar a anlise qualitativa dos riscos, percebemos que a resposta da primeira pergunta SIM! Vamos para a segunda pergunta! A Avaliao de probabilidade e impacto dos riscos uma das ferramentas utilizadas no processo citado, porm, o Guia do PMBoK 4 Edio no cita, em nenhum momento, que essa
avaliao faz uso da atribuio de probabilidades numricas [1]: A avaliao da probabilidade e do impacto feita para cada risco identificado. Os riscos podem ser avaliados em entrevistas ou reunies com participantes selecionados por sua familiaridade com as categorias dos riscos na agenda. So includos membros da equipe do projeto e, talvez, pessoas experientes externas ao projeto. O nvel de probabilidade de cada risco e seu impacto em cada objetivo so avaliados durante a entrevista ou reunio. Tambm so registrados detalhes explicativos, incluindo as premissas que justificam os nveis atribudos. As probabilidades e os impactos dos riscos so classificados de acordo com as definies fornecidas no plano de gerenciamento dos riscos. (Grifo meu) V-se ento que no h uso de atribuies de probabilidades numricas na ferramenta citada, o que notamos que a resposta da segunda pergunta seja NO! Entretanto, no mesmo processo, faz-se o uso da ferramenta Matriz de probabilidade e impacto que pode levar ao candidato a pensar que a questo est certa. Essa matriz especifica as combinaes de probabilidade e impacto que resultam em uma classificao dos riscos como de prioridade baixa, moderada ou alta. Podem ser usados termos descritivos ou valores numricos, dependendo da preferncia organizacional [2]. A tabela 4 mostra um exemplo dessa matriz.
Probabilidade 0,90 0,70 0,50 0,30 0,10 0,05 0,04 0,03 0,02 0,01 0,05 0,09 0,07 0,05 0,03 0,01 0,10
Ameaas 0,18 0,14 0,10 0,06 0,02 0,20 0,36 0,28 0,20 0,12 0,04 0,40 0,72 0,56 0,40 0,24 0,08 0,80 0,72 0,56 0,40 0,24 0,08 0,80
Oportunidades 0,36 0,28 0,20 0,12 0,04 0,40 0,18 0,14 0,10 0,06 0,02 0,20 0,09 0,07 0,05 0,03 0,01 0,10 0,05 0,04 0,03 0,02 0,01 0,05
Tabela 4: Matriz de probabilidade e impacto. Para entender a tabela acima, temos que: As clulas com cores mais escuras (com os nmeros maiores) representam alto risco; As clulas com cores em tom mdio (com os nmeros menores) representam baixo risco; e As clulas com cores claras (com os nmeros intermedirios) representam risco moderado. Como no mundo de projetos, os riscos podem ser tanto ameaas quanto oportunidades, a matriz tambm mostra as classificaes para riscos de oportunidades. Finalizando, os riscos podem ser priorizados para uma posterior anlise quantitativa e resposta com base na sua classificao. Acredito que o examinador tenha explorado essa definio da Matriz de probabilidade e impacto e tenha colocado propositalmente a ferramenta de Avaliao de probabilidade e impacto dos riscos.
Gabarito preliminar: ERRADO. Referncias: [1] Guia do PMBok 4 Edio. [2] Matriz de probabilidade e impacto: http://wpm.wikidot.com/tecnica:matriz-de-probabilidadee-impacto
88 As quatro possibilidades de trmino de projeto so absoro, integrao, esgotamento e

extino. Comentrios O Guia do PMBoK 4 Edio fala sobre trs formas de trmino de um projeto: Quando os objetivos tiverem sido atingidos; Quando se concluir que esses objetivos no sero ou no podero ser atingidos e o projeto for encerrado; ou Quando o mesmo no for mais necessrio. A questo citou quatro possibilidades e, com isso, acredito que a questo deveria ser anulada. Essas possibilidades foram descritas pelo Kim Heldman [1]. Gabarito preliminar: CERTO. Referncias: [1] Gerncia de Projetos - Guia Para o Exame Oficial do PMI. 3 Edio. Kim Hedman.
89 Os riscos desconhecidos podem representar uma ameaa ou uma oportunidade, por isso, o
gerente de projeto deve manter reserva dos seus recursos para control-los quando necessrio. Comentrios A rea de conhecimento Gerenciamento de Custos possui trs processos [1]: Estimar os custos: desenvolvimento de uma estimativa de custos dos recursos monetrios necessrios para terminar as atividades do projeto; Determinar o oramento: agregao dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base autorizada dos custos; e Controlar os custos: monitoramento do andamento do projeto para atualizao do seu oramento e gerenciamento das mudanas feitas na linha de base dos custos. No processo de Estimar os custos, utiliza-se a ferramenta Anlise das reservas [1]: As estimativas de custos podem incluir reservas de contingncias (algumas vezes chamadas de subsdios para contingncias) para considerar os custos das incertezas. A reserva para contingncias pode ser uma porcentagem do custo estimado, um nmero fixado ou pode ser desenvolvida atravs do uso de mtodos de anlise quantitativa. Conforme informaes mais precisas sobre o projeto se tornam disponveis, a reserva para contingncias pode ser usada, reduzida ou eliminada. Contingncias devem ser claramente
identificadas na documentao do cronograma. As reservas para contingncias so parte dos requisitos dos recursos financeiros. (Grifo meu) Gabarito preliminar: CERTO. Referncias: [1] Guia do PMBok 4 Edio.
90 Opinio especializada, auditorias de aquisies, acordos negociados e sistema de

gerenciamento de registros so recursos e tcnicas empregados no processo encerrar as aquisies. Comentrios Galera, vimos at agora que o CESPE meteu bronca nesta prova em cobrar ferramentas utilizadas nos processos. A questo atual trouxe mais algumas para sabermos se so utilizadas no processo Encerrar as aquisies. Nesse processo, as ferramentas usadas so [1]: Auditorias de aquisies; Acordos negociados; e Sistema de gerenciamento de registros. Conclumos ento que Opinio especializada no est no meio, portanto, questo errada. Gabarito preliminar: ERRADO. Referncias: [1] Guia do PMBok 4 Edio.
1.6 CMMi
A respeito de CMMI (capability maturity model integration), julgue os itens que se seguem.
121 Validao, verificao e integrao do produto so processos que integram a disciplina de

suporte ao processo de software.
122 O CMMI, que surgiu do esforo de integrao de diversos modelos que estavam sendo 123 Os nveis de maturidade do CMMI variam de 0 incompleto a 5 otimizado , que
mostram o grau de implementao dos processos da referida metodologia.
propostos no mercado, como, por exemplo, o SW-CMM, compatvel e consistente com o previsto em norma ISO a respeito desse assunto.
1.7 MPS.BR
Acerca de MPS.BR, julgue os itens de 124 a 128.
Rogrio Arajo
48
124 O plano de avaliao deve conter o roteiro para realizao da anlise de conformidade de um
processo de criao de software empresarial com o modelo MPS.BR; esse plano prega que nenhum dos processos envolvidos nessa criao deve estar fora do escopo de anlise para que se diagnostique o nvel de maturidade existente.
125 O nvel de maturidade C nvel definido do MPS.BR, alm de conter todos os processos
dos nveis anteriores, engloba tambm os processos desenvolvimento para reutilizao, gerncia de decises e gerncia de riscos.
126 Uma das principais bases tcnicas para a criao do modelo de referncia do MPS.BR foi uma
norma ISO/IEC, a qual estabeleceu uma arquitetura para o ciclo de vida dos processos de software. software durante todo o ciclo de vida deste, tendo sido desenvolvido para atender complexidade dessa atividade em organizaes de grande porte, no sendo, portanto, indicada a sua utilizao por micro ou pequenas empresas.
127 O modelo MPS.BR prev atividades, processos, produtos e equipes de desenvolvimento de
128 O MPS.BR formado por trs componentes e respectivos guias. O modelo de referncia
formado pelos guias geral, de aquisio e de implementao.
Rogrio Arajo
49
http://rogerioaraujo.wordpress.com

Pco01 Cespe 2010 Mpu Cargo25 Parteiv1

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pco01 Cespe 2010 Mpu Cargo25 Parteiv1

Enviado por

Direitos autorais:

Formatos disponíveis

http://rogerioaraujo.wordpress.

Srie Provas Comentadas

Cargo 25 Analista de Desenvolvimento de Sistemas

Parte Parte IV IV PMBoK PMBoK Rogrio Arajo

Srie Provas Comentadas

Parte III ITIL Rogrio Arajo

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

61 As ferramentas GUT (gravidade, urgncia e tendncia), o Diagrama de Pareto e a Curva de

62 Um dos objetivos da governana de TI possibilitar o alinhamento das atividades da equipe de

63 Os marcos de regulao, o ambiente de negcios, a transparncia da administrao e a

1.2 Escritrio de projetos para Governana de TI

66 O escritrio de projetos de uma organizao tem, entre outras, as seguintes atribuies:

1.3 CobiT 4.1

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

68 No modelo COBIT, o conceito de agregao de valor diz respeito proposio de valor no

69 A estrutura do COBIT foi idealizada para controlar, nas organizaes, os recursos de TI e os

75 No que diz respeito ao desenvolvimento da estratgia de servio na organizao, necessrio

79 O processo de gerenciamento da continuidade de servio de TI do estgio desenho de servio

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

armazenamento de dados so atividades tcnicas altamente especializadas do estgio operao de servio.

1.5 PMBoK 4 Edio

85 A rea de conhecimento do gerenciamento do escopo do projeto abrange os seguintes

90 Opinio especializada, auditorias de aquisies, acordos negociados e sistema de

121 Validao, verificao e integrao do produto so processos que integram a disciplina de

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

123 Os nveis de maturidade do CMMI variam de 0 incompleto a 5 otimizado , que

127 O modelo MPS.BR prev atividades, processos, produtos e equipes de desenvolvimento de

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

Contratao de Bens e Servios de TI

91 O plano diretor de tecnologia da informao (PDTI) um instrumento de diagnstico e gesto

92 A gesto de processos de TI, incluindo a gesto de segurana da informao, no pode ser

93 rea de TI considerada como uma unidade setorial ou seccional do sistema de administrao

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

4.1 Lgica de programao

104 Se um trecho de algoritmo tiver de ser executado repetidamente e o nmero de repeties

4.2 Programao Orientada a Objetos

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

137 No cdigo em Java mostrado a seguir, as classes Conta e Poupanca implementam o

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

4.4 Linguagens e tecnologias de programao

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

5.1 Engenharia de requisitos

111 A especificao de requisitos permite, em determinado momento, revelar o que o sistema ir

112 Na validao de requisitos parte integrante da especificao desses requisitos , correto

5.2 Qualidade de Software

114 O nvel mximo de qualidade de um software atingido quando os stakeholders esto

116 Na fase de elaborao do RUP, so desenvolvidas as funcionalidades do sistema e

117 Extreme programming (XP) embasado em requisitos conhecidos, definidos de antemo,

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

118 Produto da metodologia Scrum, o documento product backlog contm os requisitos

119 O plano de garantia de qualidade de software, os documentos, padres e guias a serem

120 A reviso de um projeto de software, tendo em vista a qualidade do processo de codificao,

5.3 Padres de Projetos

5.4 Processo Unificado

134 No PU, a elicitao de requisitos do sistema de software inicia-se na fase de concepo.

136 Na conveno de notao usada na UML, a chamada por mensagens assncronas

5.6 Testes de Software

CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

145 O teste de integrao geralmente um processo de teste de caixa-preta no qual os testes