Tecnologia Da Informacao - Questoes Comentadas Cespeunb - Serie Questoes - Elsevier Editora

QUESTÕES

Gledson P

vedo, M

arcelo Pa

cio Vi

Tecnologia da InformaçãoQuestões comentadasCESPE/UnB

Gledson Pompeu, Gleyson Azevedo, Marcelo Pacote e Marcio Victorino

Banco de DadosDesenvolvimento de Sistemas WebEngenharia de SoftwareGestão de Tecnologia da InformaçãoSegurança da Informação

Com código de acesso exclusivo ao site: www.dominandoti.com.br

Obrigado por adquirir o livro

TECNOLOGIA DA INFORMAÇÃO – Questões comentadas Cespe/UnB

Nesta página você tem o código para acesso gratuito a materiais de estudo complementares disponíveis no site http://www.dominandoti.com.br

A melhor preparação para concursosna área de Tecnologia da Informação

Para acessá-lo, encaminhe a confirmação de compra deste e-book para [email protected], solicitando seu código de acesso.

Cadastre-se em www.elsevier.com.brpara conhecer nosso catálogo completo,

ter acesso a serviços exclusivos no site e receber informações sobre nossos

lançamentos e promoções.

QUESTÕES

Gledson Pompeu, Gleyson Azevedo, Marcelo Pacote e Marcio Victorino

Tecnologia da InformaçãoQuestões comentadasCESPE/UnB

Banco de DadosDesenvolvimento de Sistemas WebEngenharia de SoftwareGestão de Tecnologia da InformaçãoSegurança da Informação

CIP-Brasil. Catalogação-na-fonte.Sindicato Nacional dos Editores de Livros, RJ

_________________________________________________________________________

T425

TI [recurso eletrônico] : questões comentadas CESPE/UNB / Gled-son Pompeu ... [et al.]. - Rio de Janeiro : Elsevier, 2012. recurso digital Formato: PDF Requisitos do sistema: Adobe Digital Editions Modo de acesso: World Wide We ISBN 978-85-352-6135-6 (recurso eletrônico) 1. Tecnologia da informação - Administração. 2. Sistemas de infor-mação gerencial - Problemas, questões, exercícios. 3. Serviço público - Brasil - Concursos. 4. Livros eletrônicos. I. Pompeu, Gledson.

12-2591. CDD: 658.0546 CDU: 005.94_________________________________________________________________________

© 2012, Elsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998.Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos, gravação ou quaisquer outros.

Copidesque: Carla das NevesRevisão: Daniela MarrocosEditoração Eletrônica: SBNigri Artes e Textos Ltda.

Coordenador da Série: Sylvio Motta

Elsevier Editora Ltda.Conhecimento sem FronteirasRua Sete de Setembro, 111 – 16o andar20050-006 – Centro – Rio de Janeiro – RJ – Brasil

Rua Quintana, 753 – 8o andar04569-011 – Brooklin – São Paulo – SP – Brasil

Serviço de Atendimento ao [email protected]

ISBN 978-85-352-6135-6

Nota: Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a comunicação ao nosso Serviço de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questão.

Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicação.

Aos nossos familiares, nosso agradecimento pela compreensão por todo o tempo investido na preparação deste livro.

Aos leitores, que lutam pela tão sonhada vaga no serviço público, nossa es-perança de que este livro possa ajudá-los a chegar mais rápido ao seu objetivo.

Gledson, Gleyson, Marcio e Pacote.

Dedicatória

página deixada intencionalmente em branco

Gledson Pompeu

Bacharel em Ciência da Computação pela UnB, com especializações em Administração Estratégica de Sistemas de Informação pela FGV, Gestão do Conhecimento e Inteligência Organizacional pela PUC-PR, Gestão Estratégica de Pessoas pela FIA-USP e Auditoria e Controle Governamental pelo ISC/TCU, além de detentor da certificação CGEIT (Certified in the Governance of Enterprise IT).

Auditor do Tribunal de Contas da União desde 1995, onde exerce funções relacionadas à gestão de TI desde 1999, e aprovado em 4º lugar no concurso para Consultor Legislativo do Senado Federal para a área de Comunicações e Tecnologia da Informação.

Professor de cursos preparatórios para concursos de TI desde o ano 2000, já tendo ministrado aulas sobre todos os assuntos da área. Desde 2005, tem se concentrado em modelos de gestão e governança de TI e na preparação para provas discursivas. Desde 2008 atua como coordenador de cursos presenciais em Brasília e em outras capitais, bem como de cursos online na área de TI. É responsável pela gestão de conteúdo do site Mapa da Prova (http://www.mapadaprova.com.br) e faz parte da equipe que mantém o site Dominando TI (http://www.dominandoti.com.br).

Gleyson Azevedo

Formado em Engenharia de Telecomunicações e Mestre em Segurança da Informação, ambos pelo Instituto Militar de Engenharia (IME). Atua na área de segurança há seis anos, trabalhando no Centro de Desenvolvimento de Sistemas do Exército Brasileiro.

Os Autores

Atuou como professor de cursos de graduação e pós-graduação nas áreas de Segurança da Informação e Redes de Computadores em Brasília e fre-quentemente ministra palestras em seminários e congressos. Desde 2009, é professor de Segurança da Informação e Redes de Computadores em cursos online e presenciais em diversas capitais do Brasil, além de fazer parte da equipe do site Dominando TI (http://www.dominandoti.com.br).

Marcelo Pacote

Mestre em Informática pela Universidade de Brasília (UnB), trabalha na área de arquitetura e desenvolvimento de sistemas há mais de 10 anos, atualmente como Auditor Federal de Controle Externo do Tribunal de Contas da União (TCU). Possui 11 certificações profissionais na área de TI: CSM, SCJA, SCJP, SCJD, SCWCD, SCBCD, SCEA(I), RUPF, IRUP, ITIL Founda-tions e Oracle SQL Expert.

Ministra cursos preparatórios para certificações na área de desenvolvi-mento desde 2007 e desde 2010 é professor de Desenvolvimento de Sistemas em cursos online e presenciais em diversas capitais do Brasil.

Marcio Victorino

Oficial do Exército Brasileiro formado pela Academia Militar das Agulhas Negras (AMAN) em 1988 e em Engenharia da Computação pelo Instituto Militar de Engenharia (IME) em 1994. Possui Especialização em Sistemas de Informação e Telemática pela UFRGS, Mestrado em Sistemas e Computação pelo IME e Doutorado em Ciência da Informação pela Unb. Também é pós--graduado em Gestão da Administração Pública pela Unisul.

Possui as seguintes certificações: Sun Certified Java Programmer, Sun Certified Web Component Developer, Sun Certified Business Component De-veloper, Project Management Professional, IBM Certified Solution Designer, OMG Certified UML Professional e Oracle Database 11g: SQL Fundamentals.

Trabalha na área de desenvolvimento e integração de Sistemas Corporati-vos e Gerenciamento de Projetos de TI desde 1995, quando também começou a ministrar cursos de TI. Já atuou como instrutor da disciplina gerenciamento de projetos na Escola Nacional da Administração Pública (ENAP) e, atualmen-te, é professor universitário das disciplinas de Programação OO, Engenharia de Software e Banco de Dados em cursos de graduação e pós-graduação.

Atua como professor em cursos preparatórios para concursos públicos para cargos de TI desde 2004 e é um dos mantenedores do site Dominando TI (http://www.dominandoti.com.br).

Este livro traz mais de 700 questões selecionadas criteriosamente pelos autores de modo a cobrir, de forma precisa e abrangente, os diversos assuntos cobrados nas provas aplicadas pelo Cespe nos últimos anos, nas matérias de bancos de dados, desenvolvimento de sistemas web, engenharia de software, gestão de tecnologia da informação e segurança da informação.

Na primeira parte do livro, as questões são listadas de forma sequencial, organizadas por assunto, sem o acréscimo de qualquer outro elemento além do texto e das imagens das provas originais. Sugerimos que você use as questões de cada seção como uma espécie de “simulado”, a ser respondido para avaliar o seu conhecimento de cada tema.

Na segunda parte do livro, o gabarito oficial de cada questão é apresen-tado, seguido de comentários diretos e objetivos para que você possa enten-der claramente o motivo de ter errado determinadas questões. Em muitos casos, esses comentários vêm acompanhados de breves resumos da matéria, pequenos “lembretes” sobre tópicos importantes para que você não erre mais questões sobre aquele assunto específico. No caso de questões anuladas, ou com gabarito questionável, é apresentada a visão dos autores sobre qual deveria ter sido a resposta correta, com base na bibliografia consagrada de cada assunto.

Ao final do livro, você encontra ainda as referências bibliográficas re-comendadas para o estudo de cada uma das matérias, várias delas citadas pontualmente nos comentários das questões.

Apresentação

Durante os mais de 10 anos dedicados à preparação para concursos pú-blicos na área de TI, tive a oportunidade de mostrar a milhares de candidatos a importância de aliar o estudo teórico à resolução de questões de provas anteriores. Nos cursos teóricos, em cursos de exercícios ou em “aulões” em que eram resolvidas todas as questões de determinadas provas, a conclusão coletiva era sempre a mesma: não adianta saber só a teoria; é funda-mental saber como essa teoria é cobrada, conhecer os macetes e a “jurisprudência” de cada banca – entendimentos específicos (e muitas vezes questionáveis) que são adotados pelas bancas na hora de definir o ga-barito das questões.

Ao longo desse tempo, conseguimos reunir uma equipe de professores altamente especializados, que aliam o conhecimento sólido das respectivas matérias a um entendimento completo sobre a forma como essas matérias são cobradas. Esta equipe, a que hoje chamamos “Dominando TI”, começou dando aulas nos cursos preparatórios de Brasília, onde a chamada “indús-tria dos concursos” é mais forte. Depois, vieram os cursos online, por meio de vídeoaulas e de redes de teleconferência. Nos últimos dois anos, em um esforço de democratização do conhecimento, passamos a ministrar aulas presenciais em outras capitais: Belo Horizonte, Rio de Janeiro, Fortaleza, Recife e Salvador.

Agora, atendendo aos pedidos de ex-alunos e outros interessados, re-solvemos dar mais um passo para levar uma preparação de excelência aos candidatos de todas as localidades, com a edição de livros específicos para concursos na área de TI. Este é apenas o primeiro volume de uma coleção que pretende ser extensa – cobrindo todos os assuntos e as principais bancas organizadoras de concursos para essa área.

Palavras da Coordenação da Obra

Para mais detalhes sobre os livros publicados ou planejados, acesse a seção de Livros do nosso site, em http://www.dominandoti.com.br.

Para terminar, quero apenas lembrar que a aprovação em concursos públicos sempre foi, e continuará sendo, mérito dos candidatos que dedicam semanas, meses e às vezes anos de suas vidas aos estudos. O nosso papel, como professores, é fazer com que esse caminho possa ser trilhado de forma mais eficiente, ao mostrar os atalhos e armadilhas espalhados ao longo da estrada.

Sucesso a todos!

Gledson Pompeu

PARTE 1QUESTÕES PARA RESOLUÇÃO

Capítulo 1 Questões de BanCo de dados ......................................... 31.1. Modelagem de Dados ................................................................................... 31.2. Normalização ............................................................................................... 91.3. Álgebra Relacional ..................................................................................... 111.4. Transações ................................................................................................. 121.5. Arquitetura de Banco de Dados e Bancos de Dados Distribuídos ........... 141.6. Arquitetura OLAP ..................................................................................... 15

Capítulo 2 Questões de desenvolvimento de sistemas WeB ..........172.1. Linguagem Java ......................................................................................... 17

2.1.1. Sintaxe, características e APIs .......................................................172.1.2. Orientação a objetos com Java .......................................................20

2.2. Padrões de Projeto ..................................................................................... 232.3. Arquitetura Java EE ................................................................................. 25

2.3.1. JSP/Servlets, EJB e Servidores de Aplicação ................................252.3.2. JSF ...................................................................................................292.3.3. JPA/Hibernate .................................................................................29

2.4. Desenvolvimento Web (lado cliente) ......................................................... 302.5. Interoperabilidade de sistemas Web ......................................................... 34

2.5.1. XML .................................................................................................352.5.2. Web Services ....................................................................................362.5.3. SOA ..................................................................................................39

Sumário

Capítulo 3 Questões de engenharia de softWare ..........................413.1. Análise por Pontos de Função ................................................................... 41

3.1.1. Conceitos básicos de APF ...............................................................413.1.2. APF segundo o IFPUG ....................................................................423.1.3. APF segundo a NESMA ..................................................................433.1.4. Aplicações da APF ...........................................................................43

3.2. Modelos de Processos de Desenvolvimento de Software ......................... 443.3. Processo Unificado .................................................................................... 463.4. Processos Ágeis .......................................................................................... 493.5. Engenharia de Requisitos ......................................................................... 523.6. Arquitetura de Software ........................................................................... 553.7. Qualidade de Software .............................................................................. 563.8. Orientação a Objetos ................................................................................. 593.9. Unified Modeling Language (UML).......................................................... 61

Capítulo 4 Questões de gestão de teCnologia da informação .....734.1. Gerenciamento de Projetos ....................................................................... 73

4.1.1. Conceitos básicos de gerenciamento de projetos ...........................744.1.2. Portfólios, programas e estruturas organizacionais ......................744.1.3. Escritórios de projetos e outras partes interessadas .....................754.1.4. Ciclo de vida e grupos de processos ................................................764.1.5. Gerência de integração....................................................................774.1.6. Gerência de escopo ..........................................................................784.1.7. Gerência de tempo ...........................................................................784.1.8. Gerência de custos ...........................................................................794.1.9. Gerência de riscos............................................................................804.1.10. Gerências de qualidade, RH, comunicações e aquisições ..............80

4.2. Qualidade de Software .............................................................................. 814.2.1. CMMI – Conceitos básicos e estrutura ...........................................824.2.2. CMMI – Níveis de capacidade e maturidade ..................................824.2.3. CMMI – Áreas de Processo .............................................................834.2.4. MPS.BR – Conceitos básicos e níveis de maturidade ....................854.2.5. MPS.BR – Processos ........................................................................87

4.3. Gerenciamento de Serviços ....................................................................... 874.3.1. ITIL – Conceitos básicos e estrutura do modelo ............................884.3.2. ITIL – Estratégia de serviços ..........................................................884.3.3. ITIL – Desenho de serviços .............................................................894.3.4. ITIL – Transição de serviços ..........................................................90

Tecnologia da Informação – Questões Comentadas I Cespe / UnB

XIV

ELSEVIER

4.3.5. ITIL – Operação de serviços ...........................................................914.3.6. ITIL – Melhoria contínua de serviços ............................................92

4.4. Governança de TI ...................................................................................... 934.4.1. Cobit – Conceitos básicos ...............................................................934.4.2. Cobit – Características gerais .........................................................944.4.3. Cobit – Modelo de maturidade ........................................................964.4.4. Cobit – Domínios e processos ..........................................................97

4.5. Planejamento e Gestão Estratégica de TI ................................................ 99

Capítulo 5 Questões de segurança da informação ......................1035.1. Conceitos básicos de Segurança da Informação ..................................... 1035.2. Criptografia – Conceitos, algoritmos e protocolos ................................. 1045.3. Assinatura digital, certificação digital e PKI ......................................... 1105.4. Ameaças, vulnerabilidades e ataques ..................................................... 1115.5. Dispositivos e sistemas de proteção ........................................................ 1135.6. Normas ABNT NBR ISO/IEC 27001 e 27002 – Gestão de segurança

da informação........................................................................................... 1175.7. Norma ABNT NBR ISO/IEC 27005 – Gestão de riscos em segurança

da informação........................................................................................... 1235.8. Norma ABNT NBR 15999 – Gestão da continuidade de negócios ........ 124

PARTE 2GABARITOS COMENTADOS

Capítulo 1 gaBaritos de BanCo de dados .....................................1291.1. Modelagem de Dados ............................................................................... 1291.2. Normalização ........................................................................................... 1371.3. Álgebra Relacional ................................................................................... 1391.4. Transações ............................................................................................... 1411.5. Arquitetura de Banco de Dados e Bancos de Dados Distribuídos ......... 1451.6. Arquitetura OLAP ................................................................................... 146

Capítulo 2 gaBaritos de desenvolvimento de sistemas WeB .......1492.1. Linguagem Java ....................................................................................... 149

2.1.1. Sintaxe, características e APIs .....................................................1492.1.2. Orientação a objetos com Java ....................................................151

2.2. Padrões de Projeto ................................................................................... 1542.3. Arquitetura Java EE ............................................................................... 156

I Sumário

XV

2.3.1. JSP/Servlets, EJB e Servidores de Aplicação ..............................1562.3.2. JSF .................................................................................................1602.3.3. JPA/Hibernate ...............................................................................161

2.4. Desenvolvimento Web (lado cliente) ....................................................... 1622.5. Interoperabilidade de sistemas Web ....................................................... 166

2.5.1. XML ...............................................................................................1662.5.2. Web Services ..................................................................................1672.5.3. SOA ................................................................................................170

Capítulo 3 gaBaritos de engenharia de softWare .......................1723.1. Análise por Pontos de Função ................................................................. 172

3.1.1. Conceitos básicos de APF ............................................................1723.1.2. APF segundo o IFPUG ..................................................................1743.1.3. APF segundo a NESMA ................................................................1763.1.4. Aplicações da APF .........................................................................177

3.2. Modelos de Processos de Desenvolvimento de Software ...................... 1783.3. Processo Unificado .................................................................................. 1823.4. Processos Ágeis ........................................................................................ 1863.5. Engenharia de Requisitos ....................................................................... 1903.6. Arquitetura de Software ......................................................................... 1943.7. Qualidade de Software ............................................................................ 1953.8. Orientação a Objetos ............................................................................... 2013.9. Unified Modeling Language (UML)........................................................ 204

Capítulo 4 gaBaritos de gestão de teCnologia da informação ..2134.1. Gerenciamento de Projetos ..................................................................... 213

4.1.1. Conceitos básicos de gerenciamento de projetos .........................2134.1.2. Portfólios, programas e estruturas organizacionais ....................2154.1.3. Escritórios de projetos e outras partes interessadas ...................2164.1.4. Ciclo de vida e grupos de processos ..............................................2184.1.5. Gerência de integração..................................................................2204.1.6. Gerência de escopo ........................................................................2224.1.7. Gerência de tempo .........................................................................2234.1.8. Gerência de custos .........................................................................2254.1.9. Gerência de riscos..........................................................................2264.1.10. Gerências de qualidade, RH, comunicações e aquisições ............228

4.2. Qualidade de Software ............................................................................ 2314.2.1. CMMI – Conceitos básicos e estrutura .........................................2314.2.2. CMMI – Níveis de capacidade e maturidade ................................232


XVI

ELSEVIER

4.2.3. CMMI – Áreas de Processo ...........................................................2354.2.4. MPS.BR – Conceitos básicos e níveis de maturidade ..................2394.2.5. MPS.BR – Processos ......................................................................241

4.3. Gerenciamento de Serviços ..................................................................... 2424.3.1. ITIL – Conceitos básicos e estrutura do modelo ..........................2424.3.2. ITIL – Estratégia de serviços ........................................................2444.3.3. ITIL – Desenho de serviços ...........................................................2464.3.4. ITIL – Transição de serviços ........................................................2484.3.5. ITIL – Operação de serviços .........................................................2494.3.6. ITIL – Melhoria contínua de serviços ..........................................252

4.4. Governança de TI .................................................................................... 2524.4.1. Cobit – Conceitos básicos .............................................................2524.4.2. Cobit – Características gerais .......................................................2554.4.3. Cobit – Modelo de maturidade ......................................................2574.4.4. Cobit – Domínios e processos ........................................................259

4.5. Planejamento e Gestão Estratégica de TI .............................................. 263

Capítulo 5 gaBaritos de segurança da informação .....................2665.1. Conceitos básicos de Segurança da Informação .................................... 2665.2. Criptografia – Conceitos, algoritmos e protocolos ................................. 2685.3. Assinatura digital, certificação digital e PKI ......................................... 2755.4. Ameaças, vulnerabilidades e ataques ..................................................... 2775.5. Dispositivos e sistemas de proteção ........................................................ 2805.6. Normas ABNT NBR ISO/IEC 27001 e 27002 – Gestão de segurança

da informação........................................................................................... 2875.7. Norma ABNT NBR ISO/IEC 27005 – Gestão de riscos em segurança da

informação ............................................................................................... 2945.8. Norma ABNT NBR 15999 – Gestão da continuidade de negócios ........ 295

PARTE 3REFERÊNCIAS BIBLIOGRÁFICAS

Capítulo 1 referênCias BiBliográfiCas ........................................2991.1. Referências de Bancos de Dados ............................................................. 2991.2. Referências de Desenvolvimento de Sistemas Web ............................... 2991.3. Referências de Engenharia de Software ................................................. 3001.4. Referências de Gestão de Tecnologia da Informação ............................. 3001.5. Referências de Segurança da Informação .............................................. 301

I Sumário

XVII

Parte 1 Questões

para resolução

Parte 1

Questões para

resolução

C a p í t u l o 1

Questões de Banco de Dados

1.1. Modelagem de Dados

A disciplina de Banco de Dados (BD) é bastante relevante em concursos para a área de tecnologia da informação. Os principais autores que abordam essa disciplina de forma completa, independente de banca examinadora, são Navathe, Korth e Date. No entanto, pode-se perceber que ultimamente as questões de BD do Cespe têm sido embasadas, principalmente, na abordagem dos autores Navathe e Korth.

Este é o assunto mais cobrado em questões de concurso sobre BD. Um autor muito didático para este assunto é Carlos Alberto Heuser, em seu livro “Projeto de Banco de Dados”. As questões de modelagem abordam, principalmente, modelo entidade rela-cionamento, tal como proposto por Peter Chen, e cardinalidade de relacionamentos.

1. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Em um modelo entidade--relacionamento, as entidades fracas não possuem seus próprios atributos--chave. Elas possuem sempre restrição de participação total, também co-nhecida como dependência de existência em relação a seu relacionamento identificador. Esse tipo de restrição ocorre porque uma entidade fraca não pode ser identificada sem um tipo identificador.

2. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) Atributos derivados são atributos cujos valores estão relacionados aos atributos armazenados. Como exemplo, tem-se o atributo idade, que está relacionado ao atributo data de nascimento; assim, armazena-se o atributo data de nascimento e o atributo idade é derivado do atributo armazenado.

3. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) A restrição de integridade de entidade estabelece que nenhum valor de chave primária e chave estrangeira pode ser nulo. Se houver valores nulos para as chaves, então não será possível identificar alguma tupla.

4. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) Uma restrição importante das entidades de um tipo entidade

é a chave ou restrição de unicidade. Um tipo entidade tem, geralmente, um ou mais atributos, denominado atributo-chave, cujos valores são distintos para cada uma das entidades do conjunto de entidades e podem ser usados para identificar cada entidade univocamente.

5. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Em um banco de dados relacional, os dados são armazenados em tabelas compostas por uma simples estrutura de linhas e colunas. As tabelas se relacionam por meio de chaves, criando tipos de relacionamento no modelo de entidade e relacionamento. Uma chave estrangeira implementa restrições nos sistemas gerenciadores de bancos de dados relacionais.

6. (MPU/Analista de Informática/Banco de Dados/2010) Na construção de um banco de dados relacional, a vinculação entre as entidades conceituais e as tabelas implementadas no banco de dados é biunívoca, ou seja, cada entidade conceitual dá origem a uma única tabela.

7. (MPU/Analista de Informática/Banco de Dados/2010) Em um banco de dados relacional, os valores que compõem um índice em uma tabela não podem ser repetidos em outro registro da mesma tabela.

8. (MPU/Analista de Informática/Banco de Dados/2010) Considerando uma tabela AUTOMOVEL, que tenha como atributo ANO_DE_FABRICACAO, para o qual exista uma restrição que estabelece o limite mínimo para seu valor, a forma mais ade-quada de implementar essa restrição seria por meio da definição de um trigger.

Considerando o diagrama entidade-relacionamento (E-R) na figura acima, julgue o próximo item.

9. (MPU/Analista de Informática/Banco de Dados/2010) No modelo E-R da figura, os atributos de uma agregação, de modo geral, coincidem com os atributos do relacionamento que são englobados.

10. (MPU/Analista de Informática/Banco de Dados/2010) Considere a seguinte situação hipotética. Em determinada organização, os funcionários (entidade F) associam-se


4

ELSEVIER

aos departamentos (entidade D), por meio do relacionamento de lotação (L), sendo N funcionários em 1 departamento (N:1). Também pode ocorrer, concomitantemente com a lotação, o relacionamento gerencial (G), do tipo 1:1, ou seja, um funcioná-rio gerencia no máximo um departamento. Como restrição da organização, todo gerente deve estar lotado obrigatoriamente no departamento que dirige. Nessa situação, é correto afirmar que, na referida organização, verifica-se um exemplo de restrição de integridade envolvendo relacionamentos.

11. (MPU/Analista de Informática/Banco de Dados/2010) O termo integridade é uti-lizado em sistema de banco de dados com o significado de precisão, correção ou validade. Nesse contexto, a integridade tem como função assegurar que os dados no banco de dados sejam precisos e preservados contra atualizações válidas.

12. (TRT21-RN/Analista Judiciário/Tecnologia da Informação/2010) A chave can-didata, conjunto de um ou mais atributos tomados coletivamente, permite identificar de maneira unívoca uma entidade em um conjunto de entidades.

13. (TRT21-RN/Analista Judiciário/Tecnologia da Informação/2010) Uma chave es-trangeira é um atributo ou uma combinação de atributos em uma relação, cujos valores são necessários para equivaler somente à chave primária de outra relação.

Capítulo 1 I Questões de Banco de Dados

5

A figura acima apresenta um modelo de banco de dados denominado ER1, no qual são representadas informações acerca de comissões, compostas por vários membros, os quais se reúnem periodicamente para discutir e votar propostas. Suponha que um modelo relacional denominado R1 seja gerado a partir do modelo ER1. Nesse contexto, julgue os itens seguintes, acerca das informações apresentadas e dos conceitos de bancos de dados.

14. (ANATEL/Analista Administrativo/Análise de Negócios/2009) ER1 é um modelo lógico.

15. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Em R1, o relacio-namento “presença” será representado por meio de uma tabela que contém pelo menos quatro colunas, sendo duas delas chaves estrangeiras.

16. (ANATEL/Analista Administrativo/Análise de Negócios/2009) ER1 está na terceira forma normal.

17. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Em R1, os ele-mentos “Reunião” e “Proposta” são relações que contêm, cada uma, uma ou mais chaves estrangeiras.

18. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Em R1, uma operação de junção efetuada entre as relações “Comissão” e “Reunião” utilizaria adequa-damente os atributos “cod_comissão” e “cod_reunião” como atributos de junção.

19. (ANATEL/Analista Administrativo/Análise de Negócios/2009) São propriedades ou limitações do modelo ER1: uma comissão pode ser composta por um número arbitrário de pessoas; uma pessoa pode participar de um número arbitrário de comissões; cada proposta é encaminhada em apenas uma reunião; e uma pessoa pode ter presença em reuniões de comissões das quais ela não faz parte.

20. (ANTAQ/Analista Administrativo/Informática/2009) A abordagem relacional parte do princípio de que os dados são percebidos como tabelas que satisfazem relações de integridade manipuláveis por meio de operadores.

21. (ANTAQ/Analista Administrativo/Informática/2009) Um diagrama entidade--relacionamento permite uma representação, em forma de figura, da estrutura física de um banco de dados.

22. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Dado um conjunto de relacionamentos R binário entre os conjuntos de entidades A e B, é correto afirmar que, em um mapeamento de cardinalidade muitos para muitos, uma entidade A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A.

23. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) As carac-terísticas do atributo CEP — numérico, sequencial e não repetido — permitem utilizá-lo como chave primária em um banco de dados destinado ao cadastro de clientes de uma loja.

24. (STF/Analista Judiciário/Análise de Sistemas de/2008) Qualquer relação que não faça parte do modelo lógico, mas seja visível para o usuário como uma relação virtual, é denominada visão.


6

ELSEVIER

25. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Integri-dade referencial pode ser definida como uma condição imposta a um conjunto de atributos de uma relação para que valores que apareçam nesse conjunto também apareçam em um certo conjunto de atributos de uma outra relação.

26. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Chaves estrangeiras podem ser definidas como sendo um conjunto de atributos pertencentes a um esquema de relação que constituem chaves primárias ou candidatas em outros esquemas independentes.


7

Considerando as figuras I e II acima, que apresentam, respectivamente, um modelo de entidades e relacionamentos e um esquema resumido do banco de dados relacional, julgue os três itens subsequentes.

27. (STJ/Analista Judiciário/Informática/2008) Segundo a figura I, para identifi-car uma entidade do tipo CRIANCA, é necessário identificar uma entidade do tipo HOSPEDE; para cada entidade do tipo HOTEL, o atributo NOME tem valor único; para cada entidade do tipo FUNCIONARIO, o atributo APELIDO pode ter um conjunto de valores. O atributo HORAS pode ser migrado para a entidade FUNCIONARIO.

28. (STJ/Analista Judiciário/2008) Segundo a figura I, o número de horas que um funcionário trabalha em um hotel é determinado combinando-se entidades dos tipos HOTEL e FUNCIONARIO; uma entidade do tipo HOTEL pode estar associada a apenas uma entidade do tipo HOSPEDE; os valores do atributo NOME são distintos para cada entidade do tipo CRIANCA.

29. (STJ/Analista Judiciário/Informática/2008) A partir do modelo de entidades e relacionamentos e do esquema resumido do banco de dados relacional, é correto inferir que o esquema descreve incorretamente parte do projeto de um banco de dados para o modelo apresentado, uma vez que há atributos e entidades incorretamente mapeados para as relações.

30. (TST/Analista Judiciário/Análise de Sistemas/2008) No modelo relacional, cada tupla em uma relação deve ser distinta das demais por definição.

31. (TST/Analista Judiciário/Análise de Sistemas/2008) Uma chave primária é usada para identificar tuplas individuais em uma relação, não podendo ter o valor nulo.

32. (TST/Analista Judiciário/Análise de Sistemas/2008) A existência de uma tupla em uma relação que faz referência a uma tupla não-existente em outra relação constitui uma violação das restrições de chave da primeira relação.

33. (TST/Analista Judiciário/Análise de Sistemas/2008 No modelo entidade-rela-cionamento (ER), a modelagem analisa e representa os dados da aplicação de forma independente do processamento que transforma os dados.

34. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) Em um banco de dados, o grau de um tipo relacionamento é o número de tipos entidade que participam desse relacionamento. Um tipo relacionamento binário tem grau dois e um ternário tem grau três.

35. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) A razão de cardinalidade para um tipo relacionamento binário especifica o número má-ximo de instâncias de relacionamento em que uma entidade pode participar. 1:1, 1:N, N:1 e M:N, por exemplo, são possíveis razões de cardinalidade para um tipo relacionamento binário.


8

ELSEVIER

36. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) Há atributos cujos valores são relacionados, como, por exemplo, idade e data de nascimento, pois, para uma pessoa, a idade pode ser calculada a partir da data atual e da data de nascimento. Diz-se, assim, que a idade é um atributo derivado e que a data de nascimento é um atributo armazenado.

37. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) Há casos em que um tipo entidade participa, em papéis diferentes, mais de uma vez em um tipo relacionamento. Por exemplo, em uma associação entre subordinado e chefe na qual ambos são do tipo Empregado, podem-se usar nomes de papéis para definir o significado de cada participação.

38. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) Atributos compostos podem ser divididos em partes menores. Por exemplo, um endereço pode ser dividido em rua e cidade. Atributos que não são divisíveis são ditos simples ou atômicos.

39. (MPE-RR/Analista Judiciário/Analista de Banco de Dados/2008) Um tipo en-tidade cujas entidades são identificadas a partir apenas dos valores dos seus atributos-chave é um tipo entidade fraca. Em contraste, um tipo entidade cujas entidades são identificadas por estarem relacionadas a entidades específicas de outro tipo entidade são do tipo entidade forte.

1.2. Normalização

As questões sobre normalização concentram-se em cobrar conceitos relacio-nados à primeira, segunda e terceira formas normais. As demais formas normais são cobradas esporadicamente e de forma bem superficial.

40. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) Quando um esquema de relação tem mais de uma chave, cada uma delas é denominada chave-candidata, e, nesse caso, deve-se decompor a relação com base nas dependências funcionais até que somente uma chave primária permaneça na relação.

41. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) Um atributo Y possui uma dependência funcional do atributo X se, para cada valor do atributo X, existe exatamente um único valor do atributo Y. A dependência funcional é representada por X -> Y.

42. (MEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011) A normalização de dados é o processo da análise de deter-minados esquemas de relações com base em suas dependências funcionais e chaves primárias. Esse processo visa alcançar as propriedades desejáveis de maximização da redundância e de minimização das anomalias de inserção, exclusão e atualização.


9

43. (MPU/Analista de Informática/Banco de Dados/2010) Uma relação está na se-gunda forma normal (2FN) se e somente se estiver na 1FN e qualquer atributo da chave for dependente funcional (DF) completo em relação a cada chave, tal que não há atributo fora da chave que seja DF parcial em relação a cada chave.

44. (MPU/Analista de Informática/Banco de Dados/2010) Se os valores de atributos forem atômicos, ou seja, estiverem vinculados a um modelo relacional unitá-rio, então nem todas as relações estarão normalizadas ou na primeira forma normal (1FN), segundo definido pela álgebra relacional.

45. (TRT21-RN/Analista Judiciário/Tecnologia da Informação/2010) A primeira forma normal estabelece que os atributos da relação contêm apenas valores atômicos.

46. (TRT21-RN/Analista Judiciário/Tecnologia da Informação/2010) A dependência funcional é uma associação que se estabelece entre dois ou mais atributos de uma relação e define-se do seguinte modo: se A e B são atributos ou conjuntos de atributos, da relação R, diz-se que B é funcionalmente dependente de A se cada um dos valores de A em R tem associado a si um e um só valor de B em R.

47. (ANTAQ/Analista Administrativo/Informática/2009) São objetivos da nor-malização: eliminar redundâncias, evitar erros de atualização e facilitar tanto a representação do mundo real quanto a imposição de restrições de integridade.

48. (ANTAQ/Analista Administrativo/Informática/2009) A reversibilidade é um aspecto da normalização que permite que esta ocorra sem perdas de dados e relações, preservando-se as informações do banco de dados.

49. (STJ/Analista Judiciário/Informática/2008) A normalização é um processo no qual são analisados esquemas de relações, com base em dependências fun-cionais e chaves primárias, visando minimizar redundâncias e anomalias de inserção, exclusão e atualização. Na normalização, se ocorrer a decomposição de uma relação, cada dependência funcional existente antes da decomposição terá de ser representada em alguma relação existente depois da decomposição.

50. (STJ/Analista Judiciário/Informática/2008) O teste para a segunda forma normal envolve verificar se os atributos do lado esquerdo das dependências funcionais são parte da chave primária. Nas dependências funcionais apresen-tadas na tabela abaixo, as relações atendem aos requisitos da segunda forma normal.

relação chave primária dependência funcionalR1 CPF CPF > NOME, CGCR2 NOME, CPF NOME, CPF > IDADE

R3 CGCCGC > RUA, CIDADE, ESTADO,

NOMER4 CGC, CPF CGC, CPF> HORAS


10

ELSEVIER

51. (STJ/Analista Judiciário/Informática/2008) A partir das dependências funcio-nais apresentadas na tabela a seguir, é correto inferir que as relações estão na terceira forma normal, pois: as relações só contêm atributos atômicos; para as relações que possuem chaves primárias com vários atributos, ne-nhum atributo externo à chave é funcionalmente dependente de parte da chave primária; há dependência transitiva entre atributo não-chave e chave primária.

relação chave primária dependência funcional

R1 CPFCPF > AUTOR

AUTOR > TELEFONE

R2 ISBN, CAPITULOISBN, CAPÍTULO > AUTO

RISBN> TITULOR3 EDITORA EDITORA > NOME, EDITOR

52. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) A FNBC exige que todas as dependências não-triviais sejam da forma α→β, em que α é uma superchave. A terceira forma normal (3FN) também não suaviza essa restrição.

53. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Um esquema de uma relação que se encontra na primeira forma normal apresenta atributos compostos que podem ser multivalorados.

1.3. Álgebra Relacional

A Álgebra Relacional abrange uma coleção de operações usadas para mani-pular registros em tabelas. É uma maneira formal de se responder às demandas dos usuários do Banco de Dados.

54. (MPU/Analista de Informática/Banco de Dados/2010) A interseção X INTERSECT Y, em que X e Y são duas relações, é o conjunto de todas as tuplas pertencentes a ambas as relações X e Y.

55. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) A opera-ção de junção externa (outer join) é uma extensão da operação de junção para tratar informações omitidas.

56. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Apenas as operações union e intersect são disponibilizadas pela linguagem SQL para manipulação de conjuntos.

57. (TST/Analista Judiciário/Análise de Sistemas/2008) Duas relações de mesmo grau e com atributos correspondentes que pertencem ao mesmo domínio são compatíveis quanto à operação UNION.


11

58. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) A álgebra relacional consiste em um conjunto de operações e relações, sendo que cada operação usa uma ou mais relações com seus operandos e produz outra relação como seu resultado.

59. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) Segundo C. J. Date, o conjunto de operadores tradicionais na álgebra relacional é formado por união, interseção, diferença e produto cartesiano e os operadores relacionais especiais são seleção, projeção, junção e divisão.

60. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) A interseção de duas relações (compatíveis de união) X e Y – X INTERSECT Y – é o conjunto de todas as tuplas t pertencentes a X e a Y.

61. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) O produto cartesiano de duas relações X e Y – X TIMES Y – é o conjunto de todas as tuplas t, em que t é a concatenação de uma tupla x, pertencente a X, com uma tupla y, pertencente a Y.

62. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) A cláusula select corresponde à seleção do predicado da álgebra relacional. Ela consiste em um predicado envolvendo atributos da relação que aparece na cláusula from.

63. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) A cláusula where corresponde à operação de projeção da álgebra relacional.

1.4. Transações

No passado, as questões sobre transação cobravam apenas as propriedades dos SGBDs Atomicidade, Consistência, Isolamento e Consistência (ACID). No entanto, atualmente pode-se perceber questões mais elaboradas cobrando es-tratégias de lock e o entendimento de protocolos de serialização de transações.

64. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Para o SGBD viabilizar a execução de transações concomitantemente existem diversas téc-nicas e controle de concorrência que são utilizadas para garantir propriedade de não-interferência ou isolamento de transações. Uma dessas técnicas é o controle de concorrência baseado em ordenamento de registro de timestamp que utiliza o bloqueio combinado com o Protocol Two-Phase locking (2PL).

65. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Um escalonamento é considerado correto quando se pode encontrar um esca-lonamento serial que seja equivalente a ele. Dado um conjunto de transações T1,...,Tn, dois escalonamentos S1 e S2 são equivalentes se existe sincronização read-write e sincronização write-write.


12

ELSEVIER

66. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) No two-phase locking, os locks de dados supõem que a transação está dividida em uma fase de crescimento, na qual os locks são feitos, e em uma fase de encolhimento, na qual os locks são confirmados.

T1lock(p1)read(p1)

write(p1)lock(p2)unlock(p1)

read(p2)write(p2)unlock(p2)

T2

lock(p1)

read(p1)write(p1)lock(p2)unlock(p1)

read(p2)write(p2)unlock(p2)

Considerando as transações T1 e T2 apresentadas acima, julgue os itens subsequentes.

67. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Na situação em questão, a transação T2 pode ver os writes incrementais de T1. Esse enfoque diminui a concorrência do sistema.

68. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Se, por alguma razão, a transação T1 for abortada, o requerimento de atomicidade impli-cará que também sejam abortadas as transações como T2, aquelas que igualmente tenham visto os resultados de T1, transações que tenham visto os writes dessas transações e assim por diante. Esse problema é conhecido como rollback em cascata.

69. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Quando uma regra de integridade referencial é violada, o procedimento normal a ser adotado é rejeitar a ação que ocasionou essa violação.

70. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) A execução de transações de maneira concorrente possibilita o surgimento de inconsis-tências dos dados armazenados em um banco de dados. A responsabilidade pela consistência dos dados é única e exclusiva do banco de dados, mais es-pecificamente, do componente de controle de concorrência.


13

71. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) As proprie-dades dos sistemas de banco de dados conjuntamente denominadas ACID são consistência, isolamento e durabilidade. Elas asseguram a integridade dos dados nas transações.

72. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) Quando mudan-ças causadas por uma transação abortada são desfeitas, a transação foi commited; enquanto uma transação completada com sucesso é chamada de rolled back.

73. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/2008) Em relação ao término com sucesso de uma transação, os possíveis estados são: ativa, em efetivação parcial, em falha, abortada e em efetivação. Uma transação é dita concluída se estiver em efetivação ou abortada.

74. (BASA/Tecnologia da Informação/Banco de Dados/2010) Um update lock insere um bloqueio no objeto para impedir que outros usuários façam alterações, porém não é ativado quando já existe um shared lock ou um exclusive lock no mesmo objeto.

75. (BASA/Tecnologia da Informação/Banco de Dados/2010) Uma transação do tipo dirty read lê todos os registros, não importando se estão sendo modificados ou se ainda não houve um commit.

1.5. Arquitetura de Banco de Dados e Bancos de Dados Distribuídos

O Cespe aborda a arquitetura de Sistemas Gerenciadores de Banco de Da-dos (SGBDs) de várias formas. No entanto, o conceito mais cobrado tem sido a arquitetura em três esquemas. Em SGBDs distribuídos, a cobrança mais comum abrange conceitos relacionados a transações distribuídas, Commit em Duas Fases ou em Três Fases.


14

ELSEVIER

Considerando a figura acima, que ilustra uma arquitetura de banco de dados de três esquemas, julgue os itens subsequentes (76 à 79).

76. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) Em razão de a independência de dados, provida pela arquitetura em tela, permitir a execução mais eficiente de consultas no sistema gerenciador de banco de dados (SGBD), os mais conhecidos SGBDs comerciais implementam a arquitetura de banco de dados de três esquemas por completo.

77. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) O acesso do usu-ário ao banco de dados, que ocorre no nível do “esquema externo”, classifica--se em interativo ou em modo batch. No primeiro caso, ocorre por meio de uma sublinguagem de dados, tal como a SQL; e, no segundo, por meio de um programa aplicativo, escrito em Java, C++ ou C, que contém um subconjunto de comandos que disponibilizam uma sublinguagem de dados.

78. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) Na arquitetura em questão, a independência lógica de dados consiste na capacidade de alterar o “esquema interno” sem mudar o “esquema conceitual”.

79. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) Devido à indepen-dência de dados, provida pela referida arquitetura, as modificações do “esque-ma conceitual” — tais como a adição ou a remoção de um tipo de registro (ou item) de dados — não causam ou requerem alterações no “esquema externo” ou nos programas de acesso ao banco de dados.

1.6. Arquitetura OLAP

Data Warehouse (DW) e Data Mining são os assuntos mais cobrados rela-cionados à Arquitetura OLAP. Este assunto está em ascendência, ou seja, a cada prova que passa mais questões são cobradas.

80. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) O modelo multidimensio-nal contém elementos básicos como a tabela fato, as dimensões, as métricas e as medidas. As dimensões participam de um fato, determinando o contexto do modelo, enquanto a tabela fato reflete a evolução dos negócios por meio das métricas aditivas ou não aditivas. Se a modelagem for do tipo snowflake, as medidas ficarão inseridas tanto nas dimensões quanto na fato, por haver um grau de normalização maior que no esquema star-schema.

81. (QOBM/Complementar/Informática/2011) Em banco de dados de apoio à de-cisão, há muita preocupação com a integridade dos dados e com a existência de redundância.


15

82. (QOBM/Complementar/Informática/2011) Utilizando OLAP, usuários finais conseguem, mediante um simples estilo de navegação e pesquisa, analisar rapidamente inúmeros cenários, gerar relatórios ad-hoc e descobrir tendên-cias e fatos relevantes, independentemente do tamanho, da complexidade e da fonte dos dados corporativos.

83. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) As ferra-mentas de software ETL (extract transform load) têm como função a extração de dados de diversos sistemas, a transformação desses dados de acordo com as regras de negócio e a carga dos dados em um data mart ou um DW.

84. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Toda estrutura de dados no DW tem um elemento de tempo – como dia, mês ou ano – como referência.

85. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Em um ambiente data warehouse (DW), é possível a análise de grandes volumes de dados, os quais ficam disponíveis para serem alterados e manipulados pelo usuário.

86. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Fer-ramentas OLAP (online analytical processing) permitem a navegação pelos dados de um DW, o que possibilita a realização de pesquisas e apresentação de informações. Por meio de um processo drill down, por exemplo, um rela-tório consolidado de vendas mensal poderá ser preparado de forma que as informações sejam dispostas por trimestre, por semestre, por ano, e assim sucessivamente.

87. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Inteligên-cia empresarial, ou business inteligence, é um termo utilizado para descrever as habilidades das corporações para coletar dados e explorar informações, analisá-las e desenvolver entendimentos para tomada de melhores decisões.

88. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Na modelagem dimensional, que pode ser usada para a construção de um DW, forma-se, basicamente, uma tabela central e tabelas dimensões diretamente ligadas a essa tabela central. O star schema, que atua nesse contexto, tem a característica de ser normalizado, exigindo excessivo espaço em disco, já que são necessárias diversas informações em cada linha das tabelas.

89. (Previc/Analista Administrativo/Tecnologia da Informação/2010) Os esquemas em estrela e em flocos de neve são dois modelos multidimensionais comuns. Dadas as suas características, o modelo em flocos de neve aumenta a redun-dância de dados e, por isso, aumenta o espaço utilizado em disco.


16

ELSEVIER

C a p í t u l o 2

Questões de Desenvolvimento de Sistemas Web

A disciplina de desenvolvimento de sistemas engloba um número elevado de tecnologias e linguagens. Ao contrário de outras matérias, as questões passam por atualização rápida e, em pouco tempo, uma tecnologia se torna obsoleta ou detém novas versões. Nesta seção tentamos destacar o que há de mais importante e perene nessas tecnologias.

2.1. Linguagem Java

A linguagem de programação Java é, sem dúvida, a mais cobrada em con-cursos públicos. Para abordar o tema, as questões selecionadas foram divididas sob dois aspectos:

• Sintaxe,característicaseAPIs–sãobastantecobradasemconcursodenível médio. Geralmente apresentam trechos de código Java e questio-nam sobre o resultado de uma execução. É importante treinar o per-corrimento de algoritmos e atentar para situações nas quais podem ocorrer erros em tempo de compilação ou de execução.

• Orientaçãoaobjetos–figuramcomfrequêncianasprovasqueexigemnível superior. Conceitos de encapsulamento, abstração, herança e po-limorfismo devem ser dominados pelos candidatos. Este último, o po-limorfismo, é o conceito mais complexo e também o mais cobrado nas questões.

2.1.1. Sintaxe, características e APIs

90. (MPU/Técnico de Informática/2010) 1 public class MpuJava2 {

2 public static void main (String args [ ]) {

3 Integer i = null;

4 Int j = i;

5 System.out.println (j);

6 }

7 }

O código na linha 5 produzirá a impressão do conteúdo da variável j que terá o valor null.

91. (BASA/Técnico Científico/Tecnologia da Informação/Arquitetura de Tecnolo-gia/2010) Ao final da execução do trecho de código abaixo, escrito na linguagem Java, será exibido o valor 21.int [ ] m = {1, 2, 3, 4,5};

int [ ] n = {0, 1, 2, 3, 4};

int s = 0;

for(int i = 0; i<4; i++) {

if (m[i] % 2 ! = 0)

m[i] = m[i] + n[i];

}

for (int a: m)

s = s + a;

System.out.print(s);

92. (DETRAN-DF/Analista/Análise de Sistemas/2009) Por meio do tipo de dados float, é possível representar números em notação de ponto flutuante norma-lizada em precisão simples de 32 bits.

93. (EMBASA/Analista de Tecnologia da Informação/Desenvolvimento/2010) O trecho de código a seguir está incorreto porque comentário em Java não usa \\.public synchronized Message getNewMessage ( ) {

if (messages.isEmpty ( )) {

\\ o código espera aqui }

return (Message) (messages.remove (0));

}

94. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) São algumas palavras reservadas da linguagem Java: public, private, protected, class, interface, abstract, extends, implements, super, byte, short, char, int, long, float, double, boolean, void, try, catch, finally, throws, throw, import, package, if, else, false, true, continue, default, break, return, while, switch, transient, final, synchro-nized, null, new.

95. (PREVIC/Analista de Tecnologia da Informação/2011) Em um programa Java, um thread que esteja bloqueado, à espera de um recurso de entrada ou saída, retornará para o estado de execução quando o recurso for disponibilizado.


18

ELSEVIER

96. (INSS/Analista de Seguro Social/Ciência da Computação/2008) A tentativa de execução do programa usando a linha de comando java Reverso 5 joão maria josé produziria um erro de runtime.1 package br.gov.inss;

2 import java.io.DataImputStream;

3 import java.io.IOException;

4 public class Reverso {

5 protected static void out (int quantos) throws IOException {

6 DataInputStream in = new DataInputStream(System.in);

7 String name;

8 if (quantos > 0) {

9 name = in.readLine ( );

10 lista.insere(name);

11 System.out.println(lista.remove( ));

12 out(quantos - 1);

13 System.out.println(name);

14 }

15 }

16 public static void main(String args [ ]) throws IOException {

17 int quantos = Integer.parseInt(args(0));

18 System.out.println(“entre com uma sequência de “+quantos+” nomes.");

19 out(quantos);

20 }

21 static Lista lista = new Lista( );

22 private static class No {

23 String conteudo; No proximo;

24 No(String c, No p) {conteudo = c; proximo = p;}

25 }

26 private static class Lista {

27 No cabeça = null;

28 void insere(String c) {

29 cabeça = new No(c, cabeça);

30 }

31 String remove( ) {

32 String conteudo = null;

33 if (cabeça != null) {

34 conteudo = cabeça.conteudo; cabeça = cabeça.proximo;

35 }

36 return conteudo;

37 }

38 }

39 }

Capítulo 2 I Questões de Desenvolvimento de Sistemas Web

19

97. (EMBASA/Analista de Tecnologia da Informação/Desenvolvimento/2010) O trecho de código a seguir está sintaticamente incorreto.If (ChatUser.getByName(getName( )) != null) {

throw new IllegalArgumentException(“Invalid username”);

} else {

ChatUser.addUser(this);

}

2.1.2. Orientação a objetos com Java

98. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) No código em Java mostrado a seguir, as classes Conta e Poupança implementam o po-limorfismo dinâmico.class Conta

{

float saldo;

public float getSaldo(int i)

{

float saldo = Of;

if (i == 1) saldo = this.saldo + 1.03f;

return saldo;

}

public void setSaldo (float saldo)

{

this.saldo = saldo + 20f;

}

class Poupança extends Conta

{

public float getSaldo( )

{

return saldo;

}

}

99. (BASA/Técnico Científico/Tecnologia da Informação/Arquitetura de Tecnolo-gia/2010) Na linguagem Java, se uma classe tem uma variável declarada com a palavra-chave final, significa que qualquer subclasse dessa classe estará impedida de alterar o valor dessa variável.

100. (MEC/Atividade Técnica de Complexidade Intelectual/Analista de Siste-mas/2011) De acordo com o trecho de programa em questão, o mecanismo de herança foi bloqueado pela redefinição de atributos na subclasse criada.


20

ELSEVIER

class Bicycle { int cadence = 0; int speed = 0; int gear = 1; void changeCadence(int newValue) { cadence = newValue; } void changeGear(int newValue) { gear = newValue; } void speedUp(int increment) { speed = speed + increment; } void applyBrakes(int decrement) { speed = speed – decrement; } void printStates() { System.out.println(“cadence:“+cadence+”speed: “+speed+”gear:“+gear); }}

class BicycleDemo { public static void main(String[]args) { Bicycle bike1 = new Bicycle(); Bicycle bike2 = new Bicycle(); bike1.changeCadence(50); bike1.speedUp(10); bike1.changeGear(2); bike1.printStates(); bike2.changeCadence(50); bike2.speedUp(10); bike2.changeGear(2); bike2.changeCadence(40); bike2.speedUp(10); bike2.changeGear(3); bike2.printStates(); }}

101. (DETRAN-DF/Analista/Análise de Sistemas/2009) Os moderadores de acesso são empregados para restringir o acesso a um método. Em Java, há os mode-radores public, protected, package, friendly, private e private protected. No moderador private, o método é privativo da classe que o contém, sendo seu uso permitido apenas dentro de um mesmo arquivo-fonte, e vedado a qualquer outra classe.


21

102. (DETRAN-DF/Analista/Análise de Sistemas/2009) Ao declarar uma nova classe, é possível especificar um dos seguintes modificadores: public, friendly, final, abstract. Uma classe abstract pode ser instanciada e derivada.

103. (TRT-ES/Técnico Judiciário/Tecnologia da Informação/2009) Uma variável de instância possui vários valores para cada instância da classe, enquanto variá-veis de classe iniciam-se pelo modificador private, significando, ao compilador, que há apenas uma cópia da classe em existência, independentemente de quantas vezes ela é instanciada.

104. (TRE-ES/Analista/Análise de Sistemas/2011) Em programação orientada a objetos, um construtor java serve para inicializar os atributos, sendo automa-ticamente executado sempre que se cria um novo objeto.

105. (FUB/Analista de Tecnologia da Informação/2011) Uma classe abstrata não pode ser diretamente instanciada. Somente as subclasses derivadas por he-rança múltipla de classes abstratas, chamadas de classes concretas, podem ser instanciadas.

106. (TRE-ES/Técnico/Programação de Sistemas/2011) O encapsulamento em Java somente pode ser realizado por meio do modificador de acesso protegido.

107. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) Na lin-guagem de programação Java, um método público da superclasse somente pode ser anulado por um método público da subclasse.

108. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) No código em Java apresentado a seguir, a tentativa de execução 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;

}

}


22

ELSEVIER

public class Principal

{

public static void main (String args[ ])

{

conta p1 = new Poupanca( );

((Poupanca)p1).setSaldo(450f);

System.out.println(“saldo: “+((Poupanca)p1).saldoConta( ));

}

}

109. (DETRAN-DF/Analista/Análise de Sistemas/2009) A implementação de herança múltipla em Java não é possível.

2.2. Padrões de Projeto

Ao estudar padrões de projeto, há dois tópicos de maior relevância: a clas-sificação dos padrões (criação, estruturais e comportamentais) e seu propósito.

Conhecer a classificação é fundamental para eliminar opções nas questões. Em muitos casos, apenas o conhecimento da classificação é suficiente para de-terminar se um item está correto.

Cada padrão está documentado sob o formato: intenção (propósito), mo-tivação, aplicabilidade, estrutura, participantes, colaborações, consequências, implementação, usos conhecidos e padrões relacionados. É claro que é importante conhecer todos os elementos, mas vale destacar a importância de conhecer o propósito de cada um deles.

Questões incluindo código-fonte e a diagramas sobre a estrutura dos padrões tem chance mínima de serem cobradas.

As questões a seguir tratam dos 23 padrões de projeto da chamada “gangue dos quatro” (GoF ou Gang of Four – os quatro autores do Livro Padrões de Pro-jeto – Soluções Reutilizáveis de Software Orientado a Objetos).

110. (TRT-RN/Técnico Judiciário/Tecnologia da Informação/2010) Os padrões de projeto podem ser definidos como soluções já testadas para problemas que ocorrem frequentemente durante o projeto de software.

111. (STJ/Analista Judiciário/Tecnologia da Informação/2008) Os padrões de projeto podem ser usados no projeto orientado a objetos para apoiar o reuso de software. Esses padrões frequentemente empregam a herança e o poli-morfismo para prover generalidade. Abstract factory, strategy e template method são padrões de projeto que podem ser empregados nos frameworks orientados a objetos para facilitar a adaptação dos frameworks.


23

112. (TJ-DF/Analista Judiciário/Tecnologia da Informação/2008) O padrão de projeto orientado a objetos denominado singleton exprime o fenômeno recorrente na análise que é a existência de muitas aplicações nas quais há um objeto que é a única instância de sua classe.

113. (ANAC/Técnico Administrativo/Tecnologia da Informação/2009) O uso de pa-drões de projeto somente pode ser aplicado a projetos que implementam o paradigma de programação orientada a objetos.

114. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) Adapter é um padrão estrutural utilizado para compatibilizar interfaces de modo que elas possam interagir.

115. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) Expert é um padrão que apresenta uma interface para várias funcionalidades de uma API de maneira simples e fácil de usar.

116. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Caso seja verificado no desenvolvimento de um sistema forte acoplamento entre as classes, recomenda-se o uso do padrão de comportamento Factory Method, que evita o acoplamento do remetente de uma solicitação ao seu re-ceptor, dando a mais de um objeto a oportunidade de tratar uma solicitação, mesmo nos casos em que o conjunto de objetos não seja conhecido a priori ou seja definido dinamicamente.

117. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) No desenvolvimento de um sistema estruturado em subsistemas para facilitar o acesso e minimizar a comunicação e dependências entre os subsistemas, o padrão de criação Factory Method, que fornece uma interface para a criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas, é mais indicado que o padrão de criação Prototype.

118. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Se, no desenvolvimento de uma aplicação que leia documentos do tipo txt e seja capaz de converter o documento em vários formatos distintos, houver a necessidade de facilitar acréscimos de novos tipos de conversão, será mais indicado o uso do padrão de estrutura Adapter que o uso do padrão de estrutura Bridge, pois o padrão Adapter separa a construção de um objeto complexo de sua representação para criar representações diferentes com o mesmo processo.

119. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Alguns dos usos típicos do padrão Façade são a unificação das várias interfaces de um sistema complexo; a construção de pontos de entrada para cada uma das múltiplas ca-madas de um sistema; a redução de dependências entre um cliente e múltiplas classes de implementação e o encapsulamento de todas as demais interfaces públicas de um sistema.


24

ELSEVIER

2.3. Arquitetura Java EE

Este tópico aborda uma verdadeira “sopa de letrinhas”. O primeiro passo é dominar o que significa cada uma delas. EJB, JPA, JSP, JTA, JSF e servlets são detalhadas nos itens a seguir. Outras como JMS e JCA fazem parte de escopo complementar que deve ser conhecido pelos candidatos. Perceba que, por hora, tratamos apenas de saber qual o propósito de cada uma dessas especificações.

Trata-se de matéria bastante extensa e que permeia assuntos correlacionados. Assim, embora Hibernate não faça parte diretamente da arquitetura Java EE, foi incluído nesta seção haja vista seu relacionamento com a arquitetura. Ademais, foram incluídas questões que citam de servidores de aplicação e servidores web, frequentemente cobrados em provas relacionadas à infraestrutura e suporte.

O termo corrente para retratar a arquitetura é Java EE. Antes, eram adotados os termos J2EE e JEE. Perceba que, mesmo em questões recentes, todos os três termos seguem sendo utilizados. Isso será comprovado nas questões dessa seção.

2.3.1. JSP/Servlets, EJB e Servidores de Aplicação

120. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Na arquitetura J2EE, o container web Apache Tomcat permite a execução de páginas JSP e servlets, que são classes Java que processam dinamicamente as requisições e constroem respostas na forma de páginas HTML.

121. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) Ao ser registrado com o contêiner JSP, o arquivo WAR de uma aplicação torna os re-cursos nele armazenados disponíveis para usuários finais mediante o acesso do servidor HTTP associado.

122. (PREVIC/Analista de Tecnologia da Informação/2011) Em uma aplicação mul-ticamadas na plataforma Java EE, servlets, JavaServer Faces e JSP consistem em tecnologias utilizadas na camada web.

123. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) O Enterprise Java-Beans (EJB), cuja especificação mais recente é a da versão 2.1, define, em sistemas Java, um conjunto de tecnologias utilizadas do lado cliente.

124. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) Em um sistema de transação distribuído, o Java Transaction API (JTA) permite especificar um conjunto de interfaces entre o gerenciador de transações e as partes envolvidas.

125. (STJ/Analista Judiciário/Tecnologia da Informação/2008) Na plataforma J2EE, uma aplicação web para a Internet pode ser composta por servlets, Java Server Pages (JSP) e páginas HTML. Nessas aplicações, a apresentação dos dados pode ser separada da lógica do negócio, adotando-se o estilo de arquitetura model view controller (MVC). Nesse caso, pode-se usar servlets operando


25

como controladoras que recebem as solicitações dos usuários e providenciam o processamento das mesmas. Em uma mesma aplicação, entretanto, só pode existir um servlet operando como controladora.

126. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) Ao usar tag personalizada JSP, é suficiente carregar uma URL que indique a localização do arquivo TLD para a biblioteca que se deseja acessar.

127. (PREVIC/Analista de Tecnologia da Informação/2011) O container JSP provê uma lista de objetos instanciados, chamados de objetos implícitos. É através do objeto aplicação (application object) que são rastreadas as informações de um cliente específico entre múltiplas requisições.

128. (SECONT-ES/Auditor/Tecnologia da Informação/2009) No desenvolvimento de uma aplicação web que siga o padrão JEE, a tecnologia JSP (Java Server Pages) permite criar páginas web com componentes estáticos e dinâmicos; o AJAX permite a troca e manipulação de dados XML com comunicação assíncrona, utilizando XMLHttpRequest; e o servlet é exemplo de servidor de aplicações que contém diretórios como o bin e o webapps e é responsável por gerenciar requisições recebidas de clientes.

129. (MPU/Analista de Informática/Perito/2010) Os programas a seguir, que cons-tituem uma integração entre as tecnologias JSP e Servlet, implementam uma solução válida para mostrar o valor obtido, por uma empresa, com o lucro ou prejuízo na venda de um produto.<html>

<body>

<form action=”VendaServlet” method=”POST”>

Produto:<input type=”text” name=”btDesc” value=”” size=”30” /><br>

Compra:<input type=”text” name=”btCompra” value=”” /><br>

Venda:<input type=”text” name=”btVenda” value=”” /><br>

<input type=”submit” value=”Executa” name=”btExecutar” />

</form>

</body>

<html>

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class VendaServlet extends HttpServlet {

protected void service (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

response.setContentType (“text/html;charset=UTF-8”);

PrintWriter out = response.getWriter( );

String produto = request.getParameter(“btDesc”);

float compra = Float.parseFloat(request.getParameter(“btCompra”));

float venda = Float.parseFloat(request.getParameter(“btVenda”));


26

ELSEVIER

float lucro = venda - compra;

out.println (“<html>”);

out.println (“<head>”);

out.println (“<title>Mpu VendaServlet</title>”);


out.println (“<body>”);

out.println (“<h1>O lucro : + lucro + “</h1>”);



}

}

130. (MPU/Analista de Informática/Perito/2010) Para que métodos estáticos de classes Java sejam executados a partir das funções da linguagem de expressão em JSP, é necessário que o nome da função coincida com o nome do método da classe Java.

131. (MPU/Analista de Informática/Perito/2010) O contêiner, que executa JSP, transforma o programa JSP em Servlet, assim, a expressão “< %=Math.Ran-dom()% >” se torna argumento para out.println().

132. (MPU/Analista de Informática/Perito/2010) Em um contêiner Servlet, a exe-cução do programa MpuServlet1 a seguir implica, também, na execução do programa MpuServlet2.import java.io.*;



public class MpuServlet1 extends HttpServlet (

protected void doGet (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {





out.println (“<title>Concurso MPU</title>”);

out.println (“</head>”);


out.println (“<h1>Concurso do MPU – Tela 1</h1>”);

response.flushBuffer( );

RequestDispatcher rd = request.getRequestDispatcher(“MpuServlet2”);

rd.forward(request, response);

out.println (“</body>”);

out.println (“</html>”);

out.close( );

}

}


27

import java.io.*;



public class MpuServlet2 extends HttpServlet (

protected void doGet (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException (





out.println (“<title>Concurso MPU</title>”);

out.println (“</head>”);


out.println (“<h1>Concurso do MPU – Tela 2</h1>”);

out.println (“</body>”);

out.println (“</html>”);

out.close( );

}

}

133. (CBM-DF/Oficial/Informática/2011) O uso de Javabeans, o controle de trans-ferência entre as páginas e o suporte independente de applets Java pelos browsers são possibilidades proporcionadas pela action tag da JSP.

134. (TRE-ES/Técnico/Programação de Sistemas/2011) Nos beans de entidade cuja persistência é gerenciada por contêiner, o desenvolvedor tem a responsabili-dade de escrever todo o código JDBC para a interação com o banco de dados.

135. (MPU/Técnico de Informática/2010) A plataforma adotada pela SUN para a sua versão 6 do Java EE é o JBoss, que implementa resposta para requisições JSP e WebServices e ainda permite implantar servlets.

136. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A web profile da plataforma JEE apresenta, em relação ao perfil application server definido em edições anteriores da plataforma Java, as seguintes vanta-gens: fornece suporte para POJOs (plain old Java objects) e annotations; possui modelo de empacotamento de componentes mais simples; a configuração dos seus descritores XML (extensible markup language) é mais fácil; é aderente ao padrão SOA.

137. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A tecnologia EJB (enterprise Java beans) apresenta, na sua versão 3.1, melhorias que propiciam facilidades para o uso de beans singleton e que permitem o uso de beans de uma classe, sem necessidade de desenvolvimento de sua interface correspondente, e a invocação assíncrona de beans de sessão.


28

ELSEVIER

138. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) No desenvolvimento de conteúdos para apresentação, o uso de facelets traz vantagens em relação ao uso de JSP. Uma delas é a maior modularidade, com o uso de templates e componentes compostos (composite).

2.3.2. JSF

139. (TRT-RN/Analista Judiciário/Tecnologia da Informação/2010) Portlets é um subprojeto do Java Server Faces (JSF) que permite integração com o Apache Myfaces e que tem como característica nativa a criação de templates com componentes reutilizáveis utilizando o XHTML como tecnologia de view do JSF.

140. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) Entre os itens que o padrão Java Server Faces (JSF) utiliza, estão os componentes, os eventos e a navegabilidade.

141. (MPU/Analista de Informática/Perito/2010) Uma aplicação web deve prover mecanismos de validação de dados. O JSF fornece vários validadores de dados padrões que podem ser utilizados no lado do cliente (client-side).

142. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Para suportar a construção de aplicações com Ajax e JSF, recomenda-se aos desenvolvedores de páginas que usem a tag <f:ajax>, relacionada ao proces-samento de pedidos http assíncronos.

143. (SECONT-ES/Auditor/Tecnologia da Informação/2009) O JSF é um framework web embasado em interface gráfica, capaz de renderizar componentes e manipular eventos em aplicações web no padrão Java EE, no qual os com-ponentes JSF são orientados a eventos. O JSF fornece, ainda, mecanismos para conversão, validação, execução de lógica de negócios e controle de navegação.

2.3.3. JPA/Hibernate

144. (MPU/Técnico de Informática/2010) A API de Persistência Java é embasada em ideias contidas em frameworks líderes de mercado, como Hibernate, Oracle TopLink e Objetos de Dados Java.

145. (SECONT-ES/Auditor/Tecnologia da Informação/2009) O Hibernate, um fra-mework de mapeamento objeto relacional (ORM), cria uma camada persistência na solução desenvolvida, o que permite ligar os objetos aos bancos de dados relacionais. Entre seus serviços, o Hibernate provê um meio de controlar tran-sações, por meio de métodos de suas interfaces session e transaction, tendo ainda suporte a herança e polimorfismo. É distribuído sob a licença LGPL, o que permite seu uso em projetos comerciais ou open source.


29

146. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) No Hibernate, apenas a linguagem de consulta HQL (hibernate query language) pode ser utilizada. A HQL executa os pedidos SQL sobre as classes de persistência do Java, em vez de tabelas no banco de dados, o que diminui a distância entre o desenvolvimento das regras de negócio e o banco de dados.

147. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Considerando que para o uso da tecnologia Hibernate na linguagem Java são empregados, usual-mente, dois tipos de arquivos: (i) configuração e (ii) mapeamento, sendo a lista a seguir uma sequência de elementos XML utilizados na tecnologia Hibernate: (a) hibernate-mapping (b) class; (c) generator; (d) property; (e) session-factory; e (f) mapping, então, uma associação adequada entre os elementos e o tipo de arquivo Hibernate, no qual eles usualmente são empregados, é a seguinte: {(a, ii), (b, ii), (c, i), (d, ii), (d, i), (e, i), (f, i)}.

148. (CBM-DF/Oficial/Informática/2011) A principal característica do Hibernate é a transformação das tabelas de dados para classes em Java. Além disso, ele gera as chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dos dados resultantes.

149. (MPU/Analista de Informática/Perito/2010) Na instalação padrão do Hibernate, o trecho de código Java abaixo permite a inserção de 200.000 linhas em uma tabela no banco de dados.Session ses = sessionFactory.openSession( );

Transaction trans = ses.beginTransaction( );

for (int i=0; i<200000; i++) {

Pessoa p = new Pessoa ( );

ses.save(p);

}

trans.commit( );

ses.close( );

2.4. Desenvolvimento Web (lado cliente)

AJAX e Javascript são os assuntos chave desta seção. AJAX tem sido assunto recorrente em todos os editais que incluem desenvolvimento de sistemas. Javas-cript é a linguagem usada no browser no modelo de programação AJAX e, por isso, também tem ganhado destaque em questões de concursos.

HTML e CSS são assuntos mais básicos e de menor complexidade. Aparecem com maior frequência nas prova de nível médio.

Questões com exemplos de código-fonte são comuns e misturam HTML e Javascript. É fundamental conhecer bem as propriedades e métodos do objeto XMLHttpRequest, o coração do AJAX.


30

ELSEVIER

150. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A fim de preservar a acessibilidade de tabelas, o elemento <table> não deve ser usado para composição do layout de páginas HTML.

151. (BASA/Técnico Científico/Tecnologia da Informação/Análise de Sistemas/2010) A sintaxe da linguagem JavaScript assemelha-se muito à da Java e da C++, por exemplo, na criação de objetos usando o operador new e na definição de classes usando a diretiva class.

152. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Alguns dos efeitos da carga do script abaixo em um browser habilitado para execução de scripts na linguagem JavaScript e que a suporta, são: o título da janela do browser será Página 1 e o conteúdo da página apresentada será a expressão Olá!

<!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 4.01//EN” “http//www.w3.org/TR/html4/strict.dtd”>

<html>

<head><title>Página 1</title></head>

<body>

<script type=”text/javascript”>

document.write(‘olá!’);

document.title=’Título’;

</script>

<noscript>

<p>Sem JavaScript.</p>

</noscript>

</body>

</html>

153. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) O Javascript expande as capacidades de uma página HTML e, unido ao CSS, formou o DHTML.

154. (ANATEL/Especialista em Regulação/Informática/2006) Um documento HTML é armazenado em um arquivo ASCII e a estrutura do documento é descrita com sequências de caracteres chamadas tags. O estilo de um documento pode ser definido com tags HTML ou com a linguagem Cascading Style Sheets. O código que define o estilo de um documento HTML tem de ser armazenado no mesmo arquivo no qual está o documento.1 <SCRIPT LANGUAGE=”JavaScript1.1” SRC=”valida.js”></SCRIPT>

2 <BODY>

3 <FORM onSubmit=”this.primeiro.opcional = true;>

4 this.fone.opcional = true;

5 this.cep.numerico = true; this.cep.min = 0; this.cep.max = 99999;

6 this.idade.numerico = true; this.idade.min = 0; this.idade.max = 120;

7 return verifica (this);” METHOD=”post”>


31

8 Primeiro nome: <INPUT TYPE=text NAME=”primeiro”>

9 Último nome: <INPUT TYPE=text NAME=”ultimo”><BR>

10 Endereço: <TEXTAREA NAME=”endereco” ROWS=4 COLS=40”></TEXTAREA><BR>

11 CEP: <INPUT TYPE=text NAME=”cep” onkeypress=”window.status=ehBranco(cep.value);”><BR>

12 Fone: <INPUT TYPE=text NAME=”fone” onblur=alert(‘esqueceu o ddd?’)”><BR>

13 Idade: <INPUT TYPE=text NAME=”idade”><BR>

14 <INPUT TYPE=submit NAME=”Submeter”>

15</FORM>

16</BODY>

1 function ehBranco(s)

2 {

3 for(var i = 0; i <s.length; i++) { var c = s.charAt(i);

4 if((c != ‘ ‘) && (c != ‘\n’) && (c !=’\t’)) return false;

5 } return true;

6 }

7 function verifica(f)

8 { var msg; var empty_fields = “”; var errors = “”;

9 for(var i = 0; i< f.length; i++) {

10 var e = f.elements[i];

11 if ((e.type ==”text”) || (e.type ==”textarea”)) {

12 if (!e.opcional && ((e.value == null) || (e.value == “”) || ehBranco(e.value))) {

13 empty_fields +=”\n “ + e.name;

14 continue;

15 }

16 if (e.numerico && ((e.min !=null || (e.max !=null))) {

17 var v = parseFloat(e.value);

18 if (isNaN(v) ||

19 ((e.min != null) && (v < e.min)) ||

20 ((e.max != null) && (v < e.max))) {

21 errors += “- 0 campo “ + e.name + “ deve ser um número”;

22 if (e.min != null) errors += “ maior que “ + e.min;

23 if (e.max != null) errors += “ e menor que “ + e.max;

24 else if (e.max != null) errors += que é menor que “ + e.max;

25 errors += “.\n”;

26 }

27 }

28 }

29 }

30 if (!empty_fields && !errors) return true;

31 msg = “O formulário não foi submetido.\n”;

32 if (empty_fields) {

33 msg += “São campos vazios: “+empty_fields +”\n”;

34 if (errors) msg += ”\n”;

35 }


32

ELSEVIER

36 msg += errors;

37 alert(msg);

38 return false;

39 }

Os códigos acima, adaptados de JavaScript: The Definitive Guide, apresentam o conteúdo de dois arquivos: uma página HTML cujo nome é teste.html e um script JavaScript cujo nome é valida.js. Julgue os seguintes itens, a partir do comportamento exibido pelo browser quando interpretando a referida página HTML, considerando que a página tenha sido recebida por meio de um pedido http enviado a um servidor, e para a qual o browser habilitou permissões para execução de todos os códigos apresentados.

155. (STF/Analista Judiciário/Tecnologia da Informação/2008) A página HTML apresentará um botão de formulário cujo rótulo é Submeter.

156. (STF/Analista Judiciário/Tecnologia da Informação/2008) Se o campo primeiro e o campo idade do formulário HTML não forem preenchidos pelo usuário, será apresentada uma mensagem pop-up quando da submissão do botão Submeter, e os dados do formulário não serão enviados para o servidor.

157. (STF/Analista Judiciário/Tecnologia da Informação/2008) A página teste.html é bem formada, conforme a especificação: XHTML ou HTML 4.01.

158. (STF/Analista Judiciário/Tecnologia da Informação/2008) Para o elemento form da linguagem HTML, são válidos os atributos onsubmit, action e method. “GET” e “POST” são valores válidos para o atributo method.

159. (STF/Analista Judiciário/Tecnologia da Informação/2008) Considere a situação na qual um usuário esteja preenchendo o campo fone, que já se encontra pre-enchido com a sequência 123456. Nesse caso, se o usuário pressionar a tecla Tab, o foco da entrada de dados será imediatamente direcionado para o campo idade.

160. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) O Ajax incorpora diferentes tecnologias, como o DOM, o XML, o XSLT, o objeto

XMLHttpRequest,o objeto XMLHttpResponse e o Javascript, cuja função é fazer a junção entre os elementos.

161. (MPU/Analista de Informática/Perito/2010) O objeto XMLHttpRequest apresenta a estrutura das páginas web como um conjunto de objetos programáveis que pode ser manipulado com JavaScript.

162. (BASA/Técnico Científico/Tecnologia da Informação/Análise de Sistemas/2010) Por meio da tecnologia AJAX, é possível fazer o envio de formulários HTML por meio de estruturas de dados baseadas em XML, sem a necessidade de recarregar novas páginas no navegador.


33

A figura abaixo apresenta um código que pode ser interpretado por um brow-ser web padrão habilitado para funcionamento com a tecnologia Ajax e que a suporta. A respeito do comportamento desse browser quando o usuário inte-ragir com a correspondente página renderizada, julgue os itens subsequentes.<html>

<body>

<script type=”text/Javascript”>

function ajaxFunction() {

if (window.XMLHttpRequest) {//IE7+, Firefox, Chrome, Opera, Safari

alert(“Seu browser suporta Ajax!”);

} else {

alert(“Seu browser não suporta Ajax!”);

}

}

</script>

<form name=”formulario”>

Nome: <input type=”text” name=”nome” onkeydown=”ajaxFunction();”/>

Hora: <input type=”text” name=”tora” />

</form>

</body>

</html>

163. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Sempre que o usuário pressionar uma tecla nos campos nome e hora do formulário de nome formu-lário, será apresentada uma janela pop-up ao usuário com a expressão: Seu browser suporta Ajax!

164. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Um novo pedido HTTP será enviado pelo browser ao servidor HTTP que enviou a página sempre que a função ajaxFunction for executada com sucesso.

2.5. Interoperabilidade de sistemas Web

Nesta seção são abordadas questões sobre XML, Web Services e SOA.Quanto a XML, destaque para os tópicos: regras de formação de documentos

XML, APIs de processamento – DOM e SAX, XML Schema, documentos XML válidos e XSLT.

Dentre todos os assuntos em Desenvolvimento de Sistemas, Web Services é, seguramente, um dos mais cobrados. Muitas questões cobram apenas uma dife-renciação entre as tecnologias SOAP, WSDL e UDDI. Dominá-las é fundamental.

SOA há pouco tempo passou a figurar nos editais de concursos. As questões são bastante recentes e cobram principalmente o conceito de SOA, seu relacio-namento com Web Services e modelagem de processos de negócio.


34

ELSEVIER

2.5.1. XML

165. (TRE-ES/Técnico/Programação de Sistemas/2011) No prólogo de um arquivo XML, existe o atributo standalone o qual, com valor padrão yes, de escrita obrigatória, indica que o documento não pode ser analisado no lado servidor.

166. (TRE-ES/Técnico/Programação de Sistemas/2011)<pessoa> <nome> Fulano de Tal </nome>

<matricula>l23456</matricula>

<cargo>Coordenador</cargo>

<departamento>

<sala>1001</sala><ramal>1234</departamento>

</pessoa>

Considerando a estrutura acima, armazenada no arquivo Funcionario.xml: Com essa estrutura, ao abrir o arquivo Funcionario.xml em um navegador, será mostrado um erro de processamento de recurso.

167. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) As marcações XML não fazem distinção entre letras minúsculas e maiúsculas.

168. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) A instrução a seguir está sintaticamente correta e permite o uso de algarismos romanos para co-dificação de números.<? xml version=”1.0” encoding=”ISSO-8859-1” ?>

169. (INMETRO/Analista/Desenvolvimento de Sistemas/2009) Na linguagem XML, todo atributo é parte de um elemento, todo elemento é raiz ou filho de uma raiz, a construção de uma árvore pode empregar o modelo DOM, uma transformação pode ser direcionada por um documento XSLT, e quando se deseja consumir pouca memória no processamento de XML pode-se empregar um parser do tipo SAX.

170. (TRT-RN/Analista Judiciário/Tecnologia da Informação/2010) A XSD – XML schema definition permite definir elementos e atributos que podem aparecer em um documento XML, tal como um DTD (document type definition).

171. (TRT-RN/Analista Judiciário/Tecnologia da Informação/2010) Considere que haja a necessidade de publicar dados de trâmites de processos que se encon-tram armazenados em XML, no sítio do TRT, em formato HTML, e também em formato TXT, no servidor de arquivos. Para essa finalidade, uma solução adequada é utilizar o XSLT, pois essa é a opção recomendada pelo W3C para que documentos XML sejam transformados em documentos de texto ou docu-mentos HTML, como nas condições requeridas.


35

2.5.2. Web Services

172. (BASA/Técnico Científico/Tecnologia da Informação/Análise de Sistemas/2010) O SOAP (simple object access protocol), muito utilizado no transporte de da-dos dos web services, permite que aplicações troquem informações usando requisições HTTP em formato XML.

173. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Considere que um líder tenha solicitado a um programador do projeto que comentasse o seguinte trecho de código.POST /objectURI HTTP/1.1Host: www.foo.comSOAPMethodName: urn:develop-com:IBank#getBalanceContent-Type: text/xmlContent-Length: 1234

O comentário do programador teria sido correto se ele dissesse que esse código é provavelmente o esqueleto de um pedido http que foi invocado sobre o ser-vidor http (hypertext transfer protocol) de endereço www.foo.com, embasado no modelo de comunicação SOAP (simple object access protocol), que apenas o cabeçalho do pedido está sendo apresentado e que o pedido completo deve possuir em seu corpo um documento XML com 1.234 bytes de tamanho.

174. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009)


36

ELSEVIER

Na figura mostrada, na notification, o serviço envia uma mensagem e a ope-ração tem um único elemento de saída. O padrão request-response é pouco utilizado nos serviços SOAP.

175. (PREVIC/Analista de Tecnologia da Informação/2011) Uma mensagem SOAP (simple object access protocol) compreende duas partes, o corpo e o cabeçalho (opcional) da mensagem, que são depositadas em um envelope SOAP, o qual deve conter o endereço do receptor.

176. (STJ/Analista Judiciário/Tecnologia da Informação/2008) O SOAP encapsula mensagens que podem ser transmitidas via HTTP; permite o modelo de inte-ração cliente-servidor; define como usar XML para representar mensagens de requisição e resposta. Um documento XML é transportado no corpo de uma mensagem SOAP; no modelo cliente-servidor, o corpo de uma mensagem SOAP pode conter uma requisição, mas não uma resposta.

177. (MPU/Técnico de Informática/2010) A descrição de um web service é feita utilizando-se WSDL (Web Services Description Language), que é uma lingua-gem embasada em RPC (Remote Procedure Call) e UDDI (Universal Description Discovery and Integration), com a qual se descreve a forma de acesso dos serviços e seus parâmetros de entrada e de saída.

178. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Considere que um líder de equipe solicite a um programador do projeto que analise o seguinte trecho de código de um documento XML. <service name = ”StockQuoteService”>

<documentation>My first service</documentation>

<port name=”StockQuotePort” binding=”tns:StockQuoteBinding”>

<soap:address location=”http://example.com/stockquote”/>

</port>

</service>

Nessa situação, se o programador disser que esse trecho de documento é pro-vavelmente de declaração de serviço web com base na tecnologia WSDL (web services description language) e que, embora o serviço descrito contenha uma única porta, é possível a definição de várias portas associadas a um mesmo serviço, a análise feita deverá ser considerada correta.

179. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Em WSDL, os elementos do tipo types descrevem todos os tipos de dados usados entre cliente e servidor. O WSDL está exclusivamente ligado a um sistema de tipagem específico, pois utiliza, como padrão, um esquema de especificação W3C XML.


37

180. (STJ/Analista Judiciário/Tecnologia da Informação/2008) O WSDL separa a parte abstrata de uma descrição de serviço da parte concreta; nessa descrição, a parte concreta contém as definições de tipos usados pelo serviço e a parte abstrata especifica como e onde o serviço pode ser contatado. Os documentos WSDL podem ser acessados via um serviço de diretório como o UDDI; as defi-nições WSDL podem ser geradas a partir de definições de interfaces escritas em outras linguagens.

181. (Antaq/Analista Administrativo/Informática/2009) Web service é um conjunto de tecnologias utilizadas na integração de sistemas e na comunicação entre aplicações diferentes. Para a representação e estruturação dos dados nas men-sagens recebidas/enviadas, é utilizado o XML (eXtensible markup language). As chamadas às operações, incluindo-se os parâmetros de entrada e saída, são codificadas no protocolo UDDI (universal description, discovery and inte-gration). Os serviços (operações, mensagens, parâmetros etc.) são descritos usando-se a linguagem WSDL (web services description language). O processo de publicação, pesquisa e descoberta de web services utiliza o protocolo SOAP (simple object access protocol).

182. (TRT-RN/Analista Judiciário/Tecnologia da Informação/2010) Na figura abaixo, em que é esboçado o esquema de um web service e suas relações (setas), foi feita a associação número e descrição da relação, da seguinte forma: 1 – “É acessado usando”; 2 – “Permite a descoberta de”; 3 – “Liga-se a”; 4 – “Permite comunicação com” e 5 – “Descreve”. De acordo com as funcionalidades dessas partes, a associação entre número e descrição apresentada tem o significado correto em todas as cinco associações.


38

ELSEVIER

183. (MPU/Técnico de Informática/2010) REST (Representationals State Transfer) é uma tecnologia que está sendo utilizada em web services, como substituta das tecnologias SOAP (Simple Object Access Protocol) e WSDL.

184. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O estilo de arquitetura de software denominado REST (representational state transfer) demanda mais recursos computacionais que o modelo de desenvol-vimento de sistemas embasado em SOAP (single object access protocol), por isso não é recomendável a adoção do padrão REST de arquitetura de software no desenvolvimento do sistema em questão.

2.5.3. SOA

185. (TRT-BA/Analista Judiciário/Tecnologia da Informação/2008) Na visão do SOA, XML e WSDL são padrões abertos que permitem que os serviços se comuniquem de maneira homogênea, independentemente da plataforma de hardware, do sistema operacional e da linguagem de programação nos quais o serviço está implementado.

186. (TRT-BA/Analista Judiciário/Tecnologia da Informação/2008) No SOA, os web services permitem que os aplicativos se comuniquem entre si de modo inde-pendente da plataforma e da linguagem de programação. Os web services utilizam WSDL para descrever interfaces de aplicativos na linguagem XML.

Com referência ao processo de negócio apresentado no fluxograma a seguir, que deverá ser automatizado usando uma abordagem de orientação por ser-viços, e aos princípios de orientação a serviços e das boas práticas de adoção de arquitetura orientada a serviços (SOA):

187. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Após definidos os serviços que automatizam as tarefas, esses serviços podem ser orquestrados para prover a automatização do processo como um todo. Essa abor-dagem está ligada à característica de que SOA deve ser direcionada pelo negócio.

188. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O referido processo de negócio é sequencial. Esse processo poderá ser otimizado por meio da análise e do projeto orientados a serviços, que poderá transformá--lo em um processo que emprega atividades executadas em paralelo, promo-vendo maior agilidade organizacional, outra característica intrínseca de SOA.


39

189. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Uma equipe de desenvolvimento de software recebeu a incumbência de desenvolver um sistema com as características apresentadas a seguir.• Osistemadeveráserintegrado,interoperável,portáveleseguro.• Osistemadeveráapoiartantooprocessamentoonline,quantoosuportea

decisão e gestão de conteúdos.• OsistemadeveráserembasadonaplataformaJEE(Javaenterpriseedi-

tion) v.6, envolvendo servlets, JSP (Java server pages), Ajax, JSF (Java server faces) 2.0, Hibernate 3.5, SOA e web services.

O líder da equipe iniciou, então, um extenso processo de coleta de dados com o objetivo de identificar as condições limitantes da solução a ser desenvolvida e tomar decisões arquiteturais e tecnológicas que impactarão várias caracte-rísticas funcionais e não funcionais do sistema, ao longo de seu ciclo de vida. A partir dessa coleta, o líder deverá apresentar à equipe um conjunto de in-formações e de decisões. Visando ao bom funcionamento do sistema descrito no texto, julgue os itens subsequentes, que tratam de interoperabilidade de sistemas web em Java.Para o projeto em tela, é recomendado que se adote uma arquitetura orientada a serviços web (SOA e web services) porque esse tipo de arquitetura facilita o reuso de componentes de software fisicamente distribuíveis, além de ser embasado em ligação estática entre provedores e consumidores de serviço.


40

ELSEVIER

C a p í t u l o 3

Questões de Engenharia de Software

A disciplina de Engenharia de Software é uma das mais cobradas em concur-sos para a área de tecnologia da informação, e sua principal dificuldade reside no nível de profundidade crescente das questões. Assim, nos últimos anos tem sido mais frequente a cobrança de detalhes, por exemplo, das técnicas de contagem de pontos de função, de metodologias ágeis de desenvolvimento e de conceitos e ferramentas da engenharia de requisitos. Ao mesmo tempo, um percentual sig-nificativo das questões continua cobrando fundamentos de orientação a objetos, do processo unificado e da linguagem UML.

3.1. Análise por Pontos de Função

Apesar da grande complexidade da APF para aplicação prática, na contagem de sistemas, em geral as questões de prova sobre o assunto são simples, por tratar apenas dos conceitos básicos da técnica e não das minúcias das regras de conta-gem. É recomendável, entretanto, conhecer bem as principais diferenças entre as práticas do IFPUG e da NESMA, tema que tem se tornado mais frequente em provas recentes.

3.1.1. Conceitos básicos de APF

190. (Anatel/Analista Administrativo/Análise de Negócios/2009) A análise de pontos de função de um programa produz estimativas de tamanho funcional de um produto de software embasada em cinco parâmetros-chave: entradas externas, saídas externas, consultas externas, arquivos lógicos internos e arquivos de interface externos. Os três primeiros parâmetros são funções transacionais, enquanto os dois últimos são funções de dados. As operações CRUD (create, read, update e delete) são consideradas pertencentes às entradas externas.

191. (TST/Analista Judiciário/Análise de Sistemas/2008) A estimativa de caracterís-ticas de projeto por pontos de função requer que as características do domínio

de informação do software sejam categorizadas como de realização simples, média ou complexa, em função do grau de dificuldade de desenvolvimento em determinada organização.

192. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) Registros lógicos são subconjuntos de dados dentro de um ALI/AIE que foram reconhecidos pelo usuário. Caso o usuário não reconheça subconjuntos de dados em um ALI/AIE, este deve ser contado como um registro lógico.

193. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Na análise por pontos de função (APF), as funções podem ser do tipo transação e do tipo dados. Nas funções do tipo transação, são manipulados os arquivos de interface externa (AIE) bem como os arquivos lógicos internos (ALI).

194. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) De acordo com o manual de contagem de pontos de função, consulta externa é um processo elementar que envia dados ou informações de controle para fora da fronteira, sendo considerada componente funcional básico.

195. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Um arquivo lógico interno (ALI) é utilizado para o armazenamento de dados de arquivos temporários, que são gerados para processamento em outra aplicação.

196. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Uma consulta externa disponibiliza informações para o usuário por meio de lógica de processamento, ou seja, não se limita apenas a recuperação de dados. A lógica de processamento deve conter pelo menos uma fórmula matemática ou cálculo, ou criar dados derivados.

197. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Um arquivo de interface externa é obrigatoriamente um ALI de outra aplicação.

3.1.2. APF segundo o IFPUG

198. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó-cios e Tecnologia da Informação/2009) A APF pode ser utilizada na estimativa de tamanho funcional de um software a ser desenvolvido, sem ser aplicável a situações em que o software esteja em fase de implantação ou já implantado (produto pronto).

199. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) A contagem não ajusta-da de pontos de função é a soma das contribuições de cada função identificada na aplicação que esteja sendo contada. Para obter a contagem ajustada de pontos de função, a referida soma é multiplicada pelo valor do fator de ajuste.

200. (Ipea/Analista de Sistemas/Suporte de Processos de Negócios/2008) A análi-se de pontos por função contempla três formas de contagem: a estimativa, a indicativa e a detalhada. Ao medir a funcionalidade entregue por um sistema,


42

ELSEVIER

considera as entradas, saídas e consultas externas, bem como o número de arquivos lógicos internos e as interfaces externas. A avaliação da complexidade considera mais 14 fatores de ajuste de valor.

201. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) Em um projeto de desen-volvimento, uma contagem deve incluir a funcionalidade provida pela conversão de dados e relatórios associados com os requisitos de conversão de dados.

202. (STM/Analista Judiciário/Análise de Sistemas/2011) O conceito de projeto de melhoria do IFPUG envolve as manutenções evolutivas, corretivas e preventivas da aplicação.

3.1.3. APF segundo a NESMA

203. (STM/Analista Judiciário/Análise de Sistemas/2011) A NESMA (Netherlands Software Metrics Users Association) tem objetivos e ações bem próximos aos do IFPUG; ambos apresentam abordagens semelhantes para a aplicação da análise de pontos de função em projetos de melhoria de software e na fase inicial do desenvolvimento do produto de software.

3.1.4. Aplicações da APF

204. (Sebrae/Analista Técnico/2008) A contagem pelas métricas baseadas em pontos de função são preferidas por serem totalmente objetivas e confiáveis, uma vez que se originaram de dados estatísticos de projetos já executados e medidos.

205. (Sebrae/Analista Técnico/2008) A APF pode ser realizada no início do projeto e serve como base para não só estimar custos, como também riscos que devem ser considerados no planejamento em função de equipe e de tempo disponíveis.

206. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Essa análise pode ser utilizada para estimar o custo relativo a codificação e teste, mas não para estimar o custo referente ao projeto do software.

207. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A análise por ponto de função não permite prever o número de erros que serão encontrados durante o teste; por isso, é necessário o uso de uma métrica adicional para tal fim.

208. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) A técnica de análise de pontos de função tem como objetivos primários, entre outros, a medição da funcionalidade que o usuário solicita e recebe a medição do desempenho e a manutenção de software independentemente da tecnologia utilizada para sua implementação.

209. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A partir de diagramas UML de classe e de sequência, é possível calcular o número de pontos de função de um sistema ou módulo.

Capítulo 3 I Questões de Engenharia de Software

43

3.2. Modelos de Processos de Desenvolvimento de Software

Neste tópico são abordadas as questões sobre os principais processos de de-senvolvimento de software. Pressman e Sommerville são os principais autores. O modelo em Cascata, denominado também Waterfall ou modelo sequencial linear é o mais cobrado. O Processo Unificado e os processos ágeis são apresentados em tópicos específicos devido à relevância desses assuntos em concursos do Cespe.

210. (MEC/Atividade Técnica de Complexidade Gerencial/Análise de Sistemas/2011) O modelo Waterfall tem a vantagem de facilitar a realização de mudanças sem a necessidade de retrabalho em fases já completadas.

211. (MEC/Atividade Técnica de Complexidade Gerencial/Análise de Sistemas/2011) O processo de desenvolvimento de software é uma caracterização descritiva ou prescritiva de como um produto de software deve ser desenvolvido.

212. (MEC/Atividade Técnica de Complexidade Gerencial/Análise de Sistemas/2011) No modelo de prototipação, o processo de desenvolvimento de software é modelado como uma sequência linear de fases, enfatizando um ciclo de de-senvolvimento de breve duração.

213. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) O modelo em espiral de ciclo de vida de software é iterativo e incremental, uma vez que a mesma sequência de atividades relacionadas à produção de software é realizada a cada ciclo da espiral.

214. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Um modelo de pro-cesso de software consiste em uma representação complexa de um processo de software, apresentada a partir de uma perspectiva genérica.

215. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Entre os desafios enfrentados pela engenharia de software estão: lidar com sistemas legados, atender à crescente diversidade e atender às exigências quanto a prazos de entrega reduzidos.

216. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) O termo engenharia pretende indicar que o desenvolvimento de software submete-se a leis similares às que governam a manufatura de produtos industriais em engenharias tradicionais, pois ambos são metodológicos.

217. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) A fase de projeto define o que o software deve fazer, enquanto a fase de elicitação de requisitos define como o software deve atingir seus requisitos.

218. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Um protótipo evolutivo apresenta, de forma geral, maior manutenabilidade e escalabilidade quando comparado a um protótipo descartável.


44

ELSEVIER

219. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Entre as metodo-logias de desenvolvimento de software atualmente empregadas destacam-se as abordagens embasadas no modelo unificado e as abordagens ágeis. O uso das técnicas de test-drive design, refactoring, design patterns e pair programming é, entre os modelos acima, maior nas abordagens do modelo unificado. Por outro lado, o uso de ferramentas CASE-UML é mais comum nas abordagens ágeis.

220. (ANTAQ/Analista Administrativo/Informática/2009) O modelo em espiral, que descreve o processo de desenvolvimento de um software, apresenta uma espi-ral em que cada loop representa uma fase distinta desse processo. A ausência de risco nesse modelo o diferencia dos demais modelos de software.

221. (TCE-RN/Assessor Técnico de Informática/2009) A prototipação, uma aborda-gem para desenvolvimento de software na qual se cria um modelo do software que será implementado, é composta de quatro etapas: planejamento, análise de risco, engenharia e avaliação do cliente.

222. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) O modelo em cascata consiste em fases e atividades que devem ser realizadas em sequência, de forma que uma atividade é requisito da outra.

223. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) O modelo orientado a reuso parte de um software existente para que se crie outro, no todo ou apenas em parte de seus componentes.

224. (TST/Analista Judiciário/Análise de Sistemas/2008) O modelo RAD (rapid ap-plication development) consiste em uma forma de prototipação para esclarecer dúvidas da especificação do software.

225. (TST/Analista Judiciário/Análise de Sistemas/2008) No modelo de desenvol-vimento sequencial linear, a fase de codificação é a que gera erros de maior custo de correção.

226. (TST/Analista Judiciário/Análise de Sistemas/2008) O modelo de desenvolvi-mento em espiral permite repensar o planejamento diversas vezes durante o desenrolar do projeto.

227. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) O modelo de desen-volvimento sequencial linear tem como característica principal a produção de uma versão básica, mas funcional, do software desde as primeiras fases.

228. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) No modelo de proto-tipação, a especificação de requisitos tem pouca importância, pois o software é continuamente adaptado em função dos desejos do usuário.

229. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) O modelo RAD (rapid application development) é específico para projetos de software que empregam linguagens de programação de terceira geração.


45

230. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) O modelo de desen-volvimento incremental combina características do modelo de desenvolvimento sequencial linear com características do modelo RAD, embora isso resulte em projetos que sistematicamente apresentam maior duração do que aqueles feitos com os dois modelos de desenvolvimento originais.

231. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Empregando o mo-delo de desenvolvimento em espiral, o software é desenvolvido em uma série de versões intermediárias incrementais.

232. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) A utilização de um modelo de desenvolvimento embasado em componentes é uma forma de desenvolvimento em espiral que busca a reutilização de trechos de software desenvolvidos e testados em projetos anteriores e armazenados em um repo-sitório.

3.3. Processo Unificado

Segundo Larman, em seu livro “Utilizando UML e Padrões: Uma introdução ao Processo Unificado”, o Processo Unificado (PU) surgiu como um processo popular para o desenvolvimento de software, visando à construção de sistemas orientados a objetos.

O Processo Unificado da Rational (Rational Unified Process – RUP), é um refinamento do PU. Então, em questões de concursos é muito comum os dois termos UP e RUP serem tratados como sinônimos. No entanto, cabe ressaltar que o RUP é uma customização do UP feita pela empresa Rational, atualmente de propriedade da IBM.

233. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Conforme o RUP, o plano de teste, artefato da disciplina de teste de responsabilidade do testador, reúne as informações necessárias para planejar e controlar o esforço de teste refe-rente a uma iteração específica ou ao projeto e, entre outros itens, deve conter o tipo de teste a ser realizado, sua estratégia e as ferramentas necessárias para sua execução.

234. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Elaboração, no contexto do RUP, é uma fase que visa criar a baseline para a arquitetura do sistema a ser desenvolvido e, no contexto de engenharia de requisitos, a elaboração consiste em atividade cujo objetivo é o desenvolvimento de um modelo técnico refinado das funções, características e restrições do sistema.

235. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Sistemas/2011) O diagrama de caso de uso de negócio é um diagrama do RUP utilizado para mapear e descrever atores e funções envolvidos na modelagem de negócio.


46

ELSEVIER

236. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) O framework de pro-cesso RUP organiza o ciclo de vida de um produto de software desde o início de sua concepção até sua aposentadoria, na seguinte sequência de etapas: concepção, elaboração, construção e transição.

237. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) No modelo RUP, a primeira linha de base da arquitetura de um software é produzido ao final da fase de elaboração.

238. (STM/Analista Judiciário/Análise de Sistemas/2010) O RUP (rational unified process) é um modelo de processo de desenvolvimento genérico e moderno, organizado em fases — concepção, elaboração, construção e implantação —, que separa as atividades em requisitos, análise e projeto.

239. (MPU/Analista de Informática/Desenvolvimento/2010) Na fase de elaboração do RUP, são desenvolvidas as funcionalidades do sistema e implementados os requisitos identificados na fase de concepção.

240. (MPU/Analista de Informática/Desenvolvimento/2010) O processo unificado (PU) é um processo iterativo para a análise de projetos orientados a objetos, no qual o trabalho e as iterações são organizados em três fases principais: concepção, elaboração e construção.

241. (MPU/Analista de Informática/Desenvolvimento/2010) No PU, a elicitação de requisitos do sistema de software inicia-se na fase de concepção.

242. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) UML (unified modeling language) é uma tecnologia concorrente com o processo unificado, no que diz respeito ao apoio à prática de engenharia de software orientada a objetos.

243. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O processo unificado de software é centrado na arquitetura e orientado por casos de uso, o que sugere um fluxo de processo iterativo e incremental.

244. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Uma falha comum em projetos de sistemas computacionais é não assegurar a qualidade do software. Normalmente, essa questão é discutida após o término dos projetos, ou a qualidade fica sob a responsabilidade de equipe diferente da equipe de desen-volvimento. O RUP, proposto pela IBM, é um processo que provê uma solução disciplinada sobre como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software, porém, não auxilia no controle do planejamento e verificação da qualidade.

245. (TCE-RN/Assessor Técnico de Informática/2009) Estruturar o modelo de caso de uso de negócios, que é o modelo das metas de negócio e as funções preten-didas, é uma tarefa da disciplina requisitos do RUP.


47

246. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) A criação de baselines no RUP tem como motivação a rastreabilidade, a ela-boração de relatórios e a reprodutibilidade, além de estabelecer, na fase de construção, um marco da arquitetura do ciclo de vida do projeto. Com os ba-selines, é possível desfazer mudanças caso as atualizações realizadas sejam consideradas instáveis ou não confiáveis.

247. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) A modela-gem de negócios (business modeling) é uma disciplina do RUP. Nessa disciplina, a compreensão dos negócios realizados por uma organização para a qual se deseja produzir um software é reforçada por meio da construção de modelo dos processos de negócios dessa organização, que usa várias técnicas, como elaboração de diagramas de casos de uso, atividade, classe e interação.

248. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) Ativi-dades de planejamento, avaliação, monitoramento e controle relacionam-se diretamente à disciplina de gerência de projeto, existente no RUP. Dado um esquema fixo de alocação de recursos para a gerência de um projeto ao longo do seu ciclo de vida, é recomendável que a execução do workflow de gerência de projetos enfatize, durante as iterações iniciais, as atividades de planejamento, em detrimento das atividades de monitoramento e controle.

249. (STF/Analista Judiciário/Análise de Sistemas de Informações/2008) O docu-mento Vision (visão) é um artefato produzido sob responsabilidade da equipe de requisitos, e não deve conter informações detalhadas sobre a equipe e o cronograma do projeto nem detalhes técnicos da arquitetura do sistema. O conteúdo desse documento é, dessa forma, adequado para apoiar a validação dos requisitos.

250. (STJ/Analista Judiciário/Informática/2008) No RUP (rational unified process), um ciclo de desenvolvimento é dividido em quatro fases, uma delas é a de construção (construction). Nessa fase, tipicamente tem-se atividades da dis-ciplina de análise e projeto. Essas atividades realizam a definição preliminar da arquitetura do software e resultam na primeira versão de um documento que descreve a arquitetura.

251. (STJ/Analista Judiciário/Informática/2008) No RUP, a fase denominada elabo-ração (elaboration) é aquela em que as atividades da disciplina implementação (implementation) são mais intensas. Ao final dessa fase, o sistema provê todos os serviços previstos para a versão a ser entregue no final do atual ciclo de desenvolvimento e encontra-se em um estado que permite a sua instalação no ambiente dos usuários para início do teste beta.

252. (TST/Analista Judiciário/Análise de Sistemas/2008) As principais necessidades de informação devem estar identificadas ao final da fase de iniciação.


48

ELSEVIER

253. (TST/Analista Judiciário/Análise de Sistemas/2008) Não há código-fonte ou interfaces homem-máquina projetados antes da fase de construção.

254. (TST/Analista Judiciário/Análise de Sistemas/2008) A integração de compo-nentes é definida essencialmente na fase de construção.

255. (TST/Analista Judiciário/Análise de Sistemas/2008) Como o desenvolvimento é iterativo, a priorização do desenvolvimento é realizada ao final da fase de iniciação, mas é revista de acordo com os riscos de projeto a cada iteração.

3.4. Processos Ágeis

Estes processos surgiram com o manifesto ágil no qual vários autores da área de engenharia de software declararam: “Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo”. O eXtreme Programming (XP) e o Scrum são os principais processos ágeis cobrados em concursos.

O XP, proposto por Kent Beck (livro Programação Extrema Explicada), é uma metodologia bastante nova que renega todos os paradigmas do desenvolvimento tradicional de software.

Já o Scrum, proposto por Ken Schwaber, é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para a criação de produtos. Apesar do Scrum ser um processo de gerenciamento de produtos (não apenas software), muitas questões o tratam, equivocadamente, como um processo de desenvolvimento de software.

256. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) O SCRUM é um método ágil em que todos os itens do sprint backlog advêm do product backlog.

257. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) O desenvolvimento de um código na Extreme Programming está relacionado à fase de planejamento, pois, nessa metodologia, não há fase de desenvolvimento, haja vista que a codificação é realizada em pares.

258. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Para que se obtenha sucesso na utilização do Scrum, o cliente deve se tornar parte da equipe de desenvolvimento do software, participando diretamente do processo.

259. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Entre as metodologias ágeis para o desenvolvimento de software, o Scrum permite a criação de equipes auto-organizadas e, consequentemente, possibilita o in-centivo à comunicação verbal entre todos os membros da equipe. Da mesma forma que as abordagens típicas de Project Management Body of Knowledge ou


49

PRINCE2, o Scrum caracteriza-se por apresentar uma abordagem elementar do gerenciamento de projetos.

260. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) Cada sequência de etapas de um ciclo de vida aderente ao modelo em cascata é equivalente a uma iteração em um processo embasado no XP.

261. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) Metodologias ágeis, como a XP, enfatizam a documentação de software no próprio código, que deve ser escrito por meio de ferramenta CASE voltada ao desenvolvimento rápido de aplicações (RAD Tools).

262. (SERPRO/Analista/Desenvolvimento de Sistemas/2010) Scrum é uma metodolo-gia formal, desenvolvida no início deste século, que enfatiza o uso de padrões de projetos orientados a objetos para a construção de microarquiteturas de software.

263. (STM/Analista Judiciário/Análise de Sistemas/2010) O extreme programming (XP), que se inclui entre os métodos ágeis, apresenta, entre outras, as seguintes características: pequenos releases, projeto simples, refactoring, programação em pares e propriedade coletiva.

264. (MPU/Analista de Informática/Desenvolvimento/2010) Extreme programming (XP) é embasado em requisitos conhecidos, definidos de antemão, que não sofram muitas alterações, devendo ser usado por equipes de pequeno porte, formadas por representantes de todos os stakeholders.

265. (MPU/Analista de Informática/Desenvolvimento/2010) Produto da metodologia Scrum, o documento product backlog contém os requisitos definidos a partir da visão do cliente e é utilizado novamente no final do sprint para revisão ou modificações dos requisitos inicialmente definidos.

266. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) A metodologia XP prevê valores e princípios básicos para serem considerados durante o de-senvolvimento de software. Feedback, coragem e respeito são exemplos de valores; mudanças incrementais, abraçar mudanças e trabalho de qualidade são exemplos de princípios básicos.

267. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Um princípio-chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-se uma abordagem tradicional de controle. O Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

268. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O desenvolvimento adaptativo de software (DAS) é uma técnica para construção de sistemas e software complexos que foca na colaboração e na auto-organização da equipe.


50

ELSEVIER

269. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A agilidade não pode ser aplicada a todo e qualquer processo de software.

270. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O processo XP (extreme programming) envolve a realização das atividades de planejamento, de projeto, de codificação e de teste.

271. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A atividade de planejamento XP inclui a criação das denominadas histórias de usuário, nas quais devem ser descritas as características e as funcionalidades requeridas para o software em desenvolvimento.

272. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A atividade de projeto é uma desvantagem do processo XP, pelo fato de requerer uma quantidade de produtos de trabalho considerada excessiva pela comuni-dade de desenvolvimento de software.

273. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um software. Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog. Isso significa que product backlog e sprint backlog são estruturas similares.

274. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sistemas/2010) Na extreme programming, os requisitos são expressos como cenários e implementados diretamente como uma série de tarefas. O represen-tante do cliente faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.

275. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Extreme Programming é um modelo de processo de desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem software com base em requisitos vagos e que são modificados rapidamente.

276. (ANTAQ/Analista Administrativo/Informática/2009) O extreme program-ming (XP) constitui método ágil de desenvolvimento de software. Uma das práticas que se enquadram nos princípios dos métodos ágeis é a progra-mação em pares, que promove o compartilhamento da autoria do código do sistema. Além dessa vantagem, a programação em pares atua como processo informal de revisão porque cada linha de código é vista por pelo menos duas pessoas.

277. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) Os modelos ágeis são muito mais rápidos e eficientes que os modelos incremental e iterativo, não partilhando aqueles, portanto, das visões adotadas por estes.


51

3.5. Engenharia de Requisitos

Engenharia de Requisitos é o tópico com mais questões em concursos do Cespe quando o assunto é Engenharia de Software. Os principais autores cobrados são Pressman e Sommerville.

278. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. Além disso, a va-lidação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

279. (STM/Analista Judiciário/Análise de Sistemas/2010) São consideradas técnicas de validação de requisitos: revisões de requisitos, prototipação e geração de casos de teste.

280. (STM/Analista Judiciário/Análise de Sistemas/2010) Requisitos não funcio-nais são declarações dos serviços a serem fornecidos pelo sistema, enquanto requisitos funcionais restringem tanto o sistema quanto o processo de desen-volvimento que deve ser usado. Os requisitos funcionais podem ser de produto, organizacionais ou externos.

281. (STM/Analista Judiciário/Análise de Sistemas/2010) Um processo de elicitação e análise de requisitos envolve as seguintes atividades: obtenção de requisitos, em que são coletados os requisitos e os requisitos de domínio; classificação e organização de requisitos, que agrupa e organiza os requisitos relaciona-dos; priorização e negociação de requisitos, em que, com a participação dos stakeholders, são resolvidos os conflitos de requisitos; e documentação de requisitos, para a produção dos documentos de requisitos formais ou informais.

282. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Na con-cepção de engenharia de software, uma reunião ou entrevista é a técnica mais utilizada na elicitação de requisitos. Nesse momento, os requisitos de dados funcionais e comportamentais do sistema são levantados, refinados e anali-sados para serem validados pelos desenvolvedores e clientes/usuários.

283. (MPU/Analista de Informática/Desenvolvimento/2010) Embora a criação de uma sequência ilustrada de telas por meio de programas de desenho gráfico seja útil para a identificação de alguns requisitos do software, ela não é considerada uma atividade de prototipação, por não envolver o uso de uma linguagem de programação.

284. (MPU/Analista de Informática/Desenvolvimento/2010) O levantamento de requisitos é realizado ao final da primeira versão de um protótipo, para se


52

ELSEVIER

definir, junto aos envolvidos no processo, quais são as premissas básicas para o início do entendimento das funcionalidades desejadas.

285. (MPU/Analista de Informática/Desenvolvimento/2010) A verificação de requi-sitos tem por objetivo analisar se os modelos construídos estão de acordo com os requisitos definidos. Por sua vez, a validação de requisitos visa assegurar que as necessidades do cliente estão sendo atendidas por tais requisitos.

286. (MPU/Analista de Informática/Desenvolvimento/2010) A especificação 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 serão implementadas.

287. (MPU/Analista de Informática/Desenvolvimento/2010) Na validação de requisitos – parte integrante da especificação desses requisitos –, é correto o uso de dia-gramas da UML, tais como diagrama de classes, de casos de uso e de interação.

288. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Para o desenvolvimento de casos de uso, é fundamental a identificação dos atores, tanto os principais quanto os secundários, já na primeira iteração do levantamento de requisitos.

289. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O checklist de validação é uma forma útil de averiguar se determinado requisito pode ser testado e, em caso afirmativo, se os testes podem ser especificados.

290. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Por se tratar de função essencial da engenharia de requisitos, a gestão formal de requisitos é indispensável mesmo para projetos de pequeno porte, com apenas duas ou três dezenas de requisitos identificáveis.

291. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.

292. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Requisitos descrevem um acordo ou contrato entre duas partes, especificando, entre outros aspectos, o que o sistema de software deve fazer para ser aprovado em um teste de aceitação.

293. (ANATEL/Analista Administrativo/Análise de Negócios/2009) A elicitação de requisitos ocorre usualmente antes da fase de análise de requisitos, e resulta na produção de uma especificação precisa das necessidades do usuário, bem como dos requisitos do sistema a ser desenvolvido, o que exige maior interação social por parte do responsável pela elicitação, quando relacionada à exigência de interação durante a fase de análise.


53

294. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Acerca das simi-laridades e diferenças entre requisitos de software e requisitos de sistema, é correto afirmar que os primeiros devem ser elicitados antes dos segundos, e que ambos devem ser consistentes, não-ambíguos e verificáveis.

295. (ANTAQ/Analista Administrativo/Informática/2009) Uma técnica para levan-tamento de requisitos eficiente e recomendada pelo SWEBOK é o envio de questionário por e-mail, visto ser uma forma de elucidar com precisão as necessidades do usuário.

296. (ANTAQ/Analista Administrativo/Informática/2009) A especificação de requi-sitos é uma atividade fundamental do processo de software, mas carece de normas e técnicas que auxiliem as equipes nessa tarefa.

297. (ANTAQ/Analista Administrativo/Informática/2009) A validação de requisitos deve ser feita tanto por meio da análise subjetiva quanto por meio de atividades técnicas de revisão, prototipação, validação de modelo e testes de aceitação.

298. (TCE-RN/Assessor Técnico de Informática/2009) A etnografia é uma técnica utilizada para a descoberta de requisitos de sistemas de software na qual, por meio de observações, procura-se compreender os requisitos sociais e organizacionais do ambiente onde o sistema será usado.

299. (TCE-RN/Assessor Técnico de Informática/2009) A proteção, pelo sistema, das informações pessoais dos usuários cadastrados é exemplo de requisito fun-cional. A capacidade do sistema de gerar relatório de empréstimos de usuário em, no máximo, três segundos é um requisito não funcional.

300. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) VORD (viewpoint-oriented requeriments definition) é um framework para levantamento de requisitos, que consiste em realizar brainstorm no qual os stakeholders sugerem pontos de vista usando como técnica de cenários os diagramas de bolha e, para técnica de ponto de vista, os diagramas use case.

301. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Os requisitos podem ser classificados como de domínio, funcionais, não funcionais, permanentes ou consequentes. Os requisitos de domínio podem ser uma declaração explícita do que o sistema não deve fazer ou, ainda, uma característica que o mesmo tenha de ter, como, por exemplo, no máximo, 100 MB de tamanho; os funcionais detalham recursos que devem ser realizados pelo sistema; os permanentes originam-se da atividade principal da orienta-ção; os consequentes são requisitos voláteis e podem se modificar ao longo do desenvolvimento do sistema.

302. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) O gerenciamento de requisitos inclui, entre outras, as seguintes atividades: levantar, analisar, especificar, validar e prototipar requisitos funcionais e não-funcionais.


54

ELSEVIER

303. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) O levantamento de requisitos é importante, porém não é fundamental, pois recomenda-se avançar o quanto antes para as demais atividades que permitam uma visualização do software e reduzam a ansiedade do cliente em ver algo pronto.

3.6. Arquitetura de Software

Arquitetura refere-se a uma representação abstrata de componentes e comportamentos de um sistema. Uma arquitetura bem projetada deve ser capaz de atender aos requisitos funcionais e não funcionais do sistema e ser suficien-temente flexível para suportar requisitos voláteis. Os modelos de arquitetura mais cobrados pelo Cespe são a arquitetura cliente-servidor em duas camadas, a arquitetura cliente-servidor em três camadas e a arquitetura Model-View--Controller (MVC) em três ou em N camadas.

304. (STM/Analista Judiciário/Análise de Sistemas/2010) Aplicações web que não requerem controle de segurança podem ser construídas utilizando-se a arqui-tetura conhecida como modelo 1 ou MVC (model control view).

305. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) No padrão de desenvolvimento modelo-visualização-controlador (MVC), o controlador é o elemento responsável pela interpretação dos dados de entrada e pela ma-nipulação do modelo, de acordo com esses dados.

306. (STJ/Analista Judiciário/Informática/2008) Sistemas de software podem ser decompostos em subsistemas, que, por sua vez, podem ser decompostos em módulos. Um módulo é normalmente um componente de sistema que fornece um ou mais serviços para outros módulos. No desenvolvimento orientado a objetos, um módulo pode ser composto por um conjunto de classes.

307. (STJ/Analista Judiciário/Informática/2008) A arquitetura de um sistema de software pode se basear em determinado estilo de arquitetura. Um estilo de arquitetura é um padrão de organização. No estilo cliente-servidor, o sistema é organizado como um conjunto de serviços, servidores e clientes associados que acessam e usam os serviços. Os principais componentes desse estilo são servidores que oferecem serviços e clientes que solicitam os serviços.

308. (STJ/Analista Judiciário/Informática/2008) Na arquitetura cliente-servidor com três camadas (three tier), a camada de apresentação, a camada de aplicação e o gerenciamento de dados ocorrem em diferentes máquinas. A camada de apresentação provê a interface do usuário e interage com o usuário, sendo máquinas clientes responsáveis pela sua execução. A camada de aplicação é responsável pela lógica da aplicação, sendo executada em servidores de aplicação. Essa camada pode interagir com um ou mais bancos de dados ou


55

fontes de dados. Finalmente, o gerenciamento de dados ocorre em servidores de banco de dados, que processam as consultas da camada de aplicação e enviam os resultados.

3.7. Qualidade de Software

A qualidade de software não é uma dimensão única. Obter qualidade não é simplesmente "atender a requisitos" ou produzir um produto que atende às necessidades e expectativas dos usuários. Pelo contrário, a qualidade também inclui a identificação das medidas e dos critérios para demonstrar a obtenção da qualidade e a implementação de um processo para garantir que o produto por ele criado tenha atingido o grau desejado de qualidade e possa ser repetido e gerenciado. O Cespe tem aumentado gradativamente o número de questões sobre este assunto.

309. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) A engenharia da usabilidade é aplicada em qualquer tipo de interface, como, por exemplo, sítios web, software e desktop. Uma das principais fases da engenharia de usabilidade é a que permite o conhecimento do usuário ao qual o software se destina.

310. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) A pro-totipação possibilita que o usuário teste as características do produto final. Dos dois tipos de prototipação, a horizontal é focada nas funcionalidades que permitem ao usuário ver somente detalhes de determinadas partes do sistema.

311. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Em um teste de integração, é possível detectar possíveis falhas provenientes da integração interna dos componentes de um sistema. O teste de integração sucede o teste de unidade, no qual os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo é testado.

312. (MPU/Analista de Informática/Desenvolvimento/2010) O nível máximo de qua-lidade de um software é atingido quando os stakeholders estão satisfeitos com os resultados que ele apresenta; para tanto, é essencial que todos os envolvidos no processo de criação desse software façam parte da revisão de qualidade.

313. (MPU/Analista de Informática/Desenvolvimento/2010) A revisão de um projeto de software, tendo em vista a qualidade do processo de codificação, inclui, entre outros aspectos, verificar a ocorrência de erros de ortografia, o uso adequado das convenções da linguagem e se as constantes físicas estão corretas.

314. (MPU/Analista de Informática/Desenvolvimento/2010) O teste de integração geralmente é um processo de teste de caixa preta no qual os testes são deri-vados da especificação do sistema, cujo comportamento pode ser determinado por meio do estudo de suas entradas e saídas.


56

ELSEVIER

315. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Segundo o IEEE, defeito é um ato inconsistente cometido por um indivíduo ao tentar entender determinada informação, resolver um problema ou utilizar um método ou uma ferramenta; erro é o comportamento operacional do software diferente do esperado pelo usuário, e que pode ter sido causado por diversas falhas; e falha é uma manifestação concreta de um defeito em um artefato de software, ou seja, é qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa.

316. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) A técnica estrutural de teste de software (ou teste caixa branca), avalia o comportamento interno do componente de software, atuando diretamente sobre o código-fonte do componente para realizar testes de condição, de fluxo de dados, de ciclos e de caminhos lógicos.

317. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) Para a verificação de resultados de um protótipo de sistema, podem-se utilizar testes back-to-back, nos quais os mesmos casos de teste são submetidos ao protótipo e ao sistema em teste a fim de produzir um relatório de diferenças.

318. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Considerando-se o programa final como caixa preta, a validação dinâmica, ou teste, pode ser utilizada para identificar a ocorrência de defeitos no programa ou para confirmar se ele atende aos requisitos estabelecidos.

319. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Nos testes de caixa branca, o código-fonte do programa é usado para identificar testes de defeitos potenciais, particularmente no processo de validação, o qual demonstra se um programa atende a sua especificação.

320. (ANATEL/Analista Administrativo/Análise de Negócios/2009) Entre os prin-cipais processos da gestão da qualidade de software, estão a verificação, a validação, a revisão e a auditoria. Os processos de verificação e validação são processos mais associados ao controle do que à garantia da qualidade.


57

A partir da figura acima, que representa os fatores de qualidade de software, julgue os dois itens que se seguem.

321. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) A usabilidade é uma medida de qualidade de software a ser observada também no levantamento de requisitos, que pode ser auferida analisando-se subjeti-vamente as atitudes dos usuários em relação ao sistema, por exemplo, por meio de um questionário de avaliação. De acordo com a figura, a usabilidade estaria corretamente classificada se posicionada em #1.

322. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) A funcionalidade é um requisito funcional, uma característica a ser observada em um modelo de qualidade de software. Ela agrega subcaracterísticas como interoperabilidade, adequabilidade e acurácia. Segundo a figura, a interope-rabilidade estaria corretamente classificada se posicionada em #3.

323. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) A revisão técnica for-mal é atividade central que leva a efeito a avaliação da qualidade de software.

324. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) A garantia de software não avalia o impacto da falha de software sobre o sistema a ser desenvolvido.

325. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) Na gestão de configu-ração de software, a manutenção pode ser feita de maneira proativa, reativa, preventiva ou corretiva.

326. (STJ/Analista Judiciário/Informática/2008) Os processos no ciclo de vida de um produto de software podem ser classificados como fundamentais, de apoio ou organizacionais. O processo de garantia da qualidade pode ser considerado um processo de apoio que define atividades para garantir a conformidade dos processos e produtos de software com requisitos e planos estabelecidos. Um processo de garantia da qualidade pode abranger a garantia da qualidade do produto, do processo e do sistema de qualidade.

327. (STJ/Analista Judiciário/Informática/2008) Há modelos de qualidade de software nos quais os atributos de qualidade são agrupados em características de qua-lidade, que, por sua vez, são desdobradas em subcaracterísticas. Por exemplo, confiabilidade é uma possível característica e refere-se à capacidade de o software manter seu nível de desempenho, sob condições estabelecidas, por um período de tempo.

328. (STJ/Analista Judiciário/Informática/2008) Inspeções e walkthroughs podem fazer parte de um processo de verificação e validação, sendo realizadas por equipes cujos membros têm papéis definidos. Quando da inspeção de um có-digo, uma lista de verificação de erros (checklist) é usada. O conteúdo da lista tipicamente independe da linguagem de programação usada.


58

ELSEVIER

329. (STJ/Analista Judiciário/Informática/2008) Uma abordagem para o projeto de casos de teste consiste em identificar as partições de equivalência. Uma parti-ção de equivalência de entrada contém conjuntos de dados que são processados de modo equivalente. No teste estrutural, que é outra estratégia para projetar casos de teste, se usa o conhecimento da estrutura do programa. O teste de caminho é um teste estrutural no qual se procura exercitar os caminhos per-corridos ao executar o programa.

3.8. Orientação a Objetos

Neste item serão apresentadas questões sobre os principais conceitos de orientação a objetos, sem abordar uma linguagem de programação específica.

330. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Por meio do encapsulamento, para impedir o acesso direto ao atributo de um objeto, são disponibilizados externamente apenas os métodos que alteram esse objeto. Por exemplo, não é preciso conhecer todos os detalhes dos circuitos de uma câmera digital para utilizá-la; a parte externa da câmera encapsula os detalhes, provendo para o usuário uma interface mais amigável.

331. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Uma classe é capaz de instanciar um objeto de uma classe abstrata, para utilizar seus métodos e manipular seus atributos.

332. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) A abstração per-mite, entre outras funcionalidades, identificar e compor objetos complexos e construir estruturas, na forma de classes de objetos, para organizar objetos de diferentes tipos. Porém, conceitos implementados por classes que são construídas com base na abstração não podem ser generalizados nem espe-cializados.

333. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Em programação orientada a objetos, as propriedades que definem a estrutura e o comporta-mento de um objeto são especificadas para a classe da qual o objeto é instância e são válidas para todos os objetos dessa classe.

334. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Por meio da técnica denominada agregação, determinada operação pode ser programada para ter comportamentos distintos, quando aplicada a diferentes objetos.

335. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) O estado de um objeto é definido pelo conjunto de valores de suas propriedades.

336. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Todo objeto tem um identificador único que varia com o tempo de vida do objeto.


59

337. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Uma classe pode ser vista como uma descrição generalizada de uma coleção de objetos semelhantes.

338. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) Classes são constituídas por interfaces e nelas definidas. O nome de uma classe deve ser único e tem escopo dentro da interface na qual é declarado.

339. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sistemas/2010) Um objeto apresenta três características básicas, o estado, a identidade e o comportamento. A parte de dados de um objeto é definida por um conjunto de mensagens, e a porção funcional, por um conjunto de atributos.

340. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Objeto é o agrupamento de classes similares que apresentam os mesmos atributos e operações. Na definição de uma classe, é necessário estabelecer a que objeto ela ocorre como instância.

341. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) Polimorfismo permite estabelecer uma interface comum que define os atributos que um objeto pode receber em um grupo de classes criadas por herança. Assim, ao longo de uma hierarquia de classes, uma operação pode ter o mesmo nome compartilhado, e cada pacote, uma implementação diferente.

342. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Mensagem é uma solicitação entre classes para invocar certa operação, particularmente quando ocorre polimorfismo. Identidade é uma propriedade de um objeto que o distingue de todos os demais, sendo preservada até mesmo quando o estado do objeto muda completamente.

343. (ABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Herança é um mecanismo de reutilização de classes e atributos definidos em classes gerais por classes mais específicas que pode ser utilizado para expressar tanto associações quanto generalizações. Em herança linear múltipla, ocorrem múltiplas superclasses para uma mesma subclasse. As superclasses irão se comportar como classes concretas somente para o objeto instanciado na subclasse de herança múltipla, permanecendo abstratas para instâncias regulares.

344. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Pelo uso de polimorfismo, uma chamada de método pode fazer com que diferentes ações ocorram, dependendo do tipo do objeto que recebe a chamada.

345. (SERPRO/Analista/Desenvolvimento de Sistemas/2008) Na área de projeto de software, também conhecida como design de software, o software começa a ser implementado e validado pelos programadores.


60

ELSEVIER

346. (STJ/Analista Judiciário/Informática/2008) Se uma classe abstrata declara uma interface, essa classe tipicamente contém declarações de métodos, mas não corpos de métodos; a interface não pode ser implementada por classes que herdem da classe abstrata. Em diagramas UML, a classe abstrata pode ser identificada colocando-se seu nome em itálico, e relacionamentos de de-pendência podem ser representados por setas tracejadas entre clientes da interface e a classe abstrata.

347. (TST/Analista Judiciário/Análise de Sistemas/2008) Uma das consequências do polimorfismo é que objetos de classes diferentes podem receber mensagens idênticas para ativar operações das respectivas classes, embora o processa-mento real a ser realizado seja diferente em cada classe.

348. (TST/Analista Judiciário/Análise de Sistemas/2008) A sobreposição (overriding) é a funcionalidade pela qual duas instâncias de uma classe podem compartilhar, no todo ou em parte, determinada área da memória.

3.9. Unified Modeling Language (UML)

A UML é uma linguagem de modelagem visual, independente tanto de lingua-gens de programação quanto de processos de desenvolvimento. No entanto, tem sido muito utilizada para modelar sistemas de informação orientados a objetos. Essa linguagem é constituída por elementos gráficos, utilizados na modelagem, que permitem representar os conceitos do paradigma de orientação a objetos e, através deles, é possível construir diagramas que representam diversas perspec-tivas de um sistema. Os principais livros sobre este assunto são UML guia do Usuário de Booch, Rumbauch e Jacobson; e UML Essencial de Martin Fowler.

349. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O diagrama de componentes deve ser utilizado para representar a configuração e a arqui-tetura de um sistema no qual estarão ligados todos os software e hardware, bem como sua interação com outros elementos de suporte ao processamento.

350. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O diagrama de sequência pode ser usado para descrever como alguns objetos de um caso de uso colaboram em algum comportamento ao longo do tempo.

351. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Um rela-cionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A. Então, ao executar o caso de uso A, executa-se também o B.

352. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O diagrama de classes define todas as classes de que o sistema necessita e é a base para a construção dos diagramas de sequência e comunicação.


61

Tendo o diagrama UML da figura acima como referência, julgue os itens se-guintes (TRE-ES/Analista Judiciário/Análise de Sistemas/2011).

353. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) A figura representa um ator que, na figura acima, é o “submissor”, contudo essa mesma figura pode ser utilizada em situações diferentes para caracterizar um usuário, uma secretária ou uma impressora.

354. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) A figura indica a presença do pacote “controlador congresso”, que representa um mecanismo de propósito geral para organizar elementos de modelo em grupos.

355. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) A figura representa um diagrama do estado do sistema e de suas diversas fases de execução.

356. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) Na figura

, o trecho representa uma associação ConsTema () verdadeiro

recursiva que especifica que objetos de uma classe podem participar de, no máximo, uma das associações em determinado momento.

357. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) Na figura, o tempo é mostrado no eixo vertical e os objetos envolvidos na sequência de uma ativi-dade, no eixo horizontal.


62

ELSEVIER

358. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) A seta pontilhada “verdadeiro” indica a existência de um laço do processo executado pelo objeto “Sub1”.

359. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) No diagrama de caso de uso não há herança entre use case, apesar de haver entre os atores.

360. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) É possível indicar multiplicidade em diagramas de caso de uso. O diagrama ilustrado abaixo indica que o caso de uso conduzir transações é utilizado 400.000 vezes por dia pelos clientes. Cada cliente inicia o caso de uso duas vezes ao mês.

361. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) Em um diagrama de implantação com componentes, é possível indicar o protocolo na ligação entre dois nós, bem como mostrar relações de dependência entre componentes.

362. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) Uma agregação composta presente entre duas classes indica uma associação do tipo todo parte, em que uma classe é a parte e a outra, o todo.

363. (MEC/Atividade Técnica de Complexidade Gerencial/Arquiteto de Siste-mas/2011) O diagrama de sequência descreve as mudanças de estado ou con-dição de uma instância de uma classe na troca de mensagens entre os objetos.

364. (MPU/Analista de Informática/Desenvolvimento/2010) Na UML, um diagrama de atividades oferece uma notação para mostrar uma sequência de atividades, inclusive atividades paralelas. Ele pode ser aplicado em qualquer perspectiva ou propósito, no entanto, é normalmente mais utilizado para a visualização de fluxos de trabalho, processos de negócios e casos de uso.

365. (MPU/Analista de Informática/Desenvolvimento/2010) Na convenção de nota-ção usada na UML, a chamada por mensagens assíncronas é representada no diagrama de sequência por meio de seta cheia (não pontilhada).

366. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) O propósito maior de um caso de uso é fornecer uma descrição do comportamento do sistema. Assim, em um processo de desenvolvimento orientado a objetos, os objetivos de um caso de uso são: definir escopo, detalhar os processos e cálculos do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e direcionar os testes.


63

367. (TRE9-BA/Analista Judiciário/Análise de Sistemas/2009) Considerando o caso de uso e ator a seguir, é correto afirmar que, na narrativa do caso de uso, não é necessário se preocupar em como o sistema obteve ou calculou os dados, e que o desenvolvedor deve limitar-se a escrever o que o sistema responde e não como ele obtém a resposta. Caso de Uso: consultar preço Ator: vendedor 1. O ator inicia o caso de uso selecionando “consultar preço”; 2. O sistema oferece a interface para consulta de preços; 3. O ator seleciona um grupo de produtos; 4. O sistema lista os subgrupos do grupo selecionado; 5. O ator seleciona um subgrupo de produtos; 6. O sistema apresenta os produtos do subgrupo selecionado; 7. O ator seleciona os produtos; 8. O sistema calcula os preços.

368. (TCE-RN/Assessor Técnico de Informática/2009) Em um diagrama UML, a herança é um tipo de relacionamento especial que mistura características dos relacionamentos de generalização e dependência, sendo utilizada para identificar, no relacionamento entre classes, que uma herda o comportamento de outra, mas não sua estrutura.

Considerando o diagrama UML acima, julgue o seguinte item.


64

ELSEVIER

369. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) De acordo com o diagrama, estão corretas as seguintes afirmações: o ator Supervisor é uma especialização do ator Professor; o caso de uso Incluir Fal-tas é abstrato e pode ser acionado pelo ator Supervisor; o caso de uso Incluir Conteúdo Programático é abstrato e representa um segmento opcional de comportamento.

Tendo o diagrama UML da figura acima como referência, julgue os dois itens seguintes.

370. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) O método #Cadastrar() da classe Instrutor tem visibilidade do modo protegido tal que somente a classe possuidora Instrutor pode utilizá-lo.

371. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Na associação do tipo agregação composta identificado por #2, uma instância da classe Departamento pertence exclusivamente a uma única instância composta em Escola, e um objeto da classe Escola pode relacionar-se com, no máximo, três objetos da classe Departamento.


65

Com base no diagrama UML apresentado acima, julgue o item subsequente.

372. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) No referido diagrama, o número 1 no canto superior direito dentro do objeto fisica1: Física indica que esse objeto é unitário tal que, em padrões de projeto, pode ser classificado como do tipo singleton; #6 é uma mensagem de retorno sem disparo de método; e #5 é uma mensagem simples entre atores que indica somente a ocorrência de um evento.

Tendo o diagrama UML acima como referência, julgue os dois itens seguintes.

373. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Nesse diagrama, #1 é uma interface do tipo fornecida que descreve um serviço implementado; e #2 é uma interface do tipo requerida. Tas interfaces podem ser substituídas, sem prejuízo, pelos relacionamentos de dependência e rea-lização, respectivamente.


66

ELSEVIER

374. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Na figura, um diagrama UML de implantação é modelado juntamente com um diagrama de componentes, ambos voltados para a modelagem de aspectos físicos e estáticos de sistemas orientados a objetos.

375. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2009) Na UML 2.0, o diagrama de interação geral é utilizado para modelar colaborações, conjunto de instâncias que cooperam entre si para uma função específica; o diagrama de máquina de estados representa estados de um caso de uso de um subsistema ou de um sistema completo; e o diagrama de tempo demonstra a mudança de estado de um objeto, ao longo do tempo decorrente de eventos externos.

376. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) A figura a seguir ilustra um diagrama de implantação usado para modelar a visão estática de implantação de um sistema, que, em geral, envolve a modelagem da topologia do hardware no qual o sistema executa. Essencialmente, são diagramas de classe que incidem sobre os nós de um sistema.

Fonte: Booch, Rumbauch e Jacobson (2006, p. 411)


67

Tendo o diagrama UML acima como referência, julgue os dois itens seguintes.

377. (STJ/Analista Judiciário/Informática/2008) De acordo com o diagrama, a classe CntrPersistenciaRelacional implementa IPersistencia; a classe Pessoa pode ser instanciada; a classe CntrAutenticacao é abstrata e implementa IRAuten-ticacao; Driver é uma classe da associação entre CntrPersistenciaRelacional e Conexao; o método conectar da classe CntrPersistencia é protegido e visível a partir de código que esteja presente no método desconectar da classe Cntr-PersistenciaRelacional.

378. (STJ/Analista Judiciário/Informática/2008) No diagrama, uma instância da classe Grupo pode ter ligações para mais de uma instância dessa mesma classe; a classe Grupo herda um atributo da classe Usuario; há uma agregação entre Grupo e Usuario; o método desconectar, na classe CntrPersistenciaRelacional, tem visibilidade pública; cada objeto da classe TelaAutenticacao pode ter uma ligação com um objeto da classe Grupo.


68

ELSEVIER

Tendo o diagrama UML acima como referência, julgue o seguinte item.

379. (STJ/Analista Judiciário/Informática/2008) No diagrama da figura, telaA é o nome de uma instância de uma classe; três objetos são criados e dois são des-truídos; há duas autochamadas e uma delas só é executada se uma condição de guarda for satisfeita; a mensagem da instância de TelaReserva para a de CntrReserva é assíncrona; a mensagem da instância de TelaResultado para a de CntrReserva é síncrona.


69

Tendo o diagrama UML acima como referência, julgue o item seguinte.

380. (STJ/Analista Judiciário/Informática/2008) No diagrama da figura, há dois nós interligados, que representam duas unidades computacionais; há cinco componentes distribuídos entre os nós; um destes implementa uma interface e um outro depende dessa interface; ClienteAplicacao depende de Stub; Ser-vidorAplicacao depende de Banco de dados.

381. (STJ/Analista Judiciário/Informática/2008) Em um modelo construído com a UML, estão corretas as seguintes características de diagramas de atividades: separações (forks) e junções (joins) são empregadas quando há atividades em paralelo; cada junção tem uma transição de entrada e várias de saída; cada separação tem várias transições de entrada e uma de saída; atividades estão agrupadas em raias separadas por linhas.

382. (STJ/Analista Judiciário/Informática/2008) As seguintes características estão corretas para um modelo construído com a UML: nos diagramas de compo-nentes, há módulos de código representados por componentes; há diagramas de componentes onde dependências de compilação estão representadas por setas tracejadas entre componentes; nos diagramas de utilização (deployment), alguns nós representam unidades computacionais, outros representam dispo-sitivos periféricos.

383. (TST/Analista Judiciário/Análise de Sistemas/2008) Na abordagem de análise UML (unified modelling language), a visão de modelo comportamental repre-senta a dinâmica do sistema nas interações entre seus diversos elementos estruturais.

384. (TST/Analista Judiciário/Análise de Sistemas/2008) Na UML, os casos de uso descrevem cenários de utilização do software, explicitando os atores e as fun-cionalidades disponibilizadas.

385. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Na abordagem de análise UML (unified modelling language), a visão de modelo comportamental representa o sistema do ponto de vista dos comportamentos e interações do sistema com o usuário.


70

ELSEVIER

386. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Em um diagrama de casos de uso da UML, um ator é definido como um usuário humano do sistema.

387. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Na UML, uma agre-gação é um relacionamento que estabelece que uma classe define objetos que são parte de um objeto definido por outra classe.

388. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Em um diagrama de classes UML, uma associação entre classes pode ser documentada em termos da multiplicidade da associação.

389. (MPE-AM/Analista Judiciário/Analista de Sistemas/2008) Um diagrama de sequência da UML apresenta tanto as interações entre atores e objetos quanto interações de objeto para objeto.


71

C a p í t u l o 4

Questões de Gestão de Tecnologia da Informação

Os diversos modelos de gestão de TI, que antes costumavam ser cobrados apenas em alguns concursos específicos, tornaram-se conteúdo obrigatório em quase todos os editais. Ao mesmo tempo, o nível de cobrança das questões tem aumentado de forma significativa: enquanto há poucos anos cobrava-se mais o conhecimento de conceitos básicos e a identificação dos processos, nas provas mais recentes com frequência encontram-se questões sobre ferramentas, indicadores e outros detalhes menos conhecidos do conteúdo, o que representa um desafio a mais para os estudos.

4.1. Gerenciamento de Projetos

Historicamente, a maioria das questões sobre o assunto concentra-se sobre os processos das áreas de conhecimento de gerenciamento de escopo, de tempo, de custos e de riscos. Mais recentemente, tem havido um aumento das questões sobre o contexto do gerenciamento de projetos, em especial sobre escritórios de projetos.

Embora a maioria absoluta das questões sobre gerenciamento de projetos seja baseada nos conceitos e processos descritos no Guia PMBOK, é importante notar que o Cespe também costuma, de forma esporádica, elaborar questões com base em conceitos sobre o gerenciamento de projetos apresentados por Pressman e Sommerville em seus livros sobre engenharia de software.

4.1.1. Conceitos básicos de gerenciamento de projetos

390. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) Um projeto pode ser definido como o esforço temporário empreendido para criar um produto, ser-viço ou resultado, e o seu término somente é alcançado quando se atingem os objetivos.

391. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) As quatro possibilidades de término de projeto são absorção, integração, esgotamento e extinção.

392. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) O gerente de projetos é responsável pelo controle dos recursos atribuídos ao projeto para atender aos seus objetivos, bem como pela otimização dos recursos organizacionais compartilhados entre todos os projetos.

393. (IPEA/Analista de Sistemas/Processos de Negócios/2008) A gerência por proje-tos trata muitos aspectos dos serviços continuados como projetos, objetivando aplicar também a eles os conceitos de gerência de projetos.

394. (TCE-RN/Inspetor de Controle Externo/Tecnologia da Informação/2009) Em gerenciamento de projetos, as operações são caracterizadas por objetivos que podem ser medidos qualitativa e financeiramente.

395. (Antaq/Analista Administrativo/Informática/2009) As habilidades interpessoais são mais relevantes no gerenciamento de recursos humanos e de comunicação que no gerenciamento de custos e de tempo.

4.1.2. Portfólios, programas e estruturas organizacionais

396. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) O gerenciamento de portfólios, que, entre outras finalidades, visa garantir que projetos e progra-mas sejam analisados de modo a se priorizar a alocação de recursos, deve ser consistente e estar alinhado às estratégias da organização.

397. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Programas são grupos de projetos relacionados e um projeto, seja ele qual for, será parte de um programa.

398. (Serpro/Analista/Negócios em Tecnologia da Informação/2008) Os subprojetos, resultantes da divisão de projetos em componentes mais facilmente gerenci-áveis, são geralmente implementados por uma empresa externa contratada ou por uma unidade funcional na organização executora.

399. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) Em uma estrutura de projeto do tipo matricial, há uma combinação de estruturas funcional e projetizada, de modo que os grupos de projeto es-tejam sob a responsabilidade de um único gerente de projeto. Cada equipe de


74

ELSEVIER

projeto possui atividades apenas no projeto do qual faz parte, não possuindo atividades junto ao setor funcional em que se encontra.

400. (Serpro/Analista/Administração de Serviços de Tecnologia da Informação/2008) Considerando a figura abaixo, se A, B e C são gerentes funcionais, então a organização, como regra geral, estará melhor adaptada à mudança, quando comparada a uma situação na qual A, B e C são gerentes de projetos.

401. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Em uma organização do tipo matricial forte, os gerentes de projeto têm o mais alto nível de autoridade e poder.

4.1.3. Escritórios de projetos e outras partes interessadas

402. (Sebrae-DF/Analista Técnico/2008) O PMO (project management organization) é a unidade organizacional que concentra os projetos sob seu domínio para coordená-los de maneira integrada.

403. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Um gerente de projeto e um escritório de projeto (PMO) são orientados por objetivos diferentes e, por isso, a responsabilidade do PMO é a de fornecer suporte ao gerenciamento de projetos, não cabendo a ele o gerenciamento direto de um projeto.

404. (TJ-ES/Analista Judiciário 02/Análise de Sistemas/2011) O escritório de pro-jetos é responsável pelo gerenciamento das restrições relativas ao escopo, ao cronograma, ao custo e à qualidade dos projetos individuais; ao passo que o gerente de projetos é responsável pelo gerenciamento de metodologias, padrões e interdependências entre os projetos.

405. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Um escri-tório de projetos pode ser implantado em qualquer tipo de estrutura organiza-cional — funcional, matricial ou por projeto — e ele pode ter autoridade para supervisionar e cancelar projetos.

Capítulo 4 I Questões de Gestão de Tecnologia da Informação

75

406. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) O escritório de projetos de uma organização tem, entre outras, as seguintes atribuições: padronização de processos de suporte a projetos, treinamento de pessoal, gerenciamento de recursos e elaboração do plano estratégico da organização.

407. (TCE-RN/Inspetor de Controle Externo/Tecnologia da Informação/2009) No PMBOK, os stakeholders são definidos como indivíduos ou organizações en-volvidos no projeto, ou que serão afetados positivamente ou negativamente pelo resultado final de um projeto. Esses indivíduos e organizações devem ser identificados, mas não são elementos-chave em um projeto.

4.1.4. Ciclo de vida e grupos de processos

408. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) As fases de um projeto são divisões desse projeto, sendo que o trabalho em cada uma delas tem foco distinto do de qualquer outra fase e, por isso, geralmente cada fase requer organização e habilidades específicas.

409. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Quando o projeto é dividido em fases, o fim de cada fase representa um marco que, quando atingido, possibilita o início da fase seguinte do projeto.

410. (MPU/Analista de Informática/Perito/2010) Um dos tipos básicos de relação entre as fases de um projeto é a iterativa, em que apenas uma fase está pla-nejada a cada momento e o planejamento da próxima é feito à medida que o trabalho avança na fase atual e nas entregas.

411. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O ciclo de vida de um produto inicia-se quando os ciclos de vida dos projetos a ele relacionados são encerrados.

412. (STF/Analista Judiciário/Análise de Sistemas de Informação/2008) A melhor associação para os elementos de #1 a #5 na figura abaixo é iniciação, plane-jamento, execução, controle e encerramento.


76

ELSEVIER

413. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Os grupos de processos são fases do ciclo de vida do projeto que permite a separação em fases ou subprojetos distintos de projetos grandes ou complexos.

414. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) Em projetos com várias fases, os processos de iniciação são re-alizados durante fases subsequentes para validar as premissas e as decisões tomadas no início do projeto.

415. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Os grupos de processos de planejamento e de monitoramento e controle servem como entrada de um para o outro reciprocamente.

4.1.5. Gerência de integração

416. (Previc/Analista Administrativo/Tecnologia da Informação/2011) O termo de abertura de um projeto descreve os objetivos do projeto e os requisitos gerais necessários para satisfazer as expectativas das partes interessadas, além de ser uma das entradas do processo de desenvolver o plano de gerenciamento do projeto, realizado pelo grupo de planejamento.

417. (TJ-ES/Analista Judiciário 02/Análise de Sistemas/2011) Entre os documentos relativos aos termos de abertura de projetos, a declaração de trabalho é o documento que contém a descrição narrativa dos produtos e serviços a serem fornecidos pelo projeto e no qual são informadas, entre outros aspectos, as necessidades de negócio embasadas em demanda de mercado, avanço tecno-lógico, requisito legal ou regulamentação de governo.

418. (Sebrae-DF/Analista Técnico/2008) Os processos de monitoramento e con-trole contêm atividades estratégicas que embasam exceções no percurso de um projeto, pois permitem a definição de ações emergenciais para mudanças no gerenciamento de projetos, mesmo que tais mudanças não tenham sido aprovadas.

419. (Antaq/Analista Administrativo/Informática/2009) O sistema de gerência de configuração de um projeto é um subsistema dentro do processo de gerencia-mento de escopo.

420. (TJ-ES/Analista Judiciário 02/Análise de Sistemas/2011) Nas saídas do pro-cesso de realização do controle integrado de mudanças, caso as mudanças sejam consideradas exequíveis e estejam fora do escopo do projeto, para sua aprovação, é requerida mudança na linha de base do tempo atual para frente, e os desempenhos passados não podem ser modificados, a fim de que se pro-tejam a integridade das linhas de base e os dados históricos de desempenhos passados.


77

421. (Antaq/Analista Administrativo/Informática/2009) Os processos e procedi-mentos da organização, bem como as bases de conhecimento corporativo são exemplos de categorias de ativos de processos organizacionais, em que a primeira categoria incorpora controles de gestão, e a segunda, registros de não conformidades.

4.1.6. Gerência de escopo

422. (Correios/Analista de Correios/Suporte de Sistemas/2011) Considere que, para o desenvolvimento de determinado projeto referente à entrega de um produto que será vendido em lojas de informática, seja necessário coletar requisitos e definir o escopo. Com base nessa situação, é correto afirmar que essas etapas fazem parte do plano de gerenciamento de recursos humanos.

423. (Sebrae-DF/Analista Técnico/2008) Na definição do escopo do projeto, o cliente é o mais atuante, portanto não é necessária uma opinião especializada, pois esta será necessária apenas na execução do projeto.

424. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) A estrutura analítica do projeto (EAP) subdivide as principais entregas do projeto e do trabalho necessário para desenvolvê-lo em componentes menores e mais facilmente gerenciáveis. Para isso, deve incluir o trabalho definido pelo escopo do projeto, considerando as ações, internas e externas, para que ele esteja completo. As atividades de gerenciamento de projetos, controladas em separado por meio de ferramentas e técnicas específicas, não são contempladas pela EAP.

425. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) As entradas do proces-so de criação da estrutura analítica do projeto incluem o termo de abertura, a documentação dos requisitos e os ativos de processos organizacionais.

4.1.7. Gerência de tempo

426. (STJ/Analista Judiciário/Informática/2008) Em um processo de gerenciamento de tempo, tipicamente existem atividades que visam: identificar atividades que precisam ser realizadas para produzir as entregas; identificar e documentar dependências entre atividades; estimar tipos e quantidades de recursos para realizar cada atividade; estimar o trabalho para terminar as atividades; analisar recursos necessários, restrições, durações e sequências de atividades para criar o cronograma do projeto.

427. (Antaq/Analista Administrativo/Informática/2009) Durante o gerenciamento de tempo de um projeto, a estimativa de duração de atividades é estabelecida após a definição e o sequenciamento de atividades, mas antes da estimativa dos recursos necessários à realização de cada atividade.


78

ELSEVIER

428. (Sebrae-DF/Analista Técnico/2008) O gerenciamento do tempo do projeto não deve se basear apenas no cronograma, pois, de acordo com a velocidade dos projetos, muitas vezes, eles não são atualizados. Portanto, deve-se ter como referência a EAP para tanto.

429. (TST/Analista Judiciário Análise de Sistemas/2008) A ocorrência de flutuação de prazo em uma atividade do caminho crítico de um projeto pode ser com-pensada pelo adiantamento de outras atividades fora do caminho crítico.

430. (STM/Analista Judiciário/Análise de Sistemas/2011) Diagramas de barras e redes de atividades são notações gráficas usadas para ilustrar o cronograma e o custo de um projeto. Enquanto o diagrama de barras mostra a duração das atividades, as redes de atividades mostram os interrelacionamentos entre as atividades.

431. (IPEA/Analista de Sistemas/Processos de Negócios/2008) Os diagramas de rede do projeto ou gráficos de PERT são um esquema de apresentação das atividades do projeto e dos relacionamentos lógicos entre eles. Os riscos identificados de alta probabilidade ou impacto podem ser considerados entradas para a estimativa da duração das atividades e incorporados à baseline de duração de cada atividade.

432. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) Uma linha de base do cronograma é um componente do plano de gerenciamento do projeto e se baseia na análise de rede PERT do cronograma do modelo de atividades. Ela fornece a base para medição e emissão de relatórios de desempenho, de prazos e de custos como parte da linha de base da medição de atividades do projeto.

4.1.8. Gerência de custos

433. (STJ/Analista Judiciário/Informática/2008) A estimativa de custos em um pro-jeto pode empregar diversas técnicas, por exemplo, a estimativa análoga e a estimativa paramétrica. Na estimativa paramétrica, são usados os custos de projetos anteriores para estimar os custos do projeto atual. Essa estratégia é tipicamente usada quando há uma quantidade limitada de informações sobre o projeto sendo executado. Por sua vez, a estimativa análoga utiliza uma relação estatística entre dados históricos para estimar custos.

434. (TJDFT/Analista Judiciário/Análise de Sistemas/2008) No processo de uso da téc-nica de análise do valor agregado (earned value analysis), para acompanhamento de um projeto, o cálculo de um valor negativo para a variância do escalonamento (schedule variance) significa que o projeto está com prazo atrasado.

435. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Se, em um projeto, o valor agregado a um componente da estrutura analítica de projetos ou atividade do cronograma for inferior ao custo real correspondente ao ele-


79

mento em foco (componente ou atividade), o índice de desempenho de custos correspondente ao elemento assumirá um valor maior que um, sinalizando que o projeto pode estar acima do orçamento.

4.1.9. Gerência de riscos

436. (Sebrae-DF/Analista Técnico/2008) Um risco ao projeto é uma condição de incerteza que pode causar apenas efeitos negativos e por isso os riscos devem ser sempre eliminados.

437. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó-cios e Tecnologia da Informação/2009) No processo de identificação de riscos, diagramas de causa e efeito e diagramas de influência são utilizados como técnicas para estudo de riscos.

438. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) Identi-ficar os riscos é o processo em que os riscos que podem afetar o projeto são determinados, gerando-se uma lista de riscos identificados. Esse processo pode produzir, ainda, uma lista de respostas potenciais aos riscos.

439. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Os riscos desconhecidos podem representar uma ameaça ou uma oportunidade, por isso, o gerente de projeto deve manter reserva dos seus recursos para controlá-los quando necessário.

440. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) A pro-babilidade de ocorrências de risco e suas consequências são avaliadas pelo processo realizar a análise qualitativa de riscos, com o uso da atribuição de probabilidades numéricas.

441. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) A análise de sensibilidade é uma técnica que examina a extensão com que a incerteza de cada elemento do projeto afeta o objetivo que está sendo examinado, quando todos os outros elementos incer-tos são mantidos em seus valores de linha de base. Essa técnica é usada no processo de análise quantitativa de riscos.

4.1.10. Gerências de qualidade, RH, comunicações e aquisições

442. (Basa/Técnico Científico/Governança de TI/2010) Entre o grupo de processos de execução, o processo “realizar a garantia de qualidade” visa garantir que o projeto realize os processos necessários para atender aos requisitos do projeto. São exemplos de algumas entradas desse processo, o plano de gerenciamento de projetos, reparos de defeitos e ações preventivas implementadas.


80

ELSEVIER

443. (Sebrae-DF/Analista Técnico/2008) O gerenciamento de recursos humanos do projeto engloba o planejamento, a contratação ou mobilização, o desenvolvi-mento e gerenciamento da equipe do projeto. O treinamento é uma atividade externa a esse processo e deve ser considerada na área de gerenciamento das comunicações do projeto.

444. (Correios/Analista de Correios/Suporte de Sistemas/2011) Suponha que, du-rante a execução de um projeto, ocorra grande conflito entre os stakeholders, e o gerente do projeto identifique a necessidade de resolvê-lo imediatamente, para que gere um grau de satisfação para ambas as partes, garantindo a con-tinuidade do projeto. Nessa situação, a técnica mais adequada para gerenciar o conflito é a negociação.

445. (TCU/Analista de Controle Externo/Tecnologia da Informação/2007) Considerando que estejam envolvidas 40 pessoas na primeira fase do projeto e 25, na segunda, a diferença no número de canais de comunicação entre as duas fases é de 455.

446. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) Os processos de gerenciamento de aquisição do projeto referem--se ao que deve ser comprado, como e de quem será comprado, por meio de contratos que são acompanhados do início ao fim das aquisições, ou seja, em todo o seu ciclo de vida. Os contratos também podem ser denominados acordos, subcontratos ou pedidos de compra.

447. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó-cios e Tecnologia da Informação/2009) Para minimizar os efeitos de decisões pessoais na seleção de fornecedores, utiliza-se um sistema de ponderação. Na maioria desses sistemas, são atribuídos pesos numéricos a cada um dos critérios de avaliação.

448. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O desem-penho dos fornecedores de um projeto, analisado no processo Administrar as aquisições, pode ser usado como medida de competência do fornecedor na contratação de trabalhos futuros semelhantes, assim como para subsidiar a retificação de contratos.

449. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Opinião especializada, auditorias de aquisições, acordos negociados e sistema de gerenciamento de registros são recursos e técnicas empregados no processo encerrar as aquisições.


Embora o antigo modelo CMM tenha sido um dos precursores da cobrança de gestão de TI em concursos, nos últimos anos tem diminuído a quantidade de questões sobre modelos de qualidade de software nas provas. Nem mesmo


81

a introdução do modelo MPS.BR, juntamente com o CMMI, foi suficiente para reverter esse quadro. Em ambos os casos, a maioria das questões concentra-se na compreensão dos níveis de capacidade ou maturidade, conforme o caso, e na associação entre processos e respectivos níveis de maturidade.

4.2.1. CMMI – Conceitos básicos e estrutura

450. (MPU/Analista de Informática/Perito/2010) Os múltiplos modelos CMM evolu-íram para um modelo integrado, o CMMI, planejado para ser formado por um conjunto único de componentes que atende os interesses de desenvolvimento, serviços e aquisição de software.

451. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O CMMI abrange práticas que cobrem o ciclo de vida do produto desde a sua concepção até sua entrega, além das atividades de manutenção aplicadas a produtos e serviços.

452. (STM/Analista Judiciário/Análise de Sistemas/2011) As representações por estágios e contínua, no CMMI, utilizam conceitos como áreas de processo, objetivos específicos, práticas específicas, objetivos genéricos e práticas gené-ricas. Áreas de processo são um conjunto de práticas que, quando executadas coletivamente, satisfazem um conjunto de objetivos. Os objetivos genéricos são aplicados para cada área de processo e identificam características únicas que descrevem o que deve ser implementado para satisfazer a área de processo.

453. (ANEEL/Analista Administrativo/Área 3/2010) As notas, exemplos, relatórios, amplificações e referências são componentes informativos de suporte do mo-delo CMMI.

454. (MPU/Analista de Informática/Perito/2010) Um exemplo de componente infor-mativo é o glossário de termos do CMMI.

4.2.2. CMMI – Níveis de capacidade e maturidade

455. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O CMMI propõe dois tipos de representação para os planos de melhoria e avalia-ção de processos: a representação contínua e a representação por estágios. Ao definir seu plano, uma organização deverá utilizar exclusivamente uma delas, uma vez que elas são embasadas em princípios incompatíveis.

456. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Seis são os níveis nos quais se pode mensurar o desempenho de metas e práticas rela-cionadas a uma área de processo individual, enquanto cinco são os níveis nos quais se pode mensurar o alcance de platôs evolucionários para a melhoria de processos organizacionais. A medição de capacidades de processos é requisito para a medição de maturidade organizacional.


82

ELSEVIER

457. (Basa/Técnico Científico/Governança de TI/2010) No que se refere à melhoria de processos em uma organização, se a estratégia exige rigidez, então deve-se adotar a representação contínua do modelo CMMI, em alternativa à represen-tação em estágios.

458. (STF/Analista Judiciário/Análise de Sistemas de Informação/2008) Ao avaliar se determinada organização alcançou o nível de capacidade 1 em uma área de processo, um avaliador CMMI deverá atentar para o desempenho satisfatório de práticas específicas associadas a essa área de processos.

459. (ANEEL/Analista Administrativo/Área 3/2010) O processo é planejado e exe-cutado no nível 2 do modelo CMMI, de acordo com políticas organizacionais, por pessoal habilitado e utilizando recursos adequados para gerar saídas de forma controlada. Esse processo envolve os grupos interessados adequados, além de ser monitorado, controlado, revisado e avaliado quanto à conformidade com sua descrição e ao desempenho previsto nos seus planos.

460. (Previc/Analista Administrativo/Tecnologia da Informação/2011) No nível 3 de maturidade do modelo CMMI, o processo é planejado e executado de acordo com políticas organizacionais, devendo-se utilizar pessoal habilitado e recur-sos adequados para gerar saídas de forma controlada e envolver os grupos interessados adequados.

461. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) O estabe-lecimento e a manutenção do plano para a execução do processo é uma prática genérica necessária ao nível de maturidade 3 do CMMI.

462. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) No nível de maturidade 4 do CMMI, o desempenho dos processos é previsível quanti-tavamente, ao passo que, no nível 3, a previsibilidade é apenas qualitativa.

463. (Previc/Analista Administrativo/Tecnologia da Informação/2011) Uma das características do nível 4 de maturidade do modelo CMMI diz respeito à impor-tância e à explicitação da análise e da eliminação das causas dos problemas ocorridos no desenvolvimento e manutenção de software.

464. (Basa/Técnico Científico/Governança de TI/2010) No modelo CMMI, a avaliação formal de processos baseia-se no método SCAMPI, que apresenta cinco dife-rentes níveis de avaliação, sendo o nível 1 o inicial, e o nível 5, o otimizante.

4.2.3. CMMI – Áreas de Processo

465. (Sebrae-DF/Analista Técnico/2008) As dezenas de áreas de processo do CMMI não contemplam as seguintes: atendimento a marcos regulatórios, gerencia-mento de riscos de processo e inovação organizacional, visto que essas áreas abrangem particularidades muito específicas de cada contexto organizacional.


83

466. (STJ/Analista Judiciário/Informática/2008) No nível de maturidade definido (de-fined), é definida a área de processo gerenciamento de requisitos (requirements management), que visa gerenciar requisitos e identificar as inconsistências entre requisitos, planos e produtos do projeto. Por sua vez, no nível gerenciado (managed), é definida a área de processo gerenciamento de riscos, que visa o planejamento e a execução de atividades destinadas a tratar os riscos.

467. (Min. Comunicações/Informática/Análise de Sistemas/2008) A área de pro-cesso denominada análise causal e resolução (causal analysis e resolution) encontra-se definida no nível de maturidade otimizado (optimizing) e objetiva identificar as causas dos defeitos e outros problemas e tomar ações para evitar que defeitos e problemas se repitam no futuro.

468. (Antaq/Analista Administrativo/Informática/2009) Existem quatro categorias de áreas de processo no modelo CMMI para desenvolvimento: gerenciamento de processo, gerenciamento de produto, engenharia e apoio.

469. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Validação, verificação e integração do produto são processos que integram a disciplina de suporte ao processo de software.

470. (Anac/Analista Administrativo/Tecnologia da Informação/2009) No CMMI, a área de processo de desempenho do processo organizacional (OPP) deriva os objetivos quantitativos de qualidade e desempenho dos processos a partir dos objetivos de negócios da organização, a qual fornece aos projetos e grupos de suporte medidas comuns, baselines de desempenho de processos e modelos de desempenho de processos.

471. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) São pro-dutos de trabalho típicos encontrados em organizações que estão no nível de maturidade 2 segundo o modelo CMMI: diagramas de causa e efeito; decla-rações das necessidades e objetivos dos processos da organização; listas de fontes de riscos, de origem interna e externa.

472. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Testes de cobertura de caminhos, normas e políticas organizacionais, relatórios de avaliação de produtos de software de prateleira (COTS) são artefatos de tra-balho típicos que caracterizam uma organização que desempenha processos de validação no nível de capacidade 1.

473. (Basa/Técnico Científico/Governança de TI/2010) No âmbito das organizações que adotam o modelo CMMI, verifica-se que as práticas e produtos de trabalho relacionadas à área de desenvolvimento de requisitos são menos frequentes que as práticas e produtos relativas à área de gerenciamento de requisitos.

474. (Basa/Técnico Científico/Governança de TI/2010) Nas organizações que adotam o modelo CMMI, o gerenciamento das interfaces internas e externas entre os


84

ELSEVIER

componentes de uma solução em desenvolvimento constitui atividade carac-terística da área de processo de verificação.

475. (Basa/Técnico Científico/Governança de TI/2010) No modelo CMMI, não há, em relação aos componentes requeridos ou esperados na área de processo denominada gerenciamento de riscos, prescrição em favor de abordagem quantitativas ou qualitativas no gerenciamento de riscos de projeto.

476. (Basa/Técnico Científico/Governança de TI/2010) No modelo CMMI, alguns produtos típicos da área de solução técnica são utilizados para definir as aquisições a serem feitas na área de processo denominada gerenciamento de acordo com fornecedores, pertencendo as duas áreas citadas à categoria de processos de suporte.

477. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) O desenvolvimento do plano de projeto cobre avaliações de pro-cessos, avaliações de produtos, gerenciamento de configurações e medições e análises. O plano do projeto define o nível apropriado de monitoramento do projeto, a frequência das revisões de progresso e as medidas utilizadas para monitorar o progresso.

478. (Basa/Técnico Científico/Governança de TI/2010) A estrutura analítica de pro-jeto (EAP) desenvolvida de forma orientada a produto, caso esteja presente em uma organização que adote o modelo CMMI, é resultado típico de trabalho gerado por práticas da área de processo denominada integração de produto.

479. (Serpro/Analista/Negócios em Tecnologia da Informação/2008) Entre as práticas específicas do planejamento do projeto, incluem-se: a estimativa do escopo do projeto; o estabelecimento das estimativas de atributos de produtos de trabalho e de tarefas; a definição do ciclo de vida do projeto; a identificação e monitoramento dos riscos do projeto; o estabelecimento do orçamento e do cronograma; o planejamento dos recursos do projeto; o monitoramento do gerenciamento dos dados; o estabelecimento do plano de projeto; a revisão dos planos que afetam o projeto.

4.2.4. MPS.BR – Conceitos básicos e níveis de maturidade

480. (Sebrae-DF/Analista Técnico/2008) Qualidade é algo que se aplica no processo e no produto, no entanto, a qualidade do processo em nada interfere na qua-lidade do produto, e vice-versa.

481. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Uma das principais bases técnicas para a criação do modelo de referência do MPS.BR foi uma norma ISO/IEC, a qual estabeleceu uma arquitetura para o ciclo de vida dos processos de software.


85

482. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) O MPS.BR é formado por três componentes e respectivos guias. O modelo de referência é formado pelos guias geral, de aquisição e de implementação.

483. (Antaq/Analista Administrativo/Informática/2009) O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Nesse contexto, o MPS.BR, que possui três componentes: Modelo de Referência, Método de Avaliação e Modelo de Negócio, é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. No Brasil, uma das principais vantagens desse modelo é seu custo reduzido de certificação em relação às normas estrangeiras e, portanto, é avaliado como ideal para micro, pequenas e médias empresas.

484. (Sebrae-DF/Analista Técnico/2008) No MPS/BR, verifica-se se o processo atinge seus resultados, ou seja, busca-se garantir que o processo transforme produtos de trabalho de entrada identificáveis em produtos de trabalho de saída também identificáveis.

485. (Min. Comunicações/Informática/Análise de Sistemas/2008) A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização. A capacidade é representada por um conjunto de atributos de processo descrito em termos de resultados espera-dos. Uma vez que níveis de maturidade são acumulativos, a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos dos níveis G e F para os processos relacionados no nível F.

486. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) O nível de maturidade C — nível definido — do MPS.BR, além de conter todos os processos dos níveis anteriores, engloba também os processos desenvolvimento para reutilização, gerência de decisões e gerência de riscos.

487. (Min. Comunicações/Informática/Análise de Sistemas/2008) São processos no nível de maturidade E: verificação, validação, projeto e construção do produto. São processos no nível D: gerência de riscos, desenvolvimento para reutilização, análise de decisão e resolução. São processos no nível F: garantia da qualida-de, gerência de configuração, medição. São processos no nível G: gerência de requisitos, gerência de projetos.

488. (Min. Comunicações/Informática/Análise de Sistemas/2008) Um componente do MPS.BR é o modelo de referência, que contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o modelo MPS.BR. Nesse modelo, são definidos níveis de maturidade que es-tabelecem patamares de evolução de processos em sete níveis de maturidade, cuja escala se inicia no nível de menor maturidade A e progride até o de maior maturidade G.


86

ELSEVIER

489. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) O plano de avaliação deve conter o roteiro para realização da análise de conformidade de um processo de criação de software empresarial com o modelo MPS.BR; esse plano prega que nenhum dos processos envolvidos nessa criação deve estar fora do escopo de análise para que se diagnostique o nível de maturidade existente.

4.2.5. MPS.BR – Processos

490. (Sebrae-DF/Analista Técnico/2008) A gerência de requisitos é um item essen-cial no processo de qualidade, pois visa identificar inconsistências entre os requisitos, planos e produtos de trabalho do projeto.

491. (Min. Comunicações/Informática/Análise de Sistemas/2008) O processo de-nominado desenvolvimento para reutilização (DRU) reúne os componentes do produto, gerando um modelo integrado consistente com o projeto e demonstra que os requisitos funcionais são satisfeitos para o ambiente alvo ou equivalen-te. O processo denominado integração do produto (ITP) projeta, desenvolve e implementa soluções para atender aos requisitos.

492. (Min. Comunicações/Informática/Análise de Sistemas/2008) O processo deno-minado verificação (VER) prevê que um produto ou componente atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido. Por sua vez, o processo análise de causas de problemas e resolução (ACP) identifica causas de defeitos e de outros problemas, assim como objetiva agir de modo a prevenir suas ocorrências no futuro.

493. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) No nível G, o planejamento e as estimativas das atividades do projeto são feitos com base no repositório de estimativas e no conjunto de ativos de processo organizacional.

494. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) No nível E, é estabelecida uma rede de especialistas na organi-zação e implementado um mecanismo de apoio à troca de informações entre os especialistas e os projetos.

4.3. Gerenciamento de Serviços

Com o advento do ITIL v3, publicado em 2007 e atualizado em 2011, as questões sobre gerenciamento de serviços vêm se tornando cada vez mais difíceis, cobrando detalhes de conceitos e processos descritos nos livros da nova versão. Dentre os conceitos cobrados, merecem destaque aqueles de estratégia de serviços. Como a maioria refere-se a elementos do planejamento e da gestão de negócios, costumam dar origem a questões mais difíceis para a maioria dos candidatos em concursos da área de TI.


87

4.3.1. ITIL – Conceitos básicos e estrutura do modelo

495. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Serviço é a denominação dada ao meio de se entregar valor aos clientes para facilitar a obtenção dos resultados desejados e minimizar os custos e riscos específicos.

496. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Na atu-alização da versão 3 do ITIL em relação à versão 2, a abordagem passou a ser embasada no ciclo de vida dos serviços e na visão integrada de TI, negócios e fornecedores (gestão de outsourcing).

497. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) A versão 3 do ITIL é composta pelos livros: Service Strategy (Estratégia do Serviço); Service Design (Desenho do Serviço); Service Transition (Transição do Servi-ço); Service Operation (Operação do Serviço) e Continual Service Improvement (Melhoria do Serviço Continuada), além de anexos de segurança da informação e contingência.

498. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) O ITIL trabalha de for-ma segmentada, o que permite que se abranja cada departamento que necessite de serviços de TI e que se descrevam as melhores práticas do gerenciamento de serviços em TI de maneira independente da estrutura da organização.

499. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Por não depender de plataforma tecnológica, a ITIL oferece um conjunto de processos genéricos que podem ser utilizados por empresas tanto públicas como privadas.

500. (MPU/Analista de Informática/Perito/2010) Embora tenha uma grande ênfase na fase de estratégia de serviço, o gerenciamento de risco também está pre-sente na fase de desenho e de transição do ciclo de vida do serviço.

4.3.2. ITIL – Estratégia de serviços

501. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Do escopo da estratégia de serviço constam os processos de gerenciamento financeiro, o de gerenciamento do portfólio de serviços e o de gerenciamento da demanda.

502. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) A gestão financeira realiza a análise, o rastreamento, o monitoramento e a documenta-ção de padrões de atividade do negócio (PAN ou BAP) para prever as demandas atuais e futuras por serviços.

503. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Entre as extensões que a ITIL v.3 traz em relação a sua versão anterior, estão estraté-gias de serviços para modelos de sourcing e de compartilhamento de serviços e abordagens de retorno de investimento para serviços.


88

ELSEVIER

504. (Basa/Técnico Científico/Governança de TI/2010) Uma organização de TI pode ser considerada uma função de negócio ou uma unidade de serviço autônoma cujos processos são ativos operacionais quando criam vantagens competitivas ou propiciam diferenciação no mercado.

505. (Basa/Técnico Científico/Governança de TI/2010) O gerenciamento de serviços pode ser visto como um ativo operacional de uma organização. Um processo é um conjunto de atividades coordenadas que combinam e implementam recursos e capacidades para produzir um resultado que, direta ou indiretamente, cria valor para um cliente interno ou departamental.

506. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Acerca de modelos de provisionamento de serviço de TI definidos pelo ITIL, a decisão por adotar um modelo embasado em utility confere maior escalabilidade às soluções de serviços de TI de uma organização, quando comparado a um modelo de serviços gerenciados. Tal decisão, embora apresente aumento de riscos de segurança no que concerne à confidencialidade, não implica, adicionalmente, o aumento de competências internas para gerenciamento de capacidade de recursos.

507. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) No que diz respeito ao desenvolvimento da estratégia de serviço na organização, é necessário considerar o estilo de gestão organizacional dominante na empresa, o qual pode apresentar os seguintes estágios ou níveis de maturidade: rede, diretivo, delegação, coordenação e colaboração.

4.3.3. ITIL – Desenho de serviços

508. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Estratégia de serviço é a publicação do núcleo da ITIL v.3 que contém orientações acerca do projeto e desenvolvimento dos serviços e dos processos de gerenciamento de serviços. Essa publicação apresenta, em detalhes, aspectos do gerenciamento do catálogo de serviços, do nível de serviço, da capacidade, da disponibilidade e da segurança da informação.

509. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) O processo de gerenciamento da continuidade de serviço de TI do estágio desenho de servi-ço abrange um desdobramento do processo de gerenciamento da continuidade do negócio, com o objetivo de assegurar que os recursos técnicos e os serviços de TI necessários sejam recuperados dentro de um tempo preestabelecido.

510. (Basa/Técnico Científico/Governança de TI/2010) O gerenciamento do catá-logo de serviços produz informações sobre serviços acordados e assegura que estejam disponíveis às pessoas autorizadas a obtê-las. Os indicadores de desempenho chave associados ao catálogo de serviços são o número de pro-


89

dutos produzidos e o de variações detectadas entre as informações contidas no catálogo e observáveis nas instalações dos clientes externos da organização.

511. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) O acordo de nível operacional é firmado com um departamento interno de TI e detalha o provimento de certos elementos de um serviço de TI.

512. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) Disponibilidade refere-se à habilidade de um serviço, componente ou item de configuração em executar a função a ele atribuída quando esta for requerida.

513. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) São métri-cas adotadas no modelo ITIL: mean time between failures (MTBF), mean time between service incidents (MTBSI), mean time to repair (MTTR) e mean time to restore service (MTRS). O MTBSI pode ser definido como a soma do MTBF e do MTRS; e o MTRS é sempre maior ou igual ao MTTR.

514. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) No de-senvolvimento de uma estratégia de continuidade de serviços de TI, o uso de soluções de cold site, em vez de soluções de hot stand by, indica que o tempo máximo tolerável de interrupção dos serviços de TI é superior a 24 horas, o que não seria verdade caso a segunda solução fosse adotada.

4.3.4. ITIL – Transição de serviços

515. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) O desenho do serviço é a fase do ciclo de vida em que o projeto é construído, testado e colocado em produção para que alcance as expectativas dos clientes.

516. (ANEEL/Analista Administrativo/Área 3/2010) Os processos de transição de serviço (gerenciamento de conhecimento, gerenciamento de mudança, ge-renciamento da configuração e ativos de serviços, gerenciamento de liberação e implantação, validação e teste de serviço e avaliação) e a coordenação de recursos que eles requerem são de responsabilidade do processo de planeja-mento e suporte da transição.

517. (Anatel/Analista Administrativo/Ambiente Operacional/2009) A gerência de configurações trata o hardware, o software e a documentação como itens de configuração; difere de gerenciamento de ativos, pois não considera o registro contábil de depreciação e não mantém informações acerca dos relacionamentos entre ativos.

518. (Anatel/Analista Administrativo/Ambiente Operacional/2009) O gerenciamento de mudanças é responsável por autorizar a mudança e avaliar seus impactos, enquanto o gerenciamento de configurações é responsável por identificar as áreas impactadas e manter os registros das mudanças.


90

ELSEVIER

519. (Sebrae-DF/Analista Técnico/2008) A decisão para o desenvolvimento ou compra de um novo software é uma atividade pertinente ao gerenciamento de mudanças.

520. (Anatel/Analista Administrativo/Ambiente Operacional/2009) Uma versão corresponde a um conjunto de mudanças autorizadas para um serviço de tecnologia da informação. Um release do tipo delta, ou total, inclui os itens de configuração que mudaram ou são novos desde a última liberação de versão.

4.3.5. ITIL – Operação de serviços

521. (Basa/Técnico Científico/Governança de TI/2010) A operação de serviços é necessária para, de modo consistente, fornecer a seus usuários e clientes os níveis de serviço de TI acordados, enquanto, ao mesmo tempo, busca otimizar os custos e a utilização de recursos.

522. (IJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) Entre as atividades pertinentes à operação de serviços no modelo ITIL, estão o gerenciamento de eventos dependentes de monitoramento, a gestão dos incidentes que reduzem a qualidade dos serviços de TI, o atendimentos aos pedidos de clientes e usuários, o gerenciamento de acessos embasado na verificação da identidade e na concessão de permissões, bem como o gerenciamento de problemas.

523. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Um ob-jetivo conflitante na operação de serviço considerando TI e negócio é que a visão técnica é necessária para a gestão dos componentes dos serviços, mas não se pode sobrepor aos requisitos de qualidade dos usuários para esses serviços.

524. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) O Service Desk é um processo que fornece um ponto único de contato para os usuários de TI solici-tarem serviços.

525. (Basa/Técnico Científico/Governança de TI/2010) Uma métrica adequada para avaliar o desempenho da central de serviços (service desk) é o volume de chamadas recebidas, uma vez que um incremento nesse indicador significa maior confiança dos usuários nesse tipo de serviço e, portanto, bom desem-penho.

526. (TJ-ES/Analista Judiciário 02/Análise de Banco de Dados/2011) Um dos princi-pais objetivos da gerência de incidentes é restaurar o serviço do usuário, a fim de minimizar os impactos na operação do negócio dentro dos níveis de service level agreement (SLA) estabelecidos. Para isso, a central de serviços deve inserir no sistema as requests for change (RFC) assim que o usuário reportar o problema identificado.


91

527. (TJ-ES/Analista Judiciário 02/Análise de Banco de Dados/2011) No gerencia-mento de problemas, busca-se a causa raiz dos incidentes reportados pelos usuários e registrados na central de serviços (service desk) para que seja possível determinar a mudança adequada à infraestrutura de TI.

528. (Anatel/Analista Administrativo/Ambiente Operacional/2009) Um problema pode resultar em múltiplos incidentes, e requer uma análise de impacto, uma vez que pode levar à degradação dos acordos de níveis de serviço. É possível que um problema não seja diagnosticado até que vários incidentes tenham ocorrido.

529. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Se, em uma base de dados de erros conhecidos de uma organização que possui alto nível de maturidade no modelo ITIL, existe um número x de registros de erros, então é de se esperar que exista uma quantidade: de registros de problemas aproximada-mente igual a x; kx de registros de incidentes, em que k é um número superior a 1; lx de pacotes de release, em que l é um número superior a 1.

530. (Basa/Técnico Científico/Governança de TI/2010) No gerenciamento das opera-ções, os planos se tornam ações, e o foco está nas atividades diárias e de curto prazo, embora tais atividades sejam realizadas e repetidas em um período de tempo relativamente grande. As atividades são realizadas geralmente por técnicos especializados que recebem treinamento para desempenhar cada uma delas.

531. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Monito-ração e controle, gerenciamento do mainframe, gerenciamento de redes e armazenamento de dados são atividades técnicas altamente especializadas do estágio operação de serviço.

4.3.6. ITIL – Melhoria contínua de serviços

532. (Previc/Analista Administrativo/Tecnologia da Informação/2011) A publicação do ITIL intitulada Operação de Serviço orienta, por meio de princípios, práticas e métodos de gerenciamento da qualidade, a respeito de como fazer sistemati-camente melhorias incrementais e de larga escala na qualidade dos serviços.

533. (MPU/Analista de Informática/Perito/2010) A maturidade dos serviços de TI deve ser avaliada pela fase de melhoria continuada com base em conceitos alinhados com o modelo de maturidade genérico do Cobit.

534. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis-temas/2010) O livro Melhoria Contínua de Serviços, incluído na versão 3 do ITIL, apresenta uma visão de ciclo de vida embasado no modelo PDCA (plan, do, check, act).


92

ELSEVIER

4.4. Governança de TI

Em geral, as questões sobre o modelo Cobit concentram-se mais sobre os fundamentos conceituais e sobre a estrutura do modelo, restando uma parcela menor para questões sobre os domínios e processos. Vale notar que a publicação do Cobit 5, em maio de 2012, trouxe mudanças estruturais profundas em relação às versões anteriores. Assim, torna-se necessário acompanhar com atenção os novos editais e provas da área de TI para identificar quando essa nova versão começará a ser cobrada em concursos.

4.4.1. Cobit – Conceitos básicos

535. (Basa/Técnico Científico/Governança de TI/2010) Governança em TI é respon-sabilidade dos executivos e diretores da organização. Consiste na liderança, nas estruturas organizacionais e nos processos que garantam que a TI sustente e estenda as estratégias e os objetivos da organização.

536. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) A governança de TI preocupa-se com processos de análise de riscos e de tomada de decisão, permitindo a criação de processos estruturados para gerenciar e controlar iniciativas de TI nas empresas.

537. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) No modelo Cobit, o conceito de agregação de valor diz respeito à proposição de valor no tempo e garante que a TI entregue os benefícios prometidos com a otimização de custos.

538. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) No Cobit, a mensuração de desempenho é essencial para a governança de TI.

539. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Objetivos de controle do Cobit são os requisitos mínimos para o controle efetivo de cada processo de TI, de modo que cada processo de TI do Cobit tem um objetivo de controle de alto nível e uma série de objetivos de controle detalhados, além dos quais existem no Cobit, para cada processo, requisitos genéricos (ou gerais) de controle.

540. (Basa/Técnico Científico/Governança de TI/2010) Diretriz é o conjunto de políticas, procedimentos, práticas e estruturas organizacionais planejadas para prover uma garantia razoável de que os objetivos de negócio serão alcançados e que eventos indesejáveis serão evitados ou detectados e cor-rigidos.

541. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) A disponibilidade refere-se à entrega da informação por meio do melhor ou mais produtivo e econômico uso dos recursos.


93

542. (MPU/Analista de Informática – Perito/2010) Um dos recursos de TI é a infra-estrutura, em que estão incluídos os sistemas automatizados para usuários que processam as informações.

543. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) O Cobit é definido como um modelo, em vez de uma ferramenta de suporte, visto que, a partir dessa visão, os gerentes podem suprir deficiências referentes a requisitos de controle, questões técnicas e riscos de negócios.

544. (Previc/Analista Administrativo/Tecnologia da Informação/2011) A implantação do Cobit como modelo de governança de TI de uma empresa ou organização propicia, como um dos seus benefícios, o cumprimento dos requisitos do COSO (Committee of Sponsoring Organizations of the Treadway Commission) para controle de ambientes de TI.

545. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Cobit é o único framework gerencial que trata todo o ciclo de vida de TI. O modelo apoia a TI para a organização atingir os objetivos de negócio, garantir o alinhamento estratégico e melhorar a eficiência e eficácia de TI.

4.4.2. Cobit – Características gerais

546. (Basa/Técnico Científico/Governança de TI/2010) A orientação a negócios do Cobit compreende o alinhamento entre objetivos organizacionais e os objetivos de TI. Para tanto, a gerência procura identificar as atividades mais importan-tes a serem executadas, medir o progresso obtido em relação aos objetivos a serem atingidos e determinar se os processos de TI estão sendo executados adequadamente.

547. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) Entre outras con-tribuições para as atividades de TI, o Cobit estabelece relacionamentos com os requisitos do negócio e organiza as atividades de TI em um modelo de processos genéricos, com foco mais acentuado no controle que na execução dos processos.

548. (TJ-ES/Analista Judiciário 02/Análise de Banco de Dados/2011) O Cobit pro-picia um modelo de gestão embasado em objetivos de controle, enquanto os indicadores-chaves de meta (ou KGI) estão estritamente relacionados às me-dições que auxiliam a gerência a determinar quando um processo de TI está atingindo os requisitos do produto.

549. (Basa/Técnico Científico/Governança de TI/2010) Os controles embutidos nas aplicações dos processos são responsabilidade conjunta entre o negócio e a área de TI. A área de aplicação relativa à autenticação de transação e integri-dade estabelece procedimentos e responsabilidades que garantem que a saída


94

ELSEVIER

de cada processo seja tratada de maneira autorizada, entregue ao recipiente adequado e protegida durante a transmissão. Além disso, asseguram que a exatidão da saída seja verificada, detectada e corrigida.

550. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) Alguns requisitos de controle genéricos são aplicáveis a todos os processos do Cobit, tais como a definição e a divulgação de políticas, os procedimentos e planos relativos ao processo, e o desempenho do processo medido em relação às respectivas metas.

551. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) O Cobit, ferramenta de gestão orientada a negócios, apresenta indi-cadores de objetivo que definem a forma do progresso das ações necessárias para atingir os objetivos estratégicos da organização, que podem ser expressos sob a forma de disponibilidade de informação para dar apoio ao negócio; riscos da falta de informação e confiabilidade das informações; eficiência de custos, entre outras.

552. (Basa/Técnico Científico/Governança de TI/2010) Para medir o desempenho, o Cobit 4 define três níveis de métricas e metas, quais sejam, metas e métricas de TI, de processo e de atividade, bem como os meios de medi-las. As primei-ras definem o que o negócio espera de TI, as segundas, o que um processo de TI deve entregar para suportar os seus objetivos, e as terceiras estabelecem o que é necessário acontecer dentro do processo para atingir o desempenho desejado.

553. (Sebrae-DF/Analista Técnico/2008) O KGIs (key goal indicators) indicam se os objetivos foram alcançados. Pela sua natureza a posteriori, também são chamados de lag indicators.

554. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) O pla-nejamento estratégico, um processo regularmente executado no âmbito organizacional, define a maneira pela qual a estratégia de uma organização é desenvolvida e prescreve o emprego da TI para executar o plano de ações, a fim de cumprir as metas estratégicas estabelecidas. O alinhamento entre as metas de negócio (organizacionais) e os resultados da TI pode ser calculado, segundo o modelo Cobit, por meio do mapeamento direto dos indicadores de desempenho da TI para os indicadores de meta do negócio.

555. (STF/Analista Judiciário/Análise de Sistemas de Informação/2008) Segundo o modelo apresentado na figura a seguir, o desempenho da TI será direcio-nado pelo desempenho dos processos da TI e, dessa forma, a definição das metas de processos da TI deverá ser efetuada após a definição das metas da TI.


95

4.4.3. Cobit – Modelo de maturidade

556. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Os níveis de maturidade descrevem perfis de processos de TI que possam ser reconheci-dos pelas organizações. Esses níveis estabelecem patamares evolutivos, como no CMM/CMMI e em outros modelos similares.

557. (MPU/Analista de Informática/Perito/2010) Diferentemente da representação por estágios do modelo CMMI, no Cobit é possível avançar do nível de maturi-dade 3 para o nível de maturidade 4 sem ter cumprido todas as condições do nível 3.

558. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) O modelo de maturidade é utilizado para avaliar os níveis de maturidade da aplicação do conjunto de melhores práticas de governança, os quais variam entre 1 e 5. O nível 3 preconiza que é possível monitorar e medir a conformidade de procedi-mentos que são necessários para a implementação de ações, se os processos não estiverem funcionando de forma eficaz.

559. (TJ-ES/Analista Judiciário 02/Análise de Banco de Dados/2011) Caso um gestor eleve o nível de maturidade de seus processos de 2 para 3, ele estará realizan-do uma ação em que os processos, por seguirem um padrão de regularidade, precisam atingir um nível em que sejam monitorados e medidos.


96

ELSEVIER

560. (STJ/Analista Judiciário/Informática/2008) Considere que, no que diz respeito ao processo avaliar e gerenciar riscos de TI (assess and manage IT risks), uma organização apresente as seguintes características: existe uma abordagem para avaliar riscos; para cada projeto, implementar a avaliação de riscos de-pende de decisão do gerente do projeto; a gerência de riscos é aplicada apenas aos principais projetos ou em resposta a problemas. Nessa situação, o nível de maturidade da referida organização, em relação a tal processo, é gerenciado e mensurável (managed and measurable).

561. (Sebrae-DF/Analista Técnico/2008) Os modelos de maturidade no Cobit 4.1 são utilizados para controlar os processos de TI, fornecendo um método para quantificar o nível de maturidade dos processos.Tais modelos permitem mape-ar o estágio de cada um dos processos de uma organização e compará-la com o que o mercado espera dela ao considerar o estágio atual da organização, o estágio corrente da indústria, o status dos padrões internacionais e os objetivos da organização.

562. (Sebrae-DF/Analista Técnico/2008) Os níveis de maturidade podem ser defini-dos em função de seis variáveis que identificam as características dos proces-sos da função de sistemas informativos, dentro de um contexto empresarial específico. Entre essas variáveis, é correto citar as ferramentas de suporte e as competências.

563. (Basa/Técnico Científico/Governança de TI/2010) A implementação de um ambiente de controle adequado ocorre quando se considera que os aspectos capability, cobertura e controle foram atingidos. Melhorar a maturidade or-ganizacional reduz riscos e incrementa a eficiência, levando a menos erros, a processos mais previsíveis e com boa relação custo-eficiência dos recursos.

4.4.4. Cobit – Domínios e processos

564. (IJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) O Cobit tem por objetivo controlar detalhadamente os processos organizados em domínios ou áreas com atuação alternada ao longo do tempo.

565. (TJ-ES/Analista Judiciário 02/Análise de Banco de Dados/2011) O domínio denominado planejamento e organização (PO) compreende os processos res-ponsáveis pela avaliação dos riscos, pelo asseguramento da continuidade dos serviços e pelo gerenciamento das mudanças.

566. (TRE-BA/Analista Judiciário/Análise de Sistemas/2010) No domínio de plane-jamento e organização do Cobit, são desenvolvidos e mantidos procedimentos da infraestrutura tecnológica, além de definido o plano estratégico de TI.


97

567. (ANEEL/Analista Administrativo/Área 3/2010) O domínio aquisição e implemen-tação envolve a identificação, desenvolvimento e(ou) aquisição de soluções de TI para executar a estratégia de TI estabelecida, assim como a sua implementação e integração junto aos processos de negócio. Mudanças e manutenções em sistemas existentes também estão cobertas por esse domínio, para garantir a continuidade dos respectivos ciclos de vida.

568. (MPU/Analista de Informática/Perito/2010) A contemplação dos aspectos de confidencialidade, integridade e disponibilidade para garantir a segurança da informação cabe ao domínio Entregar e Suportar.

569. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Siste-mas/2010) O Cobit 4.1 está organizado em 34 processos agrupados em quatro domínios, que atuam dentro de recursos de TI classificados em pessoas, apli-cações, tecnologia, infraestrutura e dados. No domínio de entrega e suporte (delivery and support), identificam-se os seguintes processos específicos: gerenciamento de problemas e incidentes; gerenciamento de dados; garantia de segurança dos sistemas; educação e treinamento de usuários; e gerencia-mento de infraestrutura predial.

570. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Consti-tuem métricas que apoiam diretamente o alcance do objetivo de controle sobre processos de TI: o percentual de papéis da organização de TI com posição e responsabilidades documentadas; e a quantidade de unidades organizacionais não apoiadas pela organização de TI, mas que deveriam sê-lo, conforme apre-senta a estratégia organizacional. Tal objetivo de controle pertence ao domínio de planejamento e organização.

571. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) A medi-ção do turnover do pessoal de TI, bem como a percentagem de pessoas de TI certificadas conforme as necessidades do negócio, constituem métricas que apoiam diretamente o alcance de objetivos de controle sobre processos de TI pertencentes ao domínio de aquisição e entrega.

572. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) O processo DS5 garante a segurança dos sistemas, que pertence ao domínio de entrega e suporte, visa criar e manter regras de segurança de TI, incluindo políticas, normas e pro-cedimentos. Pode ser avaliado pelo número de processos críticos de negócios não cobertos por um plano de disponibilidade.

573. (IJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) Os objetivos de controle de comunicação dos alvos e direcionamento da gestão, demandados no domínio de planejamento e organização do Cobit 4.1, podem ser alcançados diretamente por processos típicos da área de gerenciamento de comunicações existente no PMBOK.


98

ELSEVIER

574. (IJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) Conforme o diagrama RACI do modelo Cobit, o estabelecimento de ligações entre as metas de negócio e as metas da TI é efe-tuado sob responsabilidade não exclusiva do dirigente máximo da organização de TI.

575. (MEC/Atividade Técnica de Complexidade Gerencial/Analista de Sistema Ope-racional/2011) Um dos objetivos do processo de gerenciamento de serviços terceirizados é garantir a satisfação entre os fornecedores e os usuários que utilizam o serviço fornecido. Cabe, ainda, a esse processo monitorar e gerir riscos, isto é, identificar e minimizar riscos relacionados à capacidade de os fornecedores continuarem a prestação do serviço.

576. (MEC/Atividade Técnica de Complexidade Gerencial/Analista de Sistema Opera-cional/2011) A garantia de segurança dos sistemas objetiva proteger os ativos de TI, abrangendo a necessidade de prevenção contra códigos maliciosos, mas não a gestão de contas de usuários.

4.5. Planejamento e Gestão Estratégica de TI

577. (Detran-ES/Técnico Superior/Analista de Sistemas/2010) Em um estudo de planejamento estratégico, as metas, os objetivos, os negócios e a missão or-ganizacional devem ser definidos, sequencialmente, nessa ordem.

578. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) A missão corresponde aos limites que os principais responsáveis pela organização conseguem vislumbrar dentro de um período de tempo mais longo e uma abordagem mais ampla.

579. (Aneel/Analista Administrativo/Área 3/2010) A TI tanto pode ser direcionada a partir da estratégia de negócio quanto ser o ponto de partida para a formula-ção de uma estratégia corporativa. Assim, a percepção de uma oportunidade de uso estratégico de TI para alavancar negócios permite que a organização desenvolva uma estratégia corporativa embasada na tecnologia.

580. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) A estra-tégia de TI pode ser definida como um padrão no fluxo de ações e decisões da organização, desenvolvido pelos tomadores de decisão, cujo objetivo é identificar as oportunidades nas quais os sistemas de informação existentes podem apoiar os negócios da empresa, conduzindo às mudanças e à inovação organizacional.

581. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) Ao distinguir a estratégia deliberada da estratégia emergente, é correto afirmar que a estratégia deliberada é a que focaliza o aprendizado.


99

582. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) O plane-jamento estratégico é uma metodologia gerencial que permite estabelecer a direção a ser seguida pela organização, visando maior grau de interação com o ambiente; já gestão estratégica é o processo contínuo e interativo que visa manter essa interação.

583. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) Um dos benefícios da adoção da gestão estra-tégica é que ela facilita a identificação e a exploração de futuras oportunidades de mercado.

584. (Aneel/Analista Administrativo Área 3/2010) Na gestão estratégica, estabe-lecer políticas consiste em decidir a qual negócio (ou negócios) uma empresa deve se dedicar, além de selecionar os assuntos fundamentais que guiarão e caracterizarão o negócio de forma duradoura.

585. (Detran-ES/Técnico Superior/Analista de Sistemas/2010) Benchmarking e SWOT são dois métodos distintos usados no planejamento de sistemas de informação. O primeiro é utilizado em estudos de natureza comparativa e o segundo, em análises do ponto de vista de competitividade e segurança.

586. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) Na matriz SWOT, as ameaças são caracte-rísticas que impedem que a empresa ou unidade de negócio tenha um bom desempenho e, portanto, precisam ser tratadas/minimizadas.

587. (MPU/Analista de Informática/Desenvolvimento de Sistemas/2010) As ferra-mentas GUT (gravidade, urgência e tendência), o Diagrama de Pareto e a Curva de Tendência fornecem suporte à atividade do planejamento estratégico de filtrar informações de interesse da organização.

588. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Entre as principais metodologias para planejamento de TI incluem-se o BSP (Business Systems Planning), o SSP (Strategic Systems Planning), a engenharia da in-formação, os fatores críticos de sucesso, o modelo eclético de Sullivan e os estágios de crescimento da organização.

589. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) No pro-cesso de aumento de maturidade da TI em grandes empresas heterogêneas ou geograficamente dispersas, o estabelecimento de sistemas de informação federados, de forma geral, ocorre apenas após a adoção de modelos ad ho-cráticos. Isso é especialmente verdadeiro se consideradas as oportunidades da microcomputação presentes nos anos 1980 e 1990 do século passado, as quais deram aos departamentos e unidades isoladas de grandes empresas a capacidade de organizarem suas soluções de TI individuais em desconformi-


100

ELSEVIER

dade com os padrões estabelecidos pelo órgão central de TI, supondo-se que o mesmo era anteriormente presente.

590. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó-cios e Tecnologia da Informação/2009) Entre as forças competitivas propostas por Michael Porter destacam-se a liderança no custo, a diferenciação e o enfoque.

591. (Inmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) Na estrutura da cadeia de valor, as atividades desempenhadas por uma empresa são divididas em atividades de suporte e atividades de apoio.


101

C a p í t u l o 5

Questões de Segurança da Informação

Segurança da informação é uma disciplina que vem ganhando destaque cres-cente nas provas de concurso público e isso talvez se deva, em grande medida, à própria relevância do tema, seja no cotidiano das organizações, seja no dia a dia das pessoas.

A despeito de, num primeiro momento, a matéria parecer mais relacionada a suporte ou a infraestrutura, os editais de concursos para cargos de desenvolvi-mento ou de gestão de TI costumeiramente também trazem a disciplina segurança da informação dentre os assuntos passíveis de cobrança.

Uma postura adotada por diversas organizadoras é uma evidente predileção pelo tópico Criptografia, comportamento repetido pelo Cespe e que pode ser evi-denciado pela maior quantidade de questões desse assunto cobradas em prova. A despeito disso, desde 2007 evidencia-se um crescente interesse desta banca pelas questões que envolvem normas.

5.1. Conceitos básicos de Segurança da Informação

Qualquer discussão que envolva segurança da informação invariavelmente exige um conhecimento prévio sobre ataques, serviços e mecanismos de seguran-ça. O Cespe costuma cobrá-los principalmente das seguintes formas: exigindo o conhecimento das definições corretas destes conceitos ou o relacionamento dos mecanismos de segurança com os serviços que eles propiciam. As questões a seguir ilustram alguns desses casos.

592. (PF–Regional/Perito Criminal Federal/Área 3/2004) Segurança da informação é caracterizada, basicamente, pelo fornecimento de três serviços de segurança: a preservação do sigilo ou da confidencialidade das informações, a garantia da integridade dos dados e a manutenção da disponibilidade.

593. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Disponibilida-de é a garantia de que a informação é acessível ou revelada somente a pessoas, entidades ou processos autorizados a acessá-la.

594. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) A confidencialidade tem o objetivo de garantir que apenas pessoas autorizadas tenham acesso à informação. Essa garantia deve ser obtida em todos os níveis, desde a geração da informação, passando pelos meios de transmissão, até chegar ao seu destino e ser devidamente armazenada ou, se necessário, destruída sem possibilidade de recuperação.

595. (EMBASA/Analista de Saneamento/Analista de TI/Desenvolvimento/2010) O princípio da autenticação em segurança diz que um usuário ou processo deve ser corretamente identificado. Além disso, todo processo ou usuário autêntico está automaticamente autorizado para uso dos sistemas.

O Banco ABC disponibiliza seus serviços exclusivamente por meio da Internet, 24 horas por dia, e está sujeito a ataques aos seus sistemas, que podem ser realizados por meio da própria Internet. Como qualquer empresa do sistema financeiro, o banco está sujeito a leis que garantem o sigilo bancário de seus clientes. Além disso, precisa garantir que os dados das transações financeiras realizadas pelos seus clientes cheguem aos seus sistemas sem alterações. Acerca desse cenário hipotético, julgue os próximos dois itens.

596. (INMETRO/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da Informação/2009) O uso de senhas para efetuar a autenticação dos clientes do banco pode ser um mecanismo para garantir a confidencialidade necessária às transações financeiras do banco.

597. (INMETRO/Analista Executivo em Metrologia e Qualidade/Processos de Negó-cios e Tecnologia da Informação/2009) Entre as necessidades de segurança do Banco ABC, a integridade e a confidencialidade são as que podem ser compro-metidas pelos ataques efetuados por meio da Internet.

598. (MCT-CTI/Tecnologista Pleno 1/Padrão I/Segurança de Sistemas de Informa-ção/2008) A análise de tráfego não autorizada em uma rede é considerada um ataque passivo, pois o conteúdo dos pacotes não é alterado, embora possa ser coletada uma considerável quantidade de informação do fluxo de mensagens entre os entes que se comunicam.

5.2. Criptografia – Conceitos, algoritmos e protocolos

599. (PRODEPA/Analista de Suporte/2004) A criptologia é uma área do conhecimento humano que pode ser dividida em criptografia, que trata da defesa dos sistemas de informação, e esteganografia, que se preocupa na identificação de técnicas para o ataque a sistemas de informação.


104

ELSEVIER

600. (EMBASA/Analista de Saneamento/Analista de Tecnologia da Informação/Atuação em Rede/2010) Na criptografia simétrica, a mesma chave é utilizada tanto para a cifração quanto para a decifração.

601. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) A distribuição de chaves é mais simples e segura na utilização de um sistema criptográfico simétrico ou de chave secreta que na utilização de um sistema criptográfico assimétrico ou de chave pública.

602. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) Sistemas cripto-gráficos assimétricos ou de chave pública oferecem melhor desempenho na cifração e decifração de mensagens que sistemas criptográficos simétricos.

603. (STM/Analista Judiciário/Análise de Sistemas/2011) Os sistemas assimétricos usam duas chaves com funções complementares: se uma é usada para cifração, a outra é usada na decifração; além disso, uma delas deve ser mantida secreta, enquanto a outra pode ser pública.

604. (EMBASA/Analista de Saneamento/Analista de Tecnologia da Informação/Atu-ação em Rede/2010) A criptografia, seja simétrica ou assimétrica, proporciona confidencialidade, integridade, autenticidade e irretratabilidade.

605. (TCU/Analista de Controle Externo/Tecnologia da Informação/2007) Atualmen-te, os sistemas criptográficos utilizados são incondicionalmente seguros por se basear na dificuldade de resolução de problemas matemáticos específicos ou em limitações na tecnologia computacional vigente.

606. (MPU/Analista de Informática/Banco de Dados/2010) Abordagens básicas de criptografia de dados incluem a substituição e a permutação. A substituição ocorre na situação em que, para cada caractere de um texto simples, verifica-se a substituição desse caractere por um outro texto cifrado. A permutação ocorre quando caracteres de texto simples são reformulados em alguma sequência diferente da original.

607. (MCT/Tecnologista Pleno/Segurança de Sistemas de Informação/2008) Shan-non identificou duas propriedades essenciais em um algoritmo criptográfico: a confusão, em que a relação entre o Plaintext e o Ciphertext se torna o mais complexa possível; e a difusão, em que se removem do Ciphertext as proprie-dades estatísticas do Plaintext.

608. (PF-Nacional/Perito Criminal Federal/Área 3/2004) O algoritmo criptográfico DES é uma cifra de substituição que mapeia um bloco de texto claro de 64 bits em um outro bloco de criptograma de 64 bits.

609. (PF-Regional/Perito Criminal Federal/Área 3/2004) O algoritmo DES (Data Encryption Standard) efetua exatamente as mesmas operações durante o pro-cesso de cifração e o de decifração. A única diferença percebida entre os dois processos está na ordem de aplicação das chaves parciais (chaves de round).

Capítulo 5 I Questões de Segurança da Informação

105

610. (ABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) O esquema de criptografia data encryption standard (DES) duplo é vulnerável a ataque do tipo meet-in-the-middle (encontro no meio).

Na rede de computadores de uma organização pública brasileira com diversos ativos, como, por exemplo, switches, roteadores, firewalls, estações de traba-lho, hosts servidores de aplicação web, servidores de bancos de dados, é comum a ocorrência de ataques e de outros incidentes que comprometem a segurança de seus sistemas. Nessa organização, a definição de políticas e metodologias adequadas para lidar com esse tipo de problema cabe ao departamento de TI. Acerca deste cenário, julgue as próximas três questões.

611. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Se, na rede de computadores da organização citada, para garantir maior confidencialidade na troca de dados entre duas de suas máquinas, seus administradores empre-garem a técnica conhecida como cifra de transposição para cifrar determinado conjunto de mensagens, então, nessas duas máquinas, devem ser utilizadas chaves simétricas.

612. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Caso a rede de computadores dessa organização utilize o algoritmo DES (Data Encryp-tion Standard) e os administradores dessa rede decidam empregar a técnica conhecida como whitening, com o objetivo de reduzir as vulnerabilidades de um dos sistemas criptográficos empregados na rede, haverá um acréscimo de bits à chave criptográfica original, reduzindo as chances de sucesso de uma eventual criptoanálise desse sistema.

613. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Se, para a troca de mensagens seguras na rede de computadores da organização citada, seus vários dispositivos móveis empregarem sistemas baseados no algoritmo criptográfico 3DES (DES triplo) e os vários dispositivos não-móveis utilizarem sistemas baseados no algoritmo simples DES, a superação da diferença entre os algoritmos criptográficos empregados pelos sistemas de troca de mensagens seguras usados por dispositivos móveis e não-móveis dessa rede pode ser feita pelo administrador por meio da definição K1 = K2 = K3 = K, em que K1, K2 e K3 são as três chaves usadas no 3DES e K é a chave usada no simples DES e com-partilhada entre dois dispositivos quaisquer das duas categorias mencionadas.

614. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) O padrão AES define uma cifra na qual os comprimentos do bloco e da chave podem ser especificados independentemente para 128 bits, 192 bits ou 256 bits. Os três tamanhos de chave determinam vários parâmetros da cifra, como número de rodadas, e podem ser usados limitando o bloco a 128 bits.


106

ELSEVIER

615. (PF-Nacional/Perito Criminal Federal/Área 3/2004) O DES e o seu sucessor como padrão de criptografia do governo norte-americano, o AES, são cifrado-res de bloco que obedecem o esquema geral de cifradores de Feistel. Nesses cifradores, os blocos cifrados são divididos em metades (lado esquerdo e lado direito) de mesmo tamanho, que são processadas independentemente, a cada rodada de cifração. Esse processo faz que apenas metade dos bits do bloco cifrado sofra influência da chave, em cada rodada, introduzindo confusão no processo criptográfico.

616. (PF-Regional/Perito Criminal Federal Área 3/2004) Para a utilização do modo de operação CBC (Cipher Block Chaning Mode), é necessário que seja criado o que se denomina vetor de inicialização (initialization vector), que evita que mensagens que comecem idênticas gerem criptogramas com começos idên-ticos. Um inconveniente desse modo de operação reside na questão da pro-pagação de erros, pois, caso haja um bit errado em um bloco de criptograma a ser decifrado, todos os blocos a partir dali serão decriptografados de forma errada.

617. (INMETRO/Analista Executivo em Metrologia e Qualidade/Redes/2009) O modo ECB é mais seguro que o CBC, mas é menos eficiente que o CTR.

618. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Enquanto uma cifra de bloco atua em um bit ou byte do fluxo de dados por vez, uma cifra de fluxo atua sobre um conjunto de caracteres de texto em claro, que são tratados como um todo e usados para produzir um criptograma de igual comprimento.

619. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Conside-re a seguinte situação hipotética. Um analista foi incumbido de construir um sistema de comunicações seguro baseado em uma combinação de cifragem simétrica e esteganografia no qual as mensagens trocadas entre o emissor (E) e o destinatário (D) sejam sempre de pequeno tamanho e que apenas uma pequena quantidade de mensagens seja eventualmente trocada durante todo o ciclo de vida do sistema. De acordo com os critérios de segurança do sistema, deverá ser provida absoluta confidencialidade do teor das mensagens, em detrimento de integridade e disponibilidade. Para tal tarefa, o implementador dispõe de um gerador de números aleatórios de elevadíssima qualidade, mas precisa fazer uma implementação de grande simplicidade. Esses critérios e o desenho do sistema de cifragem não são conhecidos pelo oponente (O). Nessa situação, é mais adequado que o implementador do sistema adote um modelo com base na técnica de one-time pad, que utiliza uma cifra de fluxo, em vez de um modelo baseado no algoritmo DES (data encription standard), que utiliza cifra de bloco.


107

620. (BASA/Técnico Científico/2006) Um dos mais utilizados algoritmos de cripto-grafia é o RSA, que se baseia na dificuldade de fatoração de números primos grandes e utiliza, por ser um algoritmo de ciframento assimétrico, um par de chaves (pública e privada) para cada usuário.

621. (ABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Em crip-tossistemas de chave pública, o algoritmo de Rivest, Shamir e Adleman (RSA) é adequado para a implementação de criptografia/decriptografia, assinatura digital e troca de chave.

622. (PF-Nacional/Perito Criminal Federal/Área 3/2004) Cada uma das chaves pú-blica e privada de um criptossistema RSA é formada por dois números inteiros denominados expoente e módulo, ambos devendo ser números primos.

623. (STJ/Analista Judiciário/Informática/2008) O sistema RSA é seguro contra ataques adaptativos de texto cifrado escolhido.

624. (STJ/Analista Judiciário/Informática/2008) O esquema OAEP apresenta se-gurança demonstrável no caso em que utiliza o RSA, devido às propriedades deste último.

625. (MPU/Analista de Informática/Suporte Técnico/2010) Em sistemas criptográfi-cos de chave pública, curva elíptica consiste na implementação de algoritmos de chave pública já existentes que proveem sistemas criptográficos com chaves de maior tamanho que os algoritmos de chaves simétricas.

626. (SERPRO/Analista/Redes/2008) O criptossistema Diffie-Hellman define uma forma segura de troca de chaves.

627. (MPU/Analista de Informática/Suporte Técnico/2010) Em processos de auten-ticação de mensagens, um digest MDC (modification detection code) utiliza uma função hash sem chaves. Se for assinado, o digest permite verificar a integridade de mensagem, além de sua autenticação, e não repúdio.

628. (PF/Perito Criminal Federal/Área 3/2002) Um princípio básico para a utilização de senhas em serviços de segurança, tais como autentificação e controle de acesso, consiste em não armazenar a senha diretamente, pois o acesso a tal entidade de armazenamento poria em risco toda a segurança do sistema. Ao contrário, é armazenado um resumo da senha, gerado normalmente por algum tipo de função digestora unidirecional. Ataques de força bruta a esses sistemas podem ser bem-sucedidos, caso se encontre a mensagem original utilizada na entrada da função (isto é, a senha) ou alguma outra mensagem que resulte em um mesmo resumo que aquele gerado para a mensagem original.

629. (ANATEL/Analista Administrativo/Tecnologia da Informação/Redes e Seguran-ça/2009) MD2, MD4 e MD5 são uma família de funções hash do tipo one-way. O MD2 produz uma chave de 64 bits que é considerada menos segura que as do MD4 e do MD5. O MD4 produz uma chave de 128 bits e usa operandos de 32 bits para uma rápida implementação.


108

ELSEVIER

630. (TRE-PR/Analista Judiciário/Análise de Sistemas/2009) Criptoanálise diferen-cial e linear são tipos de ataques, porém, não podem ser utilizados no DES com 16 etapas.

631. (MCT/Tecnologista Jr/2008) No campo da criptografia, a criptoanálise diferen-cial analisa a evolução da diferença — operação de E de três n-gramas — entre duas mensagens conhecidas e cifradas com a mesma chave durante o processo de criptografia. A criptoanálise linear é uma técnica que se vale de convoluções lineares equivalentes ao algoritmo criptográfico.

Stallings. Criptografia e segurança de redes, Pearson, 2006.

A figura acima apresenta um modelo para segurança de rede, no qual se desta-cam vários elementos, individualmente nomeados. Esse modelo apresenta um conjunto de elementos que compõem soluções para o provimento de um canal de informação seguro entre o emissor (E) e o (D) destinatário, envolvendo um terceiro confiável (TC). Julgue o item, acerca das informações apresentadas e dos conceitos de ataques e dispositivos de segurança de redes de computadores e criptografia.

632. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Quando do uso de criptografia simétrica, as transformações relacionadas à segurança, realizadas nos lados do emissor (E) e do destinatário (D), devem ser efetuadas com o uso de uma informação secreta denominada chave. Essa chave pode ser permanente ou transitória, conforme o desenho dos algoritmos e protocolos de criptografia em-pregados. No caso do protocolo https, por exemplo, empregam-se, entre outros aspectos, dois tipos de chaves: chaves criptográficas simétricas e transitórias, bem como chaves assimétricas permanentes. Adicionalmente, chaves de ambos os tipos podem ser geradas no lado do emissor (E) ou do destinatário (D) da mensagem, bem como são trocadas com o outro lado por meio de um canal de confiança estabelecido com um terceiro confiável (TC), que é comum ao emissor e ao destinatário.


109

633. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Conside-rando que o modelo mostrado na figura seja empregado na arquitetura de um serviço de controle de acesso baseado no Kerberos, em que existe um domínio de rede que contém um servidor Kerberos, vários servidores de recursos — destinatários (D) — e vários clientes de recursos — emissores (E), é correto afirmar que: o servidor Kerberos precisa conhecer senhas de autenticação dos clientes; o servidor Kerberos precisa compartilhar chaves criptográficas simétricas com cada servidor de recursos (D); para obter bilhetes de acesso a cada servidor de recursos (D) individual do domínio de rede, o cliente de recursos (E) precisa dialogar com o servidor Kerberos.

5.3. Assinatura digital, certificação digital e PKI

634. (STM/Analista Judiciário/Análise de Sistemas/2011) Uma assinatura digital confere autenticidade, integridade e sigilo a uma mensagem.

635. (TJ-ES/Analista Judiciário/Análise de Banco de Dados/2011) A adição de uma assinatura digital a uma mensagem pode ser efetuada pelo seu transmissor, por meio da adição, à mensagem cifrada, de um hash (da mensagem original em claro) cifrado com sua chave privada.

636. (SEGER-ES/Especialista em Políticas Públicas e Gestão Governamental/Ciência da Computação, Engenharia da Computação e Sistemas de Informação/2011) Os portais corporativos permitem que se disponham diversas aplicações para acesso, uso e compartilhamento de informações em ambientes empresariais, que podem ser feitos por meio de autenticação do tipo single sign on, em que uma única identidade se replica para diversas aplicações.

637. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) Para conferir a autenticidade de um certificado digital, é necessário utilizar o cer-tificado digital da autoridade certificadora que o emitiu. Esse certificado pode ser emitido por outra autoridade certificadora ou pode ser autoassinado.

638. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/2011) Para as-sinar digitalmente um documento eletrônico, um usuário deve utilizar a chave que consta no seu certificado digital.

639. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Caso ocor-ra, na comunicação entre os computadores da rede da organização mencionada, o problema conhecido como man-in-the-middle attack, uma solução eficaz será utilizar uma autoridade de certificação, que provê alto grau de confiança durante o processo de distribuição de chaves públicas.

640. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Se a rede de uma organização atuar de forma integrada a uma infraestrutura de chave pública, de natureza hierárquica, formada por RAs (regional authorities) e


110

ELSEVIER

CAs (certification authorities), o administrador da rede, ao analisar qual foi a entidade que assinou digitalmente o certificado público de cada membro dessa infraestrutura de chave pública, constatará que todos os certificados analisados foram assinados pela autoridade certificadora raiz.

641. (MCT/Tecnologista Pleno/Segurança de Sistemas de Informação/2008) Na public key infrastructure X.509 (PKIX), o processo de registro é definido como sendo aquele em que uma autoridade certificadora (CA) se registra junto a outra CA, tornando-se a primeira uma CA subordinada à segunda.

5.4. Ameaças, vulnerabilidades e ataques

642. (Correios/Analista de Sistemas/Suporte de Sistemas/2011) Uma das técnicas de phishing consiste em envenenar cache de servidores DNS, fornecendo, assim, URLs falsas aos usuários que consultam esse servidor DNS e apontando para servidores diferentes do original.

643. (STJ/Analista Judiciário/Informática/2008) Em redes IP que utilizam switches, pode-se realizar a escuta do tráfego com o ARP spoofing.

644. (EMBASA/Analista de Saneamento/Analista de Tecnologia da Informação – Rede/2010) O ataque de MAC flooding faz um switch transmitir frames para todas as suas portas, como se fosse um hub.

645. (DATAPREV/Analista de Tecnologia da Informação/Redes/2006) A restrição na capacidade de aprendizado de endereços nas portas de um switch é suficiente para evitar o ARP spoofing.

646. (TJ-ES/Analista Judiciário/Análise de Suporte/2011) IP Spoofing é uma técnica utilizada para mascarar pacotes IP por meio de endereços errados, a fim de que não seja possível identificar o endereço IP e para que não se permita a identificação do invasor.

647. (MCT/Tecnologista Jr/2008) Um vírus de macrocomandos de uma aplicação, como, por exemplo, um editor de textos, é independente da plataforma com-putacional e dos sistemas operacionais.

648. (MCT/Analista de C&T/2008) Na fase latente ou dormente, um vírus de com-putador encontra-se quieto, mas pronto para ser ativado por algum evento.

649. (MCT/Analista de C&T/2008) Do ponto de vista estrutural, o programa hospe-deiro de um vírus de computador contém adicionado ao seu código executável pelo menos uma parte do código executável do próprio vírus.

650. (ABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Os scan-ners heurísticos, programas de combate a códigos maliciosos, dependem da assinatura específica de um vírus, que deve ser combinada com regras heu-rísticas para a detecção de provável infecção por vírus.


111

651. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Um worm pode realizar diversas funções maliciosas, como a insta-lação de keyloggers ou screenloggers, o furto de senhas e outras informações sensíveis, como números de cartões de crédito, a inclusão de backdoors, para permitir que um atacante tenha total controle sobre o computador, e a alteração ou destruição de arquivos.

652. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) O cavalo de troia (trojan horse) não embute cópias de si mesmo em outros programas ou arquivos e não necessita ser executado para se propagar. Sua propagação se dá por meio da exploração de vulnerabilidades existentes ou de falhas na configuração de software instalados em computadores.

653. (EMBASA/Assistente de Saneamento/Assistente de Informática I/2010) Ca-valo de troia é um software legítimo que o usuário utiliza normalmente, mas, ao mesmo tempo, executa outras funções ilegais, como enviar mensagens e arquivos para o hacker ou abrir portas de entrada para futuras invasões.

654. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Um adware difere de um spyware pela intenção. O primeiro é proje-tado para monitorar atividades de um sistema e enviar informações coletadas para terceiros, e o segundo é projetado especificamente para apresentar propagandas.

655. (PF-Nacional/Perito Criminal Federal/Computação Científica/2004) Os pro-gramas conhecidos como spyware são um tipo de trojan que tem por objetivo coletar informações acerca das atividades de um sistema ou dos seus usuários e representam uma ameaça à confidencialidade das informações acessadas no sistema infectado. Esses programas não são considerados como vírus de computador, desde que não se repliquem a partir de um sistema onde tenham sido instalados.

656. (TJ-ES/Analista Judiciário/Análise de Suporte/2011) Um spyware consiste em uma falha de segurança intencional, gravada no computador ou no sistema operacional, a fim de permitir a um cracker obter acesso ilegal e controle da máquina.

657. (TCU/Analista de Controle Externo/Auditoria de TI/2007) São características típicas dos malwares: cavalos de troia aparentam realizar atividades úteis; adwares obtêm e transmitem informações privadas do usuário; backdoors estabelecem conexões para fora da rede onde se encontram; worms modificam o código de uma aplicação para propagar-se em uma rede; e botnets realizam ataques articulados por meio de um controle remoto.

658. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Infor-mação/2009) Um ataque de negação de serviço (DoS) não é uma invasão do


112

ELSEVIER

sistema e objetiva tornar os recursos de um sistema indisponíveis para seus utilizadores. O ataque tenta indisponibilizar páginas hospedadas em servidores web e produz como efeito uma invalidação por sobrecarga.

659. (STM/Analista Judiciário/Análise de Sistemas/2011) A filtragem de tráfego egresso e ingressante é uma das medidas aplicáveis na proteção a ataques de negação de serviço, distribuídos ou não, como o syn flooding e o icmp flooding.

660. (TCU/Analista de Controle Externo/Auditoria de TI/2007) A detecção, por um sniffer de rede, de uma longa série de segmentos TCP SYN enviados de um host local para um host remoto, sem o correspondente envio de segmentos TCP ACK, sugere que a rede sob análise pode estar sofrendo um ataque de negação de serviço.

661. (IPEA/Analista de Sistemas/Suporte de Infraestrutura/2008) Em um ataque negação de serviço por refletor — reflector distributed denial of service (DDoS) — entidades escravas do atacante constroem pacotes que requerem respostas e contém o endereço IP do alvo como endereço fonte no cabeçalho, de modo que ao serem enviados a computadores não infectados, os refletores, tais pacotes provocam respostas direcionadas ao endereço alvo do ataque.

662. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Para confir-mar a suspeita de que a indisponibilidade apresentada por um host da rede de computadores de uma organização está sendo causada por um ataque do tipo smurf, o administrador deverá verificar se há um grande número de pacotes ICMP (Internet control message protocol) do tipo request originados de vários computadores pertencentes a uma mesma rede e direcionados a este host.

5.5. Dispositivos e sistemas de proteção

Um dos temas mais cobrados pela banca em suas provas para cargos de infraestrutura ou suporte. Dentre os principais tópicos, ganha destaque as questões sobre firewall, onde o tipo mais comum de questão são as que envolvem comparações entre os filtros de pacotes, baseados ou não em estados, e os proxy firewall, também conhecidos como gateways de aplicação. No tocante aos sistemas de detecção de intrusão (Intrusion Detection System – IDS), as questões quase sempre recaem sobre a classificação desses sistemas, em especial no tocante à metodologia de detecção e o alvo, se eles são baseados em host ou rede. Por fim, no tocante às redes privadas virtuais (Virtual Private Network – VPN), o tema mais exigido é o IPSec, principalmente aspectos que envolvem o AH (Authenti-cation Header), o ESP (Encapsulating Security Payload) e o IKE (Internet Key Exchange).


113

663. (PF-Regional/Perito Criminal Federal/Computação Científica/2004) Entre os diversos equipamentos que podem ser utilizados para aumentar o nível de segurança de uma rede de computadores corporativa, os firewalls exercem um papel fundamental. Para que sua ação possa ser eficaz, eles devem ser instalados entre a rede interna da organização e as redes do mundo externo e têm por objetivo filtrar o conteúdo que chega até a rede interna impedindo que ataques conhecidos sejam realizados.

664. (Correios/Analista de Sistemas/Suporte de Sistemas/2011) As ferramentas de firewall conhecidas como filtro de pacotes trabalham na camada de transporte e de rede do protocolo TCP/IP e tratam os protocolos TCP e UDP e as portas de acesso aos serviços.

665. (EMBASA/Assistente de Saneamento/Assistente de Informática I/2010) Uma rede interna pode ser protegida contra o IP spoofing por meio da aplicação de filtros; como exemplo, se a rede tem endereços do tipo 100.200.200.0, então o firewall deve bloquear tentativas de conexão originadas externamente, caso a origem tenha endereços de rede do tipo 100.200.200.0.

666. (MPE-AM/Analista de Redes/2008) A filtragem de pacotes sem estado baseia--se na inspeção das informações de cabeçalho para determinar se um pacote pode ou não ser aceito ou transmitido.

667. (MPE-AM/Analista de Redes/2008) A filtragem com informação de estado leva em consideração o estado das conexões para aceitar ou não pacotes, o que reduz o esforço computacional da inspeção em si e aumenta a granularidade da filtragem.

668. (MC/Informática/Administração de Rede/2008) Firewalls baseados em filtra-gem de pacotes não apresentam problemas ao lidar com pacotes fragmentados.

669. (MC/Informática/Administração de Rede/2008) Firewalls que realizam a inspeção de estado normalmente são menos eficazes e seguros que firewalls baseados em filtragem de pacotes.

670. (MC/Informática/Administração de Rede/2008) Os firewalls stateful utilizam apenas estado das conexões TCP para realizar a inspeção.

671. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) A inspeção de estados visa determinar se um pacote pode entrar ou sair de uma rede, tendo por base a verificação de informações localizadas no cabeçalho do pacote.

672. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Tanto na filtragem quanto na inspeção que se baseiam em estado, a informação de estado é mantida em uma tabela até que a conexão se encerre (como no tráfego TCP) ou ao atingir um limite de tempo (como no caso de trá-fego TCP, UDP e ICMP).


114

ELSEVIER

673. (CBMDF/QOBM/Complementar/Informática/2011) Os firewalls com filtragem por inspeção de estado apresentam, em relação aos que utilizam filtragem de pacotes por endereço, as vantagens de permitir a implantação de regras de filtragem mais sofisticadas e apresentar arquitetura mais simples e mais robusta.

674. (MPE-AM/Analista de Redes/2008) Uma proxy media a conexão de um cliente ou usuário para prover acesso a um serviço de rede, o que evita a conexão direta peer-to-peer.

675. (TCU/Analista de Controle Externo/Tecnologia da Informação/2008) Se o admi-nistrador da rede de computadores tiver de escolher entre implantar um proxy firewall ou um firewall do tipo packet filter, a sua decisão deverá basear-se em um dos dois critérios seguintes: necessidade de atuação na camada de aplicação ou maior vazão de dados. Se o critério preponderante for o primeiro, então, a decisão deve ser favorável à instalação de proxy firewalls; se for o segundo, deve ser escolhido um packet filter.

676. (ABIN/Analista de Informações/Código 9/2004) Um proxy de aplicação tem capacidade de detectar ataque contra um servidor mediante a observação da chegada de pacotes IP fragmentados.

677. (BRB/Analista de Tecnologia da Informação/2011) O posicionamento correto de um firewall é dentro da DMZ.

Um firewall tem três interfaces, conectadas da seguinte forma: uma à rede externa; outra à rede interna; e a terceira a uma DMZ. Nessa situação, consi-derando que o firewall registre todas as suas ações referentes ao exame do tráfego, julgue o item seguinte.

678. (EMBASA/Analista de Saneamento/Analista de Tecnologia da Informação/Atuação em Rede/2010) Nessa situação, as regras do firewall devem: permitir acesso da rede externa apenas aos servidores presentes na DMZ; negar acesso do tráfego da rede externa que tenha como origem endereços da rede interna; e negar acesso do tráfego da rede interna que tenha como origem endereços distintos dos utilizados na rede interna.

679. (TJ-ES/Analista Judiciário/Análise de Suporte/2011) IDS (intrusion detection system) pode ser utilizado para incrementar o trabalho do firewall e permitir que o tráfego de dados de uma rede seja monitorado para correção imediata de problemas ou falhas.

680. (ABIN/Analista de Informações/Código 9/2004) Em um sistema de detecção de intrusão (intrusion detection system — IDS), um falso positivo consiste em um evento em que o IDS deixa de detectar uma intrusão que efetivamente ocorreu.


115

681. (PF-Nacional/Perito Criminal Federal/Computação Científica/2004) Um sistema de detecção de intrusão (IDS) por uso incorreto utiliza descrições de ataques previamente conhecidos (assinaturas) para identificar a ocorrência de ataques. Esse tipo de IDS tem como inconveniente a geração de um número elevado de falsos positivos quando ataques novos, para os quais ainda não foram espe-cificadas assinaturas de ataque convenientes, são lançados contra o sistema monitorado pelo IDS.

682. (MCT/Tecnologista Jr/2008) Na abordagem de detecção estatística de anoma-lias, definem-se regras de comportamento a serem observadas para decidir se determinado comportamento corresponde ao de um intruso.

683. (IPEA/Analista de Sistemas/Suporte de Infraestrutura/2008) A abordagem de detecção de anomalias por contagem de eventos em intervalos de tempo, com indicação de alarme em caso de ultrapassagem de um limiar, é uma aborda-gem com baixo índice de falsos positivos e de falsos negativos na detecção de intrusão.

684. (ABIN/Tecnologista/Classe Pleno/Padrão/Código 15/2004) Sistemas de de-tecção de intrusão enquadram-se em duas categorias: baseados em rede (network based) e baseados em host. Os primeiros monitoram todo o tráfego em um segmento de rede, procurando por assinaturas que evidenciem uma atividade suspeita, e os demais monitoram a atividade em um host específico. Um IDS baseado em rede tende a ser mais complexo e caro, estando sujeito a gerar falsos alarmes com maior frequência.

685. (SERPRO/Técnico/Operação de Redes/2010) A desvantagem de um IDS com análise por estado do protocolo é que a monitoração e a análise dos ataques é feita individualmente em cada pacote, desconsiderando a informação distri-buída dentro de uma sessão.

686. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) IDS e IPS são sistemas que protegem a rede de intrusões, diferindo no tratamento dado quando uma intrusão é detectada. Especificamente, o IPS limita-se a gerar alertas e ativar alarmes, e o IDS executa contramedidas, como interromper o fluxo de dados referente à intrusão detectada.

687. (SERPRO/Analista/Suporte Técnico/2010) Em uma rede de comunicação, um sistema de detecção de intrusos monitora os cabeçalhos e o campo de dados dos pacotes, a fim de detectar possíveis invasores no sistema, além de acessos que podem prejudicar o desempenho da rede. Esse processo não fica preju-dicado com a implantação de criptografia, via SSL, IPSec, entre outras, como elemento de segurança nas transmissões de dados.

688. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Uma VPN é uma conexão estabelecida sobre uma infraestrutura


116

ELSEVIER

pública ou compartilhada, usando tecnologias de tunelamento e criptografia para manter seguros os dados trafegados.

689. (DATAPREV/Analista de Tecnologia da Informação/Redes/2006) As VPNs que utilizam túneis TCP são mais seguras que aquelas que utilizam UDP, já que o TCP é confiável, enquanto o UDP não é.

690. (Correios/Analista de Sistemas/Suporte de Sistemas/2011) O protocolo IPSEC possui a capacidade de esconder os endereços IPs internos, pois suporta o recurso chamado NAT (network address translation).

691. (Correios/Analista de Sistemas/Suporte de Sistemas/2011) O IPSEC é muito utiliza-do em conexões VPN (virtual private network), pois é capaz de validar a integridade e a confidencialidade das informações trafegadas na VPN, por meio da utilização do AH (autentication header) e do ESP (encapsulating security payload).

692. (CBMDF/QOBM/Complementar/Informática/2011) Em uma VPN (virtual pri-vate network) que utilize a técnica de tunelamento, os conteúdos dos pacotes que trafegam pela Internet são criptografados, ao passo que, para permitir o roteamento eficiente dos pacotes, os seus endereços de origem e de destino permanecem não criptografados.

693. (MCT/Tecnologista Jr/2008) Na arquitetura de segurança do internet protocol (IP) — IPSec —, a associação de segurança é um relacionamento bidirecional entre um emissor e um receptor, que é identificada pelo número do soquete da aplicação usuária.

694. (MCT/Tecnologista Jr/2008) O Internet security association key management protocol (ISA KMP) pode ser usado para a automação da gerência de chaves criptográficas entre o emissor e o receptor no IPSec.

5.6. Normas ABNT NBR ISO/IEC 27001 e 27002 – Gestão de segurança da informação

As normas de segurança da série ISO/IEC 27000 e a norma ABNT NBR 15999 são, depois de Criptografia, o tema mais exigido em provas do CESPE. Em alguns concursos, chega a ser o único tema de segurança constante do edital. Dentre essas normas, a que apresenta maior número de questões em provas é a ABNT NBR ISO/IEC 27002:2005. Algumas seções dessa norma são temas absolutamente recorrentes, como: introdução (seção 0), termos e definições (seção 2), política de segurança da informação (seção 5), gestão de ativos (seção 7), segurança física e do ambiente (seção 9) e gestão de operações e comunicações (seção 10). No tocante à norma ABNT NBR ISO/IEC 27001:2006, os conceitos mais cobrados são aqueles que envolvem a seção de número 4, onde consta o ciclo de gestão que fundamenta o Sistema de Gestão de Segurança da Informação (SGSI).


117

695. (SERPRO/Analista/Negócios em Tecnologia da Informação/2010) Segundo a NBR 27001, um sistema de gestão da segurança da informação apresenta o seguinte ciclo: estabelecimento, implementação e operação, monitoramento e revisão, e manutenção e melhoria do sistema.

696. (MCT/Tecnologista Jr/2008) Dependendo de seu tamanho ou natureza, uma organização pode considerar um ou mais requisitos da norma ISO 27001 como não-aplicáveis e, ainda assim, continuar em conformidade com essa norma internacional.

697. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) Na prática, os padrões 27001 e 27002 normalmente são usados em conjunto, embora seja possível o uso de outros controles de segurança da informação juntamente com o padrão 27001, até mesmo em substituição ao padrão 27002.

698. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) O sistema de gestão de segurança da informação é o sistema global de gestão, embasado em uma abordagem de risco, que permite definir, implementar, operacionalizar e manter a segurança da informação.

699. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Um evento de segurança de informação é uma ocorrência em um sistema, serviço ou estado de rede que indica, entre outras possibilidades, um possível desvio em rela-ção aos objetivos de segurança específicos da organização, e um incidente de segurança de informação é um evento único ou uma série de eventos indese-jados de segurança da informação que possuem um impacto mediano sobre os negócios.

700. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) Incidente de se-gurança da informação é uma ocorrência identificada de um sistema, serviço ou rede que indica uma possível violação da política de segurança da informação ou falha de controles, ou uma situação previamente desconhecida, que possa ser relevante para a segurança da informação.

701. (Correios/Analista de Sistemas/Suporte de Sistemas/2011) No processo de estabelecimento de um sistema de gestão de segurança da informação, deve ser definido o escopo, além de serem analisados e avaliados os riscos.

702. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Apesar de recomendável, a aceitação de riscos residuais não precisa necessariamente passar pela aprovação da gestão superior da organização.

703. (ANAC/Analista Administrativo/Tecnologia da Informação/2009) Na implemen-tação e operacionalização do sistema de gestão de segurança da informação, deve-se medir a eficácia dos controles propostos.

704. (IJSN/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) A norma ISO 27001 indica que uma política global


118

ELSEVIER

de segurança da informação deve ser estabelecida antes da elaboração de uma declaração de aplicabilidade de controles de segurança, mas somente após a realização de uma análise/avaliação de risco formal.

705. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Entre os documentos e registros cujo controle é demandado pela norma ABNT NBR ISO/IEC 27001, destacam-se como documentos a declaração da política de seguran-ça, o relatório de análise/avaliação de risco e a declaração de aplicabilidade; além disso, destacam-se como registros os livros de visitantes, os relatórios de auditoria, as ocorrências de incidentes de segurança e outros registros, inclusive de não conformidade.

706. (SERPRO/Analista/Redes/2008) A definição de critérios para aceitação de riscos é uma das responsabilidades da alta administração, segundo a norma NBR ISO/IEC 27001.

707. (SERPRO/Analista/Redes/2008) Para assegurar que os controles, objetivos de controle e processos sejam executados e implementados de forma eficaz, a norma NBR ISO/IEC 27001 recomenda a realização de auditorias externas em intervalos regulares de, no máximo, seis meses.

708. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) A organi-zação deve fazer análises críticas com o objetivo de identificar tentativas e violações de segurança bem-sucedidas, sendo esta uma atividade verificada na fase check (checar).

709. (SERPRO/Analista/Redes/2008) O estabelecimento da política do sistema de gestão de segurança da informação (SGSI) é de responsabilidade da equipe de segurança da informação.

710. (SERPRO/Analista/Redes/2008) Entre as atividades contempladas na fase agir (act) está a necessidade de identificar não-conformidades potenciais e suas causas, objetivando alcançar a melhoria contínua do sistema de gestão de segurança da informação.

711. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A Norma NBR ISO/IEC 27001 estabelece o código de prática para a gestão da segurança da informação e a Norma NBR ISO/IEC 27002 trata dos requisitos dos sistemas de gestão de segurança da informação.

712. (MPU/Analista de Informática/Banco de Dados/2010) O padrão atual da nor-ma em questão constitui-se em uma revisão da primeira versão dessa norma publicada pela ISO/IEC, em 2000. À época, essa norma era cópia da norma britânica British Standard (BS) 7799-1:1999.

713. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Estão entre os objetivos da segurança da informação a garantia da continui-


119

dade do negócio, a minimização dos riscos para o negócio e a maximização do retorno sobre os investimentos.

714. (TJ-ES/Analista Judiciário/Análise de Suporte/2011) Na área de segurança da informação, estão excluídas do conceito de controle as políticas, as diretrizes, as práticas ou a própria estrutura organizacional, que são consideradas con-tramedidas ou ações de prevenção.

715. (TCU/Analista de Controle Externo/Tecnologia da Informação/2007) O esta-belecimento de controles visando a proteção aos dados privados tratados no âmbito dessa organização deve ser prioritário frente aos controles que visam a garantia da continuidade dos negócios da organização.

716. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) Os requisitos do negócio para o processamento de informação, que uma organi-zação tem de desenvolver para apoiar suas operações, estão entre as fontes principais de requisitos de segurança da informação.

717. (MPU/Analista de Informática/Perito/2010) Os principais fatores críticos de sucesso apresentados na referida norma incluem política de segurança, abor-dagem e estrutura da segurança consistente com a cultura organizacional, comprometimento de todos os níveis gerenciais, entendimento dos requisitos de segurança e divulgação da segurança.

718. (MPU/Analista de Informática/Suporte Técnico/2010) Vulnerabilidade, em segu-rança de sistemas computacionais, é uma falha no projeto, implementação ou configuração do sistema operacional, ou de outro software, que, quando explorada por um atacante, permite a violação da integridade de um computador.

719. (TJ-ES/Analista Judiciário/Análise de Sistemas/2011) Para a garantia de um nível de segurança mínimo, que evite a concretização de ameaças em uma organização, é obrigatória a implantação de todos os controles contidos na norma 27002, conforme recomendação feita na ISO, independentemente do tamanho e tipo de organização.

720. (ANTAQ/Analista Administrativo/Informática/2009) As normas ABNT NBR ISO/IEC 27001:2006 e ABNT NBR ISO/IEC 17799:2005 enunciam um mesmo conjunto de mais de cento e trinta controles de segurança, os quais, por sua vez, são agrupados em mais de 30 objetivos de controle, sendo a primeira das normas de redação mais abstrata que a segunda e com estrutura de seções parcialmente correspondente à da norma ABNT NBR ISO 9001:2000.

721. (MPU/Analista de Informática/Suporte Técnico/2010) Segundo a referida norma, por meio da gestão de ativos, é possível identificar as ameaças aos ativos e suas vulnerabilidades e realizar uma estimativa da probabilidade de ocorrência e do impacto potencial ao negócio.


120

ELSEVIER

722. (ABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) No âmbito da segurança da informação, não existem riscos aceitáveis; por isso, todos os riscos devem ser controlados, evitados ou transferidos.

723. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) São exemplos de conteúdos que constam no documento de política da informação: conformidade com a legislação e cláusulas contratuais, requisitos na educação de segurança, gestão da continuidade do negócio e regras para controle de acesso.

724. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) O documento relativo à política de segurança da informação deve ser aprovado pela direção da em-presa, publicado e comunicado a todos os funcionários e às partes externas relevantes.

725. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) Uma polí-tica de segurança eficaz parte da premissa do uso efetivo de um conjunto de ferramentas de segurança, como firewalls, sistemas de detecção de intrusos, validadores de senha e criptografia forte.

726. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) Um dos controles da política de segurança da informação estabelece que ela deve ser analisada criticamente a intervalos planejados ou quando mudanças significativas ocor-rerem, para assegurar a sua contínua pertinência, adequação e eficácia.

727. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) São exemplos de ativos de uma organização a informação e os processos de apoio, sistemas e redes. Os requisitos de segurança, em uma organização, são identificados por meio de análise sistemática dos riscos de segurança.

728. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Infor-mação/2009) Uma organização deve ser capaz de inventariar seus ativos, identificar seus respectivos valores e importâncias e indicar um proprietário responsável por eles. A informação deve ser classificada em termos de sua utilidade, adequabilidade e nível de segurança.

729. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) Um arqui-vo de texto, uma IDE para desenvolvimento em linguagem C e um pendrive são classificados como ativos de software, de serviço e físico, respectiva-mente.

730. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) O objetivo de controle Controles de Entrada Física estabelece que perímetros de segurança (barreiras, como paredes, portões de entrada controlados por cartão ou balcões de recepção com recepcionistas) devem ser utilizados para proteger as áreas que contenham informações e recursos de processamento da informação.


121

731. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) As instalações de pro-cessamento da informação gerenciadas pela organização podem permanecer fisicamente juntas das que são gerenciadas por terceiros, desde que o acesso ao local seja devidamente controlado.

732. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) Alcançar e manter a proteção adequada dos ativos da organização é um objetivo de controle estabelecido na norma NBR/ISO/IEC 27001/2006. Associado a esse objetivo, há o controle relativo à remoção de propriedade, o qual determina que um ativo não mais utilizado por um proprietário deverá ser dele desvinculado.

733. (MPU/Analista de Informática/Perito/2010) Com o objetivo de otimizar o uso de um ambiente de desenvolvimento de software quanto aos procedimentos e responsabilidades operacionais relativos ao gerenciamento das operações e das comunicações, uma organização deve garantir que software em desen-volvimento e software em produção partilhem de sistemas e processadores em um mesmo domínio ou diretório, de modo a garantir que os testes sejam compatíveis com os resultados esperados no mundo real.

734. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) Registros ou logs de auditoria podem conter dados pessoais confidenciais e de intrusos; por isso, é importante que medidas de proteção adequadas sejam tomadas, como, por exemplo, não permitir, quando possível, que administradores de sistemas não tenham permissão de exclusão ou desativação de registros de suas próprias atividades.

735. (MPU/Analista de Informática/Perito/2010) A adoção de senhas de qualidade por parte dos usuários são recomendações para implantar uma política de uso de chaves e senhas. Alguns aspectos, citados na norma, característicos de senhas de qualidade são senhas fáceis de serem lembradas, que não sejam vulneráveis a ataques de dicionário e que sejam isentas de caracteres idênticos consecutivos.

736. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) O objetivo de controle Análise Crítica dos Direitos de Acesso de Usuário estabelece que deve existir um procedimento formal de registro e cancelamento de usuário para garantir e revogar acessos em todos os sistemas de informação e serviços.

737. (TRE-ES/Analista Judiciário/Análise de Sistemas/2011) As ações que minimi-zam o risco de vazamento de informações mediante o uso e a exploração de covert channels incluem a varredura do envio de mídias e comunicações, para verificação da presença de informação oculta; o mascaramento e a modula-ção do comportamento dos sistemas e das comunicações, a fim de evitar que terceiros subtraiam informações dos sistemas; e o monitoramento regular do uso dos recursos computacionais e das atividades do pessoal.


122

ELSEVIER

738. (TCU/Analista de Controle Externo/Tecnologia da Informação/2007) Conforme a ISO 17799, é obrigatório o relatório de incidentes de segurança ao ponto de contato designado. Assim, um funcionário de uma organização que realiza operações de alto risco e identifica uma violação de acesso, porém encontra-se sob coação, poderá utilizar-se de um método secreto para indicar esse evento de segurança. Esse método é conhecido como alarme de coação.

739. (ABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/2010) Funcioná-rios, fornecedores e terceiros devem ser instruídos a averiguar, imediatamente, qualquer fragilidade na segurança de informação suspeita.

740. (ANTAQ/Analista Administrativo/Informática/2009) O desenvolvimento de uma estrutura básica de um plano de continuidade do negócio constitui controle com foco administrativo; os ativos de processo contidos no plano referido, em geral, são críticos ao negócio da organização e apresentam objetivos de tempo de recuperação da ordem de poucos segundos.

741. (BASA/Técnico Científico/Tecnologia da Informação/Segurança da Informa-ção/2009) Alguns controles deverão salvaguardar sistemas operacionais e ferramentas de auditoria durante as auditorias de sistema. O escopo de veri-ficação deve ser acordado e controlado.

5.7. Norma ABNT NBR ISO/IEC 27005 – Gestão de riscos em segurança da informação

742. (PREVIC/Analista Administrativo/Tecnologia da Informação/2011) De acordo com a norma NBR/ISO/IEC 27005, a comunicação de riscos visa assegurar que as informações sobre os riscos sejam compartilhadas entre os tomadores de decisão e outros stakeholders, buscando-se, assim, alcançar um entendimento de todos sobre como os riscos serão gerenciados.

743. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) Os processos que fazem parte da análise/avaliação de riscos são identificação de riscos, estimativa de riscos e avaliação de riscos.

744. (IJSN/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) Ativos, ameaças, controles existentes, vulnera-bilidades e consequências são componentes que servem de insumos para a elaboração de cenários de incidentes e identificação de riscos.

745. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A norma NBR ISO/IEC 27005 prescreve que o gerenciamento de incidentes pode ser realizado iniciando-se com uma definição de contexto, seguido por uma análise e avaliação, tratamento, aceitação, comunicação, monitoramento e análise crítica dos incidentes.


123

Acerca do processo ilustrado na figura acima, que apresenta as principais ati-vidades envolvidas na gestão de riscos, conforme a ABNT NBR ISO/IEC 27005, publicada em 2008, julgue o próximo item.

746. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Durante o início da adoção da gestão de riscos em uma organização, a aplicação de métodos quantitativos para cálculo do nível de risco ocorre principalmente durante a estimativa de riscos e tende a oferecer resultados mais confiáveis e eficazes comparativamente ao uso de métodos quantitativos, sobretudo quando os ativos no escopo apresentam elevada intangibilidade.

5.8. Norma ABNT NBR 15999 – Gestão da continuidade de negócios

747. (TRT-21/Analista Judiciário/Tecnologia da Informação/2010) No que concerne à gestão da continuidade de negócios, a norma brasileira NBR 15999 estabelece o que deve ser atendido. Nesse aspecto, todos os estágios da gestão da con-tinuidade são: Compreender o Negócio; Estratégia de Continuidade; Plano de Continuidade; Construir e Disseminar a Cultura; e Exercitar, Manter e Auditar.


124

ELSEVIER

748. (IJSN/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da Informação/2010) Para a elaboração de uma estratégia de conti-nuidade de negócios, pode-se recorrer aos valores dos objetivos de tempo de recuperação, os quais, por sua vez, são derivados a partir dos períodos máximos toleráveis de interrupção.

749. (TCU/Auditor Federal de Controle Externo/Tecnologia da Informação/2010) A norma NBR ISO/IEC 15999 destina-se a orientar as empresas no que fazer a partir do momento em que acontecer algum incidente, oferecendo respostas às ameaças sofridas e seus impactos nas operações do negócio.

Considerando a figura acima, que apresenta o modelo sistêmico de gestão de continuidade de negócios proposto pelas normas ABNT NBR 15999, em que se destacam processos numerados de 1 a 6, bem como fluxos nomeados A até D, julgue os próximos dois itens.

750. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) A deter-minação de RTOs (objetivos de tempo de recuperação) ocorre apenas após a compreensão dos tempos máximos toleráveis de interrupção, sendo os RTDs insumos fundamentais para a execução de 4.

751. (TCU/Analista de Controle Externo/Tecnologia da Informação/2009) Consideran-do que a auditoria seja um processo sistemático, documentado e independente para obter evidências de auditoria e avaliá-las objetivamente para determinar a extensão na qual os critérios da auditoria são atendidos, é correto afirmar que evidências de auditoria são produzidas no âmbito das atividades 3, 4, 5 e 6, enquanto o processo de auditoria é realizado no âmbito da atividade 2.


125

Parte 2Gabaritos

comentados

Parte 2

Gabaritos comentados

C a p í t u l o 1

Gabaritos de Banco de Dados

1.1. Modelagem de Dados

1. Certa.A questão aborda de maneira correta as principais características de entida-

des fracas. O identificador de uma entidade fraca é composto por um identificador local (chave parcial, no modelo lógico) mais o atributo identificador da entidade forte relacionada. Como o identificador da entidade forte irá compor o identifica-dor da entidade fraca, toda instância de entidade fraca obrigatoriamente deverá estar relacionada a uma instância da entidade forte.

2. Certa.Korth, Silberschatz e Sudarshan (2006, p. 139), afirmam que os valores para

atributos derivados podem ser obtidos a partir dos valores de outros atributos ou entidades relacionadas tal como a questão sugere.

3. Errada.A restrição de integridade de entidade estabelece que nenhum valor de chave

primária pode ser nulo. A chave estrangeira pode ser nula no caso de relaciona-mentos opcionais.

4. Certa.A questão aborda de maneira correta o conceito de identificador de entidade.

A restrição de chave garante a unicidade do atributo ou atributos identificadores.

5. Certa.A questão aborda de maneira correta os principais conceitos de modelagem

relacional, são eles: composição de tabelas por linhas e colunas, a materialização de relacionamentos por meio de chaves estrangeiras e a restrição de integridade


130

ELSEVIER

referencial que garante que o valor de uma coluna que representa uma chave estrangeira em uma tabela exista como chave candidata (primária ou alternativa) em uma tabela do modelo considerado.

Restrições de Integridade:• Éumaregradeconsistênciadedadosqueégarantidapelopróprio

SGBD.• Integridade de Domínio: define os valores que podem ser assumidos

pelos campos de uma coluna, como por exemplo, sexo só poder assu-mir os valores “M” (masculino) e “F” (feminino).

• Integridade de Vazio: especifica se um campo de uma coluna pode ou não ser vazio.

• Integridade de Chave: define que os valores da chave primária e alter-nativa devem ser únicos.

• Integridade de Entidade: define que nenhum valor de chave primária pode ser NULL.

• Integridade Referencial: define que os valores dos campos que apa-recem numa chave estrangeira devem aparecer na chave candidata (primária, alternativa) da tabela referenciada.

• Integridade de Unicidade: define que o valor do campo deve ser único.

6. Errada.Cada entidade representada no nível conceitual não precisa, necessariamente,

se transformar em uma tabela no nível lógico. Como exemplo temos o relaciona-mento de Generalização/Especialização que possui várias formas de mapeamento do nível conceitual para o lógico.

Níveis de Abstração de Um Projeto de Banco de Dados:• Um projeto de Banco de Dados pode ser abstraído em três níveis: con-

ceitual, lógico e físico.• O nível conceitual representa o domínio observado independente de

Sistema Gerenciador de Banco de Dados (SGBD) ou do paradigma utilizado por ele, como por exemplo, hierárquico, em rede, relacional ou orientado a objetos, entre outros. O modelo utilizado neste nível de abstração é o Modelo Entidade Relacionamento (ER) (CHEN, 1976).

• O nível lógico também não depende de um SGBD específico, mas de-pende do paradigma utilizado pelo SGBD. Ao desenharmos um mo-delo lógico para o paradigma relacional, esse modelo é válido para qualquer SGBD Relacional, como por exemplo, Oracle, DB2, MS SQL Server, MySQL. Por outro lado, o modelo utilizado neste nível de

Capítulo 1 I Gabaritos de Banco de Dados

131

abstração é dependente de paradigma. Por exemplo, para um SGBD Relacional será utilizada um modelo baseado em tabelas, para um SGBD Orientado a Objetos (OO), será utilizado o diagrama de clas-ses da UML.

• Por último, o modelo físico depende do SGBD específico e do paradig-ma implementado por ele. O modelo utilizado neste nível de abstração deve ser capaz de descrever as estruturas físicas do SGBD específico.

7. Errada.Os índices podem ser baseados em campos que não sejam únicos.

8. Errada.Este tipo de restrição pode ser implementado de maneira mais simples por

meio de restrição de integridade de domínio (constraint de check).

9. Certa.Segundo Korth, Silberschatz e Sudarshan (2006, p. 124), a agregação é uma

abstração pela qual os relacionamentos são tratados como entidades de nível supe-rior. Na figura apresentada, o relacionamento R1 pode ser interpretado como um relacionamento entre as entidades E1 e E2. No entanto, quando interpretamos na vertical, R1 se comporta como uma entidade relacionada à entidade E3. Os atributos de R1 serão oriundos das entidades relacionadas, E1 e E2.

10. Certa.Em um projeto de banco de dados podem existir restrições de integridade

implementadas automaticamente pelo SGBD e restrições de integridade semân-ticas (dependentes de significado) que estão diretamente ligadas ao domínio mo-delado. Neste segundo caso pode haver diversas variações, uma delas é a citada no enunciado da questão.

11. Errada.Segundo Navathe e Elmasri (2011, p. 47), restrições de integridade são

especificadas em um esquema de banco de dados e espera-se que sejam manti-das em cada estado de banco de dados válido de esquema, por tanto, permitem atualizações válidas.

12. Certa.A questão apresenta de maneira correta o conceito de chave candidata.


132

ELSEVIER

13. Errada.Os valores referenciados por uma chave estrangeira não precisam, necessaria-

mente, referenciar valores de chaves primárias, eles também podem referenciar valores de chaves candidatas. Outro erro da questão é afirmar que uma chave estrangeira sempre referencia valores de outra relação, pois a chave estrangeira pode referenciar a própria tabela no caso de auto-relacionamento.

Superchave, Chave Candidata, Chave Primária e Chave Alternada:• Uma superchave é um conjunto de um ou mais atributos que, tomados

coletivamente, nos permite identificar unicamente uma tupla (linha) da relação. Por exemplo, considerando uma tabela Empregado com as colunas CPF, Nome e Sexo, seriam exemplos de superchaves os con-juntos compostos pelas colunas (CPF, Nome, Sexo), (CPF, Sexo), (CPF, Nome) e (CPF),pois na tabela Empregado não haverá duas tuplas re-petidas considerando esses subconjunto de colunas.

• As chaves candidatas são superchaves mínimas ou irredutíveis, ou seja, considerando-se uma superchave, caso qualquer atributo integrante da superchave seja suprimido ela deixa de ser uma superchave. Por exem-plo, considerando-se a superchave (CPF, Nome, Sexo), ao retirarmos a coluna Sexo, o subconjunto (CPF, Nome) continua sendo uma supercha-ve. Então (CPF, Nome, Sexo) é uma superchave, mas não é uma chave candidata. Por outro lado, a superchave (CPF) é um exemplo de chave candidata, pois é mínima e garante a unicidade das tuplas da tabela empregado.

• Chave Primária é o termo utilizado para denotar a chave candidata que é escolhida pelo projetista de banco de dados como principal meio de identificar tuplas dentro de uma relação.

• Chaves Primárias e Alternativas (ou Alternadas) são exemplos de chaves candidatas. Em certas situações mais de uma coluna ou com-binação (irredutível) de colunas servem para distinguir uma linha das demais dentro de uma tabela. Se uma destas for escolhida como chave primária, as demais serão chamadas de chaves alternativas. Por exemplo, caso a tabela empregado também possuísse a coluna Ma-trícula, cujo valor fosse único para cada tupla da tabela, sua compo-sição seria (CPF, Matrícula, Nome, Sexo). Neste caso não há qualquer diferença entre usar as CPF ou Matrícula como chave primária. Ao escolher CPF para chave primária, a coluna Matrícula passa a ser denominada chave alternativa ou alternada, também denominada chave secundária (Navathe; Elmasri, 2011, p. 349).


133

14. Errada.A figura apresenta um modelo entidade relacionamento (CHEN, 1990) que

é um exemplo de modelo conceitual.

15. Certa.O relacionamento “presença” quando mapeado para o nível lógico gerará

uma tabela com quatro atributos, dois atributos já previstos no nível conceitual, horário_chegada e horário_saida, mais as chaves estrangeiras que referenciarão as chaves candidatas das relações “Reunião” e “Pessoa” geradas a partir das entidades de mesmo nome.

16. Errada.Por se tratar de uma representação do nível conceitual não faz sentido falar-

-se em normalização, pois esta característica é inerente ao modelo lógico.

17. Certa.As entidades “Reunião” e “Proposta”, de fato, darão origem a tabelas com

chaves estrangeiras. A tabela “Reunião” possuirá uma chave estrangeira refe-renciando a tabela “Comissão” por estar do lado de cardinalidade n do relacio-namento e a tabela “Proposta” possuirá uma chave estrangeira referenciando a tabela “Reunião” pelo mesmo motivo.

18. Errada.A junção deve ser baseada no relacionamento entre as duas tabelas que

será representado pelo atributo “cod_comissão” da tabela “Comissão” e a chave estrangeira que deverá ser criada na tabela “Reunião” para referenciar “cod_co-missão” da tabela “Comissão”.

19. Certa.Uma comissão pode ser composta por um número arbitrário de pessoas de-

vido ao relacionamento de cardinalidade n:n entre “Pessoa” e “Comissão” e uma pessoa pode participar de um número arbitrário de comissões devido ao mesmo relacionamento. Cada proposta é encaminhada em apenas uma reunião devido ao relacionamento de cardinalidade 1:n entre “Pessoa” e “Reunião”. E uma pessoa pode ter presença em reuniões de comissões das quais ela não faz parte, esta característica é possível devido ao relacionamento direto entre “Pessoa” e “Reunião” de cardinalidade n:n.


134

ELSEVIER

20. Certa.A questão aborda corretamente uma característica do modelo relacional e

cita os operadores da álgebra relacional como um meio de manipular os dados desse modelo.

21. Errada.Um diagrama entidade-relacionamento permite uma representação do mo-

delo conceitual apenas.

22. Certa.A questão está correta. Uma outra maneira de falar a mesma coisa seria: “Dado

um relacionamento R binário entre as entidades A e B, é correto afirmar que, em um mapeamento de cardinalidade muitos para muitos, uma instância da entidade A está associada a qualquer número de instâncias da entidade B e uma instância da entidade em B está associada a um número qualquer de instâncias da entidade A”.

23. Errada.A questão é inapropriada, pois o domínio deveria ter sido descrito para que

pudéssemos avaliar a unicidade do CEP, no entanto, na vida real sabemos que um mesmo CEP serve para identificar vários endereços e por isso não pode ser chave primária neste contexto.

24. Certa.A questão aborda definição de visão segundo Korth, Silberschatz e Sudar-

shan (2006, p. 65).

25. Certa.A questão apresenta uma possível definição para o conceito de integridade

referencial, ou seja, ela afirma que a chave estrangeira de uma relação deve existir como chave candidata em outra relação. No entanto, ela apresenta uma inconsistência ao excluir o autorrelacionamento, caso em que a chave estrangei-ra de uma relação deve existir como chave candidata na mesma relação. Cabe ressaltar que o enunciado da questão afirma “Integridade referencial pode ser definida...” o que ameniza a inconsistência citada.

26. Certa.A questão apresenta uma possível definição para o conceito de chave estran-

geira, ou seja, ela afirma que a chave estrangeira de uma relação deve existir como chave candidata em outra relação. No entanto, ela apresenta uma inconsistência


135

ao excluir o autorrelacionamento, caso em que a chave estrangeira de uma re-lação deve existir como chave candidata na mesma relação. Cabe ressaltar que o enunciado da questão afirma “Chaves estrangeiras podem ser definidas...” o que ameniza a inconsistência citada.

27. Errada. A afirmativa “para identificar uma entidade do tipo CRIANCA, é necessário

identificar uma entidade do tipo HOSPEDE” é verdadeira, pois a entidade CRIAN-CA é um exemplo de entidade fraca, ou seja, sua chave primária será composta pela chave parcial NOME mais a chave primária da tabela identificadora que é o atributo CPF da tabela HOSPEDE. Por outro lado, a afirmativa “para cada enti-dade do tipo HOTEL, o atributo NOME tem valor único” é falsa pois o atributo citado não está sublinhado. A afirmativa “Para cada entidade do tipo FUNCIO-NARIO, o atributo APELIDO pode ter um conjunto de valores” é verdadeira, pois esse atributo está representado com uma linha dupla. Por último., a afirmativa “O atributo HORAS pode ser migrado para a entidade FUNCIONÁRIO” é falsa, pois este atributo pertence a um relacionamento de cardinalidade “N:N” e por isso não pode ser migrado para nenhuma das entidades participantes.

28. Errada.A afirmativa “o número de horas que um funcionário trabalha em um hotel

é determinado combinando-se entidades dos tipos HOTEL e FUNCIONÁRIO” é verdadeira. Por outro lado, a afirmativa “uma entidade do tipo HOTEL pode estar associada a apenas uma entidade do tipo HOSPEDE” é falsa, pois um HOTEL pode estar associado a vários HOSPEDES devido ao relacionamento de cardinalidade 1:N. Por último, a afirmativa “os valores do atributo NOME são distintos para cada entidade do tipo CRIANÇA” é falsa, pois esse atributo é uma chave parcial de uma entidade fraca e por isso não precisa ser único.

29. Errada.O modelo lógico apresentado descreve corretamente o mapeamento do mo-

delo entidades e relacionamentos. A partir da análise dos dois modelos, pode-se afirmar que todos os atributos e entidades foram corretamente mapeados para as relações.

30. Certa.Segundo Heuser (2001, p. 78), por definição, tabela é um conjunto não ordenado

de tuplas (linhas) exclusivas. Navathe e Elmasri (2011, p. 44) afirmam que no modelo relacional formal, uma relação é definida como um conjunto de tuplas distintas.


136

ELSEVIER

31. Certa.Uma chave primária deve respeitar duas restrições de integridade, a inte-

gridade de chave e a de entidade. A integridade de chave define que os valores da chave primária e alternativa devem ser únicos (NAVATHE; ELMASRI, 2011, p. 44) e a integridade de entidade que define que nenhum valor de chave primária pode ser NULL (NAVATHE; ELMASRI, 2011, p. 47).

32. Errada.A questão refere-se a restrição de integridade referencial, que prevê que a

chave estrangeira de uma tabela deve referenciar a chave candidata da tabela referenciada. Caso o valor não exista na tabela referenciada diz-se que houve violação da integridade referencial.

33. Certa.O modelo entidade-relacionamento (ER) representa apenas as estruturas

de armazenagem, sem se preocupar com os programas que transformarão os dados armazenados.

34. Certa.A questão aborda de maneira correta o conceito de grau de relacionamentos.

35. Certa.A questão aborda de maneira correta o conceito de cardinalidade para

relacionamentos binários. Quando a cardinalidade mínima não é especificada, conforme apresentado na questão, considera-se o relacionamento opcional, ou seja, a cardinalidade mínima é zero.

36. Certa.A questão aborda de maneira correta o conceito de atributo derivado, res-

saltando que esse tipo de atributo embora não seja armazenado, pode ser obtido a partir de um outro atributo armazenado.

37. Certa.Segundo Heuser (2001, p. 14), não necessariamente um relacionamento associa

entidades diferentes. Em um modelo relacional, pode-se ter um auto-relacionamen-to, isto é, um relacionamento entre ocorrências de uma mesma entidade. Neste caso, para diferenciar a participação das instâncias em um relacionamento usa-se o conceito de papel. O papel de uma entidade em um relacionamento define que função uma instância da entidade cumpre dentro de uma instância do relacionamento.


137

38. Certa. A questão aborda de forma correta um conceito característico de atributos em

relações. Segundo Navathe e Elmasri (2011, p. 349), os atributos de uma relação devem incluir apenas valores atômicos (simples, indivisíveis).

39. Errada.A questão inverteu as definições de entidade fraca e entidade forte. Na ver-

dade, as instâncias de uma entidade forte são identificadas a partir dos valores dos seus atributos-chave (chave candidata), por outro lado, as instâncias de uma entidade fraca são identificadas por estarem relacionadas a instâncias específicas de uma entidade forte, pois sua chave primária será composta por uma chave parcial mais a chave primária da entidade forte com a qual se relaciona.

1.2. Normalização

40. Errada.Em um esquema de relação (tabela) pode haver mais de uma chave-

-candidata. Por definição, cave-candidata consiste em uma coluna ou conjunto irredutível de colunas capaz de distinguir um registro dos demais. Quando uma chave-candidata é escolhida para ser chave-primária as demais são denominadas chaves alternadas ou alternativas. Então, é possível possuirmos uma relação com várias chaves candidatas, no qual uma é denominada chave-primária e as demais chaves-candidata.

41. Certa.A questão cita corretamente o conceito de dependência funcional em esque-

mas relacionais. Para materializar o conceito basta imaginarmos uma tabela “Pessoa” com os atributos “identidade” e “nome”. Neste caso, a identidade corresponderia ao atributo X e o nome, ao atributo Y. A representação X -> Y corresponde à afirmativa “X determina Y”, no exemplo, “identidade determina nome”. Então, pode-se afirmar que para cada valor do atributo identidade, existe exatamente um único valor do atributo nome, porém o inverso não é verdadeiro, pois podemos ter dois nomes idênticos com identidades distintas (no caso de homônimos).

42. Errada.O processo de normalização visa alcançar as propriedades desejáveis de mini-

mizar a redundância e de evitar as anomalias de inserção, exclusão e atualização.


138

ELSEVIER

43. Errada.Segundo Navathe e Elmasri (2011, p. 352), a definição correta para a segunda

forma normal é “Um esquema de relação R está em 2FN se cada atributo não principal (não membro de chave candidata) A em R for total e funcionalmente dependente da chave primária de R”.

44. Errada. Segundo Navathe e Elmasri (2011, p. 349), a 1FN é considerada parte da

definição formal de uma relação. Ela afirma que o domínio de um atributo deve incluir apenas valores atômicos (simples e indivisíveis).

45. Certa.Definição correta para a 1FN segundo Navathe e Elmasri (2011, p. 349).

46. Certa.A definição de dependência funcional está correta segundo Navathe e Elmasri

(2011, p. 346). Vejamos um exemplo de uso desta definição. Suponhamos que a relação R seja a tabela EMPREGADO (CPF, NOME), sendo assim, A corresponde ao atributo CPF e B corresponde ao atributo NOME. Suponhamos, também, que esta tabela possua os registros (111, ANA), (222, BETO) e (333, ANA). Observando os registros, pode–se perceber que sempre que o CPF for “111” só poderá a pare-cer o NOME “ANA”, sempre que o CPF for “222” só poderá a parecer o NOME “BETO” e sempre que o CPF for “333” só poderá a parecer o NOME “ANA”. Então CPF determina funcionalmente NOME. A recíproca não é verdadeira, pois quando o NOME for “ANA” poderão aparecer dois CPF, “111” ou “333”.

47. Certa.A questão aborda de maneira correta as características da normalização

segundo Korth, Silberschatz e Sudarshan (2006, p. 11).

48. Certa.A questão cita corretamente uma das propriedades da normalização que é

a reversibilidade. Esta característica corresponde a afirmar que todo esquema, quando normalizado, passa por uma decomposição sem perda, ou seja, tabelas grandes (com várias colunas) são decompostas em várias tabelas pequenas (com poucas colunas). No entanto, é possível reconstruir as estruturas das tabelas grandes a partir das estruturas das tabelas pequenas.


139

49. Certa.A questão afirma corretamente que a normalização proporciona a decom-

posição das tabelas originais, no entanto, as dependências funcionais devem ser corretamente representadas nas tabelas resultantes do processo de normalização.

50. Certa.A 2FN foca a dependência funcional parcial, ou seja, nenhum atributo não

chave não deve ser dependente funcional de parte de uma chave candidata. Então, para sabermos se há uma dependência funcional parcial deve-se testar as chaves candidatas e quem determina quem em uma relação. Para isto basta analisar o lado esquerdo da simbologia “A → B”. Nesta simbologia no lado esquerdo está localizado o determinante e o no lado direito o determinado. Na sequência da questão, pode-se observar que a figura citada não possui nenhuma relação com dependência parcial, pois todos os atributos apresentados são dependentes das chaves primárias completas.

51. Errada.A questão está errada, pois afirma que na 3FN há dependência transitiva

entre atributo não-chave e chave primária. Na verdade a 3FN elimina qualquer dependência funcional transitiva. Na figura pode-se perceber que há uma de-pendência transitiva na relação R1(AUTOR→TELEFONE) e uma dependência parcial na relação R2(ISBN→TITULO).

52. Errada.A definição da FNBC está correta, porém a 3FN suaviza esta restrição, ou

seja, a FNBC é mais restritiva que a 3FN.

53. Errada.A 1FN elimina atributos compostos ou multivalorados e suas combinações.

1.3. Álgebra Relacional

54. Certa. A questão está correta de acordo com Date (2003, p. 156). Segundo o autor, a

interseção de duas relações a INTERSECT b, é uma relação do mesmo tipo das originárias, cujo corpo consiste em todas as tuplas t tais que t aparece em a e em b.

55. Certa.Segundo Korth, Silberschatz e Sudarshan (2006, p. 44), a operação de junção

externa é uma extensão da operação de junção (interna) para lidar com a perda


140

ELSEVIER

de informações desta última. O resultado da junção interna de uma relação a com outra relação b, são as tuplas t de a e b que possuem um atributo em comum, ou seja, tuplas relacionadas. Por outro lado, o resultado da junção externa de uma relação a com outra relação b, são todas as tuplas t de pelo menos uma das relações, mais as tuplas relacionadas resultantes da junção interna.

Tipos de Junção Externa:• Junção Externa à Esquerda (LEFT OUTER JOIN): considerando

as relações a e b, quando executamos a operação a LEFT OUTER JOIN b, o resultado será composto por todas as tuplas da relação a mais as tuplas da relação b que estão relacionadas às tuplas de a.

• Junção Externa à Direita (RIGHT OUTER JOIN): considerando as relações a e b, quando executamos a operação a RIGHT OUTER JOIN b, o resultado será composto por todas as tuplas da relação b mais as tuplas da relação a que estão relacionadas às tuplas de b.

• Junção Externa Completa (FULL OUTER JOIN): considerando as relações a e b, quando executamos a operação a FULL OUTER JOIN b, o resultado será composto por todas as tuplas da relação a mais todas as tuplas da relação b, sendo que as tuplas de a e b rela-cionadas aparecerão na mesma linha.

56. Errada.Segundo o Date (2003, p. 150), os operadores de conjunto tradicionais são:

união, interseção, diferença e produto cartesiano. A linguagem SQL possui im-plementação para esses quatro operadores de conjuntos.

57. Certa.Segundo Korth, Silberschatz e Sudarshan (2006, p. 33), para que uma ope-

ração de união entre duas relações, a U b, seja válida, é necessário que duas condições sejam satisfeitas: as relações a e b precisam ser da mesma aridade (mesmo grau) e atributos correspondentes das duas relações tem que pertencer ao mesmo domínio, ou seja, as duas relações devem ter o mesmo número de atri-butos e o 1º atributo de a tem que pertencer ao mesmo domínio que o primeiro atributo de b e assim sucessivamente.

58. Certa.Segundo Date (2003, p. 150), a álgebra relacional é uma coleção de operado-

res que tomam relações como seus operandos e retornam uma relação como seu resultado., tal como o enunciado da questão.


141

59. Certa.Segundo Date (2003, p. 150), a primeira versão da álgebra relacional foi

definida por Codd e veio a ser considerada como a origem da álgebra “original”. De fato, essa álgebra original consistia de oito operadores conforme o enunciado da questão.

60. Certa.A questão aborda de maneira correta dois aspectos da operação de in-

terseção. O primeiro aspecto é a necessidade das duas relações participantes da operação serem compatíveis para a união, ou seja, as duas relações devem possuir o mesmo número de atributos (mesmo grau) e atributos corresponden-tes das duas relações tem que pertencer ao mesmo domínio. O outro aspecto é o resultado que deverá conter as tuplas que existem simultaneamente nas duas relações.

61. Certa.Segundo Navathe e Elmasri (2011, p. 102), a operação PRODUTO CARTE-

SIANO, também conhecida como PRODUTO CRUZADO ou JUNÇÃO CRUZADA, entre duas relações produz uma nova relação cujas tuplas consistem da combina-ção de cada tupla de uma relação com cada tupla da outra relação. Por exemplo, sendo a relação A(a1, a2, a3,..., an) e a relação B(b1, b2, b3,..., bm) o resultado do produto cartesiano entre estas duas relações será uma relação R que terá o grau n+m e uma tupla para cada combinação de tuplas, uma de A e uma de B, com a estrutura de R (a1, a2, a3,..., an, b1, b2, b3,..., bm).

62. Errada.A cláusula select equivale à projeção da álgebra relacional, pois é neste mo-

mento da consulta que as colunas que aparecerão na resposta serão escolhidas.

63. Errada.A cláusula where equivale à seleção da álgebra relacional, pois é neste mo-

mento da consulta que as linhas que aparecerão na resposta serão escolhidas.

1.4. Transações

64. Errada.O início da afirmativa está correto. No entanto, a técnica controle de concor-

rência baseado em ordenamento de registro de timestamp não utiliza bloqueio.


142

ELSEVIER

65. Certa.A primeira parte da questão está de acordo com Navathe e Elmasri (2011, p.

509). Os autores afirmam que quando transações estão sendo executadas concor-rentemente e de modo entrelaçado, a ordem de execução das operações das várias transações é conhecida como escalonamento (schedule). Dois escalonamentos são considerados seriais quando as operações de cada transação são executadas em série, consecutivamente, sem quaisquer operações entrelaçadas as outra transa-ção. Um escalonamento é serial se, para todas as transações T participantes do escalonamento, todas as operações de T forem executadas consecutivamente no escalonamento; caso contrário, o escalonamento é dito não-serial. Um escalona-mento S de n transações é seriável (ou serializável) se for equivalente a algum escalonamento serial das mesmas n transações. A segunda parte da questão abor-da de maneira correta dois casos de necessidade de sincronismo entre transações aninhadas. Esse recurso é necessário para que uma transação não interfira na outra quando executas de modo entrelaçado. Korth, Silberschatz e Sudarshan (2006, p. 139), afirmam que o acesso a recursos compartilhados entre transações aninhadas deve obedecer as seguintes regras de sincronização:

T1 Read(tupla(i)) e T2 Read(tupla(i)): a ordem não importa.T1 Read(tupla(i)) e T2 Write(tupla(i)): a ordem importa.T1 Write(tupla(i)) e T2 Read(tupla(i)): a ordem importa.T1 Write(tupla(i)) e T2 Write(tupla(i)): a ordem importa caso haja outra

operação de leitura no mesmo schedule.

66. Certa.Apesar do gabarito final ter considerado a afirmativa correta, a questão tem

um problema. Segundo Navathe e Elmasri (2011, p. 527), no protocolo two-phase locking (bloqueio em duas fases) uma transação pode ser dividida em duas fases: uma fase de expansão ou crescimento (primeira), durante a qual novos bloqueios em itens podem ser adquiridos, mas nenhum pode ser liberado; e uma fase de en-colhimento (segunda) durante a qual os bloqueios existentes podem ser liberados, mas nenhum novo bloqueio pode ser adquirido. O autor é bem claro em afirmar “liberação de bloqueios”, que pode ocorrer devido a um comando “commit” ou um “rollback”. No entanto, o enunciado usa o termo “confirmados”, passando a impressão que a única maneira de liberar um bloqueio é dando o comando “com-mit”. Foram montados recursos com a alegação supracitada para a mudança de gabarito, mas a banca ignorou.

67. Errada.De fato a transação T2 pode ver os writes incrementais de T1. No entanto,

esse enfoque aumenta a concorrência do sistema.


143

68. Certa.A questão aborda de maneira correta o conceito de atomicidade abrangendo

várias transações.

Propriedades das Transações (ACID) (Korth, Silberschatz e Sudarshan, 2006, p. 409):

• Atomicidade: uma transação é uma unidade de processamento, é rea-lizada integralmente ou não é realizada.

• Consistência: uma transação leva um banco de dados de um estado consistente para outro estado consistente.

• Isolamento: uma transação deve parecer como se estivesse sendo exe-cutada isoladamente.

• Durabilidade: as alterações aplicadas a um banco de dados por meio de uma transação confirmada (commited) devem persistir no banco de dados.

69. Certa.Quando uma transação viola qualquer restrição de integridade, o SGBD

executa rollback da transação evitando que o banco de dados passe para um estado inconsistente.

70. Certa.Todo Sistema Gerenciador de Banco de Dados deve possuir um módulo de

gerência de transações que garanta as propriedades ACID.

71. Errada.As propriedades dos sistemas de banco de dados conjuntamente denominadas

ACID são atomicidade, consistência, isolamento e durabilidade. No enunciado faltou a propriedade atomicidade.

72. Errada. Os conceitos estão invertidos, o correto é: quando mudanças causadas por

uma transação abortada são desfeitas, houve o rolled back da transação; enquanto uma transação completada com sucesso a transação foi commited.

73. Certa.A afirmativa está correta de acordo com Korth, Silberschatz e Sudarshan

(2006, p. 412).


144

ELSEVIER

Estados de uma Transação (Korth, Silberschatz e Sudarshan, 2006, p. 412):• Ativa: estado inicial.• Parcialmente confirmada: depois que a instrução final foi executada.• Falha: depois da descoberta que a transação não pode mais prosse-

guir.• Abortada: depois que a transação foi revertida.• Confirmada: após o término bem-sucedido.

74. Errada.Existem apenas dois tipos de lock: shared lock ou um exclusive lock.

75. Certa.O nível de isolamento de uma transação pode causar problemas de incon-

sistências. De fato, o nível de isolamento “READ UNCOMMITED” (leitura não confirmada) pode causar o problema denominado “dirty read” (leitura suja).

Níveis de Isolamento de Transações:• SERIALIZABLE: uma transação é totalmente isolada das outras.

Caso a transação tenha comandos DML que tentem atualizar dados não gravados de outra transação, essa transação não será efetuada.

• REPEATABLE READ: os dados podem ser lidos mais de uma vez, e se outra transação tiver incluído ou atualizado linhas e estas forem gravadas no banco de dados entre uma e outra leitura dos dados, então os dados retornados da última busca serão diferentes dos dados da busca anterior. Esse efeito é conhecido como leitura fantasma.

• READ COMMITED: caso a transação utilize comando DML que precise do bloqueio de linhas que outras transações estão utilizando, a operação somente será concluída após a liberação da linha da outra transação.


145

• READ UNCOMMITED: serão lidos conteúdos não gravados ainda pelo banco de dados (transações passíveis de ROLLBACK). Há um enorme risco nessas operações, visto que o usuário que está bloqueando a infor-mação pode descartá-la. Esse efeito é conhecido como leitura suja.

Problemas de Consistência em Transações:• Leitura Suja: leitura de dados não confirmados de uma linha existen-

te, podendo ocasionar a leitura de uma informação nunca confirma-da.

• Leitura Não-Repetida: duas leituras de dados na mesma transação não se repetem. Na segunda leitura, dados não existem ou foram mo-dificados.

• Leitura Fantasma: na releitura de um conjunto de dados, surgem no-vas informações no conjunto.

• Perda de atualização: duas transações que ocorrem simultaneamente atualizam o mesmo dado. Isto pode ocorrer em uma sequência segun-do a qual uma das atualizações é perdida.

Problemas de Consistência versus Níveis de Isolamento de Transações:

Perda de Atualização

Leitura Suja

Leitura Não-Repetida

Leitura Fantasma

READ UNC0MMITTED

Não Permite Permite Permite Permite

READ C0MMITTED

Não Permite Não Permite Permite Permite

REPEATABLE READ

Não Permite Não Permite Não Permite Permite

SERIALIZABLE Não Permite Não Permite Não Permite Não Permite

1.5. Arquitetura de Banco de Dados e Bancos de Dados Distribuídos

76. Errada.Segundo Navathe e Elmasri (2011, p. 23), a arquitetura em três esquemas

tem por objetivo separar o usuário da aplicação do banco de dados físico, no entanto, a maioria dos SGBDs não separa completamente os três níveis, mas suporta essa arquitetura de alguma forma.


146

ELSEVIER

A Arquitetura em Três Esquemas é Organizada em Três Níveis:• Nível Interno ou Físico: descreve a estrutura de armazenamento físico

do banco de dados.• Nível Conceitual: descreve a estrutura de todo o banco de dados para

a comunidade de usuários.• Nível Externo ou Visão: cada esquema externo descreve a parte do

banco de dados que um dado grupo de usuários tem interesse e oculta o restante do banco de dados desse grupo.

77. Certa.A questão cita corretamente os dois tipos de interação do usuário com o

banco de dados que ocorre no nível externo ou visão.

78. Errada.Independência de dados consiste da capacidade de mudar o esquema em um

nível do sistema de banco de dados sem que ocorram alterações do esquema no próximo nível mais alto. Independência lógica de dados é a capacidade de alterar o “esquema conceitual” sem mudar o “esquema externo” ou os programas.

79. Errada.A independência de dados é organizada em duas categorias, a questão cita

a independência lógica de dados e por isso está errada.

Independência de Dados na Arquitetura em Três Esquemas:• Independêncialógicadedados:éacapacidadedealteraroesquema

conceitual sem mudar o esquema externo ou os programas.• Independênciafísicadedados:éacapacidadedealteraroesquema

interno sem mudar o esquema conceitual.

1.6. Arquitetura OLAP

80. Errada.Tabela de Fatos é a tabela central do projeto dimensional. Armazena medi-

ções numéricas do negócio. Possui chaves de múltiplas partes, cada chave é uma chave externa para uma tabela de dimensão. Tabelas de Dimensões representam os contextos relevantes para a análise de um fato. No modelo snowflake (flocos de neve) há um grau de normalização maior que no esquema star-schema (estrela). No modelo snowflake as dimensões são normalizadas até a 3FN (terceira forma normal). No entanto, os fatos existirão apenas nas tabelas de fatos.


147

Tipos de Medidas em Tabelas Fato:• Aditivas: são as mais frequentes e são obtidas por meio da soma de

valores gerados pela seleção de membros das dimensões. Exemplo: lucro líquido;

• Semi-aditivas: são medidas obtidas a partir da soma de apenas par-tes de suas dimensões. Exemplo: quantidade em estoque (não faz sen-tido somá-la através da dimensão tempo);

• Não-aditivas: são medidas que não podem ser somadas através de nenhuma de suas dimensões. O exemplo mais comum desse tipo de medidas são valores percentuais.

81. Errada.Em banco de dados de apoio à decisão, como por exemplo, um Datawarehou-

se (DW), a preocupação com a integridade dos dados ocorrerá apenas durante a carga dos dados no DW, durante a interação com os usuários essa preocupação não existe, pois os usuários só podem selecionar dados para a montagem de re-latórios, não é previsto atualização, inserção ou deleção de dados. A redundância neste ambiente é muito comum para a melhoria do desempenho das consultas.

82. Certa.Em uma arquitetura OLAP, os dados que compõem o Datawarehouse são

oriundos dos sistemas operativos. Esses dados passam por um processo de extra-ção, transformação e carga (extract transform load – ETL) para comporem o DW. De fato, a armazenagem desses dados no DW permite ao usuário usar consultas pré-montadas ou interativas (ad-hoc) e descobrir tendências e fatos relevantes.

83. Certa. A questão aborda de maneira correta as atividades desempenhadas pelas

ferramentas ETL.

84. Certa. A definição de Inmon (1999, p. 13) ampara a afirmativa da questão, pois

segundo o autor o DW fornece dados integrados e históricos.

85. Errada.Os dados do DW são não-voláteis, ou seja, não são alterados pelo usuário.


148

ELSEVIER

86. Errada.A operação de drill down parte do maior grão (ano, por exemplo) para um

grão menor (semestre, trimestre ou mês, por exemplo). A operação citada na questão é o drill up ou roll up.

87. Certa.A questão apresenta uma definição correta para business inteligence (BI), a

arquitetura OLAP é um exemplo de aplicação desse princípio. Nesta arquitetura os dados dos sistemas operativos são tratados e armazenados em um datawarehouse para a geração de relatórios analíticos para o suporte à decisão.

88. Errada.O modelo star schema não é normalizado, o modelo dimensional que possui

suas dimensões normalizadas até a 3FN é o snowflake.

89. Errada.O modelo flocos de neve (snowflake) possui suas dimensões normalizadas

até a 3FN, e, por isso, diminui a redundância.

C a p í t u l o 2

Gabaritos de Desenvolvimento de Sistemas Web

2.1. Linguagem Java

2.1.1. Sintaxe, características e APIs

90. Errada.A linha 5 do código não será executada. Ocorrerá um exceção (java.lang.

NullPointerException) na linha 4. A variável “j” é do tipo primitivo “int”. Des-tarte, não pode receber de valor null.

91. Errada.O primeiro laço for do programa percorre os quatro primeiros itens do array

“m”. Caso seus valores sejam ímpares, eles são somados aos elementos do array “n” de mesmo índice. Assim, após a execução do primeiro laço, os valores do array “m” seriam:

m = {1, 2, 5, 4, 5}O segundo laço soma os valores de todos os elementos do array “m”. Desta

forma, teríamos 1 + 2 + 5 + 4+ 5 = 17.

92. Certa.Na linguagem Java, há dois tipos de ponto flutuante: float e double. Este

tem precisão de 32 bits enquanto aquele tem precisão de 64 bits.

93. Certa.Em Java os comentários de uma só linha são definidos por//e não por \\.


150

ELSEVIER

Há duas outras modalidades de comentários em Java.a)Várias linhas: /*...Comentário*/b) Comentários JAVADOC/**.../Esse padrão de comentário é lido pela ferramenta JAVADOC e convertido

em arquivo HTML para gerar documentação de código.

94. Certa.Todas as 40 palavras reservadas listadas fazem parte da linguagem Java.

Tecnicamente, true e false são literais booleanos. Da mesma forma, null é chamado literal nulo. De qualquer forma, todos os três podem ser citados como palavras-chave. A tabela abaixo contém todas as 53 palavras reservadas da linguagem:

abstract class extends implements strictfp import

transient static char while break null

enum catch native synchronized boolean assert

new interface long instanceof private case

throws return throw volatile default float

public short final double byte else

true switch finally void package super

const try false int for if

protected goto do this continue

95. Errada.Quando o recurso esperado for disponibilizado a thread retorna ao estado

pronto (Runnable) e deve aguardar que o escalonador a escolha novamente para execução.

Estados de uma Thread, segundo Sierra e Bates (2003, p. 485):• New: este é o estado da thread após sua instanciação. Neste ponto o mé-

todo start() ainda não foi invocado. A thread não é considerada viva.

Capítulo 2 I Gabaritos de Desenvolvimento de Sistemas Web

151

• Runnable: este é o estado no qual a thread está pronta para executar, mas o escolonador ainda não a selecionou para execução. Uma thread entra neste estado quando o método start() é chamado. Ela também pode retornar a este estado após passar pelos estados blocked/waiting/sleeping. Neste momento a thread é considerada viva.

• Running: a thread está efetivamente em execução. Ocorre quando o escalonador seleciona uma thread para executar.

• Waiting/Blocked/Sleeping: este é o estado de uma thread quando ela não está disponível para execução. Está certo que há três estados com-binados em um único estado, mas todos eles têm algo em comum: a thread continua viva. Em outros termos, ela não está no estado run-nable, mas pode retornar a ele caso um evento particular ocorra. Ela pode estar bloqueada aguardando por um recurso, pode estar dormin-do a pedido de outra thread ou simplesmente aguardando haja vista que seu método run() ordenou esta ação.

• Dead: uma thread é considerada morta quando seu o método run() completa a execução. Neste ponto, não há como voltar à vida, ainda que seu método start() seja chamado.

96. Errada.A execução do código não provoca erro em tempo de execução. A linha de

comando java Reverso 5 joão maria josé executa o programa Reverso com quatro parâmetros de linha de comando do tipo String: “5”, “joão”, “maria” e “josé”.

A execução se inicia na linha 16, no método main. A linha 17 transforma o primeiro argumento de linha de comando (“5”) em número inteiro e o atribui à variável quantos. Na linha 18 é impressa a mensagem: “Entre com uma sequência de 5 nomes”. A linha 19 invoca o método out, que está definido na linha 5.

O método out inicia sua execução. Na linha 9 há uma chamada a in.readline(). Neste ponto é solicitada entrada de dados do usuário via console. O programa fica parado aguardando a digitação. Logo, a linha de comando especificada no item não provoca erro de runtime.

97. Errada.O referido item não apresenta erro de compilação.

2.1.2.Orientação a objetos com Java

98. Errada.As classes Conta e Poupança implementam sobrecarga de métodos, um tipo

de polimorfismo estático.


152

ELSEVIER

Podemos classificar o polimorfismo sob diversas óticas. Em Java, descre-vemos as modalidades estática e dinâmica da seguinte forma:

• Polimorfismo estático: é também conhecido por sobrecarga (overlo-ading). Ocorre quando há métodos com mesmo nome, mas com ar-gumentos diferentes. Eles podem estar em uma única classe ou em classes distintas, desde que haja relação de herança entre elas.

• Polimorfismo dinâmico: recebe o nome de sobrescrita (overriding). Ocorre quando métodos de uma subclasse com mesmo nome, argu-mentos e tipo de retorno da superclasse redefinem o comportamento do método desta superclasse.

99. Errada.Um atributo definido como final recebe uma única atribuição de valor e se

mantém constante, isto é, seu valor não pode ser modificado ao longo do pro-cessamento.

A palavra reservada final pode ser aplicada em três contextos:• Atributos: indica que o atributo é uma constante. Após atribuído, o

valor não pode ser modificado.• Métodos: indica que o método não pode ser sobrescrito (overriding)

por uma subclasse.• Classes: especifica que a classe não pode ser estendida, isto é, a classe

não pode ter subclasses.

100. Errada.O mecanismo de herança de classe é “bloqueado” por meio do uso do modifi-

cador final na definição da classe. Caso o modificador seja utilizado na definição de um método, ocorre que a sobrescrita é “bloqueada”. O código-fonte apresen-tado não possui exemplo de herança nem tampouco de redefinição de atributos.

101. Errada.Os moderadores de acesso existentes em Java são: public, package ou

friendly, protected e private. O moderador package é o padrão e não precisa ser declarado explicitamente. Ele é o valor assumido caso não haja outra declaração de moderador de acesso.

O termo mais usual para denotar restrições de acesso a métodos e atributos é modificador de acesso e não moderadores de acesso.

102. Errada.Uma classe abstrata não pode ser instanciada.


153

Uma classe abstrata define um modelo contendo implementação incompleta, isto é, funcionalidades genéricas a serem implementadas por classes derivadas. Não possui instâncias e, normalmente, contém métodos abstratos, cabeçalhos de método sem um corpo de comandos definidos.

103. Errada.As variáveis de classe iniciam pelo modificador static e não private como

disposto no item. As definições de variável de instância (possui vários valores para cada instância da classe) e variáveis de classe (há apenas uma cópia da classe em existência, independentemente de quantas vezes ela é instanciada) estão corretas.

104. Certa.O construtor é executado sempre que um novo objeto é criado. De fato, ele

é utilizado para realizar inicializações. Possui o mesmo nome da classe na qual reside e tem estrutura sintática similar à de qualquer outro método, exceto pelo fato de que não possui tipo de retorno.

Toda classe Java possui ao menos um construtor. Se nenhum construtor for explicitamente definido pelo programador, um construtor padrão, que não recebe argumentos, é incluído automaticamente pelo compilador Java.

105. Errada.Não é necessário que haja herança múltipla para que subclasses de uma

classe abstrata possam ser instanciadas.O item estaria corretamente escrito da seguinte forma: “Uma classe abstrata

não pode ser diretamente instanciada. Subclasses derivadas por herança de classes abstratas, chamadas de classes concretas, podem ser instanciadas.”

106. Errada.São quatro os modificadores de acesso que implementam encapsulamento

em Java: public, protected, private e package (friendly). Assume-se a visibilidade package quando nenhum modificador de acesso é declarado explicitamente. To-dos eles definem regras de acesso e realizam alguma forma de encapsulamento.

A tabela a seguir lista os modificadores e suas respectivas possibilidades de acesso:


154

ELSEVIER

Modificador Universo Subclasse Mesmo pacote Mesma classe

private Sim

default Sim Sim

protected Sim Sim Sim

public Sim Sim Sim Sim

107. Certa.O termo “anulado” usado na questão se refere à sobrescrita de métodos.

Em Java, a visibilidade do método que sobrescreve não pode ser mais restritiva que a visibilidade do método sobrescrito. Destarte, um método público em uma superclasse só pode ser sobrescrito por outro método público em uma subclasse.

108. Errada.A execução do código não resultará em erro. A classe p1 é instância da sub-

classe Poupanca. Esta, por sua vez, estende a classe abstrata Conta e sobrescreve o método saldoConta().

O código realiza conversão explícita (casting) para Poupanca. Embora des-necessária, esta ação não causa erro.

109. Certa.A linguagem Java implementa apenas a herança simples.

2.2. Padrões de Projeto

110. Certa.Padrões de projeto (Design Patterns) descrevem soluções para problemas

recorrentes no desenvolvimento de software.

111. Certa.De fato, os padrões de projeto utilizam conceitos de orientação a objetos,

como herança e polimorfismo, para prover soluções de software com alto poten-cial de reuso.

São 23 os padrões de projeto da conhecida “Gangue dos Quatro”. Trata-se dos autores do livro Design Patterns: Elements of Reusable Object-Oriented SoftwareGamma et al., 1995) e que popularizou o movimento em torno dos padrões. Eles foram categorizados em três grupos: (de criação, estruturais e comportamentais. A tabela a seguir lista todos os 23 padrões, por categoria:


155

Criação Estruturais Comportamentais

Singleton Adapter Chain of Responsibility

Abstract Factory Bridge Command

Factory Method Composite Interpreter

Builder Decorator Iterator

Prototype Façade Mediator

Flyweight Memento

Proxy Observer

State

Strategy

Template Method

112. Certa.O padrão de projeto Singleton garante a ocorrência de um único objeto de

uma classe e provê um ponto de acesso global a ele.

113. ErradaO termo “padrões de projeto” se refere a qualquer solução para problemas

recorrentes no desenvolvimento de sistemas de software. Não é obrigatória a utilização da programação orientada a objetos para que se aplique o uso de padrões de projeto, embora seja a forma mais comum. Um programa escrito em linguagem C pode adotar padrões a despeito de utilizar programação estruturada.

114. Certa.O Adapter, assim como Bridge, Composite, Decorator, Façade, Flyweight

e Proxy são padrões de projeto classificados como estruturais. O objetivo deste padrão é converter uma interface de uma classe em outra, de modo que classes com interfaces incompatíveis possam colaborar.

115. Errada.A descrição do item se refere ao padrão de projeto Façade.

116. Errada.O padrão de projeto Factory Method pertence à família de padrões de criação

e não de comportamento. Ademais, a descrição do item diz respeito ao padrão Chain of Resposibility.


156

ELSEVIER

117. Errada.O padrão de projeto “que fornece uma interface para a criação de famílias

de objetos relacionados ou dependentes sem especificar suas classes concretas” é o Abstract Factory e não o Factory Method.

118. Errada.O padrão de projeto que “separa a construção de um objeto complexo de sua

representação para criar representações diferentes com o mesmo processo” é o Builder e não o Adapter.

119. Errada. De fato, o padrão façade unifica interfaces de um sistema tornando-o mais

simples de entender e utilizar. Além disso, é correto dizer que ocorre redução de dependências em relação às características internas de uma biblioteca de software. O padrão também viabiliza a criação de pontos de entrada para acesso a um subsistema. Entretanto, não está previsto o encapsulamento de todas as interfaces públicas de um sistema. Apenas interfaces que fazem sentido para um determinado serviço de negócio é que são encapsuladas.

2.3. Arquitetura Java EE

2.3.1. JSP/Servlets, EJB e Servidores de Aplicação

120. Certa.As tecnologias JSP e Servlet são voltadas para criação de páginas web di-

nâmicas. Todos os arquivos JSP são compilados e transformados em servlets, classes java capazes de gerar páginas HTML. O container TOMCAT permite a execução de JSP e servlets.

121. Certa.O WAR (Web Archive) encapsula uma aplicação web. Trata-se de um arquivo

no formato zip que pode conter contém páginas JSP, páginas HTML, servlets, imagens, bibliotecas.(jar) e um descritor da aplicação (WEB.XML). Uma vez implantado no container JSP ele torna disponível a aplicação ao usuário final.

122. Certa.As tecnologias JSP/Servlet e JSF são utilizadas na camada web. A camada

de negócio engloba a tecnologia EJB (Enterprise Java Beans).


157

123. Errada.Em se tratando de tecnologia, apontar versões de especificações não é boa

ideia. As mudanças são rápidas. Em 2010, quando a prova foi aplicada, a versão vigente do EJB era a 3.1, definida na JSR 318. Esse já é um erro na questão. Entretanto, mais importante, é a ideia dos EJBs. Eles são tecnologia utilizada no lado servidor e não no lado cliente como foi definido nesse item.

124. Certa.Segundo a JSR 907 (Java Transaction API), “a JTA especifica interfaces

de alto nível entre o gerenciador de transações e as partes envolvidas em um sistema de transação distribuído”. Essas partes são a aplicação, o gerenciador de recursos e o servidor de aplicação.

125. Errada.Mais de uma servlet pode operar como controladora em uma aplicação.

126. Errada.Além da URL de localização do arquivo TLD, é necessário especificar um

prefixo para identificar o uso das tags ao longo do documento JSP.

Sintaxe para declaração de tags personalizadas:<@taglib uri=”localizacao_arquivo_tld” prefix=”prefixoTag”>

127. Errada.É por meio do objeto sessão (session object) que são rastreadas as informações

de um cliente específico.

128. Errada.O Tomcat é exemplo de servidor de com diretórios bin e webapps. Ele é

responsável por gerenciar requisições recebidas de clientes.

De acordo com a JSR 315 (Servlet Specification), servlets são componentes web – gerenciados por um container – responsáveis por gerar conteúdo dinâ-mico. Assim como outras tecnologias Java baseadas em componentes, servlets são independentes de plataforma.

129. Certa.Embora o primeiro programa contenha apenas código HTML, pode se tratar

de um arquiv o JSP. A página possui campos para preenchimento de informações de descrição de um produto, valor de compra e de venda. Estas informações são envia-das, via método post, à servlet VendaServlet quando o botão Executa é pressionado.


158

ELSEVIER

O segundo programa (VendaServlet) recupera as informações do produto a partir do objeto que encapsula a requisição. Ato contínuo, é feito cálculo do lucro (ou prejuízo) e gerado código HTML para apresentar esse valor ao usuário.

130. Errada.O nome da função pode ser diferente do nome do método da classe.

Exemplo de declaração de função em arquivo descritor de biblioteca de tags (TLD):

<function>

<name>total</name>

<function-class>br.gov.mpu.util.Funcoes</function-class>

<function-signature>double calcularTotal(double) </function-signature>

</function>

Note que o nome da função a ser utilizada por meio da expressão JSP (total) é diferente do nome do método estático definido na classe Funcoes (calcularTotal).

131. Certa.As expressões JSP são traduzidas para chamadas a out.print() no método

_jspService da servlet gerada.

132. Errada.O método forward tem por objetivo repassar uma requisição de uma servlet

para outro recurso – outra servlet, página JSP ou HTML. Assim, a linha “rd.forward(request, response)” poderia ser usada pela MpuServlet1 para executar a MpuServlet2. Entretanto, imediatamente antes dessa linha, há uma chamada a “response.flushBuffer()”.

De acordo com a JSR 315, que especifica o comportamento de servlets, o método forward da interface RequestDispatcher só pode ser executado quando nenhum dado foi enviado ao cliente. A chamada a flushBuffer() envia dados ao cliente. Por consequência, a exceção IllegalStateException será lançada e a servlet MpuServlet2 não será executada.

133. Certa.Além das possibilidades especificadas na questão, as action tags permitem

ainda a inclusão dinâmica de arquivos. A tabela a seguir lista as tags de ação e uma breve descrição:


159

JSP tag Descrição

<jsp:include> Inclui um arquivo quando a página é carregada.

<jsp:useBean> Declara ou inicializa um javabean

<jsp:setProperty> Atualiza o valor de uma propriedade de um javabean.

<jsp:getProperty> Recupera e apresenta o valor de uma propriedade de um javabean.

<jsp:forward> Transfere o controle para uma nova página.

<jsp:plugin> Gera código HTML para carregamento de applets. O código gerado é específico para o navegador que solicitou a página.

134. Errada.Na arquitetura J2EE, a persistência dos beans de entidade (Entity Beans)

pode ser gerenciada de duas formas:

Bean (BMP) Contêiner (CMP)

O desenvolvedor cuida do tratamento relativo à persistência

O contêiner implementa a persistên-cia de forma automática, utilizando mecanismo de mapeamento objeto relacional.

Queries são escritas pelo desenvolvedor e podem ser otimizadas.

O desempenho das consultas não pode ser otimizado haja vista que toda a persitência é de responsabilidade do contêiner.

Assim, se a persistência é gerenciada pelo contêiner, é dele a responsabilidade por gerar código JDBC para interação com banco de dados.

135. Errada.A plataforma padrão, também conhecida como implementação de referên-

cia, adotada pela Oracle (Sun) no Java EE 6 é o Glassfish e não o JBOSS como sugere o item.

136. Errada.O Java EE 6 introduz o conceito de perfis como uma forma de reduzir o ta-

manho da plataforma Java EE e torná-la mais alinhada ao público que a utiliza. Perfis são, portanto, customizações da plataforma Java EE projetadas para uma classe específica de aplicações.


160

ELSEVIER

O Web Profile é o primeiro perfil definido para a plataforma Java EE 6. Trata-se de um subconjunto da plataforma Java EE para desenvolvimento de aplicações Web. É o único perfil definido até o momento. Não existe o perfil Application Server na versão Java EE 6, nem tampouco em versões anteriores.

137. Certa.O referido item apresenta características da especificação EJB 3.1.

Principais novidades da especificação EJB 3.1: • Uso opcional de interfaces• Surgimento dos Singleton Beans – beans de sessão que possuem uma

única ocorrência no servidor de aplicação.• EJB Timer – melhorias na facilidade de agendamento de execução de

beans de sessão com interface similar à do cron.• EJB na camada Web – permite-se o uso de EJBs em container de Servlets.• Beans de Sessão assíncronos – alternativa ao JMS.

138. Certa.

De acordo com a Oracle, são vantagens do facelets: • maior modularidade, com o uso de templates e componentes compostos• compilação mais rápida, se comparada com JSP• Alto desempenho na renderização das páginas• Extensibilidade de componentes por meio de customizações

2.3.2. JSF

139. Errada.A descrição apresentada pela questão é de Facelets e não de Portlets.

De acordo com a JSR 168 (Portlet Specification), portlets são componentes web – como servlets – projetados para composição de páginas. Cada portlet produz um fragmento de página que é combinado com os fragmentos de outros portlets para compor páginas de um portal.

140. Certa.Além de componentes, eventos e navegabilidade, o JSF provê suporte padrão

a conversores, validadores e listeners.

141. Errada.Os validadores de dados padrão do JSF são utilizados apenas no lado servidor

(server-side).


161

142. Certa.A partir da versão 2.0, o JSF passou a suportar AJAX de forma nativa. Por

meio da tag <f:ajax> é possível realizar solicitações HTTP assíncronas.

143. Certa.Uma das principais características do JSF é o fato de ser orientado a eventos.

Além do suporte a mecanismos para conversão, validação, execução de lógica de negócios e controle de navegação, há também suporte à internacionalização de aplicações e criação de novos componentes.

2.3.3. JPA/Hibernate

144. Certa.A ideia inicial do JPA (Java Persistence API – API de Persistência Java)

era simplificar a especificação EJB no que diz respeito aos beans gerenciados pelo container (CMP). Essa era uma especificação bastante “pesada” para im-plementação de mapeamento objeto relacional (ORM) e necessitava evolução. No mercado, surgiram frameworks ORM mais leves como Hibernate, Oracle Toplink e Objetos de Dados Java (JDO) e que rapidamente se tornaram líderes nesse segmento. As ideias desses frameworks foram utilizadas para guiar a especificação JPA.

145. Certa.O Hibernate é uma camada de software capaz de traduzir um modelo orienta-

do a objetos em um modelo baseado em tabelas de banco de dados. Ele simplifica o desenvolvimento de soluções que dependem de inclusões, alterações, exclusões e consultas a dados. Suporta polimorfismo, herança e encapsulamento. Tem código aberto e é distribuído sob licença LGPL.

146. Errada.Há três formas de se realizar consultas utilizando Hibernate:a) linguagem de consulta HQL (hibernate query language)b) SQL nativoc) API de consulta por critério (Criteria API)Ademais, vale ressaltar que a realização de consultas sobre classes de per-

sistência aumenta a distância entre regras de negócio e o banco de dados – em vez de diminuir, como preconiza a questão.


162

ELSEVIER

147. Errada.A tabela a seguir sumariza a associação adequada entre os elementos e o

tipo de arquivo Hibernate:

configuração mapeamento

propertysession-factorymapping

hibernate-mappingclassgeneratorproperty

148. Errada.A principal característica do Hibernate é a transformação de classes em

Java para tabela de dados. Na questão “classes em Java” e “tabela de dados” aparecem invertidos.

149. Errada.O Hibernate trabalha com esquema de cache. Faz-se, pois, necessário utilizar

métodos flush e clear para descarregar para banco de dados objetos mantidos no cache.

Os métodos supracitados não são chamados no código apresentado na questão. Em algum momento da execução, será gerada a exceção java.lang. OutOfMemoryError.

2.4. Desenvolvimento Web (lado cliente)

150. Certa.O W3C, nas orientações para acessibilidade de conteúdo Web, dispõe que

“deve-se utilizar folhas de estilho para controlar layout e apresentação” de páginas HTML. Dispositivos para leitura em braille e leitores de tela são beneficiados pelo uso de folhas de estilo em detrimento a tags <table>. Eles têm menos problemas na leitura haja vista que ela ocorre de forma lógica e sequencial.

151. Errada.No tocante à instanciação de objetos, Java, C++ e Javascript são seme-

lhantes. Todas usam o operador new. Por outro lado, em javascript não existe o conceito de classe. Pode-se utilizar funções para simular classes.

Exemplo de uso de função para criar pseudo-classe em javascriptfunction Pessoa(n) {this.sexo = “Masculino”;this.idade = n;}var marcelo = new Pessoa(30);


163

152. Errada.Código javascript escrito na seção <body> de uma página HTML é execu-

tado à medida que a página é carregada. Assim, ao executar a linha document.title=‘Título’, o título da janela é modificado de “Página 1” para “Título”.

153. Certa.De acordo com Goodman (1999, p.4), DHTML é termo usado para designar

uma coleção de tecnologias usadas em conjunto para criar sítios animados e interativos na web por meio da combinação de linguagem de marcação estática (como HTML), linguagem de script (como javascript) e linguagem de definição de apresentação (como CSS), aliado a um modelo de objeto de documentos (DOM).

154. Errada.O código que define os estilos pode ser armazenado fora do documento HTML,

em arquivo à parte. Basta referenciá-lo da seguinte forma:<link rel=”stylesheet” type=”text/css” href=”estilo.css”/>

Onde estilo.css é o nome do arquivo que contém o código que define os estilos. A declaração acima deve estar entre as tags <head> </head> do documento HTML.

155. Errada.A definição do rótulo do botão é feita por meio do atributo “value”. Para

que o rótulo fosse apresentado conforme descrito no item, o código deveria ser escrito da seguinte forma:

<input type=”submit” name=”Submeter” value=”Submeter”/>

156. Certa.A linha 3 do código em tela descreve o código javascript executado quando

ocorre submissão do botão Submeter. Trata-se do evento onSubmit. Este código especifica que o campo primeiro é opcional e que o campo idade deve ser numé-rico. Em seguida, a função verifica é invocada.

A linha 9 itera sobre cada elemento do formulário. O sexto elemento é o campo idade. Quando o código da linha 12 é executado para este campo, o condicional if é avaliado como true haja vista que o campo não foi marcado como opcional e não foi preenchido pelo usuário. Então, a variável empty_fields é atualizada.

A linha 30 verifica se a variável empty_fields não está preenchida. Não é nosso caso, por conta do campo idade.

Nas linhas 31 a 36 é montada uma mensagem para apresentação ao usuário. A linha 37 mostra a mensagem pop-up com a listagem de problemas encontrados.


164

ELSEVIER

Finalmente, a linha 38 retorna o valor false. Desta feita, os dados do formu-lário não são enviados ao servidor.

157. Errada.A página contém erros básicos de formação. Por exemplo, é obrigatória a

declaração de DOCTYPE bem como a existência dos elementos <html> <head> e <title>.

Segundo o W3C, as seguintes regras devem ser obedecidas para que um documento seja XHTML seja bem formado:

• Elementos devem estar corretamente aninhados• Atributos devem ser envolvidos por aspas simples ou duplas• Todas as tags devem ser escritas em letras minúsculas.• Elementos não-vazios devem ter tags de fechamento• Elementos vazios devem ser fechados com/> como em <br/> e <hr/>

158. Certa.Os atributos action, method e enctype fazem parte da especificação HTML

desde sua versão 2.0 (RFC 1866). A partir da versão 4, eventos como onsubmit, onkeyup e onclick também passaram a fazer parte da especificação.

159. Errada.O campo fone está definido na linha 12 do arquivo teste.html. Ele contém

um evento onblur associado. Este evento é disparado sempre que o campo perde o foco, por exemplo, quando o usuário pressiona a tecla Tab. Logo, o foco de entrada será direcionado para uma janela pop-up com os dizeres: “esqueceu o ddd?”

160. Errada.

Não existe o objeto XMLHttpResponse. Toda a comunicação assíncrona é implementada por meio do objeto XMLHttpRequest.

Garret (2005), quem definiu o termo AJAX, estabeleceu os seguintes rela-cionamentos entre as tecnologias:

• HTML ou XHTML e CSS para apresentação das informações.• Document Object Model (DOM) para interação dinâmica com as pági-

nas• XML e XSLT para intercâmbio e manipulação de dados.• XmlHttpRequest para comunicação assíncrona.• Javascript para ligar essas tecnologias.


165

161. Errada.Quem “apresenta a estrutura das páginas web como um conjunto de objetos

programáveis que pode ser manipulado com JavaScript” é o Document Object Model (DOM) e não o objeto XMLHttpRequest.

Segundo o W3C, o XMLHttpRequest é usado para enviar requisições HTTP e HTTPS a um servidor Web e para ler respostas a estas requisições e tratá-las por meio de um linguagem de scripts, como Javascript.

O W3C também oferece definição de DOM. Trata-se de uma interface inde-pendente de plataforma e linguagem de programação que permite que programas e scripts acessem e modifique, dinamicamente, o conteúdo, a estrutura e o estilo de documentos.

162. Certa.O mecanismo tradicional de funcionamento de uma aplicação web é baseado

em esquema síncrono: um formulário HTML é preenchido e submetido para processamento. Assim, uma requisição HTTP é enviada ao servidor web, pro-cessada e nova página HTML é enviada ao cliente. O usuário precisa aguardar o recarregamento da nova página para interagir com a aplicação. Com AJAX, não é necessário aguardar que a página seja recarregada para que nova interação seja realizada. Trata-se de um modelo assíncrono. Esta é uma das principais vantagens desta tecnologia.

163. Errada.O item apresenta dois erros:

a) Apenas o campo nome possui função javascript associada (onkeydo-wn). Assim, a janela pop-up não é apresentada para o campo hora.

b) A partir da versão 7.0, o Internet Explorer aderiu à especificação do W3C e passou a disponibilizar a mesma interface para uso do objeto XMLHttpRequest dos navegadores Firefox, Chrome, Opera e Safari. Antes, nas versões 5, 5.5 e 6 o acesso à interface XMLHTTPRequest era efetuado por meio de objetos ActiveX. Assim, caso um usuário esteja usando, por exemplo, o IE 6 e interaja com o campo nome, será apresentada uma janela pop-up com a expressão: “Seu browser não suporta Ajax!”.

164. Errada.A função ajaxFuncion() não utiliza o objeto XMLHttpRequest para realizar

chamadas a um servidor web. Todo o processamento fica no cliente e, portanto, nenhuma solicitação HTTP é enviada ao servidor.


166

ELSEVIER

2.5. Interoperabilidade de sistemas Web

2.5.1. XML

165. Errada.O atributo standalone tem como valor padrão “no”. É de escrita opcional

e indica se o documento possui elementos, atributos ou entidades definidos ex-ternamente.

Lista de possíveis atributos de uma declaração XML:

Nome É obrigatório? Descrição

version Sim Especifica a versão do padrão XML a qual o docu-mento obedece. O único valor possível é 1.0.

encoding Não Indica o conjunto de caracteres usados no docu-mento.

standalone Não Especifica se o documento possui elementos, atri-butos ou entidades definidos externamente. yes e no são os valores possíveis.

166. Certa.A questão trata das regras a serem verificadas para determinar se um docu-

mento é bem formado. O caso apresentado gera erro, haja vista que não há tag de fechamento para <ramal>.

Regras obedecidas por um documento XML bem formado:• Deve haver um elemento raiz• Todas as tags abertas devem ser fechadas• Não pode haver atributos repetidos dentro de um elemento• Valores de atributos devem ser envoltos por aspas simples ou duplas• Todos os elementos devem estar aninhados de forma consistente.

167. Errada.A linguagem XML é sensível ao caso (case sensitive), isto é, diferencia carac-

teres maiúsculos de minúsculos.

168. Errada.A questão é capciosa. Se pensarmos apenas nos primeiros caracteres usados

para escrever números romanos – I, V, X, L, C, D, M – todos são representados por meio da codificação de caracteres ISO-8859-1. Entretanto, lembremo-nos de números grandes como o 5000 e o 10000. Como são representados? Utiliza-se, respectivamente, um V e um X com uma barra horizontal em cima. Neste caso, não há representação na codificação ISO-8859-1.


167

169. Certa.O item descreve corretamente características da linguagem XML. Nessa

linguagem, atributos não podem existir isoladamente. Eles dependem de elemen-tos para existir. XSLT é uma linguagem para transformar documentos XML em outros documentos. Há dois mecanismos de processamento de arquivos XML: DOM e SAX. Eis um quadro comparativo entre eles:

DOM X SAX

DOM (Document Object Model) SAX (Simple API for XML)

Modelo Baseado em árvore Baseado em eventos

Uso de recursos Proporcional ao tamanho do do-cumento. Potencialmente pode utilizar muita memória.

Valor constante de uso de memória.

Aplicabilidade Ideal para manipulação do XML (inclusão, remoção de elementos)

Leitura sequencial de do-cumentos

170. Certa. XML Schema e DTD são linguagens que descrevem a estrutura de um do-

cumento XML. A gramática (esquema) gerada por essas linguagens especifica, em termos de metadados, elementos, atributos e os tipos de dados associados a eles. Embora utilizem sintaxe bastante diferente, ambos têm o mesmo objetivo: definir regras que determinam a validade de um documento XML.

171. Certa.De acordo com Fitzgerald (2003, p. 1), XSLT (eXtensible Stylesheet Language

Transformations) é uma linguagem que permite transformar documentos XML em novos documentos XML, em documentos HTML (Hypertext Markup Langua-ge), em documentos XHTML (Extensible HyperText Markup Language) e em documentos de texto puro. Trata-se, pois, de solução adequada para publicar dados de trâmites de processos, armazenados em XML, nos formatos HTML e TXT.

2.5.2. Web Services

172. Certa.

Segundo o W3C:SOAP é um protocolo projetado para troca de informações estruturadas em

ambiente descentralizado e distribuído. Utiliza tecnologia XML para definir um framework para troca de mensagens sobre diversos protocolos. É independente de linguagem de programação e qualquer outra semântica específica de imple-mentação. Foi criado a partir de premissas de simplicidade e extensibilidade.


168

ELSEVIER

173. Certa.A primeira linha indica que o código se trata de uma solicitação HTTP. A

segunda linha identifica um header do protocolo HTTP. Ela indica o endereço do servidor. A terceira linha contém um header chamado SOAPMethodName. Ele especifica o método invocado e nos permite identificar que a requisição está embasada no modelo de comunicação SOAP. Finalmente, os headers “content--type” e “content-length” nos indicam, respectivamente, o tipo de documento transportado (XML) e seu tamanho em bytes (1234).

174. Errada.O modelo Request/response é um dos cenários de uso de Web Services lista-

dos pela W3C. SOAP é o protocolo usado para transporte de informações neste cenário. Trata-se do padrão mais utilizado.

175. Errada.Não há referência ao endereço de destino no envelope da mensagem SOAP.

SOAP independe do mecanismo de transporte utilizado. O protocolo HTTP é quem tem a atribuição de especificar o endereço de destino.

Partes de um documento SOAP, segundo o W3C:• Envelope: elemento raiz de uma mensagem SOAP. Define o conteúdo

da mensagem. É obrigatório.• Header: mecanismo de extensão que permite especificar informações

de controle nas mensagens SOAP. É opcional.• Body: possibilita a utilização de informações específicas de aplicação

dentro da mensagem SOAP. É obrigatório.

176. Errada.O corpo de uma mensagem SOAP pode conter tanto uma requisição quanto

uma resposta.

177. Errada.WSDL é uma linguagem baseada em XML (e não em UDDI e RPC como

descreve o item).

178. Certa.Trata-se de questão que teve seu gabarito alterado de “errado” para “certo”.

A própria banca comentou o item: “O trecho de código apresentado pode figu-rar como parte de uma especificação na linguagem WSDL. Além disso, as duas afirmações do programador estão corretas, razão pela qual o item está CERTO”.


169

179. Errada.A especificação WSDL 2.0 está dividida em quatro grandes elementos: types,

interface, binding e service. Segundo Cerami (2002, p.119), o elemento types “descreve todos os tipos de dados usados entre o cliente e o servidor. WSDL não é amarrado exclusivamente a um sistema de tipagem específico, mas utiliza a especificação W3C Schema como escolha padrão. Caso o serviço utilize apenas tipos básicos, como strings e inteiros, a seção types não é necessária”.

O mesmo Cerami descreve quatro elementos de dados básicos de um do-cumento WSDL:

• Informações de interfaces que descrevem todas as funções públicas disponíveis.

• Informações de tipos de dados, usados pelas mensagens de requisição e resposta.

• Informações de binding a respeito do protocolo de transporte a ser usado.

• Informações de endereço para localização de um serviço.

180. Errada.Um documento WSDL envolve duas seções: a parte abstrata e a parte

concreta. No item apresentado, a descrição destas seções aparece invertida. Na verdade, a parte abstrata contém as definições de tipos usados pelo serviço. Ela define a forma como o serviço será acessado. Isso independe de porta, protocolo ou tecnologia. A parte concreta especifica como e onde o serviço poderá ser con-tatado por meio de informações de binding (porta, protocolo).

181. Errada.O protocolo utilizado para realizar as chamadas às operações é o SOAP e não

o UDDI como foi disposto no item. Ademais, o processo de publicação, pesquisa e descoberta de web services utiliza o padrão UDDI (e não SOAP).

182. Certa.A figura utilizada no item foi baseada na ilustração disponível no sítio SO-

ASpecs.com. O examinador apenas traduziu os termos usados na figura.

Quando tratamos de Web Services, faz-se necessário conhecer uma verdadei-ra sopa de letras: UDDI, WSDL e SOAP. De forma simplificada, um memento sobre cada uma delas:

• WSDL – linguagem para descrição dos Web Services.• UDDI – utilizado para realizar a descoberta de serviços.• SOAP – troca de mensagens e comunicação entre web services.


170

ELSEVIER

183. Certa.Há duas abordagens para implementação de Web Services:• REST (Representational State Transfer) – estilo arquitetural forte-

mente centrado no protocolo HTTP. • WS-*–webservicestradicionais(tambémconhecidosporBig Web Ser-

vices).Devido principalmente à sua simplicidade e ao menor overhead comunicação,

REST tem ganhado popularidade e frequentemente é utilizado em detrimento ao uso da abordagem tradicional, baseada em SOAP e WSDL.

184. Errada.O estilo arquitetural REST baseia seus serviços diretamente no protocolo

HTTP. Não há camadas extras ou envelopes para encapsular informações de requisição e resposta. No REST, o overhead na comunicação e tempo necessário para processar informações de controle são menores do que no modelo de desen-volvimento de sistemas embasado em SOAP. Portanto, é incorreto afirmar que o modelo REST demanda mais recursos computacionais que o modelo baseado em SOAP.

2.5.3. SOA

185. Certa. SOA é um estilo arquitetural que tem como princípio básico disponibilizar

sob a forma de serviços, funcionalidades implementadas por aplicações. Um me-canismo comum para viabilizar a comunicação entre aplicações é o uso de Web Services. XML e WSDL são padrões abertos utilizados na implementação de Web Services que permitem que os serviços se comuniquem de maneira homogênea, independentemente da plataforma de hardware, do sistema operacional e da linguagem de programação.

186. ErradaNessa assertiva, o avaliador baseou-se em artigo publicado pela IBM: “Os

Web Services permitem que os aplicativos se comuniquem entre si de modo independente da plataforma e linguagem de programação. Os Web Services uti-lizam XML (linguagem de marcações extensíveis) para descrever as interfaces de aplicativos em uma linguagem chamada WSDL (linguagem de definição de Web Services)”. Os termos XML e WSDL aparecem trocados no item.


171

187. Certa.A orquestração é a capacidade de ordenar a execução de serviços e de fornecer

lógica para processamento de dados destas execuções. Trata-se da atividade a ser executada após a identificação dos serviços.

O foco central de SOA são tarefas ou funções de negócio. É ele quem guia a definição de serviços.

O Manifesto SOA descreve os valores priorizados nessa arquitetura:• Valor do negócio em relação a estratégia técnica;• Objetivos estratégicos em relação a benefícios específicos de projetos;• Interoperabilidade intrínseca em relação a integração personali-

zada;• Serviços compartilhados em relação a implementações de propósito

específico; • Flexibilidade em relação a otimização;• Refinamento evolutivo em relação a busca da perfeição inicial.

188. Errada.Durante a análise e projeto orientado a serviços podem ocorrer otimizações

no processo de trabalho, por exemplo, por meio da paralelização da execução de serviços. Sem embargo, as atividades descritas no fluxograma são dependentes entre si. No caso específico das atividades descritas no item, não há possibilidade de paralelização. Ademais, segundo a OASIS, SOA fornece “sólidos fundamentos para agilidade organizacional e adaptabilidade”, mas não se trata de característica intrínseca dessa arquitetura.

189. Errada.Ocorre que a ligação entre provedores e consumidores de serviço é dinâmica

e não estática como foi descrito no item.

C a p í t u l o 3

Gabaritos de Engenharia de Software

3.1. Análise por Pontos de Função

3.1.1. Conceitos básicos de APF

190. Errada.Dentre as operações “CRUD”, apenas a criação, a atualização e a exclusão

de registros são consideradas entradas externas. De acordo com os critérios es-tabelecidos pela APF, a leitura de registros (read) é uma transação de consulta externa.

Funções de Dados:• Arquivo lógico interno: conjunto de dados ou informações de controle

(parâmetros de funcionamento do sistema) solicitados pelo usuário e mantidos por meio de funcionalidades do sistema.

• Arquivo de interface externa: conjunto de dados solicitados pelo usu-ário apenas para consulta pelo sistema.

Funções Transacionais:• Entrada externa: tem como principal objetivo a manutenção de arqui-

vos lógicos internos ou a alteração do comportamento do sistema.• Saída externa: tem como principal objetivo a geração de dados deri-

vados (que não estão armazenados em nenhum ALI/AIE) e sua exi-bição para o usuário; opcionalmente, pode realizar manutenção em ALIs antes de exibir dados para o usuário.

• Consulta externa: tem como principal objetivo a recuperação e exibi-ção de dados armazenados em ALIs/AIEs a partir de parâmetros in-formados pelo usuário; não pode gerar dados derivados e nem alterar nenhum ALI.

Capítulo 3 I Gabaritos de Engenharia de Software

173

191. Errada.A complexidade funcional não depende do grau de dificuldade de desenvolvi-

mento em cada organização. Segundo o IFPUG, a avaliação da complexidade de cada função é feita com base em dois critérios: para as funções de dados (ALIs e AIEs), consideram-se a quantidade de registros lógicos e itens de dados de cada arquivo; para as funções transacionais (EEs, SEs e CEs), consideram-se a quan-tidade de arquivos referenciados e de itens de dados que cruzam a fronteira da aplicação. A expressão “características do domínio de informação do software” é utilizada por Pressman (2006, p. 357) para referenciar todos os tipos de funções contabilizadas pela APF – ALI, AIE, EE, SE e CE.

A expressão “características do domínio de informação do software” é utili-zada por Pressman para referenciar todos os tipos de funções contabilizadas pela APF – ALI, AIE, EE, SE e CE.

192. Certa.Conta-se um registro lógico para cada subgrupo de itens de dados obrigató-

rios e, no mínimo, um registro lógico para os itens de dados opcionais. Caso não existam subgrupos de dados, o manual do IFPUG determina a contagem de um único registro lógico para o arquivo.

193. Errada.Nas funções transacionais, apenas os arquivos lógicos internos são manipu-

lados (tem seus dados modificados); os arquivos de interface externa são apenas referenciados (tem seus dados consultados).

194. Certa.As consultas externas recuperam e exibem o conteúdo de ALIs e AIEs, que

podem ser tanto dados como informações de controle.Processo elementar é a menor unidade de atividade de um sistema que possui

significado para o usuário. Sua funcionalidade é autocontida e mantém os dados da aplicação em um estado consistente.

195. Errada.Apenas repositórios persistentes de dados ou informações de controle são

associados a funções do tipo dados (ALI/AIE). Dados temporários gerados para processamento em outra aplicação são classificados como saídas externas.


174

ELSEVIER

196. Errada.Uma consulta externa deve limitar-se à recuperação de dados, não sendo

permitida a inclusão de lógicas complexas de processamento e a geração de dados derivados. A definição dada pela questão corresponde ao critério de identificação de saídas externas.

197. Certa.Segundo o manual de práticas de contagem do IFPUG, esse é um dos cri-

térios obrigatórios para identificação de um AIE. Portanto, a questão deve ser considerada certa por reproduzir textualmente o conteúdo do manual.

Na prática, considerando o desenvolvimento em uma arquitetura orienta-da a serviços (SOA), é possível que uma aplicação A faça referência a dados de outra aplicação B por meio de Web Services sem saber que tais dados não estão armazenados de forma permanente. Nesse caso, a aplicação A contaria os dados consultados como um AIE, enquanto na aplicação B existiria apenas uma saída externa para produção desses dados (e não um ALI).

3.1.2. APF segundo o IFPUG

198. Errada.Embora a aplicação típica da APF seja para estimativa de projetos de desen-

volvimento e manutenção de software, o IFPUG também provê regras específicas para contagem de aplicações prontas.

Tipos de Projetos de Contagem:• Projeto de desenvolvimento: aplica-se à estimativa de tamanho fun-

cional dos requisitos de usuário para sistemas cujo desenvolvimento ainda não tenha sido iniciado ou esteja em andamento.

• Projeto de melhoria (ou manutenção): aplica-se à estimativa de tama-nho de alterações corretivas ou evolutivas solicitadas pelo usuário em sistemas existentes.

• Projeto de aplicação: aplica-se aos casos em que o sistema já está con-cluído e em fase de implantação ou em plena utilização, permitindo medir a funcionalidade efetivamente entregue ao usuário.

199. Certa.O total de pontos de função obtidos pela soma das funções individuais é

chamado de “pontos de função brutos” ou “pontos de função não-ajustados”, sendo usado o termo “pontos de função ajustados” para o total obtido após a aplicação do fator de ajuste.


175

Processo de contagem do IFPUG:• Etapa I – Identificação do tipo de contagem – Projeto de desenvolvi-

mento, melhoria (manutenção) ou aplicação.• Etapa II – Definição da fronteira da aplicação – Definição da perti-

nência dos dados e identificação de transações.• Etapa III – Contagem de pontos de função não-ajustados.• Etapa IV – Cálculo do fator de ajuste – Avaliação das característi-

cas não funcionais solicitadas pelo usuário que afetam o tamanho da aplicação.

• Etapa V – Cálculo de pontos de função ajustados – Multiplicação do total de pontos de função não-ajustados pelo fator de ajuste.

200. Errada.As três formas de contagem definidas pelo manual de práticas de contagem

do IFPUG são: projeto de desenvolvimento, projeto de melhoria e projeto de aplicação. As contagens estimativa, indicativa e detalhada são definidas pela NESMA, sendo que a contagem detalhada corresponde à aplicação das regras descritas pelo IFPUG.

Além disso, os 14 “fatores de ajuste de valor” mencionados pela questão referem-se às 14 características gerais que são utilizadas para determinação do valor do fator de ajuste, não possuindo relação direta com a avaliação da com-plexidade das funções.

Características gerais utilizadas para cálculo do fator de ajuste:

• Comunicação de dados • Atualização on-line

• Funções distribuídas • Processamento complexo

• Performance • Reusabilidade

• Configuração do equipamento • Facilidade de implantação

• Volume de transações • Facilidade operacional

• Entrada de dados on-line • Múltiplos locais

• Interface com o usuário • Facilidade de mudanças

201. Certa.O manual do IFPUG prevê a contagem de pontos de função associados à

conversão de dados tanto para projetos de desenvolvimento como para projetos de manutenção.


176

ELSEVIER

Funcionalidade de conversão:Funções utilizadas apenas no momento da instalação de uma aplicação nova

ou alterada, para converter dados preexistentes ou atender a outros requisitos de conversão especificados pelo usuário, tais como relatórios específicos.

202. Errada.Segundo consta da parte dois do manual de práticas de contagem, manu-

tenções preventivas referem-se a otimizações de desempenho ou atualizações tecnológicas e não afetam a funcionalidade de negócio oferecida pela aplicação. Por esse motivo, não se enquadram no conceito de projeto de melhoria definido pelo IFPUG.

3.1.3. APF segundo a NESMA

203. Errada.Embora os objetivos da NESMA sejam similares aos do IFPUG no que se

refere à padronização e ao suporte ao uso da APF, há diferenças significativas entre as duas entidades justamente quanto à contagem de projetos de melhoria e à aplicação da técnica na fase inicial do desenvolvimento.

Contagens Antecipadas NESMA:• Contagem estimativa: requer informações gerais sobre quais grupa-

mentos de dados devem ser utilizados e quais transações serão exe-cutadas; considera que todos as funções de dados (ALI e AIE) são de complexidade baixa e todas as funções transacionais (CE, EE e SE) são de complexidade média.

• Contagem indicativa: requer somente informações sobre os grupa-mentos de dados que serão consultados (AIE) ou manipulados (ALI) pela aplicação; utiliza a fórmula PF = 35 * ALI + 15 * AIE.

Projetos de Melhoria NESMA:Ao contrário do IFPUG, que considera a quantidade integral dos pontos

referentes a funções adicionadas, modificadas ou excluídas, a NESMA define deflatores, chamados de fatores de impacto, para cada tipo de alteração.

• Funções adicionadas: sempre são consideradas integralmente (fator de impacto igual a 1,00).

• Funções modificadas: o fator de impacto pode variar entre 0,25 e 1,00 para funções de dados e entre 0,25 e 1,50 para funções transacionais.

• Funções excluídas: sempre utilizam fator de impacto igual a 0,40.


177

3.1.4. Aplicações da APF

204. Errada.Segundo Pressman, cada organização estabelece critérios próprios para

determinar a complexidade de cada função (simples, média ou complexa), o que tornaria a técnica subjetiva. Mesmo se considerarmos a existência de regras e critérios definidos pelo IFPUG para identificação de funções e determinação de sua complexidade, ainda assim a interpretação dessas regras para cada sistema envolve certo grau de subjetividade.

205. Certa.A realização de contagem no início do projeto é prevista tanto pelo IFPUG

como pela NESMA, embora com critérios e processos distintos. Tipicamente a APF é usada como base para estimativas de esforço, tempo e custo; indiretamen-te, também permite avaliar riscos do projeto caso não haja disponibilidade de recursos, orçamento e tempo compatíveis com a necessidade estimada.

206. Errada.Vide o comentário da questão seguinte.

207. Errada.Embora possam ser igualmente resolvidas com base nos objetivos e benefícios

associados pelo IFPUG à utilização da técnica de APF, ambas as questões (206 e 207) foram baseadas na abordagem descrita por Pressman na seção 15.3.1 do livro “Engenharia de Software”.

Segundo aquele autor, a APF pode ser usada para estimar os custos de pro-jeto e a quantidade de erros durante os testes, sem o uso de métricas adicionais.

Aplicações da APF, segundo Pressman:• estimar o custo ou esforço necessário para projetar, codificar e testar o

software;• prever o número de erros que vão ser encontrados durante o teste;• prever o número de componentes e/ou o número de linhas de código

projetadas no sistema implementado.

208. Errada.O objetivo da técnica é medir o desenvolvimento e manutenção de software

(e não o desempenho e manutenção), sendo uma característica fundamental da APF o fato de que a contagem é totalmente independente de tecnologia.


178

ELSEVIER

Aplicações da APF, segundo o IFPUG:• medir a funcionalidade que o usuário solicita e recebe;• medir o desenvolvimento e manutenção de software independente-

mente da tecnologia utilizada para a implementação;• determinar o tamanho de um pacote de aplicativos adquiridos, por

meio da contagem de todas as funções incluídas no pacote;• ajudar os usuários a determinar o benefício de um pacote de aplicati-

vos para a sua organização, contando funções que correspondam aos seus requisitos específicos;

• medir as unidades de um produto de software para suporte a análises de qualidade e produtividade;

• estimar custo e recursos necessários para o desenvolvimento e manu-tenção de software.

209. Certa.Trata-se de uma questão polêmica. A afirmativa da questão consta explici-

tamente da seção 15.3.1 do livro do Pressman e, por esse motivo, foi considerada como certa pelo Cespe. Por outro lado, o IFPUG diferencia claramente a visão técnica do software da visão de requisitos do usuário, sendo esta última a base para todas as contagens de PF. Nesse sentido, os diagramas de classe e sequência não deveriam ser usados para calcular os pontos de função, por representarem uma visão técnica do software.

3.2. Modelos de Processos de Desenvolvimento de Software

210. Errada.O termo “modelo Waterfall” refere-se ao modelo em cascata, também denomi-

nado modelo linear ou ciclo clássico. Este ciclo tem como principal característica o sequenciamento das fases, no qual só passa-se para a fase seguinte quando a anterior estiver finalizada. Este ciclo caracterize-se, também, pela dificuldade de lidar com requisitos voláteis, pois dependendo do erro encontrado na materializa-ção de um determinado requisito em uma fase, será necessário refazê-lo desde seu início, independente da fase na qual se encontra, o que torna a afirmativa errada.

211. Certa.Segundo Pressman (2006, p. 38), um modelo prescritivo consiste em um con-

junto específico de atividades de arcabouço, como por exemplo a NBR ISSO/IEC 12207 que estabelece uma estrutura comum para os processos de ciclo de vida de software. Já um modelo descritivo apresenta o processo em detalhes, é como se fosse um guia para o desenvolvimento de software. Tal como o enunciado da questão,


179

Becker Ulrike, um autor renomado da área de engenharia de software, afirma que “a tarefa de implantação (ou melhora da qualidade) de um processo de software engloba duas atividades principais: a elaboração de um modelo de processo des-critivo e de um modelo de processo prescritivo”. O autor conclui que “Um modelo descritivo retrata como um processo é executado em um ambiente em particular; um modelo prescritivo retrata como um processo deveria ser executado”.

212. Errada.No modelo de desenvolvimento prototipação, o processo de desenvolvimento

de software não é linear, na verdade, este processo é iterativo.

213. Errada.Segundo Pressman (2006, p. 42), o modelo em espiral de ciclo de vida de

software é evolucionário e nem sempre a mesma sequência de atividades rela-cionadas à produção de software é realizada a cada ciclo da espiral.

214. Errada.Segundo Sommerville (2003, p. 6), um modelo de processo de software

consiste em uma representação simplificada (o enunciado da questão afirma representação complexa) de um processo de software, apresentada a partir de uma perspectiva específica (o enunciado da questão afirma perspectiva genérica).

215. CertaSegundo Sommerville (2003, p. 6), os desafios enfrentados pela engenharia de

software são lidar com sistemas legados, atender à crescente diversidade e atender às exigências quanto a prazos de entrega reduzidos, tal como o enunciado da questão.

216. CertaPressman (2006, p. 17), cita uma definição para “Engenharia de Software”

elaborada pelo IEEE que justifica o enunciado da questão.

Engenharia de Software:• Consiste da aplicação de uma abordagem sistemática, disciplinada e

quantificável, para o desenvolvimento, operação e manutenção do softwa-re; isto é, a aplicação da engenharia ao software.

217. ErradaAs características das fases de projeto e elicitação de requisitos estão trocadas.

Pois Larman (2004, p. 30) afirma que o projeto enfatiza uma solução conceitual que satisfaça os requisitos enquato que a elicitação de requisitos tem por objetivo determinar o escopo do projeto de software.


180

ELSEVIER

218. CertaO protótipo evolutivo comporá a solução final enquanto o descartável será

substituído por outro módulo de software. Por isso o protótipo evolutivo apresenta, de forma geral, maior manutenabilidade e escalabilidade quando comparado a um protótipo descartável.

219. ErradaAs características das abordagens do modelo unificado e ágeis estão troca-

das. O uso das técnicas de test-driven design, refactoring, design patterns e pair programming é maior nos modelos ágeis, enquanto o uso das Ferramentas CASE é mais comum no modelo unificado, devido à robustez da sua documentação.

Ferramentas CASE (Computer-Aided Software Engeneering):• Consiste em um conjunto de ferramentas computadorizadas, utiliza-

das para a construção e manutenção dos artefatos previstos em uma metodologia de engenharia de software.

220. ErradaSegundo Pressman (2006, p. 45), o modelo espiral exige a consideração direta

dos riscos técnicos em todos os estágios do projeto.

221. ErradaSegundo Pressman (2006, p. 43), as etapas da prototipação são: Comuni-

cação; Plano Rápido; Modelagem Projeto Rápido; Construção do Protótipo; e Implentação, Entrega e Feedback.

222. CertaSegundo Pressman (2006, p. 38), o Modelo em Cascata, também denomina-

do ciclo de vida clássico, segue uma abordagem sequencial das suas fases para o desenvolvimento de software.

223. CertaSegundo Pressman (2006, p. 48), o desenvolvimento Baseado em Compo-

nentes oferece benefícios inerentes em qualidade de software, produtividade dos desenvolvedores e custos globais do sistema. É um processo que enfatiza o projeto e a construção de sistemas usando componentes de software reusáveis. Compõe aplicações a partir de componentes prontos. Os requisitos que não são atendidos pelos componentes são adaptados ou excluídos, quando possível (PRESSMAN, 2006, p. 663).


181

224. Errada.Segundo Pressman (2006, p. 40), o RAD é um modelo de processo de software

incremental que enfatiza um ciclo de desenvolvimento curto. É uma adaptação “de alta velocidade” do modelo em cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes. Por outro lado, a prototipagem é um modelo evolucionário utilizado quando os requisitos são confusos, o que torna o enunciado inválido.

225. Errada.Considerando que o modelo sequencial linear só produzirá software execu-

tável no fim do projeto e que a detecção do problema foi na implantação, a fase que gera os erros de maior custo de correção é a fase de requisitos, por ser a mais afastada da fase de implantação.

226. Certa.O modelo de desenvolvimento em espiral é iterativo, permitindo o replane-

jamento do projeto ao término de cada iteração.

227. Errada.Segundo Pressman (2006, p. 39), o modelo de desenvolvimento sequencial

linear só produz uma versão executável do software no período final do intervalo de tempo do projeto.

228. Errada.A especificação dos requisitos de software é de fundamental importância

para qualquer processe de desenvolvimento de software. No entanto, Pressman (2006, p. 42) afirma que o paradigma de prototipagem auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos. Neste caso, o protótipo serve como um mecanis-mo para a identificação dos requisitos de software, que são importantes do mesmo jeito.

229. Errada.A restrição citada no enunciado não existe.

230. Errada.Segundo Pressman (2006, p. 40), o modelo incremental combina elementos

do modelo em cascata aplicada de maneira iterativa. Já o modelo RAD, segundo o autor, é um modelo de processo de software incremental que enfatiza um ciclo


182

ELSEVIER

de desenvolvimento curto. Na verdade, é o RAD que possui as características do modelo de desenvolvimento incremental e não o contrário, conforme o enunciado da questão.

231. Certa.Segundo Pressman (2006, p. 44), usando o modelo em espiral, o software

é desenvolvido numa série de versões evolucionárias, tal como a afirmativa da questão.

232. Certa.Segundo Pressman (2006, p. 48), o modelo de desenvolvimento baseado em

componentes incorpora muitas das características do modelo espiral. Este modelo preconiza o uso de componentes comerciais prontos para uso.

3.3. Processo Unificado

233. Errada.Diferentemente do enunciado da questão, o plano de teste no RUP é respon-

sabilidade do Gerente de Teste.

234. Certa. Assim como o enunciado da questão, pode-se afirmar que o marco da fase

Elaboração é a consolidação da arquitetura. Pode-se afirmar que a arquitetura de software consiste em uma representação abstrata de componentes e compor-tamentos de um sistema. Uma arquitetura bem projetada deve ser capaz de aten-der aos requisitos funcionais e não funcionais do sistema e ser suficientemente flexível para suportar requisitos voláteis.

235. Certa.De fato, o diagrama de caso de negócio é um artefato do RUP desenvol-

vido na disciplina Modelagem de Negócio que escreve a direção e a intenção do negócio. A direção é fornecida na forma de metas de negócio, que são deri-vadas da estratégia de negócio, enquanto a intenção é expressa como o valor agregado e os meios de interação com os envolvidos e clientes do negócio. O Modelo de Caso de Uso do Negócio é utilizado pelos investidores, os analistas de processo de negócios e os designers de negócios para entender e aprimorar o modo em que o negócio interage com o seu ambiente e pelos analistas de sistemas e arquitetos de software para fornecer o contexto para o desenvol-vimento de software.


183

236. ErradaO ciclo de vida do RUP de fato é composto pelas fases concepção, elaboração,

construção e transição, no entanto, ele abrange apenas até a entrada do software em produção.

237. CertaA primeira linha de base da arquitetura de fato é o marco da fase elaboração.

238. Errada.O RUP é organizado em fases e disciplinas. As disciplinas são representadas

por fluxos de atividades.

O Rational Unified Process (RUP): • É um processo de engenharia de software que oferece uma aborda-

gem baseada em disciplinas para atribuir tarefas e responsabili-dades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orça-mento previsíveis.

Dimensões do RUP:• O eixo horizontal representa as fases e mostra os aspectos do ciclo de

vida do processo à medida que se desenvolve, são elas: Iniciação, Ela-boração, Construção e Transição.

• O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza, são elas: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Ge-renciamento de Projeto, Gerenciamento de Configuração e Mudança e Ambiente.

239. Errada.Na concepção são levantados todos os requisitos do projeto e na elaboração

são implementados os requisitos mais críticos, ou seja, apenas uma parte dos requisitos identificados na fase de concepção será implementada na elaboração.

240. Errada.O RUP (Rational Unified Process) é uma versão do PU (Processo Unificado)

desenvolvida pela empresa “Rational”, então, para efeito dos concursos, RUP é sinônimo de UP. Assim, as quatro fases do UP são: concepção, elaboração, cons-trução e transição.


184

ELSEVIER

241. Certa.De fato a elicitação de requisitos é uma disciplina do RUP que inicia-se e

tem seu maior volume de trabalho durante a fase de concepção.

242. Errada.A UML é uma linguagem de modelagem e o UP é um processo de desen-

volvimento de software. Vários produtos de trabalho do UP são diagramas da UML. Então, pode-se afirmar que o UP não concorre com a UML, seus objetivos são distintos.

243. Certa.Segundo o Rational Unified Process online (disponível em: http://www.

wthreex.com/rup/ou http://www-01.ibm.com/software/br/rational/) o RUP é um processo iterativo e incremental, orientado por casos de uso e centrado na arquitetura. Portanto, a questão deve ser considerada certa.

244. Errada.O RUP segue a boa prática de desenvolvimento de software denominada

“Verificação Contínua da Qualidade”.

Segundo o RUP:• A qualidade é definida como: “...a característica de ter demonstrado a

realização da criação de um produto que atende ou excede os requisi-tos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em um processo acordado.”

• O gerenciamento da qualidade é implementado em todas as dis-ciplinas, fluxos de trabalho, fases e iterações do RUP. Em geral, o gerenciamento da qualidade durante o ciclo de vida significa que você implementa, mede e avalia tanto a qualidade do processo como a do produto.

245. Errada.Estruturar o modelo de caso de uso de negócios é uma tarefa da disciplina

modelagem de negócio do RUP.

246. Errada.Estabelecer o marco da arquitetura do ciclo de vida do projeto ocorre na fase

de elaboração do RUP.

http://www.wthreex.com/rup/


185

247. Certa.A afirmativa enumera corretamente as técnicas utilizadas para a construção

do modelo dos processos de negócios durante a disciplina modelagem de negócios do RUP.

248. Certa.A afirmativa ressalta corretamente que as iterações da fase concepção (ou

iniciação) enfatizam, na disciplina gerência de projetos, as atividades de plane-jamento, em detrimento das atividades de monitoramento e controle.

249. Certa.A afirmativa descreve de maneira correta as características do documento

de visão, ou simplesmente visão, que é um dos artefatos do RUP mais cobrados em questões de concursos.

250. Errada.A fase do RUP que possui tipicamente atividades da disciplina de análise e

projeto é a elaboração.

251. Errada.A fase do RUP na qual as atividades da disciplina implementação (imple-

mentation) são mais intensas é a construção.

252. Certa.O marco da fase de iniciação (ou concepção) é o Objetivos do Ciclo de Vida que

avalia a viabilidade básica do projeto. Por isso, no término dessa fase as principais necessidades de informação devem estar identificadas, pois elas caracterizam o escopo do projeto.

253. Errada.Toda iteração do RUP, independente da fase, pode e deve gerar código ou

interfaces homem-máquina.

254. Errada.A integração de componentes é definida essencialmente na fase de elabo-

ração, devido ao fato do seu foco ser a disponibilização da primeira arquitetura executável do sistema em desenvolvimento.


186

ELSEVIER

255. Certa.Ao término da fase de iniciação do RUP é disponibilizado um planejamento

macro de todo o ciclo de desenvolvimento do projeto com a ordem de implemen-tação dos casos de uso do sistema. No entanto, devido a sua iteratividade, o RUP permite que, ao término de cada iteração, esse planejamento inicial seja revisto e corrigido quando necessário. Uma das principais vantagens da iteratividade é a flexibilização do planejamento do projeto que permite adaptações no seu transcurso e proporciona o auxílio no gerenciamento de riscos.

3.4. Processos Ágeis

256. Certa.Assim como o enunciado a firma, o SCRUM é um método ágil em que todos

os itens do sprint backlog advêm do product backlog. O product backlog contém uma lista inicial de necessidades que precisam ser produzidas para que a visão do projeto seja bem-sucedida (escopo do projeto). Por outro lado, o sprint back-log contém as necessidades que serão implementadas em uma sprint.

257. Errada.Segundo Pressman (2006, p. 63), o Extreme Programming inclui um conjunto

de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço: planejamento, projeto, codificação e teste. Então, pode-se afirmar que o desen-volvimento de um código na XP está relacionado à fase de codificação.

258. Certa.Apesar do gabarito definitivo ter considerado a afirmativa correta, o Scrum é

um processo de gerenciamento de projetos e não de desenvolvimento de software, conforme a afirmação da questão. Na verdade, a questão cita características do XP. Esta questão deveria ter seu gabarito mudado para Errada.

Segundo o Ken Schwaber (autor do Scrum):• Scrum é um processo bastante leve para gerenciar e controlar projetos

de desenvolvimento de software e para a criação de produtos.

259. Errada.O início da afirmativa está errado por afirmar que o Scrum é uma me-

todologia para o desenvolvimento de software. Na verdade, o Scrum é uma metodologia ágil para o gerenciamento de projetos de software ou de qualquer outro produto.


187

260. Errada.O modelo em cascata caracteriza-se por possuir as fases: requisitos de sistema,

requisitos de software, análise, projeto, implementação, testes e implantação. No XP, cada iteração é composta por atividades de planejamento, projeto, codificação e teste apenas.

261. Errada.As metodologias ágeis pregam a simplificação da documentação, não sendo

necessário o uso de ferramentas CASE.

262. Errada.O Scrum é um processo de gerenciamento de projetos e não de desenvolvi-

mento de software.

263. Certa.Tal como preconizado por Kent Beck, o autor do XP, a questão apresenta

algumas das práticas do XP.

Práticas do XP segundo o Kent Beck (autor do XP):• Cliente Presente – o cliente está sempre disponível para resolver dúvi-

das, alterar o escopo de uma iteração e definir prioridades. • Metáfora – o time se comunica sobre o software em termos de uma

metáfora, caso consiga encontrar uma boa.• Ciclos de Entrega Curtos – O software é entregue em pequenas versões

para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos.

• Testes – são definidos pelos usuários e pelos desenvolvedores. São os critérios de aceitação do software.

• Integração Contínua – os diversos módulos do software são integra-dos diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

• Projeto Simples – o código está, a qualquer momento, na forma mais simples que passe todos os testes.

• Refatoração – a cada nova funcionalidade adicionada, é trabalhado o design do código até ficar na sua forma mais simples.

• Programação em Pares – Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor.


188

ELSEVIER

• Propriedade Coletiva – a equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qual-quer arquivo.

• Padrão de Codificação – todo código é desenvolvido seguindo um padrão.• Semana de 40 horas de trabalho – trabalhar por longos períodos é

contraproducente.

264. Errada.O XP trabalha com requisitos voláteis não necessariamente conhecidos de

antemão em sua totalidade.

265. Certa.A questão apresenta de maneira correta a definição de Ken Schwaber (autor

do Scrum) para o product baklog.

266. Certa. A questão apresenta alguns valores e princípios do XP segundo Kent Beck

(2004).

Valores do XP segundo o Kent Beck (autor do XP):• Comunicação: a equipe deve ser capaz de se comunicar da maneira

mais clara possível. • Simplicidade: o projeto de software deve prezar pela simplicidade.• Feedback: todo teste deve gerar um retorno que colabore com a evolu-

ção do projeto.• Coragem: a equipe deve ter coragem de mudar código para melhorar

o software em desenvolvimento.

267. Certa.Segundo Ken Schwaber, seu autor, o Scrum é um processo ágil que segue a

filosofia iterativa e incremental. O autor também afirma que o Scrum é adaptativo e empírico, tal como a afirmativa da questão.

268. Certa.Segundo Pressman (2006, p. 66), apoio filosófico do DAS concentra-se na

colaboração humana e na auto-organização. A auto-organização aparece quando agentes individuais independentes cooperam para criar resultados emergentes. Um resultado emergente é uma propriedade além da capacidade de qualquer agente individual.


189

269. Errada.Segundo Pressman (2006, p. 60) “a agilidade pode ser aplicada a qualquer

processo de software. Entretanto, para conseguir isso, é essencial que o proces-so seja projetado de modo que permita à equipe de projeto adaptar tarefas e aperfeiçoá-las, conduzir o planejamento para que se entenda a fluidez de uma abordagem de desenvolvimento ágil, eliminar tudo menos os produtos de traba-lho mais essenciais e mantê-los simples, e enfatizar uma estratégia de entrega incremental que forneça o software funcionando ao cliente o mais rápido possível para o tipo de produto e ambiente operacional”.

Esta afirmativa deixa bem claro que a agilidade pode ser aplicada a qualquer processo de software desde que certas condições sejam satisfeitas.

No entanto, segundo a resposta do gabarito é errado afirmar que “A agilidade não pode ser aplicada a todo e qualquer processo de software.”, ou seja, pode-se afirmar que “A agilidade pode ser aplicada a todo e qualquer processo de software”, independente de qualquer condição, pois nenhuma condição foi citada na questão.

Visto que Pressman (2006, p. 60) afirma que a agilidade em qualquer pro-cesso é dependente de determinadas condições e que a questão não cita esta peculiaridade, o gabarito deveria ser mudado para Certo.

270. Certa.Segundo Pressman (2006, p. 63), o XP possui quatro atividades de arcabouço:

planejamento, projeto, codificação e teste.

271. Certa.Segundo Pressman (2006, p. 63), a atividade de planejamento XP começa

com a criação de um conjunto de histórias (também chamado de histórias de usuário) que descrevem as características e as funcionalidades requeridas para o software a ser construído.

272. Errada.Segundo Pressman (2006, p. 64), atividade de projeto do XP segue o princípio

“mantenha a simplicidade”.

273. Errada.No Scrum, o Product Owner (PO) cria uma lista inicial de necessidades que

precisam ser produzidas para que a visão (escopo) do projeto seja bem-sucedida. Esta lista de necessidades é chamada de Product Backlog. Uma sprint é um pe-ríodo de tempo entre 2 e 4 semanas que dever ser fixo, dentro do qual o time do projeto irá produzir uma parte do produto definido pelo PO. No planejamento


190

ELSEVIER

da sprint, o PO deverá definir a meta da sprint e expor para o time os itens mais prioritários do Product Backlog. O time deve estimar os itens em tamanho e de-finir o que acredita que pode ser implementado dentro da sprint. Essa listagem é chamada de Selected Product Backlog. Posteriormente, o time deverá colher mais detalhes do Selected Product Backlog e decompô-los em tarefas, gerando assim a Sprint Backlog. O PO pode alterar as prioridades dos itens no Product Backlog e na Sprint Backlog; e as estruturas do Product Backlog e da Sprint Backlog são distintas, a Sprint Backlog contém mais detalhes relacionados à estratégia de implementação.

274. Certa.A questão descreve algumas práticas do XP de maneira correta.

275. Errada.Extreme Programming é um modelo de processo de desenvolvimento de

software para equipes com pequeno número de pessoas (até 10).

276. Certa.A questão descreve de maneira correta as características da prática de pro-

gramação em pares do XP.

277. Errada.Os modelos ágeis são incrementais e iterativos.

3.5. Engenharia de Requisitos

278. Certa.Pressman (2006, p. 239) afirma que a engenharia de requisitos é composta

pelas seguintes atividades: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. O autor afirma que na validação os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qua-lidade, tal como o enunciado.

279. Certa.Todas as técnicas citadas na afirmativa são válidas para a validação de re-

quisitos de acordo com Sommerville (2003, p. 116).

280. Errada.As definições e tipos de requisitos estão errados.


191

Requisitos segundo o Sommerville (2003, p. 83):• Requisitos Funcionais: são declarações de funções que o sistema deve

fornecer; como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações.

• Requisitos não Funcionais: são restrições sobre os serviços ou as fun-ções oferecidas pelo sistema (tempo, padrão, etc).

• Requisitos de Domínio: originam-se no domínio de aplicação do siste-ma e refletem características desse domínio. Podem ser funcionais ou não funcionais.

• Os requisitos não funcionais podem ser de produto, organizacionais ou externos.

281. Certa.A definição está correta e pode ser encontrada em (Sommerville, 2003, p. 105).

282. Certa.De fato a coleta colaborativa de requisitos, que pode ser feita por meio de uma

reunião ou entrevista, é a técnica mais utilizada para a elicitação de requisitos. Pressman (2006, p. 125) detalha esta técnica.

283. Errada.A prototipação pode compreender apenas uma interface gráfica com o usuário

sem nenhum código. Esta abordagem é útil para auxiliar o entendimento dos requisitos do software a ser desenvolvido.

284. Errada.O ciclo de desenvolvimento de software denominado prototipagem é itera-

tivo e por isso os requisitos são levantados logo no início da primeira iteração e poderão ser aprimorados ao longo de várias outras.

285. Certa.

Segundo Bohem (Pressman, 2006, p. 289), verificação e validação de re-quisitos são definidas da seguinte forma:

• Verificação: se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica (estamos construindo o produto corretamente?).

• Validação: se refere ao conjunto de atividades que garante que o software construído corresponde aos requisitos do cliente (estamos construindo o produto correto?).


192

ELSEVIER

286. Certa.Durante a análise, a especificação de requisitos permite revelar o que o siste-

ma irá realizar no que se refere às funcionalidades, sem definir, nesse momento, como as funcionalidades serão implementadas. Durante o projeto a solução começa a ser esboçada e na implementação todos os detalhes relacionados a programação serão concluídos.

287. Certa.Os diagramas de classes, de casos de uso e de interação da UML podem ser

utilizados durante validação de requisitos, no entanto, não podemos esquecer que a palavra final será do usuário do sistema e por isso o nível de detalhamento deve respeitar a sua capacidade de compreensão.

288. Errada.Em um processo iterativo, a identificação dos atores, tanto os principais

quanto os secundários, pode ser realizada em mais de uma iteração.

289. Certa.A afirmativa é verdadeira e está de acordo com Pressman (2006, p. 120).

290. Errada.Pressman (2006, p. 121) afirma que a gestão formal de requisitos é necessária

apenas para grandes projetos com centenas de requisitos.

291. Errada.Requisitos não funcionais não abrangem declarações de serviços que o sistema

deve fornecer, pois este são os requisitos funcionais.

292. Certa.Afirmativa aborda a essência do conceito de requisito de maneira correta.

293. Errada.Sommerville (2003, p. 115) afirma que enquanto a análise trabalha com

requisitos incompletos, a validação elabora um esboço completo do documento de requisitos.

294. Errada.Requisitos de software devem ser levantados após requisitos de sistema.


193

295. Errada.O SWEBOK (Guide to the Software Engineering Body of Knowledge – dispo-

nível em: http://www.computer.org/portal/web/swebok) não considera o envio de questionário por e-mail, uma técnica para levantamento de requisitos eficiente.

296. Errada.Na verdade, existem várias normas para o gerenciamento de requisitos como,

por exemplo, a IEEE Std 830-1998.

297. Certa.Esta afirmativa pode ser encontrada em (Sommerville, 2003, p. 116).

298. Certa.Etnografia é definida por Sommerville (2003, p. 115) como técnica de observa-

ção utilizada para compreender os requisitos organizacionais e sociais. O trabalho diário é observado e são anotadas as tarefas reais em que os participantes estão envolvidos. O valor da etnografia está na descoberta de requisitos implícitos, que refletem os processos reais.

299. Errada.A proteção, pelo sistema, das informações pessoais dos usuários cadastrados

é exemplo de requisito não funcional, pois está relacionado ao aspecto segurança da informação e não às regras de negócio do domínio.

300. Errada.Segundo Sommerville (2003, p. 109), pontos de vista são documentados por

meio de diagramas de bolha e os cenários, por meio de diagramas use case.

301. Errada.A questão apresenta tipos de requisitos válidos segundo Sommerville (2003,

p. 119). Ela ainda afirma que a limitação do tamanho do sistema em 100 MB é um requisito de domínio, mas para julgarmos essa afirmativa precisaríamos ter a descrição do domínio, tendo em vista que os requisitos de domínio podem ser funcionais e não funcionais (Sommerville, 2003, p. 83). Como a questão não apre-sentou essa descrição, nada podemos afirmar. Então optamos pela resposta Errada.

Uma das Classificações de Requisitos por Sommerville (2003, p. 119):• Requisitos Permanentes: são requisitos relativamente estáveis, que

derivam da atividade principal da organização e que se relacionam diretamente com o domínio do sistema.


194

ELSEVIER

• Requisitos voláteis: são requisitos que provavelmente vão se modificar durante o desenvolvimento do sistema ou depois que o sistema estiver em operação. Os requisitos voláteis podem ser: mutáveis, emergentes, consequentes ou de compatibilidade.

302. Certa.Questão correta segundo Sommerville (2006, p. 103).

303. Errada.O levantamento de requisitos nunca deve ser negligenciado em hipótese

alguma.

3.6. Arquitetura de Software

304. Certa.A princípio, qualquer aplicação web pode ser construída utilizando-se a ar-

quitetura MVC, desde que a relação custo benefício justifique esse uso.

305. Certa.Em uma arquitetura MVC o controlador é responsável pelo fluxo da apli-

cação e, por isso, é o responsável pela interpretação dos dados de entrada e pela manipulação do modelo, de acordo com esses dados.

Arquitetura de software (ALLEN; BAMBARA, 2003, p. 27):• Arquitetura refere-se a uma representação abstrata de componentes e

comportamentos de um sistema. Uma arquitetura bem projetada deve ser capaz de atender aos requisitos funcionais e não funcionais do sis-tema e ser suficientemente flexível para suportar requisitos voláteis.

Padrão Arquitetural MVC (ALLEN; BAMBARA, 2003, p. 150):• Modelo: representa os dados da aplicação e as regras de negócio.• Controlador: define o comportamento da aplicação.• Visão: apresenta o dados aos usuários.

306. Certa. Segundo Pressman (2006, p. 241), no contexto da engenharia de software

convencional, um componente, também denominado módulo, é um elemento funcional de programa que incorpora lógica de processamento e uma interface que possibilita ao componente ser chamado por outros módulos. Por outro lado, no contexto da engenharia de software orientada a objetos, o componente possui um conjunto de classes colaborativas (PRESSMAN, 2006, p. 239).


195

307. Certa.A questão apresenta uma definição correta para a arquitetura cliente-servidor

segundo Sommerville (2006, p. 187).

Arquitetura Cliente- Servidor (SOMMERVILLE, 2003, p. 187):• O modelo de arquitetura cliente-servidor é um modelo de sistema dis-

tribuído, que mostra como os dados e o processamento são distribuí-dos em uma série de processadores, seus principais componentes são:

• Servidores: oferecem serviços, como por exemplo, servidores de banco de dados.

• Clientes: solicita os serviços oferecidos pelos servidores.• Rede: permite aos clientes acessarem os servidores.

308. Certa.Uma arquitetura normalmente implica em uma organização lógica do

software, no entanto, segundo Fowler (2006, p. 39), o uso do termo “Tier” implica na separação física das camadas. Já quando é usado o termo “Layer”, as camadas não precisam rodar em máquinas distintas.

Arquitetura Cliente- Servidor em Três camadas (Larman, 2004, p. 446):• Camada de Apresentação: classes que contêm funcionalidade para

visualização dos dados pelos usuários. As classes de fronteira para atores humanos se encontram nessa camada.

• Camada da Lógica da Aplicação: consiste da camada existente no ser-vidor de aplicação. Classes que implementam as regras do negócio no qual o sistema está para ser implantado.

• Camada de Armazenamento: tipicamente essa camada é implemen-tada utilizando algum mecanismo de armazenamento persistente (SGBD).


309. Certa.Usabilidade é o termo usado para descrever a qualidade da interação dos

usuários com uma determinada interface. Considera-se que a interface tem um problema de usabilidade se um determinado usuário ou um grupo de usuários encontra dificuldades para realizar uma tarefa com a interface. Pode-se afirmar que a primeira e uma das mais importantes fases da engenharia de usabilidade é a que permite o conhecimento do usuário do software.


196

ELSEVIER

Fases da Engenharia de Usabilidade:1. Conhecer o usuário: fase básica e essencial de análise das tarefas e

objetivos, para identificação das características individuais dos usu-ários.

2. Analisar os aplicativos concorrentes: análise comparativa de diversos produtos disponíveis, para estudo de recursos interessantes e falhas para inovar.

3. Especificar metas de usabilidade: determinação dos pesos dos atribu-tos de usabilidade, em função do projeto, dos objetivos da interface e das métricas da usabilidade.

4. Realizar o Design paralelo: exploração das diversas alternativas de design, através do trabalho independente de vários designers, para geração de múltiplas soluções.

5. Fazer o Design participativo: apresentação de diversas opções de de-sign para uma amostra representativa de usuários, para seleção das alternativas adequadas.

6. Efetuar o Design coordenado para a interface total: aplicação de ar-gumentos de consistência para todo o conjunto da interface homem--computador incluindo, além das telas do produto, a documentação.

7. Aplicar os princípios de Design de interfaces e de análise heurística: utilização de princípios para design de interfaces com usuário e de heurísticas de usabilidade, para avaliação do design considerado.

8. Elaborar protótipos: elaboração de telas sem funcionalidades para avaliação dos usuários e diminuição de tempos de reengenharia.

9. Aplicar testes empíricos: elaborar uma série de testes das telas com os usuários para listagem de erros e melhorias de usabilidade.

10. Realizar o Design iterativo: realização de novas versões da interface, através de um processo iterativo de design, baseados nos problemas de usabilidade e nas observações identificadas na fase 9.

11. Efetuar observação em campo: análise da utilização do produto, para coleta de feedbacks.

310. Errada.De fato a prototipação possibilita que o usuário teste as características do pro-

duto final. No entanto é a prototipação vertical que é focada nas funcionalidades.

• Prototipação Horizontal: consiste em montar uma interface completa em termos de elementos, permitindo uma visão geral do usuário por todo o sistema, assim como uma pessoa observa o horizonte, em um protótipo horizontal, o usuário obtém uma visão geral de tudo.


197

• Prototipação Vertical: é focada nas funcionalidades. Dessa forma, um protótipo do sistema pode ser reduzido a um módulo isolado, onde o usuário poderá ver em detalhes um pedaço limitado do sistema.

311. Certa.A questão aborda corretamente a estratégia de teste proposta por Pressman

(2006, p. 291).

312. Errada.O nível máximo de qualidade de um software é atingido quando todos os cri-

térios de qualidade estabelecidos no início do projeto são atingidos. Normalmente não é possível que todos os envolvidos no processo de criação desse software façam parte da revisão de qualidade.

313. Certa.A questão aborda corretamente as características da revisão da codificação.

314. Errada.Apesar do gabarito final da questão ser errada, Sommerville (2003, p 385)

afirma que “Os testes de integração devem ser desenvolvidos a partir da especi-ficação do sistema e começar assim que as versões de alguns dos componentes do sistema estejam disponíveis.”. A questão afirma a mesma coisa e acrescenta que o comportamento do sistema pode ser determinado por meio do estudo de suas entradas e saídas o que também é verdadeiro, pois pode-se considerar uma saída correta como um estado consistente do sistema e uma saída incorreta como um estado inconsistente. Então, acreditamos que o gabarito poderia ser modificado para certa.

315. Errada.A questão aborda de maneira errada as definições de erro, defeito e falha

da IEEE 829.

IEE 829:• Erro: resultado de uma falha humana.• Defeito: resultado de um erro existente num código ou num documento.• Falha: resultado ou manifestação de um ou mais defeitos.

316. Certa.A questão cita corretamente as características dos testes caixa-branca.


198

ELSEVIER

IEE 829:• Testes Caixa Preta (Black Box): visam verificar a funcionalidade e a

aderência aos requisitos, em uma ótica externa ou do usuário, sem se basear em qualquer conhecimento do código e da lógica interna do componente testado.

• Testes Caixa Branca (White Box) ou Caixa de Vidro: visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos.

317. Certa.Segundo a IEEE 829, os testes back-to-back, conforme a afirmativa, são uti-

lizados para a comparação do comportamento das versões diferentes do mesmo software.

318. Certa.Segundo Sommerville (2003, p. 358), a validação dinâmica é executada por

meio da execução de código e pode ser utilizada para detectar defeitos ou para a validação das funcionalidades de um software.

Sommerville (2003, p. 358):• Inspeção de software: analisam e verificam as representações do sis-

tema, como o documento de requisitos, os diagramas de projeto e o código-fonte do programa. As inspeções podem ser aplicadas em todos os estágios do processo e serem complementadas por alguma análise automática do texto de origem de um sistema ou dos documentos asso-ciados. As inspeções de software e as análises automatizadas são téc-nicas estáticas de V&V, tendo em vista não ser necessária a execução do sistema.

• Teste de software: envolve executar uma implementação do software com os dados de teste e examinar as saídas dele e seu comportamento operacional, a fim de verificar se ele está sendo executado conforme o esperado. Os testes são uma técnica dinâmica de V&V.

319. Errada.O teste de validação é um teste caixa-preta e tem por objetivo avaliar se os

requisitos foram implementados de acordo com as necessidades dos usuários.

320. Certa.A primeira frase da questão está de acordo com a NBR ISO/IEC 12207:1998.

Já a segunda frase encontra amparo em Pressman (2006, p. 579). Segundo o


199

autor Controle de Qualidade envolve a série de inspeções, revisões e testes usada ao longo do processo de software para garantir que cada produto de trabalho satisfaça os requisitos para ele estabelecidos. O conceito-chave do controle de qualidade é que todos os produtos de trabalho têm especificações definidas e mensuráveis com as quais podemos comparar o resultado de cada processo. O autor também define Garantia da Qualidade como um conjunto de funções para auditar e relatar que avalia a efetividade e completeza das atividades de controle de qualidade. A meta da garantia de qualidade é fornecer à gerência os dados necessários para que fique informada sobre a qualidade do produto, ganhando assim compreensão e confiança de que a qualidade do produto está satisfazendo suas metas. Sendo assim, a garantia da qualidade abrange o controle de qualidade e esse último foca as atividades relacionadas aos testes. Pressman (2006, p. 289) também afirma que o teste de software é um elemento de um aspecto amplo, que é frequentemente referido como verificação e validação (V&V). Do exposto, pode-se concluir que os processos de verificação e validação são processos mais associados ao controle que à garantia da qualidade.

Fatores de qualidade de software de McCall.Fonte: Pressman (2006, p.350).

321. Errada.De acordo com Pressman (2006, p. 350), a usabilidade estaria corretamente

classificada se posicionada em #3.

322. Errada.A usabilidade, normalmente (dependendo do domínio modelado), é um requi-

sito não funcional. De acordo com Pressman (2006, p. 350), a interoperabilidade estaria corretamente classificada se posicionada em #2.


200

ELSEVIER

323. Certa.A afirmativa “A revisão técnica formal é atividade central que leva a efeito

a avaliação da qualidade de software.” está correta de acordo com Pressman (2006, p. 585).

324. Errada. Segundo a NBR ISO/IEC 12207:1998, o processo de garantia da qualidade

define atividades para garantir a conformidade dos processos e produtos de software com requisitos e planos estabelecidos. Sendo assim, ele avalia o impacto da falha de software sobre o sistema a ser desenvolvido.

325. Errada. Segundo Pressman (2006, p.685) a manutenção de software pode ser feita

de maneira corretiva, adaptativa, perfectiva ou preventiva.

Manutenção de Software Segundo Pressman (2006, p. 685):• Corretiva: corrigir erros.• Adaptativa: adaptar o software a modificações no seu ambiente externo.• Perfectiva ou de melhoria: fazer melhorias solicitadas pelos usuários• Preventiva ou reengenharia: realizar reengenharia para uso futuro, o

que melhora a manutenibilidade.

326. Certa.A afirmativa está correta segundo a NBR ISO/IEC 12207:1998.

Ciclo de Vida de um Produto de Software Segundo NBR ISO/IEC 12207:1998:

• Processos fundamentais: aquisição, fornecimento, desenvolvimento, operação e manutenção;

• Processos de apoio: documentação, gerência de configuração, garan-tia da qualidade, verificação, validação, revisão conjunta, auditoria e resolução de problema;

• Processos organizacionais: gerência, infraestrutura, melhoria e trei-namento.

• Processo de garantia da qualidade: define as atividades para garantir objetivamente que os produtos e processos de software estão em con-formidade com seus requisitos especificados e aderem aos seus planos estabelecidos. Revisões conjuntas, auditorias, verificação e validação podem ser utilizadas como técnicas para garantia de qualidade.


201

327. Certa.Segundo Sommerville (2003, p. 300), confiabilidade de um sistema é a proba-

bilidade, por um determinado período de tempo, de que o sistema disponibilizará serviços de maneira correta, tal como a afirmativa da questão.

328. Errada.As afirmativas iniciais da questão estão corretas, no entanto, segundo Som-

merville (2003, p. 365), diferentes checklists devem ser preparadas para diferentes linguagens de programação.

329. Certa.A questão aborda de maneira correta as características do teste de partição

de equivalência (SOMMERVILLE, 2003, p. 378), do teste estrutural (SOMMER-VILLE, 2003, p. 382) e do teste de caminho (SOMMERVILLE, 2003, p. 382).

3.8. Orientação a Objetos

330. Errada.A parte da afirmação “... são disponibilizados externamente apenas os mé-

todos que alteram esse objeto...” é falsa, pois pode-se disponibilizar métodos que processam informações sem que seja necessário alterar o objeto e mesmo assim ainda caracteriza o encapsulamento.

Elementos do Paradigma Orientação a Objetos (OO):• Abstração: é o processo de abstrair as características essenciais de

um objeto real. O conjunto de características resultante da abstração forma um Tipo Abstrato de Dados (TAD) com informações sobre seu estado e comportamento.

• Encapsulamento: é o processo de combinar tipos de dados, dados e funções relacionadas em um único bloco de organização e só permitir o acesso a eles através de métodos determinados.

• Herança: é o aproveitamento e extensão das características de uma classe existente.

• Polimorfismo: é a propriedade de se utilizar um mesmo nome ou for-ma para fazer coisas diferentes.

331. Errada.Classe abstrata não gera instância.


202

ELSEVIER

332. Errada. É possível em orientação a objetos implementar os relacionamentos de ge-

neralização e especialização, em OO este relacionamento denomina-se herança.

333. Certa.A questão define corretamente o relacionamento entre os termos “Classe”

e “Objeto”, ou seja, ela afirma que um objeto é a instância de uma classe e que todos os objetos da mesma classe possuem a mesma estrutura.

334. Errada.Agregação ocorre quando um conjunto de instâncias de um objeto forma uma

semântica maior. O conceito apresentado na questão refere-se a polimorfismo.

335. Certa.A questão apresenta de forma correta o que representa os atributos de um

objeto, ou seja, os atributos representam o estado de um objeto.

336. Errada.Todo objeto possui um identificador único que nunca varia com o tempo de

vida do objeto. Esse identificador denomina-se OID (Object Identifier) e é atri-buído no momento de sua instanciação.

337. Certa.De fato, uma classe é capaz de instanciar vários objetos que possuirão a

mesma estrutura.

338. Errada.Classe e interface são dois conceitos independentes.

339. Errada.A parte da afirmação “...A parte de dados de um objeto é definida por um

conjunto de mensagens, e a porção funcional, por um conjunto de atributos.” está errada, pois a parte de dados de um objeto é definida por um conjunto de atributos, e a porção funcional, por um conjunto de mensagens.

340. Errada.A afirmação está errada, pois o objeto é instância da classe, não o contrário.


203

341. Errada.A questão não tem sentido, mas é possível reconhecer o erro quando ela afirma

que “...Polimorfismo permite estabelecer uma interface comum que define os atri-butos que um objeto...”, pois polimorfismo é em relação a métodos e não atributos.

342. Errada.Mensagem é chamada a métodos independente de haver polimorfismo.

343. Errada.Herança é um mecanismo de reutilização de métodos e atributos definidos

em classes gerais por classes mais específicas que pode ser utilizado para expres-sar apenas generalizações/especializações. Outro erro é que herança múltipla é não-linear.

344. Certa.A questão apresenta corretamente uma característica do polimorfismo dinâ-

mico, também denominado sobreposição (overriding) ou sobrescrita. Nesse tipo de polimorfismo uma mesma referência do tipo da superclasse pode apontar para qualquer objeto de uma de suas subclasses. Por exemplo, dada a superclasse “C1” com o método “m1()” e duas subclasses “C2” e ”C3”, ambas herdam automatica-mente o método “m1()” da superclasse. Então é possível que uma variável “a” do tipo “C1” (basta declararmos: C1 a) aponte para os objetos de “C2” ou “C3” (basta chamarmos os construtores das subclasses: C1 a = new C2() ou C1 a = new C3()). Neste caso, se o método “m1()”, herdado pelas subclasses “C2” e “C3” for sobrescrito (reimplementado) em cada uma das subclasses, quando a partir referencia “a” do tipo “C1” chamarmos o método “m1()” ele executará de uma determinada forma quando a referência apontar para um objeto de “C2” (por exemplo, C1 a = new C2(); a.m1();) e de outra forma quando a referência apontar para objeto de “C3” (por exemplo, C1 a = new C3(); a.m1();), tal como a questão afirma.

345. Errada.O projeto inicia-se com o planejamento da solução. Já a implementação é

que se ocupa das atividades de construção do código.

346. Errada.O início da questão já apresenta um erro ao afirmar que “...tipicamente

contém declarações de métodos, mas não corpos de métodos...”, pois classes abs-tratas podem possuir métodos com corpos. Outro erro da questão consiste em afirmar que subclasses de classes abstratas não podem implementar interfaces.


204

ELSEVIER

347. Certa.A questão pode ser facilmente entendida por meio de um exemplo. Dada

uma classe “Ca” que possua o método “m()” e duas subclasses “Cb” e “Cc”. Por serem subclasses de “Ca”, as classes “Cb” e “Cc” herdam automaticamente o método “m()”. No entanto, essas duas subclasses podem reimplementar esse método. Então, caso haja as chamadas do método “m()” a partir de objetos de “Cb” e “Cc”, apesar da assinatura ser a mesma, as implementações dos métodos são distintas possibilitando processamentos diferentes.

348. Errada.Sobreposição ocorre quando um método de uma superclasse é herdado por

uma subclasse e reimplementado para atender às necessidades específicas dessa subclasse.

3.9. Unified Modeling Language (UML)

349. Errada.De fato, o diagrama de componentes é um diagrama estrutural que deve

ser utilizado para representar a configuração e a arquitetura de um sistema no qual estarão ligados todos os software e hardware. No entanto, para representar a interação de um sistema com outros elementos de suporte ao processamento devem ser utilizados os diagramas comportamentais.

A figura abaixo apresenta a taxonomia utilizada por Fowler (2005) para representar os diagramas da UML.


205

350. Certa.O diagrama de sequência realiza um caso de uso, isso quer dizer que esse

diagrama representa como os objetos interagem em um sistema para a reali-zação das funcionalidades representadas em um diagrama de caso de uso. O diagrama de caso de uso também representa a sequência temporal das interações dos objetos.

351. Certa.A questão descreve de maneira correta a principal característica do relacio-

namento de inclusão entre casos de uso, a obrigatoriedade da execução do caso de uso incluído quando o caso de uso principal for executado.

352. Certa.O diagrama de classes é um diagrama estático que pode representar todas

as classes de um sistema e quando se desenha um diagrama dinâmico como, por exemplo, o diagrama de sequência ou o de comunicação, os objetos representados nesses diagramas são instâncias das classes representadas no diagrama de classes. Cabe ressaltar que o diagrama de caso de uso também é muito importante para entender as interações que serão representadas no diagramas de sequência e de comunicação.

353. Certa. Em um diagrama de casos de uso, um ator pode ser um sistema externo, um

usuário ou um hardware que interaja com o sistema representado.

354. Errada.A figura apresentada representa a classe de fronteira pagina_congresso.

355. Errada.A figura representa um diagrama de sequência.

356. Errada.Na figura, a linha cheia representa a chamada ao método ConsTema (), já a

linha pontilhada representa a resposta a esta chamada.

357. Certa.Tal como o enunciado, o eixo horizontal do diagrama de sequência apresen-

tado representa a interação entre objetos, enquanto o eixo vertical representa a sequência temporal das chamadas aos métodos.


206

ELSEVIER

358. Errada.A seta pontilhada “verdadeiro” indica o retorno de uma chamada a método.

359. Errada.No diagrama de caso de uso há herança entre use case e entre os atores

360. Certa.A questão aborda de maneira correta o recurso de multiplicidade em casos

de uso. Na figura, o conteúdo entre chaves representa restrições, que na UML deve sempre aparecer entre chaves. Segundo Fowler (2005, p. 64), uma restrição pode ser descrita em linguagem natural ou linguagem formal (OCL – Object Constraint Language).

361. Certa.Um diagrama de implantação representa a topologia física do sistema e

opcionalmente os componentes que são executados nesta topologia. Apresenta um mapeamento entre os componentes de software e o hardware utilizado. Tal como a afirmação do enunciado, é possível indicar o protocolo na ligação entre dois nós, bem como mostrar relações de dependência entre componentes.

362. Certa.O enunciado está correto, de fato, uma agregação composta presente entre

duas classes indica uma associação do tipo todo parte, em que uma classe é a parte e a outra, o todo. No entanto, existem dois relacionamentos com esta semântica: a agregação e a composição. Na agregação a vida da parte independe do todo, por outro lado, na composição a vida da parte depende o todo. Cabe ressaltar que agregação composta é sinônimo de composição.

363. Errada.O diagrama de sequência descreve as troca de mensagens entre os objetos

sem mostrar as mudanças de estado dos mesmos.

364. Certa.Segundo Fowler (2005, p. 118), os diagramas de atividades são uma técnica

para descrever lógica de procedimento, processo de negócio e fluxo de atividades. De várias formas eles desempenham um papel semelhante aos fluxogramas, mas a principal diferença entre eles e a notação de fluxogramas é que os diagramas de atividades suportam comportamento paralelo. Outro aspecto importante é que os diagramas de atividades são frequentemente utilizados para representar os fluxos de atividades dos diagramas de caso de uso complexos.


207

365. Errada.Segundo Fowler (2005, p. 73), em um diagrama de sequência as mensa-

gens assíncronas são representadas pelo símbolo ‘→’ (seta aberta), enquanto as mensagens síncronas são representadas pelo símbolo ‘‘ (seta fechada). No entanto, a questão faz referência à seta cheia (não pontilhada) o que não é uma característica que diferencie chamadas síncronas de assíncronas e o gabarito considera esta afirmação “ERRADA”. Booch, Rumbauch e Jacobson (2006, p.255) afirmam que “Se a mensagem é assíncrona, a linha tem uma seta fina. Se a mensagem é síncrona (uma chamada), a linha tem uma seta triangular cheia. Uma resposta a uma mensagem síncrona (um retorno de chamada) é exibida por uma linha tracejada com uma seta fina.” Do exposto, pode-se concluir que uma mensagem assíncrona possui uma seta não ponti-lhada, denominada seta fina, pois segundo a definição apresentada apenas a mensagem de retorno possui linha tracejada. Então, o gabarito da questão deveria ser modificado para “CERTO” ou a questão deveria ser cancelada devido à mistura de conceitos.

366. Errada.Um caso de uso representa os aspectos externos de uma funcionalidade

sem os detalhes de implementação. Os objetivos de um caso de uso são: definir escopo, organizar e dividir o trabalho, estimar o tamanho do projeto e direcionar os testes. No entanto, detalhar os processos e cálculos do sistema está fora do escopo de um caso de uso.

367. Certa.A questão aborda de maneira correta o objetivo de um caso de uso.

368. Errada.Em um diagrama UML, a herança é um tipo de relacionamento especial que

apresenta as características do relacionamento de generalização/especialização e de dependência, pois para a subclasse ser compilada é necessário o acesso ao código da superclasse. A herança também é utilizada para identificar, no relacio-namento entre classes, que uma herda o comportamento e a estrutura da outra.

369. Certa.As afirmações estão corretas, pois o ator Supervisor é uma especialização do

ator Professor devido ao relacionamento de herança apresentado na figura. O caso de uso Incluir Faltas é abstrato por estar escrito em itálico. Esse caso de uso pode ser acionado pelo ator Supervisor, pois esse ator pode acionar todos os casos


208

ELSEVIER

de uso acionados pelo ator Professor; devido ao relacionamento de herança. Por outro lado, devido ao relacionamento “include” toda vez que o caso de uso Incluir Notas for acionado o caso de uso Incluir Faltas também será executado. O caso de uso Incluir Conteúdo Programático é abstrato por estar escrito em itálico e representa um segmento opcional de comportamento devido ao relacionamento “extend” com o caso de uso Incluir Nota.

370. Errada.O método #Cadastrar() da classe Instrutor tem visibilidade do modo pro-

tegido devido o símbolo ‘#’ e por isso, segundo a UML, pode ser acessado pela própria classe e pelas suas subclasses.

Modificadores de Visibilidade de Métodos e Atributos de acordo com a UML:• (+) public (publico): o elemento da classe pode ser acessado direta-

mente por qualquer objeto de qualquer classe. • (#) protected (protegido): o elemento da classe pode ser acessado dire-

tamente apenas por objetos da própria classe e de suas subclasses. • (~) package (pacote): o elemento da classe pode ser acessado direta-

mente apenas por objetos da própria classe e de classes do mesmo pacote.

• (-) private (privado): o elemento da classe pode ser acessado direta-mente apenas por objetos da própria classe.

• Obs: em Java, a visibilidade protegida (protected) é menos restritiva que o previsto na UML. O elemento da classe com visibilidade prote-gido, em Java, pode ser acessado diretamente por objetos da própria classe, de suas subclasses e por objetos das classes do mesmo pacote.

371. Certa.Agregação composta é sinônimo de composição, e por isso na associação iden-

tificado por #2, uma instância da classe Departamento pertence exclusivamente a uma única instância de Escola. Devido à multiplicidade do relacionamento entre as classes Escola e Departamento, um objeto de Escola pode relacionar-se com, no máximo, três objetos de Departamento.

Agregação e Composição segundo Booch, Rumbauch e Jacobson (2006, p. 69):• Os autores afirmam que uma associação simples entre duas classes re-

presenta um relacionamento estrutural entre pares, significando que es-sas duas classes estão conceitualmente em um mesmo nível, sem que uma seja mais importante do que a outra.No entanto, em alguns casos, há a necessidade de se fazer a modelagem de um relacionamento “todo/parte”


209

(por exemplo, time/jogador), no qual uma classe represente um item mais importante, “todo” (time), formado por itens menos importantes, “parte” (jogadores). Este tipo de relacionamento é denominado agre-gação. Outro relacionamento “todo/parte” da UML é a composição. No entanto, na agregação, a existência das instâncias que representam as “partes” é independente da existência da instância que representa o “todo”, enquanto que na composição a existência das instâncias que representam as “partes” depende da existência da instância que re-presenta o “todo”.

372. Certa.De fato, o número ‘1’ no canto superior direito dentro indica que esse obje-

to é unitário tal que, em padrões de projeto, pode ser classificado como do tipo singleton, que garante uma única instancia de uma classe. A mensagem #6, por ser pontilhada, representa uma mensagem de retorno sem disparo de método. Finalmente, a mensagem #5 é uma mensagem entre os atores Cliente e Banco que indica somente a ocorrência de um evento.

373. Certa.De fato, #1 é uma interface do tipo fornecida, representada pelo círculo; e

#2 é uma interface do tipo requerida, representada pelo gancho. No entanto, na segunda parte da questão, os conceitos estão invertidos, ou seja, #1 corresponde ao relacionamento de realização e #2 corresponde ao relacionamento de dependên-cia. Devido a esta troca, o gabarito da questão deveria ser mudado para Errada.

374. Certa.A afirmativa cita corretamente os diagramas apresentados na figura, ou seja,

o diagrama de implantação, representado pelos cubos ligados por uma linha e o diagrama de componentes, representado pelos componentes distribuídos no interior dos cubos. Ambos são estruturais.

375. Errada.A questão possui dois erros. Na UML 2.0, é o diagrama de estrutura composta

que é utilizado para modelar colaborações e o diagrama de máquina de estados representa estados de um objeto.

376. Certa.O início do enunciado está correto: “A figura ilustra um diagrama de im-

plantação, usado para modelar a visão estática de implantação de um sistema, que, em geral, envolve a modelagem da topologia do hardware no qual o sistema


210

ELSEVIER

executa.”. Já a continuação, “Essencialmente, são diagramas de classe que inci-dem sobre os nós de um sistema.”, não faz muito sentido. Este texto foi baseado na seguinte afirmativa de Booch, Rumbauch e Jacobson (2006, p. 411): “Os dia-gramas de implantação são essencialmente diagramas de classes que focalizam os nós do sistema.”. Os autores afirmam que o diagrama de implantação pode ser interpretado como um diagrama de classes no qual as classes representam os nós da rede. No entanto, apesar da questão trocar apenas o termo “focalizam” por “incidem sobre” a semântica da afirmação foi dramaticamente mudada. Acreditamos que o correto seria anular a questão.

377. Errada.O erro da questão consiste em afirmar que a classe Pessoa pode ser instancia-

da devido ao fato dessa classe ser abstrata, pois seu nome está escrito em itálico. O restante do enunciado está correto.

378. Errada.O erro da questão consiste em afirmar que o método desconectar, na classe

CntrPersistenciaRelacional, tem visibilidade pública, pois o símbolo utilizado foi o “-“ que indica visibilidade privada (private). Outro potencial problema consiste em afirmar que a classe Grupo herda um atributo da classe Usuario, pois, ape-sar de haver o relacionamento de herança entre as duas classes, o atributo em Usuario é privado e em Java atributo privado não é herdado, mas a questão não afirmava se era para considerar o contexto da UML ou de Java.

379. Certa.De fato, telaA é o nome de uma instância de uma classe, pois o termo que

antecede os dois pontos, em um diagrama de classes, representa o nome da instância da classe. O termo após os dois pontos representa o nome da classe. As três setas diretamente no retângulo representam a criação de objetos, então pode-se afirmar que três objetos são criados. O “X” na linha de vida do objeto (linha vertical pontilhada) representa a destruição de objetos, então dois objetos são destruídos na interação representada. A autochamada é representada por uma seta que sai de um objeto e chega ao próprio objeto que enviou; e a condição de guarda é representada por uma expressão no interior de pois colchetes, então há duas autochamadas e uma delas só é executada se uma condição de guarda for satisfeita. A mensagem da instância de TelaReserva para a de CntrReserva é assíncrona por possuir a seta aberta e a mensagem da instância de TelaResultado para a de CntrReserva é síncrona por possuir a seta fechada (ou cheia).


211

380. Errada.O erro da questão consiste em afirmar que há cinco componentes distribu-

ídos entre os nós. Na verdade, existem quatro componentes (ClienteAplicacao, Stub, ServidorAplicacao e BancoDeDados) e uma interface implementada pelo componente ServidorAplicacao.

381. Errada.Em um diagrama de atividades, separações (forks) e junções (joins) são em-

pregadas quando há atividades em paralelo. No entanto, cada junção tem várias transições de entrada e uma de saída, enquanto que, cada separação tem uma transição de entrada e várias de saída.

382. Certa.A questão apresenta uma definição correta para componentes (módulos de

código), cita o relacionamento de dependência que, de fato, é representado por uma seta com a linha pontilhada e, finalmente, afirma que alguns nós de um diagrama de implantação representam unidades computacionais, outros repre-sentam dispositivos periféricos, o que também está correto.

383. Certa.Para entendermos a afirmativa, que está correta, basta analisarmos um

diagrama de sequência que representa uma visão comportamental do sistema. Esse diagrama representa a interação entre os objetos do sistema. Como os ob-jetos são instâncias de estruturas (classes), esse diagrama representa a dinâmica do sistema nas interações entre seus diversos elementos estruturais, tal como assinalado na afirmativa.

384. Certa.Booch, Rumbauch e Jacobson (2006, p. 452) definem cenário como uma

sequência específica de ações que ilustram o comportamento. Um caso de uso, representa os atores e as funcionalidades disponibilizadas e pode ter várias se-quências distintas de execução, como por exemplo, fluxo principal e alternativo. Cada sequência de um caso de uso é um cenário, então podemos afirmar que um cenário é uma instância de um caso de uso.

385. Errada.Segundo Booch, Rumbauch e Jacobson (2006, p. 98), os diagramas compor-

tamentais são utilizados para visualizar os aspectos dinâmicos de um sistema. Os autores consideram aspectos dinâmicos de um sistema como uma representação


212

ELSEVIER

de suas partes que sofrem alterações tais como fluxo de mensagens ao longo do tempo e a movimentação física de componentes em uma rede, não restringindo apenas às interações com os usuários.

386. Errada.Booch, Rumbauch e Jacobson (2006, p. 98), definem ator como um conjunto

de coerente de papéis que os usuários de casos de uso desempenham quando interagem com esses casos de uso. Pode ser um ser humano, um dispositivo de hardware ou um outro sistema.

387. Certa.A afirmação apresenta uma definição correta para “agregação” segundo

Booch, Rumbauch e Jacobson (2006, p. 69).

388. Certa.Booch, Rumbauch e Jacobson (2006, p. 98) afirmam que uma associação

representa um relacionamento estrutural existente entre objetos. A “quantida-de” de objetos de uma classe associados a um objeto de outra classe representa a multiplicidade da associação entre esses dois objetos que são instâncias de classes. Logo, em diagrama de classes da UML, uma associação entre classes pode ser documentada em termos da multiplicidade da associação.

389. Certa.Um sistema orientado a objetos nada mais é que um conjunto de objetos in-

teragindo para fornecer as funcionalidades requeridas pelos usuários. Os objetos interagem por meio de chamadas a métodos. O diagrama de sequência da UML representa as interações entre os objetos, ou seja, as chamadas à métodos, no entanto, eles também representam o momento em que um usuário, ao clicar uma interface do sistema, aciona um método de um objeto que compõe este sistema.

C a p í t u l o 4

Gabaritos de Gestão de Tecnologia da Informação

4.1. Gerenciamento de Projetos

4.1.1. Conceitos básicos de gerenciamento de projetos

390. Errada.Embora a definição de projeto esteja correta, um projeto não termina somente

quando os objetivos são atingidos. Um projeto também pode ser encerrado caso seus objetivos tornem-se impossíveis de atingir, ou deixem de ser de interesse da organização.

Condições que caracterizam um projeto: • Temporariedade: após alcançar seus objetivos, um projeto deve ser

necessariamente encerrado.• Singularidade: o trabalho realizado para gerar o produto, serviço ou

resultado do projeto é único, diferente de todos os demais projetos.

391. Errada.Os termos citados na questão são utilizados no livro da Kim Heldman, o que

levou o CESPE a considerar inicialmente a questão como certa. Entretanto, como o PMBOK não reconhece os mesmos critérios para encerramento de um projeto, o gabarito definitivo considerou a questão errada.

Condições de término de um projeto, segundo Kim Heldman:• Absorção: ocorre quando a equipe do projeto torna-se responsável pela

operação do produto ou serviço gerado pelo projeto; na visão do PMBOK, o projeto teria simplesmente alcançado seus objetivos e terminado.

• Integração: ocorre quando os recursos do projeto são redirecionados para outros projetos ou para operações da empresa; na visão do PM-


214

ELSEVIER

BOK, isso poderia se dar porque o projeto deixou de ser importante para a organização ou porque verificou-se que os objetivos não são exequíveis.

• Esgotamento: ocorre quando os recursos do projeto são cortados, sem que sejam realocados para outros projetos; na visão do PMBOK, não haveria diferença entre integração e esgotamento.

• Extinção: ocorre quando o projeto simplesmente é encerrado após al-cançar seus objetivos; na visão do PMBOK, também não haveria dife-rença entre absorção e extinção.

392. Errada.As responsabilidades do gerente de projeto limitam-se ao que é necessário

para que o projeto alcance seus objetivos. A otimização de recursos compartilhados entre vários projetos é uma atividade típica da gerência de portfólio, que pode ser exercida por um escritório de projetos.

393. Certa.Serviços continuados – chamados pelo PMBOK de trabalho operacional ou

simplesmente operações – possuem características distintas dos projetos; enquan-to projetos são temporários e singulares, as operações são contínuas e repetitivas.

Entretanto, como o trabalho operacional também precisa ser planejado e controlado, é possível aplicar a maioria das ferramentas de gerenciamento de projetos também ao gerenciamento das operações. A essa prática dá-se o nome de gerenciamento por projetos.

394. Certa.Segundo o PMBOK, enquanto a finalidade dos projetos é alcançar seus obje-

tivos e encerrar, a finalidade das operações é manter o funcionamento do negócio. É justamente esse funcionamento do negócio que pode ser medido de maneira qualitativa (satisfação do cliente, por exemplo) ou com indicadores financeiros.

395. Certa.Os processos de gerenciamento de recursos humanos lidam com a equipe do

projeto, enquanto os processos de gerenciamento de comunicações lidam com as partes interessadas. Portanto, são atividades altamente dependentes das habili-dades interpessoais do gerente e demais membros da equipe do projeto.

Os processos de gerenciamento de custos e de tempo possuem natureza mais técnica e incluem muitas atividades de planejamento nas quais o gerente e a equi-pe aplicam ferramentas específicas, com menor nível de interação interpessoal.

Capítulo 4 I Gabaritos de Gestão de Tecnologia da Informação

215

4.1.2. Portfólios, programas e estruturas organizacionais

396. Certa.Portfólios são compostos por programas, projetos e outras atividades relacio-

nadas ao alcance dos objetivos estratégicos da organização. Uma das atividades do gerenciamento de portfólio é a definição de prioridades para alocação dos recursos, tendo como critério justamente o alinhamento às estratégias organizacionais.

397. Errada.Programas são conjuntos de projetos relacionados entre si, que são agrupados

para se obter benefícios e controle que não estariam disponíveis caso os projetos fossem gerenciados isoladamente. Entretanto, nem todo projeto faz parte de um programa.

398. Certa.Segundo o PMBOK, o principal motivo para a constituição de subprojetos é

a necessidade de delegar responsabilidade a terceiros por uma parte do escopo do projeto. Isso acontece, por exemplo, quando a implementação do subprojeto é feita por uma empresa externa ou por uma unidade funcional da organização.

399. Errada.Estruturas matriciais recebem essa denominação justamente por combina-

rem relacionamentos verticais, oriundos da vinculação hierárquica, e relaciona-mentos horizontais, decorrentes do relacionamento entre participantes de um mesmo projeto. Justamente por isso, os membros da equipe tipicamente possuem atividades tanto no projeto como em sua área funcional de origem.

Tipos de estruturas matriciais:• Matricial fraca: mais próxima da organização funcional, é caracte-

rizada pela delegação de responsabilidades para a equipe do projeto, sem a designação formal de um gerente de projeto em tempo integral.

• Matricial balanceada: embora conte com um gerente de projeto em tempo integral, esse gerente possui baixa autoridade sobre o projeto e sobre os recursos necessários para sua execução.

• Matricial forte: dá maior ênfase à execução de projetos, pela designação de gerentes de projetos em tempo integral com autoridade considerável e alocação de pessoal administrativo do projeto em tempo integral.


216

ELSEVIER

400. Errada.Segundo os diagramas adotados pelo PMBOK para representar as diferentes

estruturas organizacionais, uma situação em que A, B e C sejam gerentes fun-cionais pode caracterizar tanto uma organização funcional como organizações matriciais. Caso A, B e C sejam gerentes de projetos, essa será uma organização projetizada.

Na visão do PMBOK, as operações (priorizadas em estruturas funcionais) tem como finalidade manter o negócio em funcionamento, enquanto os projetos possuem objetivos derivados do plano estratégico da organização. Como iniciativas estratégicas em geral implicam mudanças, enquanto a manutenção do funcio-namento do negócio implica continuidade, pode-se concluir que organizações projetizadas são mais adaptadas à mudança, enquanto organizações funcionais são mais rígidas.

401. Errada.Segundo o PMBOK, os gerentes de projeto têm o mais alto nível de autoridade

e poder em organizações projetizadas.

Características do projeto e estruturas organizacionais, segundo o PMBOK:

Estrutura da organização

Características do projeto

Funcional

Matricial

Por projetoFraca Balanceada Forte

Autoridade do gerente de projetos

Pouca ou nenhuma

LimitadaBaixa a

moderadaModerada

a altaAlta a quase

total

Disponibilidade de recursosPouca ou nenhuma

LimitadaBaixa a

moderadaModerada

a altaAlta a quase

total

Quem controla o orçamento do projeto

Gerente funcional

Gerente funcional

MistoGerente

de projetosGerente de

projetos

Função do gerente de projetosTempo parcial

Tempo parcial

Tempo integral

Tempo integral

Tempo integral

Equipe administrativa do gerenciamento de projetos

Tempo parcial

Tempo parcial

Tempo parcial

Tempo integral

Tempo integral

4.1.3. Escritórios de projetos e outras partes interessadas

402. Errada.A sigla PMO refere-se a Project Management Office (escritório de gerencia-

mento de projetos). Além disso, um escritório de projetos centraliza e coordena


217

alguns aspectos do gerenciamento de projetos sob seu domínio, mas não neces-sariamente mediante integração desses projetos. Essa integração é típica do gerenciamento de programas.

403. Errada.De fato os objetivos do gerente de projeto são distintos dos objetivos de um

escritório de projetos. Entretanto, um PMO tanto pode fornecer suporte ao gerenciamento de projetos como pode também ser responsável por gerenciar diretamente projetos na organização.

404. Errada.

Responsabilidades do gerente de projeto x escritório de projetos:• Gerente de projeto: concentra-se nos objetivos especificados para o

projeto, controlando os recursos atribuídos ao projeto e gerenciando as restrições (escopo, cronograma, custo, qualidade, etc.) para alcan-çar da melhor forma possível tais objetivos.

• Escritório de projetos: gerencia mudanças de escopo de programas e oportunidades para melhor alcançar objetivos de negócio, otimiza o uso de recursos compartilhados e gerencia metodologias, padrões, riscos e interdependências entre projetos.

405. Certa.Embora estruturas funcionais possuam maior foco sobre as operações, ainda

assim organizações desse tipo executam projetos e podem optar pela implantação de um escritório de projetos, assim como em estruturas matriciais ou projetizadas. Da mesma forma, em qualquer dessas situações a organização pode optar por delegar ao escritório de projetos poderes para supervisionar e cancelar projetos em andamento.

406. Errada.A elaboração do plano estratégico da organização não se inclui entre as ati-

vidades típicas de um escritório de projetos, pois não possui relação direta com a padronização, o suporte ou a execução de atividades típicas do gerenciamento de projetos, programas e portfólios.

407. Errada.Partes interessadas (ou stakeholders) são pessoas ou organizações direta-

mente envolvidas no projeto, que podem ser afetadas pelo resultado final ou que


218

ELSEVIER

podem exercer influência sobre a execução do projeto. Justamente por serem elementos-chave para o sucesso do projeto, devem ser identificados e gerenciados de maneira apropriada.

Principais partes interessadas:• Patrocinador (pessoa ou grupo que fornece os recursos financeiros)• Clientes e usuários• Gerente e demais membros da equipe do projeto• Escritório de Projetos• Gerentes de portfólios ou comitê de análise de portfólios• Gerentes de programas• Gerentes funcionais• Gerentes de operações• Fornecedores e parceiros comerciais

4.1.4. Ciclo de vida e grupos de processos

408. Certa.O ciclo de vida define as fases em que o projeto será dividido, o trabalho a ser

realizado em cada fase, os papéis envolvidos, os produtos gerados e os critérios de aprovação. O foco de cada fase é sempre distinto, embora os papéis e habili-dades envolvidos possam ser comuns a várias fases. Como a questão afirma que “geralmente cada fase requer organização e habilidades específicas”, não há erro.

409. Errada.Ao término de cada fase, as entregas correspondentes devem ser revisadas

para garantir que estejam corretas e tenham sido aprovadas. Ao final dessa revi-são, pode-se decidir que o trabalho seja iniciado na próxima fase, que o trabalho da fase atual seja corrigido ou que o projeto seja encerrado.

410. Certa.

Relações entre fases do ciclo de vida:• Fases sequenciais: cada fase só pode ser iniciada após o término e

aprovação da fase anterior; reduz incertezas, mas pode restringe op-ções para compressão do cronograma.

• Fases sobrepostas: permite o início de uma nova fase antes da conclusão da fase anterior; pode aumentar o risco e resultar em retrabalho caso sur-jam problemas que invalidem os produtos gerados de forma antecipada.


219

• Fases iterativas: apenas a fase atual está planejada a cada momen-to, sendo que o planejamento da próxima fase é feito à medida que o trabalho avança; útil em ambientes muito indefinidos ou em rápida transformação.

411. Errada.O projeto que resulta na criação do produto faz parte do ciclo de vida do

produto. Portanto, o ciclo de vida do produto se inicia imediatamente antes do projeto que cria esse produto. Além disso, ao longo do ciclo de vida do produto podem ser executados diversos projetos para modificação ou melhoria desse produto, cada um com seu ciclo de vida (de projeto) próprio.

Relação entre ciclo de vida do projeto e ciclo de vida do produto:

412. Errada.Segundo o PMBOK, em cada fase (ou ao longo do projeto como um todo)

há um primeiro esforço de atividades de iniciação (#1), seguido de um pico de atividades de planejamento (#2), da execução das tarefas do projeto (#4) e das atividades de encerramento (#5), sendo que as atividades de monitoramento e controle (#3) distribuem-se de maneira mais uniforme.

Portanto, a associação correta seria iniciação (#1), planejamento (#2), mo-nitoramento e controle (#3), execução (#4) e encerramento (#5).

413. Errada.Embora diversos autores confundam os dois conceitos, o PMBOK afirma

explicitamente que os grupos de processos não podem ser confundidos com fases do ciclo de vida, uma vez que todos os grupos de processos estão presentes em cada uma das fases.


220

ELSEVIER

414. Certa.Na primeira fase do projeto, a iniciação consiste no desenvolvimento do ter-

mo de abertura e na autorização para início do projeto. Nas fases subsequentes, as premissas constantes do termo de abertura e as decisões tomadas quando da autorização são revistas com base no andamento atual do projeto.

415. Errada.Segundo o diagrama genérico que mostra a interação entre os grupos de

processos no PMBOK 2008, são os grupos de planejamento e execução que ser-vem de entrada um para o outro. Caso se considere os fluxos preponderantes entre os processos de cada área de conhecimento, a exemplo da análise feita por Mulcahy (2009), são os processos de execução e monitoramento e controle que se alimentam mutuamente.

Relação entre os grupos de processos, segundo o PMBOK e Mulcahy (2009):

4.1.5. Gerência de integração

416. Certa.O termo de abertura define as diretrizes para realização do projeto na visão

do cliente ou patrocinador, sendo a principal referência para iniciar a elaboração do plano de gerenciamento do projeto.

Conteúdo do termo de abertura do projeto:• Propósito ou justificativa do projeto.• Objetivos mensuráveis e critérios de sucesso relacionados.• Requisitos e riscos de alto nível.• Resumo do cronograma de marcos e orçamento.


221

• Requisitos para aprovação do projeto.• Gerente do projeto, responsabilidade e nível de autoridade.• Identificação do patrocinador ou emitente do termo de abertura.

417. Certa.A declaração de trabalho (statement of work) é o documento emitido pelo pa-

trocinador ou contratante do projeto do qual constam a necessidade de negócio a ser atendida, a descrição do escopo do produto e a vinculação estratégica do projeto. O business case é um documento complementar que detalha a análise custo-benefício do projeto, considerando a necessidade a ser atendida e o custo esperado do projeto. Ambos servem de entrada para a elaboração do termo de abertura.

418. Errada.O controle integrado de mudanças é processo de monitoramento e controle

que permite tratar as exceções ocorridas no andamento do projeto, incluindo eventuais ações emergenciais para correções de problemas. Um dos objetivos desse processo é garantir que somente mudanças aprovadas (ou pré-aprovadas) sejam incorporadas ao projeto.

419. Errada.O PMBOK descreve o sistema de gerenciamento de configuração como parte

do processo Controle Integrado de Mudanças, que pertence ao gerenciamento de integração.

Objetivos do sistema de gerência de configuração:• Estabelecer método para identificar, solicitar e avaliar mudanças nas

linhas de base de forma consistente.• Validar e melhorar o projeto, ao considerar o impacto de cada mudança.• Comunicar as mudanças de forma consistente às partes interessadas.

420. Certa.Se as mudanças aprovadas estão fora do escopo original do projeto, isso

implica que haverá um acréscimo de produtos ou tarefas e, portanto, a linha de base de escopo será alterada. Entretanto, para que a avaliação do desempenho anterior do projeto não seja distorcida, a nova linha de base somente pode ser utilizada como referência para avaliações a partir desse momento.


222

ELSEVIER

421. Certa.

Categorias de ativos de processos organizacionais:Processos e procedimentos• Normas, políticas e ciclos de vida padrão• Modelos e instruções de trabalho• Políticas e procedimentos de qualidade• Procedimentos de controle financeiro e medição• Procedimentos e critérios para gerenciamentos de riscos e mudanças• Procedimentos e critérios para comunicação e encerramento do projetoBases de conhecimento• Arquivos do projeto (linhas de base, cronogramas, diagramas de rede,

registros de riscos, etc.)• Informações históricas e lições aprendidas• Bases de gerenciamento de configuração• Bases de gerenciamento de questões (issues) e defeitos• Dados de medição de processos e produtos• Dados financeiros

4.1.6. Gerência de escopo

422. Errada.

Processos de gerenciamento de escopo:• Coletar os requisitos: define e documenta as características do projeto

e do produto, necessárias para atender às necessidades e expectativas das partes interessadas.

• Definir o escopo: desenvolve a declaração de escopo do projeto, con-tendo a descrição detalhada do trabalho a ser realizado e do produto resultante.

• Criar a EAP: subdivide as principais entregas e o trabalho do projeto em partes menores e mais facilmente gerenciáveis.

• Verificar o escopo: obtem a aceitação formal das entregas pelas partes interessadas.

• Controlar o escopo: influencia os fatores que criam mudanças no es-copo do projeto, submete as solicitações de mudança ao controle inte-grado de mudanças e controla o impacto das mudanças aprovadas.

423. Errada.A definição do escopo requer conhecimento aprofundado das características

dos produtos do projeto e do trabalho necessário para realizar esses produtos, o


223

que pode requerer consultas a especialistas. Por esse motivo, o PMBOK cita a opinião especializada como ferramenta do processo de definição do escopo.

424. Errada.A EAP define e organiza o escopo total do projeto, o que implica dizer que

todos os produtos e todo o trabalho do projeto devem ser contemplados na EAP, inclusive o trabalho de gerenciamento do próprio projeto.

425. Errada.O termo de abertura do projeto serve de entrada para o processo de definição

de escopo, o qual tem como produto a declaração de escopo do projeto. A EAP é elaborada com base na declaração de escopo, não no termo de abertura.

4.1.7. Gerência de tempo

426. Certa.Embora não cite o processo de controle do cronograma, a questão permane-

ce correta pois afirma que “existem atividades que visam...”, ou seja, a lista de objetivos é apenas exemplificativa dos processos da área de gerência de tempo.

Processos de gerenciamento de tempo:• Definir as atividades: identifica e documenta o trabalho a ser realiza-

do, por meio da decomposição dos pacotes de trabalho em atividades.• Sequenciar as atividades: identifica e documenta os relacionamentos

lógicos entre as atividades do cronograma.• Estimar os recursos das atividades: determina o tipo e as quantidades

de cada recurso usado para realizar as atividades do projeto.• Estimar as durações das atividades: determina o número de períodos

de trabalho (esforço/recursos) para terminar cada atividade do crono-grama.

• Desenvolver o cronograma: determina as datas de início e término planejadas de cada atividade e do projeto como um todo, com base nas estimativas de recursos, duração e sequência das atividades.

• Controlar o cronograma: avalia o andamento atual do cronograma do projeto, controla os fatores que criam mudanças no cronograma e sub-mete as solicitações de mudança ao controle integrado de mudanças.

427. Errada.Embora o PMBOK afirme que os processos de planejamento do tempo podem

ser executados como se fossem um único processo, especialmente em projetos de menor escopo, ainda assim a estimativa de duração das atividades só pode ser


224

ELSEVIER

feita após a estimativa dos recursos, pois o tempo necessário para realizar cada tarefa depende diretamente da quantidade de recursos alocados.

428. Errada.A EAP é instrumento para gerenciamento do escopo do projeto e não con-

templa as atividades do cronograma. Portanto, não é possível gerenciar o tempo do projeto com base na EAP.

429. Errada.O caminho crítico consiste em uma sequência de tarefas do início ao fim do

projeto com folga total nula ou negativa. As atividades que compõem o caminho crítico são chamadas de atividades críticas porque qualquer atraso nessas ativi-dades implica atraso na data de término do projeto e, por esse motivo, atrasos em uma atividade do caminho crítico só podem ser compensados pelo adiantamento de outras atividades do mesmo caminho.

430. Errada.As ferramentas citadas se prestam ao gerenciamento do cronograma (tempo),

mas não dos custos do projeto. Os diagramas de barras (ou gráficos de Gantt) permitem visualizar, além da duração das atividades, as relações de precedência (inclusive o seu tipo), as folgas existentes, o andamento e os marcos do projeto. Já os diagramas de rede representam apenas as atividades e relacionamentos lógicos entre elas.

431. Certa.Os diagramas de rede também são chamados de diagramas (ou gráficos)

PERT, devido ao fato de terem sido criados originalmente como parte da técnica de análise PERT. Também no caso da análise PERT, os riscos mais significativos são considerados na estimativa de duração das atividades para se obter a estima-tiva pessimista para realização de cada atividade.

432. Errada.A linha de base do cronograma é um componente do plano de gerenciamen-

to do projeto, assim como as linhas de base de custos e de escopo. A emissão de relatórios de desempenho de prazos baseia-se na linha de base do cronograma, mas o desempenho de custos adota como parâmetro a linha de base de custos.


225

433. Errada.Ambas as técnicas podem ser usadas tanto para estimativa de custos como

para estimativa de duração das atividades de um projeto. Entretanto, a questão apresenta uma inversão na descrição de características das técnicas.

Técnicas de estimativa de duração e custos de atividades:• Estimativa análoga (duração/custo): utiliza dados históricos de pro-

jetos similares realizados anteriormente para estimar a duração e o custo das atividades de um novo projeto.

• Estimativa paramétrica (duração/custo): utiliza fórmulas matemáti-cas derivadas a partir de análise estatística de dados de projetos an-teriores para estimar a duração e o custo das atividades de um novo projeto.

• Estimativa de três pontos (duração/custo): calcula médias aritméticas simples ou ponderadas a partir de três estimativas distintas (otimista, mais provável e pessimista) para cada atividade, de modo a incorpo-rar o efeito dos riscos conhecidos à duração estimada das atividades.

• Estimativa bottom-up (custo): obtém estimativas de custo para cada pa-cote de trabalho da EAP ou atividade do cronograma, e posteriormente agrega essas estimativas em componentes de mais alto nível do projeto, que são usados para gerenciamento dos custos e elaboração de relatórios.

434. Certa.Vide o comentário da questão seguinte.

435. Errada. Na análise de valor agregado, o cálculo de valores negativos para a variância

(de custos ou prazo) indica que o projeto está com desempenho abaixo do esperado, enquanto variâncias positivas indicam desempenho acima do esperado.

De maneira análoga, caso o índice de desempenho (de custos ou prazo) assu-ma um valor menor do que um, isso indicará que o projeto não está alcançando o rendimento planejado (está acima do orçamento ou atrasado). Caso o projeto esteja adiantado ou gastando menos do que o previsto, os índices de desempenho correspondentes assumirão valores maiores do que um.

Análise de valor agregado – medidas básicas e derivadas:• Valor agregado (VA): é o custo orçado para o trabalho que foi conclu-

ído até um determinado momento; reflete o andamento do escopo do projeto.

4.1.8. Gerência de custos


226

ELSEVIER

• Valor planejado (VP): é o custo orçado do trabalho que deveria ter sido concluído até um determinado momento; reflete o tempo consumido pelo projeto.

• Custo real (CR): mede o custo efetivo da realização do trabalho.• Variação de custos: mede a diferença entre o valor agregado pelo pro-

jeto e o custo real até um dado momento (VA – CR).• Variação de prazos: mede a diferença entre o valor agregado e o tempo

gasto no projeto (VA – VP).• Índicededesempenhodecustos:representaacapacidadedoprojeto

em gerar os produtos planejados dentro do custo esperado (VA/CR).• Índicededesempenhodeprazos:representaacapacidadedoprojeto

em realizar as tarefas de acordo com os prazos planejados (VA/VP).

4.1.9. Gerência de riscos

436. Errada.Segundo o PMBOK, risco é todo evento de natureza incerta que, caso ocorra,

pode causar impactos positivos ou negativos sobre um ou mais objetivos do pro-jeto. Em função disso, o gerenciamento de riscos tem como finalidade aumentar a probabilidade e o impacto de riscos positivos (oportunidades) e reduzir a pro-babilidade e o impacto de riscos negativos (ameaças).

437. Certa.

Ferramentas e técnicas para identificação de riscos:• Técnicas de coleta de informações: brainstorming, técnica Delphi (obten-

ção de consenso entre especialistas), entrevistas, análise de causa raiz.• Análise de listas de verificação (check-lists) e de premissas do projeto.• Técnicas de diagramas: causa e efeito, fluxogramas e diagramas de

influência.• Análise SWOT: pontos fortes e fracos, oportunidades e ameaças.

438. Certa.Embora o objetivo desse processo produzir apenas uma lista com os riscos

do projeto, o PMBOK prevê a possibilidade de que durante a identificação de riscos sejam também identificadas possíveis respostas para alguns riscos. Caso isso ocorra, o resultado será uma lista de respostas potenciais.

439. Certa.Por definição qualquer risco (conhecido ou não) pode representar uma

ameaça ou oportunidade. Entretanto a afirmativa de que “o gerente de projeto


227

deve manter reserva” de recursos para controlar os riscos é altamente questio-nável. Segundo o PMBOK, a manutenção de reservas de contingência de tempo e custo é uma estratégia possível, mas não mandatória. Além disso, as respostas aos riscos devem ser adequadas à relevância do risco e devem observar uma boa relação custo-benefício.

Assim, embora a questão tenha sido dada como certa pelo Cespe, esse en-tendimento não é suportado pelo PMBOK.

440. Certa.A análise qualitativa de riscos é o processo responsável pela priorização dos

riscos identificados, sendo as prioridades atribuídas principalmente em função da probabilidade de que o risco venha a ocorrer e do impacto causado caso o risco ocorra. Para essa priorização, o PMBOK sugere que seja adotada a prática mais comum em processos de gerenciamento de riscos, que consiste em atribuir valores numéricos para probabilidade e impacto e depois multiplicar ambos para obter o nível do risco.

441. Certa.O processo de análise quantitativa de riscos aplica métodos estatísticos para

avaliar o impacto dos riscos priorizados sobre as principais variáveis do projeto, em especial sobre o tempo e o custo.

Técnicas de análise quantitativa de riscos:• Analise de sensibilidade: permite determinar quais riscos apresentam

maior impacto potencial sobre um determinado objetivo do projeto; o resultado da análise é tipicamente apresentado em um gráfico de tor-nado, no qual os riscos são ordenados pelo nível de impacto estimado.

• Análise de valor monetário esperado: calcula o resultado médio espe-rado de cenários futuros, a partir da análise de riscos específicos do projeto; a aplicação mais típica é na construção de árvores de deci-são, que indicam qual decisão produz o resultado mais adequado aos objetivos do projeto, considerando um risco pontual ou um conjunto restrito de riscos.

• Modelagem e simulação: constrói modelos estatísticos que permitem avaliar a probabilidade de se alcançar determinado resultado no pro-jeto, considerando o conjunto de riscos priorizados; em geral é feita por meio da análise de Monte Carlo, técnica que simula iterativa-mente a ocorrência dos riscos individuais e calcula a distribuição de probabilidades em função do impacto combinado desses riscos.


228

ELSEVIER

4.1.10. Gerências de qualidade, RH, comunicações e aquisições

442. Certa.O processo em questão pertence ao grupo de execução e tem exatamente

o objetivo descrito no enunciado. Entretanto, segundo o PMBOK, as entradas desse processo são: plano de gerenciamento do projeto, métricas da qualidade, informações sobre o desempenho do trabalho e medições de controle de qualidade.

Como os itens “reparos de defeitos” e “ações preventivas implementadas” não constam como entradas do processo, essa questão deveria ter sido considerada errada pelo Cespe. É interessante notar que na versão anterior do PMBOK esses dois itens constavam como entradas do processo, mas não o plano de gerencia-mento do projeto. Ou seja, mesmo que se considerasse a versão mais antiga do modelo, a questão deveria ter sido considerada errada.

Processos da gerência de qualidade:• Planejar a qualidade: identifica requisitos e padrões de qualidade do

projeto e do produto e estabelece os métodos a serem utilizados para gerenciamento da qualidade do projeto.

• Realizar a garantia da qualidade: acompanha a execução do projeto para garantir que os processos e padrões de qualidade sejam respeita-dos.

• Realizar o controle da qualidade: avalia os produtos resultantes da exe-cução das atividades e recomenda as eventuais mudanças necessárias.

443. Errada.Os processos da área de gerenciamento de recursos humanos estão listados

corretamente. Entretanto, a questão está errada porque o treinamento é uma das atividades previstas no contexto do processo de desenvolvimento da equipe.

Processos da gerência de recursos humanos:• Desenvolver o plano de recursos humanos: define a estrutura de pes-

soal do projeto – papéis, responsabilidades e habilidades necessárias; define também os processos e critérios para gerenciamento da equipe.

• Mobilizar a equipe do projeto: obtém os recursos humanos necessários para realizar as atividades do projeto.

• Desenvolver a equipe do projeto: desenvolve as competências indivi-duais dos membros da equipe, bem como a capacidade de interação e o trabalho em equipe.

• Gerenciar a equipe do projeto: acompanha o desempenho dos mem-bros da equipe, fornece feedback e resolve conflitos para otimizar o desempenho do projeto.


229

444. Certa.

Técnicas de resolução de conflitos:• Retirada: ocorre quando uma das partes se retira para evitar que o

conflito se estabeleça ou que tenha continuidade.• Acomodação: busca minimizar as diferenças que deram origem ao confli-

to e enfatizar as áreas de concordância entre as partes (“panos quentes”).• Negociação: identifica concessões possíveis de cada parte para encon-

trar soluções que proporcionem alguma satisfação para todas as partes. • Imposição: consiste em forçar a aceitação de um ponto de vista às

custas de outro (“ganha-perde”).• Colaboração: construção conjunta de solução que incorpore diferentes

opiniões e perspectivas, com foco na obtenção de consenso e compro-misso (“ganha-ganha”).

• Confronto/Solução de problemas: trata o conflito como um problema que deve ser solucionado com o exame lógico de alternativas.

445. Errada.Segundo o PMBOK, os canais de comunicação de um projeto envolvem sempre

duas pessoas. Assim, a quantidade de canais de comunicação é dada pelo número de combinações possíveis das pessoas do projeto, duas a duas, o que resulta na seguinte fórmula: C = P x (P – 1)/2, onde C é o número de canais e P é o número de pessoas no projeto.

No caso descrito pela questão, a primeira fase do projeto conta com 780 canais de comunicação (40 x 39/2) e a segunda fase conta com 300 canais (25 x 24/2), logo, a diferença é de 480, e não 455.

Processos da gerência de comunicações:• Identificar as partes interessadas: além da identificação de todas as

partes interessadas, analisa os níveis de interesse, expectativas, im-portância e influência de cada parte interessada e desenvolve estraté-gias adequadas ao nível de envolvimento requerido no projeto.

• Planejar as comunicações: determina as necessidades de informações e comunicações das partes interessadas – quem precisa de qual infor-mação, quando precisarão dela e como ela será fornecida e por quem.

• Distribuir as informações: coloca as informações à disposição das partes interessadas no momento oportuno.

• Gerenciar as expectativas das partes interessadas: gerencia as comu-nicações para satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas.


230

ELSEVIER

• Reportar o desempenho: distribui informações consolidadas sobre o desempenho às partes interessadas.

446. Certa.

Processos da gerência de aquisições:• Planejar as aquisições: identifica as necessidades do projeto que po-

dem ser atendidas por meio de aquisições, define a abordagem a ser utilizada em cada aquisição e identifica fornecedores potenciais.

• Realizar as aquisições: encaminha as solicitações de propostas aos fornecedores potenciais, obtém respostas, seleciona fornecedores a se-rem contratados e assina os contratos necessários.

• Administrar as aquisições: orienta e monitora o desempenho do con-trato para assegurar que as partes cumpram suas obrigações.

• Encerrar as aquisições: verifica se as entregas de cada contrato foram consideradas aceitáveis e finaliza as aquisições do projeto.

447. Certa.O PMBOK prevê a utilização de dois tipos de critérios para a seleção de

fornecedores a serem contratados: critérios de seleção, também chamados de sis-temas de triagem, que permitem determinar quais fornecedores são considerados aceitáveis para o projeto; e critérios de ponderação, que permitem classificar os fornecedores aceitáveis com base em fatores previamente definidos, aos quais podem ser atribuídos pesos numéricos.

448. Certa.O PMBOK lista os seguintes critérios aplicáveis à seleção de fornecedores:

entendimento da necessidade pelo fornecedor, custo geral da proposta (custo da compra mais custo operacional do produto, ou custo do ciclo de vida), capacidade de produção, capacidade e abordagens técnica e de gerenciamento, risco, capaci-dade financeira e garantias providas, tamanho e tipo da empresa, desempenho passado, referências e reivindicações quanto a direitos de propriedade intelectual e sobre o trabalho.

449. Errada.Segundo o PMBOK, as ferramentas e técnicas do processo em questão são:

auditorias de aquisições, acordos negociados e sistema de gerenciamento de registros. A opinião especializada não é citada como ferramenta desse processo, embora apareça em diversos outros no PMBOK.


231


4.2.1. CMMI – Conceitos básicos e estrutura

450. Errada.Embora o CMMI tenha sido projetado para integrar diversas disciplinas em

um modelo comum, as especializações para serviços e aquisição surgiram apenas na versão 1.2, com o conceito de constelação. Além disso, cada constelação reúne conjuntos de componentes específicos, o que torna a questão errada.

O CMMI 1.2 criou o conceito de “constelação” – componentes comuns, usados em modelos, materiais de treinamento e roteiros de avaliação para uma área – e definiu três constelações:

• CMMI para Desenvolvimento (CMMI-Dev), que se aplica ao desenvol-vimento e à manutenção de produtos e serviços, inclusive serviços que não sejam de TI.

• CMMI para Aquisições (CMMI-Acq), uma adaptação do CMMI-Dev para organizações que contratam o desenvolvimento.

• CMMI para Serviços (CMMI-Svc), que aborda o fornecimento e geren-ciamento de serviços de qualquer natureza, também sendo aplicável a serviços que não sejam de TI.

No CMMI 1.3 passou a existir o CMMI Model Foundation (CMF), conjunto de elementos comuns a todos os modelos CMMI, no qual são descritas 16 áreas de processo que existem em todos os modelos, com variações mínimas.

451. Certa.Essas são características inerentes ao CMMI para Desenvolvimento, que

abrange tanto o desenvolvimento como a manutenção de produtos e serviços.

452. Errada.Objetivos genéricos (ou metas genéricas) são comuns a todas as áreas de

processo e referem-se ao estágio de institucionalização dos processos, e não aos resultados específicos de cada área de processo.

CMMI – Principais componentes:• Metas Específicas: se aplicam a cada área de processo e descrevem os

resultados que devem ser alcançados para satisfazer a área de proces-so.

• Práticas Específicas: atividades consideradas importantes para al-cançar as metas específicas de uma área de processo.

• Metas Genéricas: são associadas aos níveis de capacidade e recebem


232

ELSEVIER

essa denominação porque a mesma afirmação de meta se aplica a todas as áreas de processo.

• Práticas Genéricas: atividades para garantir que os processos sejam efetivos, repetíveis e duradouros.


454. Errada.Na estrutura do CMMI, as metas (específicas e genéricas) são elementos

requeridos, as práticas (específicas e genéricas) são elementos esperados e todos os demais componentes (notas, exemplos, relatórios, etc.) são elementos infor-mativos. Entretanto, o CMMI afirma explicitamente que o glossário não é um componente informativo do modelo, sendo apenas uma lista de termos com os respectivos significados.

CMMI – Classificação dos componentes:• Requeridos: o alcance de metas é usado como base para determinar a

capacidade de áreas de processo e a maturidade organizacional.• Esperados: espera-se que as práticas (ou alternativas aceitáveis) este-

jam presentes para que as metas possam ser alcançadas.• Informativos: fornecem detalhes que ajudam a compreender as metas

e práticas e como elas podem ser realizadas.

455. Errada.No CMMI 1.2 (p. 18) consta explicitamente a afirmativa de que o glossário

não é um componente informativo do modelo, sendo apenas uma lista de termos com os respectivos significados.

4.2.2. CMMI – Níveis de capacidade e maturidade

455. Errada.As duas representações do CMMI são baseadas nos mesmos elementos: áreas

de processo, metas e práticas. Até a versão 1.2 do modelo, apenas a representa-ção contínua utilizava as metas e práticas genéricas de níveis 4 e 5, enquanto a representação por estágios ficava limitada às metas e práticas genéricas de níveis 2 e 3. Na versão 1.3 as metas e práticas de níveis 4 e 5 foram eliminadas, o que tornou as duas representações idênticas em seus componentes.


233

456. Certa.A avaliação de cada área de processo pode resultar na atribuição de um nível

de capacidade de 0 a 5 (na versão 1.2) ou de 0 a 3 (na versão 1.3). Como essa prova foi aplicada antes do lançamento da versão 1.3, não há erro nesse ponto. A avaliação da organização resulta em um nível de maturidade de 1 a 5, qual-quer que seja a versão utilizada. Por fim, cada nível de maturidade contempla um conjunto específico de áreas de processo que devem alcançar determinadas metas genéricas – ou seja, que devem alcançar determinado nível de capacidade.

457. Errada.

A representação contínua permite à organização determinar a prioridade e o nível de investimento desejado na melhoria de cada área de processo, enquanto a representação por estágios impõe a sequência de áreas de processo a serem implementadas e o nível de capacidade necessário para cada uma das áreas.

Representações do CMMI:• Contínua:avaliacadaáreadeprocessodemaneiraisolada,emníveis

de capacidade que variam de 0 a 5 (CMMI 1.2) ou de 0 a 3 (CMMI 1.3). Como as áreas são tratadas de maneira independente, cada or-ganização pode definir seu próprio perfil alvo – quais áreas de proces-sos deverão alcançar quais níveis de capacidade.

• Por estágios: avalia o processo organizacional como um todo, em fun-ção de etapas bem definidas de melhoria. A maturidade organizacio-nal é medida em níveis de 1 a 5, com base em conjuntos predefinidos de áreas de processo e níveis de capacidade dessas áreas, associados a cada nível.

458. Certa.O nível 1 de capacidade está associado à meta genérica 1, que exige o alcance

das metas específicas. De maneira análoga, existe apenas uma prática genérica de nível 1, a qual indicar a necessidade de implementação das práticas específicas. Portanto, para avaliar se uma área de processo alcançou o nível 1 de capacidade, é necessário verificar a execução das práticas específicas associadas à área.

459. Certa.As características citadas na questão correspondem a práticas genéricas de

nível 2 do CMMI.

CMMI – Práticas Genéricas de Nível 2:• 2.1 Estabelecer política organizacional


234

ELSEVIER

• 2.2 Planejar o processo• 2.3 Prover recursos• 2.4 Atribuir responsabilidades• 2.5 Treinar pessoas• 2.6 Gerenciar a configuração• 2.7 Identificar e envolver as partes interessadas• 2.8 Monitorar e controlar o processo• 2.9 Avaliar objetivamente a aderência do processo• 2.10 Revisar o status com a alta administração

460. Certa.À primeira vista pode-se achar que a questão esteja errada (e o CESPE havia

cometido esse erro no gabarito preliminar), uma vez que as características citadas correspondem a práticas genéricas de nível 2. Entretanto, é preciso lembrar que os níveis de capacidade e maturidade no CMMI são cumulativos e, portanto, todas as características de nível 2 devem continuar presentes nos níveis subsequentes, o que torna a questão certa.

461. Certa.Mais uma questão que aborda o fato do CMMI ser organizado em patamares

sucessivos de capacidade/maturidade, onde o alcance de níveis mais elevados pressupõe, no mínimo, a manutenção das condições exigidas para os níveis ante-riores. Assim, o planejamento é prática genérica de nível 2, mas continua sendo necessário para o alcance do nível 3 de maturidade.

462. Certa.O nível 4 de maturidade do CMMI é caracterizado pelo gerenciamento quan-

titativo do processo organizacional, o que é descrito na primeira parte da questão. A previsibilidade qualitativa, atribuída ao nível 3 de maturidade, corresponde ao fato de que a existência de um processo padrão permite prever que tipo de resultados serão obtidos pela aplicação desse processo, ainda que isso se dê de maneira subjetiva. Entretanto, como essa é uma interpretação mais avançada do modelo, que não consta explicitamente da documentação, a questão acabou sendo anulada pelo Cespe.

CMMI – maturidade x previsibilidade de processos:• Nível 1 – Inicial: o trabalho é realizado de maneira improvisada (ad-hoc),

o que impede previsões sobre o desempenho e o resultado dos projetos.• Nível 2 – Gerenciado: é possível prever o desempenho de cada projeto,

com base na experiência acumulado de projetos similares anteriores.


235

• Nível 3 – Definido: é possível prever o desempenho dos projetos da or-ganização em geral, com base nas características do processo padrão.

• Nível 4 – Gerenciado quantitativamente: a previsibilidade dos proje-tos passa a ser descrita de maneira precisa com base em indicadores de desempenho coletados de diversos projetos executados com base no mesmo processo padrão da organização.

• Nível 5 – Em otimização: além do desempenho do processo padrão, torna-se possível prever também as alterações nesse desempenho cau-sadas por intervenções de melhoria em processos, métodos e ferramen-tas adotadas pela organização.

463. Errada.A explicitação e eliminação de causas de defeitos é característica típica do

nível 5 de maturidade, mais especificamente do processo de gerenciamento do desempenho organizacional presente no CMMI 1.3 (anteriormente chamado de (antigo “inovação e implantação organizacional”, no CMMI 1.2).

464. Errada.

Trata-se de uma questão bastante atípica, que cobrou detalhes do método de avaliação do CMMI – o SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Os níveis de avaliação do método SCAMPI dizem respeito ao rigor e ao nível de profundidade com que a organização é avaliada, e não tem nenhuma ligação com os níveis de maturidade resultantes dessa avaliação.

CMMI – Níveis de avaliação SCAMPI:• SCAMPI A: método mais rigoroso, exige a demonstração do cumpri-

mento das metas vinculadas a cada nível de capacidade ou maturidade e é o único que tem como resultado a atribuição de uma classificação formal.

• SCAMPI B: método intermediário, permite a seleção de áreas e práti-cas de forma mais flexível, mas avalia a implementação das práticas em uma escala fixa do modelo.

• SCAMPI C: oferece maior flexibilidade ao permitir que a organização determine o nível de granularidade e os critérios adotados para ava-liação das áreas de processos e práticas existentes.

4.2.3. CMMI – Áreas de Processo

465. Errada.O atendimento a marcos regulatórios é contemplado como um dos aspectos

que deve ser observado na área de processo de desenvolvimento de requisitos. A


236

ELSEVIER

área de processo de gerenciamento de riscos abrange riscos de diversas origens e naturezas, inclusive aqueles relacionados a processos. Por fim, a inovação organizacional é abordada de maneira sistemática pela área de processo de ge-renciamento do desempenho organizacional.

466. Errada.A área de processo de gerenciamento de requisitos pertence ao nível de

maturidade gerenciado (nível 2), e não ao nível definido (nível 3). Por sua vez, a área de gerenciamento de riscos pertence ao nível definido, não ao gerenciado.

CMMI – Níveis de maturidade x Áreas de processo:• Nível 2 – Gerenciado: gestão de requisitos, planejamento de projeto,

monitoramento e controle de projeto, garantia da qualidade de pro-cesso e produto, gestão de contrato com fornecedores, gestão de confi-guração, medição e análise.

• Nível 3 – Definido: definição dos processos da organização, foco nos processos da organização, treinamento na organização, gestão inte-grada de projeto, gestão de riscos, desenvolvimento de requisitos, so-lução técnica, integração de produto, validação, verificação, análise e tomada de decisões.

• Nível 4 – Gerenciado Quantitativamente: desempenho dos processos da organização, gestão quantitativa de projeto.

• Nível 5 – Em otimização: análise e resolução de causas, gerenciamen-to do desempenho da organização.

467. Certa.A questão faz referência às metas específicas da área citada: determinar as

causas de defeitos e tratar as causas de defeitos.

468. Errada.Esse é um bom exemplo de um aspecto sempre difícil na análise de questões

de prova: até que ponto podemos aceitar a troca dos termos “oficiais” do modelo por outros termos similares? Nessa questão em particular, a troca de “suporte” por “apoio” como uma das categorias seria perfeitamente aceitável. Porém, ao substituir “gerenciamento de projeto” por “gerenciamento de produto”, há uma troca de significado importante que torna a questão errada, pois “produto” não é sinônimo e nem similar a “projeto”.

CMMI 1.3 – Categorias de áreas de processo:• Gestão de projeto: gestão de requisitos, planejamento de projeto, moni-

toramento e controle de projeto, gestão de contrato com fornecedores,


237

gestão integrada de projeto, gestão de riscos, gestão quantitativa de projeto.

• Gestão de processo: foco nos processos da organização, definição dos processos da organização, treinamento na organização, desempenho dos processos da organização, gestão do desempenho da organização.

• Engenharia: desenvolvimento de requisitos, solução técnica, integra-ção de produto, verificação, validação.

• Suporte: gestão de configuração, garantia da qualidade de processo e produto, medição e análise, análise e tomada de decisões, análise e resolução de causas.

469. Errada.As áreas citadas pertencem todas à categoria de processos de engenharia.

470. Certa.Embora contenha uma falha na estrutura semântica, a questão foi dada como

certa pelo Cespe. Segundo as regras gramaticais vigentes, a expressão “a qual” remete ao substantivo mais próximo na frase, que é “organização”. Entretanto, quem “fornece [...]medidas comuns, baselines de desempenho [...]” é a “área de processo de desempenho do processo organizacional” citada no início da frase.

471. Errada.A questão cita produtos de trabalho típicos, elementos que são descritos no

detalhamento das práticas específicas do CMMI. As declarações de necessidades e objetivos de processos da organização são pertinentes à área de foco no processo da organização, enquanto listas de fontes de riscos são descritas na área de gestão de riscos, ambas pertencentes ao nível 3 de maturidade.

472. Errada.O nível de capacidade 1 exige apenas que as metas específicas da área de

processo sejam alcançadas, no entanto a questão fala em normas e políticas organizacionais, que são características do nível 2 de capacidade. Além disso, a questão cita a área de processo de validação, entretanto relatórios de avaliação de produtos COTS são produtos típicos da área de solução técnica e testes de cobertura de caminhos são atividades pertinentes à área de verificação.

473. Certa.Essa é uma questão inteligente, que exige raciocínio sobre o modelo e não

apenas o tradicional “decoreba” de processos e metas. A chave da questão está


238

ELSEVIER

na natureza cumulativa dos níveis de maturidade do CMMI, em que os requisitos para um nível qualquer de maturidade devem ser mantidos quando se evolui para os níveis seguintes.

Assim, todas as organizações que alcançam o nível 3 de maturidade (e para isso implementam as práticas de desenvolvimento de requisitos) devem manter as práticas exigidas para o nível 2 (dentre as quais, as de gestão de requisitos). Por outro lado, há diversas organizações de nível 2 que não adotam ainda as práticas de nível 3. Por esse motivo, é correto dizer que as práticas de gerenciamento de requisitos são mais frequentes do que as práticas de desenvolvimento de requisitos.

474. Errada.O gerenciamento de interfaces entre componentes constitui prática específica

da área de processo de integração de produto.

CMMI – Definição, desenho e gerenciamento de interfaces:No âmbito das áreas de processo de engenharia do CMMI, o termo interface

é utilizado para referenciar as conexões entre componentes do produto sendo desenvolvido, ou entre o produto e outros produtos ou sistemas. Portanto, deve--se tomar cuidado para não confundir essas interfaces entre componentes com as interfaces de um sistema com seus usuários.

Os requisitos de interfaces entre componentes são identificados na área de desenvolvimento de requisitos, dando origem a implementações sob responsa-bilidade da área de solução técnica, as quais serão gerenciadas pela área de integração de produto para garantir a compatibilidade entre as interfaces dos diversos componentes.

475. Certa.Inicialmente é importante lembrar que componentes requeridos são as metas,

enquanto componentes esperados são as práticas. De fato, nas metas e práticas da área de gestão de riscos não consta nenhuma orientação sobre a abordagem a ser utilizada pelas organizações – quantitativa ou qualitativa. Além disso, mesmo no detalhamento de subpráticas e produtos de trabalho – componentes informativos do CMMI – também não há nenhuma prescrição sobre os métodos a serem utilizados para implementação das práticas.

476. Errada.A primeira parte da questão está certa ao afirmar que produtos da área

de solução técnica direcionam aquisições feitas pelo projeto. Uma das práticas específicas da área de solução técnica consiste em “analisar alternativas: desen-volver, comprar ou reusar”. Assim, caso a escolha recaia sobre a aquisição de


239

componentes do produto, essa aquisição será feita pela área de processo de gestão de contratos com fornecedores.

Entretanto, a questão se encerra declarando que ambas as áreas pertencem à categoria de suporte, o que é errado. A área de solução técnica pertence à ca-tegoria de processos de engenharia, enquanto a área de gestão de contratos com fornecedores é da categoria de gestão de projetos.

477. Certa.Essa foi uma questão bastante difícil, cujo conteúdo o Cespe transcreveu

literalmente do CMMI. O problema é que o texto cita avaliações de processos e produtos (atividades típicas de validação), gerenciamento de configuração (há um processo para isso) e medições e análises (idem), todos associados ao desen-volvimento do plano do projeto.

Essa associação pode sugerir ao candidato que a questão estaria errada, por aparentemente misturar conceitos e produtos típicos de outras áreas de processos. Entretanto, como o conteúdo foi apenas copiado da descrição da área de processos de planejamento do projeto, é inegável que a questão esteja certa.

478. Errada.A estrutura analítica do projeto (EAP) é um artefato voltado para a definição

do escopo do projeto; no CMMI, a EAP é tratada como produto de trabalho típico da prática de estimativa de escopo, presente na área de processo de planejamento de projeto.

479. Errada.Mais uma questão difícil, que aborda as práticas específicas de uma área de

processos. Nesse caso em particular, a questão enumera práticas da área de pla-nejamento de projetos. Dentre as práticas listadas, há duas que não pertencem ao processo em questão: monitoramento do riscos e revisão de planos.

4.2.4. MPS.BR – Conceitos básicos e níveis de maturidade

480. Errada.Um princípio básico não apenas do MPS.BR, mas de todos os modelos de

processos aplicados à gestão de TI, é que quanto maior a qualidade do processo, maiores as chances de obter produtos de qualidade.



240

ELSEVIER


483. Certa.

MPS.BR – Principais elementos e características:• Referências: CMMI 1.2, ISO/IEC 12.207 (processos do ciclo de vida de

software) e ISO/IEC 15504 (avaliação de processos).• Componentes: modelo de referência (MR-MPS), método de avaliação

(MA-MPS) e modelo de negócio (MN-MPS).• Guias e documentos: guia geral, guia de aquisição, guia de imple-

mentação (em sete partes, um para cada nível de maturidade), guia de avaliação e documentos do programa.

• Características: 7 níveis de maturidade, para implementação mais gradual e com maior visibilidade de resultados; compatibilidade com normas internacionais; criado para a realidade brasileira, com custo acessível e foco em empresas de software de pequeno porte.

484. Certa.Ao contrário do CMMI, que avalia a implementação de áreas de processo

com base na implementação de práticas (esperadas) e no cumprimento de metas (requeridas), o MPS.BR baseia-se apenas nos resultados esperados de processos e de atributos de processos.

485. Certa.Embora o MPS.BR não atribua formalmente níveis de capacidade aos pro-

cessos, prevalece o conceito de capacidade como elemento necessário ao alcance da maturidade organizacional. E assim como ocorre no CMMI, os níveis de maturidade apresentam requisitos acumulativos, onde o alcance de um nível mais elevado de maturidade requer a preservação ou ampliação da capacidade já alcançada pelos processos da organização.

Dessa forma, para que a organização alcance o nível F de maturidade, de-vem ser implementados todos os processos pertinentes aos níveis G e F, e tais processos devem exibir todos os atributos de processo exigidos nos níveis G e F.

486. Certa.Os requisitos dos níveis de maturidade no MPS.BR são cumulativos, assim

como na representação por estágios do CMMI. Ou seja, para se alcançar níveis de maturidade mais altos é necessário preservar todas as características exigidas dos níveis mais baixos.


241


488. Errada.No MPS.BR, o nível G é o de menor maturidade, enquanto o nível A é o de

mais alta maturidade.

MPS.BR – Níveis de maturidade:• A – Em otimização: não possui processos associados na versão 2009

do MPS.BR; na versão 1.2, continha o processo Análise de Causas de Problemas e Resolução.

• B – Gerenciado Quantitativamente: Gerência de Projetos (evolução).• C – Definido: Gerência de Riscos, Desenvolvimento para Reutilização,

Gerência de Decisões, Gerência de Reutilização (evolução).• D – Largamente Definido: Verificação, Validação, Projeto e Construção

do Produto, Integração do Produto, Desenvolvimento de Requisitos• E – Parcialmente Definido: Gerência de Projetos (evolução), Gerência

de Reutilização, Gerência de Recursos Humanos, Definição do Proces-so Organizacional, Avaliação e Melhoria do Processo Organizacional

• F – Gerenciado: Medição, Garantia da Qualidade, Gerência de Con-figuração, Aquisição, Gerência de Portfólio de Projetos (esse último, somente na versão 2009).

• G – Parcialmente Gerenciado: Gerência de Requisitos, Gerência de Projetos.

489. Errada.O MPS.BR prevê a possibilidade de excluir determinados processos da

avaliação de maturidade, quando for demonstrado que aqueles processos não se aplicam à organização avaliada. Por exemplo, organizações que realizam 100% de seus projetos internamente podem excluir do escopo da avaliação o processo de Aquisição.

4.2.5. MPS.BR – Processos

490. Certa.Além do objetivo do processo de gerenciamento de requisitos estar correto,

a afirmativa de que esse processo é essencial para a qualidade é suportada pela própria estrutura do modelo: para que a organização possa alcançar o primeiro nível de maturidade (nível G), é obrigatória a implementação do gerenciamento de requisitos em seus projetos.


242

ELSEVIER

491. Errada.A descrição atribuída ao processo de desenvolvimento para reutilização cor-

responde ao processo de integração de produto. Por sua vez, a descrição atribuída ao processo de integração de produto refere-se, na verdade, ao processo de projeto e construção de produto.

492. Errada.A descrição atribuída ao processo de verificação corresponde ao processo de

validação. O objetivo da verificação é garantir que os produtos estão de acordo com os requisitos.

493. Errada.De acordo com a descrição dos resultados esperados do processo de gerência

de projetos, os repositórios de estimativas e os ativos de processo organizacional citados pela questão são usados como referência para o planejamento do projeto somente a partir do nível E de maturidade. Nos níveis G e F, as estimativas de esforço e custo são feitas com base em dados históricos.

494. Certa.Trata-se de um dos resultados esperados do processo de gerência de recursos

humanos, que pertence ao nível E do MPS.BR.

4.3. Gerenciamento de Serviços

4.3.1. ITIL – Conceitos básicos e estrutura do modelo

495. Certa.Segundo o ITIL v3, serviço é um “meio para entregar valor pela facilitação

de resultados sem que o cliente tenha que assumir a responsabilidade por custos e riscos específicos”.

Ou seja, embora o Cespe tenha considerado essa questão como certa, o con-ceito do ITIL é ligeiramente diferente: custos e riscos específicos não são mini-mizados por meio do serviço, e sim encapsulados de maneira tal que o cliente se preocupe e assuma apenas os custos e riscos do serviço como um todo.

496. Certa.

ITIL v3 – Principais inovações:• Abordagem baseada no ciclo de vida dos serviços.• Visão integrada de infraestrutura, aplicações, processos e pessoas.• Visão integrada de TI, áreas de negócio e fornecedores.• Novos processos para preencher lacunas da versão anterior.


243

497. Errada.A segurança da informação e a continuidade de serviços (ou contingência,

como se refere a questão) são tratadas por meio de processos definidos explici-tamente no livro de desenho de serviços.

ITIL 2011 – Publicações da biblioteca:• Estratégia de Serviço (Service Strategy): trata da definição de estra-

tégias e modelos de funcionamento da organização, bem como a for-ma como requisitos de negócio são identificados e documentados por meio de pacotes de nível de serviço (SLP – Service Level Packages).

• Desenho de Serviço (Service Design): abrange a concepção do serviço em todos os seus aspectos, que são documentados em um pacote de desenho de serviço (SDP – Service Design Package).

• Transição de Serviço (Service Transition): descreve as ações neces-sárias para implementação, teste e validação do serviço, bem como a manutenção da base de conhecimento (SKMS – Service Knowledge Management System) usada para gerenciamento do serviço no am-biente de produção.

• Operação de Serviço (Service Operation): trata das atividades, pro-cessos e funções para que o serviço seja mantido em funcionamento de acordo com o acordo de nível de serviço estabelecido.

• Melhoria Contínua de Serviço (Continual Service Improvement): abrange os investimentos em medição e melhoria de serviços e dos processos de gerenciamento de serviços.

Orientações complementares: publicações adicionais com orientações especí-ficas para setores da indústria, tipos de organização, modelos de funcionamento e arquiteturas tecnológicas.


499. Certa.Os elementos descritos pelo ITIL – processos, funções, papéis e atividades –

tratam da implementação de boas práticas de gerenciamento de serviços aplicáveis a organizações públicas ou privadas, quaisquer que seja o porte ou a estrutura dessas organizações.

A afirmativa de que o ITIL trabalha de forma segmentada justifica-se pela separação das atividades em processos distintos, por sua vez agrupados em livros de acordo com os estágios do ciclo de vida. Além disso, tais processos não possuem qualquer vínculo com plataformas tecnológicas específicas.


244

ELSEVIER

500. Certa.A ênfase em gerenciamento de riscos na fase de estratégia está associada ao

próprio conceito de serviço adotado pelo ITIL, que pressupõe que o prestador de serviço deve assumir a responsabilidade pelos custos e riscos específicos da TI.

Na fase de desenho o gerenciamento de riscos está presente principalmente nos processos de gerência de disponibilidade, continuidade e segurança, enquanto na fase de transição o foco se altera para o gerenciamento dos riscos de que a colocação de um serviço novo ou alterado em produção possa prejudicar a esta-bilidade do ambiente e o cumprimento dos acordos de nível de serviço.

4.3.2. ITIL – Estratégia de serviços

501. Certa.Estes são exatamente os processos descritos no livro de estratégia de servi-

ços na versão inicial do ITIL v3, publicada em 2007. Na atualização do modelo ocorrida em 2011 foram acrescentados novos processos a esse estágio.

ITIL 2011 – Processos de Estratégia de Serviços:• Gerenciamento da estratégia de serviços de TI• Gerenciamento de portfólio de serviços• Gerenciamento financeiro para serviços de TI• Gerenciamento de demandas• Gerenciamento de relacionamento com o negócio

502. Errada.A identificação, a análise e o tratamento de padrões de atividade do negócio

são de responsabilidade do processo de gerenciamento de demandas.

503. Certa.Embora todos os livros do ITIL v3 tragam inovações em relação à versão

anterior do modelo, o livro de Estratégia de Serviços apresenta tais inovações em maior quantidade e complexidade: assuntos como modelos de prestação e contratação de serviços (sourcing), estágios de desenvolvimento organizacional, alocação de capacidades e recursos na construção de portfólios de serviço e méto-dos para definição de valor esperado e mensuração de retorno de investimentos em serviços.



245

505. Errada.De acordo com o ITIL, a capacidade e os processos de gerenciamento de ser-

viços devem ser vistos como ativos estratégicos da organização, pois “fornecem a base para competências essenciais, desempenho diferenciado, vantagens duráveis e qualificações para participar de oportunidades de negócios”. Portanto, ambas as questões estão erradas por referirem-se aos processos e ao gerenciamento de serviços como ativos operacionais.

506. Certa.O modelo de provimento de serviços baseado em utility consiste na otimização

do uso dos recursos de um provedor de serviço, por meio do compartilhamento intensivo de recursos entre serviços distintos (eventualmente, serviços para clientes distintos). Em geral, esse modelo é adotado por provedores externos de serviços, e a cobrança se dá em função do volume de recursos utilizados.

Já o modelo de serviços gerenciados representa a situação típica da maioria das organizações, que investem na aquisição ou construção de recursos próprios para sustentação exclusiva dos serviços de interesse da organização.

Assim, o modelo baseado em utility oferece maior escalabilidade porque não requer investimentos diretos da organização cliente, que pode simplesmente soli-citar do provedor de serviço a alocação de maior capacidade para atender às suas necessidades. Como não há investimento em recursos próprios, o gerenciamento de capacidade dos recursos fica a cargo do provedor de serviço. Por outro lado, o trânsito e o armazenamento de informações em sistemas de terceiros podem dar origem a riscos quanto à confidencialidade da informação.

507. Errada.Embora essa questão tenha sido considerada certa no gabarito preliminar

do concurso, o Cespe posteriormente alterou o gabarito com base na justificati-va de que os estágios de desenvolvimento organizacional são, segundo o ITIL, apenas “similares a níveis de maturidade”. Ainda assim, vale ressaltar que o desenvolvimento da estratégia de serviço deve considerar em qual estágio de desenvolvimento a organização se encontra, e os estágios enumerados na questão estão de acordo com o descrito no livro de Estratégia de Serviço.

ITIL v3 – Estágios de Desenvolvimento Organizacional:• Rede: colaboração informal para entrega rápida de serviços, com foco

acentuado na tecnologia.• Direção: estabelecimento de hierarquias rígidas, com foco no controle

centralizado das atividades das diversas áreas.


246

ELSEVIER

• Delegação: transferência da autonomia dos gerentes funcionais para gerentes de processo.

• Coordenação: maior envolvimento da alta gerência na coordenação centralizada dos processos descentralizados de gerenciamento de ser-viços.

• Colaboração: adoção de estruturas totalmente matriciais, com foco no atendimento às necessidades de negócio.

4.3.3. ITIL – Desenho de serviços

508. Errada.As características e os processos citados referem-se ao livro de Desenho de

Serviços.

ITIL 2011 – Processos de Desenho de Serviços:• Gerenciamento do Catálogo de Serviços• Coordenação do Desenho de Serviços• Gerenciamento de Nível de Serviço• Gerenciamento de Capacidade• Gerenciamento de Disponibilidade• Gerenciamento de Continuidade de Serviços de TI• Gerenciamento de Segurança da Informação• Gerenciamento de Fornecedores

509. Certa.O processo de gerenciamento de continuidade de serviços de TI tem como

objetivo manter a capacidade de recuperação dos serviços de TI em casos de desastres, para atender aos requisitos do negócio. A definição desses requisitos de negócio é feita por processos de gerenciamento de continuidade de negócio.

510. Errada.O catálogo de serviços oferece, às pessoas autorizadas, uma fonte centrali-

zada de informações sobre os serviços de TI providos pela organização. Assim, um indicador chave para avaliar o desempenho do processo seria a quantidade de variações entre as informações do catálogo e a situação real dos serviços. A questão está errada porque o número de produtos produzidos pela organização não tem qualquer relação com o bom funcionamento do processo de gerencia-mento do catálogo de serviços.

511. Certa.Os acordos de nível de serviço firmados entre uma organização e seus

clientes tratam dos requisitos do serviço sob a ótica de negócio. Para que seja


247

possível assegurar o cumprimento de tais requisitos de negócio, as áreas técnicas responsáveis pelo desenho, transição e operação do serviço precisam conhecer os requisitos específicos para cada área. O instrumento para isso é o acordo de nível operacional, que é firmado entre as áreas internas e a equipe responsável pelo gerenciamento de nível de serviço.

512. Certa.O enunciado corresponde à definição de disponibilidade adotada pelo ITIL.

Ainda segundo o modelo, a disponibilidade é determinada pela confiabilidade, sustentabilidade, funcionalidade, desempenho e segurança do serviço.

ITIL v3 – Componentes da disponibilidade de serviço:• Confiabilidade: período durante o qual um serviço de TI ou outro

item de configuração pode executar a sua função acordada sem inter-rupção.

• Sustentabilidade: velocidade com que um serviço de TI ou outro item de configuração pode ser restaurado à operação normal após uma falha.

• Funcionalidade: habilidade que um fornecedor tem de cumprir os ter-mos do seu contrato, no que se refere à disponibilidade de um item de configuração.

• Desempenho.• Segurança.

513. Certa.

ITIL v3 – Métricas do gerenciamento de disponibilidade:• Mean time between failures (MTBF): período durante o qual um ser-

viço opera normalmente, entre períodos consecutivos de indisponibili-dade.

• Mean time to restore service (MTRS): período durante o qual um ser-viço fica fora do ar, logo após a ocorrência de um incidente e até que retorne à operação normal.

• Mean time between service incidents (MTBSI): período entre inciden-tes consecutivos, correspondente à soma do MTRS (tempo de indispo-nibilidade após o incidente) e do MTBF (tempo de operação normal até a ocorrência do próximo incidente).

• Mean time to repair (MTTR): período necessário para reparar o item de configuração responsável pela ocorrência do incidente, antes que o serviço possa retornar à operação normal.


248

ELSEVIER

514. Certa.

ITIL v3 – Estratégias para recuperação de desastres:• Workaround Manual: uso de solução não baseada em TI para superar

a interrupção de serviços de TI.• Recuperação Gradual (Cold Standby): uso de local alternativo (stan-

dby) para no qual os serviços são implantados somente após a ocor-rência do desastre; tipicamente implicam tempos de recuperação su-periores a 72h.

• Recuperação Intermediária (Warm Standby): uso de local alternativo que já se encontra previamente preparado para receber os serviços, sendo apenas ativado quando da ocorrência de um desastre; normal-mente permitem a recuperação em períodos de 24 a 72h.

• Recuperação Imediata (Hot Standby): manutenção de local alternati-vo no qual os serviços encontram-se ativos e sincronizados com o site principal, o que permite o uso imediato quando da ocorrência de um desastre; geralmente requerem no máximo 1 a 2 horas para recuperação do serviço.

4.3.4. ITIL – Transição de serviços

515. Errada.A descrição corresponde ao estágio de transição de serviços.

ITIL 2011 – Processos de Transição de Serviços:• Gerenciamento de conhecimento• Gerenciamento da mudança• Gerenciamento da configuração e ativos de serviço• Planejamento e suporte da transição• Gerenciamento de liberação e implantação• Validação e teste • Avaliação da mudança

516. Errada.O planejamento e suporte da transição é responsável pela coordenação dos

recursos utilizados pelos demais processos do estágio de transição. No entanto, a questão afirma que “os processos de transição de serviço [...]e a coordenação dos recursos [...] são de responsabilidade do processo de planejamento e suporte da transição”, o que está errado.


249

517. Errada.Embora a gerência de configuração e a gerência de ativos possuam focos

distintos (reunidos em um só processo pelo ITIL v3), a questão erra ao afirmar que a gerência de configuração não mantém informações sobre os relaciona-mentos existentes entre os ativos, já que esse é um dos principais objetivos do processo.

518. Certa.Para que uma mudança seja autorizada, o gerenciamento de mudanças pre-

cisa consultar o sistema de gerência de configuração para identificar as áreas que serão impactadas e avaliar se tal impacto é aceitável. Uma vez implementada a mudança (pelo gerenciamento de liberação), o gerenciamento de configuração registra as alterações nos itens de configuração.

519. Errada.O gerenciamento de mudanças avalia e autoriza solicitações de mudança

previamente elaboradas, ou seja, não é responsável por definir as características da mudança a ser efetuada. No âmbito do ITIL v3, a decisão entre desenvolver ou comprar um novo software é tomada no âmbito das atividades do estágio de Desenho de Serviço.

520. Errada.Um release do tipo delta realmente inclui somente os itens de configuração

novos ou alterados desde a última liberação. Já um release total inclui todos os itens de configuração do serviço.

4.3.5. ITIL – Operação de serviços

521. Certa.O estágio de Operação de Serviços é responsável por garantir a geração dos

resultados esperados dos serviços em conformidade com os acordos de nível de serviço estabelecidos, o que inclui a otimização de custos e recursos.

522. Certa.

ITIL 2011 – Processos e Funções de Operação de Serviços:• Gerenciamento de eventos• Gerenciamento de incidentes• Gerenciamento de problemas• Atendimento de solicitações


250

ELSEVIER

• Gerenciamento de acesso• Central de Serviços (Service Desk) (função)• Gerenciamento de aplicações (função)• Gerenciamento de operações (função)• Gerenciamento técnico (função)

523. Certa.

ITIL v3 – Objetivos conflitantes da operação de serviços:• Visão interna (TI) x visão externa (negócio): a visão técnica é necessá-

ria para gestão dos componentes dos serviços, mas não pode se sobre-por aos requisitos de qualidade dos usuários para desses serviços.

• Estabilidade x tempo de atendimento: a infraestrutura de TI deve ser estável para oferecer a disponibilidade esperada, ao mesmo tempo em que deve ser flexível para adaptar-se a mudanças de requisitos do negócio.

• Qualidade x custo: os serviços devem atender aos SLAs estabelecidos, ao menor custo possível e com uso otimizado dos recursos.

• Atividades reativas x proativas: é importante antecipar-se aos possí-veis problemas, desde que isso não implique mudanças excessivas ou perda da capacidade de reação.

524. Errada.O Service Desk é uma função, e não um processo.

ITIL v3 – Características de processos x funções:Processos:• Descrevem dependências e sequências de ações executadas em respos-

ta a eventos específicos.• Geram resultados específicos e mensuráveis (é possível contar ou me-

dir os resultados de um processo, mas não de uma função).• Possuem clientes definidos, para quem são entregues os resultados

gerados.• Utilizam feedback para correção do desempenho.Funções:• Unidades organizacionais especializadas em certos tipos de trabalho

e responsáveis por resultados específicos.• Possuem capacidades e recursos necessários para alcance dos resultados.


251

525. Errada.O volume de chamadas recebidas pode aumentar e diminuir conforme a

variação das demandas dos usuários, sem qualquer relação com o desempenho do service desk. Métricas adequadas para avaliar o service desk seriam, por exemplo, a taxa de resolução de chamados no primeiro contato e o tempo médio para solução de incidentes.


527. Certa.A gerência de incidentes tem como objetivo restaurar o serviço normal o mais

rápido possível, enquanto a gerência de problemas tem como objetivo diagnos-ticar a causa raiz de um ou mais incidentes. As solicitações de mudança (RFC) são registradas como resultado desse diagnóstico e da documentação de um erro conhecido a ser corrigido por meio da mudança solicitada.

528. Certa.Segundo o ITIL, um problema é a causa desconhecida de um ou mais in-

cidentes. Portanto, um problema pode resultar em múltiplos incidentes. Além disso, como o processo de gerenciamento de incidentes é responsável por tentar restaurar o serviço o mais rapidamente possível, normalmente um problema só é registrado e diagnosticado após a ocorrência de múltiplos incidentes relacionados à mesma causa raiz.

529. Errada.Se a organização “possui alto nível de maturidade no modelo ITIL”, pres-

supõe-se que os processos sejam executados exatamente na forma sugerida pelo modelo. Nesse caso, se há X registros de erros conhecidos, deveria haver aproximadamente o mesmo número de registros de problemas (cada problema diagnosticado com sucesso dá origem a um erro conhecido), múltiplos incidentes para cada problema/erro conhecido (problema é a causa de um ou mais incidentes) e apenas um release para cada erro conhecido (uma vez diagnosticado o problema, a solução deveria ser imediata e efetiva).

530. Certa.As afirmativas contidas na questão são características atribuídas pelo ITIL

v3 à função de gerenciamento de operações.


252

ELSEVIER

531. Certa.Além das atividades citadas na questão, o ITIL relaciona outras igualmen-

te relacionadas ao estágio de Operação de Serviços: administração de bases de dados, gerenciamento de serviços de diretório, suporte a estações de trabalho, gerenciamento de middleware, gerenciamento de Internet, gerenciamento de instalações físicas e data centers, gerenciamento de segurança e melhoria de atividades operacionais.

4.3.6. ITIL – Melhoria contínua de serviços

532. Errada.Essas são características do livro de Melhoria Contínua de Serviços.

533. Errada.O modelo de melhoria contínua de serviços (chamado de abordagem de me-

lhoria contínua, no ITIL 2011) recomenda que seja avaliada a maturidade dos processos de gerenciamento de serviço, e não dos serviços de TI. Além disso, não há recomendação explícita para adoção do modelo de maturidade genérico do Cobit.

534. Certa.Tanto o modelo de melhoria contínua como o processo de melhoria em sete

passos baseiam-se nos princípios de melhoria contínua do modelo PDCA.

4.4. Governança de TI

4.4.1. Cobit – Conceitos básicos


536. Certa.A primeira questão simplesmente transcreve de maneira literal o conceito

de governança de TI adotado pelo Cobit. Já a segunda enfatiza, além da tomada de decisão por executivos e diretores, o gerenciamento de riscos como uma das áreas de foco da governança de TI.



253

538. Certa.A agregação de valor e a mensuração de desempenho são áreas de foco da

governança de TI, conforme descrito pelo Cobit.

Cobit 4.1 – Focos da governança de TI:• Alinhamento estratégico: vinculação entre TI e negócios, tanto no pla-

nejamento como nas operações.• Entrega de valor: garantia de alcance dos benefícios, com otimização

de custos.• Gerenciamento de recursos: otimização dos investimentos e do uso dos

recursos de TI.• Gerenciamento de riscos: incorporação do tratamento de riscos e da

conformidade nos processos.• Mensuração de desempenho: Uso do Balanced Scorecard (BSC) para

avaliar todas as dimensões da TI.

539. Certa.Segundo o Cobit, objetivos de controle são declarações dos resultados deseja-

dos ou do propósito a ser alcançado pela implementação de controles sobre uma atividade. Além dos objetivos de controle (de alto nível e detalhados) específicos de cada processo, o Cobit descreve seis requisitos de controle (ou controles gerais) aplicáveis a todos os processos.

540. Errada.O texto da questão descreve o conceito de controle contido no Cobit.

541. Errada.O texto da questão descreve o critério de eficiência, e não disponibilidade.

Cobit 4.1 – Critérios da Informação:• Efetividade: informação relevante e pertinente para o processo de ne-

gócio, entregue em tempo, de maneira correta, consistente e utilizável.• Eficiência: entrega da informação por meio do melhor (mais produti-

vo e econômico) uso dos recursos.• Confidencialidade: proteção de informações confidenciais para evitar

a divulgação indevida.• Integridade: fidedignidade e totalidade da informação, bem como sua

validade de acordo os valores de negócios.• Disponibilidade: disponibilidade da informação quando exigida pelo

processo de negócio hoje e no futuro, o que implica a salvaguarda dos recursos necessários e capacidades associadas.


254

ELSEVIER

• Conformidade: aderência a leis, regulamentos e obrigações contratu-ais aos quais os processos de negócios estão sujeitos, isto é, critérios de negócios impostos externamente e políticas internas.

• Confiabilidade: entrega da informação apropriada para os executivos administrarem a entidade e exercerem suas responsabilidades fiduci-árias e de governança.

542. Errada.Os sistemas automatizados são contemplados pelo recurso “aplicativos”.

Cobit 4.1 – Recursos de TI:• Aplicativos: sistemas automatizados para usuários e procedimentos

manuais que processam as informações.• Informações: dados em todas as suas formas, processados por siste-

mas de informação em qualquer formato a ser utilizado pelos negó-cios.

• Infraestrutura: tecnologia e recursos (ou seja, hardware, sistemas operacionais, sistemas de gerenciamento de bases de dados, redes, multimídia e os ambientes que abrigam e dão suporte a eles) que pos-sibilitam o processamento dos aplicativos.

• Pessoas: funcionários (internos, terceirizados ou contratados) reque-ridos para planejar, organizar, adquirir, implementar, entregar, su-portar, monitorar e avaliar os sistemas de informação e serviços.

543. Errada.Segundo a documentação da versão 4.1, o Cobit é tanto um modelo como

uma ferramenta de suporte.

544. Certa.O modelo COSO é a principal referência conceitual para implementação e

auditoria de controles internos. Por esse motivo, o COSO foi utilizado como base para construção do Cobit e, assim, uma organização que adote o Cobit estará, automaticamente, atendendo aos requisitos do COSO para controle da TI.

545. Certa.A afirmativa de que o Cobit é “o único framework gerencial que trata todo

o ciclo de vida de TI” deixou de ser verdadeira após a publicação do ITIL v3, ao final do ano de 2007. Portanto, essa questão deveria ter sido dada como errada pelo Cespe, que provavelmente baseou-se em alguma referência antiga para elaboração do enunciado.


255

4.4.2. Cobit – Características gerais

546. Certa.

Cobit 4.1 – Características gerais do modelo:• Focado no negócio: alinhamento dos objetivos de TI a objetivos de

negócio e monitoramento do alcance dos resultados esperados.• Orientado a processos: organização das atividades de TI em um mo-

delo de processos, com identificação de responsabilidades pela execu-ção.

• Baseado em controles: definição dos objetivos de controle a serem consi-derados para cada processo, bem como das práticas de controle necessá-rias.

• Dirigido por métricas: uso de indicadores e modelos de maturidade.

547. Certa.O Cobit é orientado a processos, mas baseado em controles. Ou seja, o foco

principal do modelo está no controle e não na execução dos processos.

548. Errada.Indicadores de meta (KGI) ou métricas de resultado indicam se os objetivos

do processo foram alcançados. Para avaliar o processo durante a sua execução e determinar se “o processo de TI está atingindo os requisitos”, são usados os indicadores de performance (KPI).

549. Errada.Os controles de aplicação podem ser específicos, de responsabilidade do

negócio, ou genéricos, de responsabilidade da área de TI. A descrição contida na questão refere-se ao controle de revisão de saídas, reconciliação e tratamento de erros (AC5), e não ao controle de autenticação de transação e integridade (AC6).

Cobit 4.1 – Controles gerais de aplicação:• AC1 Preparação e Autorização de Dados Originais: os documentos

fonte devem ser preparados por pessoal autorizado e de acordo com procedimentos estabelecidos.

• AC2 Entrada e Coleta de Dados Fontes: a entrada de dados deve ser feita por pessoal autorizado, e eventuais erros devem ser corrigidos.

• AC3 Testes de Veracidade, Totalidade e Autenticidade: as transações devem ser exatas, completas e válidas.

• AC4 Processamento Íntegro e Válido: a integridade e validade dos dados são preservadas em todos os ciclos de processamento.


256

ELSEVIER

• AC5 Revisão das Saídas, Reconciliação e Manuseio de Erros: as saí-das são manuseadas de forma autorizada, entregues para os destina-tários corretos e protegidas durante a transmissão.

• AC6 Autenticação e Integridade das Transações: dados transmitidos entre aplicativos e funções de negócio são verificados quanto à auten-ticidade da origem e integridade do conteúdo.

550. Certa.Embora todos os controles gerais de processos sejam aplicáveis a todos os pro-

cessos do Cobit, a menção de “alguns requisitos de controle genéricos” não torna a questão errada. Se todos são aplicáveis, logo alguns são aplicáveis. A questão so-mente se tornaria errada se dissesse que “apenas alguns requisitos” são aplicáveis.

Cobit 4.1 – Controles gerais de processos:• PC1 Metas e Objetivos do Processo: define e comunica metas e objeti-

vos específicos, mensuráveis e ligados aos objetivos de negócio, para cada processo de TI.

• PC2 Propriedade dos Processos: designa um proprietário para cada processo de TI, com responsabilidades claramente definidas.

• PC3 Repetibilidade dos Processos: estabelece processos consistentes que possam ser repetidos e produzam os resultados esperados; usa processos personalizados apenas quando inevitável.

• PC4 Papéis e Responsabilidades: designa papéis e responsabilidades para execução das atividades-chave do processo.

• PC5 Políticas, Planos e Procedimentos: Define e comunica políticas, planos e procedimentos que direcionam os processos de TI.

• PC6 Melhoria de Performance do Processo: identifica métricas para a performance e resultados dos processos, coleta dados e toma provi-dências quanto aos desvios quando necessário.

551. Certa.Segundo o Cobit, os indicadores de objetivo (KGI) avaliam resultados e,

portanto, podem ser expressos em função dos critérios da informação (efetivi-dade, eficiência, confidencialidade, integridade, disponibilidade, conformidade e confiabilidade). Já os indicadores de desempenho (KPI) avaliam a execução dos processos e podem ser expressos em função dos recursos utilizados (aplicações, dados, infraestrutura e pessoas).

552. Certa.O enunciado da questão apenas transcreveu literalmente a descrição cons-

tante do Cobit sobre os três níveis de métricas: TI, processos e atividades.


257

553. Certa.Como os KGI indicam se os resultados foram ou não alcançados, são chamados

de indicadores de passado ou lag indicators. Já os KPI, que medem a execução do processo para prever se o resultado será ou não alcançado, são chamados de indicadores de futuro ou lead indicators.

554. Errada.O Cobit adota a mesma lógica do Balanced Scorecard, segundo a qual os

indicadores de uma perspectiva medem o alcance dos objetivos naquele nível e permitem prever se será possível alcançar os objetivos do nível seguinte. Na nomenclatura do Cobit, os indicadores de resultado (KPI) de um nível tornam-se indicadores de desempenho (KPI) do nível superior.

Assim, o alinhamento entre metas de negócio e resultados da TI poderia ser calculado pela utilização de indicadores de resultado da TI como indicadores de desempenho do negócio (a questão inverte os termos resultado/desempenho na descrição dos indicadores).

555. Questão Certa.A figura em questão representa a lógica de definição e mensuração de metas

e indicadores do Cobit. A definição de metas se dá na sequência negócio > TI > processos > atividades, enquanto o direcionamento do desempenho se dá no sentido contrário.

4.4.3. Cobit – Modelo de maturidade


557. Certa.No modelo de maturidade genérico, o Cobit descreve as características gerais

de processos situados em cada um dos níveis de maturidade, de 0 a 5. No modelo de maturidade específico, o Cobit descreve, para cada um dos 34 processos, o perfil específico do processo em cada nível de maturidade.

Nos dois casos, embora cada nível apresente melhorias em relação ao nível anterior, o Cobit afirma explicitamente que os níveis não representam patamares evolutivos porque, ao contrário do que ocorre no CMM/CMMI, as características de um nível não são requisito para o alcance do nível seguinte. Assim, é possível alcançar o nível 4, por exemplo, sem cumprir os requisitos exigidos para o nível 3.


258

ELSEVIER


559. Questão Errada.Os níveis de maturidade no Cobit variam de 0 a 5 e são utilizados para avaliar

cada processo individualmente, e não o “conjunto de melhores práticas de gover-nança”. Além disso, o monitoramento de conformidade com os procedimentos é característica do nível 4 de maturidade.

Cobit 4.1 – Níveis de maturidade:• 0 – Inexistente: não há atividades do processo, pois a organização não

reconhece que existe uma questão a ser trabalhada.• 1 – Inicial/Ad-hoc: a organização reconhece a necessidade do proces-

so, mas a abordagem é improvisada, aplicada caso-a-caso.• 2 – Repetível, porém Intuitivo: procedimentos similares são seguidos

por diferentes pessoas fazendo a mesma tarefa, mas não existe treina-mento formal e a responsabilidade é dos indivíduos.

• 3 – Processo Definido: procedimentos foram padronizados, documen-tados e comunicados e são obrigatórios, porém é possível que desvios do padrão não sejam detectados.

• 4 – Gerenciado e Mensurável: a gerência monitora e mede a aderência aos procedimentos e adota ações onde os processos parecem não estar funcionando; automação e ferramentas são utilizadas de maneira li-mitada.

• 5 – Otimizado: adoção/evolução de melhores práticas, como resultado de aprimoramento contínuo e automação dos processos de TI.

560. Errada.O cenário descrito no enunciado corresponde ao nível 2 de maturidade –

repetível, mas intuitivo. Há dois elementos chave para identificar esse nível de maturidade: “existe uma abordagem para avaliar riscos”, ou seja, existe algum nível de consistência, mas não há um padrão formal; e “implementar a avaliação depende de decisão do gerente”, logo o processo não é obrigatório.

561. Certa.Esse é o uso típico do modelo de maturidade, segundo a visão do Cobit 4.1:

avaliar os processos atuais, comparar a situação com referências de padrões internacionais e benchmarking com organizações similares; e definir objetivos de melhoria para sanar as lacunas mais importantes entre a situação atual e a desejada.


259

562. Certa.Além do modelo de maturidade genérico e do modelo de maturidade especí-

fico, o Cobit 4.1 traz um terceiro modelo, baseado nos atributos de maturidade (chamadas no enunciado da questão de “variáveis”), dentre os quais encontram-se as ferramentas de suporte e competências.

Cobit 4.1 – Modelo de atributos de maturidade:• Consciência e comunicação• Políticas, planos e procedimentos• Ferramentas e automação• Habilidades e especialização• Responsabilidade e responsabilização• Definição de objetivos e medição

563. Certa.A questão apenas transcreve literalmente um trecho do Cobit. Segundo o

modelo, o aspecto de capability refere-se a como os processos são executados, a cobertura reflete a abrangência das atividades descritas pelo processo e o aspecto de controle preocupa-se com a verificação de que as atividades estejam em con-formidade com os padrões definidos para o processo.

4.4.4. Cobit – Domínios e processos

564. Errada.Os processos do Cobit são organizados em domínios que mapeiam responsa-

bilidades típicas de planejamento, construção, processamento e monitoramento da área de TI. O erro está em afirmar que essas áreas têm atuação alternada ao longo do tempo, quando se sabe que a maioria dos processos ocorre de forma simultânea nas organizações.

565. Errada.A questão faz referência a processos de três domínios distintos: o processo

de gerenciamento de riscos (planejamento e organização), o processo de garantia de continuidade de serviços (entrega e suporte) e o processo de gerenciamento de mudanças (aquisição e implementação).

Cobit 4.1 – Domínios e processosPlanejamento e Organização• PO1 Definir um Plano Estratégico de TI• PO2 Definir a Arquitetura da Informação• PO3 Determinar as Diretrizes de Tecnologia


260

ELSEVIER

• PO4 Definir os Processos, a Organização e os Relacionamentos de TI• PO5 Gerenciar o Investimento de TI• PO6 Comunicar Metas e Diretrizes Gerenciais• PO7 Gerenciar os Recursos Humanos de TI• PO8 Gerenciar a Qualidade• PO9 Avaliar e Gerenciar os Riscos de TI• PO10 Gerenciar ProjetosAquisição e Implementação• AI1 Identificar Soluções Automatizadas• AI2 Adquirir e Manter Software Aplicativo• AI3 Adquirir e Manter Infraestrutura de Tecnologia• AI4 Habilitar Operação e Uso• AI5 Adquirir Recursos de TI• AI6 Gerenciar Mudanças• AI7 Instalar e Homologar Soluções e MudançasEntrega e Suporte• DS1 Definir e Gerenciar Níveis de Serviços• DS2 Gerenciar Serviços Terceirizados• DS3 Gerenciar o Desempenho e a Capacidade• DS4 Assegurar a Continuidade dos Serviços• DS5 Garantir a Segurança dos Sistemas• DS6 Identificar e Alocar Custos• DS7 Educar e Treinar os Usuários• DS8 Gerenciar a Central de Serviço e os Incidentes• DS9 Gerenciar a Configuração• DS10 Gerenciar Problemas• DS11 Gerenciar os Dados• DS12 Gerenciar o Ambiente Físico• DS13 Gerenciar as OperaçõesMonitoramento e Avaliação• ME1 Monitorar e Avaliar o Desempenho de TI• ME2 Monitorar e Avaliar os Controles Internos• ME3 Assegurar a Conformidade com Requisitos Externos• ME4 Prover Governança de TI

566. Errada.No domínio de planejamento e organização encontra-se o processo “Deter-

minar as Diretrizes de Tecnologia” (PO3), que estabelece os padrões a serem adotados para a infraestrutura tecnológica. Com base em tais padrões, é o processo “Adquirir e Manter Infraestrutura de Tecnologia” (AI3), do domínio de aquisição


261

e implementação, quem concretiza a implementação da infraestrutura de acordo com os padrões estabelecidos e determina os procedimentos para manutenção dessa infraestrutura.

567. Certa.O domínio de aquisição e implementação possui processos para identificar a

melhor solução para atendimento às necessidades de negócio (AI1), desenvolver e manter os softwares e a infraestrutura que compõem a solução (AI2 e AI3), adquirir os recursos necessários (AI5) e capacitar os usuários das áreas de ne-gócio (AI4). Por fim, o gerenciamento (AI6) e a homologação (AI7) de mudanças também fazem parte desse domínio.

568. Certa.Embora os aspectos de segurança da informação não sejam tratados exclusi-

vamente no domínio de entrega e suporte, é nesse domínio que se encontra o pro-cesso “Garantir a Segurança dos Sistemas”, citado explicitamente pela questão.

569. Anulada.Embora a relação de processos associados ao domínio de entrega e suporte

esteja correta, a questão cita indevidamente “tecnologia” e “infraestrutura” como tipos distintos de recursos de TI. Essa era a terminologia utilizada no Cobit 3.0 (que considerava haver cinco tipos de recursos). A partir do Cobit 4.0, os recursos tecnológicos passaram a fazer parte do tipo “infraestrutura”. Essa questão foi anulada pela banca em função dessa diferença entre as versões do modelo.


571. Errada.A primeira questão lista indicadores associados ao processo “Definir os

Processos, a Organização e os Relacionamentos de TI”, pertencente ao domínio de planejamento e organização. Já os indicadores citados pela segunda questão referem-se ao processo “Gerenciar os Recursos Humanos de TI”, também do mesmo domínio.

Vale ressaltar que ambas as questões poderiam ser respondidas mesmo sem um conhecimento detalhado dos indicadores citados. Por definição, os indicadores-chave medem os aspectos mais importantes de cada processo e, portanto, estão sempre diretamente associados ao propósito geral dos respec-tivos processos.


262

ELSEVIER

572. Errada.A descrição do objetivo do processo “Garantir a segurança dos sistemas” e

sua vinculação ao domínio de entrega e suporte estão corretas. Entretanto, o indicador citado ao final da questão avalia a cobertura de processos críticos de negócio por um plano de disponibilidade, uma responsabilidade do processo de “Gerenciar o desempenho e a capacidade” (DS3).

573. Errada.O processo citado pela questão – “Comunicar Metas e Diretrizes Gerenciais”

(PO6) – tem como principais objetivos a formalização e a disseminação de po-líticas, procedimentos e diretrizes para controle da TI. Já o gerenciamento de comunicações do PMBOK tem foco bem mais restrito, limitado ao planejamento e à implementação dos fluxos de comunicação gerenciais e operacionais de um projeto, não sendo suficiente para atender aos objetivos definidos no Cobit.

574. Certa.A questão cobra o conhecimento da distribuição de responsabilidades suge-

rida pelo Cobit na matriz RACI do processo “Definir um Plano Estratégico de TI” (PO1). Segundo o Cobit, a vinculação entre TI e negócio é de responsabili-dade compartilhada entre os executivos de negócio e o CIO – dirigente máximo da área de TI. Vale ressaltar que esse nível de informação (detalhes da tabela RACI) aparece de forma muito pontual em provas de concurso, não justificando qualquer tentativa de decorar todos os detalhes desse elemento para cada um dos processos do Cobit.

Cobit 4.1 – Tabela RACI• R (responsible) – Quem é responsável pela execução da atividade• A (accountable) – Quem é responsabilizado pelos resultados da atividade• C (consulted) – Quem é consultado para execução da atividade• I (informed) – Quem é informado do resultado da atividade

575. Certa.Embora exista no Cobit um processo dedicado ao gerenciamento de riscos –

Avaliar e Gerenciar os Riscos de TI (PO 9) –, tal processo tem como objetivos a criação e manutenção de estruturas de gestão de riscos. O gerenciamento efetivo dos riscos se dá no âmbito de vários outros processos, dentre eles o processo de gerenciamento de serviços terceirizados (DS 2), citado na questão.


263

576. Errada.

O processo em questão abrange diversos aspectos da segurança da informação e dos sistemas de TI, dentre eles a gestão de identidades e de contas de usuários, a gestão de chaves criptográficas, o tratamento de códigos maliciosos e a gestão da segurança de redes e comunicações de dados.

4.5. Planejamento e Gestão Estratégica de TI

577. Errada.Embora exista grande variedade de métodos de planejamento estratégico,

a maioria dos autores coloca em primeiro lugar a definição de aspectos mais perenes da estratégia – negócio, missão e valores – e, na sequência, a definição de aspectos transitórios – visão, objetivos e metas.

578. Errada.O texto da questão traz a definição de visão, segundo Oliveira (1999). O mes-

mo autor conceitua missão como sendo a função principal de uma organização, geralmente relatada em uma frase, que deixa claro porque a organização existe.

579. Certa.Segundo o modelo clássico de desenvolvido por Henderson e Venkatraman

(1993), o alinhamento estratégico entre TI e negócios pode ter como ponto de partida tanto a estratégia de negócio como a estratégia de TI.


581. Errada.Segundo Mintzberg et al (2000), considera-se estratégia deliberada aquela

que é resultado de um processo formal de planejamento estratégico, no qual a organização tenta antecipar os acontecimentos futuros e desenvolve previamente seu plano de ação com base nessa visão. Já a estratégia emergente surge a partir de processo dinâmico de aprendizado com os acontecimentos reais, à medida em que eles efetivamente ocorrem.



264

ELSEVIER

583. Certa.Ambas as definições são citadas por Rezende (2007, p. 2-4) como parte de

sua revisão sobre conceitos de planejamento estratégico. A gestão estratégica, enquanto processo contínuo, tem como uma de suas vantagens a maior facilidade de adaptação a oportunidades de mercado surgidas posteriormente à elaboração do plano estratégico da organização.

584. Errada.Segundo o modelo de gestão estratégica descrito por Certo e Peter (1993), a

decisão sobre a quais áreas e assuntos a empresa deve se dedicar corresponde à etapa de definição do negócio, e não das políticas.

585. Certa.

Ferramentas de suporte ao planejamento estratégico• Benchmarking – permite comparar as práticas em uso na organiza-

ção com práticas adotadas por outras empresas, em geral aquelas re-conhecidas por sua excelência em determinada área de atuação.

• Análise SWOT – avalia os pontos fortes (Strength) e fracos (Weakness) presentes no ambiente interno da organização, em comparação com as oportunidades (Opportunity) e ameaças (Threat) presentes no ambien-te externo.

A análise SWOT permite analisar a competitividade da empresa quando verifica se há pontos fortes suficientes para aproveitar oportunidades identifica-das, e permite analisar a segurança quando verifica se há ameaças que possam explorar pontos fracos da organização.

586. Errada.Ameaças são fatores do ambiente externo, fora do controle da organização.

Na análise SWOT, as características internas que impedem um bom desempenho são chamadas de pontos fracos.

587. Certa.

Ferramentas de suporte ao planejamento estratégico• Matriz GUT – utilizada para priorização de ações, com base na Gra-

vidade dos problemas, na Urgência para o seu tratamento e na Ten-dência de evolução do problema caso nada seja feito.


265

• Diagrama de Pareto – consiste em histograma baseado na frequência com que cada tipo de problema ocorre em uma organização, de modo a permitir a priorização dos problemas com maior incidência (Pareto: 20% das causas são responsáveis por 80% dos problemas).

• Curva de tendência – gráfico que representa a variação de uma de-terminada medição ao longo do tempo, com o propósito de realizar projeções quanto à evolução da variável em questão no futuro.

588. Certa.Todos os métodos citados na questão são descritos, de maneira resumida, por

Rezende (2007, p. 57-58) como parte de uma revisão sobre o histórico dos méto-dos de planejamento de sistemas de informação e de tecnologia da informação.


590. Errada.Os elementos citados na questão referem-se às possíveis estratégias adotadas

por uma organização. As forças competitivas propostas por Michael Porter são a ameaça de novos entrantes e de produtos ou serviços substitutos, o poder de barganha de clientes e fornecedores, e a intensidade da rivalidade entre compe-tidores (REZENDE, 2007, p. 28).

591. Errada.Porter classifica as atividades da cadeia de valor em atividades primárias,

relacionadas com a criação ou transformação dos produtos e serviços, e atividades de suporte ou apoio, que dão sustentação às atividades primárias.

c a p í t u l o 5

Gabaritos de Segurança da Informação

592. Certa.Os três principais serviços de segurança citados na literatura são justamente

a confidencialidade, a integridade e a disponibilidade. A despeito de haver outros, como a autenticação, a irretratabilidade e o controle de acesso (STALLINGS, 2008, p. 8-10), o uso do termo “basicamente” não torna aqueles exclusivos. A propósito, a afirmativa da questão é similar à primeira parte da definição de segurança da informação presente na norma ABNT NBR ISO/IEC 27002:2005 (ABNT, 2005, p. 1).

593. Errada.Em segurança da informação, o conceito de disponibilidade é a propriedade

de estar acessível e utilizável sob demanda por uma entidade autorizada (ABNT, 2006, p. 2). A afirmativa da questão corresponde ao serviço confidencialidade.

Serviços de segurança:• Confidencialidade–propriedadedequeainformaçãonãoestejadis-

ponível ou revelada a indivíduos, entidades ou processos não autori-zados (ABNT, 2006, p. 2).

• Integridade – garantia de que os dados recebidos estão exatamen-te como foram enviados por uma entidade autorizada (ou seja, não contém modificação, inserção, exclusão ou repetição) (STALLINGS, 2008, p. 9).

• Autenticação – garantia de que uma comunicação é autêntica(STALLINGS, 2008, p. 8).

5.1. Conceitos básicos de Segurança da Informação

capítulo 5 I Gabaritos de Segurança da Informação

267

• Irretratabilidade–impedimentodequeoemissorouoreceptornegueuma mensagem transmitida (STALLINGS, 2008, p. 10).

• Controledeacesso–oimpedimentodeusonãoautorizadodeumre-curso (STALLINGS, 2008, p. 9).

594. Certa.A primeira afirmativa da questão é perfeitamente coerente com a definição

do serviço confidencialidade. O complemento da questão diz que a garantia for-necida por ele deve se estender desde a geração da informação, passando por sua transmissão, e chegando até à recepção, onde os dados deveriam ser apropriada-mente armazenados ou mesmo destruídos, com o objetivo de evitar divulgações não autorizadas. De fato, a preservação do sigilo de uma informação deveria efetivamente alcançar todas essas etapas, inclusive na destruição da informação.

Embora a destruição dos dados afete outros serviços, como a integridade e a disponibilidade, tal ação em nada viola a confidencialidade. Um caso prático onde isso se evidencia acontece quando recebemos uma nova senha de um ban-co. É praxe a recomendação de que ela deva ser memorizada e aquele papel seja posteriormente destruído.

595. Errada.A primeira parte da questão está correta, uma vez que o serviço de auten-

ticação diz respeito à prova de uma identidade. Por sua vez, a autorização é a aprovação que é concedida a uma entidade para acessar um recurso do sistema, podendo também ser interpretada como “permissão” ou “privilégio” (SHIREY, 2007, p. 29).

Entretanto, a autenticação de uma entidade não implica diretamente numa autorização para acessar qualquer sistema ou informação, pois o acesso depende da entidade ter permissão para executar essa tarefa.

Passos para uma entidade acessar um objeto (HARRIS, 2010, p. 157):• identificação;• autenticação;• autorização;• auditoria(accounting).

596. Errada.A autenticação é um serviço associado tão somente à prova de uma identidade.

No caso da questão, essa demonstração é obtida pela apresentação de uma senha. Por sua vez, a confidencialidade das transações realizadas após a autenticação de-penderia de um mecanismo capaz de fornecê-la, como a criptografia, por exemplo.


268

ELSEVIER

Nada impediria que, uma vez autenticado o usuário, as informações trafe-gassem em claro, o que implicaria na inexistência de confidencialidade.

597. Errada.O comando da questão sugere que as necessidades de segurança do banco ABC

são as seguintes: disponibilidade (24 horas por dia), confidencialidade (garante o sigilo bancário de seus clientes) e integridade (garantir que os dados das tran-sações financeiras realizadas pelos seus clientes cheguem aos seus sistemas sem alterações). Como a questão afirma explicitamente que dentre as necessidades de segurança do banco, a integridade e a confidencialidade são as que podem ser comprometidas pelos ataques efetuados por meio da Internet, excluindo portanto a disponibilidade, a questão é errada. Esta última poderia ser alvo de ataques de negação de serviço (denial of service – DoS).

598. Certa.Os ataques são tipicamente classificados em ativos e passivos (SHIREY, 2007,

p. 23). Em particular, a análise de tráfego é um exemplo da segunda modalidade (STALLINGS, 2008, p. 6). Como o seu caráter passivo independe da quantidade de informação coletada, o item é correto.

Ataques (STALLINGS, 2008, pp. 6-7):• passivos–tentamdescobrirouutilizarinformaçõesdosistema,mas

não afeta seus recursos e se dividem em: liberação do conteúdo da mensagem e análise de tráfego;

• ativos–tentamalterarosrecursosdosistemaoualterarsuaoperaçãoe compreendem: disfarce, repetição, modificação de mensagem e nega-ção de serviço.

5.2. Criptografia – Conceitos, algoritmos e protocolos

599. Errada.A criptologia é o estudo das comunicações seguras que abrange tanto a

criptografia, quanto a criptoanálise (STALLINGS, 2008, p. 469). Por sua vez, a esteganografia diz respeito aos métodos empregados para ocultar a existência de uma mensagem ou outros dados (SHIREY, 2007, p. 292).

Desta forma, a questão apresenta erro tanto na divisão apresentada para a criptologia, bem como na afirmação de que a esteganografia se preocupa na identificação de técnicas para o ataque a sistemas de informação, uma vez que trata-se eminentemente de um mecanismo de defesa, proteção.


269

600. Certa.Esse é o conceito clássico de critptografia simétrica usado por Stallings (2008,

p. 469) e outros autores.

A despeito da correção da definição acima e este ser o conceito mais comum em questões de prova, cabe ressaltar que outra situação também caracterizada como criptografia simétrica é quando as chaves de cifração e decifração são diferentes, mas uma pode ser calculada a partir da outra e vice-versa (SCH-NEIER, 1996, p. 4).

601. Errada.Segundo Stallings (2008, p. 182), uma concepção errada a respeito dos algo-

ritmos de chave pública é de que a distribuição de chaves para estes é um processo mais simples quando comparado aos algoritmos simétricos. Segundo este autor consagrado, a distribuição de chaves com criptografia de chave pública exige al-guma forma de protocolo, normalmente envolvendo uma terceira parte confiável, e os procedimentos envolvidos não são mais simples nem mais eficientes do que os exigidos para a criptografia simétrica, uma vez que se uma chave simétrica deve ser confidencial, uma chave pública deve ser autêntica.

602. Errada.É justamente o contrário, os sistemas simétricos apresentam desempenho

significativamente superior aos assimétricos na cifração e decifração de mensa-gens (SCHNEIER, p. 216).

603. Certa.Conceito clássico de critptografia assimétrica apresentado por Schneier

(1996, pp. 4-5) e outros autores.

604. Errada.O relacionamento da criptografia com os serviços de segurança é recorrente

em provas do CESPE. A visão da banca é a de que a criptografia simétrica propor-ciona confidencialidade e integridade e a de chave pública oferece adicionalmente autenticação e irretratabilidade.

Esse conceito não encontra amparo na literatura consagrada. Os autores renomados insistem na tese de que a criptografia, seja simétrica ou assimétrica, só oferece confidencialidade (SCHNEIER, 1996, p. 4; MENEZES, 1997, p. 283).O que se pode afirmar do ponto de vista acadêmico é que o emprego da criptogra-fia aliada a alguma formatação/redundância adicional dentro de um método ou protocolo poderia fornecer serviços adicionais (STALLINGS, 2008, p. 231).


270

ELSEVIER

605. Errada.Os sistemas criptográficos utilizados atualmente são computacionalmente

seguros e não incondicionalmente seguros (STALLINGS, 2008, p. 21). Os simé-tricos baseiam sua segurança na limitação da tecnologia computacional vigente, enquanto os assimétricos em problemas matemáticos de difícil solução.

Segundo Stallings (2008, p. 21), um sistema criptográfico é computacio-nalmente seguro se atender um dos seguintes critérios:

• ocustoparaquebraracifraésuperioraovalordainformaçãocodificada;• otempoexigidoparaquebraracifraésuperioraotempodevidaútil

da informação.Um sistema criptográfico é incondicionalmente seguro se o texto cifrado

gerado pelo esquema não tiver informações suficientes para determinar exclusi-vamente o texto claro correspondente, não importando quanto texto cifrado esteja à disposição. Somente o One-Time Pad é considerado incondicionalmente seguro.

606. Certa.Uma das formas de se classificar um algoritmo criptográfico é quanto ao

tipo de operação usada para transformar texto claro em texto cifrado. A questão apresenta a definição correta das duas abordagens básicas: substituição e trans-posição, também chamada de permutação (STALLINGS, 2008, p. 19).

607. Certa.Aqui há um claro equívoco da banca. A descrição da propriedade difusão

está correta, mas o método da confusão busca tornar o relacionamento entre as estatísticas do texto cifrado e o valor da chave de criptografia o mais complexo possível (SHANNON, 1949, p. 709). O gabarito da questão deveria ser “Errado”.

608. Certa.A despeito de o DES possuir em seu desenho operações de substituição e de

transposição, ele é classificado como de substituição porque, se comparados o bloco cifrado de 64 bits gerado com o bloco em claro de mesmo tamanho, o que resulta do processo de cifração é uma substituição de bits e não uma transposição.

609. Certa.A decriptografia no DES, assim como em qualquer cifra de Feistel, usa o

mesmo algoritmo da criptografia, exceto pela inversão da aplicação das chaves de round (STALLINGS, 2008, p. 52).


271

610. Certa.O ataque de encontro no meio (meet-in-the-middle) é bem-sucedido contra

o DES duplo (chave de 112 bits) com um esforço da ordem de 256 (STALLINGS, 2008, p. 123).

611. Certa.Embora numa cifra de transposição, as chaves de cifração e decifração sejam

diferentes, uma pode facilmente ser obtida a partir do conhecimento da outra, o que também caracteriza uma cifra simétrica (MENEZES, 1197, pp. 15 e 238).

612. Certa.O branqueamento (whitening) consiste em um XOR entre uma chave e o

bloco de entrada e um novo XOR entre outra chave e o bloco de saída do algorit-mo. Como resultado desse procedimento, são adicionados bits à chave original, em decorrência das chaves adicionais. Isso minimiza a efetividade de ataques de força bruta contra a cifra (TANENBAUM, 2003, p. 787).

613. Errada.O arranjo proposto na questão (K1 = K2 = K3 = K) gera compatibilidade

entre os algoritmos DES e 3DES. Isso implica que um texto cifrado com o DES poderia ser decifrado com o 3DES e vice-versa, contudo, com esse procedimento não há “superação da diferença entre os algoritmos. Por exemplo, o tempo de cifração com o 3DES ainda seria o triplo do gasto pelo DES para um mesmo texto claro (STALLINGS, 2008, p. 92).

A compatibilidade citada decorre de o 3DES executar as operações cripto-grafar – decriptografar – criptografar com o DES simples (STALLINGS, 2008, p. 124).

614. Certa.Grave equívoco do examinador. O AES usa bloco de tamanho fixo de 128

bits (NIST, 2001, p. 5). A descrição da questão corresponde não ao AES, mas ao algoritmo Rijndael, vencedor da competição para se tornar o novo padrão de cifração americano (STALLINGS, 2008, p. 95).

O AES utiliza bloco de 128 bits e chaves de 128, 192 e 256 bits. O Rijndael foi proposto com tamanhos de bloco e de chave variáveis, podendo

assumir os valores 128, 160, 192, 224 e 256 bits (TANENBAUM, 2003, p. 790).


272

ELSEVIER

615. Errada.O AES não é um cifrador de Feistel (STALLINGS, 2008, p. 91).

A cifra de Feistel é definida por diversas rodadas de processamento idên-ticas em que, a cada rodada, uma substituição é realizada em metade dos bits sendo processados, seguida por uma permutação que troca as duas metades. Uma chave diferente, derivada da chave original, é usada a cada rodada (STALLINGS, 2008, p. 40).

616. Anulada.No modo de operação CBC, um bit errado em um bloco cifrado afeta apenas

a decifração do bloco claro correspondente e um bit do próximo (SCHNEIER, 1996, p. 195), portanto, a afirmativa da questão é errada. A anulação deveu-se ao erro de grafia em Chaning, que deveria ser Chaining.

Os principais modos de operação para cifra de bloco são (STALLINGS, 2008, p. 126):

• EletronicCodebook(ECB);• CipherBlockChaining(CBC);• CipherFeedback(CFB);• OutuputFeedback(OFB);• Counter(CTR).Os dois primeiros geram cifra em bloco, enquanto os demais geram cifra

em fluxo.

617. Errada.No modo ECB, blocos de texto claro iguais resultam em bloco cifrados iguais.

Essa manutenção de padrões o torna menos seguro do que o CBC, onde blocos claros iguais resultam em cifrados diferentes. Na comparação com o CTR (modo counter), o ECB é menos eficiente, pois o texto cifrado é maior do que o texto claro por um bloco devido ao padding, gerando maior overhead (SCHNEIER, 1996, p. 209).

618. Errada.Os conceitos de cifra de bloco e de fluxo estão trocados (STALLINGS, 2008,

p. 41).

619. Certa.Toda a descrição da solução de segurança desejada aponta para o uso do One-

-Time Pad, desde o tamanho e quantidade de mensagens, passando pela simpli-cidade da implementação e absoluta confidencialidade até a posse do gerador de


273

números aleatórios de elevadíssima qualidade. Para finalizar, o One-Time Pad, que emprega chave aleatória e que nunca é reutilizada, é um caso particular da cifra de fluxo conhecida como cifra de Vernam (MENEZES, 1997, p. 21).

620. Certa.O RSA baseia sua segurança na fatoração de inteiros grandes (MENEZES,

1997, p. 284). Cabe ressaltar que a questão afirma que o problema seria a fa-toração de números primos grandes, o que é um grave equívoco, uma vez que números primos não são fatoráveis, haja vista que a definição de fatoração é a decomposição de um número em fatores primos (COUTINHO, 2000, p. 35). Nosso parecer é de que essa questão deveria ser dada como errada.

621. Certa.O RSA pode é adequado para as três aplicações citadas (STALLINGS, 2008,

p. 188).

622. Errada.As chaves pública e privada no RSA são, respectivamente, formadas por (e,

n) e (d, n) (RIVEST, 1978, p. 6), onde os inteiros e e d são chamado de expoentes de cifração e decifração, respectivamente, e n é chamado de módulo (MENEZES, 1997, p. 286). Este último é o produto de dois primos grandes (p e q) e, portanto, não é primo.

623. Errada.Segundo Stallings (2008, p. 196), o RSA básico é vulnerável a ataques de

texto cifrado escolhido.

Tipos clássicos de ataques a mensagens criptografadas (STALLINGS, 2008, p. 20; SCHNEIER, 1996, pp. 5-7):

• apenastextocifrado;• textoclaroconhecido;• textoclaroescolhido;• textoclaroescolhidoadaptativo;• textocifradoescolhido;• chaveescolhida.Os ataques de texto cifrado escolhido são primariamente aplicáveis a al-

goritmos de chave pública, mas também podem ser efetivos contra algoritmos simétricos. Neles, o criptoanalista pode escolher diferentes textos cifrados e tem acesso às suas versões decifradas. O objetivo é descobrir a chave de decifração (SCHNEIER, 1996, p.6).


274

ELSEVIER

624. Certa.Segundo Stallings (2008, p. 197), o preenchimento ideal de criptografia as-

simétrica (optimal asymmetric encryption padding – OAEP) representa solução recomendável para proteger o RSA contra ataques de texto cifrado escolhido.

625. Certa.Para um mesmo nível de resistência à criptoanálise, os algoritmos de curvas

elípticas possuem tamanho de chave sensivelmente menor do que outros algo-ritmos de chave pública, como o RSA. Todavia, as chaves empregadas ainda são maiores do que a dos algoritmos simétricos, normalmente, o dobro (STALLINGS, 2008, p. 223).

626. Errada.O algoritmo de troca de chaves Diffie-Hellman é vulnerável contra ataque

man-in-the-middle (homem no meio) (STALLINGS, 2008, p. 214).

627. Certa.Um digest MDC (modification detection code) é um resumo de uma mensa-

gem gerado a partir de uma função de hash sem chave. A assinatura digital de uma mensagem pode ser criada a partir desse resumo, cifrando-o com a chave privada do emissor e garantindo os serviços de segurança citados na questão (FOROUZAN, 2008, pp. 969-975).

Mecanismos de segurança gerados a partir de funções hash (FOROUZAN, 2008, pp. 969-975):

• códigodedetecçãodemodificação(MDC)–nãoempregachaveeofe-rece apenas integridade;

• códigodeautenticaçãodemensagens(messageauthenticationcode–MAC) –emprega chave simétrica e oferece integridade e autenticação;

• assinaturadigital–empregacriptografiadechavepúblicaeofereceintegridade, autenticação e não repúdio.

628. Certa.Conceito correto da aplicação de funções hash para o armazenamento de

senhas, conforme Menezes (1997, p. 389). O armazenamento do hash das senhas evita que elas sejam obtidas por uma leitura do arquivo de senhas. Ataques de dicionário, onde se gera o hash de todas as entradas de um dicionário de palavras escolhidas, podem resultar na obtenção da senha ou de um outro valor que gere o mesmo hash (colisão).


275

629. Errada.MD2, MD4 e MD5 geram hashes de 128 bits (SCHNEIER, pp. 435-436 e

441). MD4 e MD5 utilizam os mesmos quatro operandos de 32 bits para gerar um hash (RIVEST, 1992, p. 3; SCHNEIER, p. 436).

630. Errada.Ambas as modalidades de criptoanálise podem ser empregadas contra o DES,

conforme Stallings (2008, p. 56).

A criptoanálise linear é uma modalidade de ataque onde são geradas aproximações lineares (equações que valem com alguma probabilidade) que relacionam o XOR entre certos bits do texto claro e do texto cifrado a alguns bits da chave (STALLINGS, 2008, p. 58).

A criptoanálise diferencial consiste na análise da evolução da diferença entre um par de blocos de texto claro e texto cifrado que diferem apenas por um pequeno número de bits quando processados pelo algoritmo criptográfico (STALLINGS, 2008, p. 56; TANENBAUM, 2003, p. 799).

631. Errada.A diferença entre dois blocos analisada na criptoanálise diferencial é um XOR

entre dois n-gramas (n caracteres – um bloco de texto claro) (STALLINGS, 2008, p. 56). Outro erro na questão é que a descrição apresentada para a criptoanálise linear não corresponde à definição correta.

632. Errada.O erro da questão está na afirmação de que as chaves assimétricas empre-

gadas juntamente com o protocolo HTTPS são permanentes. Embora a vida útil delas seja consideravelmente maior do que as chaves simétricas, ainda assim elas não são permanentes (MENEZES, 1997, p. 31). Isso pode ser evidenciado na prática com a validade dos certificados de chave pública.

633. Certa.O Kerberos é um serviço de autenticação que possui um centro de distri-

buição de chaves simétricas (FOROUZAN, 2008, p. 983). A questão descreve corretamente características do Kerberos conforme Stallings (2008, pp. 296-297).

5.3. Assinatura digital, certificação digital e PKI

634. Errada.Uma assinatura digital não confere sigilo a uma mensagem. Como visto an-

teriormente, os serviços oferecidos são: integridade, autenticação e não repúdio.


276

ELSEVIER

635. Certa.Definição correta da geração de uma assinatura digital empregando uma

função hash e um algoritmo de chave pública (FOROUZAN, 2008, p. 973).

636. Certa.Conceito correto do login unificado propiciado pelo single sign on, conforme

Tipton (2010, p. 105).

637. Certa.A autenticidade de um certificado é verificada pela validação da assinatura

da autoridade certificadora (AC) que o emitiu. Como em qualquer assinatura digital, isso é realizado com o emprego da chave pública da AC emissora, que é obtida a partir do certificado dela própria. Se ela for uma AC raiz, seu certificado é autoassinado (SHIREY, 2007, p. 255).

638. Errada.A chave que consta em um certificado de chave pública é a chave pública do

titular do certificado (STALLINGS, 2008, p. 468).

639. Errada.O ataque man-in-the-middle é evidenciado pela interceptação e modificação

seletiva de dados com o objetivo de se disfarçar como uma ou mais das entidades envolvidas numa comunicação (SHIREY, 2007, p. 186). Desta forma, o serviço de segurança alvo deste ataque é a autenticação e a assinatura digital é uma solução viável. Como seu emprego depende da certificação digital, a solução apresentada na questão é eficaz.

640. Errada.A autoridade certificadora só assina o seu próprio certificado e o das autori-

dades certificadoras que lhe são diretamente subordinadas.

Segundo (TANENBAUM, 2003, pp. 817-818), uma autoridade regional (regional authority – RA) é uma AC de segundo nível e que podem cobrir alguma região geográfica, como um país ou um continente.

641. Errada.Segundo Stallings (2008, p. 310), registro é o processo em que um usuário

primeiramente se torna conhecido por uma AC (diretamente, ou por meio de uma RA), antes que a AC emita um certificado para o usuário.


277

5.4. Ameaças, vulnerabilidades e ataques

642. Certa.Phishing pode ser caracterizado como uma fraude que emprega meios eletrô-

nicos e cujo objetivo é furtar dados pessoais (CERT.BR, 2006, p. 35). A situação descrita na questão é uma das hipóteses envolvendo phishing que vêm sendo utilizadas por fraudadores na Internet (CERT.BR, 2006, p. 40).

643. Certa.Numa rede interligada por switch, a comunicação entre duas máquinas leva

em consideração os endereços MAC de ambas. Como no ARP spoofing a falsificação ocorre no nível de rede (endereço IP), não prejudicando assim a comunicação em nível de enlace entre as máquinas da vítima e do atacante, este poderia envenenar o cache ARP da máquina vítima e coletar todo o tráfego que ela enviasse para uma suposta terceira parte (ZÚQUETE, 2010, p. 150).

O ataque ARP spoofing consiste em envenenar o cache ARP de uma vítima enviando uma resposta ARP forjada, onde o endereço IP fornecido é o de uma terceira parte, com quem a vítima desejaria se comunicar (o default gateway, por exemplo) e o MAC é o da máquina do atacante.

644. Certa.O MAC flooding consiste em enviar uma imensa quantidade de quadros

com endereços MAC de origem forjados e aleatórios com o objetivo de esgotar a tabela MAC do switch. Quando isso ocorre, comumente o switch passa a enviar dados para todas as suas portas, como se fosse um hub, e viabilizando ataques de sniffer passivo (SKOUDIS, 2006, p. 451).

645. Errada.A restrição da capacidade de aprendizagem nas portas de um switch é uma

contramedida para o ataque de MAC flooding e não tem qualquer eficácia contra o ARP spoofing (SKOUDIS, 2006, pp. 452-453).

646. Certa.Definição correta de IP spoofing, conforme Nakamura (2007, p. 103).

647. Certa.Caracterização correta do vírus de macro, conforme Stallings (2008, p. 432).

Outros tipos comuns de vírus (STALLINGS, 2008, p. 432):• parasitário–infectaarquivosexecutáveis;


278

ELSEVIER

• residentenamemória–aloja-senamemóriaprincipaleinfectaospro-gramas ececutados;

• do setorde inicialização (boot) – infecta o registro de inicialização (Master Boot Record – MBR);

• furtivo–projetadoparaseocultardossistemasantivírus;• polimórfico–mudaasuaformaacadanovainfecção;• metamórfico–capazdemudartantoasuaaparênciaquantoseucom-

portamento;• vírusdee-mail–embute-seemanexosdee-mail.

648. Certa.Descrição correta, segundo Stallings (2008, p. 430).

Fases do ciclo de vida de um vírus (STALLINGS, 2008, p. 430):• latente;• propagação;• disparo;• execuçãodaatividademaliciosa.

649. Certa.Descrição correta da relação entre o vírus de computador e o seu programa

hospedeiro, segundo Stallings (2008, pp. 429-430) e outros autores. Particular-mente, o caso em que o hospedeiro armazena apenas parte do código do vírus pode ser exemplificado pelos vírus multipartite (SZOR, 2005, pp. 115-116).

650. Errada.Os scanners heurísticos não dependem de uma assinatura específica

(STALLINGS, 2008, p. 435). Seu funcionamento depende apenas de regras heu-rísticas, como uma verificação de integridade baseada em hash, por exemplo, para detectar uma provável infecção.

Gerações de software antivírus (STALLINGS, 2008, p. 435):• scannersimples–baseadosemassinaturas;• scannerheurísticos;• interceptaçãodeatividade–baseadoemcomportamento;• proteçãocompleta–combinaçãodasanteriores.

651. Errada.As ações citadas são atribuídas aos cavalos de troia em CERT.br (2006, p. 68).


279

652. Errada.A descrição corresponde à caracterização de um worm, conforme CERT.br

(2006, p. 75).

653. Certa.A afirmação é coerente com a definição de cavalo de troia, segundo Stallings

(2008, p. 429).

654. Errada.O conceitos de adware e spyware estão trocados (CERT.BR, 2006, p. 70).

655. Errada.Enquanto os vírus são pedaços de código inseridos em outros arquivos do

sistema infectado, chamados hospedeiros (STALLINGS, 2008, p. 429), os spyware são programas inteiros que executam independentemente de outros arquivos do sistema infectado (SZOR, 2005, p. 38). Assim, o real motivo para os spyware não serem considerados vírus é por não necessitarem de um arquivo hospedeiro e não apenas quando não possuírem um mecanismo de replicação. Esta justificativa levou o CESPE a alterar o gabarito da questão de Certo para Errado.

656. Errada.A descrição apresentada corresponde à caracterização de backdoor, conforme

(STALLINGS, 2008, p. 429).

657. Errada.Os responsáveis pela obtenção e transmissão de informações privadas do

usuário são os spyware (CERT.BR, 2006, p. 70). Além disso, backdoors permi-tem que um atacante estabeleça conexões na máquina em que se encontram (STALLINGS, 2008, p. 429).

658. Certa.Há duas grandes modalidades de ataque: a intrusão propriamente dita, que

corresponde a uma invasão, e a negação de serviço (ASSUNÇÃO, 2008, p. 56). A questão apresenta um exemplo típico de negação de serviço.

659. Certa.Como técnicas empregadas em ataques de negação de serviço, o syn flooding

e o ICMP flooding usualmente dependem do IP spoofing (NAKAMURA, 2007, p. 103). Desta forma, a filtragem dos tráfegos egresso e ingressante pode ser útil no combate a esses ataques da seguinte forma:


280

ELSEVIER

a) não se admite sair da rede interna pacotes cujo IP de origem seja da rede externa (NAKAMURA, 2007, p. 109);

b) não se admite a entrada de pacotes da rede externa cujo IP de origem seja da rede interna (NAKAMURA, 2007, p. 103).

Syn flooding é um ataque que explora o mecanismo de estabelecimento de conexões TCP, conhecido como three-way handshake. Nele, um grande número de pedidos de conexão (pacotes SYN) é enviado, causando um estouro da pilha de memória do alvo, que não é capaz de responder a todas (NAKAMURA, 2007, p. 105).

ICMP flooding é um ataque de negação de serviço em que o atacante envia uma série de pacotes de requisição ICMP de eco (ping) maior do que a imple-mentação do protocolo pode manipular (SHIREY, 2007, p. 145).

660. Errada.Na verdade, pelo descrito na questão, quem efetua o ataque é o host local,

uma vez que ele é o responsável pelo envio da longa série de segmentos TCP SYN sem os correspondentes segmentos TCP ACK.

661. Certa.A questão descreve com precisão um ataque distribuído de negação de serviço

(distributed denial of service – DDoS) por refletor (STALLINGS, 2008, p. 439).

662. Errada.No smurf, os pacotes ICMP enviados ao alvo são do tipo reply e não request

(NAKAMURA, 2007, p. 108). Este ataque explora o fato de nem todos os rotea-dores bloquearem o broadcast dirigido, em que um pacote de difusão tem como IP de destino o endereço de broadcast de uma rede (BAKER, 1995, p. 48).

5.5. Dispositivos e sistemas de proteção

663. Errada.A instalação de um firewall dentro da rede interna de uma organização para

segregar o tráfego de rede de um determinado departamento, por exemplo, não o torna menos eficaz do que um posicionado entre a rede interna e as redes do mundo externo.

664. Certa.O conceito apresentado é a visão consagrada a respeito das camadas em que

atua um filtro de pacotes, conforme pode ser visto em Nakamura (2007, p. 228), dentre outros autores.


281

Principais tecnologias de firewall (NAKAMURA, 2007, p. 228):• filtrodepacotes(stateless);• filtrodepacotesbaseadoemestados(stateful);• firewallproxy;• híbrido;• adaptativo;• reativo;• pessoal.Desta lista, os que costumeiramente são cobrados em questões de prova

são o filtro de pacotes, o filtro de pacotes baseado em estados e o firewall proxy, também chamado de gateway de aplicação.

665. Certa.Conforme discutido na questão 68, essa forma de filtragem de tráfego ingres-

sante pode evitar essa modalidade de IP spoofing. Texto similar ao da questão pode ser visto em Nakamura (2007, p. 103).

666. Certa.O descrito na questão está em plena conformidade com o descrito em Naka-

mura (2007, p. 228).

667. Certa.O melhor desempenho de um filtro de pacotes baseado em estados decorre

dos seguintes fatos (NAKAMURA, 2007, p. 233):• onúmeroderegrasnatabeladeestadosémenor,umavezquesomen-

te os pacotes de início de conexão (SYN puro, por exemplo) devem ser comparados com essas regras;

• averificaçãonatabeladeestadosnãoéfeitadeformasequencial,comono filtro de pacotes, mas com base em tabelas hash, otimizando a busca.

A maior granularidade desses firewalls se explica por eles usarem mais de-talhes para executarem a sua filtragem, particularmente, o estado das conexões e sua semântica são levados em consideração (CHESWICK, 2005, p. 189).

668. Errada.Em um pacote fragmentado, apenas o primeiro fragmento contém o cabeça-

lho do protocolo de nível superior, como o TCP, informação necessária para que o filtro de pacotes execute adequadamente sua tarefa de filtragem. Assim, todos os demais fragmentos são possivelmente descartados, o que demonstra a inabili-dade desse tipo de firewall em lidar com a fragmentação (ZWICKY, 2000, p. 82).


282

ELSEVIER

Originalmente, a solução adotada para lidar com o problema da fragmenta-ção executar a filtragem somente no primeiro fragmento e permitir a passagem de todos os demais fragmentos.

Esta abordagem foi inicialmente considerada segura porque, mesmo que apenas o primeiro fragmento seja barrado no processo de filtragem, o sistema de destino não será capaz de remontar o pacote a partir dos demais. Se o pacote original não pode ser reconstruído, um ataque nele presente não é efetivo.

A despeito disso, constatou-se um novo problema: o sistema de destino mantém os fragmentos na memória por um determinado tempo, aguardando o fragmento faltante. Cientes disso, os atacantes passaram a usam pacotes fragmentados para gerar ataques de negação de serviço (ZWICKY, 2000, p. 83).

669. Errada.É justamente o contrário. Em filtros de pacotes, as regras permitem tanto

que clientes como servidores iniciem conexões, o que representa uma vulnera-bilidade que pode ser explorada por usuários não autorizados. Já nos firewalls que realizam a inspeção de estado, podem ser criadas regras que só permitam o estabelecimento de conexões originadas em clientes ou na rede interna, provendo maior segurança (STALLINGS, 2008, p. 448).

670. Errada.A inspeção de estados em um firewall stateful também pode alcançar proto-

colos não orientados à conexão, como o UDP e o ICMP. Basta que o encerramento da pseudoconexão seja associado a um tempo limite ou a alguma outra heurística, como a contagem de pacotes, por exemplo (CHESWICK, 2005, p. 190).

671. Errada.A inspeção de estados, como o nome sugere, toma por base a inspeção da

tabela de estados. Apesar de informações de cabeçalho constarem nessa tabela, o objetivo da inspeção é verificar o estado de uma conexão, informação que não está presente nos cabeçalhos, e, a partir disso, decidir se um pacote pode ou não ser aceito (NAKAMURA, 2007, p. 232).

As decisões de filtragem em um firewall stateful são tomadas considerando (NAKAMURA, 2007, p. 232):

• informaçõesdecabeçalhosdospacotes,comonosfirewallsstateless,para os pacotes de início de conexão;

• ainspeçãodatabeladeestados,quearmazenaoestadodasconexões,para todos os demais pacotes.


283

672. Certa.Os conceitos apresentados na questão estão em total conformidade com o

disposto em Nakamura (2007, p. 235).

A limitação temporal das sessões na tabela de estados, além de permitir o encerramento das pseudoconexões dos protocolos não orientados à conexão, visa evitar ataques de negação de serviço que tenham como alvo a própria tabela de estados do firewall (NAKAMURA, 2007, p. 235).

673. Errada.A simples adição de mais um elemento na arquitetura do firewall stateful,

a tabela de estados, a torna mais complexa em relação ao filtro de pacotes sem estados.

674. Certa.Num cenário envolvendo a comunicação cliente-servidor mediada por um

proxy, o cliente se conecta ao proxy e lhe faz uma requisição. Por sua vez, o proxy se conecta ao servidor e faz pedido similar ao do cliente. O servidor responde para o proxy, que responde para o cliente. Desta forma, não há conexão direta entre cliente e servidor (NAKAMURA, 2007, p. 238).

675. Certa.A comparação apresentada na questão é coerente com a caracterização das

duas abordagens de firewalls, conforme pode ser visto em Nakamura (2007, 238).

676. Errada.A remontagem de um pacote IP ocorre na camada de rede do host de des-

tino. Quando a comunicação entre cliente e servidor é mediada por um proxy, o destino dos pacotes originados no cliente é o proxy. A despeito disso, como o pacote IP fragmentado é remontado no nível de rede, o proxy de aplicação, atu-ando na última camada, não tem acesso aos fragmentos, mas somente a dados remontados a partir de fragmentos ou oriundos de pacotes IP não fragmentados.

677. Errada.É justamente o contrário. No contexto de arquiteturas de firewall, a DMZ é

posicionada dentro do firewall (NAKAMURA, 2007, p. 248).

DMZ é uma rede de perímetro adicionada entre uma rede protegida e uma rede externa, de modo a propiciar uma camada extra de segurança.

Principais arquiteturas de firewall (NAKAMURA, 2007, pp. 246-249):


284

ELSEVIER

• dual-homedhost–formadaporumúnicodispositivocomnomínimoduas interfaces de rede e que age como proxy;

• screenedhost–formadaporumfiltrodepacoteseumtipoespecialdeservidor chamado bastion host;

• screenedsubnet–formadapordoisfiltrosdepacotes,uminternoeou-tro externo, e que possui, confinada entre eles, uma rede de perímetro, denominada DMZ.

678. Certa.A primeira regra permite que máquinas externas tenham acesso apenas

aos serviços que devem ser prestados à rede externa e evita o acesso indevido às redes internas. As outras duas regras evitam IP spoofing.

679. Certa.A natureza complementar à ação de um firewall descrita na questão corres-

ponde ao apresentado em Nakamura (2007, pp. 265-266).

680. Errada.A descrição da questão corresponde a um falso negativo. Um falso positivo

corresponde a um alarme falso, quando um IDS conclui incorretamente que ocorreu um evento intrusivo (CHESWICK, 2005, p. 271).

681. Errada.O problema causado pela inexistência de assinatura é o falso negativo

(NAKAMURA, 2007, p. 282).

A classificação mais comum dos IDS quanto à metodologia de detecção os divide em (NAKAMURA, 2007, p. 281):

• detecçãobaseadaemassinaturas, tambémchamadadebaseadaemconhecimento ou por uso incorreto;

• detecçãobaseadaemcomportamento.Além dessa abordagem, o CESPE costuma utilizar outra, descrita em

Stallings (2008, p. 409):• detecçãoestatísticadeanomalia–dadosrelacionadosaocomportamen-

to de usuários legítimos são coletados por um período de tempo e, após isso, são aplicados testes estatísticos ao comportamento observado para determinar se o comportamento é ou não de um usuário legítimo;

• detecçãobaseadaemregras–édefinidoumconjuntoderegrasquepodem ser usadas para decidir se determinado comportamento é o de um intruso.


285

682. Errada.A definição apresentada é não é a da detecção estatística de anomalias, mas

da baseada em regras (STALLINGS, 2008, p. 409).

683. Errada.A detecção estatística de anomalias, pode se dar sob duas hipóteses

(STALLINGS, 2008, p. 409):• detecçãodelimiar–limiaressãodefinidosindependentementedousu-

ário, para a frequência de ocorrência de vários eventos;• baseadaemperfil–mudançasnocomportamentodascontasindividu-

ais são detectadas com base no perfil de atividade de cada usuário.A questão trata da primeira abordagem, onde é, dada a variabilidade entre

os usuários, reconhecidamente comum uma alta incidência de falsos positivos ou de falsos negativos, conforme Stallings (2008, p. 410).

684. Certa.As características dos IDS baseados em host e em rede bem como as desvan-

tagens destes últimos apresentadas na questão são claramente detalhadas em Nakamura (2007, pp. 270-274).

685. Certa.Os IDS com análise por estado do protocolo analisam todo o contexto da

sessão para decidir a respeito de uma intrusão (TIPTON, 2010, p. 128).

686. Errada.As características do IDS e do IPS estão trocadas (NAKAMURA, 2007, pp.

292-294).

687. Errada.Uma clara desvantagem do IDS baseado em rede frente ao de host é sua

incapacidade de avaliação de tráfego cifrado (NAKAMURA, 2007, p. 274).

688. Certa.Essa é a definição clássica de VPN, conforme Shirey (2007, p. 333).

689. Errada.O conceito de VPN possui dois fundamentos, tunelamento e criptografia,

sendo esta última a exclusiva responsável por propiciar a segurança para o esta-belecimento da VPN. Isso independe da rede, da aplicação e do correspondente


286

ELSEVIER

protocolo de transporte que venha a ser utilizado, podendo ser aplicável a qualquer comunicação passível de roteamento, como voz, vídeo e dados (NAKAMURA, 2007, p. 334).

690. Errada.A ocultação de endereços executada pelo IPSEC no modo túnel independe

do NAT, uma vez que essa é uma característica do próprio IPSEC atuando neste modo. Não há, portanto, qualquer associação entre a capacidade do IPSEC es-conder endereços e seu suporte ao NAT. Esse raciocínio levou a banca a rever o gabarito dessa questão, que antes fora dada como certa.

691. Certa.O AH fornece autenticação, enquanto o ESP fornece confidencialidade e,

opcionalmente, autenticação e integridade (STALLINGS, 2008, p. 352).

Serviços IPSEC (STALLINGS, 2008, p. 352):• AH– controlede acesso, integridade sem conexão, autenticaçãoda

origem dos dados e rejeição de pacotes repetidos;• ESP(apenascomcriptografia)–controledeacesso,rejeiçãodepaco-

tes repetidos, confidencialidade e confidencialidade limitada do fluxo de tráfego (proteção contra análise de tráfego);

• ESP (criptografiamais autenticação) – controle de acesso, integridadesem conexão, autenticação da origem dos dados, rejeição de pacotes repe-tidos, confidencialidade e confidencialidade limitada do fluxo de tráfego.

692. Certa.Um exemplo da situação descrita é o IPSEC com ESP no modo túnel, onde

é adicionado um novo cabeçalho IP aos pacotes IPSEC, cujos IPs de origem e destino são o dos gateways envolvidos na comunicação. Esse arranjo propicia de forma clara o roteamento correto dos pacotes (STALLINGS, 2008, p. 360).

693. Errada.A associação de segurança e unidirecional. Além disso, ela é identificada

pelos seguintes parâmetros (NAKAMURA, 2007, p. 356):• umnúmerode32bitsdenominadoíndicedeparâmetrodesegurança

(Security Parameter Index – SPI);• oIPdedestino;• omecanismodesegurançaaserusado–AHouESP.


287

694. Certa.Essa é a atribuição correta do ISAKMP, conforme (NAKAMURA, 2007, p. 357).

5.6. Normas ABNT NBR ISO/IEC 27001 e 27002 – Gestão de segurança da informação

695. Anulada.Conforme ABNT (2006, p. vi), o ciclo de gestão da norma NBR ISO/IEC

27001:2006 é composto das seguintes fases: estabelecimento, implementação e operação, monitoramento e análise crítica, manutenção e melhoria. O gabarito preliminar da banca dava a questão como certa, mas ela foi anulada com a justi-ficativa de que “na redação do item, a palavra “revisão” pode ter interpretações diferentes, o que poderia ter levado os candidatos ao erro”. A despeito disso, nosso entendimento é de que a questão deveria ter seu gabarito alterado para errado, dada a diferença de termos empregados na questão e na norma.

696. Errada.De acordo com ABNT (2006, p. 1), a exclusão de quaisquer dos requisitos

especificados na norma NBR ISO/IEC 27001:2006 não é aceitável quando uma organização reivindica conformidade com a referida norma.

697. Certa.A despeito de a banca ter considerado a afirmação como certa, nosso en-

tendimento é de que ela é errada, a partir do emprego equivocado da expressão “substituição ao padrão 27002”. A norma ABNT NBR ISO/IEC 27001:2006 afirma na seção 2 que é indispensável para sua aplicação a norma ABNT NBR ISO/IEC 17799:2005, desde 2007 nomeada como NBR ISO/IEC 27002:2005 (ABNT, 2006, p. 2). No item 4.2.1 g), a norma 27001 afirma que os controles listados no Anexo A, que contém em resumo todos os controles da norma 27002, não são exaustivos, podendo ser selecionados objetivos de controle e controles “adicionais” (ABNT, 2006, p. 6). Para finalizar, a preparação da declaração de aplicabilidade, um re-quisito da norma 27001, depende dos controles do anexo A (ABNT, 2006, p. 6). Portanto, a adição de novos controles, além dos previstos na 27002 é coerente com a norma, mas não a substituição do padrão 27002.

698. Errada.O sistema de gestão de segurança da informação (SGSI) é “a parte” do sistema

global de gestão, baseado na abordagem de riscos ao negócio (ABNT, 2006, p. 3).


288

ELSEVIER

699. Errada.O impacto de um incidente de segurança da informação não é mediano, uma

vez que a norma afirma que ele possui grande probabilidade de comprometer as operações do negócio e ameaçar a segurança da informação (ABNT, 2006, p. 2).

700. Errada.Esse é o conceito de evento de segurança da informação, conforme ABNT

(2006, p. 2).

701. Certa.Afirmação em conformidade com os itens 4.2.1 a) e 4.2.1 e) da norma (ABNT

2006, pp. 4-5).

702. Errada.A afirmativa contraria o item 4.2.1 h) (ABNT, 2006, pp. 4-5).

703. Errada.Na fase Do (implementação e operacionalização), deve-se definir como medir a

eficácia dos controles propostos de acordo com o item 4.2.2 d) (ABNT, 2006, p. 6).

704. Errada.A definição da política do SGSI (item 4.2.1 b) antecede a realização da análise

e da avaliação de risco (item 4.2.1 e) (ABNT, 2006, pp. 4-5).

705. Certa.Declaração em conformidade com os itens 4.3.1 a), e), i) e 4.3.3 da norma

(ABNT, 2006, pp. 8-9).

706. Certa.Questão em conformidade com o item 5.1 f) da norma (ABNT, 2006, p. 10).

707. Certa.De acordo com a seção da norma, as auditorias devem ser internas e a inter-

valos planejados, sem sugestão de periodicidade (ABNT, 2006, p. 11).

708. Certa.Afirmativa em conformidade com o item 4.2.3 a) 2) da norma (ABNT, 2006,

p. 7).


289

709. Certa.De acordo com o item 5.1 a), o estabelecimento da política do SGSI é respon-

sabilidade da direção (ABNT, 2006, p. 9).

710. Errada.As ações executadas em 4.2.3 a) e e) permitem a identificação de não-confor-

midades e fazem parte da fase “checar” (check) e não da fase “agir” (act), justi-ficativa que levou a banca a alterar o gabarito da questão de certo para errado.

711. Errada.Os assuntos das normas estão trocados.

712. Certa.O histórico apresentado está em conformidade com o disposto em ISO/IEC

(2012).

Histórico da norma ISO/IEC 27002:2005 a partir da BS 7799 (ISO/IEC, 2012):

• BS7799:1995;• BS7799-1:1998–renomeação;• BS7799-1:1999–revisão;• ISO/IEC17799:2000;• ISO/IEC17799:2005–revisão;• ISO/IEC17799:2005.

713. Certa.Assertiva em conformidade com a definição de segurança da informação

presente no item 0.1 da norma 27002 (ABNT, 2005, p. x).

714. Errada.Todos os itens listados são possibilidades de controle, segundo a definição

2.2 da norma 27002 (ABNT, 2005, p. 1).

715. Anulada.No item 0.6 da norma 27002, declara-se que “embora todos os controles da

norma sejam importantes e devam ser considerados, a relevância de qualquer controle deve ser determinada segundo os riscos específicos a que uma organi-zação está exposta” (ABNT, 2005, p. xii). Diante disso, a banca optou por anular a questão com a justificativa de que o uso do termo “prioritário” compromete o julgamento do item frente à pequena quantidade de informações providas.


290

ELSEVIER

Nosso entendimento diverge dessa posição, uma vez que, se a questão declara explicitamente que um controle é prioritário frente ao outro e isso não pode ser afirmado, o gabarito da questão deveria ser Errada.

716. Certa.De acordo com a norma 27002, os requisitos de negócio constituem uma das

três possíveis fontes de requisitos de segurança da informação, conforme ABNT (2005, p. xi).

Fontes principais de requisitos de segurança da informação (ABNT, 2005, p. xi):

• análise/avaliaçãoderiscosparaaorganização;• legislaçãovigente,estatutos,regulamentaçãoecláusulascontratuais;• conjuntoparticulardeobjetivoserequisitosdenegócio.

717. Certa.Todos os itens listados são fatores críticos de sucesso e encontram-se listados

no item 0.7 da norma 27002 (ABNT, 2005, p. xii).

Fatores críticos para o sucesso da implementação de segurança da infor-mação (ABNT, 2005, pp. xii-xiii):

• políticadesegurançadainformaçãoquereflitaosobjetivosdonegócio;• abordagemeestruturadasegurançadainformaçãoconsistentecoma

cultura organizacional;• comprometimentoeapoiovisíveldetodososníveisgerenciais;• bomentendimentodosrequisitosdesegurançadainformação;• divulgaçãoeficientedasegurançadainformaçãoparasealcançara

conscientização;• distribuiçãodediretrizesenormassobreapolíticadesegurançada

informação;• provisãoderecursosfinanceirosparaasatividadesdagestãodesegu-

rança da informação;• provisãodeconscientização,treinamentoeeducaçãoadequados;• estabelecimentodeumeficienteprocessodegestãode incidentesde

segurança da informação;• implementaçãodeumsistemademedição,quesejausadoparaava-

liar o desempenho da gestão da segurança da informação.

718. Anulada.A definição para vulnerabilidade apresentada na questão é praticamente

a mesma descrita em CERT.br (2006, p. 7), com a diferença de que o texto da


291

questão fala em “violação da integridade de um computador”, ao passo que a definição do CERT.br se refere à “violação da segurança de um computador”. A banca optou por anular a questão sob a alegação de que a redação do item possa ter levado a uma interpretação equivocada.

719. Errada.A afirmação contrasta com a declaração da norma 27002 no item 4.2, onde

diz que “é importante reconhecer que alguns controles podem não ser aplicáveis a todos os sistemas de informação ou ambientes, e podem não ser praticáveis para todas as organizações” (ABNT, 2005, p. 7).

720. Anulada.As normas 27001 (anexo A) e 27002 possuem um mesmo conjunto de 133

controles e 39 objetivos de controle. A norma 27001, por ser gerencial e não um código de prática, possui redação mais abstrata do que a 27002 e sua estrutu-ra possui correlação com a norma ISO 9001:2000 (ABNT, 2006, pp. 32-33). A despeito disso, a banca anulou a questão alegando a presença de ambiguidade no texto, evidenciada pela expressão “a primeira das normas”, haja vista que o leitor poderia ficar em dúvida se a questão estava se referindo à primeira citada no texto ou à que foi primeiro publicada.

721. Anulada.As ações descritas são referentes à gestão de riscos de segurança da infor-

mação (ABNT, 2005, p. 2) e não à gestão de ativos. A banca anulou a questão sob a afirmação de que a redação do item possa ter levado a uma interpretação equivocada, contudo, nosso parecer é de que o gabarito definitivo para a questão deveria ser Errada.

À luz da norma 27002, a gestão de ativos compreenderia, dentre outras, diversas ações referentes aos ativos, como (ABNT, 2005, pp. 21-24):

• inventário;• atribuiçãoderesponsabilidadespelosativos;• definiçãodousoaceitável;• classificação;• rotulação.

722. Errada.Segundo a norma 27002, dentre as opções de tratamento de riscos, uma das

possibilidades é a aceitação de riscos, conforme (ABNT, 2005, p. 6).


292

ELSEVIER

Formas de tratamento de risco (ABNT, 2005, p. 6):• reduzirriscos;• aceitarriscos;• evitarriscos;• transferirriscos.

723. Errada.Todos os itens listados são possíveis conteúdos do documento da política de

segurança da informação, conforme a seção 5 da norma 27002 (ABNT, 2005, p. 8), à exceção das regras para controle de acesso, que por serem detalhes técnicos e cuja divulgação poderia comprometer a segurança, não devem constar deste documento.

724. Errada.A afirmativa da questão é bastante similar à descrição do controle 5.1.1, re-

lativo ao documento da política de segurança da informação (ABNT, 2005, p. 8). A única distinção entre ambos é que a norma traz o controle como uma sugestão, na forma: “Convém que um documento da política de segurança da informação seja aprovado...”, enquanto na questão é utilizado o verbo “dever”, como se o controle descrito fosse uma imposição. Cabe observar que o texto da questão é exatamente o mesmo trazido na descrição do controle 5.1.1 no anexo A da norma 27001 (ABNT, 2006, p. 14) e que em diversas outras questões o CESPE considera como corretas afirmativas que contêm descrições de controles a partir do anexo A da 27001, onde o verbo dever é sempre empregado.

725. Errada.A eficácia da política de segurança, bem como sua pertinência e adequação,

não está associada à utilização de ferramentas específicas, mas a um processo de constante avaliação e implementação de ajustes, fundamentados na realização de análises críticas a intervalos planejados ou quando mudanças significativas ocorrerem (ABNT, 2005, p. 9).

726. Certa.A afirmativa corresponde à descrição do controle 5.1.2 da norma 27002

(ABNT, 2005, p. 9). Cabe observar que o examinador não se ateve ao verbo “de-ver” presente no enunciado.

727. Certa.Os ativos citados estão em conformidade com as informações adicionais do

controle 7.1.1 da norma 27002 (ABNT, 2005, p. 21). A análise de riscos é uma das fontes de requisitos de segurança da informação (ABNT, 2005, p. xi).


293

728. Errada.Segundo o controle 7.2.1 da norma 27002, convém que classificação da infor-

mação se dê em termos do seu valor, requisitos legais, sensibilidade e criticidade (ABNT, 2005, p. 23).

729. Errada.De acordo com o controle 7.1.1 da norma 27002, um arquivo de texto é um

ativo de informação, uma IDE para desenvolvimento em linguagem C é um ativo de software e um pendrive é um ativo físico (ABNT, 2005, p. 21).

730. Errada.Controle de entrada física não é objetivo de controle e sim um controle da

norma 27002 (9.1.2). Além do mais, a descrição dada na questão diz respeito ao controle 9.1.1 da referida norma, que trata de perímetros de segurança física (ABNT, 2005, pp. 32-33).

731. Errada.As instalações citadas devem ficar separadas, conforme diretrizes do controle

9.1.1 da norma 27002 (ABNT, 2005, p. 32).

732. Errada.O objetivo de controle citado no início da questão é o 7.1 – responsabilidade

pelos ativos (ABNT, 2006, p. 16). Já a remoção de propriedade (controle 9.2.7) está associada ao objetivo de controle 9.2 – segurança de equipamentos (ABNT, 2006, p. 18).

733. Errada.A afirmativa contraria o controle 10.1.4 – separação dos recursos de desen-

volvimento, teste e de produção – da norma 27002 (ABNT, 2005, p. 42).

734. Errada.A declaração presente na questão contraria o disposto nas informações adi-

cionais do controle 10.10.1 da norma 27002 (ABNT, 2005, p. 61), o que levou a banca a alterar o gabarito de Certo para Errado.

735. Certa.A afirmativa está em plena conformidade com as diretrizes para implemen-

tação do controle 11.3.1 – uso de senhas – da norma 27002 (ABNT, 2005, p. 69).


294

ELSEVIER

736. Errada.A análise crítica dos direitos de acesso de usuário é o controle 11.2.4 da

norma 27002 e não um objetivo de controle. Além disso, a descrição presente na questão diz respeito ao controle 11.2.1, que trata do registro de usuário (ABNT, 2005, p. 66).

737. Certa.As medidas listadas estão previstas no controle 12.5.4 da norma 27002, que

trata do vazamento de informações (ABNT, 2005, p. 95).

738. Errada.A despeito de a notificação de eventos de segurança da informação, que

poderia evoluir para o relato de um incidente, estar presente na norma 27002 no controle 13.1.1 e as diretrizes para implementação desse controle fazerem referência ao alarme de coação (ABNT, 2005, p. 98), nem esse, nem qualquer outro controle dessa norma são obrigatórios (ABNT, 2005, p. xii). A seleção destes controles deve ser motivada pelos requisitos de segurança da informação (ABNT, 2005, p. xi). Argumentação similar a essa levou a banca a optar pela mudança no gabarito da questão, passando de certa para errada.

739. Errada.A afirmação contraria o controle 13.1.2 da norma 27002 – notificando fra-

gilidades de segurança da informação –, que apresenta em suas informações adicionais recomendação oposta ao afirmado (ABNT, 2005, p. 99).

740. Errada.A norma 27002 não faz qualquer referência a qual deveria ser o tempo

recomendável para recuperação dos ativos críticos no processo de continuidade de negócio.

741. Certa.A afirmativa da questão apresenta conformidade com o descrito nos controles

15.3.1 e 15.3.2 da norma 27002 (ABNT, 2005, p. 114).

5.7. Norma ABNT NBR ISO/IEC 27005 – Gestão de riscos em segurança da informação

742. Certa.A afirmativa da questão apresenta conformidade com definição 3.4 da norma

27005 (ABNT, 2008, p. 2).


295

743. Certa.O processo de análise de risco compreende a identificação e a estimativa de

riscos de acordo com a seção 6 da norma 27005 (ABNT, 2008, p. 5).

Etapas do processo de gestão de riscos de segurança da informação (ABNT, 2005, p. 5):

• definiçãodecontexto;• análisede riscos,quecompreendea identificaçãoea estimativade

riscos;• avaliaçãoderiscos;• tratamentoderiscos;• aceitaçãoderiscos;• comunicaçãoderiscos;• monitoramentoeanálisecríticaderiscos.

744. Certa.A afirmativa está em conformidade com o descrito no item 8.2.1 da norma

27005 (ABNT, 2008, pp. 10-13).

745. Errada.O processo tratado pela norma 27005, cujo nome das etapas parcialmente

descrito na questão é o de gerenciamento de riscos (ABNT, 2008, p. 5).

746. Errada.A questão comete equívoco grosseiro ao insinuar que os métodos quantitati-

vos são superiores aos métodos quantitativos. Cabe ressaltar que a questão estaria correta se a comparação estabelecesse superioridade da análise qualitativa sobre a quantitativa para os tipos de ativos citados (ABNT, 2008, p. 14).

5.8. Norma ABNT NBR 15999 – Gestão da continuidade de negócios

747. Errada.

Os estágios da gestão de continuidade são (ABNT, 2007, p. 8):• Gestãodoprogramadegestãodecontinuidadedenegócio(GCN);• Entendendoaorganização;• Determinandoaestratégiadecontinuidadedenegócios;• DesenvolvendoeimplementandoumarespostadeGCN;• Testando, mantendo e analisando criticamente os preparativos de

GCN;• IncluindoaGCNnaculturadaorganização.


296

ELSEVIER

748. Certa.A afirmação de que escolha da estratégia decorre dos valores dos objetivos

de tempo de recuperação ou tempo objetivado de recuperação (recovery time ob-jective – RTO) está em conformidade com o item 6.6 da norma 15999-1 (ABNT, 2007, p. 17). Por sua vez, segundo a definição 2.32 da referida norma, o RTO deve ser menor do que o período máximo de interrupção tolerável (ABNT, 2007, p. 5).

RTO é o tempo alvo para (ABNT, 2007, p. 5):• retomadadaentregadeprodutosouserviçosapósumincidente;• recuperaçãododesempenhodeumaatividadeapósumincidente;• recuperaçãodeumsistemaouaplicaçãodeTIapósumincidente.Período máximo de interrupção tolerável é a duração a partir da qual a

viabilidade de uma organização será ameaçada de forma inevitável, caso a entrega de produtos ou serviços não possa ser reiniciada (ABNT, 2007, p. 4).

749. Certa.A afirmativa é coerente com o disposto no item 8.1 da norma 15999-1 (ABNT,

2007, p. 24). Cabe observar que a nomenclatura usada na questão não existe, uma vez que a norma é intitulada ABNT NBR 15999-1:2007. Nosso parecer é de que a questão deveria ter sido anulada em decorrência desse erro.

750. Anulada.A banca optou por anular a questão em decorrência da sigla RTD, estranha

à terminologia reconhecida de continuidade de negócios e à norma 15999. Cabe observar que se o texto trouxesse RTO no lugar de RTD, a afirmativa estaria correta.

751. Certa.As atividades 3, 4, 5 e 6 produzem, de forma não exclusiva, evidências de

auditoria de conformidade, o que pode ser constatado pela análise dos itens 6.7, 7.10, 5.2.2 e a seção 8 da norma 15999-1. A atividade 2 caracteriza-se por reco-mendar o emprego, de forma explícita, do recurso de auditoria, como forma de testar a GCN, conforme item 9.6 da referida norma. Assim, é correto afirmar que o processo de auditoria é realizado no âmbito da atividade 2. Essa justificativa levou a banca a alterar o gabarito da questão de Errada para Certa.

Parte 3Referências

bibliográficas

Parte 3

Referências bibliográficas

Referências Bibliográficas

1.1. Referências de Bancos de Dados

ALLEN, P.; BAMBARA, J. Introdução a sistemas de banco de dados. Campus-Elsevier, 2003.CHEN, P. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. Makron Books, 1990.DATE, C. J. Introdução a Sistemas de Bancos de Dados. Campus-Elsevier, 2003.HEUSER, C. A. Projeto de banco de dados. Artmed, 2001.ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. Pearson, 2011.INMON, W. H. Como construir o data warehouse. Campus-Elsevier, 1999.KORTH, H. F; SILBERSCHATZ, A.; SUDARSHAN, S. Sistemas de banco de dados. Campus-Elsevier, 2006.

1.2. Referências de Desenvolvimento de Sistemas Web

BASHAN, B.; BATES, B.; SIERRA, K. Use a Cabeça! Servlets e JSP. Alta Books, 2008.BATES, B.; SIERRA, K. Use a Cabeça! Java. Alta Books, 2005.BAUER, C.; KING, G. Java Persistence With Hibernate. Ciência Moderna, 2007.CERAMI, W. Web Services Essentials. O’Reilly, 2002.GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos. Bookman, 2005.GEARY, D.; HORSTMANN, C. S. Core Java Server Faces. Alta Books, 2007.JOSUTTIS, N. M. SOA na Prática. Starlin Alta Consult, 2008.MCLAUGHLIN, B. Use a Cabeça! AJAX. Alta Books, 2008.RAY, E. T. Learning XML. O’Reilly, 2001.


300

ELSEVIER

1.3. Referências de Engenharia de Software

ALLEN, P.; BAMBARA, J. Sun Certified Enterprise Architect For J2EE. McGraw--Hill, 2003.BECK, K. Programação extrema explicada: acolha as mudanças. Bookman, 2004.BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - Guia do usuário. Campus--Elsevier, 2006.FOWLER, M. Padrões de arquitetura de aplicações corporativas. Bookman, 2006.FOWLER, M. UML essencial. Bookman, 2005.International Function Point Users Group (IFPUG). Manual de Práticas de Contagem de Pontos de Função, versão 4.3.1. IFPUG, 2010.LARMAN, C. Utilizando UML e padrões. Bookman, 2004.Netherlands Software Metrics Users Association (NESMA). Análise de Pontos de Função para Melhoria de Software, versão 2.2.1. NESMA, 2009.Netherlands Software Metrics Users Association (NESMA). Contagem Antecipada de Pontos de Função. NESMA, 2009.PRESSMAN, R. S. Engenharia de Software. McGraw-Hill, 2006.SOMMERVILLE, I. Engenharia de Software. Addison-Wesley, 2003.VASQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de pontos de função: medição, estimativas e gerenciamento de projetos de software. Érica, 2011.

1.4. Referências de Gestão de Tecnologia da Informação

ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRA-SILEIRO (SOFTEX). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral. SOFTEX, 2009.CMMI PRODUCT TEAM. CMMI for Development, Version 1.3. Carnegie Mel-lon, 2010.FERNANDES, A. A.; ABREU, V. F. Implantando a governança de TI. Brasport, 2009.HELDMAN, K. Gerência de Projetos: Guia para o Exame Oficial do PMI. Campus-Elsevier, 2009.IT GOVERNANCE INSTITUTE (ITGI). Control Objectives for Information and Related Technology – Cobit 4.1. ITGI, 2007.MULCAHY, R. Preparatório para o Exame de PMP. RMC Publishing, 2009.OFFICE OF GOVERNMENT COMMERCE (OGC). ITIL CONTINUAL SER-VICE IMPROVEMENT, 2011 EDITION. TSO, 2011.______. ITIL SERVICE DESIGN, 2011 EDITION. TSO, 2011.______. ITIL SERVICE OPERATION, 2011 EDITION. TSO, 2011.

capítulo 5 I Referências Bibliográficas

301

______. ITIL SERVICE STRATEGY, 2011 EDITION. TSO, 2011.______. ITIL SERVICE TRANSITION, 2011 EDITION. TSO, 2011.PROJECT MANAGEMENT INSTITUTE (PMI). Um Guia do Conhecimento em Gerenciamento de Projetos - Guia Pmbok 4° Edição. PMI, 2008.REZENDE, D. A. Planejamento de sistemas de informação e informática. Atlas, 2007.WEILL, P.; ROSS, J. W. Governança de TI. Makron Books, 2005.

1.5. Referências de Segurança da Informação

ABNT. ABNT NBR ISO/IEC 27002:2005 – Tecnologia da Informação – Técnicas de Segurança – Código de Prática para a Gestão de Segurança da Informação. 2005.______. ABNT NBR ISO/IEC 27001:2006 – Tecnologia da Informação – Técnicas de Segurança – Sistema de Gestão de Segurança da Informação – Requisitos. 2006.______. ABNT NBR 15999-1:2007 – Gestão de Continuidade de Negócios – Parte 1: Código de Prática. 2007.______. ABNT NBR ISO/IEC 27005:2008 – Tecnologia da Informação – Técnicas de Segurança – Gestão de Riscos de Segurança da Informação. 2008.ASSUNÇÃO, M. F. Segredos do Hacker Ético. Ed. Visual Books, 2008.BAKER, F. Requirements for IP Version 4 Routers. RFC 1812, 1995.CGI.BR. Cartilha de Segurança para Internet. Comitê Gestor da Internet no Brasil, 2006.CHESWICK, W. R.; BELLOVIN, S. M.; RUBIN, A. D. Firewalls e Segurança na Internet. Ed. Bookman, 2005.COUTINHO, S. C. Números Inteiros e Criptografia RSA. IMPA/SBM, 2000.FOROUZAN, B. A. Comunicação de Dados e Redes de Computadores. Ed. McGraw-Hill do Brasil, 2008.HARRIS, S. CISSP All-in-One Exam Guide. McGraw-Hill Osborne Media, 2010.MENEZES, A.; VAN OORSCHOT, P. C.; VANSTONE, S. A. Handbook of Applied Cryptography. CRC Press, 1996.NAKAMURA, E. T.; GEUS, P. L. Segurança de Redes em Ambientes Cooperativos. Novatec, 2007.RIVEST, R.; SHAMIR A.; ADLEMAN, L. A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 1978.RIVEST, R. The MD4 Message-Digest Algorithm. RFC 1320, 1992.SCHNEIER, B. Applied Cryptography. John Wiley & Sons, 1996.SHANNON, C. Communication theory of secrecy systems. Bell Systems Technical Journal, No 4, 1949.SHIREY, R. Internet Security Glossary, Version 2. RFC 4949, 2007.


302

ELSEVIER

SKOUDIS, E.; LISTON, T. Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effective Defenses. Prentice-Hall, 2006.STALLINGS, W. Criptografia e Segurança de Redes: Princípios e Práticas. Prentice-Hall, 2008.SZOR, P. The Art of Virus Research and Defense. Addison-Wesley Professional, 2005.TANENBAUM, A. S. Redes de Computadores. Campus-Elsevier, 2003.TIPTON, H. F. Official (ISC)2 Guide to the CISSP CBK. Auerbach Publications, 2010.ZÚQUETE, A. Segurança em Redes Informáticas. Ed. FCA, 2010.ZWICKY, E. D.; COOPER, S.; CHAPMAN, D. B. Building Internet Firewalls. O’Rilley, 2000.

Tecnologia Da Informacao - Questoes Comentadas Cespeunb - Serie Questoes - Elsevier Editora

Documents

Transcript of Tecnologia Da Informacao - Questoes Comentadas Cespeunb - Serie Questoes - Elsevier Editora