Tecnologia Da Informação - Questões Comentadas Cespeunb - Série Questões

Tecnologia da Iruormação Questões come ntadas CESPE/UnB

Banco de Dados Desenvolvimento de Sistemas Web Engenharia de Software Gestão de Tecnologia da Informação Segurança da Infor mação

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

Obrigado por adquirir o livro

TECNOLOGIA DA INFORMAÇÃOQuestõ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

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.br

para conhecer nosso catálogo completo, ter acesso a serviços exclusivos no site

e receber informações sobre nossos lançamentos e promoções.

ELSEVLER

QUESTÕES

Gledson Pompeu. Gleyson Azevedo. Marcelo Pacote e Mareio Victorino

Tecnologia da Informação Questões comentadas CESPE/ UnB

Banco de Dados Desenvolvimento de Sistemas Web Engenharia de Software Gestão de Tecnologia da Informação Segurança da Informação

fZ CAM PUS

C 2012, Elsevier Editora ltdo.

Todos os d ireitos reservod~ e protegidos pelo lei~ 9.610, de 19/02/1998. Nenhuma porte deste livro, sem outorizosão prévio por escrito do editora, poderó ser reproduzido ou transmitido sejam quais forem os meios empregod~: eletrônicos, mecânicos, fotográficos, gravaçOo ou quaisquer outros.

Copidesque: CaNo dos Neves Revisão: Donielo Morrocos fditoroljÕO Eletrônico: SBNigri Artes e Textos ltdo.

Coordenador do Série: Sylvio Motto

Elsevier Editora ltda. Conhecimento sem Fronteiros Ruo Sete de Setembro, 11 1 - 169 andor 20050-006- Centro- Rio de Janeiro- RJ - Brasil

Rua Quintono, 753- 8"" andor 04569-0l l - Brooldin-São Paulo-SP- Brasil

Serviço de Atendimento oo Clienfe 0800-0265340 [email protected]

ISBN 978-85-352-6135-6

Nota: Muito zelo e técnico forom empregados no edic;áo desta obra. No entanto, podem ocorrer erros de d igitação, impressão ou dúvida conceituei. Em qualquer dos hipóteses, solicitemos o comunicoçôo ao nosso Servi~o de Atendimento oo Cliente, poro que possamos esclarecer ou encaminhar o questão.

Nem o editora nem o autor assumem qualquer responsabilidade por eventvais donos ou perdas o

pessocs ou bens, o riginados do uro desta publicação.

T425

CIP-Brasil. Cotologoçôo·no-fonte. Sindicato Nocional dos Editores de livros, RJ

TI frecurso e-letrônicol : questões comentados CESPE/UNB I Gled· son Pompeu .. . fet ol.]. · Rio de Janeiro : Elsevier, 2012.

recurso digital

Formato: PDF Requisitos do sistema: Adobe Digita l Editions Modo de acesso: World Wide We ISBN 978·85-352·6 135·6 (recvrso eletrônico)

1. Tecnologia do informação . Administração . 2. Sistemas de informação gerenciol • Problemas, questões, exercícios. 3. Serviço público · Brosil · Concursos. 4. livros eletrônicos. I. Pompeu, G ledson.

12-2591. COO: 658.0546 CDU: 005.94

Aos nossos familiares, nosso ag~·adecimento 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 esperança de que este liVl·o possa ajudá-los a chegar mais rápido ao seu objetivo.

Gledson, Gieyson, Mareio e Pacote.

página deixada intencionalmente em branco

Gle dson 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 ofEnterprise 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 42 lugar no concm-so 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 'l' I e na preparação para provas discursivas. Desde 2008 a tua 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.

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 frequentemente ministra palestras em seminários e congressos. Desde 2009, é professor de Segu:ranç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 Foundations e Oracle SQL Expert.

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

Mareio 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 Ce1tified Web Component Developer, Sun Certified Business Component Developer, Project Management Professional, IBM Certified Solution Designer, OMG Certified UML Professional e Oracle Database 11g: SQL Fundamentais.

Trabalha na área de desenvolvimento e integração de Sistemas Corporativos 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, atualmente, é professor universitário das disciplinas de Programação 00, 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 galbarito oficial de cada questão é apresentado, seguido de comentários diretos e objetivos para que você possa entender 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 recomendadas para o estudo de cada uma das matérias, várias delas citadas pontualmente nos comentários das questões.


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 s aber só a t eoria; é fundam en tal saber como essa teoria é cobra da, conhecer os macetes e a "jurisprudên cia" d e cada banca - entendimentos específicos (e muitas vezes questionáveis) que são adotados pelas bancas na hora de definir o gabarito 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ústria dos concursos" é mais forte. Depois, vieram os cm·sos 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, resolvemos 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.

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 lemba·ar 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 1 QUESTÕES PARA RESOLUÇÃO

CAPÍTULO 1 Q UESTÕES DE B ANCO DE D ADOS ........... . .. . ....... ........ .... .. . .... 3 1.1. Modelagem de Dados ... .... ...... ...... ..... .. .... .. .... ...... ........... .. .... ...... ............ ..... . 3

1.2. Normalização ... .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... . 9 1.3. Álgebra Relacional ..... ............ ..... .. .... ...... ............ ..... ...... .. .... .. .... ........... .. ... 11

1.4. Transações ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. ... 12 1.5. Arquitetura de Banco de Dados e Bancos de Dados Distribuídos ........... 14 1.6. Arquitetura OLAP ..... ...... ...... ..... .. .... .. .... .. .... ...... ..... .. .... .. .... .. .... ...... ..... .. ... 15

CAPíTULO 2 Q UESTÕES DE D ESENVOLVIJ\fENTO DE S ISTEMAS W EB •••••••••• 17 2.1. Linguagem Java ... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ...... ..... .. ... 17

2.1.1. Sintaxe, características e APis ... .. ..................... .. .... .. ..................... 17

2.1.2. Orientação a objetos com Java ................................ ...... ................. 20 2.2. Padrões de Projeto ...................... .. ........................... ............ ...... ................ 23 2. 3. Arquitetura J ava EE ........................ .. .... .. ..................... .. .... ...................... 25

2.3.1. JSP/Servlets, EJB e Servidores de Aplicação ......... ...... .. ............... 25 2.3.2. JSF ...... .. .... .. .... ...... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... ...... ............ ..... 29

2.3.3. JPA/Hibernate .. .... ...... ..... .. .... .. .... .. .... ...... ........... .. .... ...... .. .......... ..... 29 2.4. Desenvolvimento Web (lado cliente) .. ................................. ...... ................ 30 2.5. Interoperabilidade de sistemas Web .. ................................. ...... ................ 34

2.5 .1. XML .... .. .... .. .... ...... ...... ...... ..... .. .... .. .... ...... ........... .. .... ...... ............ ..... 35 2.5 .2. Web Services ... .. .......... ..... .. .... ...... .. .......... ........... .. .... ...... .. .......... ..... 36

2.5 .3. SOA ..... .. .... .. .... ............ ...... ..... ...... .. .......... ........... .. .... ...... ............ ..... 39

Cl Tecnolog ia da Informação- Questões Comentadas I Cespe I UnS ELSEVI6R

C APíTULO 3 Q UE!.'TÓES DE ENGENHARIA DE SOFTWARE •••• •••••••• ••••••• •••••• .41

3.1. Análise por Pontos de Função ...... .. .... .. ..................... .. .... .. .... .. ............... .. . 41 3.1.1. Conceitos básicos de APF ... ................................. .. ..................... .. . .41 3.1.2. APF segundo o IFPUG ...... .. .... .. ............... .. .... .. .... .. .... .. ... .. .... ...... .. . .42 3.1.3. APF segundo a NESMA .... .. .... .. ..................... .. .... .. .... .. ............... .. . .43 3.1.4. Aplicações da APF .. ...... ..... .. .... ...... ...... ...... ..... ...... .. .... .. .... ............ ... 43

3.2. Modelos de Processos de Desenvolvimento de Software ..... .. ......... .. ....... 44 3.3. Processo Unificado .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 46 3.4. Processos Ágeis .. .... .. .... ...... ...... ..... .. .... .. .... ............ ..... .. .... .. .......... ...... ..... .. . 49 3.5. Engenharia de Requisitos ............ .. .... .. ........ ....... .. .... .. .... .. .... .. ... .. .... .. .... .. . 52 3.6. Arquitetura de Software .................... .. ..................... .. .... .. ..................... .. . 55 3.7. Qualidade de Software ................. .. .... .. ..................... .. .... .. ..................... .. . 56 3.8. Orientação a Objetos .................... .. .... .. ........ ....... .. .... .. .... .. ......... .. .... .. .... .. . 59 3.9. Unified Modeling Language (UML) ... .. .... .. ............... .. .... .. .... .. .................. 61

C APÍTULO 4 QUEsTÕES DE G ESTÃO DE TECNOLOGIA DA I NFORMAÇÃO .. ... 73 4.1. Gerenciamento de Projetos .......... .. .... .. .... .. ............... .. .... .. .... .. ............... .. . 73

4.1.1. Conceitos básicos de gerenciamento de projetos .. .... .. .... .. ............. 74 4.1.2. Portfólios, programas e estruturas organizacionais ... ................... 74 4.1.3. Escritórios de projetos e outras partes interessadas .. .... .. ............. 75 4.1.4. Ciclo de vida e grupos de processos ..................... .. .... .. ................... 76 4.1.5. Gerência de integração ...... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ...... ..... .. .. 77 4.1.6. Gerência de escopo ............ .. .... .. ..................... .. .... .. .... .. ................... 78 4.1.7. Gerência de tempo .. ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ............ ... 78 4.1.8. Gerência de custos .. ...... ..... .. .... .. .... ............ ..... .. .... .. .... .. .... ...... ...... ... 79 4.1.9. Gerência de riscos ... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ...... ...... ... 80 4.1.10. Gerências de qualidade, RH, comunicações e aquisições .............. 80

4.2. Qualidade de Software ................. .. .... .. ..................... .. .... .. ..................... .. . 81 4.2.1. CMMI- Conceitos básicos e estrutura ................ .. .... .. ........ ........... 82 4.2.2. CMMI- Níveis de capacidade e maturidade ....... .. .... .. ................... 82

4.2.3. CMMI- Áreas de Processo .................................. .. ..................... .. .. 83 4.2.4. MPS.BR- Conceitos básicos e níveis de maturidade ..... .. .. ........... 85 4.2.5. MPS.BR- Processos ..... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ............ ... 87

4.3. Gerenciamento de Serviços .......... .. ................................. .. ..................... .. . 87 4.3.1. ITIL- Conceitos básicos e estrutura do modelo ... .... .. .... .. .. ........... 88 4.3.2. ITIL- Estratégia de serviços .. .. .... .. ..................... .. .... .. ........ ........... 88 4.3.3. ITIL- Desenho de serviços ........... .. ..................... .. .... .. ................... 89 4.3.4. ITIL- Transição de serviços .. .. .... .. .............. ....... .. .... .. ........ ....... .. .. 90

XIV

I Su már io

4.3.5. !TIL- Operação de serviços .................................... ....................... 91 4.3.6. !TIL- Melhoria contínua de serviços .................... ....... .. ............... 92

4.4. Governança de TI .. ..................... .. .... .. ................ ..... .. .... .. .......... ........... .. ... 93 4.4.1. Cobit- Conceitos básicos ........................................ ....................... 93

4.4.2. Cobit- Características gerais ................................. ........................ 94 4.4.3. Cobit- Modelo de maturidade .... .. .......... ........... .. .... ...... ................. 96 4.4.4. Cobit- Domínios e processos .. .... .. .... ....................... ....................... 97

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

CAPíTULO 5 Q UESTÕES DE SEGURANÇA DA INFORMAÇÃO ... ........ .... .. ..... 103 5.1. Conceitos básicos de Segurança da Informação ..................................... 103 5.2. Criptografia- Conceitos, algoritmos e protocolos ................................. 104

5.3. Assinatura digital, certificação digital e PKI .................... ..................... 110 5.4. Ameaças, vulnerabilidades e ataques .... .. .... ...................... ....... .. .......... .. 111 5.5. Dispositivos e sistemas de proteção .............................. .. .... .. .................. ll3 5.6. Normas ABNT NBR ISO!IEC 27001 e 27002- Gestão de segurança

da informação ... .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 117 5. 7. Norma ABNT NBR ISO/IEC 27005- Gestão de riscos em segurança

da informa~ão ... .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 123

5.8. Norma ABNT NBR 15999- Gestão da continuidade de negócios ........ 124

PARTE2 GABARITOS. COMENTADOS

CAPíTULO 1 GABARITOS DE B ANCO DE D ADOS ............... ........... ....... .... 129 1.1. Modelagem de Dados ... .... ...... ...... ..... .. .... .. .... ...... ........... .. .... .. .... ............ .. 129

1.2. Normalização ... .... .. .... ..... .. ..... ..... .. .... ...... ............ ..... ...... .. .......... ........... .. . 137 1.3. Álgebra Relacional ..... ............ ..... .. .... ...... ............ ..... ...... .. .... ...... ........... .. . 139 1.4. Transações ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 141 1.5. At-quitetura de Banco de Dados e Bancos de Dados Distribuídos ......... 145

1.6. At-quitetura OLAP ..... ...... ...... ..... .. .... .. .... .. .... ...... ..... .. .... .. .... .. .... ...... ..... .. . 146

CAPíTULO 2 GABARITOS DE D ESENiVOLVIMENTO DE SISTEJIIAS WEB ... .. . . 149 2.1. Linguagem Java ... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ...... ..... .. . 149

2.1.1. Sintaxe, características e APis ............................... ... ................... 149

2.1.2. Orientação a objetos com Java .. .. ..................... .. .... ..................... 151 2.2. Padrões de Projeto ...................... .. .... .. ..................... .. .... .. .... .. .................. 154

2.3. At-quitetura Java EE ...... .. ................ .. .... .. .......................... ... .................. 156

XV

Cl Tecnolog ia da Informação- Questões Comentadas I Cespe I UnS ELSEVI6R

2.3.1. JSPiServlets, EJB e Servidores de Aplicação .......... ...... ............. . 156 2.3.2. JSF ... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .......... ............ . 160

2.3.3. JPNHibernate .. ...... ...... ..... .. .... ...... ............ ........... .. .... .. .... ...... ...... . 161 2.4. Desenvolvimento Web (lado cliente) .. .. .... .. ..................... .. ...................... 162 2.5. Interoperabilidade de sistemas Web ............................... .. ...................... 166

2.5.1. XML .. .... .. .... .. .... ...... ...... ..... .. .... ...... ............ ..... ...... .. .......... ...... ...... . 166 2.5.2. Web Services ..... ............ ................. ............ ........... .. .......... ...... ...... . 167 2.5.3. SOA .. ..... .. .... .. .... ............ ................. ...... ...... ........... .. .......... ...... ...... . 170

C APíTULO 3 G ABARITOS DE ENGENHARIA DE SoFTWARE ....................... 172 3.1. Análise por Pontos de Função ...... .. .... .. ..................... .. .... .. .... .. ................ 172

3.1.1. Conceitos básicos de APF .. .... .. ..................... .. .... .. ..................... .. 172 3.1.2. APF segundo o IFPUG ...... .. ..................... .. .......... .. ......... .. .......... .. 174 3.1.3. APF segundo a NESMA .... .. ................................. .. ..................... .. 176

3.1.4. Aplicações da APF ............. .. .... .. ..................... .. .... .. .... .. ................. 177 3.2. Modelos de Processos de Desenvolvimento de Software .... .. .......... ...... 178 3.3. Processo Unificado .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... . 182 3.4. Processos Ágeis .. .... .. .... ...... ...... ........... .. .... ............ ..... .. .... .. .......... ...... ..... . 186 3.5. Engenharia de Requisitos ............ ................ ....... .. .......... .. ......... .. ........... 190

3.6. Arquitetura de Software .............. .. .... .. ..................... .. .... .. ...................... 194 3.7. Qualidade de Software ....................... .. ..................... .. .... .. ...................... 195 3.8. Orientação a Objetos .................... .. .... .. ..................... .. .... .. ...................... 201 3.9. Unified Modeling Language (UML) ... .. .... .. ............... .. .... .. .... .. ................ 204

C APíTULO 4 G ABARITOS DE G ESTÃO DE 1 ECNOLOGIA DA INFORl\IAÇÃO .. 213 4.1. Gerenciamento de Projetos .......... .. .... .. .... .. ............... .. .... .. .... .. ................ 213

4.1.1. Conceitos básicos de gerenciamento de projetos .. .... .. .... .. ........... 213 4.1.2. Portfólios, programas e estmturas organizacionais ... ................. 215 4.1.3. Escritórios de projetos e outras partes interessadas .. .... .. ........... 216 4.1.4. Ciclo de vida e grupos de processos ..................... .. .... .. ................. 218 4.1.5. Gerência de integração ...... .. .... .. .... ...... ...... ..... .. .... .. .......... ...... ..... .. 220 4.1.6. Gerência de escopo ....... ..... .. .......... ...... ...... ........... .. .......... ...... ...... . 222 4 .1. 7. Gerência de tempo .. ...... ................. ............ ........... .. .......... ...... ...... . 223

4.1.8. Gerência de custos .. ...... ..... .. .... ...... ............ ..... ...... .. .... .. .... ...... ...... . 225 4.1.9. Gerência de riscos ... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... .. .... ...... ...... . 226 4.1.10. Gerências de qualidade, RH, comunicações e aquisições ............ 228

4.2. Qualidade de Software ................. .. ................................. .. ...................... 231 4.2.1. CMMI- Conceitos básicos e estmtura ................ .. ....................... 231 4.2.2. CMMI- Níveis de capacidade e maturidade ....... .. ....................... 232

XVI

I Sumár io

4.2.3. CMMI- Áreas de Processo ................................ .. .... .. ................... 235 4.2.4. MPS.BR- Conceitos básicos e níveis de maturidade .................. 239

4.2.5. MPS.BR- Processos ... ..... .. .... .. .... .. .... ...... ..... .. .... .. .... ...... .. .......... ... 241 4.3. Gerenciamento de Serviços ........ .. .... .. .... .. .... ...... ..................................... 242

4.3.1. ITIL- Conceitos básicos e estrutUl'a do modelo .......................... 24.2 4.3.2. ITIL- Estratégia de serviços .. .... .. .......... ............ .......................... 244 4.3.3. ITIL- Desenho de serviços .. .................................... ...... ............... 246 4.3.4. ITIL- Transição de serviços .. .... .. ................................. ............... 248 4.3.5. ITIL- Operação de serviços .............................. .. .... ...... ............... 249 4.3.6. ITIL- Melhoria contínua de serviços .... ................. ...... .. ............. 252

4.4. Governança de TI .. ................ ...... .... ........................ ................................ 252 4.4.1. Cobit- Conceitos básicos .................................. .. .... ...... ............... 252 4.4.2. Cobit- Caracteristicas gerais ........................... ...... ....... ............ ... 255 4.4.3. Cobit- Modelo de maturidade .... .. ................................. ............... 257 4.4.4. Cobit- Domínios e processos .. .... .. .......... ........... .. .... ...... ............... 259

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

CAPÍTULO 5 GABARITOS DE S EGURANÇA DA INFORlltAÇÁO .. .. . ................ 266 5.1. Conceitos básicos de Segurança da Informação .......... .. .... .. .................. 266 5.2. Criptografia- Conceitos, algoritmos e protocolos ................................. 268 5.3. Assinatill'a digital, certificação digital e PKI ......................................... 275 5.4. Ameaças, vulnerabilidades e ataques .... .. ............................................... 277 5.5. Dispositivos e sistemas de proteção .............................. .. .... .. .................. 280 5.6. Normas ABNT NBR ISO/IEC 27001 e 27002- Gestão de segUl'ança

da informação ... .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 287 5.7. NormaABNT NBR ISO/IEC 27005- Gestão de riscos em segurança da

informação ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. .... .. .... ...... ...... ..... .. . 294 5.8. Norma ABNT NBR 15999 -Gestão da continuidade de negócios ........ 295

PARTE 3 REFEReNCIAS BlBLIOGRAFlCAS

CAPíTULo 1 REFERÊNCIAS BmuoGRÁFICAS . . ........... . .......... ................ 299 1.1. Referências de Bancos de Dados ......................................... ...... ............ .. 299 1.2. Referências de Desenvolvimento de Sistemas Web ........... ...... .. ............ 299 1.3. Referências de Engenharia de Software .. ............................................... 300 1.4. Referências de Gestão de Tecnologia da Informação ......... ...... ...... ..... ... 300 1.5. Referências de Segmança da Informação ................................ .............. 301

XVII


Questões para

resolução

PARTE 1


Capítu lo 1

1.1. Modelagem de Dados

A disciplina de Banco de Dados (BD) é bastante relevante em concursos para a

át-ea 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 pet-ceber 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 Heusei; 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. ITJ-ES/Anal ista Judiciário/Análise de Sistemas/2011 I Em um modelo entidade-relacionamento, as entidades fr acas não possuem seus próprios atributos-

-chave. Elas possuem sempre rest riçã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 ocorr e porque uma entidade fraca não

pode ser ident ificada sem um tipo identificador.

2. IMEC/Atividade Técnica de Complexidade Gerencial/Administradorde Banco de

Dados/2011 I Atributos derivados são atributos cujos valores estão relacionados aos atributos armazenados. Como exemplo, tem-se o at ribu to idade, que está

relacionado ao atributo data de nascimento; assim, armazena-se o atributo

data de nascimento e o atributo idade é derivado do at ributo ar mazenado.

3. IMEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco

de Dados/2011 I A restrição de integridade de entidade estabelece que nenhum valor de chave pr imár ia e chave estrangeira pode ser nulo. Se houver valores

nulos para as chaves, então não será possível identificar alguma tupla.


de Dados/2011 I Uma restrição importante das entidades de um tipo entidade

Cl Tecnologia da Informação- Questões Comentadas I Cespe I UnB ELSEVIER

4

é 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.

S. (Correios/Analista de Correios/Desenvolvimento de Sistemas/20111 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 estrangei ra implementa restrições nos sistemas

gerenciadores de bancos de dados relacionais.

6. IMPU/Analista de Informática/Banco de Dados/20101 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

conceituai dá origem a uma única tabela.

7. IMPU/Analista de Informática/Banco de Dados/20101 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. IMPU/Analista de Informática/Banco de Dados/20101 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.

E1 1

/ N E2

<? E3

Considerando o diagrama entidade-relacionamento !E-RI na fi gura acima, julgue o próximo item.

9. IMPU/Analista de Informática/Banco de Dados/20101 No modelo E-R da fi gura, os atributos de uma agregação, de modo geral, coincidem com os atributos do

relacionamento que são englobados.

10. IMPU/ Analista de Informática/Banco de Dados/201 01 Considere a seguinte situação hipotética. Em determinada organização, os funcionários (entidade FI associam-se

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

aos departamentos (entidade DI. por meio do relacionamento de lotação !LI. sendo N funcionários em 1 departamento (N: 11. Também pode ocorrer, concomitantemente

com a lotação, o relacionamento gerencial IGI, 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. IMPU/Analista de lnformática/Barnco de Dados/20101 O termo integridade é utilizado 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 lnformação/20101 A chave candidata, conjunto de um ou mais atributos tomados coletivamente, permite

identificar de maneira unívoca uma entidade em um conjunto de entidades.

13. ITRT21-RN/Analista Judiciário/Tecnologia da lnformação/20101 Uma chave estrangeira é um atributo ou uma combinação de atr ibutos em uma relação, cujos

valores são necessários para equivaler somente à chave primária de outra relação.

cod_comissão nome

atribuições

Comissão (O.n Pessoa

1-r-w cpf

nome

horário_ chegada

Reunião cod_reunião 1...,_- -o data horário_ saída

(1 ,1) L--{) pauta

Proposta 1--.. cod_proposta

descrição data_votação

5


6

A fi gura 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/20091 ER1 é um modelo lógico.

15. (ANATEL/Analista Administrativo/Análise de Negócios/20091 Em R1, o relacionamento "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/20091 ER1 está na terceira forma normal.

17. (ANATEL/Analista Administrativo/Análise de Negócios/20091 Em R1, os elementos "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/20091 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. IANATEL!Analista Administrativo/Anál ise de Negócios/20091 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 reun iões de comissões das quais ela não faz parte.

20. (ANTAQ/Analista Admin istrativo/lnformática/20091 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. IANTAQ/Analista Administrativo/lnformática/20091 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 lnformações/20081 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 lnformações/20081 As caracterí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/20081 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.


25. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 Integridade referencial pode ser definida como uma condição imposta a um conjunto de atr ibutos de uma relação par a que valores que apareçam nesse conjunto

também apareçam em um certo conjunto de atr ibutos de uma outra relação.

26. ISTF/Analista Judiciár io/Análise de Sistemas de lnformações/20081 Chaves est rangeiras podem ser definidas como sendo um conjunto de atributos

pertencentes a um esquema de r elação que constituem chaves primárias ou candidatas em outros esquemas i ndependentes.

HÓSPEDE

PK CPF

NOME Fkl çru;;

CRIANÇA

PK NOME PK, FK1 CPF

IDADE

PK - CHAVE PRIMÁRIA FK- CHAVE ESTRANGEIRA

ENDEREÇO

O ... N HOTEL

- - - ' ATRIBLITO r ' ~ _ _ _ DERIVADO

HOTEL

PK CGC

RUA CIDADE ESTADC NOME

TRABALHA EM

PK, FK1 CGC PK, FK:! CPF

HORAS

~ATRIBUTO ~ MULTIVALORADO

APEUDO _FUNCIONÁRIO

PK APEUDO PK, FK1 ~

FUNCIONÁRIO

PK ~

NOME

7


8

Considerando as figuras I e 11 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/lnformática/20081 Segundo a figura I, para identificar 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 FUN CIONARIO, o atributo APELIDO pode ter

um conjunto de valores. O atributo HORAS pode ser migrado para a entidade

FUNCIONARIO. 28. (STJ/ Analista Judiciário/20081 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 FUNClONARIO; 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/lnformática/20081 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. ITST /Analista Judiciário/Análise de Sistemas/20081 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/20081 Uma chave primária é usada para identificar tuplas individuais em uma relação, não podendo ter o

valor nulo.

32. ITST I Analista Judiciário/ Análise de Sistemas/20081 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. ITST /Analista Judiciário/ Análise de Sistemas/2008 No modelo entidade-rela

cionamento lER I. a modelagem analisa e representa os dados da aplicação de forma independente do processamento que transforma os dados.

34. IMPE-RR/Analista Judiciário/Analista' de Banco de Dados/20081 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ár io tem grau

dois e um ternár io tem grau três.

35. IMPE-RR/Analista Judiciário/Analista de Banco de Dados/20081 A razão de card inalidade 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.

36.


IMPE-RR/Analista Judiciário/Analista de Banco de Dados/20081 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. IMPE-RR/Analista Judiciário/Analista de Banco de Dados/20081 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 t ipo Empregado, podem-se usar nomes de papéis

para definir o significado de cada participação.

38. IMPE-RR/Analista Judiciário/Analista de Banco de Dados/20081 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. IMPE-RR/Analista Judiciário/Analista de Banco de Dados/20081 Um t ipo entidade cujas entidades são identificadas a partir apenas dos valores dos seus

atributos-chave é um t ipo 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.


de Dados/201 11 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.


de Dados/2011 I 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 --7 Y.

42. IMEC/Atividade Técnica de Complexidade Gerencial/Administrador de Banco de Dados/2011 I 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


10

43. IMPU/Analista de Informática/Banco de Dados/20101 Uma relação está na segunda forma normal (2FNI se e somente se estiver na 1 FN e qualquer atributo

da chave for dependente funcional (DFI 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. IMPU/Analista de Informática/Banco de Dados/20101 Se os valores de atributos forem atômicos, ou sej a, estiverem vinculados a um modelo relacional unitá

rio, então nem todas as relações estarão normalizadas ou na primeira forma

normal (1 FNI, segundo definido pela álgebra relacional.

45. ITRT21-RN/Analista Judiciário/Tecnologia da lnformação/20101 A primeira forma

normal estabelece que os atributos da r.elação contêm apenas valores atômicos.

46. (TRT21-RN/Analista Judiciário/Tecnologia da lnformação/20101 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. IANTAQ/Analista Administrativo/lnformática/20091 São objetivos da normalizaçã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. IANTAQ/Analista Administrativo/lnformática/20091 A reversibi lidade é 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/lnformática/20081 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/ Ana lista Judiciário/lnformática/20081 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.

relacão chave primária dependência funcional

R1 CPF CPF ~ NOME, CGC

R2 NOME, CPF NOME, CPF ~ IDADE

R3 CGC CGC ~ RUA, CIDADE, ESTADO,

NOME

R4 CGC, CPF CGC, CPF~ HORAS

51.


!STJ/Analista Judiciário/lnformática/20081 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 cão chave primária dependência funcional

R1 CPF CPF-? AUTOR

AUTOR-? TELEFONE

R2 ISBN, CAPITULO ISBN, CAPÍTULO-? AUTO

RISBN-? TITULO

R3 EDITORA EDITORA-? NOME, EDITOR

52. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 A FNBC exige

que todas as dependências não-triviais sejam da forma r<~. em que a é uma

superchave. A terceira forma normal13FNI também não suaviza essa restrição.

53. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 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 s e responder às demandas dos usuários do Banco de Dados.

54. IMPU/Analista de Informática/Banco de Dados/201 O) 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. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 A operação de j unção externa louter joinJ é uma extensão da operação de junção para

tratar informações omitidas.

56. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 Apenas as operações union e intersect são disponibilizadas pela linguagem SQL para

manipulação de conj untos.

57. ITST /Analista Judiciário/ Análise de Sistemas/20081 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


12

58. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 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. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 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. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 A interseção de duas relações (compatíveis de união) X e V- X INTERSECT V - é o conjunto

de todas as tuplas t pertencentes a X e a V.

61. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 O produto cartesiano de duas relações X e V- X TIMES V- é 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 V.

62. IMPE-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. IMPE-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 lnformação/20091 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 (2PLI.

65. (TCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 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 51 e 52 são equivalentes se existe sincronização

read-write e sincronização write-write.

66.


ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 No

two-phase locking, os locks de d!ados 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.

T1 T2 lock(p11 read(p11

lock(p1) write(p1 I

locklp21 unlock(p1 a

readlp11 write(p11 lock(p21 unlock(p11

read(p21

writelp21 unlock(p21

readlp21

writelp2l unlock(p21

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

subsequentes.

67. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 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, lransações que tenham visto os writes dessas

transações e assim por diante. Esse problema é conhecido como rollback em cascata.

69. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 Quando

uma regra de integridade referencial é violada, o procedimento normal a ser

adotado é rejeitar a ação que ocasionou essa violação.

70. ISTF I Analista Judiciário/ Análise de Sistemas de lnformações/20081 A execução de transações de maneira concor rente 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

Cl Tecnologia da Informação - Questões Comentadas I Cespe I UnB ELSEVIER

14

71. (MPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 As proprie

dades dos sistemas de banco de dados conjuntamente denominadas ACID são

consistência, isolamento e durabilidade. Elas asseguram a integri dade dos

dados nas transações.

72. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 Quando mudanças causadas por uma transação abortada são desfeitas, a transação foi commited;

enquanto uma transação completada c;om sucesso é chamada de rolled back.

73. IMPE-AM/Analista Judiciário/Analista de Banco de Dados/20081 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 é dit a

concluída se estiver em efetivação ou abortada.

74. IBASA/Tecnologia da Informação/Banco de Dados/20101 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 á exist e um shared lock ou um exclusive lock no

mesmo objeto.

75. IBASA/Tecnologia da Informação/Banco de Dados/20101 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 Dados (SGBDs) de várias formas. No en tanto, o conceito mais cobrado tem s ido a

ru-quitetura em t rês esquemas. Em SGBDs distribuídos, a cobrança mais comum

abrange conceitos relacionados a t ransações distribuídas, Commit em Duas Fases ou em Três Fases.

esquema externo

1 mapeamento extemo/conceitual

esquema concenuaJ

1 mapeamento

conceituai/interno

ô ô ô ô ô EHJ esquema interno


Considerando a figura acima, que ilustra uma arquitetura de banco de dados

de três esquemas, julgue os itens subsequentes 176 à 791.

76. ITJ-ES/Analista Judiciário/Análise de Banco de Dados/20111 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 ISGBDI,

os mais conhecidos SGBDs comerciais implementam a arquitetura de banco

de dados de três esquemas por completo.

77. ITJ-ES/Analista Judiciário/Análise de Banco de Dados/20111 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 SOL; 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. ITJ-ES/Analista Judiciário/Análise de Banco de Dados/20111 Na arquitetura em questão, a independência lógica de dados consiste na capacidade de alterar o

"esquema interno" sem mudar o "esquema conceituai" .

79. ITJ-ES/Analista Judiciário/Análise de Banco de Dados/20111 Devido à indepen

dência de dados, provida pela referida arquitetura, as modificações do "esque

ma conceituai" - tais como a adição ou a remoção de um tipo de registro (ou

item) de dados- não causam ou r equerem 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. ITJ-ES/Analista Judiciário/Análise de Sistemas/20111 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 partiicipam 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/lnformáti ca/20111 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


16

82. (QOBM/Complementar/lnformática/20111 Utilizando OLAP, usuários fina is 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/20111 As ferramentas de software ETL (extract transform loadl 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/20111 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/20111 Em um

ambiente data warehouse IDWI, é 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/20111 Ferramentas OLAP (online analytical processingl 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 relató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. (Cor reios/Analista de Correios/Desenvolvimento de Sistemas/201111nteligência 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 Corre ios/Desenvolvimento de Sistemas/20111 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/AnalistaAdministrativo/Tecnologia da lnformação/20101 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.

Capítulo 2

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 concursos públicos. Para abordar o tema, as questões selecionadas foram divididas

sob dois aspectos: • Sintaxe, características e APis -são bastante cobradas em concurso de

ní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ção a objetos - figuram com frequência nas provas que exigem

nível superior. Conceitos de encapsulamento, abstração, herança e polimorfismo devem ser dominados pelos candidatos. Este último, o polimorfismo, é o conceito mais complexo e também o mais cobrado nas

questões.

2.1 .1. Sintaxe, caracterís ticas e APis

90. IMPU/Técnico de lnformática/20101 1 public class ~1puJava2 {

2 public stat ic void main (String args [ ] ) { 3 Integer i • null;


18

4 Int j 5 i;

5 5ystem.out.println ( j );

6 }

7 }

O cód igo na linha 5 produzirá a impre.ssão do conteúdo da variável j que terá

o valor null.

91. (BASA/Técnico Científico/Tecnologia da lnformação/Arquitetura de Tecnolo

gia/201 01 Ao final da execução do trecho de código abaixo, escrito na linguagem

Java, será exibido o valor 21. int [ ] m a {1, 2, 3, 4,5}; int [ ) n • {0, 1, 2, 3, 4}; int s • 0;

f or(int i • e; i<4; i ++) {

i f (m[i] % 2 ! • 0) m[i ] • m[i] + n[i];

}

for ( i nt a : m) s • s + a;

5ystem.out.print(s);

92. IDETRAN-DF/Analista/Análise de Sistemas/20091 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. IEMBASA/ Analista de Tecnologia da lnformação/Desenvolvimento/201 01 O

trecho de cód igo a seguir está incorreto porque comentário em Java não usa

\\. public synchronized ~1essage getllewl-les.sage ( ) {

if (messages . isE•pty ( )) { \\ o código espera aqui }

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

)

94. llNMETRO/Analista/Desenvolvimento de Sistemas/20091 São algumas palavras reservadas da linguagem Java: pubfic, private, protected, c/ass, interface, abstract, extends, implements, super, byte, short, char, int,/ong, float, double,

boo/ean, void, try, catch, finally, throws, throw, import, package, if, e/se, la/se,

true, continue, default, break, return, while, switch, transient, final, synchronized, nu//, new.

95. IPREVlC/Analista de Tecnologia da lnformação/2011 I Em um programa Java, um threadque esteja bloqueado, à espera de um recurso de entrada ou saída,

retornará para o estado de execução quando o recurso for disponibilizado.

96.

Capitulo 2 I Questões de Desenvolvimento de Sistemas Web

IINSS/ Analista de Seguro Social/Ciência da Computação/20081 A tentativa de execução do programa usando a l inha de comando java Reverso 5 joão ma ria josé produziria um erro de runtime. 1 package br.gov.inss; 2 import java.io.DatalmputStream; 3 import java.io.IOException; 4 public class Reverso { S protected static void out (int quantos) throws IOException { 6 OatalnputStream in a new OatalnputStream(System.in ); 7 String na.e; 8 i f ( quantos > 0) { 9 na11e • in .readl ine ( ); 19 lista.insere{name);

11 System.out . println(lista. remove( )); 12 out(quantos - 1) ;

13 Syste11.out.println(naooe); 14 }

15 }

16 public static void 11ain(String args [ J) thro,;s IOException { 17 int quantos • Integer.parselnt(args(0)) ; 18 System.out.println(uentre com u11a sequência de u+quantos+""' nomes.");

19 out(quantos);

20 }

21 static Lista lista a new lista( );

22 private static class r~o { 23 String conteudo; No proximo; 24 No(String c, tiO p) {conteudo a c; proxi110 a p; }

25 }

26 private static class lista { 27 No cabeça 5 null;

28 void insere(String c) { 29 cabeça a new f~o( c, cabeça); 30 }

31 String remove( ) { 32 String conteudo ; null; 33 i f (cabeça !• null) {

34 conteudo • cabeça. conteudo; cabeça a cabeça.proxi.o; 35 }

36 return conteudo; 37 }

38 }

39 }

19


20

97. IEMBASA/Analista de Tecnologia da lnformação/Desenvolvimento/2010) O

trecho de código a seguir está sintaticamente incorreto. If (ChatUser.getBy,lame(getName( ) ) !z null) {

throw new IllegalArgurtentException(uinvali d usernarte""');

} else { ChatUser.addUser(this);

}

2.1 .2. Orientação a objetos com Java

98. IMPU/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 {

}

f loat saldo; public f loat getSaldo(int i ) {

float saldo • Of; i f (i ~ 1) saldo • t his.saldo + 1.93f ; return saldo; } public void setSaldo (float saldo) { this.saldo ~ saldo+ 2ef;

}

class Poupança extends Conta

{

public f loat get Saldo( ) {

return saldo; }

99. IBASA!Técnico Científico/Tecnologia da lnformação/Arquitetura de Tecnologia/201 0) 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. IMEC/Atividade Técnica de Complexidade Intelectual/Analista de Sistemas/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.


class Bicycle {

}

int cadence • e; int speed a e; int gear a 1;

voíd changeCadence(int neWVal ue) { cadence a newValue;

} voí d changeGear(ínt newValue) {

gear • newValue; }

voíd speedUp(ínt íncre•ent) { speed • s peed + incre•ent;

}

voíd applyBrakes(int decrement) { speed a s peed - decre• ent;

}

voíd príntStates() { Systell.OUt.println(((cadence:"+cadence+ .... speed: u+speed+ngear:((+gear) ;

}

class BicycleDemo {

}

}

public static voíd main(Stríng[]args) { Bicycle bikel • new Bícycle(); Bicycle bike2 • new Bicycle(); bikel.changeCadence(S9); bikel.speedUp(l9); bíkel.changeGear (2); bikel.pr í ntStates() ; bike2.changeCadence(S9); bike2.speedUp(l9); bíke2.changeGear (2); bike2.changeCadence(49) ; bike2.speedUp(l0); bíke2.changeGear(3); bike2.prí ntStates( );

101. IDETRAN-DF/Analista/Anátise de Sistemas/20091 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


22

102. IDETRAN-DF/Analista/Análise de Sistemas/20091 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. ITRT - ES/Técnico Judiciário/Tecnologia da lnformação/20091 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. ITRE-ES/Analista/Análise de Sistemas/20111 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. IFUB/Analista de Tecnologia da lnformação/20111 Uma classe abstrata não pode ser di reta mente instanciada. Somente as subclasses derivadas por he

rança múltipla de classes abstratas, chamadas de classes concretas, podem

ser instanciadas.

106. ITRE-ES/Técnico/Programação de Sistemas/2011 I O encapsulamento em Java

somente pode ser realizado por meio do modificador de acesso protegido.

107. (Correios/Analista de Sistemas/Desenvolvimento de Sistemas/20111 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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 setSal do (float saldo) {

t his .saldo a saldo+50f; }

class Poupanca extends Conta {

public f loat saldoConta( {

return saldo; }

}


public class Principal

{

}

public stat i c voi d main ( Str i ng args[ ]) {

}

conta pl s ne~o~ Poupanca( ) j

((Poupanca}pl}.setSaldo(4S0f); System.out . pri ntln(''saldo: " +( (Poupanca}pl }. saldoCont a( )) ;

109. IDETRAN-DF/Analista/Análise de Sistemas/20091 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 comportamen tais) e seu propósito.

Conhecer a classificação é fundamental para eliminar opções nas questões.

Em muitos casos, apenas o conhecimento da class ificação é suficiente para determinar se um item está correto.

Cada padrão está documentado ,sob o formato: intenção (propósito), motivaçã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 ch ance mínima de serem cobradas. As questões a seguir t ratam dos 23 padrões de projeto da chamada "gangue

dos quatro" (GoF ou Gang o(Four- os quatro autores do Livro Padrões de Proj eto - S oluções Reu tilizáveis de Sof"tware Orientado a O~jetos).

110. ITRT-RN/Técnico Judiciário/Tecn ologia da lnformação/20101 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 lnformação/20081 Os padrões de projeto podem ser usados no proj eto orientado a obj etos 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


24

112. (TJ-DF/AnalistaJudiciário/Tecnologia da lnformação/20081 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/TecnoUogia da lnformação/20091 O uso de padrõ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/20081 Adapter é um padrão

estrutural utilizado para compatibilizar interfaces de modo que elas possam

interagir.

115. (SERPRO/Analista/Desenvolvimento de Sistemas/20081 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 lnformação/20091 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 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 deipendentes sem especificar suas classes concretas, é mais indicado que o padrão de criação Prototype.

118. ITCU/ Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 Se, no desenvolvimento de uma aplicação que leia documentos do tipo txt e sej a 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. IINMETRO/Analista/Desenvolvimento de Sistemas/20091 Alguns dos usos

típicos do padrão Façade são a unificat;ã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 deipendências entre um cliente e múltiplas classes de implementação e o encapsulamento de todas as demais interfaces

públicas de um sistema.


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 serulets são detalhadas nos itens a seguir. Outras como JMS e J CA fazem parte de escopo complementar que deve ser conhecido pelos candidatos. Perceba que, por hora,

t ratamos 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.

Ass im, 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 m·quitetura é 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. ITJ-ES/Analista Judiciário/Análise de Sistemas/20111 Na arquitetura J2EE, o

container web Apache Tomcat pe:rmite 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 I 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. IPREVIC/Analista de Tecnologia da lnformação/2011 I Em uma aplicação multicamadas na plataforma Java EE, servlets, JavaServer Faces e JSP consistem

em tecnologias utilizadas na camada web. 123. ITRE-BA/Analista Judiciário/Anál ise de Sistemas/20101 O Enterprise Java

Beans IEJBI, cuja especificação mais recente é a da versão 2.1, define, em

sistemas Java, um conjunto de tecnologias utilizadas do lado cliente.

124. ITRE-BA/Analista Judiciário/Análise de Sistemas/20101 Em um sistema de transação distribuído, o Java Transaction API IJTAI permite especificar um

conjunto de interfaces entre o gerenciador de transações e as partes envolvidas.

125. !STJ/Analista Judiciário/Tecnologia da lnformação/20081 Na plataforma J2EE, uma aplicação web para a Internet pode ser composta por servlets, Java Serve r

Pages IJSPI 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 IMVC). Nesse caso, pode-se usar servlets operando

25


26

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/20111 Ao usar tag personalizada JSP, é suficiente cariregar uma URL que indique a localização do arquivo TLD para a biblioteca que se deseja acessar.

127. IPREVlC/Analista de Tecnologia da lnformação/20111 O container JSP provê uma lista de objetos instanciados, chamados de objetos implícitos. É através do objeto aplicação lapplication objectl que são rastreadas as informações de um cliente específico entre múltiplas requisições.

128. [SECONT -ES/Auditor/Tecnologia da lnformação/20091 No desenvolvimento de uma aplicação web que siga o padrão JEE, a tecnologia JSP (Java Server Pagesl 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. IMPU/Analista de lnformática/Perito/20101 Os programas a seguir, que constituem 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. <htlll>

<body> <for11 action•.O.OVendaServle~' methoda:""POSl..,>

Produto:< i nput t ype11f'"text""' mame;;"btOesc" value~11" size~"30" /><br> Compra:<i nput t ypea:ntextn na11ec"btCo11pra" value~~~~~ / ><br> Venda : <input t ype.;r!"textn name;;nbtVenda" valuec-'""" /><br>

<input type.a...,submit"" valuea•'Executa" namea,..btExecutar" / >

</forll> </body>

<htlll>

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 (atext/ htlll;charset aUTF-8"');

PrintWriter out ~ response.getWriter{ ); String produto a request .getParameter{''btDesc"'); float compra a Float. parseFloat ( request.getParameter(ubtComprcr'")) ;

float venda ;;; Float.parseFloat (request .getParameter("btVenda"));

}

}


f loat l ucro ~ venda · coMpra; out . println {"< htlll> .... );

out. println (i1< headY"); out.println (u<title>Mpu VendaServl et</titl e>u); out. println (u<head>""); out. println ("< body>"");

out . println (u<hl>O lucro + lucro + "</hl>"); out . println (u< body>"'); out . println {"< htlll> .... );

130. IMPU/Analista de lnformá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. IMPU/Analista de lnformática/Perito/2010) O contêiner, que executa JSP, transforma o programa JSP em Servlet, assim, a expressão "< %=Math.Randomll% >··se torna argumento para out.printlnll.

132. IMPU/Analista de lnformá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. i 11port java.io. • ; import javax.servlet. • ; i 11port javax.servlet.http. +;

public class MpuServletl extends HttpServl et (

}

protected void doGet (HttpServletRequest request, HttpServletResponse response) thro1~s ServletException .. IOException {

}

response. setContentType ( 1'"text/html; charset;;UTF- 8" .. );

PrintWriter out • response.getWriter( ); out . println ("t<htlll>11

) ;

out . println e"<heady'"); out. println (u<title>Concurso toiPU</title>"'); out.println (u</head>"');

out. println (u< body>"'); out.println (u<hl>Concurso do NPU -Tel a 1</hl>""};

response.flushBuffer( ) ; RequestOispatcher rd a request . getRequest0ispatcher(((MpuServlet2""); rd.forward(request,. response) ; out.println (u</body>"") ;

out . println (u</html>"') ;

out.close( );

27


28

i mport j ava. i o.•; i mport j avax. servlet. • ; i mport javax. s ervlet.http.•; public class 11puServl et2 ext ends Ht t pServlet (

}

protected void doGet (HttpServlet Request request, HttpServlet Response response) thra~s Servl etExcepti on, IOException (

}

res pons e .setContentType (utext / htlll; charset.;;UTF-8n) ;

Pri ntWriter out a response . getWriter( ); out. pri nt l n (~"<html>"') ;

out. pri nt l n (""<head>...,) ;

out. pri nt ln C'<t itl e>Concurso MPU</ t itle>..,) ;

out.pri nt l n ("'</head>"); out. pri nt l n (u<body>n) ;

out.pri nt ln C"<hl>Concurso do MPU - Tela 2</hl>"); out. pri nt l n (''< / body>"); out. pri nt l n (""</html>");

out. close( ) ;

133. (CBM-DF/Oficial/lnformática/20111 O uso de Javabeans, o controle de trans

ferência entre as páginas e o suporte independente de app/ets Java pelos

browsers são possibilidades proporcionadas pela action tag da JSP.

134. ITRE-ES/Técnico/Programação de Sistemas/20111 Nos beansde 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. IMPU/Técnico de lnformática/20101 A plataforma adotada pela SUN para a sua versão 6 do Java EE é o JBoss, que implementa resposta para requ isições JSP

e WebServices e ainda permite implantar serv/ets.

136. (TCU/Auditor Federal de Cont role Externo/Tecnologia da lnformação/20101 A web profile da plataforma JEE apresenta, em relação ao perfil app/ication

serverdefinido em edições anteriores da plataforma Java, as seguintes vanta

gens: fornece suporte para POJOs [plain o/d Java objectsl e annotations; possui

modelo de empacotamento de compon entes mais simples; a configuração dos

seus descritores XML [extensible markup languagel é mais fácil ; é aderente

ao padrão SOA.

137. (TCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 A tecnologia EJB [enterpriseJavabeans) apresenta, na sua versão 3.1, melhorias

que propiciam facilidades para o uso de beans singletone que permitem o uso

de beansde uma classe, sem necessidade de desenvolvimento de sua interface

correspondente, e a invocação assíncr ona de beans de sessão.

Capitulo 2 I Questões de Desenvolvimento de Sis te mas Web

138. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101

No desenvolvimento de conteúdos para apresentação, o uso de face/ets traz

vantagens em relação ao uso de JSP. Uma delas é a maior modularidade, com

o uso de templates e componentes compostos lcompositel.

2.3.2. JSF

139. ITRT-RN/Analista Judiciário/Tecnologia da lnformação/20101 Portletsé um subprojeto do Java Server Faces (JS FI que permite integração com o Apache

Myfaces e que tem como característica nativa a criação de temp/ates com

componentes reutilizáveis utilizando o XHTML como tecnologia de view do

JSF.

140. ITRE-BA/Analista Judiciário/Aná lise de Sistemas/20101 Entre os itens que o padrão Java Server Faces IJSFI utiliza, estão os componentes, os eventos e a

navegabilidade.

141. IMPU/Analista de lnformática/Perito/20101 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 lc/ient-sidel.


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 processamento de pedidos http assíncronos.

143. ISECONT-ES/Auditor/Tecnologia da lnformação/20091 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. IMPU/Técnico de lnformática/201 01 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. ISECONT -ES/Auditor/Tecnologia da lnformação/20091 O Hibernate, um framework de mapeamento objeto relacionaliORMI, 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


30

146. ITRE-BA/Analista Judiciário/Análise de Sistemas/20101 No Hibernate, apenas a l inguagem de consulta HQL [hibernate query languagel pode ser utilizada. A

HQL executa os pedidos SQL sobre as cnasses 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/Oesenvolvimento de Sistemas/20091 Considerando que para o uso da tecnologia Hibernatena ninguagem Java são empregados, usual

mente, dois t ipos de arquivos: (i) configuração e (ii) mapeamento, sendo a l ista

a seguir uma sequência de elementos:XML utilizados na tecnologia Hibernate:

(a/ hibernate-mapping (bJ c/ass; fel generator; (d/ property; fel session-factory;

e (fi 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:

{la, ii), (b, ii), (c, i), (d, iii, (d, ii, !e, i), (f, i)}. 148. (CBM-DF/Oficial/lnformática/2011 I 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. IMPU/Analista de lnformática/Perito/20101 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 a sessionFactory.openSess.ion( ) ; Transacti on t rans • s es. beginTransaction( ) ; f or ( i nt i c0; i<200000; i ++) {

}

Pessoa p a 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 n o 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 rú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..


150. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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. IBA5A/Técnico Científico/Tecnologia da Informação/Análise de 5istemas/20101

A sintaxe da l inguagem 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. !lN METRO/Analista/Desenvolvimento de Sistemas/20091 Alguns dos efeitos da carga do scriptabaixo em um browserhabilitado para execução de scriptsna linguagem JavaScripte que a suporta, são: o título da janela do browserserá

Página 1 e o conteúdo da página apresentada será a expressão Olá!

<IOOCl'IPE HTML IUILIC "·//W3C//DTD lOiTML 4.01//EN'' "http//looWW.w3.org/TR/html4/ strict.dtd''> <html>

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

<body> <scri pt t ypea11t ext/javascr i ptn>

document.write( 1 olá! '); document .title~'Título';

</script>

<noscript> <p>Se• JavaScript.</p>

</nosc ript> </ body>

</html>

153. (SERPRO/Analista/Desenvolvimento de Sistemas/20081 O Javascript expande

as capacidades de uma página HTML e, unido ao CSS, formou o DHTML.

154. IANATEL/Especialista em Regulação/lnformática/20061 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

defi nido com tags HTML ou com a linguagem Cascading Sty/e Sheets. O cód igo

que define o estilo de um documento HTML tem de ser armazenado no mesmo

arquivo no qual está o documento. 1 <SCRIPT LANGUAGE• 1

.. JavaScript1.1" SRC• nval i da. j s">< / SCRIPT>

2 <BODY>

3 <FORM onSub•it~'this.primeiro.opcional a t rue; > 4 this.fone.opcional a: true;

5 this.cep.numeri co 5 t rue; t his.cep.•in a 0; t his.cep.MaX a 99999; 6 this.idade.nu•erico a true; this.idade.min • e; this . idade.max . 129; 7 return verif ica (this) ;n M.ETH00;;f" .. postn>

31


32

8 Pr inteiro nome: <INPUT TYPEat ext f~AME:;;"prilleiro">

9 Úl t imo nome: <If•PUT TVPE• text NAME#"' ul t imo"><BR> 19 Ender eço: <TEXTAREA NAJotE;;:...,enderecon ROW$:;;4 COLS;;40''></TEXTAREA><BR>

11 CEP: <INPUT TYPE=text NAME="cepu onkeypress="window. status=ehBr anco(cep. value) ;"><BR>

12 Fone: <INPUT TYPEatext NA.ME;;"''fone,. onblur;aler t( 'esqueceu o ddd?' )"><BR>

13 Idade : <INPUT TYPE;;t ext tJAME;;...,idade"><BR>

14 <INPUT TYPE;;submit NAME;;;-''Sublleter'•>

15</FORM> 16</BODV>

1 funct ion ehBranco(s) 2 {

3 for{var i ;;: e; i <s.length; i ++) { var c ;;: s.charAt (i);

4 if((c !• ' ') && (c ! a '\n') && (c !a' \ t ')) ret urn false; 5 } ret urn t r ue; 6 }

7 funct ion veri f i ca( f ) B { var 11sg; var e11pty_f i elds ;; un; var errors .a

9 for (var i a 9; i< f.lengt h; i++) { 19 var e ;;: f .ele11ent s( i );

ttll .

'

11 if ((e. type .. " t ext") l i (e. type aa"textarea")) {

12 if (!e.opciooal&& ((e.value == rull) 11 (e.value == '"') ll •hBranco(e.value))) {

13 empt y_fields •"''\n u + e .name; 14 continue; 15 ) 16 if (e.llUilerico && ((e.lllin !•null li (e .111ax !•null))) { 17 var v 5 parseFloat (e .value); 18 if (isllaN(v) l i 19 ((e.min !a null) && (v < e.11in)) l i 29 ((e. max !a null) && (v < e.11ax))) {

21 errors +~ ((- e campo ., + e. na11e + (( deve ser u11 nú11er a'J;

22 i f (e.11i n !a mull) error s +5 tt 11ai or que tt + e.mi n; 23 i f (e.11ax ! ~ null) errors +a « e menor que « + e .11ax; 24 else i f (e. raax !a null} en-ors +• que é IDef'lor que ,,+ e .~~ax;

25 error s +• u. \ n"J;

26 }

27 }

28 }

29 }

30 if ( !empty_f i elds && !errors) ret urn t rue; 31 11sg • uo formulário não foi submeti do. \n";

32 if (empty_fields) { 33 msg +;; usão campos vaz ios: "+empty_f i elds +"\n"; 34 i f ( er ror s) msg +;;: "\n'"';

35 }

36

37

38

39 }

Capitulo 2 I Questões de Des envolvimento de Sis te mas Web

msg +~ error s;

alert( ntsg) ; ret urn false;

Os códigos acima, adaptados de JavaScript: lhe 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ód igos apresentados.

155. ISTF/Analista Judiciário/Tecnol.ogia da lnformação/20081 A página HTML

apresentará um botão de formulário cujo rótulo é Submeter.

156. ISTF/Analista Judiciário/Tecnologia da lnformação/20081 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. ISTF/Analista Judiciário/Têcnologia da lnformação/20081 A página lêSiê.html é bem formada, conforme a especificação: XHTML ou HTML 4.01.

158. ISTF/Analista Judiciário/Tecnologia da lnformação/20081 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. ISTF/AnalistaJudiciário/Tecnologia da lnformação/20081 Considere a situação na qual um usuário esteja preenchendo o campo fone, que já se encontra preenchido 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. (Corre ios/Anal ista de Sistemas/Desenvolvimento de Sistemas/20111 O

Ajax incorpora diferentes tecnologias, como o DOM, o XML, o XSLT, o objeto XMLHttpRequest,o objeto XMLHttpResponse e o Javascript, cuj a função é fazer a junção entre os elementos.

161. IMPU/Anali sta de lnformática/Peri to/20101 O objeto XMLHttpRequest apresenta a estrutura das páginas web como um conj unto de objetos programáveis que pode ser manipulado com JavaScript.

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

33


34

A figura abaixo apresenta um código que pode ser interpretado por um browserweb padrão habilitado para funcionamento com a tecnologia Ajax e que a suporta. A respeito do comportamento desse browserquando o usuário interagir com a correspondente página renderizada,julgue os itens subsequentes. <htlll>

<body> <script type;;"text / Javascript""> f uncti on ajaxFunction() {

}

if (window.XI1LHttpRequest) {!/IE7 .. , Firefox, Chrome, Opera, Safari alert(''Seu browser suporta Ajax!");

} else { alert('"Seu browser não s uporta Ajax!");

}

</script>

<Torll namea"''f or11ul ario"> ~~orne: <input t ype:a·"text" name~; .... nolle" onkeydowna',ajaxFunction{) /'I> Hora: <input t ype="text'' name;;nt ora" />

</form> </ body>

</ht lll>

163. (INMETRO/Analista/Desenvolvimento deSistemas/20091 Sempre que o usuário pressionar uma tecla nos campos nome e hora do formulário de nome formulário, será apresentada uma janela pop-up ao usuário com a expressão: Seu

browser suporta Ajax!

164. (lN METRO/ Analista/Desenvolvimento de Sistemas/20091 Um novo pedido HTTP será enviado pelo browserao servidor HTTP que enviou a página sempre que

a função ajaxFunction for executada C•Om sucesso.

2.5. lnteroperabilidade 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 diferenciaçã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 relacionamento com Web Services e modelagem de processos de negócio.

Capitulo 2 I Questões de Des envolvimento de Sis te mas Web

2.5.1. XML

165. ITRE-ES/Técnico/Programação de Sistemas/20111 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. ITRE-ES/Técnico/Programação de Sistemas/2011 I <pessoa> <no• e > Fulano de Tal </noMe >

<matricula>l23456</matricul a>

<cargo>Coordenador</cargo> <departamento>

<s ala>10e1</s al a><rallal>12.34</depart amento> </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. ITRE-BA/Analista Judiciário/Análise de Sistemas/20101 As marcações XML

não fazem distinção entre letras m inúsculas e maiúsculas.

168. ITRE-BA/Analista Judiciário/Aná lise de Sistemas/20101 A instrução a seguir

está sintaticamente correta e permite o uso de algarismos romanos para co

dificação de números. <? xml version.,.'l. 0'" encodinga''I SSO- 8859-ln ? >

169. IINMETRO/Analista/Desenvolvimento de Sistemas/20091 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 processament o de XML pode-se empregar um parser do

tipoSAX.

170. ITRT-RN/Analista Judiciário/Tecnologia da lnformação/20101 A XSD- XML schema definition permite definir elementos e at ributos que podem aparecer

em um documento XML, tal como um DTO (document type definitionJ.

171. ITRT -R N/ Analista Judiciário/Tecnologia da lnformação/20101 Considere que haja a necessidade de publ icar dados de trâmites de processos que se encon

tram armazenados em XML, no :sít io 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 cond ições requeridas.

35


36

2.5.2. Web Services

172. IBASA/Técnico Científico/Tecnologia da Informação/Análise de Sistemas/20101 O SOAP (simple object access protoco•ll, muito ut ilizado no transporte de da

dos dos web services, permite que aplicações troquem informações usando

requisições HTTP em formato XML. 173. ITCU/ Auditor Federal de Cont role Externo/Tecnologia da lnformação/20101

Considere que um líder tenha solicit.ado a um programador do proj eto que

comentasse o seguinte trecho de código. POST / obj ectURI HTTP/ 1. 1 Hos t : www.foo.com SOAPMethodName : urn:develop-com:IBank#getBal ance Cont ent-Type: t ext / xml Cont ent- 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 servidor http ( hypertext transfer protocoll de endereço www.foo.com, embasado

no modelo de comunicação SOAP (simple object access protocoll, que apenas o cabeçal ho 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. ITCU/ Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 one-way

B ······················· <inp~> .................... g request·response r-::::=1 ....................... <inp~> . ............. ~

~~ .................. } <output>O·········· .. ···L..:::..J so/icit-response

Client ~····· · ··· · ··· · ······ <output>O···············~ ..._ ___ _, ....................... <inp~> .............. c::::._j

notification

a~ .................. <output> ..................... a


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. IPREVIC/Analista de Tecnologia da lnformação/20111 Uma mensagem SOAP lsimple object access protocoll 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 lnformação/20081 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. IMPU/Técnico de lnformática/20101 A descrição de um web service é feita

utilizando-se WSDL I Web Services Oescription Languagel, que é uma linguagem embasada em RPC IRemote Procedure Cal li e UDDIIUniversa/ Description

Oiscovery and /ntegrationl, com a qual se descreve a forma de acesso dos

serviços e seus parâmetros de entrada e de saída.

178. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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 • ""StockQuoteServi ce">

<documentation>My f irst service</documentation> <port nante=»stockQuotePor t""' bi ndingantns :StockQuot eBinding">

<soap:address location.;;:nht tp://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 I web

services description languagel e que, embora o serviço descrito contenha uma única porta, é possível a definição de várias portas associadas a um mesmo

servico, a análise feita deverá ser considerada correta.

179. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 Em WSDL, os elementos do t ipo 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

W3CXML.

37


38

180. !STJ/Analista Judiciário/Tecnologia da lnformação/20081 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 t ipos usados pelo serviço e a parte

abstrata especifica como e onde o serviço pode ser contatado. Os documentos

WSDL podem ser a cessados via um serviço de diretório como o UDDI; as defi

nições WSDL podem ser geradas a par tir de definições de interfaces escritas

em outras linguagens.

181. (Antaq/Analista Administrativo/lnformática/20091 Web servi c e é 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 /anguagel.

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

grationl. Os serviços (operações, mensagens, parâmetros etc.) são descritos

usando-se a linguagem WSDL ( web services description languagel. O processo

de publicação, pesquisa e descoberta de web servicesutiliza o protocolo SOAP

[simp/e object access protoco[J.

182. ITRT -RN/ Analista Judiciário/Tecnologia da lnformação/20101 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.

SOA System lnc.


183. IMPU/Técnico de lnformática/20101 REST IRepresentationa/sState Transferi é uma tecnologia que está sendo utilizada em web services, como substituta

das tecnologias SOAP ISimple Object Access Protocol) e WSOL.

184. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 O estilo de arquitetura de software denominado REST (representational state transferi demanda mais recursos computacionais que o modelo de desenvol

vimento de sistemas embasado em SOAP lsingle 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. ITRT -BAIAna l ista Judiciário/Tecnologia da lnformação/20081 Na visão do SOA, XML e WSOL 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 l inguagem de programação nos quais o serviço está

implementado.

186. ITRT -BA!Analista Judiciário/Tecnologia da lnformação/20081 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 servíces

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 !SOAI:

Receber Petição

Analisar Petição

Publicar Decisão no DOU

187. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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 lnformação/20101 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


40

189. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 Uma equipe de desenvolvimento de software recebeu a incumbência de desenvolver

um sistema com as características apr esentadas a seguir.

• O sistema deverá ser integrado, interoperável, portável e seguro.

• O sistema deverá apoiar tanto o processamento online, quanto o suporte a

decisão e gestão de conteúdos.

• O sistema deverá ser embasado na plataforma JEE (Java enterprise edi

tionl v.6, envolvendo servlets, JSP (Java server pagesl, 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 webem Java.

Para o projeto em tela, é recomendado que se adote uma arquitetura orientada

a serviços web (SOA e web servicesl porque esse tipo de arquitetura facilita

o reuso de componentes de software fisicamente distribuíveis, além de ser

embasado em l igação estática entre provedores e consumidores de serviço.

Capítulo 3

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 n o nível de pt'Ofundidade crescente das questões . Assim, nos últimos anos tem s ido

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çã1o

Apesar da grande complexidade da APF para aplicação prática, na con tagem de sistemas, em geral as questões de pr ova sobre o assunto são s imples, por t ratar

apenas dos conceitos básicos da técnica e não das lnínúcias das regras de contagem. É recomendável, entretanto, conhecer bem as principais diferenças entre

as práticas do IFPUG e da NESMA, t ema que tem se tornado mais frequente em provas recentes .

3.1.1. Conceitos básicos de APF

190. (AnateVAnalista Administrativo/ Análi se de Negócios/20091 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 deletel são consideradas pertencentes às entradas externas.

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


42

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. ITRE-PR/Analista Judiciário/Análise de Sistemas/20091 Registras lógicos são subconjuntos de dados dentro de um ALI/AlE que foram reconhecidos pelo

usuário. Caso o usuário não reconheça subconjuntos de dados em um ALI/AlE,

este deve ser contado como um registro lógico.

193. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Na análise

por pontos de função [APFI, 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 [AlEI bem como os arquivos lógicos internos [ALI!.

194. (TJ-ES/Analista Judiciário/Análise de Sistemas/20111 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/20111 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 J 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/20111 Um arquivo

de interface externa é obrigatoriamente um ALI de outra aplicação.

3.1 .2. APF segundo o IFPUG

198. [lnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó

cios e Tecnologia da lnformaçã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. ITRE-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. [lpea/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,

Capítulo 3 I Questões de Enge nhar ia de Softwa re

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. ITRE-BA/Analista Judiciário/Análise deSistemas/201 01 Em um projeto de desenvolvimento, 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. ISTM/Analista Judiciário/Análise· de Sistemas/20111 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. ISTM/Analista Judiciário/Análise de Sistemas/20111 A NESMA INetherlands Software Metrics Users Associationl 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 proj etas 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/20081 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 projetas já executados e medidos.

205. (Sebrae/Analista Técnico/20081 AAPF 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. ITCU/Auditor Federal de Control e Externo/Tecnologia da lnformação/20101 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnfor mação/20101 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 I 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnfor mação/20101 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.

43


44

3.2. Modelos de Processos de Desenvolvimento de Software

Neste tópico são abordadas as questões sobre os principais processos de desenvolvimento de software. P ressman e Sommerville são os principais autores. O

modelo em Cascata, den ominado 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 des.ses asstmtos em con cursos do Cespe.

210. IMEC/At ividade Técnica de Complexidade Gerencial/Análise de Sistemas/20111 O modelo Waterfall tem a vantagem de facilitar a realização de mudanças sem

a necessidade de retrabalho em fases já completadas.

211. IMEC/At ividade Técnica de Complexidade Gerencial/Análise de Sistemas/20111 O processo de desenvolvimento de software é uma caracterização descrit iva

ou prescritiva de como um produto de software deve ser desenvolvido.

212. IMEC/At ividade Técnica de Complexidade Gerencial/Análise de Sistemas/20111 No modelo de prototipação, o processo de desenvolvimento de software é

modelado como uma sequência linear de fases, enfatizando um ciclo de desenvolvimento de breve duração.

213. [SERPRO/Analista/Desenvolvimento de Sistemas/20101 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. ITRE9-BA! Analista Judiciário/ Análise de Sistemas/20091 Um modelo de processo de software consiste em uma representação complexa de um processo

de software, apresentada a partir de uma perspectiva genérica.

215. ITRE9-BA!Analista Judiciário/Análise de Sistemas/20091 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 Administrat ivo/Tecnologia da lnformação/20091 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. IANAC/Analista Admin istrativo/Tecnologia da lnformação/20091 A fase de proj eto define o que o software deve fazer, enquanto a fase de elicitação de

requisitos define como o software deve atingir seus requisitos.

218. IANATEL/Analista Administrativo/Análise de Negócios/20091 Um protótipo evolutivo apresenta, de forma geral, maior manutenabilidade e escalabilidade

quando comparado a um protótipo descartável.

Capítulo 3 I Questões de Enge nhar ia de Software

219. (ANATEL/Analista Administrativo/Análise de Negócios/20091 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-UM L é mais comum nas abordagens

ágeis. 220. IANTAQ/Analista Administrativo/lnformática/2009) O modelo em espiral, que

descreve o processo de desenvolvi mento 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 lnformática/20091 A prototipação, uma aborda

gem para desenvolvimento de software na qual se cria um modelo do software que será implementado, é compo·sta de quatro etapas: planejamento, análise

de risco, engenharia e avaliação do cliente.

222. (SERPRO/Analista/Desenvolvimento de Sistemas/20081 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/20081 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. ITST/Analista Judiciário/Análise de Sistemas/20081 O modelo RAD (rapid application development) consiste em uma forma de prototipação para esclarecer

dúvidas da especificação do software.

225. ITST/Analista Judiciário/Análise de Sistemas/20081 No modelo de desenvolvimento sequencial l inear, a fase de codificação é a que gera erros de maior

custo de correção.

226. ITST/Analista Judiciário/Análise de Sistemas/20081 O modelo de desenvolvimento em espiral permite repensar o planejamento diversas vezes durante o desenrolar do projeto.

227. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 O modelo de desenvolvimento sequencial linear temt 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/20081 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. IMPE-AM/Analista Judiciário/ Analista de Sistemas/20081 O modelo RAD (rapid application developmentl é especffico para projetos de software que empregam

linguagens de programação de terceira geração.

45


46

230. (MPE-AM/Analista Judiciário/ Analista de Sistemas/20081 O modelo de desenvolvimento 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/20081 Empregando o modelo de desenvolvimento em espiral, o software é desenvolvido em uma série

de versões intermediá rias incrementais.

232. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 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 projetas .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 I Conforme o RUP, o plano de teste, artefato da disciplina de teste de responsabilidade do testador, reúne

as informações necessárias para plan:ejar 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 I Elaboracão, no contexto

do RUP, é uma fase que visa criar a bas.eline para a arquitetura do sistema a ser

desenvolvido e, no contexto de engenharia de requisitos, a elaboração consiste

em atividade cujo objetivo é o desenvol vimento de um modelo técnico refinado

das funções, características e restrições do sistema.

235. IMEC/Atividade Técnica de Complexidade GerenciaVArquiteto de Sistemas/2011 I

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.


236. ISERPRO/Analista/Desenvolvim~nto 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. ISERPRO/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. ISTM/Analista Judiciário/Análise de Sistemas/20101 O RUP lrational 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. IMPU/Analista de lnformática/D~senvolvimento/2010) Na fase de elaboração do RUP, são desenvolvidas as funcionalidades do sistema e implementados os

requ isitos identificados na fase de concepção.

240. IMPU/Analista de lnformática/Desenvolvimento/2010) O processo unificado I PUI é um processo iterativo para a análise de projetos orientados a objetos,

no qual o trabalho e as iterações são organizados em t rês fases principais:

concepção, elaboração e construção.

241. IMPU/Analista de lnformática/Desenvolvimento/20101 No PU, a elicitacão de requisitos do sistema de software inicia-se na fase de concepção.

242. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformaçã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. ITCU/Auditor Federal de Cont role Externo/Tecnologia da lnformaçã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. ITRE9-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. ITCE-RN/Assessor Técnico de lnformática/20091 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


48


A criação de baselines no RUP tem como motivação a rastreabil idade, 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. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 A modelagem de negócios (business modelingl é 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. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 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 qu:e a execução do workflow de gerência de

proj etas enfatize, durante as iterações in iciais, as atividades de planejamento,

em detrimento das atividades de monitoramento e controle.

249. ISTF/Analista Judiciário/Análise de Sistemas de lnformações/20081 O documento 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/lnformática/20081 No RUP (rational unified process),

um ciclo de desenvolvimento é dividi do 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/lnformática/20081 No RUP, a fase denominada elaboração (elaborationl é aquela em que as atividades da disciplina implementação

(implementationl 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 u.m estado que permite a sua instalação

no ambiente dos usuários para início do teste beta.

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


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

254. ITST/Analista Judiciário/Análise de Sistemas/20081 A integração de compo

nentes é definida essencialmente na fase de construção.

255. ITST I Analista Judiciári o/ Análise <de Sistemas/20081 Como o desenvolvimento é iterativo, a priorização do desenvolvimento é realizada ao final da fase de

iniciação, mas é revista de acordo com os r iscos de projeto a cada iteração.

3.4. Processos Ágeis

Estes processos surgiram com o manifesto ágil no qu al vários autores da

área de engenharia de software decla raram: "Estamos descobr indo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudan do outros a fazê-lo". O eXtr eme Programming (XP ) e o Scrum são os principais processos

ágeis cobrados em con cursos. O XP, proposto por Kent Beck (livro Programação Extrema Explícada), é uma

metodologia bastante nova que renega todos os paradigmas do desenvolvimen to tradicional de software.

Já o Scrum, proposto por Ken Sc!hwaber, é um processo bastante leve para

gerenciar e con trolar projetos de desenvolvimento de soft ware 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 t ratam, equivocadamente, como um processo de desenvolvimento de software.

256. IMEC/Atividade Técnica de Complexidade Gerencial/Arqu iteto de Sistemas/20111 O SCRUM é um método ágil em que todos os itens do sprint backlog

advêm do product backlog.

257. IMEC/Atividade Técnica de Complexidade Gerencial/Arqu iteto de Siste

mas/20111 O desenvolvimento de um código na Extreme Programming está

relacionado à fase de planejamemto, pois, nessa metodologia, não há fase de

desenvolvimento, haja vista que a codificação é realizada em pares.

258. (Cor reios/Analista de Correios/Desenvolvimento de Sistemas/20111 Para que

se obtenha sucesso na utilização do Scrum, o cliente deve se tornar parte da

equipe de desenvolvimento do software, participando di reta mente do processo.

259. (Cor reios/Analista de Correios/Desenvolvimento de Sistemas/20111 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 Bodyof Knowledge ou

49


50

PRINCE2, o Scrum caracteriza-se por apresentar uma abordagem elementar

do gerenciamento de projetos.

260. ISERPRO/Analista/Desenvolvimento de Sistemas/20101 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. ISERPRO/Analista/Desenvolvimento de Sistemas/20101 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 IRAD Toolsl.

262. ISERPRO/Analista/Desenvolvimento de Sistemas/201 01 Scrum é uma metodologia 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. ISTM/Analista Judiciário/Análise de Sistemas/20101 O extreme programming

IX PI, 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. IMPU/Analista de lnformática/Desenvolvimento/20101 Extreme programming

IXPI é embasado em requisitos conh·ecidos, 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. IMPU/Analista de lnformática/Desenvolvimento/20101 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. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 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. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 O

desenvolvimento adaptativo de software IDAS) é uma técnica para construção de

sistemas e software complexos que foca na colaboração e na auto-organização

da equipe.



agilidade não pode ser aplicada a todo e qualquer processo de software.


processo XP (extreme programmingl envolve a realização das atividades de

planejamento, de projeto, de codificação e de teste.


atividade de planejamento XP indu i 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 A atividade de proj eto é 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 deSiste

mas/20101 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. IABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de

Sistemas/20101 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. IANAC/Analista Administrativo/Tecnologia da lnformação/20091 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. IANTAO/Analista Administrativo/lnformática/20091 O extreme program

ming IX PI 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 autor ia 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/20081 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


52

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 I Assim como o software,

os requisitos também devem ser avaliados quanto à qualidade. A validação,

atividade da engenharia de requ isitos, é 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/20101 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/20101 Requisitos não funcionais 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/20101 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 I 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. IMPU/Analista de lnformática/Desenvo.lvimento/20101 Embora a criação de uma

sequência ilustrada de telas por meio de programas de desenho gráfico sej a

útil para a identificação de alguns requ'isitos do software, ela não é considerada

uma atividade de prototipação, por não envolver o uso de uma linguagem de

programação.

284. IMPU/Analista de lnformática/Desemvolvimento/20101 O levantamento de

requisitos é realizado ao final da primeira versão de um protôtipo, para se

285.


definir, j unto aos envolvidos no processo, quais são as premissas básicas para

o início do entendimento das funcionalidades desejadas.

IMPU/Analista de lnformática/Desenvolvimento/20101 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 requ isitos visa assegurar

que as necessidades do cliente estão sendo atendidas por tais requ isitos.

286. IMPU/Analista de lnformática/Desenvolvimento/20101 A especificação de requ isitos permite, em determinado momento, revelar o que o sistema irá

realizar no que se retere às funcionalidades, sem definir, nesse momento,

como as funcionalidades serão implementadas.

287. IMPU/Analista de lnformática/Oesenvolvimento/20101 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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.


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. ITCU/ Auditor Federal de Controle Externo/Tecnologia da lnformação/20 1 01 Por

se tratar de função essencial da engenharia de requisitos, a gestão formal de

requisitos é indispensável mesmo para projetas de pequeno porte, com apenas

duas ou três dezenas de requisitos identificáveis.

291. IABIN/Oficial Técnico de lnteligêmcia/Desenvolvimento e Manutenção de Sistemas/2010) Requ isitos 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. IANAC/Analista Administrativo/Tecnologia da lnformação/20091 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. IANATEL/Analista Administrativo/Análise de Negócios/20091 A elicitação de

requ isitos 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


54

294. IANATEL/Analista Administrativo/Análise de Negócios/20091 Acerca das similaridades 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/lnformá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 Admin istrativo/lnformática/2009) A especificação de requisitos é uma atividade fundamental do processo de software, mas carece de normas e técnicas que auxiliem as equipes nessa tarefa.

297. (ANTAQ/Analista Administrativo/lnformática/20091 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 lnformática/20091 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. ITCE-RN/AssessorTécnico de lnformática/20091 A proteção, pelo sistema, das

informações pessoais dos usuários cadastrados é exemplo de requisito funcional. A capacidade do sistema de gerar relatório de empréstimos de usuário

em, no máximo, três segundos é um r.equisito não funcional.

300. (TCU/ Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 VORD (viewpoint-oriented requeriments definitionl é 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 lnformação/20091 Os requisitos podem ser class ificados como de domínio, funcionais, não

funcionais, permanentes ou consequentes. Os requ isitos 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 requ isitos voláteis e podem se modificar ao longo

do desenvolvimento do sistema.

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


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 fun cionais 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 arquit etura cliente-servidor em duas camadas, a arquitetura cliente-servidor em t rês camadas e a arquitetura Model-View-Controller (MVC) em três ou em N camadas.

304. ISTM/Analista Judiciário/Análise- de Sistemas/20101 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/201 1) No padrão

de desenvolvimento modelo-visualizacão-controlador IMVCJ, 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/lnformá~ica/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/lnformált ica/20081 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 conj unto 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/lnformática/20081 Na arquitetura cliente-servidor com

três camadas lthree tierl, 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ár io 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 apl icação, sendo executada em servidores de

aplicação. Essa camada pode interagir com um ou mais bancos de dados ou

55


56

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 aten de às necessidades e expectativas dos usuários. Pelo contrário, a qualidade também inclui a iden tificação das medidas e dos critérios para demonstrar a obtenção

da qualidade e a implementação de um p rocesso 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 I A engenharia da usabil idade é aplicada em qualquer t ipo 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/20111 A prototipação possibilita que o usuário teste as características do produto final.

Dos dois tipos de prototipação, a hor izontal é focada nas funcionalidades que

permitem ao usuário ver somente deta1hes de determinadas partes do sistema.

311. (Correios/Analista de Cor reios/Desenvolvimento de Sistemas/2011 I 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. IMPU/Analista de lnformática/Desenvolvimento/20101 O nível máximo de qualidade 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. IMPU/Analista de lnformática/Desenvolvimento/20101 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. IMPU/Analist a de lnformática/Desenvolvimento/20101 O teste de integração

geralmente é um processo de teste de caixa preta no qual os t estes são deri

vados da especificação do sistema, cuj o comportamento pode ser determinado

por meio do estudo de suas entradas e saídas.


315. ITRE9-BA/ Analista Judiciário/ Análise de Sistemas/20091 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. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 A técnica estrutural de teste de software (ou teste caiixa brancal, 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. IABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção deSistemas/20101 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. IABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sistemas/201 01 Considerando-se o programa final como ca ixa 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. IABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis

temas/201 01 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. IANATEL/Analista Administrativo/Análise de Negócios/20091 Entre os principais 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.

# 3 operação do produto

57


58

A partir da figura acima, que representa os fatores de qualidade de software,

julgue os dois itens que se seguem.

321. ITCU/ Auditor Federal de Controle Externo/Tecnologia da lnformaçã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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/2009) A funcionalidade é um requisito funciornal, 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. ITRE-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. ITRE-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 confi gu

ração de software, a manutenção pode ser feita de maneira proativa, reativa, preventiva ou corretiva.

326. (STJ/Analista Judiciário/lnformá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/lnformá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/lnformática/2008) lnspeçõ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 (checktist) é usada. O conteúdo da lista

tipicamente independe da linguagem de programação usada.


329. (STJ/Analista Judiciário/lnformática/20081 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/20111 Por meio do encapsulamento, para impedir o acesso direto ao atributo de um objeto, são

disponibilizados externamente a1penas 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/20111 Uma classe é capaz de instanciar um objeto de uma classe abstrata, para utilizar

seus métodos e manipular seus atributos.

332. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 A abstração permite, entre outras funcionalidades, identificar e compor obj etos complexos e

construir estruturas, na forma de classes de objetos, para organizar objetos

de diferentes tipos. Porém, conceit os implementados por classes que são

construídas com base na abstração não podem ser generalizados nem espe

cializados.

333. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 Em programação or ientada 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. ITRE9- BA/Analista Judiciár io/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. ITRE9-BA/Analista Judiciário/Análise deSistemas/20091 O estado de um objeto é definido pelo conjunto de valores de suas propriedades.

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

59


60


Uma classe pode ser vista como uma descrição generalizada de uma coleção

de objetos semelhantes.

338. IABIN/Oficial Técnico de Inteli gência/Desenvolvimento e Manutenção deSiste

mas/201 01 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. IABIN/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de

Sistemas/201 01 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 conj unto de mensagens, e a porção funcional, por um conjunto de atributos.


temas/201 01 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 deSiste

mas/20101 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/201 01 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.


temas/201 01 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 supercl:asses para uma mesma subclasse. As

superclasses irão se comportar como dasses concretas somente para o objeto

instanciado na subclasse de herança múltipla, permanecendo abstratas para

instâncias regulares.

344. (ANAC/ Anal ista Administrativo/Tecnologia da lnformação/20091 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/20081 Na área de projeto de

software, também conhecida como design de software, o software começa a

ser implementado e validado pelos programadores.


346. !STJ/Analista Judiciário/lnformática/20081 Se uma classe abstraia 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. ITST/Analista Judiciário/Análise de Sistemas/20081 Uma das consequências do

polimorfismo é que obj etos 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. ITST/Analista Judiciário/Análise de Sistemas/20081 A sobreposição loverridingl é 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 con ceitos do paradigma de orientação a objetos e, através deles, é possível construir diagramas que representam diversas perspectivas 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 I O diagrama de componentes deve ser utilizadlo 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 I 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 Cor reios/Desenvolvimento de Sistemas/2011 I Um relacionamento include de um caso de uso A para um caso de uso B indica que B

é essencial para o comportamen~o de A. Então, ao executar o caso de uso A,

executa-se também o B.

352. (Correios/ Anal ista de Correios/Desenvolvimento de Sistemas/2011 I O diagrama

de classes define todas as classe.s de que o sistema necessita e é a base para

a construção dos diagramas de sequência e comunicação.

61


62

sd Realizar Submissão)

o ~. controlador l__j congressoí-:----r---i---,

' loop .J

submlissor página_cqngresso

i seleclonar opção i i de submissão i submissão

solicitada

! !

seleclonar lema

informar dados de submissão, anexar arquivo e confirmar

; [para cada ten]a) SeiTema() 1

apresentar tela d . -de submissão • · ... !~~f.!X~~ ...... ..

tema

i submissão ' confirmada

, . , ~; consTerna () ! . . .. ~~~~-~~~~?.. ...... .Q . ' ! r=istrar submissá~ R""Sub'J S..bl : submissão

submissão , O -~ i -~ ' \ conclufda i verda!:Jeiro i

n c .. ~t-m_s_u_c_es_s_o~o--·-............................. "'!""'""""""'""""""""'? : !

Tendo o diagrama UML da figura acima como referência, julgue os itens se

guintes (TRE-ES/Analista Judiciário/Análise de Sistemas/20111.

353. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 A figura f() indica a presença do pacote "controlador congresso" , que representa um mecanismo

de propósito geral para organizar elementos de modelo em grupos.

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

356. ITRE-ES/Analista Jud iciário/Análise de Sistemas/20111 Na f igura

n Com Tema () > ~ U· - u· o trecho representa uma associação ConsTerna() verdadeiro

recursiva que especifica que objetos de uma classe podem participar de, no

máximo, uma das associações em det•erminado momento. 357. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 Na figura, o tempo é

most rado no eixo vertical e os obj etos envolvidos na sequência de uma ativi

dade, no eixo horizontal.


358. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 A seta pontilhada

''verdadeiro'' indica a existência dle um laço do processo executado pelo obj eto

" Sub1 ".

359. IMEC/Atividade Técnica de Complexidade Gerenciai/Arquiteto de Siste

mas/2011 I No diagrama de caso de uso não há herança entre use case, apesar de haver entre os atores.

360. IMEC/Atividade Técnica de Complexidade Gerenciai/Arquiteto de Siste

mas/20111 É 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 in icia o caso de uso

duas vezes ao mês.

2 {por dia} {por mês e cliente}

)\ _4_oo __ .oo_o ________________ ~2--~~ ~

cliente condunr transações

361. IMEC/Atividade Técnica de Complexidade Gerenciai/Arquiteto deSistemas/2011 I 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. IMEC/Atividade Técnica de Complexidade Gerenciai/Arquiteto deSiste

mas/2011 I Uma agregação composta presente entre duas classes indica uma associação do t ipo todo parte, em que uma classe é a parte e a outra, o todo.

363. IMEC/Atividade Técnica de Complexidade Gerenciai /Arquiteto de Siste

mas/2011 I O diagrama de sequência descreve as mudanças de estado ou condição de uma instância de uma classe na troca de mensagens entre os objetos.

364. IMPU/Analista de lnformática/De-senvolvimento/20101 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. IMPU/Analista de lnformática/Desenvolvimento/20101 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 I não pontilhada).

366. ITRE9-BA/ Analista Judiciário/ AnáUise de Sistemas/20091 O propósito maior de um caso de uso é fornecer uma descrit;ão do comportamento do sistema. Assim, em

um processo de desenvolvimento orientado a objetos, os obj etivos 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


64

367. ITRE9-BA/Analista Judiciário/Análise de Sistemas/20091 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 ato r seleciona os produtos;

9. O sistema calcula os preços.

368. ITCE-RN/Assessor Técnico de lnformática/20091 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.

Professor Supervisor

Docentes <<INCLUDE>~ .. ···' ·· ·· .. <<EXTEND>>

····•·• •..

Considerando o diagrama UML acima, j ulgue o seguinte item.

Capítulo 3 I Questões de Engenhar ia de Software


De acordo com o diagrama, estã.o corretas as seguintes afirmações: o ator

Supervisor é uma especialização do ato r Professor; o caso de uso Incluir Fal

tas é abstrato e pode ser acionad o pelo ato r Supervisor; o caso de uso Incluir

Conteúdo Programático é abstrato e representa um segmento opcional de

comportamento.

EecOia Departamento 1 •. • Atribufdo a

+CNPJ 1 1 .. 3 ·Sigla + RazãoSoclal ·Descrição Responsável +Endereço tem

#Atuallzar () 0 .. 1 0 •. 1 1 #2 1 .. * ·Cadastrar ( )

) 1 •. • 1 .. * ln811Ut0r # Nomelnstrutor #DataNasclmento

matriculado #cadastrar ()

., 1 .. • I \ Aluno C U1'80

-NomeAiuno LIVro 0 .. 5 #CodlgoCurso Funcionário Convidado ·NuCPF -TituloUvro #CargaHorárla -Nu Telefone -AnoPublicação #1

·NumMatricula ·Nutelefone -Excluir( )

#Matricular () +Consultar () -Imprimir () #Cadastrar ( ) #Cadastrar ( )

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

seguintes.

370. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 O método #Cadastrar() da classe Instrutor tem visibilidade do modo protegido

tal que somente a classe possuidora Inst rutor pode utilizá-lo.

371. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 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


66

~ :.J!IO<iR ! I , .. 'M: ~.c! I

~,,·. 1:SOI.,k*abettura<iecot'lta ) : : ! 2: eonwlla ~ente ( 1 ' : ..

''.;, ' D •• r;·cse·~iiii~·:dãdõ6dO'êii&Mt ........ 1

1 4 (so noc~); atuallw: ui*!~() l

1 ~,:'. ·;,;·~~;;,;;;;;;;;;,;·-----··---·· ----···~,,. J s:Val'tlfat~: valcpro

iE?: ....,ldo"""'ado

'~:':. 8:VIliOtcfedep6eitoeaerlla J. ·.'. 1

- .. .., Çp* •. c: ... Comlf'D I j 9: Ab,.. carta: Abortt.wa () 1 · - · n I ffim' H!w)dco I

i i . j : 1 1 O: F\egl6trlf hô&tôrioo; Gravar Q 1

! ~~---!~-~~-~-~-~-~~~ .... + ........................ ~~:·;:;-;o.-.~·;;,;-~· ··9. j 13: Aberttnde cottta eordJkta 1

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


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; 116 é uma mensagem de retorno

sem disparo de método; e 115 é uma mensagem simples entre atares que indica

somente a ocorrência de um evento.

Caixa Eletr6nlco <<TCP/IP>> Servidor de Comunicação

? Gerenclador do Caixa ~ controlador do Caixa Eletrônlco

~ Eletrônlco

#2 I

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

373. ITCU/ Auditor Federal de Controle Externo/Tecnologia da lnformação/20091 Nesse diagrama, 111 é uma interface do tipo fornecida que descreve um serviço

implementado; e 112 é uma interface do tipo requerida. Tas interfaces podem

ser substituídas, sem prejuízo, pelos relacionamentos de dependência e rea

lização, respectivamente.

Capítu lo 3 I Questões de Enge n har ia de Softwa re


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 or;ientados a objetos.

375. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformaçã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 trepresenta 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. ITRE-PR/Analista Judiciário/Análise de Sistemas/20091 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.

Internet

connectíon

"processar• primary server

node

"processar" cachlng server

"processar• server

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

"processar" caching server

"processar" server

"processar• serve r

67


68

I CntrAutenticacao I I +autenticar(usuário: Usuário): booloon r ....... .

I Persistenc la

<<interface>> tRAutentlcacao

+autenticar(usuário: Usuário): booloon

i I TelaAutenlicacao I

1 1 .!, Usuário

·nome: String

+lncluir(usuário: Usuário): vold

o_·

I Pessoal I Grupo J. l+tncluir(usuário: Usuário): vold 11

CntrPersistencia + execvtarr(comando: Comando}: booloon #conectar ( ): vold

1 CntrPe1sistenciaRetacionaJI

l-desconectar (): vold 1

o 1

- .................... , Driver I

I Conexaol

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

377. (STJ/Analista Judiciário/lnformática/20081 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/lnformática/20081 No diagrama, uma instância da classe Grupo pode ter ligações para ma.is 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.


~ : CntrReservf : Passageiro .

.

<<creste>:} 1: criar

telaA : TelaReserv

•1 .. _2_a-'p_r_es_en_ta_r -i

3 · reserva~ 3.1: reservar .

. .

. . . . . . . . . . . . . . . . . . . 4: oonfirmat . . <<destroy>> . . 4.1.1: eliminar

~ . . . . . .

<<eteate>> 3.1.1: criar

: Reservai

3.1 .2: resultado: =setPararnetros Y 3 .1 .2.2 : validar

r 3.1.3: [resuHado =valido] reservar

r «des~o~» ! 3.1.4: ehm1nar •

<<create>> y

3.1.5: criar .

telaS : TelaResultad4

y . . 4.1: notificar

.

Tendo o diagrama UM L acima como referência, j ulgue o seguinte item.

379. (STJ/Analista Judiciário/ lnfor mática/2008) No diagrama da figura, tel aA é 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 Cnt rReserva é assíncrona; a mensagem da instância de Tela Resultado para a

de CntrReserva é síncrona.

69


70

Cliente Servidor

§ CllenteApllcacao I §ServldorApllcacao .............. ~ ' ;

~L I--Rede ~

~

............................... .........•..... ~ Banco de dadoa l

IR Servidor

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

380. (STJ/Analista Judiciário/lnformática/20081 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/lnformática/20081 Em um modelo construído com a UML, estão corretas as seguintes características de diagramas de atividades:

separações (forks) e j unções (joinsl 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/lnformá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. ITST/Analista Judiciário/Análise de Sistemas/20081 Na abordagem de análise UML (unified modelling language), a Viisão de modelo comportamental repre

senta a dinâmica do sistema nas interações entre seus diversos elementos estruturais.

384. ITST/Analista Judiciário/Análise de Sistemas/20081 Na UML, os casos de uso

descrevem cenários de utilização do software, explicitando os atores e as fun

cionalidades disponibilizadas.

385. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 Na abordagem de

análise UML lunified modelling languagel, a visão de modelo comportamental representa o sistema do ponto de vista dos comportamentos e interações do

sistema com o usuário.


386. IMPE-AM/Analista Judiciário/ Analista de Sistemas/2008) Em um diagrama de

casos de uso da UML, um ato r é definido como um usuário humano do sistema.

387. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 Na UML, uma agre

gação é um relacionamento que estabelece que uma classe define objetos que

são parte de um obj eto definido por outra classe.

388. IMPE-AM/Analista Judiciário/Analista de Sistemas/20081 Em um diagrama de

classes UML, uma associação entre classes pode ser documentada em termos

da multiplicidade da associação.

389. IMPE-AM/Analista Judiciár io/Analista de Sistemas/20081 Um diagrama de sequência da UML apresenta tanto as interações entre atores e objetos quanto

interações de objeto para objeto.

71


Capítulo 4

~estõ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 Projetas

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.


74

4.1 .1 . Conceitos básicos de gerenciamento de projetas

390. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 As quatro

possibilidades de término de projeto são absorção, integração, esgotamento

e extinção.

392. [lnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios

e Tecnologia da lnformação/20091 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. [I PEA/ Analista de Sistemas/Processos de Negócios/20081 A gerência por proje

tas trata muitos aspectos dos serviços continuados como projetos, objetivando

aplicar também a eles os conceitos de gerência de projetos.

394. ITCE-RN/Inspetor de Controle Externo/Tecnologia da lnformação/20091 Em gerenciamento de projetos, as operações são caracterizadas por objetivos que

podem ser medidos qualitativa e financeiramente.

395. IAntaq/Analista Administrativo/lnformática/20091 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Programas

são grupos de projetos relacionados e um projeto, sej a ele qual for, será parte

de um programa.

398. ISerpro/Analista/Negócios em Tecnologia da lnformação/20081 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. IAbin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção deSiste

mas/20101 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

Capítulo 4 I Questões de Ges tã o de Te-cnologia da Info rmação

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 lnformação/20081 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.

Executivo Chefe

401. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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 projetas e outras partes interessadas

402. (Sebrae-DF/Analista Técnico/20081 O PMO (project management organizationl é 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 lnformação/20101 Um gerente de proj eto e um escritório de projeto IPMOI 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/20111 O escritório de projetos é responsável pelo gerenciamento das restrições relativas ao escopo,

ao cronograma, ao custo e à qualridade dos proj etos individuais; ao passo que

o gerente de projetos é responsável pelo gerenciamento de metodologias, padrões e interdependências entre os projetos.

405. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Um escritório de proj etos 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.

75


76

406. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 O escritório

de projetas de uma organização tem, entre outras, as seguintes atribuições:

padronização de processos de suport e a projetas, treinamento de pessoal,

gerenciamento de recursos e elaboração do plano estratégico da organização.

407. ITCE-RN/Inspetor de Controle Extermo/Tecnologia da lnformação/20091 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 proj eto.

4.1.4. Ciclo de vida e grupos de processos

408. (TCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/201 01 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/20111 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. IMPU/Analista de lnformática/Perito/20101 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/20111 O ciclo de vida de um produto inicia-se quando os ciclos de vida dos projetas a ele

relacionados são encerrados.

412. ISTF/Analista Judiciário/Análise de Sistemas de lnformação/20081 A melhor

associação para os elementos de #1 a #5 na figura abaixo é iniciação, plane

jamento, execução, controle e encerramento.

#4

#3 #5

#6 #7

Capítulo 4 I Questões de Ges tã o de Te-cnologia da Informação

413. (Abin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sis

temas/201 O) Os grupos de processos são fases do ciclo de vida do projeto que

permite a separação em fases ou subprojetos distintos de proj etos grandes

ou complexos.

414. IAbin/Ofi cial Técnico de Inteligência/Desenvolvimento e Manutenção de Sistemas/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. IMPU/ Analista de lnformática/De:senvolvimento de Sistemas/20101 Os grupos de processos de planejamento e de monitoramento e controle servem como

entrada de um para o outro recipr ocamente.

4.1.5. Gerência de integração

416. (Previc/ Analista Administrativo/Tecnologia da lnformação/20111 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. ITJ-ES/ Analista Judiciário 02/Análise de Sistemas/2011 I Entre os documentos

relativos aos termos de abertura de proj etos, a declaração de trabalho é o

documento que contém a descrição narrativa dos produtos e serviços a serem

fornecidos pelo proj eto e no qual são informadas, entre outros aspectos, as

necessidades de negócio embasadas em demanda de mercado, avanço tecno

lógico, requ isito legal ou regulamentação de governo.

418. (Sebrae-DF/Analista Técnico/20081 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. IAntaq/Analista Administrativo/lnformática/20091 O sistema de gerência de configuração de um proj eto é um subsistema dentro do processo de gerencia

mento de escopo.

420. ITJ-ES/Analista Judiciário 02/Análise de Sistemas/20111 Nas saídas do processo 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


78

421. (Antaq/ Analista Admin istrativo/lnformática/20091 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 I 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 gerenciameMo de recursos humanos.

423. !Sebrae-DF/Analista Técnico/20081 Na definição do escopo do projeto, o cliente é o mais atuante, portanto não é necessár ia uma opinião especializada, pois

esta será necessária apenas na execu:ção do projeto.

424. ITRE-BA!Analista Judiciário/Análise de Sistemas/20101 A estrutura analítica

do projeto IEAPI subdivide as principais entregas do projeto e do trabalho

necessário para desenvolvê-lo em componentes menores e mais facilmente

gerênciávêis. Para isso, dêVê incluir o trabalho dêfinido pêlo êSCopo do projêto, considerando as ações, internas e ext·ernas, 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I As entradas do processo 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/lnformática/20081 Em um processo de gerenciamento de tempo, tipicamente existem atividades que visam: identificar at ividades 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/lnformática/20091 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.


428. ISebrae-DF/Analista Têcnico/20081 O gerenciamento do tempo do projeto não

deve se basear apenas no cronograma, pois, de acordo com a velocidade dos

projetas, muitas vezes, eles não são atualizados. Portanto, deve-se ter como

referência a EAP para tanto.

429. ITST I Analista Judiciári o Análise de Sistemas/20081 A ocorrência de flutuação de prazo em uma atividade do caminho crítico de um proj eto pode ser com

pensada pelo adiantamento de outras ativi dades fora do caminho crítico.

430. ISTM/Analista Judiciário/Análise de Sistemas/20111 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. IIPEA/ Analista de Sistemas/Processos de Negócios/20081 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. ITRE-BA/Analista Judiciário/Análise de Sistemas/20101 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 ativi dades. 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/lnformática/20081 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

projetas 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. ITJDFT I Analista Judiciário/ Análise de Sistemas/20081 No processo de uso da têcnica 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 proj eto está com prazo atrasado.

435. ITCU/Analista de Controle Externo/Tecnologia da lnformação/200915e, em um projeto, o valor agregado a um componente da estrutura analítica de projetas

ou atividade do cronograma for inferior ao custo real correspondente ao ele-

79


80

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. ISebrae-DF/Analista Técnico/20081 Um r isco ao projeto é uma condição de

incerteza que pode causar apenas efeitos negativos e por isso os r iscos devem

ser sempre eliminados.

437. (lnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó

cios e Tecnologia da lnformação/20091 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 r iscos.

438. !Correios/ Analista de Correios/Desenvolvimento de Sistemas/2011 I Identificar 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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. IMPU/Analista de lnformática/Desernvolvimento de Sistemas/20101 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. (lnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios

e Tecnologia da lnformação/20091 A an,álise de sensibilidade é uma técnica que

examina a extensão com que a incerteza de cada elemento do projeto afeta o

obj etivo 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. IBasa/Técnico Científico/Governança de Tl/20101 Ent re 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.


443. ISebrae-DF/Analista Técnico/20081 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/20111 Suponha que, du

rante a execução de um projeto, o-corra 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 proj eto. Nessa situação, a técnica mais adequada para gerenciar

o conflito é a negociação.

445. ITCU/ Analista de Controle Externo{Tecnologia da lnformação/20071 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. IAbin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção deSistemas/20101 Os processos de gerenciamento de aquisição do proj eto 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, subcontratas ou pedidos de compra.

447. llnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negó

cios e Tecnologia da lnformação/20091 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/20111 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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 ant igo modelo CMM tenha s ido 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 n as provas. Nem mesmo

81


82

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. IMPU/Analista de lnformática/Perito/20101 Os múltiplos modelos CMM evoluíram para um modelo integrado, o CM MI, 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/Desemvolvimento de Sistemas/20111 O CMMI

abrange práticas que cobrem o ciclo de vida do produto desde a sua concepção

até sua entrega, além das ativi dades de manutenção aplicadas a produtos e

serviços.

452. (STM/Analista Judiciário/Análise de Sistemas/20111 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 conj unto 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. IANEEL/Analista Admin istrativo/Área 3/20101 As notas, exemplos, relatórios, amplificações e referências são componentes informativos de suporte do mo

delo CM MI.

454. IMPU/Analista de lnformática/Perito/201 O) Um exemplo de componente infor

mativo é o glossário de termos do CM MI.

4.2.2. CMMI - Níveis de capacidade e maturidade

455. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 O CM MI 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. ITCU/ Analista de Controle Externo/Tecnologia da lnformação/20091 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.


457. IBasa/Técnico Científico/Governança de Tl/2010) No que se refere à melhoria

de processos em uma organização, se a estratégia exige r igidez, então deve-se

adotar a representação contínua do modelo CM MI, em alternativa à represen

tação em estágios.

458. ISTF/Analista Judiciário/Análise de Sistemas de lnformação/20081 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. IANEEL/Analista Administrativo/Área 3/2010) O processo é planejado e executado no nível 2 do modelo CM MI, 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 monitor ado, controlado, revisado e avaliado quanto à conformidade

com sua descrição e ao desempenho previsto nos seus planos.

460. IPrevic/Analista Administrativo/Tecnologia da lnformação/20111 No nível3 de maturidade do modelo CM MI, 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/20111 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 CM MI.

462. (Correios/Analista de Correios/Desenvolvimento de Sistemas/2011) No nível

de maturidade 4 do CM MI, o desempenho dos processos é previsível quanti

tavamente, ao passo que, no nível3, a previ sibilidade é apenas qualitativa.

463. IPrevic/Analista Administrativo/Tecnolog ia da lnformação/20111 Uma das

características do nível4 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. IBasa/Técnico Científico/Governança de Tl/2010) No modelo CM MI, a avaliação formal de processos baseia-se no método SCAMPI, que apresenta cinco dife

rentes níveis de avaliacão, sendo o nível1 o inicial, e o nível 5, o otimizante.

4.2.3. CMMI- Áreas de Processo

465. ISebrae-DF/Analista Técnico/20081 As dezenas de áreas de processo do CM MI 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


84

466. (STJ/Analista Judiciário/lnformática/20081 No nível de maturidade definido (de

finedl, é definida a área de processo gerenciamento de requisitos (requirements

managementl, que visa gerenciar requisitos e identificar as inconsistências

entre requisitos, planos e produtos do projeto. Por sua vez, no nível gerenciado

(managedl, é 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/20081 A área de processo denominada análise causal e resolução (causal analysis e resolutionl

encontra-se definida no nível de maturidade otimizado (optimizingl 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/lnfornnática/20091 Existem quatro categorias de áreas de processo no modelo CM MI para desenvolvimento: gerenciamento

de processo, gerenciamento de produto, engenharia e apoio.

469. IMPU/Analista de Informática/Desenvolvimento de Sistemas/201 01 Validação, verificação e integração do produto s:ão processos que integram a disciplina

de suporte ao processo de software.

470. (Anac/Ana lista Administrativo/Tecnologia da lnformação/20091 No CMMI, a

área de processo de desempenho do processo organizacional (OPPI deriva os obj etivos 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 dle desempenho de processos e modelos

de desempenho de processos.

471. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 São pro

dutos de t rabalho 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 r iscos, de origem interna e externa.

472. (TCU/Analista de Controle Externo/Tecnologia da lnformação/20091 Testes

de cobertura de caminhos, normas e políticas organizacionais, relatórios de

avaliação de produtos de software de prateleira ICOTSI 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ífi co/Governança de Tl/20101 No âmbito das organizações

que adotam o modelo CM MI, 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 Tl/201 01 Nas organizações que a dotam

o modelo CM MI, o gerenciamento das in terfaces internas e externas entre os

Capítulo 4 I Questões de Gestã o de Te-cnologia da Informação

componentes de uma solução em desenvolvimento constitui atividade carac

terística da área de processo de verificação.

475. IBasa/Técnico Científico/Governança de Tl/20101 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. IBasa/Técnico Científico/Governança de Tl/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. IAbin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção de Sistemas/201 O) 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. IBasa/Técnico Científico/Governança de Tl/20101 A estrutura analítica de pro

jeto I EAPI desenvolvida de forma orientada a produto, caso esteja presente em uma organização que a dote o modelo CM MI, é 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 lnformação/20081 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 proj eto.

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

480. (Sebrae-DF/Analista Técnico/20081 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. IMPU/ Analista de Informática/Desenvolvimento de Sistemas/201 01 Uma das principais bases técnicas para a criação do modelo de referência do MPS.BR

foi uma norma 150/IEC, a qual estabeleceu uma arquitetura para o ciclo de vida

dos processos de software.

85


86

482. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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. IAntaq/Analista Administrativo/lnformática/20091 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 correlatas.

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 CM MI, 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. ISebrae-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. IMin. Comunicações/Informática/Análise de Sistemas/20081 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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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. IMin. Comunicações/Informática/Análise de Sistemas/20081 São processos no nível de maturidade E: veri ficaçã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 projetas.

488. IMin. Comunicações/Informática/Análise de Sistemas/20081 Um componente do

MPS.BR é o modelo de referência, que contém os requisitos que os processos

das unidades organizacionais devem at ender 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 p rocessos em sete níveis de maturidade,

cuj a escala se inicia no nível de menor maturidade A e progride até o de maior

maturidade G.


489. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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-OF/Analista Técnico/20081 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/20081 O processo de

nominado desenvolvimento para reutilização I DR UI 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 IITPI projeta, desenvolve e implementa soluções para atender aos requisitos.

492. IMin. Comunicações/Informática/Análise de Sistemas/20081 O processo denominado verificação IVERI prevê que um produto ou componente atenderá a seu

uso prêtêndido quando colocado no ambiêntê para o qual foi desênvolvido. Por sua vez, o processo análise de causas de problemas e resolução IACPI 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 lnteligênc:ia/Oesenvolvimento e Manutenção deSiste

mas/20101 No nível G, o planejamento e as estimativas das atividades do projeto

são feitos com base no repositóriio de estimativas e no conjunto de ativos de

processo organizacional.


temas/20101 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 proj etos.

4.3. Gerenciamento de Serviços

Com o advento do !TIL v3, publicado em 2007 e atualizado em 2011, as questões sobre gerenciamento de serviços vêm se tornando cada vez mais dificeis,

cobrando detalhes de conceitos e processos descritos nos livros da n ova 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 n egócios,

costumam dar origem a questões mais dificeis para a maioria dos candidatos em concursos da área de TI.

87


88

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

495. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Serviço é a denominação dada ao meio de se entregar valor aos clientes para facilitar a

obtenção dos resultados desej ados e minimizar os custos e riscos específicos.

496. !Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 Na atualizaçã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 outsourcingl.

497. (Abin/Oficial Técn ico de Inteligência/Suporte a Rede de Dados/20101 Aversão

3 do ITIL é composta pelos l ivros: 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 Continua! Service lmprovement

(Melhoria do Serviço Continuada), além de anexos de segurança da informação

e contingência.

498. ITRE-BA/Analista Judiciário/Análise dle Sistemas/20101 O ITIL trabalha de forma 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da Jnformação/20101

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.

SOO. IMPU/Analista de lnformática/Perito/20101 Embora tenha uma grande ênfase na fase de estratégia de serviço, o ger enciamento 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. IMPU/Analista de lnformática/Desenv·olvimento de Sistemas/201 01 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/20101 A gestão

financeira realiza a análise, o rastreamento, o monitoramento e a documenta

ção de padrões de ativi dade do negócio IPAN ou BAPJ para prever as demandas atuais e futuras por serviços.

503. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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.


S04. IBasa/Técnico Científico/Governança de Tl/20101 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.

SOS. IBasa/Técnico Científico/Governança de Tl/20101 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.

S06. ITCU/ Analista de Controle Externo/Tecnologia da lnformação/20091 Acerca de modelos de provisionamento de serviço de TI defin idos 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.

S07. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 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 seguirntes estágios ou níveis de maturi dade: rede,

diretivo, delegação, coordenação e colaboração.

4.3.3 . ITIL- Desenho de serviços

SOS. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Estratégia de servi ço é a publicação do núcleo da I TIL 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.

S09. IMPU/Analista de Informática/Desenvolvimento de Sistemas/201 01 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ár ios sej am recuperados dentro de um tempo preestabelecido.

SlO. IBasa/Técnico Científico/Governança de Tl/20101 O gerenciamento do catá

logo de serviços produz informações sobre serviços acordados e assegura

que estej am 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


90

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.


e Tecnologia da lnformação/20091 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I 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. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 São métri

cas adotadas no modelo ITIL: mean time between failures IMTBFI. mean t ime

between service incidents (MTBSI), mean time to repa ir IMTTRI e mean t ime

to restore service IMTRSI. O MTBSI po,de ser definido como a soma do MTBF e do MTRS; e o MTRS é sempre maior ou igual ao MTTR.

514. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 No desenvolvimento 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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. IANEEL/Analista Administrativo/Área 3/20101 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 re.sponsabilidade do processo de planeja

mento e suporte da transição.

517. (Anatei/Analista Administrativo/Amb'iente Operacional/20091 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 i'nformações acerca dos relacionamentos

entre ativos.

518. (Anatei/Analista Administrativo/Ambiente Operacional/20091 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 registras das mudanças.


519. (Sebrae-DF/Analista Técnico/20081 A decisão para o desenvolvimento ou

compra de um novo software é uma atividade pertinente ao gerenciamento de

mudanças.

520. IAnateVAnalista 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 Cientifico/Governança de Tl/20101 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 lnformação/201 01 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/20101 Um ob

jetivo conflitante na operação de serviço considerando TI e negócio é que a

visão técn ica é necessária para a gestão dos componentes dos serviços, mas

não se pode sobrepor aos requisitos de qualidade dos usuár ios para esses

serviços.

524. ITRE-ES/Analista Judiciário/Anál ise de Sistemas/20111 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 Tl/20101 Uma métrica adequada para

avaliar o desempenho da central de serviços (service deskl é o volume de

chamadas recebidas, uma vez que um incremento nesse indicador significa

maior confiança dos usuários nesse t ipo de serviço e, portanto, bom desem

penho.

526. (TJ-ES/Analista Judiciário 02/ Análise de Banco de Dados/2011 I 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

levei agreement (SLAJ estabelecidos. Para isso, a central de serviços deve

inserir no sistema as requests for change IRFCJ assim que o usuário reportar o problema identificado.

91


92

527. ITJ-ES/Analista Judiciário 02/Análise de Banco de Dados/20111 No gerencia

mento de problemas, busca-se a causa raiz dos incidentes reportados pelos

usuários e registrados na central de serviços (service deskl para que seja

possível determinar a mudança adequada à infraestrutura de TI.

528. (Anatei/Analista Admin istrativo/Ambiente OperacionaU2009) 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. ITCU/Analista de Controle Externo/Tecn ologia da lnformação/20091 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 di e Tl/201 01 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 ativi dades 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. IMPU/ Analista de Informática/Desenvolvimento de Sistemas/201 01 Monitoraçã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 lnformação/2011 I A publicação

do I TIL 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. IMPU/Analista de lnformática/Perito/20101 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.


temas/201 01 O livro Melhoria Contínua de Servicos, incluído na versão 3 do

ITIL, apresenta uma visão de ciclo de vida embasado no modelo PDCA (plan,

do, check, act).

Capítu lo 4 I Questões de Gestão de Te-cnologia da Informação

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

men or 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 n ovos 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. IBasa/Técnico Científico/Governança de Tl/20101 Governança em TI é responsabilidade 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á1lise de Sistemas/20101 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. IMPU/ Analista de Informática/Desenvolvimento de Sistemas/201 01 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I No Cobit, a mensuracão de desempenho é essencial para a governança de TI.

539. (ANAC/Analista Administrativo/lTecnologia da lnformação/20091 Objetivos de

controle do Cobit são os requisit os 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 cont role detalhados, além dos

quais existem no Cobit, para cada processo, requisitos genéricos (ou gerais)

de cont role.

540. (Basa/Técnico Científico/Governança de Tl/201 01 Diretriz é o conjunto de políticas, procedimentos, prát icas 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

r igidos.

541. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I A disponibilidade refere-se à entrega da informação por meio do melhor ou mais produtivo e

econômico uso dos recursos.

93


94

542. IMPU/Analista de Informática- Perito/20101 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/20111 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 lnformação/20111 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 Commissionl para

controle de ambientes de TI.

545. !Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 Cobit é o

único framework gerencial que trata t·odo 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ífi co/Governança de Tl/20101 A orientação a negócios do

C o bit compreende o alinhamento entre objetivos organizacionais e os obj etivos

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. ITRE-PR/Analista Judiciário/Análise de Sistemas/20091 Entre outras contribuiçõ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. ITJ-ES/Analista Judiciário 02/Análise· de Banco de Dados/20111 O Cobit propicia um modelo de gestão embasado em objetivos de controle, enquanto os

indicadores-chaves de meta I ou KG I) 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 Tl/20101 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


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. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 Alguns requisitos de controle genér icos 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. IAbin/Oficial Técnico de Inteligência/Desenvolvimento e Manutenção deSiste

mas/201 01 O Cobit, ferramenta de gestão orientada a negócios, apresenta indicadores 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. IBasa/Técnico Científico/Governança de Tl/20101 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 obj etivos, e as terceiras estabelecem

o que é necessário acontecer dentro do processo para atingir o desempenho

desejado.

553. ISebrae-DF/Analista Técnico/20081 O KGis lkey goal indicatorsl indicam se os objetivos foram alcançados. Pela sua natureza a posteriori, também são

chamados de lag indicators.

554. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 O pla

nej amento 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. ISTF/Analista Judiciário/Análise de Sistemas de lnformação/20081 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


96

~------------~d~M~I~ne~m~e~m~•~------------~ meta da atividade

compreendendo

vul~sjlg:des e ameaças à segurança

frequência de reVISões dos

tipos de eventos de segurança

a serem monitorados

meta do processo

detecte e resolva acessos não autorizados a informações, a~licativos e in aestrutura

número de violações

de acessos

melada TI

garanta os se~sdeTI

poder o resistir e se recuperar

de ataques

número de Incidentes de TI que produziam

Impacto de negócios

melado negócio

mantenha a •=ção

e li erança da empresa

número de lncídentes causando embaraço

público

KPI métrica de negócios KGI

KPI métrica de TI KGI

KPI métrica de processo KGI

direciona o desempenho >

4.4.3. Cobit - Modelo de maturidade

III c o

~ 'ii

556. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Oados/20101 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. IMPU/Analista de lnformática/Perito/20101 Diferentemente da representação

por estágios do modelo CM MI, 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ível3.

558. (Abin/Oficial Técnico de Inteligência/Suporte a Rede de Oados/201 01 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ível3 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. IT J-ES/ Analista Judiciário 02/ Análise de Banco de Oados/20111 Caso um gestor

eleve o nível de maturidade de seus pr·ocessos de 2 para 3, ele estará realizando 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.


560. !STJ/Analista Judiciário/lnformática/20081 Considere que, no que diz respeito

ao processo avaliar e gerenciar r iscos de Tllassess and manage IT risksl, uma organização apresente as seguintes características: existe uma abordagem

para avaliar r iscos; para cada projeto, implementar a avaliação de riscos de

pende de decisão do gerente do proj eto; a gerência de riscos é aplicada apenas

aos principais proj etos 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ávellmanaged and measurablel.

561. (Sebrae-DF/Analista Técnico/20081 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 c:onsiderar 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. ISebrae-DF/Analista Técnico/200,81 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. IBasa/Técnico Científico/Govemança de Tl/20101 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 r iscos 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. IIJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática e

Gestão da lnformação/20101 O Cobit tem por objetivo controlar detalhadamente

os processos organizados em domínios ou áreas com atuação alternada ao

longo do tempo.

565. ITJ-ES/ Analista Judiciário 02/ Análise de Banco de Dados/20111 O domínio denominado planejamento e organização IPOI 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. ITRE-BA/Analista Judiciário/Análise de Sistemas/20101 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


98

567. (ANEEL/Analista Administrativo/Área 3/20101 O domínio aquisição e implemen

tação envolve a identificação, desenvolvimento e(oul 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 continu idade dos respectivos ciclos de vida.

568. IMPU/Analista de lnformática/Perito/20101 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 deSiste

mas/20101 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 supportl, 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. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 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 lnformaçã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. ITRE-PR/Analista Judiciário/Análise de Sistemas/20091 O processo 055 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 lnformação/20101 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.

574.


(IJSN-ES/Especialista em Estudos e Pesquisas Governamentais/Informática

e Gestão da lnformação/201 01 Conforme o diagrama RACI do modelo Cobit, o estabelecimento de ligações entr.e 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.

S75. IMEC/Atividade Técnica de Comp~exidade GerenciaVAnalista de Sistema Ope

racional/2011 I 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. IMEC/Atividade Técnica de Complexidade GerenciaVAnalista de Sistema Operacional/2011 I 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. IDetran-ES/Técnico Superior/Analista de Sistemas/20101 Em um estudo de

planejamênto estratégico, as metas, os objetivos, os negócios e a missão organizacional devem ser definidos, sequencialmente, nessa ordem.

578. llnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios

e Tecnologia da lnformação/20091 A missão corresponde aos l imites 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. IAneeVAnalista Administrativo/Área 3/20101 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 lnformação/20091 A estraté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, cuj o 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. llnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios

e Tecnolog ia da lnformação/20091 Ao distinguir a estratégia deliberada da estratégia emergente, é correto :afirmar que a estratégia deliberada é a que

focaliza o aprendizado.

99


100

582. !Abin/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 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. (lnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios

e Tecnologia da lnformação/20091 Um dos benefícios da adoção da gestão estratégica é que ela facilita a identificação e a exploração de futuras oportunidades

de mercado.

584. !Aneei/Analista Administrativo Área 3/20101 Na gestão estratégica, estabelecer 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/20101 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.


e Tetnologia da lnformaçào/20091 Na matriz SWOT, as ameaças são taratte

rísticas que impedem que a empresa ou unidade de negócio tenha um bom

desempenho e, portanto, precisam ser tratadas/minimizadas.

587. IMPU/Analista de Informática/Desenvolvimento de Sistemas/20101 As ferramentas 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/20101 Entre as

principais metodologias para planejamento de TI incluem-se o BSP !Business

Systems Planning), o SSP (Strategic Systems Planning), a engenharia da in

formacã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 Exter no/Tecnologia da lnformação/20091 No pro

cesso de aumento de maturi dade 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-


dade com os padrões estabelecidos pelo órgão central de TI, supondo-se que

o mesmo era anteriormente presente.

590. (ln metro/ Analista Executivo em Metrologia e Qualidade/Processos de Negó

cios e Tecnologia da lnformaçã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. llnmetro/Analista Executivo em Metrologia e Qualidade/Processos de Negócios e Tecnologia da lnformaçã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


Capí tulo 5

~estões de Segurança da Informação

Segurança da informação é uma disciplina que vem ganhando destaque crescente 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 pr imeiro 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 a dotada por diversas organizadoras é uma evidente predileção pelo tópico Cr iptografia, comportamento repetido pelo Cespe e que pode ser evidenciado 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 pr incipalmente 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. IPF-Regional/Per ito Criminal FederaVÁrea 3/20041 Segurança da informação é caracterizada, basicamente, pelo fornecimento de três serviços de segurança: a preservação do sigi lo ou da confi dencialidade das informações, a garantia da integridade dos dados e a manutenção da disponibilidade.


104

593. (ANAC/ Analista Administrativo/Tecnologia da lnformação/20091 Disponibilida

de é a garantia de que a informação é acessível ou revelada somente a pessoas,

entidades ou processos autori zados a acessá-la.

594. ITRE-PR/ Analista Judiciário/ Análise de Sistemas/20091 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. IEMBASA/Analista de Saneamento/Analista de TI/Desenvolvimento/20101 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. IINMETRO/Analista Executivo em Metrologia e Qualidade/Processos de

Negócios e Tecnologia da lnformação/20091 O uso de senhas para efetuar a autenticação dos clientes do banco pode ser um mecanismo para garantir a

confidencial idade necessária às transações financeiras do banco. 597. (INMETRO/Analista Executivo em Metrologia e Qualidade/Processos de Negó

cios e Tecnologia da lnformação/20091 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. IMCT -CTI/Tecnologista Pleno 1/Padrão l/Segurança de Sistemas de lnforma

ção/20081 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/20041 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.

Capitulo 51 Questõ es de Segurança da Informação

600. IEMBASA/Analista de Saneamento/Analista de Tecnologia da Informação/

Atuação em Rede/201 01 Na criptografia simétrica, a mesma chave é utilizada

tanto para a cifração quanto para, a decifração.

601. ITJ-ES/ Analista Judiciário/ Análise de Banco de Dados/2011 I A distribuição de chaves é mais simples e segura na utilização de um sistema criptográfico

simétri co ou de chave secreta que na utilização de um sistema criptográfico

assimétri co ou de chave pública.

602. ITJ-ES/ Analista Judiciário/Análise de Banco de Dados/2011 I 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. ISTM/Analista Judiciário/Análise de Sistemas/2011 I Os sistemas assimétricos

usam duas chaves com funções complementares: se uma é usada para cifração,

a outra é usada na decifracão; além disso, uma delas deve ser mantida secreta,

enquanto a outra pode ser pública.

604. IEMBASA/Analista de Saneamento/Analista de Tecnologia da lnformação/Atu ação em Rede/201 01 A criptografia, seja simétrica ou assimétrica, proporciona

confidencialidade, integridade, autenticidade e irretratabilidade.

605. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20071 Atualmen

te, os sistemas triptográfitos utilizados são intonditionalmente seguros por se basear na difi culdade de resol,ução de problemas matemáticos específicos

ou em limitações na tecnologia computacional vigente.

606. IMPU/ Analista de Informática/Banco de Dados/201 01 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 simp!les são reformulados em alguma sequência

diferente da original.

607. IMCT/Tecnologista Pleno/Segurança de Sistemas de lnformação/20081 Shannon identificou duas propriedade.s essencia is em um algoritmo criptográfico:

a confusão, em que a relação entre o Plaintexte o Ciphertextse torna o mais

complexa possível; e a difusão, em que se removem do Ciphertextas proprie

dades estatísticas do Plaintext. 608. IPF-Nacionai/Perito Criminal FederaVÁrea 3/20041 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. IPF-Regionai/Perito Criminal Federal/ Área 3/20041 O algoritmo DES (Data Encryption Standard! efetua exatamente as mesmas operações durante o pro

cesso decifraçã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 roundl.

105


106

610. IABIN/Ofi cial Técnico de Inteligência/Suporte a Rede de Dados/20101 O esquema

de criptografi a data encryption standard IDES) 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, r·oteadores, 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. ITCU/Analista de Controle Externo/Tecnologia da lnformaçã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, nessa,s duas máquinas, devem ser utilizadas

chaves simétricas.

612. ITCU/Analista de Controle Externo/T:ecnologia da lnformaçã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écn ica

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 lnformaçã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

cri ptográfico 3DES IDES 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áfi cos 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. IBASA/Técnico Científico/Tecnolog ia da Informação/Segurança da lnformação/2009) O padrão AES define uma dfra 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.

Capitulo 51 Questões de Segura nça da Informação

615. (PF-Nacional/Perito Criminal FederaV Ár ea 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 decifradores 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. IPF-RegionaVPerito Criminal Federal Área 3/20041 Para a utilização do modo de operação CBC (Cipher Stock Chaning Model, é necessário que seja criado

o que se denomina veto r 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. IINMETRO/Analista Executivo em Met rologia e Qualidade/Redes/20091 O modo ECB é mais seguro que o CBC, mas é menos eficiente que o CTR.

618. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnformação/20091 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 lnformação/20091 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

lEI e o destinatár io !DI sejam sempre de pequeno tamanho e que apenas uma pequena quantidade de mensage;ns 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úmero.s 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 101. 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


108

620. IBASA/Técnico Cientifico/20061 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 deciframento assimétrico, um par de

chaves (pública e privada) para cada usuário.

621. IABIN/Oficial Técnico de Inteligência/Suporte a Rede de Oados/2010) Em crip

tossistemas de chave pública, o algoriitmo de Rivest, Shamir e Adleman IRSAJ

é adequado para a implementação de criptografia/decriptografia, assinatura

digital e troca de chave.

622. IPF-NacionaVPerito Criminal Federal/Área 3/20041 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/lnformática/20081 O sistema RSA é seguro contra ataques adaptativos de texto cifrado escolhido.

624. (STJ/Analista Judiciário/lnformática/2008) O esquema OAEP apresenta se

gurança demonstrável no caso em que utiliza o RSA, devido às propriedades

deste último.

625. IMPU/Analista de Informática/Suporte Técnico/20101 Em sistemas criptográficos de chave pública, curva elíptica consiste na implementação de algoritmos

de chave pública já existentes que prove em sistemas criptográficos com chaves de maior tamanho que os algoritmos de chaves simétricas.

626. (SERPRO/Analista/Redes/20081 O criptossistema Oiffie-Hellman define uma

forma segura de troca de chaves.

627. IMPU/Analista de Informática/Suporte Técnico/20101 Em processos de autenticação de mensagens, um digest MDC [modification detection codeJ 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. IPF/Perito Criminal FederaVÁrea 3/20021 Um principio 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 ger ado para a mensagem original.

629. (ANATE L/Analista Administrativo/Tecnologia da Informação/Redes e Seguran

ça/20091 M02, M04 e MOS são uma família de funções hash do tipo one-way.

O M02 produz uma chave de 64 bits que é considerada menos segura que as

do M04 e do MOS. O M04 produz uma thave de 128 bits e usa operandos de 32

bits para uma rápida implementação.


630. ITRE-PR/ Analista Judiciário/Análise de Sistemas/20091 Criptoanálise diferencial e linear são tipos de ataques, porém, não podem ser utilizados noDES com 16 etapas.

631. IMCT/Tecnologista Jr/20081 No campo da criptografia, a criptoanálise diferencial 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.

emissor (E) transformação E relacionada à ., segurança

fi--< ~ t

informação secreta t

oponente (0)

informação secreta

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 lEI e o IDI destinatário, envolvendo um terceiro confiável(TCI. 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. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 Quando do uso de criptografia simétrica, as transformações relacionadas à segurança, realizadas

nos lados do emissor lEI e do destinatário (DI, 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 empregados. 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 lEI ou do destinatário IDI 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(TCI, que é comum ao emissor e ao destinatário.

109


110

633. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 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 (DI - e vários clientes de recursos - emissores l EI, é 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 (O); para obter bilhetes de acesso

a cada servidor de recursos 101 individual do domínio de rede, o cliente de recursos lEI precisa dialogar com o servidor Kerberos.

5.3. Assinatura digital, certificação digital e PKI

634. ISTM/Analista Judiciário/Análise de Sistemas/20111 Uma assinatura digital

confere autenticidade, integridade e sigilo a uma mensagem.

635. (TJ-ES/ Analista Judiciário/Análise de Banco de Dados/20111 A adição de uma

assinatura digital a uma mensagem pode ser efetuada pelo seu transmissor,

por meio da ad ição, à mensagem cifrada, de um hash (da mensagem original

em claro) cifrado com sua chave privada.

636. ISEGER-ES/Especialista em Políticas Públicas e Gestão Governamental/Ciência da Computação, Engenharia da Computação e Sistemas de lnformação/20111 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/20111 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/20111 Para as

sinar digitalmente um documento eletrônico, um usuário deve utilizar a chave

que consta no seu certificado digital.

639. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20081 Caso ocorra, na comunicação entre os computadores da rede da organização mencionada,

o problema conhecido como man-in-the-midd/e 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. ITCU/ Analista de Controle Externo/Tecnologia da lnformação/20081 Se a rede de uma organização atuar de forma irntegrada a uma infraestrutura de chave

pública, de natureza hierárquica, formada por RAs [regional authoritiesl e


CAs lcertification authoritiesl, o administrador da rede, ao analisar qual foi

a entidade que assinou digitalmente o certificado público de cada membro

dessa infraestrutu ra de chave pública, constatará que todos os certificados

analisados foram assinados pela autoridade certificadora raiz.

641. IMCT/Tecnologista Pleno/Segurança de Sistemas de lnformação/20081 Na

public key infrastructure X.509 IPKIXI, o processo de registro é definido como

sendo aquele em que uma autoridade certificadora (CAl 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 I Uma das técnicas de

phishingconsiste 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/lnformática/20081 Em redes lP que utilizam switches, pode-se realizar a escuta do tráfego com o ARP spoofing.

644. IEMBASA!Analista de Saneamento/Analista de Tecnologia da Informação

Rede/201 01 O ataque de MAC flooding faz um switch transmitir trames para

todas as suas portas, como se fosse um hub.

645. IDATAPREV/Analista de Tecnologia da lnformação/Redes/20061 A restrição na capacidade de aprendizado de endereços nas portas de um switch é suficiente

para evitar o ARP spoofing.

646. ITJ-E5/Analista Judiciário/Análise de Suporte/20111 lP Spoofingé uma técnica utilizada para mascarar pacotes lP por meio de endereços errados, a fim de

que não seja possível identificar o endereço lP e para que não se permita a

identificação do invasor.

647. IMCT/Tecnologista Jr/20081 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. IMCT/Analista de C& T/20081 Na fase latente ou dormente, um vírus de computador encontra-se quieto, mas pronto para ser ativado por algum evento.

649. IMCT /Analista de C& T /20081 Do ponto de vista estrutural, o programa hospedeiro 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. IABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 Os scanners 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


112

651. IBASA!Técnico Científico/Tecnologia da Informação/Segurança da lnforma

ção/20091 Um worm pode realizar diversas funções maliciosas, como a instalação de keyloggersou screen/oggers, 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. IBASA!Técnico Científico/Tecnolog ia da Informação/Segurança da lnforma

ção/20091 O cavalo de troia ( trojan horsel 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 softw.are instalados em computadores.

653. IEMBASA/Assistente de Saneamento/Assistente de Informática 1/20101 Cavalo de traia é 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. IBASA!Técnico Científico/Tecnolog ia da Informação/Segurança da lnforma

ção/20091 Um adwaredifere de um spywarepela 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. IPF-Nacional/Perito Criminal Federa l/Computação Científica/20041 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/201 1 I Um spywareconsiste 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 Tl/20071 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; wormsmodificam

o código de uma aplicação para propagar-se em uma rede; e botnets realizam

ataques articulados por meio de um c·ontrole remoto.

658. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnformação/20091 Um ataque de negação de serviço (DoS) não é uma invasão do

659.

660.

Ca pitulo 51 Questões de Segura nça da Informação

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.

ISTM/Analista Judiciár io/Análise de Sistemas/20111 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 f/oodinge o icmp f/ooding.

ITCU/Analista de Controle Externo/Auditoria de Tl/20071 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 envi o de segmentos

TCP ACK, sugere que a rede sob análise pode estar sofrendo um ataque de

negação de serviço.

661. IIPEA/Analista de Sistemas/ Suporte de lnfraestrutura/20081 Em um ataque

negação de serviço por refletor - reflector distributed denia/ of service

IODoS) - entidades escravas do atacante constroem pacotes que requerem respostas e contém o endereço lP 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. ITCU/Analista de Cont role Externo/Tecnologia da lnformação/20081 Para confir

mar a suspeita de que a indisponibilidade apresentada por um hostda 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

I CMP (Internet control message pro toco /I do tipo requestor iginados 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 o s pr incipais 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 (ln trus ion 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- VP N), o tema

mais exigido é o IPSec, principalment e aspectos que envolvem o AH (Au thentication Header), o ESP (Encapsulating Security Payload) e o IKE (Internet Key

Exchange).

113


114

663. (PF-Regionai/Perito Criminal FederaUComputação Científica/20041 Entre os

diversos equipamentos que podem ser utilizados para aumentar o nível de

segurança de uma rede de computadores corporativa, os firewal/s 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 I As ferramentas de

firewa/1 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. IEMBASA/Assistente de Saneamento/Assistente de Informática 1120101 Uma rede interna pode ser protegida contra o lP spoofingpor meio da aplicação de

filtros; como exemplo, se a rede tem endereços do tipo 1 00.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 1 00.200.200.0.

666. IMPE-AM/Analista de Redes/20081 A fi ltragem 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. IMPE-AM/Analista de Redes/20081 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) Firewa/ls baseados em filtra

gem de pacotes não apresentam problemas ao lidar com pacotes fragmentados.

669. I MC/ Informática/Administ ração de Rede/20081 Firewal/s que realizam a

inspeção de estado normalmente são menos eficazes e seguros que firewalls

baseados em filtragem de pacotes.

670. IMC/Informática/Administração de Rede/20081 Os firewa/ls stateful utilizam

apenas estado das conexões TCP para realizar a inspeção.

671. (BASA/Técnico Cientifico/Tecnologia da Informação/Segurança da lnforma

ção/20091 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. IBASA/Técnico Científico/Tecnolog ia da Informação/Segurança da lnforma

ção/20091 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 TC PI ou ao atingir um limite de tempo (como no caso de trá

fego TCP, UDP e I CMP).


673. ICBMDF/QOBM/Complementar/lnformática/20111 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. IMPE-AM/Analista de Redes/20081 Uma proxymedia a conexão de um cliente

ou usuário para prover acesso a um serviço de rede, o que evita a conexão

di reta peer-to-peer.

675. (TCU/ Analista de Controle Externo/Tecnologia da lnformação/20081 Se o administrador da rede de computadores tiver de escolher entre implantar um proxy firewa/1 ou um firewa/1 do tipo packet fi/ter, 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 à inst.alação de proxy firewal/s; se for o segundo,

deve ser escolhido um packet filfer.

676. IABIN/Analista de Informações/Código 9/20041 Um proxy de aplicação tem

capacidade de detectar ataque contra um servidor mediante a observação da

chegada de pacotes lP fragmentados.

677. IBRB/ Analista de Tecnologia da I nformaçào/20111 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. IEMBASA/Analista de Saneamento/Analista de Tecnologia da Informação/

Atuação em Rede/201 01 Nessa situação, as regras do firewa/1 devem: permitir acesso da rede externa apenas aos servidores presentes na DMZ; negar acesso

do t rá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. ITJ-ES/Analista Judiciário/Análise de Suporte/201111DS (intrusion detection systeml pode ser utilizado para incrementar o trabalho do firewa/1 e permitir

que o tráfego de dados de uma rede seja monitorado para correção imediata

de problemas ou falhas.

680. IABIN/Analista de lnformações/C,ódigo 9/20041 Em um sistema de detecção de intrusão (intrusion detectionsystem-IDSI, um falso posit ivo consiste em um

evento em que o lOS deixa de detectar uma intrusão que efetivamente ocorreu.

115


116

681. (PF-Nacionai/Perito Criminal Federal/Computação Científíca/20041 Um sistema

de detecção de intrusão IIDSJ por uso incorreto utiliza descrições de ataques previamente conhecidos (assinaturas) para identificar a ocorrência de ataques.

Esse tipo de lOS tem como inconveniente a geração de um número elevado de

falsos positivos quando ataques novo.s, para os quais ainda não foram espe

cificadas assinaturas de ataque convenientes, são lançados contra o sistema

monitorado pelo lOS.

682. (MCT /Tecnologista Jr/20081 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. IIPEAI Analista de Sistemas/Suporte de lnfraestrutura/2008) A abordagem de

detecção de anomalias por contagem de eventos em intervalos de tempo, com

indicação de alarme em caso de ultra:passagem de um limiar, é uma aborda

gem com baixo índice de falsos positivos e de falsos negativos na detecção de

intrusão.

684. IABlN/Tecnologista/Classe Pleno/Padrão/Código 15/20041 Sistemas de de

tecção de intrusão enquadram-se em duas categorias: baseados em rede

[network basedJ 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 lOS 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/20101 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. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnforma

ção/20091 lOS e lPS são sistemas que p rotegem 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 à int rusão detectada.

687. (SERPRO/Analista/Suporte Técnico/20101 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. IBASA/Técnico Científico/Tecnolog ia da Informação/Segurança da lnforma

ção/20091 Uma VPN é uma conexão estabelecida sobre uma infraestrutura


pública ou compartilhada, usando tecnologias de tunelamento e criptografia

para manter seguros os dados trafegados.

689. IDATAPREV/Anal ista de Tecnolog1ia da lnformação/Redes/20061 As VPNs que

utilizam túneis TCP são mais segruras que aquelas que utilizam UDP, já que o

TCP é confiável, enquanto o UDP não é. 690. (Correios/Analista de Sistemas/Suporte de Sistemas/20111 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 I O I PS EC é muito utiliza

do em conexões VPN I virtual private networkl, pois é capaz de validar a integridade

e a confidencialidade das informações trafegadas na VPN, por meio da utilização

do AH (autentication headerl e do ESP lencapsulating security payloadl. 692. ICBMDF/QOBM/Complementar/lnformática/20111 Em uma VPN (virtual pri

vate networkl 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

rateamento eficiente dos pacotes, os seus endereços de origem e de destino

permanecem não criptografados.

693. IMCT/Tecnologista Jr/20081 Na arquitetura de segurança do internei protocol

li PI- 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. IMCT /Tecnologista Jr/20081 O Internet security association key management protocoliiSA KM PI 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 recorren tes, 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 ambien te (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).

11 7


118

695. ISERPRO/Analista/Negócios em Tecnologia da lnformação/20101 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. IMCT/Tecnologista Jr/20081 Dependendo de seu tamanho ou natureza, uma organização pode considerar um ou m.ais requisitos da norma ISO 27001 como

não-aplicáveis e, ainda assim, continu ar em conformidade com essa norma

internacional.

697. IPREVIC/Analista Administrativo/Tecnologia da lnformação/20111 Na prática, os padrões 27001 e 27002 normalmente são usados em conj unto, 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. IANAC/ Analista Administrativo/Tecnologia da lnformação/20091 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 lnformação/20091 Um evento de

segurança de informação é uma ocorrência em um sistema, serviço ou estado

de rede que indita, 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. ITRT -21/Analista Judiciário/Tecnologia da lnformação/201011ncidente de se

gurança da informação é uma ocorrência identifi cada 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/20111 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 r iscos.

702. IANAC/ Analista Administrativo/Tecnologia da lnformação/20091 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/Tecnol.ogia da lnformação/20091 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 lnformação/20101 A norma ISO 27001 indica que uma política global

705.


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.

ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 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 i ocidentes de segurança e outros registros,

inclusive de não conformidade.

706. ISERPRO/Analista/Redes/20081 A definição de critérios para aceitação de

riscos é uma das responsabilidades da alta administração, segundo a norma

NBR 150/IEC 27001.

707. IS E R PRO/ Analista/Redes/20081 Para assegurar que os controles, objetivos de controle e processos sejam executados e implementados de forma eficaz, a

norma NBR 150/IEC 27001 recomenda a realização de auditorias externas em

intervalos regulares de, no máximo, seis meses.

708. IPREVIC/Analista Administrativo/Tecnologia da lnformação/20111 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 lchecarl.

709. ISERPRO/Analista/Redes/20081 O estabelecimento da política do sistema de

gestão de segurança da informação ISGSII é de responsabilidade da equipe de

segurança da informação.

710. ISERPRO/Analista/Redes/20081 Entre as atividades contempladas na fase agir (actl 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.


A Norma NBR 150/IEC 27001 estabelece o código de prática para a gestão da segurança da informação e a Norma NBR 150/IEC 27002 trata dos requisitos

dos sistemas de gestão de segurança da informação.

712. IMPU/ Analista de Informática/Banco de Dados/201 01 O padrão atual da norma em questão constitui-se em uma revi são da primeira versão dessa norma

publicada pela 150/IEC, em 2000. À época, essa norma era cópia da norma

britânica British Standard IBSI 7799-1 :1999.

713. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 Estão entre os objetivos da segurança da informação a garantia da continui-

119


120

dade do negócio, a minimização dos riscos para o negócio e a maximização do

retorno sobre os investimentos.

714. ITJ-ES/ Analista Judiciário/ Análise de Suporte/20111 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. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20071 O estabelecimento 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 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. IMPU/Analista de lnformática/Perito/20101 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 requ isitos

de segurança e divulgação da segurança. 718. IMPU/Analista de Informática/Suporte Técnico/201 01 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. ITJ-ES/Analista Judiciário/Análise de Sistemas/20111 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. IANTAQ/Analista Administrativo/lnformática/20091 As normas ABNT NBR

ISO/IEC 27001:2006 e ABNT NBR 150/IEC 17799:2005 enunciam um mesmo conjunto de mais de cento e trinta comtroles 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. IMPU/Analista de Informática/Suporte Técnico/20101 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 megócio.


722. IABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 No âmbito

da segurança da informação, não existem riscos aceitáveis; por isso, todos os

riscos devem ser controlados, evi tados ou transferidos.

723. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnformação/20091 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. ITRE-ES/Analista Judiciári o/Análise de Sistemas/201 1 I 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. IPREVIC/Analista Admin istrativo/Tecnologia da lnformação/20111 Uma polí

tica de segurança eficaz parte da premissa do uso efetivo de um conj unto 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 lnformação/201 O) Um dos controles

da polít ica de segurança da informação estabelece que ela deve ser analisada

criticamente a intervalos planejados ou quando mudanças significativas ocorrerem, para assegurar a sua contínua pertinência, adequação e eficácia.

727. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnforma

ção/20091 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. IBASA/Técnico Científico/Tecnologia da Informação/Segurança da lnfor

mação/20091 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. (PREVI C/ Analista Administ rativo/Tecnologia da lnformação/20111 Um arqui

vo de texto, uma IDE para desen·volvimento 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 lnformação/20101 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


122

731. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I 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. IPREVIC/Analista Administrativo/Tecnologia da lnformação/20111 Alcançar e manter a proteção adequada dos ativos da organização é um objetivo de controle

estabelecido na norma NBR/150/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. IMPU/Analista de lnformática/Perito/20101 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. lP REVI C/ Analista Administrativo/Tecnologia da lnformação/2011 I Registras 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 e,xclusão ou desativação de registros de

suas próprias atividades.

735. IMPU/Analista de lnformática/Perito/20101 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. ITRT-21/Analista Judiciário/Tecnologia da lnformação/20101 O obj etivo 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. ITRE-ES/Analista Judiciário/Análise de Sistemas/2011 I As ações que minimizam o r isco de vazamento de informações mediante o uso e a exploração de

covert channelsincluem 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.


738. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20071 Conforme a ISO 17799, é obrigatório o relatório de incidentes de segurança ao ponto de

contato designado. Assim, um funcionár io 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. IABIN/Oficial Técnico de Inteligência/Suporte a Rede de Dados/20101 Funcionários, fornecedores e terceiros devem ser instruídos a averiguar, imediatamente,

qualquer fragilidade na segurança de informação suspeita.

740. IANTAQ/Analista Administrativo/lnformática/20091 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 o:rganização e apresentam objetivos de tempo

de recuperação da ordem de poucos segundos.

741. IBASA/Técnico Científico/Tecnologia da Infor mação/Segurança da lnformação/20091 Alguns controles deverão salvaguardar sistemas operacionais e ferramentas de auditoria durante as auditorias de sistema. O escopo de veri

fi caçã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. I PREVI C/ Analista Administrativo/Tecnologia da lnformação/2011 I De acordo

com a norma NBR/ISO/IEC 27005, a comunicação de r iscos 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. ITRT-21/Analista Judiciário/Tecnologia da lnformação/20101 Os processos

que fazem parte da análise/avaliação de r iscos são identificação de riscos, estimativa de riscos e avaliação de riscos.

744. IIJSN/Especialista em Estudos e Pesquisas Governamentais/Informática e Gestão da lnformação/201 O) 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. ITCU/Auditor Federal de Controle Externo/Tecnologia da lnfor mação/20101 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


124

AVALIAÇÃO DE RISCOS

PONTO DE DECISÃO 1 Avaliação satisfatória

Não

Acerca do processo ilustrado na figura acima, que apresenta as principais ati

vidades envolvidas na gestão de riscos, conforme a ABNT NBR 150/IEC 27005,

publicada em 2008, julgue o próximo item.

746. ITCU/ Analista de Controle Externo/Tecnolog ia da lnformação/20091 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

7 47. ITRT -21 I Analista Judiciário/Tecnologia da lnformação/201 01 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

t inuidade são: Compreender o Negócio; Estratégia de Continuidade; Plano de

Continuidade; Construir e Disseminar a Cultura; e Exercitar, Manter e Auditar.

748.

749.


IIJSN/Especialista em Estudos e Pesquisas Governamentais/Informática e

Gestão da lnformação/20101 Para a elaboração de uma estratégia de continuidade 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.

ITCU/Auditor Federal de Controle Externo/Tecnologia da lnformação/20101 A norma NBR 150/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.

1

De--· Implementando 1 Reepooto de GCN

5

TMiando, Manlandol Revtoenclo

2

\!(

Considerando a fi gura 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. ITCU/Analista de Controle Externo/Tecnologia da lnformação/20091 A determinaçã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. ITCU/ Analista de Controle Externo/Tecnologia da lnformação/20091 Considerando 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 auditor ia é realizado no âmbito da atividade 2.

125


Gabaritos comentados

PARTE 2


Capítulo 1

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 identificador 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 valot-es para

atributos derivados podem ser obtidQoS 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 corr eta 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

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: • É uma regra de consistência de dados que é garantida pelo próprio

SGBD. • Integridade de Domínio: define os valores que podem ser assumidos

pelos campos de uma coluna, como por exemplo, S!!XoO só poder assumir 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 alternativa devem ser únicos.

• Integridade de Entidade: define qzte 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 conceituai não precisa, necessariamente,

se transformar em uma tabela no nível lógico. Corno exemplo temos o relaciona

mento de Generalização/Especialização que possui várias formas de mapeamento do nível conceituai para o lógico.

Níveis de Abstr~ão de Um Projeto de Banco de Dados: • Um projeto de Banco de Dadas pode ser abstraído em três níveis: con

ceituai, lógico e físico. • O nível conceitztal representa o .domínio observado independente de

Sistema Gerenciador dé 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 abst~ão é o Modelo Entidade Relacionamento (ER) (CHEN, 1976).

• O nível lógico também não depende de ztm SGBD específico, mas depende do paradigma utilizado pelo SGBD. Ao desenharmos um modelo 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

Ca pitulo 1 I Gabaritos de Banco de Dados

abstração é dependente de paradigma. Por exemplo, para um SGBD Relacional será utilizada um modelo baseado em tabelas, para um SGBD Orientado a Objetos (00), será utilizado o diagrama de classes da UML.

• Por último, o modelo físico depende do SGBD específico e do paradigma 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 dominio (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 Rl pode ser interpretado como um relacionamento entre as entidades Ele E2. No entanto, quando interpretamos

na vertical, Rl se comporta como uma entidade relacionada à entidade E3. Os atributos de Rl serão oriundos das entidades relacionadas, Ele 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ânticas (dependentes de significado) que estão diretamente ligadas ao domínio modelado. 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 mantidas 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.

131


132

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 relayão. Por exemplo, considerando uma tabela Empregado com as colunas CPF, Nome e Sexo, seriam exemplos de superchaves os conjuntos 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 Olt irredutíveis, ou seja,

considerando-se uma superchave, caso qualquer atributo integrante da superchave seja suprimido ela deixa de ser uma superchaue. Por exemplo, considerando-se a superchave (CPF, Nome, Sexo), ao retirarmos a

coluna Sexo, o subconjztnto (CPF, Nome) continua sendo uma supercha

ue. 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 relayão.

• Chaves Primárias e Alternativas (ou Alternadas) são exemplos de

chaves candidatas. Em certas situayões mais de uma coluna ou combinação (irredutível) de colunas servem para distinguir uma linha

das demais dentro de uma tabela. Se uma desta.s 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 Matrícula, cujo valor fosse único para cada rupia da tabela, sua composição seria (CPF, Matrícula, Nome, Sexo). Neste caso não há qualquer

diferen~a entre usar as CPF ou Matricula 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).


14. Errada. A figura apresenta um modelo entidade relacionamento (CHEN, 1990) que

é um exemplo de modelo conceitua!.

15. Certa. O relacionamento "presença" quando mapeado para o nível lógico gerará

urna tabela com quatro atributos, dois atributos já previstos no nível conceituai,

horário_ chegada e horário_ saida, mais as chaves estrangeiras que referenciarão as chaves candidatas das relações "Reuníão" e "Pessoa" geradas a partir das

entidades de mesmo nome.

16. Errada. Por se tratar de urna representação do nível conceituai não faz sentido falar

·se em normalização, pois esta característica é inerente ao modelo lógico.

17. Certa. As entidades "Reuníão" e "Proposta", de fato, darão origem a tabelas com

chaves estrangeiras. A tabela "Reunião" possuirá urna chave estrangeira refe

renciando a tabela "Comissãó" por estar dó lado de cardimilidade n do relâció

namento e a tabela "Proposta" possuirá urna 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. Urna 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 urna

pessoa pode participar de um número· arbitrário de comissões devido ao mesmo relacionamento. Cada proposta é encaminhada em apenas urna reunião devido

ao relacionamento de cardinalidade l :n entre "Pessoa" e "Reunião". E urna

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 dn·eto entre "Pessoa" e

"Reunião" de cardinalidade n:n.

133


134

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 conceituai apenas.

22. Certa. A questão está cotTeta. 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 flt.

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. Cer ta. 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

defmida ... " o que ameniza a inconsistência citada.

26. Certa. A questão apresenta uma possível defmiçã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


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 pod e m 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 entidade 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 FUNCIONARIO, 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 t ipo 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 l: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 desc reve 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 d efmiçã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 conjtmto de tuplas distintas.

135


136

31. Cer ta.

Uma chave primária deve respeitar duas restrições de integridade, a integt-ídade 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. Erra d a.

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. Cer ta. O modelo entidade-relacionamento (ER) representa apenas as estruturas

de armazenagem, sem se preocupar com os programas que transformarão os dados armazenados.

34. Cer ta.

A questão aborda de maneira correta o conceito de grau de relacionamentos.

35. Cer ta.

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 miníma é zero.

36. Cer ta.

A questão aborda de maneira correta o conceito de atributo derivado, ressaltando que esse tipo de atributo embora não seja armazenado, pode ser obtido

a partir de um outro atributo armazenado.

37. Cer ta. 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.


38. Certa. A questão aborda de forma cotTeta 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 in-edutível de colunas capaz de distinguir um registro dos demais. Quando uma

chave-candidatã é escolhidã para ser chave-primárià as demãis sãó denominàdás 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 con-etamente 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 minimizar a redundância e de evitar as anomalias de inserção, exclusão e atualização.

137


138

43. Errada. Segundo Navathe e Elmasri (2011, p. 352), a definição con-eta 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ômícos (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 registras, pode-se perceber que sempre que o CPF for" 111" só poderá a parecer 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 determína 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 cotTetamente 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.

Capitulo 1 I Gabaritos de Banco de Dados

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-{:have 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 Rl(AUTOR~TELEFONE) e uma dependência parcial na relação R2(1SBN4TITULO).

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 lFN 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

139


140

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 Juru;ão Externa: • Juru;ão Externa à Esquerda (LEFT OUTER JOIN): considerando

as rela~óes a e b, qz~ando executamos a ope~ã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 .

• Juru;ã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 .

• Juru;ã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 relacionadas aparecerão na mesma lin/uz..

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 implementaçã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ú1io, ou seja, as duas relações devem ter o mesmo número de atributos e o 12 atributo de a tem que pertencer ao mesmo domúlio 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.


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 relagõ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(al, a2, a3, ... , an) e a relação B(bl, 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 (al, a2, a3, ... , an, bl , 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 t imestamp não utiliza bloqueio.

141


142

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 concorrentemente 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 escalonamento 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 aborda 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 Sudru-shan (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 encolhimento (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 ocorre~· 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 Tl. No entanto,

esse enfoque aumenta a concorrência do sistema.


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, é realizada integralmente ou não é realizada.

• Consistência: uma tronsação leva um banco de dados de um estado consistente para outro estado consistente.

• Isolamento: uma transação deve parecer como se estivesse sendo executada isoladamente.

• Durabilidade: as alterações aplicadas a um banco de dados por meio de uma transação confirnuula (commited) devem persistir no banco de dados.

69. Certa. Quando uma t ransação viola qualquer 1-estrição de integridade, o SGBD

executa rollback da t ransaçã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 cor reto é: 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 acoroo com Korth, Silbersch atz e Sudarshan

(2006, p. 412).

143


144

Estados de uma TransaçéW (Korth, Silberschatz e Sudarshan, 2006, p. 412): • Ativa: estado inicial. • Parcialmente confirmada: depois que a instrução final foi executada. • Falha: depois da descoberta qtte 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çéW tenha comand.os DML que tentem atualizar dados néW gravados de outra transação, essa transaçéW néW será efetuada.

• REPEATABLE READ: os dados podem ser lidos mais de uma vez, e se outra transaçéW tiver incluído ott 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 qtte precise

do bloqueio de linhas que outras transa~ões estéW utilizando, a operoçéW somente será concluída após a liberoçtw da linha da outro transaçéW.


• READ UNCOMMITED: serão lidos conteúdos néW gravados ainda pelo banco de dados (transcu;óes passíveis de ROLLBACK). Há um enorme risco nessas operações, visto que o usuário que está bloqueando a informaçéW pode descartá-la. Esse efeito é conhecido como leitura suja.

Problemas de Consistência em Transcu;óes: • Leitura Suja: leitura de dados náo confirmados de uma linha existen

te, podendo ocasionar a leitura de uma informação nunca confirmada.

• Leitura Não-Repetida: duas leituras de dados na mesma transcu;ão náo se repetem. Na segunda leitura, dados néW existem ou foram modificados.

• Leitura Fantasma: na releitura de um conjunto de dados, surgem novas informcu;óes no conjunto.

• Perda de atualizcu;éW: duas transaçóes que ocorrem simultaneamente atualizam o mesmo dado. Isto pode ocorrer em uma sequência segundo a qual uma das atualizações é perdida.

Problemas de Consistência vers1ts Níveis de Isolamento de Transações:

Perda de Leitura Leitura Leitura Atualização Suja Não-Repetida Fantasma

READ Não Permite Permite Permite Permite

UNCOMMITTED

READ Não Permite Não Permite Permite Permite

COMMITTED

REPEATABLE Não Permite Não Permite Não Permite Permite

READ

SERIALIZABLE Não Permite Não Permite Não Permite Não Permite

1.5. Arquitetura de Banco de Dadlos 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 fisico, no entanto, a maioria dos SGBDs não separa completamente os três níveis, mas suporta essa arquitetura de alguma forma.

145


146

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 estnttura 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 conceituai" 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 Arqttitetura em Três Esquemas:

• Independência lógica de dados: é a capaâdade de alterar o esquema conceitual sem mudar o esquema externo ou os programas.

• Independência física de dados: é a capacidade de alterar o esquema 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.


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 sentido 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 01;V, 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 n este 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, t ransformação e carga (extract t ransform 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 co:rreta as atividades desempenhadas pelas

ferramentas ETL.

84. Certa. A definição de lnmon (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.

147

a. Tecnolog ia da Informação - Questões Comentadas I Cespe I UnS ELSEVIER

148

86. Erra da. 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 dt·ill up ou roll u p,

87. Cer ta. A questão apresenta uma defmição correta para business inteligence (BI), a

arquitetura OLAP é um exemplo de aplicação desse princípio. Nesta ru-quitetura 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. Erra da. O modelo star schema não é normalizado, o modelo dimensional que possui

suas dimensões normalizadas até a 3FN é o snowflake.

89. Err a da. O modelo flocos de neve (snowflake) possui suas dimensões normalizadas

até a 3FN, e, por isso, diminui a redundância.

Capítulo 2

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 (jaua.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 impares, 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 um" seriam:

m = {1, 2, 5, 4, 5} O segundo laço soma os valores d!e 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

Há duas outras modalidades de comentários em Java. a) Várias linhas:

/* ... Comentário

*I b) ComentáriosJAVADOC

!**

I Esse padrão de comentário é lido pela ferramenta JAVADOC e convertido

em arquivo HTML para gerar documentação de código.

94. Cer ta.

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 todos as 53 palavras reservadas da

linguagem:

abstract class e."Ctends implernents strictfp import

transient static char while break null

enum cate h na.tiue synchronized boolean assert

new interface long instanceof priuate case

throws return throw uolatile default float

public short final double IYyte eis e

true switch fínally uoid package super

const try false int for if

protected goto do this continue

95. Erra da.

Quando o recm-so esperado for dispon ibilizado a thread retorna ao estado pronto (Runnable) e deve aguardar que o escalonador a escolha novamente para

execução.

Estados de uma T hread, segundo Sierra e Bates (2003, p. 485):

• New: este é o estado da thread após sua instancüu;ão. Neste ponto o método start() ainda não foi invocado. A thread não é considerada uiva.

•

Capitulo 21 Gabaritos de Desenvolvimento de Sistemas Web

Runnable: este é o estado no. qual a thread está pronta para executar,

mas o escolonad<Jr ainda não a selecionou para execução. Uma thread entra neste estado quando o método start() é chamado. Ela também pode retomar a este esta® após passar pelos estados blocked/waitingl

sleeping. Neste momento a thread é considerada viva. • Running: a thread está efetivamente em execução. Ocorre quando o

escalonad<Jr seleciona uma thread para executar.

• Waiting/Blocked/Sleeping: este é o estado de uma thread quand<J ela não está disponível para execução. Está certo que há três estados com

binados em um único esta®, mas todos eles têm algo em comum: a thread continua uiva. Em outros termos, ela não está no estado m11r nable, mas pode retornar a ele caso um evento particular ocorra. Ela pode estar bloqueada aguardand<J por um recurso, pode estar dormi11r do a pedi® 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 chama®.

96. Errada. A execução do código não provoca erro em tempo de execução. A linha de

comandojava Reverso 5joão mariajosé 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á defmido na linha 5.

O métodoout inicia sua execução. lN a 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 mntime.

97. Errada. O referido item não apresenta erro de compilação.

2.1.2.0rientação a objetos com Java

98. Errada. As classes Conta e Poupança implementam sobrecarga de métodos, um tipo

de polimorfismo estático.

151


152

Podemos classificar o polimorfismo sob diversas óticas. Em Java, descrevemos as modalidadés estáJica e dinâmica da seguinte forma,·

• Polimorfismo estático: é também conhecido por sobrecarga ( overloading). 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 dé sobrescrita (overriding).

Ocorre quando métodos de uma subclasse com mesmo nome, argumentos 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 processamento.

A palavra reservada fmal 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 redefmiçã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 modera®res de acesso.

102. Erra da. Uma classe abstrata não pode ser instanciada.


Uma classe ahstrata define um modelo contendo implementação incompleta, isto é, funcionalidades çenéricas a serem implementadas por classes derivadas. Não possui instâncias e1 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:

153


154

Modificador Universo Subclasse Mesmo pacote Mesma classe

p rivate Sim

default Sim Sim

protected Sim Sim Sim

public Sim Sim Sim Sim

107. Cer ta. 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. Erra da. A execução do código não resultará em erro. A classe pl é 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. Cer ta. A linguagem Java implementa apenas a herança s imples.

2.2. Padrões de Projeto

110. Cer ta. Padrões de projeto (Design Patterns) descrevem soluções para problemas

recorrentes no desenvolvimento de software.

111. Cer ta. 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 potencial de reuso.

São 23 os padrões de projeto da conhecida "Gangue dos Quatro". Trata-se

dos autores do livro Design Pattems: 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, estmturais e comportamentais. A tabela a seguir lista todos os 23padrões, por categoria:


Criação Estruturais Comportamentais

Singleton Adapte r Chain o{Responsibility

Abstract Factory Bridge Command Factory Method Composite I nterpreter

B uilder Decorator l terator Prototype Façade Mediato r

Flyweight Me menta Proxy Obséruer

State

Strategy Template Method

112. Certa. O padrão de projeto Singleton garante a oconência de um único objeto de

uma classe e provê um ponto de acesso global a ele.

113. Errada O 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.

155


156

117. Erra da. 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. Erra da. 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. Errad a. 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. Cer ta. 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, classesjava capazes de gerar páginas HTML. O container TO.MCAT permite a

execução de JSP e servlets.

121. Cer ta. O WAR (Web Archiue) encapsula uma aplicação web. Trata-se de um arquivo

no formato zip que pode conter contém páginas JSP, páginas HT.ML, servlets, imagens, bibliotecas.(jar) e um descritor da aplicação (WEB.X.ML). Uma vez

implantado no container JSP ele torna disponível a aplicação ao usuário final.

122. Cer ta. As tecnologias JSP/Servlet e JSF são utilizadas na camada web. A camada

de negócio engloba a tecnologia EJB (Enterprise Jaua Beans).


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: <@toglib uri~»tocoLizacao_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 arquivo 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 VendaSerulet quando o botão Executa é pressionado.

157


158

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>totoL</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 MpuServletl para executar aMpuServlet2. 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. Cer ta. 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:


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 umjavabean.

<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 O contêiner implementa a persistên-

relativo à persistência cia de forma automática, utilizando mecanismo de mapeamento objeto relacional.

Queries .wio escritas pelo tle.sellvo/vedor e O desempenho das consultas não pode podem ser otimizatftls. ser otilnizado 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ência, 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 tamanho 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.

159


160

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 defmido 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 va.ntagens 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çãc das páginas • Extensibilidade de componentes por meio de customizações

2.3.2. JSF

139. Erra da.

A descrição apresentada pela questão é de Faeele t s e não de Port lets.

De acordo com aJSR 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 é cómbinado com os fragmentos de outros portlets para compor páginas de um portal.

140. Cer ta.

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) .


142. Certa. A partir da versão 2.0, o JSF passou a suportar AJAX de forma nativa. Por

meio da ta.g < 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 implementação de mapeamento objeto r elacional (ORM) e necessitava evolução.

No mercado, surgiram frarneworks ORM mais leves como Hibernate, Oracle Toplink e Objetos de Dádos Java (JDO} é 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 t raduzir 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 (hibemaée qrtery language) b) SQL nativo c) API de consulta por critério (Cri teria 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.

161


162

147. Errada. A tabela a seguir sumariza a associação adequada entre os elementos e o

tipo de arquivo Hibemale:

configuração mapeamento property hibernate-mapping session-factory class mapping generator

property

148. Errada. A principal característica do Hibemate é 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 Hiberna te 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 jaua.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, emjauascript 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 jauascript function Pessoa(n) ( this.sexo s ~ascuLino»;

this. idade ;1f n; }

var marceLo • new Pessoo(3B);


152. Errada.

Códigojauascript 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 (comojauascript) e linguagem de defmiçã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á-no da seguinte forma: <li nk rel•nstylesheet" typeantext/css...., href~nestilo.css,../>

Onde estilo.css é o nome do arquivo que contém o código que defme 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 "ualue" . Para

que o rótulo fosse apresentado conforme descrito no item, o código deveria ser escrito da seguinte forma:

<input typea"sub11i t"" na11e• ....,Sub11eter'" valuea'"'Submeter" />

156. Certa. A linha 3 do código em tela descreve o código jauascript executado quando

ocone 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 Jields 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.

163


164

Finalmente, a linha 38 retorna o valor false. Desta feita, os dados do formulário não são enviados ao servidor.

157. Erra da. 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 W30, 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. Erra da. 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 pr essiona 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 com1tnicaçâo assíncrona. • Jauascript para ligar essas tecnologias.


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 XMLHttp Request.

Segun.diJ o W3C, o XMLHttpRequest é usado para enviar requisições HTTP e HTTPS a um servidor Web e para ler resposta<; 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, processada 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çãojavascript 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, n as 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 umajanelapop·up com a expressão: "Seu browser não suporta Ajax!" .

164. Errada.

A função ajaxFuncionO 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.

165


166

2.5. lnteroperabilidade 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 externamente.

Lista de possíveis atributos de ztma declara~ão XML:

Nome É obrigatório? Descrição

version S im Especifica a versão do padrão XML a qual o doeu-mento obedece. O único valor possível é 1.0.

encoding Não Indica o conjunto de caracteres usados no doeu-

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 IS0-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 IS0-8859-1.


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:

DOMXSAX

DOM (Document Object Model) SAX (Simple API for XML)

Modelo Baseado em árvore Baseado em eventos

Uso de recursos Proporcional ao tamanho do do- Valor constante de uso de

cumento. Potencialmente pode memória. utilizar muita memória.

Aplicabilidade Ideal para manipulação do XML Leitura sequencial de do-(inclusão, remoção de elementos) 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 StylesheetLanguage

Transformations ) é uma linguagem que permíte transformar documentos XML em novos documentos XML, em documentos HTML (Hypertext Markup Language), 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 o1ttra semântica específica de implementação. Foi criado a partir de premissas de simplicidade e extensibilidade.

167


168

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 listados pela W3C. SOAP é o protocolo usado para transporte de informações neste

cenário. Trata-se do padrão mais utilizado.

175. Erra da.

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. Erra da.

O corpo de uma mensagem SOAP pod.e 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 "etTado" 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".


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·

cwnento WSDL: • Informações de interfaces que descrevem todas as /itnçõ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 dlefmiçõ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 contatado 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.

169


170

183. Certa.

Há duas abordagens para implementação de Web Services: • REST (Representational State Transfer) - estilo arquitetural forte

mente centrado no protocolo HTTP. • WS-* - web services tradicionais (também conhecidos por Big Web Ser

uices ). Devido principalmente à sua simplicidade e ao menor ouerhead 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 ouerhead na comunicação e tempo necessário para processar informações de controle são menores do que no modelo de desenvolvimento de sistemas embasado em SOA.P. Portanto, é incorreto afirmar que

o modelo REST demanda mais recursos computacionais que o modelo baseado

emSOAP.

2.5.3. SOA

185. Cer ta.

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 Seruices. XML e WSDL são padrões abertos utilizados na implementação de Web Seruices 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. Errada Nessa 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 utilizam 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.


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; • Objetiuos estratégicos em relação a benefícios específicos de projetas;

• Interoperabilidade intrínseca em relação a integração personalizada;

• 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 s i. No caso específico das atividades descritas no item, não há possibilidade de paralelização. Ademais, segundo a OASlS, 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 corno foi descrito no item.

171

Capítulo 3

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 registras 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ârnetms 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 cons1tlta pelo sistema.

Funções Transacionais: • Entrada eJ.terna: tem conw principal objetiuo a manutenção de arqui-

• vos lógicos internos ou a alterar;ão do comportamento do sistema. Saída externa: tem conw principal objetiuo a geração de dados derivados (que não estão armazenados em nenhum ALI/AlE) e sua exi

bição para o usuário; opcionalnzente, pode realizar manutenção em ALis antes de exibir dados para o usuário.

• Consulta externa: tem como principal objetiuo a recuperação e exibição de dados armazenados em ALls/AIEs a partir de parâmetros informados pelo us~tário; não pode gerar dados derivados e nem alterar

nenhwnALI.

Capítulo 3 I Gabaritos de Engenhar ia de Software

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 (ALise AlEs), 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 quantidade 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, AlE, EE, SE e CE.

A expressão "características do domínio de informação do software" é utilizada por Pressman para referenciar todos os tipos de funções contabilizadas pela

APF- ALI, AlE, 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 manipulados (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 ALise AlEs, que

podem ser tanto dados como informações de controle. Processo elementar é a menor unidade de ati v idade 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/AlE). Dados temporários gerados para

processamento em outra aplicação são classificados como saídas externas.

173


174

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 AlE. 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 orientada a serviços (SOA), é possível que uma aplicação Afaga 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 AlE, 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. Enad a. Embora a aplicação típica da APF seja para estimativa de projetas de desen·

volvimento e manutenção de software, o IFPUG também provê regras específicas

para contagem de aplicações prontas.

Tipos de Projetas de Contagem: • Projeto de desenvolvimento: aplica-se à estimativa de tamanho fun·

cional cks req1úsitos de usuário para sistemas cujo desenvolvimento ainda não tenha sido iniciado ou esteja em andamento.

• Projeto de melhoria (ou manutenção): apliéa-se à estimativa de tanuz· nho de alterações corretivas ou evolutivas soliéitadas 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, permitinck medir a funcionalidade efetivamente entregue ao usuário.

199. Certa. O total de pontos de função obtidos pela soma das ftmçõ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.

Capítulo 3 I Gabaritos de Enge nhar ia de Software

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 pertinê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 defmidas pela

NESMA, sendo que a contagem detalhada corresponde à aplicação das regras

descritas pelo IFPUG.

Além disso, os 14 "fatores de ajlllste 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 projetas

de manutenção.

175


176

Funcionalidade de conversão:

Funções utilizadas apenas rw 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, tc.is 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 projetas de melhoria e à aplicação da técnica na fase inicial do desenvolvimento.

Contagens Antecipadas NESMA: • Contagem estimativa: requer informações gerais sobre quais grnpa

mentos de dados devem ser utilizados e quais transações serão executadas; considera que todos as funções de dados (ALI e AlE) 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 grupamentos de dados que serão consultados (AlE) ou manipulados (ALI) pela aplicar;ão; utiliza a fórmula PF = 35 *ALI + 15 *AlE.

Projetas de Melhoria NESMA-

Ao contrário do IFPUG, que considera a quantidade integral dos pontos referentes a frmções adicionadas, modificadas ou excluúUJ.s, a NESMA define deflatores, chamados de fatores de impacto, para cada tipo de alteração.

•

•

•

Funções adicionadas: sempre são consideradas integralmente ({atar de impacto igual a 1,00).

Funções modificadas: o {atar de impacto pode variar entre 0,25 e 1,00 para funções de dados e entre 0,25 e 1,50 parafunções transacionais. Funções excluídas: sempre utilizam fator de impacto igual a 0,40 .


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 ftmçô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; indiretamente, 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 projeto 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.

177


178

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 independentemente 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. Erra da. 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 en·ada.

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,


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 descritivo 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 semp1·e 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 llimplificada (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. Certa Segundo 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. Certa Pressman (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 oo aplicaçOO de uma abordagem sistemática., disciplinada e

quantificáoel, paro o desenvolvimento, operot;ão e manute17.Ção do software; isto é, a aplicação da engenharia ao software.

217. Errada As cru·acterísticas das fases de projeto e elicitação de requisitos estão t rocadas.

Pois Larman (2004, p. 30) afirma que o projeto enfatiza uma solução conceituai que satisfaça os requisitos enquato que a elicitação de requisitos tem por objetivo determinar o escopo do projeto de software.

179


180

218. Certa O 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. Errada

As características das abordagens do modelo unificado e ágeis estão trocadas. 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 arte{atos previstos em uma metodologia de engenharia de software.

220. Errada

Segundo Pressman (2006, p. 45), o modelo espiral exige a consideração direta

dos riscos técnicos em todos os estágios do projeto.

221. Erra da Segundo 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 lmplentação, Entrega e Feedback.

222. Certa Segundo 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. Certa Segundo 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).

Capítulo 3 I Gabaritos de Engenharia de Software

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 mecanismo 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

181


182

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 comportamentos 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. Cer ta.

De fato, o diagrama de caso de negócio é um artefato do RUP desenvolvido 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 derivadas 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 desenvolvimento de software.


236. Errada

O 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. Certa

A 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 UnifiedProcess (RUP): • É um processo de engenharia de software que oferece rtma 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· menta 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, Elaboração, Construção e Transição.

• O eixo vertical representa as disciplinas, que agrupam as ativid<Uies de maneira lógica, por natureza, são elas: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Gerenciamento de Projeto, Gerenciamento de Configuração e Mrtdanr;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, construção e transição.

183


184

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 (disponivel em: http://www.

wthreex.com/rup/ou http://www-Ol.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 Ltm produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em um processo acordado."

• O gerenciamento da qualidade é implementado em todas as disciplinas, fluxos de trabalho, fases e iterações do R UP. 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.


247. Certa. A afirmativa enumera cotTetamente 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 planejamento, 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 mru'Co 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 ru·quitetura executável do sistema em desenvolvimento.

185


186

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 implementaçã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. C erta. 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. Erra da.

Ség'Uildo Pressmán (2006, p. 63), o Extrême Progtamrning inclui um conjunto

de regras e práticas que ocorrem no conte>.."i:o de quatro atividades de arcabouço:

planejamento, projeto, codificação e teste. Então, pode-se afirmar que o desenvolvimento de um código na XP está relacionado à fase de codificação.

258. C erta. Apesar do gabarito defmitivo 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 projetas de desenvolvimento de software e para a criação de produtos.

259. Erra da. 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.


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 encon trar 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 . . . .

mtntmz.zar nscos. • Testes - são definidos pelos usuários e pelos desenvolvedores. São os

c1ité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. • Refatoroção- a cada nova funcionalidade adicionada, é trabalhado o

design do código até ficar na sua fonna 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.

187


188

• Propriedade Coletiva- a equipe como um todo é responsável por cada

arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.

• Padrão de Codificação- todo código é deserwolvido seguindo um padrão.

• Semana de 40 horas de trabalho - trabalhar por longos períodos é contraproducente.

264. Erra da. O XP trabalha com requisitos volát.ei.s não necessariamente conhecidos de

antemão em sua totalidade.

265. Cer ta. 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

fl.losofia it.erativa 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

agent.es individuais independent-es cooperam para criar resultados emergent.es. Um resultado emergente é uma propriedade além da capacidade de qualquer agent.e individual.


269. Errada. Segundo Pressman (2006, p. 60) "a agilidade pode ser aplicada a qualquer

processo de software. Entretanto, para conseguir isso, é essencial que o processo seja projetado de modo que permita à equipe de projeto adaptar tarefas e

aperfeiçoá-las, conduzir o plan~jamento para que se entenda a fluidez de uma abordagem de desenvolvimento ágil, eliminar tudo menos os produtos de trabalho 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 defmido pelo PO. No planejamento

189


190

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. Cer ta. 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.


Requisitos segundo o Sommeruille (2003, p. 83):

• Requisitos Funcionais: são declarações dé funções que o sistema deve fornecer; como o sistema deve reagir a entradas específicas e como deve se comportar em déterminadas situações.

•

•

Rec;uisitós 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 sistema 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. E r rada. 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 qu.e garante que o

software implementa corretamente uma função específica (estamos construindo o produto corretamente?).

• Validação: se refere ao COfr:junto de atividades que garante que o software construído corresponde aos requisitos do cliente (estamos construindo o produto correto?).

191


192

286. Cer ta. Durante a análise, a especificação de requisitos permite revelar o que o s iste

ma irá realizar no que se refere às funcionalidades, sem defmir, 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. Cer ta. 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 fmal será do usuário do sistema e por isso o IÚvel de detalharnento deve respeitar a sua capacidade de compreensão.

288. Errad a. Em um processo iterativo, a identificação dos atores, tanto os principais

quanto os secundários, pode ser realizada em mais de urna iteração.

289. Cer ta. A afirmativa é verdadeira e está de acordo com Pressrnan (2006, p. 120).

290. Erra da. Pressrnan (2006, p. 121) afirma que a gestão formal de requisitos é necessária

apenas para grandes projetos com centenas de requisitos.

291. Errad a. 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. Cer ta. Afirmativa aborda a essência do conceito de requisito de maneira correta.

293. Erra da. Sornrnerville (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. Errad a. Requisitos de software devem ser levantados após requisitos de sistema.


295. Errada. O SWEBOK (Guide to the Software Engineering Body ofKnowledge- 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 é definída por Sommerville (2003, p. 115) como técníca 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 dominio.

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 requ isitos válidos segundo Sommerville (2003,

p. 119). Ela ainda afirma que a limitação do tamanho do sistema em 100MB é

um requisito de dominio, mas para julgarmos essa afirmativa precisaríamos ter

a descrição do domínío, tendo em vista que os requisitos de domínío 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 Sommeruille (2003, p. 119):

• Requisitos Permanentes: são requisitos relativamente estáueis, que deriuam da atiuidade principal da organização e que se relacionam diretamente com o domínio do sistema.

193


194

• Requisitos voláteis: são requisitos que provavelmente vão se modificar durante o desenvolvimento do sistema ou depois que o sistema estiver

em opercu;ão. Os requisitos voláteis podem ser: mutáveis, emergentes, consequentes ou de compatibilidade.

302. Cer ta. Questão correta segundo Sommerville (2006, p . 103).

303. Errada. O levantamento de requisitos mmca deve ser negligenciado em hipótese

alguma.

3.6. Arquitetura de Software

304. Cer ta. 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 inter pretação dos dados de entrada e pela

manipulação do modelo, de acordo com esses dados.

Arquitetura de software (ALLEN; BAMBARA, 2003, p. 27): • Arq1útetura 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 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 us1tá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).


307. Certa. A questão apresenta uma definição correta para a arquitetura cliente-servidor

segundo So=erville (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 FowTier (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 .

Arquítetura Cliente- Servidor em Três camadas (Larman, 2004, p. 446):

• Camada de Apresentação: classes qrte contêm funcionalidade para visualização dos dados pelos usuários. As classes de fronteira para a.tores humanos se encontram nessa camada.

• Camada da Lógica da Aplicação: consiste da camada existente no servidor 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 é implementada 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.

195


196

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 estrtdo de recursos interessantes e falhas para tnovar.

3. Especificar metas de usabilidade: determinação dos pesos dos atributos 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 a1~ 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 inte1faces 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 ttma 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.

Capítulo 3 I Gabaritos de Engenharia de Software

• 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 fmal 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 IEEE829.

IEE 829: • Erro: resultado de uma falha humana. • Defeito: resultado de um errá 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.

197


198

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ógi-ea interna do componente testado.

• Testes Caixa Branca (White Box) ou Caixa de Vidro: visam avaliar as cláusulas de código, a lógica i"nterna. do componente codificado, as

con{igura~ões e outros elementos técnicos.

317. C erta. 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.

Sommeruille (2003, p. 358):

• Inspeção de software: analisam e verificam as representações do sistema, 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 ttm sistema ou dos documentos associados. As inspeções de software e as análises automatizadas são técnicas 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

Capítulo 3 I Gabaritos de Enge n haria de Software

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.

Manutenlbllldade Flexibilidade Tesíabilidade

REVISÃO DO

Correção ~ Confiabilidade

Fatores de qualidade de sohware de McCall. Fome: Pressman (2006, p.350).

321. Errada.

ODO PRODUTO

Eficiência Integridade

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.

199


200

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. Errad a. 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.

Mmmtençã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 N BR ISO/IEC 12207:1998:

•

•

•

•

Processos fundamentais: aquisü;ã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 treinamento. Processo de garantia da qualidade: define as atividades para garantir objetivamente qrte os produtos e processos de software estão em conformidade com seus requisitos especificados e aderem aos seus planos

estabelecidos. Revisões conjuntas, attditorias, verificação e validação podem ser utilizadas como técnicas para garantia de qualidade.


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 afrrmativas iniciais da questão estão corretas, no entanto, segundo Sommerville (2003, p. 365), diferentes checklists devem ser preparadas para diferentes

linguagens de programação.

329. Certa.

A questão aborda de maneira corr eta as características do teste de partição de equivalência (SOMMERVILLE, 2003, p. 378), do teste estrutural (SOMMERVILLE, 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 (00):

• 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, dodos e

funções relacionadas em um único bloco de organ~açã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 forma para fazer coisas diferentes.

331. Errada.

Classe abstrata não gera instância.

201


202

332. Erra da. É possível em orientação a objetos implementar os relacionamentos de ge

neralização e especialização, em 00 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 obj eto é a instância de uma classe e que

todos os objetos da mesma classe possuem a mesma estrutura.

334. Erra da. 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. Erra da. Todo objeto possui um identificador úmico que nunca varia com o tempo de

vida do objeto. Esse identificador denomina-se OID (Object ldentifier) 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. Erra da. Classe e interface são dois conceitos independentes.

339. Erra da. 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. Erra da. A afirmação está errada, pois o objeto é instância da classe, não o contrário.


341. E rrada. 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 expressar 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 (ovetTiding) 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 "Cl" com o método "ml()" e duas subclasses "C2" e "C3", ambas herdam automatica

mente o método "ml()" da superclasse. Então é possível que uma variável "a" do tipo "Cl" (basta declararmos: Cl a) aponte para os objetos de "C2" ou "C3" (basta

chamarmos os construtores das subclasses: Cl a = new C2() ou Cl a = new C3()). Neste caso, se o método "ml()", herdado pelas subclasses "C2" e "C3" for sobrescrito (reimplementado) em cada uma das subclasses, quando a partir referencia "a" do

tipo "Cl" chamarmos o método "ml ()" ele executará de uma determinada forma quando a referência apontar para um objeto de "C2" (por exemplo, Cl a = new

C2(); a.ml();) e de outra forma quando a referência apontar para objeto de "C3" (por exemplo, Cl a = new C3() ; a.ml() ;), 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. E rrada.

O inicio 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.

203


204

347. Cer ta.

A questão pode ser facilmente entendida por meio de um exemplo. Dada uma classe "Ca" que possua o método "mO" 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 "mO" 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. Erra d a.

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. Erra d a.

De fato, o diagrama de componentes é um diagrama estrutural que deve

ser utilizado para réprésentar â configuraçâo e a ãrquitetura 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.

I Diagrama

~ Diagrama Estrutural I I Diagrama Comportamental I

Lf> Li> Diagrama Diagrama Diagrama

Diagrama Diagrama Diagrama de de de de Máquina de Casos de

Componentes Classes Implantação <le Estados de Uso Alividade

I Diagrama Diagrama Diagrama Diagrama

de de de Estrutura de 1 Diagrama de lnteraçáo 1

Perfil Objetos Composta Pacotes f Diagrama Diagrama Diagrama Diagrama

de de de de Sequência Comunicação lnteração Tempo

Geral


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 realizaçã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 repr-esentadas no diagramas de sequência e de

comunicação.

353. Certa. Em um diagrama de casos de uso, um ator pode ser um sistema extemo, um

usuário ou um hardware que interaja com o s istema 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 ConsTerna (), 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.

205


206

358. Erra da. A seta pontilhada "verdadeiro" indica o retorno de uma chamada a método.

359. E rra da. No diagrama de caso de uso há herança entre use case e entre os atores

360. Cer ta. 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. Cer ta. Um diagrama de implantação representa a topologia física do s istema 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. Cer ta. O enunciado está cotTeto, 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. Errad a. O diagrama de sequência descreve as troca de mensagens entre os objetos

sem mostrar as mudanças de estado dos mesmos.

364. Cer ta. 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.


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 '-t' (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 urna seta não ponti

lhada, denominada seta fina, pois segundo a defmiçã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 eJd;ernos de uma funcionalidade

sem os detalhes de implementação. Os objetivos de um caso de uso são: defmir

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 ato r 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

207


208

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 di re

ta mente apenas por objetos da própria classe e de suas subclasses.

• (-) package (pacote): o elemento da classe pode ser acessado diretamente apenas por objetos da própria classe e de classes do mesmo

pacote.

• (-) private (privado): o elemento da classe pode ser acessado diretamente 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 protegido, 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ônímo de composição, e por isso na associação identificado 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áxímo, três objetos de Departamento.

Agregação e Composição segundo Booch, Rumbauch eJacobson (2006, p. 69):

• Os autores afirmam que uma associação simples entre duas classes re

presenta um relacionamento estncturol entre pares, significando que es

sas duas classes estão mnceitualmente em um mesmo nível, sem que uma

seja mais imporlante do que a otdro.No entanto, em alguns casos, há a

necessidade de se f'azer a rrwdelagem de um relacionamento "todo/parte"


(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 agregaçã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 qrte

representam as "partes" depende da existência da instância querepresenta o "todo".

372. Certa. De fato, o número '1' no canto su.perior 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 corres ponde

ao relacionamento de realização e #2 corresponde ao relacionamento de dependência. Devido a esta troca, o gabarito da questão deveria ser mudado para En-ada.

374. Certa. A afirmativa cita conetamente 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. E rrada. 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 inicio 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

209


210

executa." . Já a continuação, "Essencialmente, são diagramas de classe que incidem 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. Erra da. 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. Erra da. O erro da questão consiste em afirmax 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. Cer ta.

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 é assincrona 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) .


380. Errada. O erro da questão consiste em aítrmar que há cinco componentes distríbu

í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 jtmções (joins) são em·

pregadas quando há atividades em pat·alelo. 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, f"malmente, afirma que alguns nós de um

diagrama de implantação representam unidades computacionais, outros representam 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 objetos são instâncias de estruturas (classes), esse diagrama representa a dinâmica

do sistema nas interações entre seus diversos elementos estruturaís, 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 disponíbilizadas 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

tamentaís 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

211


212

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. Cer ta.

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 "quantidade" 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. Cer ta.

Um sistema orientado a objetos nada mais é que um conjunto de objetos interagindo 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.

Capítulo 4

Gabaritos de Gestão de Tecnologia da Informação

4.1. Gerenciamento de Projetas

4.1.1. Conceitos básicos de gerenciamento de projetas

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: • Temporariedadé: após alcaru;ar seus oqjetivos, um projeto deve ser

necessariamente encerrado. • Singularidade: o trabalho realizado para gerar o produto, seruú;o ou

resultado do prqjeto é único, dif'erente de todos os demais projetas.

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 pt'Ojeto, o gabarito defmitivo 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 alca.Tu;ado seus objetiuos e terminado.

• Integração: ocorre quando os recursos do projeto são redirecionados

para outros projetas ou para operações da empresa; na visão do PM-


214

BOK, isso poderia se dar porque o projeto dei:tou de ser importante

para a organ~ação ou porque verificou-se que os objetiuos não são exequíveis.

• Esgotamento: ocorre quando os recursos do projeto são cortados, sem

que sejam realocados para outros projetas; 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 alcanç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 pl"ojeto limitam-se ao que é necessário

para que o projeto alcance seus objetivos. A otimização de reCUl-sos compartilhados entre vários projetas é uma atividade típica da gerência de portfólio, que pode

ser exercida por um escritório de projetas.

393. Cer ta. Serviços continuados- chamados pelo PMBOK de trabalho operacional ou

simplesmente opera<;<)es-possuem caracteTisticas distintas dos projetas; enquan·

to projetas são temporários e singulares, as operações são contínuas e repetitivas.

Entretanto, como o t rabalho operacional também precisa ser planejado e controlado, é possível aplicar a maioria das ferramentas de gerenciamento de projetas também ao gerenciamento das operações. A essa prática dá-se o nome

de gerenciamento por projetas.

394. Certa. Segundo o PMBOK, enquanto a finalidade dos projetas é 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.

Ca pítulo 4 I Gabaritos de Gestão de Te-cnologia da Informação

4.1.2. Portfólios, programas e estruturas organizacionais

396. Certa . Portfólios são compostos por progt·amas, projetos e outras atividades relacio

nadas ao alcance dos objetivos estratégicos da organização. Uma das atividades do

gerenciamento de portfólio é a deftniçã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 par te 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 ver ticais, oriundos da vinculação hierárquica, e relacionamentos 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 projetas, pela designação

de gerentes de projetas em tempo integral com autoridade considerável e aloca<;ão de pessoal admini.stratiuo do projeto em tempo integral.

215


216

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 funcionais pode caracterizar tanto uma organização funcional como organizações

matriciais. Caso A, B e C sejam gerentes de projetes, 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 projetes

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 proj eto 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-

Matricial

Funcional Por projeto Fraca Forte

Pouca ou Limitada

Baixa a Moderada Alta a quase

nenhuma moderada a alta total

de recursos Pouca ou

Limitada Baixa a Moderada Alta a quase

nenhuma moderada a alta total

controla o orçamento do Gerente Gerente Misto

Gerente Gerente de

funcional funciona) projetas

do gerente de projetas Tempo Tempo Tempo Tempo Tempo

parcial parcial integral integral integral

administrativa do Tempo Tempo Tempo Tempo Tempo de projetas parcial parcial parcial integral integral

4.1.3. Escritórios de proje tas e outras partes interessadas

402. Errada. A s igla PMO refere-se a Project Management Office (escritório de gerencia

mento de projetes). Além disso, um escritório de projetes centraliza e coordena

Capítulo 4 I Gabaritos de Gestão de Te-cnologia da Informação

alguns aspectos do gerenciamento de projetos sob seu domínio, mas não neces

sariamente mediante integração dess es 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 projetas:

• 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 projetas: gerencia mudanças de escopo de programas e oportunidades para melhor alcançar objetivos de negócio, otimiza

o uso de recursos compartilhadas e gerencia metodologias, padrões, riscos e interdependências entre projetas.

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 s upervisionar 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 fmal ou que

21 7


218

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 defme 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 habilidades 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 revisã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. Cer ta.

Relações entre f'ases 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 do conclusão

do fase anterior; pode aumentar o risco e resultar em retrabalho caso surjam problemas qu,e invalidem os produtos gerados de fomw antecipada.


• Fases iterativas: apenas a fase atual está planejada a cada nwrnento, 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 projetas 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:

Ciclo de Vida do produto

412. Errada.

INTERMEDIÁRIA

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.

219


220

414. Certa.

Na primeira fase do projeto, a irúciação consiste no desenvolvimento do termo 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 servem 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 morútoramento e controle que

se alimentam mutuamente.

Relação entre os grupos de processos, segzmdo o PMBOK e Mulcahy (2009 ):

4.1 .5. Gerência de integração

416. Cer ta.

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 irúciar 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 . Resunw do cronograma de marcos e orçamento .


• Requisitos para aprovação do projeto . • •

Gerente do projeto, responsabilidade e nível de autoridadé .

Identificação do patrocinador ou emitente do termo de abertura .

417. Certa. A declaração de trabalho (stateme:nt 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-beneficio 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 PMBO K 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.

221


222

421. Certa.

Categorias de ativos de processos orga.nizacioiWis: Processos e procedimentos • Normas, políticas e ciclos de vida padrão • Modelos e instmções de trabalho • Políticas e procedimentos de qualidade • Procedimentos de controle fi=nceiro e medição • Procedimentos e critérios para gerenciamentos de riscos e muda.nças

• Procedimentos e critérios para comunicação e encerramento do projeto Bases de conhecimento • Arquivos do projeto (linhas de base, cronogramas, diagramas de rede,

registras dé 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, contendo 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 escopo do projeto, submete as solicitações de mudança ao controle integrado de mudanças e controla o impacto das mudanças aprovadas.

423. Erra da. A defmiçào do escopo requer conhecimento aprofundado das características

dos produtos do projeto e do trabalho necessário para realizar esses produtos, o


que pode requerer consultas a especialistas. Por esse motivo, o PMBOK cita a

opinião especializada como ferramenta do processo de defmiçã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. • Seguenciar as atiuidades: identifica e documenta os relacionamentos

lógicos entre as atividades do cronograma. • Estimar os recursos das atiuidades: determina o tipo e as quantidades

de cada recurso usado para realizar as atiuidades 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 trono· grama.

• Desenvolver o cronograma: determina as datas de início e término planejadas de cada atiuidade e do projeto como um todo, com base nas estimativas de recursos, duroçáo e sequência das atiuidades.

• Controlar o cronograma: avalia o andamento atual do cronograma do projeto, controla os fatores que criam mudanças no cronograma e submete as solicitações de mrtdanç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 projetes de menor escopo, ainda assim a estimativa de duração das atividades só pode ser

223


224

feita após a estimativa dos recursos, pois o tempo necessário para realizar cada

tarefa depende diretamente da quantidade de recursos alocados.

428. Erra da. 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. Erra da. 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 estimativa pessimista para realização de cada atividade.

432. Erra da. 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.


4.1.8. Gerência de custos

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

jetas 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áticas derivadas a partir de análise estatística de dados de projetas anteriores 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 incorporar o efeito dos riscos conhecidos à duração estimada das ati v idades.

• Estimativa bottom•up (custo): obtém estimativas de custo para ccula pa.• cote de trohalho da EAP ou atividade do cronograma, e posteriormente agrega essas estimativas em t-'Omponentes 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 d o 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 (V A): é o custo orçado para o trohalho que foi conclu

ído até um determinado momento; reflete o andamento do escopo do projeto.

225


226

• Valor planejado (VP): é o custo orçado do trabalho que deveria ter sido concluído até wn determinado momento; reflete o tempo consumido pelo projeto.

• Custo real (CR): mede o custo efetivo da realização do traballw.

• Variação de custos: mede a diferença entre o valor agregado pelo pro· jeto e o custo real até um dado momento (V A- CR).

• Variação de prazos: mede a diferença entre o valor agregado e o tempo gasto no prqjeto (V A- VP).

• Índice de desempenho de custos: representa a capacidade do projeto em gerar os produtos planejados dentro do custo esperado (VA/CR).

• Índice de desempenho de prazos: representa a capacidade do projeto em realizar as tarefas de acordo com os prazos planejados 0/NVP).

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 probabilidade e o impacto de riscos negativos (ameaças).

437. Certa.

Ferramentas e técnicas para identificação de riscos: • Técnicas de coleta de informcu;ões: brainstorrning, 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ça.s.

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


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-beneficio. 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 priorida des 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 estatisticos 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 tornado, 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 esperado 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 decisão, que indicam qual decisão produz o resultado mais adequado aos objetir;os 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 projeto, considerando o conjunto de riscos priorizados; em geral é feita por meio da análise de Mo·nte Carla, técnica que simula iterativamente a ocorrência dos riscos individuais e calcula a distribuição de probabilidades em fum;ão do impacto combinado desses riscos.

227


228

4.1.1 O. 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 gerenciamento do projeto. Ou seja, mesmo que se considerasse a versão mais antiga do

modelo, a questão deveria ter sido considerada etTada.

Processos da çerê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 qztalidade: 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á etTada 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 pi'Ojeto: acompanha o desempenho dos mem· bras da equipe, fornece feedback e resolve conflitos para otimizar o desempenho do projeto.


444. Certa.

Técnicas de resolução de confiitos: • Retirada: ocorre quando uma das partes se retira para evitar que o

confiito 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 coTUXJrdâ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 dif'erentes

opiniões e perspectivas, com f'oco na obtenção de consenso e compro· misso ("ganha-ganha").

• Confronto/Solução de problemas: trata o confiito como um problema que deve ser solucionado com o exame lógico de alternativas.

445. E rrada.

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 1w projeto. • Planejar as comunicações: determina as necessidades de informações

e comunicações das partes interessadas- quem precisa de qual informaçã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 comunicações para satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas.

229


230

• Reportar o desempenho: distribui informa~ões consolidadas sobre o desempenho às partes interessadas.

446. Certa.

Processos da çerê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 nwnitora 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, capacidade fmanceira 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.



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 qrte 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-Suc), que aborda v 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

231


232

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.

453. Cer ta. Vide o comentário da questão seguinte.

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.


456. Certa. A avaliação de cada área de processo pode resultar na atribuição de um nível

de capacidade de O a 5 (na versão 1.2) ou de O 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, qualquer 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. E rrada. 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 implemen tadas e o nível de capacidade necessário para cada uma das áreas.

Representações oo CMMI: • Contínua: avalia cada área de processo de maneira isolada, em níveis

de capacidade que variam de O a 5 (CMMI 1.2) ou de O a 8 (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 {ztn

ção de etapas bem definidas de melhoria. A maturidade organizacional é medida em níveis de 1 a 5, com base em conjuntos predefini<Ws de áreas de processo e níveis de capacidade déssas áreas, associados

a cada nível.

458. Certa. O nível1 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ível2 do CMMI.

CMMI - Práticas Genéricas de Nível 2: • 2.1 Estabelecer política organizacional

233


234

• 2.2 Planejar o processo

• 2.3 Prover recursos • 2.4 Atribzúr 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 processá • 2.9 Avaliar objetivamente a aderência do processo • 2.10 Revisar o status com a alta administra~ão

460. Cer ta. À 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ível2. Entretanto, é preciso lembrar que os níveis de capacidade e maturidade no CMMI são cumulativos e, portanto, todas

as características de nível2 devem continuar presentes nos níveis subsequentes,

o que torna a questão certa.

461. Cer ta. 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 antet-iores. 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. Cer ta. O nível4 de maturidade do CMMI é caracterizado pelo gerenciamento quan

t itativo 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 permíte 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íuell- Inicial: o trabalho é realizado de maneira improvisada (ad-hoc),

o que impede previsões sobre o desempenhá e o resultado dos projetas. • Níuel2- Gerenciado: é possível prever o desempenho de cada projeto,

com base na experiência acumulado de projetas similares anteriores.

•

•


Nível 3- Definido: é possível prever o desempenho dos projetas da or

ganização em geral, com base nas características do processo padrão. Nível 4- Gerenciado qztantitativamente: a previsibilidade dos projetas passa a ser descrita de maneira precisa com base em indicadores

de desempenho coletados de diversos projetas 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, toma-se possível prever também as alterações nesse desempenho causadas por interue~õ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 ClvfMI Appraisal Method for Process lmprovement). 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 qzte 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 ztma 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 avaliaçã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

235


236

área de processo de gerenciamento de riscos abrange riscos de diversas origens

e naturezas, inclusive aqueles relacionados a processos. Por fun, a inovação

organizacional é abordada de maneira s istemática pela área de processo de gerenciamento do desempenho organizacional.

466. Erra da. A área de processo de gerenciamento de requisitos pertence ao nível de

maturidade gerenciado (nível2), e não ao nível definido (nível3). 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,

moni.toramento e controle de projeto, garantia da qualidade de processo 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 orga.nização, treinamento na orga.nização, gestão integrada de projeto, gestão de riscos, desenvolvimento de requisitos, soluçã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, gerenciamento do desempenho da organização.

467. Certa.

A questão faz referência às metas específicas da át-ea citada: determinar as causas de defeitos e tratar as causas de defeitos.

468. Errada. Esse é um bom exemplo de um aspecto sempre dificil 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 ser ia 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 é s inô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,


gestão integrada de projeto, gestão de riscos, gestão qrwntitativa de projeto.

• Gestão de processo: foco nos processos d<:J organização, definição dos processos da organização, treinamento na organização, desempenho dos processos da organizaçtw, 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 inicio 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 C MM I. 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 nivel 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 nivel 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á

237


238

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 usr~ários.

Os requisitos de interfaces entre componentes são identificados na área de desenvolvimento de requisitos, dando origem a implementagões sob responsabilidade da área de solu~ão técnica, as quais serão gerenciad.as 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 r iscos 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: desenvolvet; comprar ou reusar" . Assim, caso a escolha recaia sobre a aquisição de


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 d ifí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 er rada, por aparentemente misturar conceitos e pr odutos 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 é t ratada 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át icas listadas, há duas que não perten cem 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.


239


240

482. Certa.

Vide o comentário da questão seguinte.

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 ref'erê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 maturido.de), guia. de avaliação e documentos do programa. Características: 7 níveis de maturido.de, 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 acum111lativos, 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, devem 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.



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êru:ia de Reutilização (evolução). • D - Largamente Definido: Verificação, Validação, Projeto e Constnu;ão

do Produto, Integração do Produto, Desenvolvimento de Requisitos • E- Parcialmente Definido: Gerência de Projetas (evolução), Gerência

de Reutilização, Gerência de Recursos Humanos, Definição do Proces· so Organizacwnal, Avaliação e Melhoria do Processo Organizacional

• F- Gerenciado: Medição, Garantia da Qualidade, Gerência de Configuração, Aquisição, Gerência de Portfólio de Projetas (esse último, somente na versão 2009).

• G - Parcialmente Gerenciado: Gerência de Requisitos, Gerência de Projetas.

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.

241


242

491. Erra da. 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. Erra da. 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. Erra da. 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 dad os 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 IT IL 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 minimizados 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.

!TIL u3- Principais irwuações: • Abordagem baseada no ciclo de vida dos seroiços. • Visão integrada de infraestrutw-:a, aplicações, processos e pessoas. • Visão integrada de TI, áreas de negócio e fornecedores. • Nouos processos para preencher lacunas da uersão anterior.


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 explicitamente no livro de desenho de serviços.

!TIL 2011 - Publicações da biblioteca,· • Estratégia de Serviço (Servi'ce Strategy ): trata da definú;ão de estra

tégias e modelos de funcionamento da organização, bem como a forma como requisitos de negócio são identificadas e documentados por meio de pacotes de nivel de serviço (SLP- Service Level Packages).

• Desenho de Serviço (Service Design): abrange a concepção do servú;o em todos os seus aspectos, que são documentados em um pacote de

desenho de serviço (SDP- Service Design Package). • Transü;ã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 ambiente de prodttção.

• Operação de Serviço (Service Operation): trata das atividades, processos e fttnçõ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 (Continuai Service lmprovement):

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.

243


244

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 estabilidade 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.

!TIL 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.

504. Errada.



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 aqlllisiçã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 du-etos 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 ge1-enciamento

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 justificativa de que os estágios de desenvolvimento organizacional são, segundo o ITIL, apenas "sinlllares 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 li.vr·o de Estratégia de Serviço.

!TIL v3- Estágios de Desenvolvimento Organizacional: • Rede: colaboração informal para entrega rápida de serviços, com foco

acentua® na tecnologia. • Direção: estabelecimento de hierarqzâas rígidas, com foco no controle

centralizado das ativioodes das diversas áreas.

245


246

•

•

•

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 servtços. Colaboração: adoção de estruturas totalmente matriciais, com foco no atendimento às necessidades de neq6cio.

4.3.3. ITIL - Desenho de serviços

508. Erra da. As características e os processos citados referem-se ao livro de Desenho de

Serviços.

!TIL 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

Gerencia.mento de Continuidade de Serviços de TI Gerenciamento de Segurança da Informação Gerenciamento de Fornecedores

509. Cer ta. 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 n egócio. A definição desses requisitos de negócio é feita por processos de gerenciamento de continuidade de negócio.

510. Errad a. 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 gerenciamento do catálogo de serviços.

511. Cer ta. 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


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.

!TIL v3 - Componentes da dispo·nibilidade de serviço: • Confiahilidade: período durante o qual um seroiço de TI ou outro

item de configuração pode executar a sua função acordada sem interrupção.

• Sustentabilidade: velocidade com que um seroiç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 ref'ere à disponibilidade de um item de configuração.

• Desempenho.

• Segurança.

513. Certa.

!TIL v3 -Métricas do gerenciamento de disponibilidade: • Mean time between f'ailures (MTBF): período durante o qual um ser

viço opera normalmente, entre períodos consecutivos de indisponibilidade.

• Mean time to restare service (MTRS): período durante o qual um serviço fica fora do ar, logo ap6s a ocorrência de um incidente e até que retorne à operação rwrmal.

• Mean time between service incidents (MTBSI): período entre incidentes consecutivos, correspondente à soma do MTRS (tempo de indisponibilidade 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 repara.r o item

de configuração responsável pela ocorrência do incidente, antes que o serviço possa retornar à operação normal.

247


248

514. Certa.

!TIL v3- Estratégias para recuperação de desastres:

• Workarourui Manual: uso de solr~ção não baseada em TI para superar a interrupção de serviços de TI.

• Recuperação Gradual (Cold Staruiby): uso de local alternativo (stan

dby) para rw qual os serviços são implantados somente após a ocor

rência do desastre; tipicamente implicam tempos de recuperação superiores a 72h.

• Recuperação Intermediária (Warm Standby): uso de local alternativo

que já se encontra previamente preparado para receber os serviços, seruio apenas ativado quando da ocorrência de um desastre; rwrmal

mente permitem a recuperação em períodos de 24 a 72h. • Recuperação Imediata (Hot Sta.ndhy): manutenção de local alternati

vo 1w qual os serviços encontram-se ativos e sincronizados com o site principal, o qrte permite o uso imediato quando da ocorrência de um

desastre; geralmente requerem rw máximo 1 a 2 horas para recuperação do serviço.

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

515. Errada. A descríção corresponde ao estágío de transíção de servíços.

ITIL 2011 - Processos de Transição de Serviços: • Gerenciamento de conhecimento • Gerenciamentó da mudança

• Gerenciamento da configuração e ativos de seroiç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 transíção é responsável pela coordenação dos

recursos utilizados pelos demaís processos do estágio de transíção. No entanto,

a questão afirma que "os processos de transíção de servíço [ ... )e a coordenação dos recursos [ ... ) são de responsabílídade do processo de planejamento e suporte

da transíção", o que está errado.


517. Errada.

Embora a gerência de configuração e a gerência de ativos possuam focos distintos (reunidos em um só processo pelo I TIL v3), a questão erra ao afirmar

que a gerência de configuração não mantém informações sobre os relacionamentos 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 precisa 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. Err ada.

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.

!TIL 2011 -Processos e Funções de Operação de Servi~os:

• Geren.ciamento de eventos • Geren.ciamento de incidentes • Geren.ciamento de problemas • Atendimento de solicitações

249


250

• Gerenciamento de acesso • Central dé 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.

!TIL 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 sobrepor aos requisitos de qualidadé 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 t:W negócio.

• Qualidade x custo: os serviços devem atender aos SLAs estabelecit:Ws, ao menor custo possível e com us:o otimizado dos recursos.

• Atividades reativas x proativas: é importante antecipar-se aos possí

veis problemas, desde que isso nw implique mudanças excessivas ou perda da capacidade de reação.

524. Errada. O Service Desk é uma função, e não um processo.

!TIL 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· di r os resultados de wn processo, mas não de uma função).

• Possuem clientes definidos, para quem são entregues os resultados

gerat:Ws. • Utilizam feedback para con·eção t:W 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.


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 elTO

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 ITII.:', pres

supõe-se que os processos sejam executados exatamente na forma sugerida pelo modelo. Nesse caso, se há X registres de etTos conhecidos, deveria haver aproximadamente o mesmo número de registres de problemas (cada problema

diagnosticado com sucesso dá origem a um elTO 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 caracteristicas atribuídas pelo ITIL

v3 à função de gerenciamento de operações.

251


252

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 fisicas 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 melhoria 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

535. Certa.


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.

537. Cer ta.



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 goveman~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 alca.nce dos bene[u:ios, com otimização

de custos.

• Gerenciamento de recursos: otimização dos investimentos e <W 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 contl'Oles 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: • Efetívidade: 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 rec!crSos. • Confidencialidade: proteção de infonnações conf'idenciais para evitar

a divulgação indevida. • Integridade: fidedignidade e totalidade da infonnaçã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.

253


254

• Conformidade: aderência a leis, regulamentos e obrigações contratuais aos quais os processos de negócios estão sujeitos, isto é, critérios de negócios impostos externamente e políticas internas.

• Confiabilídade: entrega da informação apropriada para os executivos administrarem a entidade e exercerem suas responsabilidades fíduciá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 qu.e 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óctos..

• Infraestrutura: tecnologia e recursos (ou seja, hardware, sistemas operacionai.s1 sistemas de gerenciamento de bases de dados, redes, nwltimídia e os ambientes que abrigam e dão suporte a eles) que possibilitam o processamento dos aplicativos.

• Pessoas: fitncionários (internos, terceirizados ou contratados) reque

ridos para planejar, organiza1; adquirir, implementar, entregar, suportar, 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 conceituai 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. Cer ta. 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

fmal do ano de 2007. Portanto, essa questão deveria ter sido dada como etTada pelo Cespe, que provavelmente baseou-se em alguma referência antiga para

elaboração do enunciado.


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 objetiuos de

negócio e nwnitoramento 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 considerados para cada processo, bem como das práticas de controle necessá

nas. • Dirigido por métricas: uso de indicadores e modelos de maturidade.

547. Certa. O Cobit é orientado a processos, m as 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 a lcanç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

n egó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 auten ticação de transação e integridade (AC6).

Cobit 4.1 - Controles gerais de aplicação: • AGI Preparação e Autorização de Dados Originais: os documentos

fonte devem ser preparados por pessoal azttorizado e de acordo com procedimentos estabelecidos.

• AC2 Entrada e GaZeta de Dados Fontes: a entrado 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álidos.

• AC4 Processamento Íntegro e Válido: a integridade e validade dos dados são preservados em todos os ciclos de processamento.

255


256

• AC5 Revisão das Saídas, Reconciliação e Manuseio de Erros: as saí· das são manuseadas de forma autorizada, entregues para os destinatá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. Cer ta. Embora todos os controles gerais de processos sejam aplicáveis a todos os pro

cessos do Cobit, a menção de "alguns requiisitos 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 somente se tornaria errada se dissesse que "apenas alguns requisitos" são aplicáveis.

Cobit 4.1 - Controles gerais de processos: • POl 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.

• P02 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. • P05 Políticas, Planos e Procedimentos: Define e comunica polfticas,

planos e procedimentos que direcionam os processos de TI. • P06 Melhoria de Performance do Processo: identifica métricas para

a performance e resultados dos processos, coleta dados e toma providê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 (efetividade, 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. Cer ta. 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.


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<_iã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.43. 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 O 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.

257


258

558. Errada.


559. Questão Errada.

Os níveis de maturidade no Cobit variam de O a 5 e são utilizados para avaliar cada processo individualmente, e não o "c<>njunto de melhores práticas de governança". Além disso, o monitoramento de conformidade com os procedimentos é

caract-erística do nível 4 de maturidade.

Cobit 4.1- Níveis de maturidade: • O- Inexistente: não há atividades do processo, pois a organização não

reconhece que existe uma questão a ser trabalhado ..

• 1 - Inicial/Ad-hoc: a organização reconhece a necessidade do processo, 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 treinamento formal e a responsabilidade é dos indivíduos.

• 3 -Processo Definido: procedimentos foram padronizados, documentados 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 limitada.

• 5- Otimizado: adoção/evolt~çã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 pr·ocesso não é obrigatório.

561. Certa. Esse é o uso típico do modelo de matw-idade, segundo a visão do Cobit 4 .1:

avaliar os processos atuais, comparar a s ituaçã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.


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 objetiuos e medição

563. Certa. A questão apenas transcreve lite·ralmente 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 conformidade 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 r iscos (planejamento e organização), o processo de garantia de contínuidade 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 processos PlaJUdamento e Organização • POl Definir um Plano Estratégico de TI • P02 Definir a Arquitetura da Informação • P03 Determinar as Diretrizes de Tecnologia

259


260

• P04 Definir os Processos, a Organização e os Relacionamentos de TI • P05 Gerenciar o Investimento de TI • P06 Comunicar Metas e Diretrizes Gerenciais • P07 Gerenciar os Recursos Humanos de TI • P08 Gerenciar a Qualidade • P09 Avaliar e Gerenciar os Riscos de TI • POJO Gerenciar Projetas Aquisiçãa e Implementação • AI 1 Identificar Soluções Automatizadas • AI2 Adquirir e Manter Software Aplicativo • AI3 Adquirir e Manter Infraestrutura de Tecnologia • Al4 Habilitar Operação e Uso • Al5 Adquirir Recursos de TI • AI6 Gerenciar Mudanças • Al7 Instalar e Homologar Soluções e Mudanças Entrega e Suporte • DSl Definir e Gerenciar Níveis de Serviços • DS2 Gerenciar Serviços Terceirizados • DS3 Gerenciar o Desempenho e a Capacidade

• DS4 Assegurar a Contintúdade 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 • DSIO Gerenciar Problemas • DS 11 Gerenciar os Dados • DS12 Gerenciar o Ambiente Físico • DS13 Gerenciar as Operações Monitoramento e Avaliação • MEl Monitorar e Avaliar o Desempenho de TI • ME2 Monitorar e Avaliar os Controles Internos • ME3 Assegurar a Conformidade com Requisitos Externos • ME4 Prover Gouernança de TI

566. Errada. No domínio de planejamento e organização encontra-se o processo "Deter

minar as Diretrizes de Tecnologia" (P03}, 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


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 (All), desenvolver e manter os softwares e a infraestrutura que compõem a solução (AI2 e AI8},

adquirir os recursos necessários (AI5} e capacitar os usuários das áreas de negó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 exclusivamente no domínio de entrega e suporte, é nesse domínio que se encontra o processo "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 8.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.

570. Certa.


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.

261


262

572. Errada. A descrição do objetivo do pt'Ocesso "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"

(P06) - 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" (POl). Segundo o Cobit, a vinculação entre TI e negócio é de responsabilidade 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 ati v idade • A (accountable)- Quem é responsabilizado pelos resultados da atividade • C (consulted)- Quem é consultado para execução da atividade • I (infonned) - 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.


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 defmiçã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 ent re 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 ai (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.


263


264

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 asstmtos a empresa deve se dedicar corresponde à

etapa de definição do negócio, e não das políticas.

585. Cer ta.

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 reconhecid<:Zs por sua excelência em determinada área de atu<:Zção.

• Análise SWOT- avalia os pontos fortes (Strength) e fracos (Weakness)

presentes no ambiente intem{) da organizaçãiJ, 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 extetno, 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çãiJ do problema caso nada seja feito.


• 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 determinado 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ór ico 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 produ tos ou serviços substitutos, o poder de barganha de clientes e fornecedores, e a intensidade da rivalidade entre competidores (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.

265

capítulo 5

Gabaritos de Segurança da Informação

5.1. Conceitos básicos de Segurança da Informação

592. Certa.

Os três principais serviços de segurança citados na !itera tum 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 seçztrança: • Confidencialidade- propriedade de que a informação não est~ja dis·

ponível ou revelada a indivúluos, erúidades ou processos não autorizados (ABNT, 2006, p. 2).

• l rúegridade - 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 qzte uma comunicação é autêntica (STALLINGS, 2008, p. 8).

capítu lo 5 I Gabaritos de Segurança da Informação

• Irretratahilidade- impedimento de que o emissor ou o receptor negue uma mensagem transmitida (STALLINGS, 2008, p. 10).

• Controle de acesso - o impedimento de uso não autorizado de um re· curso (STALLINGS, 2008, p. 9).

594. Certa. A primeira afirmativa da questão· é perfeitamente coerente com a defmiçã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 dependeria de um mecanismo capaz de fornecê-la, como a criptografia, por exemplo.

267


268

Nada impediria que, uma vez autenticado o usuário, as informações trafegassem 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 seruice- DoS).

598. Certa.

Os ataques são tipicamente classificados em ati vos 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 - tentam déscobrir ou utilizar informações do sistema, mas

não afeta seus recursos e se dividem em: liberação do conteúdo do. mensagem e análise de tráfego;

• atiuos- tentam alterar os recursos do sistemo. ou alterar sua operação e compreendem: dis{arce, 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.


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, cahe 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 enada a respeito dos algo

r itmos 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 alguma 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étr ica, uma vez que se uma chave simétrica deve ser confidencial, uma chave pública deve ser autêntica.

602. Errada. É just.amente o contrário, os sistemas simétricos apresentam desempenho

significativamente superior aos assimétricos na cifração e decifração de mensagens (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 cripto!JI·afia aliada a alguma formatação/redundância adicional dentro de um método ou protocolo poderia fornecer serviços adicionais (STALLINGS, 2008, p. 231).

269


270

605. Erra da. Os sistemas criptográficos utilizados atualmente são computacionalmente

seguros e não incondicionalmente seguros (STALLINGS, 2008, p. 21). Os simé

tl"Ícos baseiam sua segurança na limitação da tecnologia computacional vigente,

enquanto os assimétricos em problemas matemáticos de difícil solução.

Segun® Stallings (2008, p. 21), um sistema criptográfico é computacionalmente seg1tro se atender um dos seguintes critérios:

• o custo para quebrar a cifra é superior ao valor da infonnação codificada; • o tempo exigido para quebrar a cifra é superior ao tempo de vida útil

da infonnação. Um sistema criptográfico é incondicionalmente seguro se o texto cifra®

gerado pelo esquema não tiver informações suficientes para determinar exclusivamente o texto claro correspondente, não importando quanto texto cifrado esteja

à disposição. Somente o One-Time Pad é com;idera® incondicionalmente seguro.

606. Cer ta. 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 transposição, também chamada de permutação (STALLINGS, 2008, p. 19).

607. Cer ta.

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 clhave de criptografia o mais complexo

possível (SHANNON, 1949, p. 709). O gabarito da questão deveria ser "Errado".

608. Cer ta. A despeito de o DES possuir em seu desenho operações de substituição e de

transposição, ele é classificado como de s ubstituição porque, se comparados o

bloco cifrado de 64 bits gerado com o bloco em clat-o de mesmo tamanho, o que resulta do processo decifração é uma substi tuição de bits e não uma transposição.

609. Cer ta. 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).


610. Certa. O ataque de encontro no meio (meet-in-the-middle) é bem-sucedido contra

oDES 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 decifraçã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 algoritmo. Como resultado desse procedimen to, 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 (K 1 = 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 cripta· 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 Ríjndael 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).

271


272

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 permut~ã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 oper~ão para cifra de bloco são (STALLINGS, 2008, p. 126):

• • • • •

Eletronic Codebook (ECB); Cipher Block Chaining (CBC); Cipher Feedback (CFB); Outuput Feedback (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 segm'O do que o CBC, onde blocos claros iguais result<IIIl 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 ouerhead (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 simplicidade da implementação e absoluta confidencialidade até a posse do gerador de


números aleatórios de elevadíssima qualidade. Para finalizar, o One-Time Pad, que emprega chave aleatória e que mmca é 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 e!Tada

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

decifraçã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 criptogra{adas (STALUNGS, 2008, p. 20; SCHNEIER, 1996, pp. 5-7):

• apenas texto cifrado; • texto claro conhecido; • texto claro escolhido; • texto claro escolhido adaptativo; • texto cifrado escolhido; • chave escolhida. 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 téxtos cifrados e tem acesso às suas versões decifradas. O objetivo é descobrir a chave de decifração (SCHNEIER, 1996, p.6).

273


274

624. Certa. Segundo Stallings (2008, p. 197), o preenchimento ideal de criptografia as

simétrica (optimal CM,Ymmetric enc1yption padding- OAEP) representa solução recomendável para proteger o RSA contra ataques de texto cifrado escolhido.

625. Cer ta. 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 hcu;h (FOROUZAN, 2008, pp. 969-975):

• código de detecção de modificação (MDC)- não emprega chave e oferece apenas integridade;

• código de autenticação de mensagens (message authentication code

MAC) -emprega chave simétrica e oferece integridade e autenticação; • assinatura digital - emprega criptografia de chave pública e oferece

integridade, 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 hcu;h (colisão).

capítulo 5 I Gabaritos de Segurança da Informação

629. E rrada. 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 . E rrada.

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 da 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 Cliptográfico

(STALLINGS, 2008, p. 56; TANENBAUM, 2003, p. 799).

631. E r rada.

A diferen~ entre dois blocos anali:sada 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 con-esponde à definição correta.

632. Errada.

O erro da questão está na afirmação de que as chaves assimétricas empregadas 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 distribuição de chaves simétricas (FOROUZAN, 2008, p . 983). A questão descreve con-etamente características do Kerberos conforme Stallings (2008, pp. 296-297).

5.3. Assinatura digital, certificação digital e PKI

634. E rrada. 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.

275


276

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. Cer ta. Conceito correto do login unificado propiciado pelo single sign on, conforme

Tipton (2010, p. 105).

637. Cer ta. 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. Erra da.

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 qu.e podem cobrir alguma

região geográfica, como um país ou um continente.

641. Erra da. Segundo Stallings (2008, p. 310), registn> é 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.


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 lP), não prejudicando assim a comunícaçã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 {o1jada, 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. Defmição correta de lP spoo{ing, 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 - infecta arquivos executáveis;

277


278

•

•

• • •

•

residente na memória- aloja-se na memória principal e infecta os pro

gramas eéecutados; do setor de inicialização (boot) - infecta o registro de iniéialízação (Master Boot Rerord- MBR); furtivo- projetado para se ocultar dos sistemas antivírus;

polimórfico - muda a sua forma a cada nova infecção; metamórfico- capaz de mudar tanto a sua aparência quanto seu comportamento; vínts de e-mail- embute-se em. anexos de e-mail .

648. Cer ta.

Descrição correta, segundo Stallings (2008, p. 430).

Fases do ciclo de vida de um vírns (STALLINGS, 2008, p. 430):

• • • •

latente; propagação; disparo; execução da atividade maliciosa •

649. Certa.

Descrição correta da relação entre o vírus de computador e o seu programa hospedeiro, segundo Stallings (2008, pp. 4 29-430) e out.ros autores. Particular

mente, o caso em que o hospedeiro armazena apenas parte do códígo 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):

• scanner simples - baseados em assinaturas; • scanner heurísticos; • interceptação de atividade - baseado em comportamento; • proteção completa- combinação das anteriores.

651. Errada.

As ações citadas são atribuídas aos cavalos de troia em CERT.br (2006, p. 68).


652. Errada. A descrição corresponde à caracterização de um wonn, conforme CERT.br

(2006, p. 75).

653. Certa. A afirmação é coerente com a defrniçã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, bacltdoors 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 flltragem dos tráfegos egresso e ingressante pode ser útil no combate a esses ataques da seguinte forma:

279


280

a) não se admite sair da rede interna pacotes cujo lP de origem seja da rede externa (NAKAMURA, 2007, p . 109);

b) não se admite a entrada de pacotes da rede externa cujo lP 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 ncímero de pedidos de conexão (pacotes SYN) é enviadc, causando um estouro da pilha de memória do aluo, 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' seruice- DDoS) por refletor (STALLINGS, 2008, p. 439).

662. Errada. No smur{, os pacotes I CMP 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

lP 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 firewa.ll 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. Cer ta.

O conceito apresentado é a visão consagrada a respeito das camadas em que atua um filtro de pacotes, conforme pode ser visto em Nalcamura (2007, p. 228),

dentre outros autores.


Principais tecnolàgias de firewall (NAKAMURA, 2007, p. 228): • filtro de pacotes (stateless); • filtro de pacotes baseado em estados (stateful); • firewall proxy;

• híbrido; • adaptativo; • reativo; • pessoal. Desta lista, os que costumeiramente são cobrados em questões de proua

são o filtro de pacotes, o filtro de pacotes baseado em estados e o fírewall proxy, também chamado de gateway de aplicação.

665. Certa.

Conforme discutido na questão 68, essa forma de filtragem de tráfego ingressante 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 Nakamura (2007, p. 228).

667. Certa. O melhor desempenho de um filtro de pacotes baseado em estados decorre

dos seguintes fatos (NAKAMURA, 2007, p. 233): •

•

o número de regras na tabela de estados é menor, uma vez que somente os pacotes de inicio de conexão (SYN puro, por exemplo) devem ser comparados com essas regras;

a verificação na tabela de estados não é feita de forma sequencial, como

no 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).

281


282

Originali'IWnte, a solução adotacla par.a lidar com o problema da fragmentação executar a filtragem soi'/Wnte rw primeiro fragmento e permitir a passagem

de todos os demais fragmentos. Esta abordagem foi inicialmente considerada segura porqzte, mesmo que

apenas o primeiro fragmento seja barrada 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 sistem.a de destino mantém os fragi'IWntos na memória por um determinado tempo, aguardando

o fragmento faltante. Cientes disso, os atacantes passaram a usam pacotes

fragmentados para gerar ataques de neqaçã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 protocolos não orientados à conexão, como o UDP e o I CMP. 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ções de cabeçalhos dos pacotes, como nos firewalls stateless, para os pacotes de início de conexão; a inspeção da tabela de estados, que armazena o estado das conexões, para todos os demais pacotes.


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 fírewall (NAKAMURA, 2007, p. 235).

673. Errada. A simples adição de mais um elemento na arquitetura do fírewall 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 lP 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 lP fragmentado é remontado no nível de rede, o proxy de aplicação, atuando na última camada, não tem acesso aos fragmentos, mas somente a dados

remontados a partir de fragmentos ou oriundos de pacotes lP 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 fírewall (NAKAMURA, 2007, pp. 246-249):

283


284

• dual-homed host- formada por um único dispositivo com no mínimo duas interfaces de rede e que age como proxy;

• screened host- formada por um filtro de pacotes e um tipo especial de servidor chamado bastion host;

• screened subnet- formada. por dois filtros de pacotes, um interno e outro externo, e que possui, confinada entre eles, uma rede de perímetro, denominada DMZ.

678. Cer ta. 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. Cer ta. 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ção baseada em assinaturas, também chamada de baseada em conhecimento ou por uso incorreto;

• detecção baseada em comportamento. Além dessa abordagem, o CESPE costuma utilizar outra, descrita em

Stallings (2008, p. 409):

• detecção estatística de anomalia- dados relacionados ao comportamento 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ção baseada em regras - é definido um conjunto de regras que podem ser usadas para decidir se determinado comportamento é o de um intruso.


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. Erra da.

A detecção estatística de anomalias, pode se dar sob duas hipóteses (STALLINGS, 2008, p. 409):

•

•

detecção de limiar -limiares são defmidos independentemente do usuário, para a frequência de ocolTência de vários eventos; baseada em perfil- mudanças no comportamento das contas individu

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 hoste em rede bem como as desvan

tagens destes últimos apresentadas ma 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 estabelecimento da VPN. Isso independe da rede, da aplicação e do correspondente

285


286

protocolo de transporte que venha a ser utilizado, podendo ser aplicável a qualquer comunicação passível de rateamento, 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 esconder 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- controle de acesso, integridacle sem conexão, autenticação da origem dos dados e rejeição de pacotes repetidos; ESP (apenas com criptografia)- controle de acesso, rejeição de pacotes repetidos, confidencialidade e confidencialidade limitacla do fluxo de tráfego (proteção contra análise de tráfego); ESP (criptografia mais autentica!;áo) - controle de acesso, integridade

sem conexão, autenticar;ão da origem dos dados, nljeição de pacotes repetidos, confidencialidade e confidencialidade limitada do fluxo de tráfego.

692. Certa.

Um exemplo da situação descrita é o IPSEC com ESP no modo tímel, 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 atTanjo propicia de forma clara o rateamento 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):

• um número de 32 bits denominado índice de parâmetro de segurança (S ecurity Parameter Index- SPI);

• o lP de destino; • o mecanismo de segurança a ser usado - AH ou ESP.


694. Certa. Essa é a atribuição correta do 18AKMP, 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 180/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 justificativa de que "na redação do item, a palavra " revisão" pode ter interpretações diferentes, o que poderia ter levado os candidatos ao e!To". 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 180/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 normaABNT NBR 180/IEC 27001:2006 afirma

na seção 2 que é indispensável para sua aplicação a norma ABNT NBR 180/IEC 17799:2005, desde 2007 nomeada como NBR 180/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 requisito 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 (8GSI) é "a parte" do sistema

global de gestão, baseado na abordage m de riscos ao negócio (ABNT, 2006, p. 3).

287


288

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. Erra da. Esse é o conceito de evento de segurança da informação, conforme ABNT

(2006, p. 2).

701. Certa. Alrrmaçã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 afrrmativa 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 intervalos planejados, sem sugestão de periodicidade (ABNT, 2006, p. 11).

708. Certa. Altrmativa em conformidade com o item 4.2.3 a) 2) da norma (ABNT, 2006,

p. 7).


709. Certa. De acordo com o item 5.1 a), o estabele<:imento da política do SGSI é respon

sabilidade da direção (ABNT, 2006, p. 9).

710 . E rrada.

As ações exe<:utadas em 4.2.3 a) e e ) permitem a identificação de não-conformidades 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. E rrada.

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):

• BS 7799:1995; • BS 7799-1:1998- renomeayão; • BS 7799-1:1999- revisão; • ISO/IEC 17799:2000; • ISO/IEC 17799:2005- revisão; • ISO/IEC 17799: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. E rrada.

Todos os itens listados são possibilidades de controle, segundo a definição 2.2 da norma 27002 (ABNT, 2005, p. ii.).

715. Anula da. 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 organização está exposta" (ABNT, 2005, p. x:ü). 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.

289


290

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 t rês possíveis fontes de requisitos de segurança da informação, conforme ABNT (2005, p. xi).

Fontes principais de requisitos dé segurança da infonnação (ABNT, 2005, p. xi):

• análise/avalia~ão de riscos para a organização;

• legislação vigente, estatutos, regulamentação e cláusulas contratuais; • conjunto particular de objetivos e reqrúsitos de negó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íti<:os para o sucesso da implementação de segurança da infor· mação (ABNT, 2005, pp. xii-xiii):

• política de segurança da informação que reflita os objetivos do negócio; • abordagem e estrutura da segurança da informação consistente com a

cultura organizacional; • comprometimento e apoio visível de todos os níveis gerenciais; • bom entendimento dos requisitos de segurança da informação; • divulgação eficiente da segurança da informação para se alcançar a

conscientização; • distribuição de diretrizes e normas sobre a política de segurança da

informação; • provisão de recursos financeiros para as atividadés da gestão de segu

rança da informação; • provisão de conscientização, treinamento e educação adeqnados;

• estabelecimento de um eficiente processo de gestão de incidentes de segurança da informação;

• implementação de um sistema de medição, que sllja usado para ava

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


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 a legaçã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 estrutura 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 EtTada.

À 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ção de responsabilidades pelos ativos; • definição do uso aceitá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) .

291


292

Formas de tratamento de risco (ABNT, 2005, p. 6): • reduzir riscos; • aceitar riscos; • evitar riscos; • transferir riscos.

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 t razido 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 aírrmativas 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 "dever" 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, 200·5, p. 21) . A análise de riscos é uma das

fontes de requisitos de segurança da informação (ABNT, 2005, p. xi) .


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 (ABN'I: 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 umpendriue é um ativo tisico (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 contrar ia 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).

293


294

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. xü). 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 afumado CABNT, 2005, p. 99).

740. Erra da. 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. Cer ta. 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 defmição 3.4 da norma

27005 (ABNT, 2008, p . 2).

capítulo 5 I Gabaritos de Segura nça da Informação

743. Certa. O processo de análise de risco compreende a identificação e a estimativa de

r iscos 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ção de contexto; • análise de riscos, que compreende a identificação e a estimativa de

riscos;

• avaliação de riscos; • tratamento de riscos; • aceitação de riscos;

• comunicação de riscos; • monitoramento e análise crítica de riscos.

744. Certa. A afirmativa está em conformidade com o descr ito 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

con-eta se a comparação estabelecesse super ioridade 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ão do programa de gestão de continuidade de negócio (GCN); • Entendendo a organização; • Determinando a estratégia de continu idade de negócios; • Desenvolvendo e implementando uma resposta de GCN; • Testando, mantendo e analisando criticamente os preparativos de

GCN; • Incluindo a GCN na cultura da organização.

295


296

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 (recouery time ob· jectiue- 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 aluo para (ABNT, 2007, p. 5):

• retomada da entrega de produtos ou serviços após um incidente;

• recuperação do desempenho de uma atiuidade após um incidente; • recuperação de um sistema ou aplicação de TI após um incidente. 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 fomla 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.

Referências bibliográficas

PARTE 3


1.1. Referências de Bancos de Dados

ALLEN, P.; BAMBARA, J. Introdução a sistemas de banco de dados. Campus-Elseviet;

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. Prqjeto 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! S erulets eJSP. Alta Books, 2008.

BATES, B.; SIERRA, K. Use a Cabeça! Java. Alta Books, 2005. BAUER, C.; KING, G. Java Persistent e With Hibemate. Ciência Moderna, 2007. CERAMI, W. Web Services Essen tials. O'Reilly, 2002.

GAMMA, E .; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Prqjeto: S oluções reutilizáveis de software orientado a o~jetos . Bookman, 2005. GEARY, D.; HORSTMANN, C. S. Core Java Seruer 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

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, 1.; RUMBAUGH, J. UML- Guia do usuário . Campus-Elsevier, 2006. FOWLER, M. Padrões de arquiteturade aplicações co1porativas. 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, ver:sã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 projetas 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 BRASILEIRO (SOFTEX). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral. SOFTEX, 2009. CMMI PRODUCT TEAM. CMMI for Development, Version 1.3. Carnegie Mellon, 2010. FERNANDES, A. A. ; ABREU, V. F. Implantando a governança de TI. Brasport,

2009. HELDMAN, K. Gerência de Projetas: Guia para o Exame Oficial do PMI. CampusElsevier, 2009. IT GOVERNANCE INSTITUTE (ITGI). Control Objectives f'or 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). !TIL CONTINUAL SERVICE IMPROVEMENT, 2011 EDITION. TSO, 2011. __ .!TIL SERVI CE DESIGN, 2011 EDITION. TSO, 2011. __ .!TIL SERVI CE OPERATION, 2011 EDITION. TSO, 2011.

capitulo 5 I Referênc ias Bibliográficas

__ .!TIL SERVICE STRATEGY, 2011 EDITION. TSO, 2011. __ .!TIL SERVI CE TRANSITION, 2011 EDITION. TSO, 2011.

PROJECT M.AN.AGEMENT INSTITUTE (PMI). Um Guiado Conhecimento em Gerenciamento de Prqjetos - Guia Pmbok 4• Edü;ão. PMI, 2008.

REZENDE, D. A. Planejamento de sistemas de informação e informática. Atlas, 2007.

WEILL, P.; ROSS, J. W. Gouernan~a de TI. Makron Books, 2005.

1.5. Referências de Segurança da Informação

ABNT. ABNT NBR ISO/IEC 27002:2005- Tecnologia dalnforma~ã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 Bõoks, 2008. BAKER, F. Requirements for IP 'lkrsion 4 Routers. RFC 1812, 1995.

CGI.BR. Cartilha de Segurança para Internet. Comitê Gestor da Internet no Brasil, 2006.

CHESWICK, 'vV. R.; BELLOVIN, S. M .; RUBIN, A. D. Firewalls e Segurança na Internet. Ed. Bookman, 2005.

COUTINHO, S. C. Números Inteiros e Criptografia RS.A. IMPA/SBM, 2000.

FOROUZAN, B. A. Comunicação de Dados e R edes 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 o{.Applied Cryptography. CRC Press, 1996.

NAKAMURA, E. T.; GEUS, P. L. Segurança de Redes em Ambientes Cooperaiiuos. Novatec, 2007.

RIVEST, R.; SHAMIRA.; ADLEMAN, L . A method forobtaining 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 bystems. Bel! Systems Technical Journal, N• 4, 1949.

SHIREY, R. Internet Security Glossary, Version 2. RFC 4949, 2007.

301


302

SKOUDIS, E.; USTON, T. Counter Hack Reloaded: A Step-by-Step Guide to Computer Attacks and Effectiue Defenses. :Prentice-Hall, 2006.

STALLINGS, W. Criptografia e Segurança de Redes: Princípios e Práticas. Prentice-Hall, 2008. SZOR, P. The Art ofVirus Research and D efense. 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. S egurança em Redes Informáticas . Ed. FCA, 2010. ZWICKY, E. D.; COOPER, S.; CHAPMAN, D. B. Building Internet Firewalls. O'Rilley, 2000.

Documents

Tecnologia Da Informação - Questões Comentadas Cespeunb - Série Questões