Cespe 2010 Mpu Cargo25 Parteiv

52
Rogério Araújo Série Provas Comentadas Cargo 25 Analista de Desenvolvimento de Sistemas CESPE MPU 2010 CESPE MPU 2010 http://rogerioaraujo.wordpress.com Parte IV – PMBoK Parte IV – PMBoK

description

Cespe 2010 Mpu

Transcript of Cespe 2010 Mpu Cargo25 Parteiv

  • Rogrio Arajo

    Srie Provas Comentadas

    Cargo 25Analista de Desenvolvimento de Sistemas

    CESPE

    MPU 2010CESPE

    MPU 2010

    http://rogerioaraujo.wordpress.com

    Parte IV PMBoKParte IV PMBoK

  • Rogrio Arajo

    Srie Provas Comentadas

    Parte III ITIL

    CESPE

    MPU 2010

    http://rogerioaraujo.wordpress.com

    Cargo 25Analista de Desenvolvimento de Sistemas

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    SumrioO homem aquilo que ele prprio faz.

    Andr Malraux

    PARTE I AS QUESTES OBJETIVAS DA PROVA .................................................................... 3Captulo 1 Governana de TI .............................................................................................. 4

    1.1 Conceitos .................................................................................................. 41.2 Escritrio de projetos ................................................................................. 41.3 CobiT 4.1 ................................................................................................... 41.4 ITIL verso 3 .............................................................................................. 51.5 PMBoK 4 Edio ........................................................................................ 61.6 CMMi ......................................................................................................... 61.7 MPS.BR ....................................................................................................... 7

    Captulo 2 Contratao de Bens e Servios de TI ................................................................. 82.1 IN04 .......................................................................................................... 8

    Captulo 3 Ingls ............................................................................................................... 9Captulo 4 Desenvolvimento de Sistemas ......................................................................... 10

    4.1 Lgica de programao ............................................................................ 104.2 Programao Orientada a Objetos ............................................................ 104.3 Java ......................................................................................................... 114.4 Linguagens e tecnologias de programao ............................................... 12

    Captulo 5 Engenharia de Software ................................................................................... 145.1 Engenharia de requisitos .......................................................................... 145.2 Qualidade de Software ............................................................................. 145.3 Padres de Projetos ................................................................................. 155.4 Processo Unificado ................................................................................... 155.5 UML ......................................................................................................... 155.6 Testes de Software ................................................................................... 15

    Captulo 6 Banco de Dados .............................................................................................. 176.1 SQL .......................................................................................................... 176.2 MySQL ..................................................................................................... 18

    Captulo 7 Gabarito preliminar ......................................................................................... 19

    PARTE II A REDAO ..................................................................................................... 20Captulo 1 Comando da redao ...................................................................................... 21

    1.1 Texto de apoio ......................................................................................... 21

    Rogrio Arajo rogerioaraujo.wordpress.com 1

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    1.2 Itens a serem abordados .......................................................................... 21

    PARTE III OS COMENTRIOS DAS QUESTES OBJETIVAS .................................................. 22Captulo 1 Governana de TI ............................................................................................ 23

    1.1 Conceitos ................................................................................................ 231.2 Escritrio de projetos ............................................................................... 251.3 CobiT 4.1 ................................................................................................. 271.4 ITIL verso 3 ............................................................................................ 341.5 PMBoK 4 Edio ...................................................................................... 391.6 CMMi ........................................................................................................... 1.7 MPS.BR .........................................................................................................

    Captulo 2 Contratao de Bens e Servios de TI ................................................................... 2.1 IN04 ............................................................................................................

    Captulo 3 Ingls ................................................................................................................. Captulo 4 Desenvolvimento de Sistemas .............................................................................

    4.1 Lgica de programao ................................................................................ 4.2 Programao Orientada a Objetos ................................................................ 4.3 Java ............................................................................................................. 4.4 Linguagens e tecnologias de programao ...................................................

    Captulo 5 Engenharia de Software ....................................................................................... 5.1 Engenharia de requisitos .............................................................................. 5.2 Qualidade de Software ................................................................................. 5.3 Padres de Projetos ..................................................................................... 5.4 Processo Unificado ....................................................................................... 5.5 UML ............................................................................................................. 5.6 Testes de Software .......................................................................................

    Captulo 6 Banco de Dados .................................................................................................. 6.1 SQL .............................................................................................................. 6.2 MySQL .........................................................................................................

    PARTE IV OS COMENTRIOS DA REDAO ......................................................................... Captulo 1 Comentrios da Redao .....................................................................................

    Rogrio Arajo rogerioaraujo.wordpress.com 2

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    PARTE IAS QUESTES OBJETIVAS DA PROVA

    Rogrio Arajo rogerioaraujo.wordpress.com 3

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 1

    Governana de TIA melhor maneira de melhorar o padro de vida est em melhorar o padro de pensamento.

    U. S. Andersen

    1.1 Conceitos

    Acerca de conceitos relacionados governana de tecnologia da informao (TI), julgue os itens a seguir.

    61 As ferramentas GUT (gravidade, urgncia e tendncia), o Diagrama de Pareto e a Curva de Tendncia fornecem suporte atividade do planejamento estratgico de filtrar informaes de interesse da organizao.62 Um dos objetivos da governana de TI possibilitar o alinhamento das atividades da equipe de TI com as prioridades das demais reas de negcios da empresa.63 Os marcos de regulao, o ambiente de negcios, a transparncia da administrao e a segurana da informao so fatores que motivam o uso da governana de TI nas organizaes.

    1.2 Escritrio de projetos para Governana de TI

    Julgue os prximos itens no que se refere a escritrio de projetos para governana de TI.

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

    1.3 CobiT 4.1

    Com relao ao modelo COBIT 4.1, julgue os itens a seguir.

    67 O emprego sistemtico do COBIT como modelo de gesto da organizao pode gerar, entre outros benefcios, a reduo dos riscos a que est exposta a organizao e a melhoria de sua imagem perante os clientes.

    Rogrio Arajo rogerioaraujo.wordpress.com 4

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    68 No modelo COBIT, o conceito de agregao de valor diz respeito proposio de valor no tempo e garante que a TI entregue os benefcios prometidos com a otimizao de custos.69 A estrutura do COBIT foi idealizada para controlar, nas organizaes, os recursos de TI e os recursos humanos envolvidos nesse processo.

    Acerca de domnios, processos e objetivos de controle do modelo COBIT 4.1, julgue os itens subsequentes.

    70 No mencionado modelo, possvel haver controles especficos vinculados a aplicaes e integrados aos processos de negcio, que os suportam por meio de procedimentos relacionados, por exemplo, s interfaces do sistema.71 No COBIT, um dos processos do domnio Entrega e Suporte o de assegurar conformidade com requisitos externos.72 No modelo em apreo, o domnio Planejamento e Organizao envolve identificao, desenvolvimento e(ou) aquisio de solues para a execuo de sistemas de TI especficos, assim como a sua implementao e integrao junto a processos de negcio.73 Alguns requisitos de controle genricos so aplicveis a todos os processos do COBIT, tais como a definio e a divulgao de polticas, os procedimentos e planos relativos ao processo, e o desempenho do processo medido em relao s respectivas metas.

    1.4 ITIL v3

    Julgue os itens que se seguem a respeito de conceitos da ITIL v.3.

    74 Estratgia de servio a publicao do ncleo da ITIL v.3 que contm orientaes acerca do projeto e desenvolvimento dos servios e dos processos de gerenciamento de servios. Essa publicao apresenta, em detalhes, aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade, da disponibilidade e da segurana da informao.75 No que diz respeito ao desenvolvimento da estratgia de servio na organizao, necessrio considerar o estilo de gesto organizacional dominante na empresa, o qual pode apresentar os seguintes estgios ou nveis de maturidade: rede, diretivo, delegao, coordenao e colaborao.76 Servio a denominao dada ao meio de se entregar valor aos clientes para facilitar a obteno dos resultados desejados e minimizar os custos e riscos especficos.77 A orientao complementar ITIL v.3 consiste em um conjunto de publicaes que so destinadas a adaptar a implementao e a utilizao das prticas do ncleo da ITIL para diferentes setores empresariais, tipos de empresas e plataformas tecnolgicas.78 Entre as extenses que a ITIL v.3 traz em relao a sua verso anterior, esto estratgias de servios para modelos de sourcing e de compartilhamento de servios e abordagens de retorno de investimento para servios.

    Acerca dos processos e funes da ITIL v. 3, julgue os itens subsequentes.

    79 O processo de gerenciamento da continuidade de servio de TI do estgio desenho de servio abrange um desdobramento do processo de gerenciamento da continuidade do negcio, com o objetivo de assegurar que os recursos tcnicos e os servios de TI necessrios sejam recuperados dentro de um tempo preestabelecido.

    Rogrio Arajo rogerioaraujo.wordpress.com 5

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    80 Monitorao e controle, gerenciamento do mainframe, gerenciamento de redes e armazenamento de dados so atividades tcnicas altamente especializadas do estgio operao de servio.81 Do escopo da estratgia de servio constam os processos de gerenciamento financeiro, o de gerenciamento do portflio de servios e o de gerenciamento da demanda.

    1.5 PMBoK 4 Edio

    Julgue os itens que se seguem com relao 4. edio do PMBOK.

    82 A estimativa anloga, tambm denominada estimativa topdown, pode ser usada para prever o custo e o tempo de um projeto e leva em considerao informaes do histrico de projetos semelhantes e anteriores.83 Programas so grupos de projetos relacionados e um projeto, seja ele qual for, ser parte de um programa.84 Em uma organizao do tipo matricial forte, os gerentes de projeto tm o mais alto nvel de autoridade e poder.

    Acerca de processos e reas de conhecimento da 4.a edio do PMBOK, julgue os itens seguintes.

    85 A rea de conhecimento do gerenciamento do escopo do projeto abrange os seguintes processos: coletar os requisitos, definir o escopo, desenvolver o cronograma, verificar escopo e controlar o escopo.86 Os grupos de processos de planejamento e de monitoramento e controle servem como entrada de um para o outro reciprocamente.87 A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo realizar a anlise qualitativa de riscos, com o uso da atribuio de probabilidades numricas.88 As quatro possibilidades de trmino de projeto so absoro, integrao, esgotamento e extino.89 Os riscos desconhecidos podem representar uma ameaa ou uma oportunidade, por isso, o gerente de projeto deve manter reserva dos seus recursos para control-los quando necessrio.90 Opinio especializada, auditorias de aquisies, acordos negociados e sistema de gerenciamento de registros so recursos e tcnicas empregados no processo encerrar as aquisies.

    1.6 CMMi

    A respeito de CMMI (capability maturity model integration), julgue os itens que se seguem.

    121 Validao, verificao e integrao do produto so processos que integram a disciplina de suporte ao processo de software.122 O CMMI, que surgiu do esforo de integrao de diversos modelos que estavam sendo propostos no mercado, como, por exemplo, o SW-CMM, compatvel e consistente com o previsto em norma ISO a respeito desse assunto.

    Rogrio Arajo rogerioaraujo.wordpress.com 6

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    123 Os nveis de maturidade do CMMI variam de 0 incompleto a 5 otimizado , que mostram o grau de implementao dos processos da referida metodologia.

    1.7 MPS.BR

    Acerca de MPS.BR, julgue os itens de 124 a 128.

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

    Rogrio Arajo rogerioaraujo.wordpress.com 7

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 2

    Contratao de Bens e Servios de TIOs homens que tentam fazer algo e falham so infinitamente melhores

    do que aqueles que tentam fazer nada e conseguem.Lloyd Jones

    2.1 IN04

    Julgue os prximos itens, segundo a Instruo Normativa n. 4/2008, do MPOG, que dispe acerca do processo de contratao de servios de tecnologia da informao (TI) pela administrao pblica federal direta, autrquica e fundacional.91 O plano diretor de tecnologia da informao (PDTI) um instrumento de diagnstico e gesto dos recursos e processos de TI, que visa a atender s necessidades de informao de um rgo ou entidade para determinado perodo, sem considerar aspectos de planejamento.92 A gesto de processos de TI, incluindo a gesto de segurana da informao, no pode ser objeto de contratao.93 rea de TI considerada como uma unidade setorial ou seccional do sistema de administrao dos recursos de informao e informtica, bem como rea correlata, responsvel por gerir a TI do rgo ou entidade.94 Software pode ser entendido como um sistema ou componente constitudo por um conjunto de programas, procedimentos e documentao, desenvolvido para o atendimento de necessidades especficas do rgo ou entidade.95 Requisitos um conjunto de especificaes necessrias para definir a soluo de TI a ser contratada. Critrios de aceitao so parmetros objetivos, mas nem sempre mensurveis, utilizados para verificar um servio ou produto quanto conformidade aos requisitos especificados.

    Rogrio Arajo rogerioaraujo.wordpress.com 8

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 3

    InglsA transformao pessoal requer substituio de velhos hbitos por novos.

    W. A. Peterson

    Julgue se os itens a seguir, escritos em lngua inglesa, esto tcnica e gramaticalmente corretos.96 Whenever a new release of a software package is announced, the organization needs to buy it immediately for its own safe.97 Data warehousing technology affords types of functionality such as consolidation, aggregation, and summarization of data, which let to view the same information along multiple dimensions.98 A middleware system is one that serves as interface between other systems, so we could say that a translator program works like a middleware.99 An attribute is a special characteristic related to an entity, but not to an object.100 Information technology people know the importance of periodical backup to make possible to restore non important information.

    Rogrio Arajo rogerioaraujo.wordpress.com 9

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 4

    Desenvolvimento de SistemasSomos o que fazemos repetidamente. Por isso o mrito no est na ao e sim no hbito.

    Aristteles

    4.1 Lgica de programao

    No que se refere lgica de programao, julgue os itens a seguir.

    101 Em um algoritmo, uma expresso geralmente considerada vlida quando as suas variveis e constantes respeitam o nmero e os tipos de argumentos das operaes envolvidas.102 O mtodo de pesquisa binria de clculo de endereo empregado tanto para a pesquisa quanto para a organizao fsica de tabelas.103 A instruo x %= y, em que o operador matemtico representa uma operao aritmtica seguida de uma operao de atribuio, equivalente a x = x % y, sendo que o operador % somente pode ser utilizado com um operando do tipo inteiro.104 Se um trecho de algoritmo tiver de ser executado repetidamente e o nmero de repeties for indefinido, ento correto o uso, no incio desse trecho, da estrutura de repetio Enquanto.105 A funo predefinida fopen( ) pode ser utilizada para abrir um arquivo apenas quando esse arquivo j exista no diretrio em uso; caso contrrio, necessrio inicialmente criar o arquivo por meio da funo fcreate ( ).106 O mtodo recursivo que utiliza pilhas para executar um procedimento geralmente automtico, de modo que os compiladores podem acionar os procedimentos pr-programados para manipular essas pilhas.107 A pesquisa sequencial de uma tabela, ou seja, pela comparao do argumento da pesquisa com a chave de cada entrada, ter o desempenho reduzido se a tabela for ordenada a partir do valor da chave.

    4.2 Programao Orientada a Objetos

    A respeito da hierarquia de classes, um conceito de relevncia na programao orientada a objetos, julgue os itens que se seguem.

    129 Considere que uma classe C1 implemente determinado mtodo M1 e tenha duas subclasses: C2 e C3. Nessa situao, o comportamento de um objeto de C2 ou C3 que receba uma mensagem invocando o mtodo M1 ser obrigatoriamente idntico ao comportamento de um objeto de C1 que receba a mesma mensagem.130 Se a classe C2 uma subclasse da classe C1, todas as caractersticas que so herdadas por C2 foram definidas na classe C1 ou em alguma de suas superclasses.131 Um objeto , necessariamente, instncia de apenas uma classe, mesmo quando existe herana mltipla em uma hierarquia de classes.

    Rogrio Arajo rogerioaraujo.wordpress.com 10

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    4.3 Java

    Os programas em geral manipulam, alm de nmeros e strings, itens de dados mais complexos, que representam mais precisamente entidades no mundo real. Com relao linguagem Java, usada para projetar e manipular itens de dados complexos (objetos), julgue os itens de 137 a 139.

    137 No cdigo em Java mostrado a seguir, as classes Conta e Poupanca implementam o polimorfismo dinmico.class Conta {

    float saldo;

    public float getSaldo(int i) {float saldo = 0f;if (i == 1 ) saldo = this.saldo * 1.03f;return saldo;

    }

    public void setSaldo (float saldo) {this.saldo = saldo + 20f;

    }}

    class Poupanca extends Conta {public float getSaldo() {

    return saldo;}

    }

    138 No cdigo em Java apresentado a seguir, a tentativa de execuo da classe Principal resultar em erro, porque o objeto p1 foi criado utilizando como tipo a classe abstrata Conta.abstract class Conta {

    protected float saldo;

    public abstract float saldoConta ();public void setSaldo (float saldo) {

    this.saldo = saldo + 50f;}

    }

    class Poupanca extends Conta {

    Rogrio Arajo rogerioaraujo.wordpress.com 11

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    public float saldoConta() {return saldo;}

    }

    public class Principal {public static void main (String args[]) {

    Conta p1 = new Poupanca();((Poupanca)p1).setSaldo(450f);System.out.println("saldo : " +((Poupanca)p1).saldoConta());

    }}

    139 A tentativa de execuo do programa em Java mostrado a seguir pode resultar na indicao de uma exceo do tipo InputMismatchException.import java.util.*;public class Excecao {

    public int calculo(int n1, int n2) throws ArithmeticException {return n1/n2;

    }

    public static void main (String [] args) {Scanner sc = new Scanner(System.in);int n1, n2, res;Excecao ex = new Excecao();System.out.print("Entre o valor 1: ");n1 = sc.nextInt();System.out.print("Entre o valor 2: ");n2 = sc.nextInt();res = ex.calculo(n1,n2);System.out.println("Resultado: " + res);

    }}

    4.4 Linguagens e tecnologias de programao

    Quanto s linguagens e tecnologias de programao, julgue os itens subsequentes.140 Na arquitetura do Eclipse, verso 3.1, o workbench responsvel por administrar os recursos do usurio que so organizados em um ou mais projetos.

    Rogrio Arajo rogerioaraujo.wordpress.com 12

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    141 JavaScript uma linguagem de criao de scripts de uso geral, projetada para ser embutida em aplicativos que executam em um navegador Web. Os aplicativos Ajax so escritos em JavaScript.142 O uso de Realms no servidor de aplicao Tomcat obriga a implementao de uma poltica de segurana nesse servidor, por isso, no necessrio escrever, na aplicao, um cdigo especfico para autenticao e autorizao.143 O modelo de componentes do JBoss Seam tem como caracterstica o uso direto de componentes Enterprise JavaBeans como beans acoplados s pginas JavaServer Faces.

    Rogrio Arajo rogerioaraujo.wordpress.com 13

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 5

    Engenharia de SoftwareAs oportunidades tm tamanho para qualquer tipo de capacidade.

    Walter Grando

    5.1 Engenharia de requisitos

    Acerca de engenharia de requisitos, julgue os itens subsequentes.

    108 Embora a criao de uma sequncia ilustrada de telas por meio de programas de desenho grfico seja til para a identificao de alguns requisitos do software, ela no considerada uma atividade de prototipao por no envolver o uso de uma linguagem de programao.109 O levantamento de requisitos realizado ao final da primeira verso de um prottipo, para se definir, junto aos envolvidos no processo, quais so as premissas bsicas para o incio do entendimento das funcionalidades desejadas.110 A verificao de requisitos tem por objetivo analisar se os modelos construdos esto de acordo com os requisitos definidos. Por sua vez, a validao de requisitos visa assegurar que as necessidades do cliente esto sendo atendidas por tais requisitos.111 A especificao de requisitos permite, em determinado momento, revelar o que o sistema ir realizar no que se refere s funcionalidades, sem definir, nesse momento, como as funcionalidades sero implementadas.112 Na validao de requisitos parte integrante da especificao desses requisitos , correto o uso de diagramas da UML, tais como diagrama de classes, de casos de uso e de interao.113 Os requisitos normativos, geralmente oriundos da anlise das regras de negcio a que est submetido um sistema, nunca podem ser considerados requisitos funcionais, por estarem fora do sistema, ou seja, do domnio do negcio.

    5.2 Qualidade de Software

    Julgue os seguintes itens a respeito de qualidade de software.

    114 O nvel mximo de qualidade de um software atingido quando os stakeholders esto satisfeitos com os resultados que ele apresenta; para tanto, essencial que todos os envolvidos no processo de criao desse software faam parte da reviso de qualidade.115 Na anlise por pontos de funo (APF), as funes podem ser do tipo transao e do tipo dados. Nas funes do tipo transao, so manipulados os arquivos de interface externa (AIE) bem como os arquivos lgicos internos (ALI).116 Na fase de elaborao do RUP, so desenvolvidas as funcionalidades do sistema e implementados os requisitos identificados na fase de concepo.117 Extreme programming (XP) embasado em requisitos conhecidos, definidos de antemo, que no sofram muitas alteraes, devendo ser usado por equipes de pequeno porte, formadas por representantes de todos os stakeholders.

    Rogrio Arajo rogerioaraujo.wordpress.com 14

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    118 Produto da metodologia Scrum, o documento product backlog contm os requisitos definidos a partir da viso do cliente e utilizado novamente no final do sprint para reviso ou modificaes dos requisitos inicialmente definidos.119 O plano de garantia de qualidade de software, os documentos, padres e guias a serem utilizados, as ferramentas, tcnicas e metodologias de apoio e quem deve exercer o controle dessa qualidade esto normatizados pela ISO.120 A reviso de um projeto de software, tendo em vista a qualidade do processo de codificao, inclui, entre outros aspectos, verificar a ocorrncia de erros de ortografia, o uso adequado das convenes da linguagem e se as constantes fsicas esto corretas.

    Um processo de desenvolvimento de software contm a descrio de uma abordagem para a construo de sofware. A UML (unified modeling language) uma linguagem visual para especificar, documentar e construir os artefatos de sistemas orientados a objetos. Quanto ao ambiente de desenvolvimento de sistemas orientados a objetos, julgue os itens a seguir.

    5.3 Padres de Projetos

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

    5.4 Processo Unificado

    133 O processo unificado (PU) um processo iterativo para a anlise de projetos orientados a objetos, no qual o trabalho e as iteraes so organizados em trs fases principais: concepo, elaborao e construo.134 No PU, a elicitao de requisitos do sistema de software inicia-se na fase de concepo.

    5.5 UML

    135 Na UML, um diagrama de atividades oferece uma notao para mostrar uma sequncia de atividades, inclusive atividades paralelas. Ele pode ser aplicado em qualquer perspectiva ou propsito, no entanto, normalmente mais utilizado para a visualizao de fluxos de trabalho, processos de negcios e casos de uso.136 Na conveno de notao usada na UML, a chamada por mensagens assncronas representada no diagrama de sequncia por meio de seta cheia (no pontilhada).

    5.6 Testes de Software

    No processo de teste de software, uma das metas consiste em demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos, e outra, em descobrir falhas ou defeitos no software que apresenta comportamento incorreto. Quanto aos processos de teste de software, julgue os prximos itens.

    Rogrio Arajo rogerioaraujo.wordpress.com 15

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    144 O Junit um conjunto de classes em Java que pode ser estendido para se criar um ambiente de testes de regresso automatizado.145 O teste de integrao geralmente um processo de teste de caixa-preta no qual os testes so derivados da especificao do sistema, cujo comportamento pode ser determinado por meio do estudo de suas entradas e sadas.146 No desenvolvimento orientado a objetos embasados em componentes, os objetos e os componentes so definidos por suas interfaces e podem ser reusados em combinao com outros componentes em diferentes sistemas. Nesse caso, o teste de interfaces particularmente til, porque erros de interface em componentes compostos (formados pela combinao de componentes) no podem ser detectados por meio de testes de objetos ou componentes individuais.

    Rogrio Arajo rogerioaraujo.wordpress.com 16

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 6

    Banco de DadosDepois do fim ainda existe a possibilidade do alm.

    Walter Grando

    Considerando o modelo E-R e as tabelas acima, que representam um grupo de auditores que realizam auditorias em empresas, julgue os itens seguintes.

    6.1 SQL

    147 A execuo do comando apresentado a seguir permite listar os nomes dos auditores que auditaram mais de uma empresa.Select nome from auditor where id_aud in (select id_aud from auditoriagroup by id_aud having count(*) > 1)

    150 A execuo do comando mostrado abaixo permite listar os nomes dos auditores que auditaram todas as empresas com oramento superior a 4.000.select distinct a.nome from auditor a, auditoria b, empresa cwhere a.id_aud = b.id_aud andb.id_emp = c.id_emp and c.orcamento > 4000

    Rogrio Arajo rogerioaraujo.wordpress.com 17

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    6.7 MySQL

    148 O script a seguir permite criar, corretamente, as tabelas, no MySql 5.1, em conformidade com o modelo E-R apresentado.create table auditor (id_aud int not null primary key,nome varchar (40));

    create table empresa (id_emp int not null primary key,nome_emp varchar(30),orcamento float);

    create table auditoria (id_audit int not null primary key,id_aud int,id_emp int,dt_aud date);

    149 O tipo InnoDB, no MySql 5.1, permite estabelecer, nas tabelas, o controle de transaes para possibilitar o uso dos comandos COMMIT e ROLLBACK. Nesse caso, considerando a existncia das tabelas apresentadas em um banco de dados, a execuo dos comandos a seguir habilitar corretamente a transao nas tabelas.Alter table empresa engine=innodb;Alter table auditoria engine=innodb;Alter table auditor engine=innodb;

    Rogrio Arajo rogerioaraujo.wordpress.com 18

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 7

    Gabarito preliminarNada na vida est realmente em nossas mos...mas tudo est diante das nossas possibilidades.

    Walter Grando

    Algumas questes da prova foram posta fora de ordem neste material para que houvesse uma melhor organizao dos assuntos. Verifique com cuidado o gabarito com as questes que voc est respondendo.

    61 62 63 64 65 66 67 68 69 70 71 72 73 74 75

    C C C E C E C C E C E E C E C

    76 77 78 79 80 81 82 83 84 85 86 87 88 89 90

    C C C C C C C E E E E E C C E

    91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

    E C C E E E C C E E C E C C E

    106 107 108 109 110 111 112 113 114 115 116 117 118 119 120

    C E E E C C C E E E E E C E C

    121 122 123 124 125 126 127 128 129 130 131 132 133 134 135

    E C E E C C E C E E C E E E C

    136 137 138 139 140 141 142 143 144 145 146 147 148 149 150

    E E E C E C C C C E C C E C E

    Rogrio Arajo rogerioaraujo.wordpress.com 19

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    PARTE IIA REDAO

    Rogrio Arajo rogerioaraujo.wordpress.com 20

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 1

    Comando da redaoA primeira condio para se realizar algum coisa, no querer fazer tudo ao mesmo tempo.

    Tristo de Atade

    1.1 Texto de apoio

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

    1.2 Itens a serem abordados

    Considerando que o texto acima tem carter unicamente motivador, elabore um texto dissertativo a respeito dos modelos de maturidade CMMI e MPS.BR. Ao elaborar seu texto, atenda, necessariamente, s seguintes determinaes:

    defina o modelo CMMI, apresentando suas dimenses e abordagens; defina o MPS.BR, apresentando mtodo, nveis de maturidade e respectivas dimenses; compare os dois os modelos.

    Rogrio Arajo rogerioaraujo.wordpress.com 21

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    PARTE IIIOS COMENTRIOS DAS QUESTES

    OBJETIVAS

    Rogrio Arajo rogerioaraujo.wordpress.com 22

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Captulo 1

    Governana de TIO entusiasmo a maior fora da alma.

    Conserva-o e nunca te faltar poder para conseguir o que desejas.Napoleon Hill

    1.1 Conceitos

    Acerca de conceitos relacionados governana de tecnologia da informao (TI), julgue os itens a seguir.

    61 As ferramentas GUT (gravidade, urgncia e tendncia), o Diagrama de Pareto e a Curva de Tendncia fornecem suporte atividade do planejamento estratgico de filtrar informaes de interesse da organizao.

    ComentriosEm [1], temos que ferramentas GUT so usadas para ... definir prioridades dadas as

    diversas alternativas de ao. As ferramentas GUT aplicam-se quando necessrio priorizar aes dentro de um leque de alternativas.

    O Diagrama de Pareto [2] ... um recurso grfico utilizado para estabelecer uma ordenao nas causas de perdas que devem ser sanadas. Vilfredo Pareto calculou matematicamente que 80% da riqueza estava em mos de 20% da populao. Juran trouxe isso para a realidade da qualidade e disse que Poucas causas levam maioria das perdas, ou seja, poucas so vitais, a maioria trivial.

    No achei alguma referncia para embasar a Curva de Tendncia.Concluindo, essas ferramentas sero teis para o planejamento estratgico de uma

    organizao, portanto, a questo est certa.

    Gabarito preliminar: CERTO.

    Referncias:[1] Ferramentas GUT: novosolhos.com.br/site/arq_material/13369_14428.doc[2] Diagrama de Pareto: www.brasilacademico.com/maxpt/links_goto.asp?id=1015

    62 Um dos objetivos da governana de TI possibilitar o alinhamento das atividades da equipe de TI com as prioridades das demais reas de negcios da empresa.

    ComentriosAcreditei que essa questo estava ERRADA e Entrei com recurso com o seguinte texto:A questo em tela fala de um alinhamento de um nvel operacional (atividades de TI) com

    Rogrio Arajo rogerioaraujo.wordpress.com 23

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    um nvel estratgico (prioridades das demais reas de negcios da empresa). Segundo o modelo de governana CobiT 4.1, cita-se as cinco reas de foco da Governana de TI e uma delas o Alinhamento Estratgico que foca em garantir a ligao entre os planos de negcios e de TI, definindo, mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes da organizao.

    Pode-se perceber pela rea acima que claramente existem o alinhamento estratgico (ligao entre os planos de negcios e de TI) e o alinhamento operacional (operaes de TI com as operaes da organizao).

    A questo em tela no traz essa distino, induzido o candidato ao erro, portanto, pede-se ANULAO da questo.

    Resumindo, a questo, no meu entendimento, trouxera um alinhamento operacional (atividades de TI) com alinhamento estratgico (prioridades das demais reas de negcio da empresa). Isso, para mim, est errado por conta que temos o alinhamento estratgico entre os planos da TI e da organizao e o alinhamento operacional entre as operaes de TI e operaes da organizao.

    Entretanto, com ajuda de um colega que comentou o material, Eliziomar, ele citou o seguinte trecho do livro do Aragon [2]:

    Alinhar e priorizar as iniciativas de TI com a estratgica do negcio: Isto significa que o que foi planejado para acontecer deve priorizado, tendo em vista as

    prioridades do negcio e as restries de capital de investimento; A priorizao gera um portflio de TI, que faz a ligao entre a estratgia e as aes do

    dia-dia.Ou seja, as aes do dia a dia da TI est ligada estratgia do negcio por meio de um

    portflio de TI que ... um instrumento para priorizao dos investimentos de TI com base no retorno de projetos e ativos para a organizao, e no seu alinhamento com os objetivos estratgicos do negcio.

    Portanto, a questo realmente est certa.

    Gabarito preliminar: CERTO.

    Referncia:[1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf[2] Implantando a Governana de TI, 2 Edio.

    63 Os marcos de regulao, o ambiente de negcios, a transparncia da administrao e a segurana da informao so fatores que motivam o uso da governana de TI nas organizaes.

    ComentriosEm [1], os fatores que motivam a Governana de TI so: Ambiente de Negcios; Marcos Reguladores; Segurana da Informao

    Rogrio Arajo rogerioaraujo.wordpress.com 24

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Dependncia do Negcio em relao TI; e Integrao Tecnolgica.Aragon [2] cita mais um alm dos que esto em cima: TI como prestadora de servios.Fiquei com dvida no fator transparncia da administrao, pois no encontrei nenhuma

    fonte para confirm-lo como fator de motivao da Governana de TI.

    Gabarito preliminar: CERTO.

    Referncias:[1] Mapeamento dos processos baseado em controle para Governana de Tecnologia da Informao: http://www.bibliotecadigital.puc-campinas.edu.br/tde_busca/arquivo.php?codArquivo=240[2] Implantando a Governana de TI, 2 Edio.

    1.2 Escritrio de projetos para Governana de TI

    Julgue os prximos itens no que se refere a escritrio de projetos para governana de TI.

    64 Entre as dificuldades encontradas na implantao de um escritrio de projetos, incluem-se as relacionadas mensurao e ao acompanhamento dos benefcios de um projeto, presso por resultados em curto prazo e definio da metodologia a ser utilizada.

    ComentriosA questo trouxe algumas dificuldades na implantao de um PMO. Dificuldades essas

    relacionadas: mensurao e ao acompanhamento dos benefcios de um projeto; presso por resultados em curto prazo; e definio da metodologia a ser utilizada.Em [1], h algumas dificuldades parecidas com as da questo: Baixa Credibilidade; Resistncia a Mudanas; Dificuldade de mensurao e acompanhamento dos benefcios em um projeto (valor

    agregado); Necessidade de formalizao; e Presso por resultados em curto prazo.O examinador colocou a definio da metodologia a ser utilizada como uma dificuldade na

    implantao de um PMO, entretanto no uma dificuldade e sim uma atribuio de um escritrio de projeto. No Guia PMBoK (4 Edio) [2], existem algumas atribuies para um PMO (sigla de Escritrio de Gerenciamento de Projetos em ingls), tais como:

    Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO;

    Identificao e desenvolvimento de metodologia, melhores prticas e padres de gerenciamento de projetos;

    Rogrio Arajo rogerioaraujo.wordpress.com 25

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Orientao, aconselhamento, treinamento e superviso; Monitoramento da conformidade com as polticas, procedimentos e modelos padres de

    gerenciamento de projetos por meio de auditorias do projeto; Desenvolvimento e gerenciamento de polticas, procedimentos, formulrios e outras

    documentaes compartilhadas do projeto (ativos de processos organizacionais) e Coordenao das comunicaes entre projetos.

    Gabarito preliminar: ERRADO.

    Referncias:[1] Escritrio de Projetos: www.amcham.com.br/download/informativo2005-05-20a_arquivo[2] Guia PMBoK (4 Edio).

    65 Um escritrio de projetos pode se implantado em qualquer tipo de estrutura organizacional funcional, matricial ou por projeto e ele pode ter autoridade para supervisionar e cancelar projetos.

    ComentriosEsse verbo PODER que o CESPE utiliza pode tudo. Brincadeiras parte, essa questo est correta [1]:Um PMO poder auxiliar o gerente de projetos na garantia do atendimento aos quesitos

    acima e tambm poder contribuir na busca pela excelncia em gerenciamento de projetos, mesmo o instituto apresentando uma estrutura matricial fraca, uma vez que um PMO pode ser implantado em qualquer estrutura organizacional. (Grifo meu)

    Fiquei com dvida sobre a autoridade do escritrio de projeto para supervisionar e cancelar projetos dentro de uma estrutura funcional, marcando assim errado na questo. Entretanto, pesquisando para sanar a dvida, encontrei [2] que Um PMO pode existir em qualquer uma das estruturas organizacionais, inclusive nas que apresentam uma organizao funcional... (Grifo meu).

    E para fechar a dvida, ainda no [2]: A funo de um PMO em uma organizao pode variar de uma assessoria, limitada recomendao de polticas e procedimentos especficos sobre projetos individuais, at uma concesso formal de autoridade pela gerncia executiva.

    Gabarito preliminar: CERTO.

    Referncias:[1] O apoio de um PMO na gesto de manuteno de software: http://www.ici.curitiba.org.br/Multimidia/Documento/Artigos/ArtigoMBA_Ursula.pdf[2] Influncias organizacionais: http://www.tenstep.com.br/br/TenStepPB/open/2.3.htm

    66 O escritrio de projetos de uma organizao tem, entre outras, as seguintes atribuies: padronizao de processos de suporte a projetos, treinamento de pessoal, gerenciamento de recursos e elaborao do plano estratgico da organizao.

    Rogrio Arajo rogerioaraujo.wordpress.com 26

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    ComentriosDiferentemente da questo 64 que citava algumas dificuldades na implantao de um PMO,

    a questo em tela trouxe algumas atribuies desse tipo de escritrio. Nosso trabalho, como sempre, analisar cada item para encontrar algum erro.

    Iremos ento fazer um paralelo entre as atribuies trazidas nesta questo com as atribuies j descritas na questo 64:

    Padronizao de processos de suporte a projetos: atribuio certa, pois bate com a Identificao e desenvolvimento de metodologia, melhores prticas e padres de gerenciamento de projetos;

    Treinamento de pessoal: bate com a atribuio Orientao, aconselhamento, treinamento e superviso;

    Gerenciamento de recursos: acredito que aqui teria um erro, pois existe o gerenciamento de recurso DE UM NICO PROJETO, gerenciamento esse feito pelo gerente de projetos, e o gerenciamento de recursos ENTRE PROJETOS, feito pelo escritrio de projetos (Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO); e

    Elaborao do plano estratgico da organizao: outro erro, pois um escritrio de projeto no ser responsvel pelo planejamento estratgico da organizao.

    Gabarito preliminar: ERRADO.

    Referncia:[1] Guia PMBoK (4 Edio).

    1.3 CobiT 4.1

    Com relao ao modelo COBIT 4.1, julgue os itens a seguir.

    67 O emprego sistemtico do COBIT como modelo de gesto da organizao pode gerar, entre outros benefcios, a reduo dos riscos a que est exposta a organizao e a melhoria de sua imagem perante os clientes.

    ComentriosEssa questo sai muito por tabela. Com uma viso superficial dos conceitos do CobiT,

    podemos chegar concluso de que a questo est certa.Em [1], cita-se que o CobiT oferece boas prticas utilizando um modelo de domnio (Planejar

    e Organizar; Adquirir e Implementar; Entregar e Suportar e Monitorar e Avaliar) e processos (ao todo, so 34 processos). Essas boas prticas iro ajudar a organizao a:

    Otimizar os investimentos em TI; Assegurar a entrega dos servios; e Prover mtricas para julgar quando as coisas saem erradas.Outro ponto importante tambm descrito em [1] que pode corroborar a questo fato de

    que o CobiT um modelo e uma ferramenta de suporte que permite aos gerentes suprir as deficincias com respeito aos requisitos de controle, questes tcnicas e riscos de negcios, comunicando esse nvel de controle s partes interessadas.

    Rogrio Arajo rogerioaraujo.wordpress.com 27

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Aragon [2] (depois dos comentrios dessa prova, vou cobrar dele um percentual de indicao do seu livro, se ainda houver no mercado ) traz alguns benefcios ao se utilizar sistematicamente o CobiT, entre os quais, existem os seguintes:

    Reduo de exposio a riscos; Melhoria da imagem perante os clientes, atravs do aumento do grau de satisfao e da

    confiabilidade em relao aos servios de TI.Portanto, sem menor dvida da fonte da questo, ela est certa.Aproveitando, gostaria de trazer tambm os benefcios citados em [1] que so alcanados ao

    implementar o CobiT como modelo de governana de TI: Um melhor alinhamento baseado no foco do negcio; Uma viso clara para os executivos sobre o que TI faz; Uma clara diviso das responsabilidades baseada na orientao para processos; Aceitao geral por terceiros e rgos reguladores; Entendimento compreendido entre todas as partes interessadas, baseado em uma

    linguagem comum; Cumprimento dos requisitos do COSO para controle do ambiente de TI.

    Gabarito preliminar: CERTO.

    Referncias:[1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf[2] Implantando a Governana de TI, 2 Edio.

    68 No modelo COBIT, o conceito de agregao de valor diz respeito proposio de valor no tempo e garante que a TI entregue os benefcios prometidos com a otimizao de custos.

    ComentriosExistem cinco reas de foco na governana de TI [1]: Alinhamento estratgico: foca em garantir a ligao entre os planos de negcios e de TI,

    definindo, mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes da organizao;

    Entrega de valor: a execuo da proposta de valor de IT atravs do ciclo de entrega, garantindo que TI entrega os prometidos benefcios previstos na estratgia da organizao, concentrado-se em otimizar custos e provendo o valor intrnseco de TI;

    Gesto de recursos: refere-se melhor utilizao possvel dos investimentos e o apropriado gerenciamento dos recursos crticos de TI: aplicativos, informaes, infraestrutura e pessoas. Questes relevantes referem-se otimizao do conhecimento e infraestrutura;

    Gesto de risco: requer a preocupao com riscos pelos funcionrios mais experientes da corporao, um entendimento claro do apetite de risco da empresa e dos requerimentos de conformidade, transparncia sobre os riscos significantes para a organizao e insero do gerenciamento de riscos nas atividades da companhia;

    Mensurao de desempenho: acompanha e monitora a implementao da estratgia, trmino do projeto, uso dos recursos, processo de performance e entrega dos servios,

    Rogrio Arajo rogerioaraujo.wordpress.com 28

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    usando, por exemplo, balanced scorecards que traduzem as estratgias em aes para atingir os objetivos, medidos atravs de processos contbeis convencionais.

    A questo citou Agregao de Valor ao invs de Entrega de Valor, como visto acima. A soluo da questo vem (adivinhem!) do Aragon [2].

    O autor tambm cita as cinco reas, porm chama a rea Entrega de valor como Agregao de Valor e diz o seguinte sobre essa rea: execuo de proposio de valor atravs do tempo, assegurando que a TI entregue os benefcios prometidos de acordo com a estratgia, concentrando-se em otimizar custos e em comprovar o valor intrnseco da TI.

    Com base no pargrafo anterior, confirmamos que a questo est correta.

    Gabarito preliminar: CERTO.

    Referncias:[1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf[2] Implantando a Governana de TI, 2 Edio.

    69 A estrutura do COBIT foi idealizada para controlar, nas organizaes, os recursos de TI e os recursos humanos envolvidos nesse processo.

    ComentriosPara sabermos um pouco sobre a histria do CobiT, acompanhem a tabela abaixo [1]:

    Ano Edio Evoluo

    1994 Primeira VersoA ISACA (Information System Audit and Control Association - www.isaca.org) lana um conjunto de objetivos de controle para as aplicaes de negcio.

    1998 Segunda Verso Inclui uma ferramenta de suporte implementao e a especificao de objetivos de controle de alto nvel e detalhados.

    2000 Terceira Verso Inclui normas e guias associadas gesto. O ITGI (IT Governance Institute - www.itgi.org) torna-se o principal editor do framework.

    2005 Quarta Verso Melhoria dos controles para assegurar a segurana e a disponibilidade dos ativos de TI na organizao.

    2007 Verso 4.1Segundo Aragon [2], o foco dessa verso foi ... orientado a uma maior eficcia dos objetivos e dos processos de verificao e divulgao de resultados.

    Tabela 1: Evoluo do CobiT.

    Importante destacar que em 2002 foi lanada a lei Sarbanes-Oxley Act. Este acontecimento teve um impacto significativo na adoo do CobiT nos EUA e nas empresas globais que l atuam.

    Portanto, a questo est errada porque a verso original do modelo de governana em tela era um conjunto de objetivos de controle para aplicaes de negcios.

    Gabarito preliminar: ERRADO.

    Rogrio Arajo rogerioaraujo.wordpress.com 29

    http://www.itgi.org/

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Referncias:[1] Gesto de Portaflio e Gerncia de Projetos no CobiT: http://www.pmidf.org/encontrogp/palestras/joaosouza.pdf[2] Implantando a Governana de TI, 2 Edio.

    70 No mencionado modelo, possvel haver controles especficos vinculados a aplicaes e integrados aos processos de negcio, que os suportam por meio de procedimentos relacionados, por exemplo, s interfaces do sistema.

    ComentriosEsse modelo, como dito antes, oferece boas prticas e essas so fortemente focadas mais

    nos controles e menos na execuo [1].CobiT possui quatro principais caractersticas e uma delas justamente ser Baseado em

    controles. As outras caractersticas so: Focado em negcios; Orientado a processos; e Orientado por medies.Cada processo de TI citado no CobiT possui uma descrio de processo e vrios objetivos de

    controle detalhados. Tambm temos requisitos de controle genricos (veremos esses requisitos de na questo 73) aplicveis a todos os processos. Alm desses, temos os controles de aplicativos que so controles inseridos nos aplicativos de processos de negcios:

    AC1 Preparao e Autorizao de Dados Originais; AC2 Entrada e Coleta de Dados Fontes; AC3 Testes de Veracidade, Totalidade e Autenticidade; AC4 Processamento ntegro e Vlido; AC5 Reviso das Sadas, Reconciliao e Manuseio de Erros; AC6 Autenticao e Integridade das Transaes.Pelo texto da questo, o examinador novamente utilizou o Aragon [2]. Esse autor diz que o

    AC 6 se refere Interface apenas, no informando ser interface com o usurio ou entre aplicativos.

    Entrei com recurso nessa questo com o seguinte texto:No CobiT, existe o controle de aplicao AC6 que diz:AC6 Autenticao e Integridade das TransaesAntes de transportar os dados das transaes entre os aplicativos e as funes de

    negcios/operacionais (internas ou externas organizao), verifica endereamento adequado, autenticidade da origem e integridade do contedo. Mantm a autenticidade e integridade durante a transmisso ou transporte.

    O AC6 fala do transporte os dados das transaes entre os aplicativos e as funes de negcios/operacionais, o que podemos induzir que o termo interfaces que o autor [ARAGON, 2008] cita seria interfaces ENTRE sistemas e funes. A questo em tela fala interfaces DO sistema, o que no certo, pois esse termo est diferente do que o AC6 prope.

    Portanto, pela concluso acima, pede-se ANULAO ou mudana do gabarito para ERRADO.

    Rogrio Arajo rogerioaraujo.wordpress.com 30

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf [ARAGON, 2008] Implantando a Governana de TI, 2 Edio - 2008.

    No sei se fui muito precioso nessa questo. Vamos esperar o gabarito definitivo.

    Gabarito preliminar: CERTO.

    Referncias:[1] CobiT 4.1: http://www.isaca.org/Knowledge-Center/cobit/Documents/cobit41-portuguese.pdf[2] Implantando a Governana de TI, 2 Edio.

    71 No COBIT, um dos processos do domnio Entrega e Suporte o de assegurar conformidade com requisitos externos.

    ComentriosEssa uma das questes que no podemos mais perder, at porque a forma da pergunta (se

    um processo pertence a um determinando domnio) corriqueira nas provas atuais do CESPE.A questo citou o processo ME3 Assegurar a Conformidade com Requisitos Externos. Esse

    processo do domnio Monitorar e Avaliar.Os demais processos do domnio citado esto na figura 1.

    Galera, apenas peo pacincia pela imagem do processo ME3. Procurei muito por uma figura que pudesse se encaixar no nome do processo, entretanto, no encontrei nada. Ento, como vi essa imagem de uma mo segurando uma casa, pensei em us-la para lembrar da palavra Assegurar.

    Nota 1: O porqu do uso da imagem para o processo ME Assegurar a Conformidade com Requisitos Externos.

    Rogrio Arajo rogerioaraujo.wordpress.com 31

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Figura 1: Processos do Domnio Monitorar e Avaliar.

    Gabarito preliminar: ERRADO.

    72 No modelo em apreo, o domnio Planejamento e Organizao envolve identificao, desenvolvimento e(ou) aquisio de solues para a execuo de sistemas de TI especficos, assim como a sua implementao e integrao junto a processos de negcio.Comentrios

    No disse que est ficando corriqueiro esse tipo de questo? O que est descrito na questo muito voltado para o domnio de Adquirir e Implementar

    (figura 2).

    Rogrio Arajo rogerioaraujo.wordpress.com 32

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Figura 2: Processos do domnio Adquirir e Implementar.

    Gabarito preliminar: ERRADO.

    73 Alguns requisitos de controle genricos so aplicveis a todos os processos do COBIT, tais como a definio e a divulgao de polticas, os procedimentos e planos relativos ao processo, e o desempenho do processo medido em relao s respectivas metas.

    ComentriosComo vimos na questo 70, cada processo de TI citado no CobiT possui uma descrio de

    processo e vrios objetivos de controle detalhados. Tambm temos requisitos de controle genricos aplicveis a todos os processos, identificados por PC(n):

    PC1 Metas e Objetivos do Processo; PC2 Propriedade dos Processos; PC3 Repetibilidade dos Processos; PC4 Papis e Responsabilidades; PC5 Polticas Planos e Procedimentos; e PC6 Melhoria do Processo de Performance.A questo citou alguns da lista de cima: Definio e a divulgao de polticas, os procedimentos e planos relativos ao processo:

    PC5 que trata da definio e comunicao de como todas as polticas, planos e procedimentos que direcionam os processos de TI so documentados, revisados, mantidos, aprovados, armazenados, comunicados e utilizados para treinamento; e

    Desempenho do processo medido em relao s respectivas metas: PC6 que trata da identificao de um conjunto de mtricas que fornecem direcionamento para os resultados e performance dos processos.

    Rogrio Arajo rogerioaraujo.wordpress.com 33

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Gabarito preliminar: CERTO.

    1.4 ITIL v3

    Julgue os itens que se seguem a respeito de conceitos da ITIL v.3.

    74 Estratgia de servio a publicao do ncleo da ITIL v.3 que contm orientaes acerca do projeto e desenvolvimento dos servios e dos processos de gerenciamento de servios. Essa publicao apresenta, em detalhes, aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade, da disponibilidade e da segurana da informao.

    ComentriosO examinador quis deixar a questo errada ao jogar a descrio da publicao de Desenho

    de Servio para a de Estratgia de Servio. Resumidamente, as publicaes do ITIL v3 so formadas pela sigla ED TOM [1]:

    Estratgia de Servio: orienta sobre como as polticas e processos de gerenciamento de servio podem ser desenhados, desenvolvidos e implementados como ativos estratgicos ao longo do ciclo de vida de servio;

    Desenho de Servio: fornece orientao para o desenho e desenvolvimento dos servios e dos processos de gerenciamento de servios, detalhando aspectos do gerenciamento do catlogo de servios, do nvel de servio, da capacidade da disponibilidade, da continuidade, da segurana da informao e dos fornecedores, alm de mudanas e melhorias necessrias para manter ou agregar valor aos clientes ao longo do ciclo de vida de servio;

    Transiro de Servio: orienta sobre como efetivar a transio de servios novos e modificados para operaes implementadas, detalhando os processos de planejamento e suporte transio, gerenciamento de mudanas, gerenciamento da configurao e dos ativos de servio, gerenciamento de liberao e da distribuio, teste e validao de servio, avaliao e gerenciamento do conhecimento;

    Operao de Servio: descreve a fase do ciclo de vida do gerenciamento de servios que e responsvel pelas atividades do dia-a-dia, orientando sobre como garantir a entrega e o suporte a servios de forma eficiente e eficaz, e detalhando os processos de gerenciamento de eventos, incidentes, problemas, acesso e de execuo de requisies; e

    Melhoria de Servio Continuada: orienta, atravs de princpios, prticas e mtodos do gerenciamento da qualidade, sobre como fazer sistematicamente melhorias incrementais e de larga escala na qualidade dos servios, nas metas de eficincia operacional, na continuidade dos servios etc., com base no modelo PDCA preconizado pela ISO/IEC 20000.

    Para finalizar, a tabela 2 mostra a publicaes e seus os processos e funes, esses se houver. Utilizei o material do Thiago Fagury [2] como referncia.

    Rogrio Arajo rogerioaraujo.wordpress.com 34

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Publicao Processos Funes

    Estratgia de Servio

    Gerenciamento Financeiro de TI Gerenciamento de Portflio de Servios Gerenciamento de Demanda Gerao da Estratgia

    Desenho de Servio

    Gerenciamento do Catlogo de Servios Gerenciamento de Nvel de Servio Gerenciamento da Disponibilidade Gerenciamento da Capacidade Gerenciamento da Continuidade de Servio Gerenciamento de Segurana da Informao Gerenciamento de fornecedor

    Transio de Servio

    Gerenciamento de Mudana Gerenciamento da Configurao e de Ativo de

    Servio Gerenciamento do Conhecimento Planejamento e Suporte da Transio Gerenciamento de Liberao e Implantao Validao de Servio e Testes Avaliao

    Operao de Servio

    Gerenciamento de Incidente Gerenciamento de Eventos Cumprimento de Requisies Gerenciamento de Acesso Gerenciamento de Problemas

    Central de Servios Gerenciamento Tcnico Gerenciamento de Aplicaes Gerenciamento de Operaes

    de TIMelhoria de

    Servio Continuada

    Melhoria em 7 passos Mensurao de Servios Elaborao de relatrios de servios

    Tabela 2: Publicaes, Processos e Funes do ITIL v3.

    Sobre os processos e funes acima: H processos corretamente citados pelo Thiago e os quais no esto no livro do Aragon:

    Gerao da Estratgia da Estratgia de Servio; Planejamento e Suporte da Transio da Estratgia de Servio; e Melhoria em 7 passos da Melhoria de Servio Continuada.

    Segundo o Thiago, na Transio de Servio h processos que permeiam todo o ciclo de vida: Gerenciamento de Mudana; Gerenciamento da Configurao e de Ativo de Servio; e Gerenciamento do Conhecimento.

    Apenas na publicao Operao de Servios existem funes.

    Observao 1: Itens importantes a serem considerados na tabela 2.

    Gabarito preliminar: ERRADO.

    Rogrio Arajo rogerioaraujo.wordpress.com 35

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Referncias:[1] Implantando a Governana de TI, 2 Edio.[2] Apostila Itil V3 (Primeira Verso): http://fagury.com.br/sys/wp-content/uploads/2010/09/apostila-itil-v3-3.pdf

    75 No que diz respeito ao desenvolvimento da estratgia de servio na organizao, necessrio considerar o estilo de gesto organizacional dominante na empresa, o qual pode apresentar os seguintes estgios ou nveis de maturidade: rede, diretivo, delegao, coordenao e colaborao.

    ComentriosAragon [1] cita que o desenvolvimento da estratgia deve levar em considerao o estilo de

    gesto organizacional mais adequada para o servio. Os estilos podem ser representados em estgio, algo parecido com nveis de maturidade:

    Estgio 1 (Rede): entrega de servio rpida, informal e sob demanda. O desafio a Liderana;

    Estgio 2 (Diretivo): equipe habilidosa em gesto para dirigir a estratgia e gerente com responsabilidades funcionais. O desafio a Autonomia; e

    Estgio 3 (Delegao): mais poder aos gerentes. O desafio o Controle; Estgio 4 (Coordenao): uso de sistemas formais para melhorar a coordenao. O

    desafio o Burocracia; Estgio 5 (Colaborao): forte sintonia com o negcio, maior flexibilidade, com gerentes

    altamente habilitados em trabalho de equipe e resoluo de controle.A figura 3 [2] mostra graficamente os estgios acima.

    Figura 3: Estgios do desenvolvimento organizacional.Rogrio Arajo rogerioaraujo.wordpress.com 36

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Gabarito preliminar: CERTO.

    Referncias:[1] Implantando a Governana de TI, 2 Edio.[2] Office of Government Commerce (OGC). ITIL Version 3 - Service Strategy. Editora: Stationery Office BO. Ano: 2007. Edio: 1. http://www.best-management-practice.com/officialsite.asp?FO=1245521&ProductID=9780113310456&Action=Book

    76 Servio a denominao dada ao meio de se entregar valor aos clientes para facilitar a obteno dos resultados desejados e minimizar os custos e riscos especficos.

    Comentrios

    Supondo irmos a um restaurante, ns vamos pela comida e pelo atendimento (Servio). Ao chegarmos, somos bem atendidos e recebemos um cardpio (Catlogo de Servios). Fazemos nosso pedido e esperamos. O chefe da cozinha (Pessoa) saber como fazer nosso prato (Habilidade), utilizando os ingredientes necessrios na medida certa (Recursos).

    Tudo isso acontece sem nos envolvermos nesse processo. Ora, se temos que nos envolver, por que vamos sair de casa para ter trabalho e ainda pagar por isso?

    Exemplo 1: Analogia da definio de Servio do curso de ITIL v3 do TI Exames [1].

    Ento o que seria um servio? Em [2], um servio um meio de entregar valor aos clientes, facilitando o alcance nos resultados que eles querem SEM que esses participem dos custos e riscos especficos.

    A questo citou a minimizao dos custos e riscos especficos, entretanto, ela est errada ao dizer isso, pois, mesmo com a minimizao, ainda existem esses custos e riscos. O gabarito preliminar foi dado como certo, porm, vamos esperar pelo definitivo.

    Gabarito preliminar: CERTO.

    Referncias:[1] Fundamentos no Gerenciamento de Servios de TI com base na ITIL v3: http://tiexames.com.br/curso_itil_v3_foundation.php[2] Office of Government Commerce (OGC). ITIL Version 3 - Service Strategy. Editora: Stationery Office BO. Ano: 2007. Edio: 1. http://www.best-management-practice.com/officialsite.asp?FO=1245521&ProductID=9780113310456&Action=Book

    77 A orientao complementar ITIL v.3 consiste em um conjunto de publicaes que so destinadas a adaptar a implementao e a utilizao das prticas do ncleo da ITIL para diferentes setores empresariais, tipos de empresas e plataformas tecnolgicas.

    ComentriosA ITIL possui dois componentes: Ncleo da ITIL que composto pelas 5 publicaes ED TOM

    e Orientao Complementar ITIL.Aragon [1] cita:

    Rogrio Arajo rogerioaraujo.wordpress.com 37

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Orientao Complementar ITIL: Conjunto de publicaes complementares destinadas a especializar a implementao e a utilizao das prticas do Ncleo para diferentes setores empresariais, tipos de empresas, plataformas tecnolgicas etc., concebido para ser uma biblioteca dinmica de contedo relacionado, podendo receber contribuies de toda a comunidade.Gabarito preliminar: CERTO.

    Referncias:[1] Implantando a Governana de TI, 2 Edio.

    78 Entre as extenses que a ITIL v.3 traz em relao a sua verso anterior, esto estratgias de servios para modelos de sourcing e de compartilhamento de servios e abordagens de retorno de investimento para servios.

    ComentriosNovamente, como referncia, cita-se o Aragon [1] que diz que entre as extenses que a ITIL

    V3 traz em relao verso anterior esto: Estratgias de servios para modelos de sourcing e de compartilhamento de servios; Abordagens de retorno sobre o investimento (ROI) para servios; Prticas de desenho de servios; Um sistema de gerenciamento de conhecimento sobre os servios; e Gerenciamento de requisies.

    Gabarito preliminar: CERTO.

    Referncias:[1] Implantando a Governana de TI, 2 Edio.

    Acerca dos processos e funes da ITIL v. 3, julgue os itens subsequentes.

    79 O processo de gerenciamento da continuidade de servio de TI do estgio desenho de servio abrange um desdobramento do processo de gerenciamento da continuidade do negcio, com o objetivo de assegurar que os recursos tcnicos e os servios de TI necessrios sejam recuperados dentro de um tempo preestabelecido.

    ComentriosAo responder essa questo, temos que ter cuidado em dois pontos: Se o processo de Gerenciamento da Continuidade de Servio de TI se encontra na

    publicao do Desenho de Servio; e Se a descrio mesmo desse processo.O primeiro ponto est certo. Basta ver a tabela 2 da questo 74.Agora, vamos ver se o segundo ponto est ok. A quem podemos recorrer para conferir esse

    ponto? Isso! Aragon [1]! Ele descreve que o Gerenciamento de Continuidade de Servio de TI ... visa assegurar que todos os recursos tcnicos e servios de TI necessrios .... possam ser

    Rogrio Arajo rogerioaraujo.wordpress.com 38

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    recuperados dentro de um tempo preestabelecido.

    Gabarito preliminar: CERTO.

    Referncias:[1] Implantando a Governana de TI, 2 Edio.

    80 Monitorao e controle, gerenciamento do mainframe, gerenciamento de redes e armazenamento de dados so atividades tcnicas altamente especializadas do estgio operao de servio.

    ComentriosAragon [1] fala sobre Atividades comuns da Operao de Servio. A publicao de Operao

    de Servio, alm de processos e funes, h um conjunto de atividades tcnicas que so altamente especializados. O objetivo dessas atividades garantir que a tecnologia requerida para a entrega e o suporte aos servios esteja funcionando em perfeito estado.

    Como exemplo dessas atividades, temos: Monitorao e controle; Gerenciamento do mainframe; Gerenciamento de redes; e Armazenamento de dados.

    Gabarito preliminar: CERTO.

    Referncias:[1] Implantando a Governana de TI, 2 Edio.

    81 Do escopo da estratgia de servio constam os processos de gerenciamento financeiro, o de gerenciamento do portflio de servios e o de gerenciamento da demanda.

    ComentriosPara responder essa questo, basta ver a tabela 2 da questo 74.Lembrando que, como dissemos na questo 74, o processo Gerao da Estratgia tambm

    faz parte da publicao de Estratgia de Servio.

    Gabarito preliminar: CERTO.

    Rogrio Arajo rogerioaraujo.wordpress.com 39

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    1.5 PMBoK 4 Edio

    Julgue os itens que se seguem com relao 4. edio do PMBOK.

    82 A estimativa anloga, tambm denominada estimativa top-down, pode ser usada para prever o custo e o tempo de um projeto e leva em considerao informaes do histrico de projetos semelhantes e anteriores.

    ComentriosDois pontos podem levar o candidato ao erro nessa questo: A estimativa anloga tambm pode ser denominada top-down? Essa tcnica pode ser usada para prever o custo e tempo de um projeto?Quanto ao primeiro ponto, o Guia do PMBok 4 Edio no diz nada sobre a outra forma de

    denominao. Fui encontrar a resposta na verso do ano 2000 do mesmo Guia:Estimativas por analogia. Nas estimativas por analogia, tambm chamadas de estimativas

    de cima para baixo (top-down), usam-se os valores reais de duraes de projetos anteriores ou similares para estimar a durao de uma atividade futura. Ela freqentemente utilizada para estimar a durao do projeto quando existe uma quantidade limitada de informaes detalhadas sobre ele (por exemplo, nas fases iniciais do projeto). Estimativas por analogia so uma forma de avaliao especializada. (Grifo meu)

    Essa questo bem que poderia ser anulada pelo fato de que a verso mais atual do Guia no haver essa denominao top-down.

    Agora vamos ao segundo ponto! Prever o custo e o tempo de um projeto! Antes de irmos ao embate do prever versus estimar, quero informar que a tcnica citada pela questo usada tanto no processo de Estimar custos do Gerenciamento de Custos quanto no processo de Estimar as duraes das atividades do Gerenciamento de Tempo.

    Beleza! Voltamos ao embate. Pesquisando pelo significado de cada termo, temos: Prever [1]: ver com antecipao; antever; prognosticar; e Estimar [2]: determinar o valor de uma coisa, avaliar, calcular (o preo, a quantidade).Na minha opinio, a questo deveria vir com estimar e no prever. Ao usar esse termo,

    tem-se a impresso de que a tcnica citada dar ao gerente o poder de antever com preciso o custo e o tempo de um projeto, o que nem sempre se consegue. Como diz o prprio Guia do PMBoK: um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. Mesmo que um gerente j tenha feito uma casa de um conjunto habitacional (um projeto de produto exclusivo), por exemplo, fazer outra do mesmo conjunto (outro projeto de projeto exclusivo) pode no ter o mesmo custo e tempo do projeto anterior, pois o terreno pode ser diferente, podem no existir mo-de-obra disponvel, os preos dos itens de construo podem ter aumentado de preos, etc.

    Ento mais fcil estimar do que prever, penso eu, humildemente.

    Gabarito preliminar: CERTO.

    Referncias:[1] Significado de Prever: http://www.dicio.com.br/prever/[2] Significado de Estimar: http://www.dicio.com.br/estimar/

    Rogrio Arajo rogerioaraujo.wordpress.com 40

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    83 Programas so grupos de projetos relacionados e um projeto, seja ele qual for, ser parte de um programa.

    ComentriosNo mundo dos projetos, temos [1]: Projeto: esforo temporrio empreendido para criar um produto, servio ou resultado

    exclusivo; Programa: grupo de projetos relacionados gerenciados de modo coordenado para a

    obteno de benefcios e controle que no estariam disponveis se eles fossem gerenciados individualmente; e

    Portflio: conjunto de projetos ou programas e outros trabalhos, agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos de negcios estratgicos. Os projetos ou programas do portflio podem no ser necessariamente interdependentes ou diretamente relacionados.

    Como vemos, no todo projeto que pode fazer parte de um programa. Um projeto ter que ser NECESSARIAMENTE relacionado com os outros contidos no programa.

    J em um portflio, podem existir projetos que no so necessariamente relacionados. Talvez o examinador pensou nessa diferena entre programas e portflios para pregar-nos a famosa pegadinha do malandro! R!

    Outro ponto interessante sobre programas e portflios que aqueles, os programas, tero apenas projetos enquanto esses podero ter de projetos ou programas e outros trabalhos.

    Gabarito preliminar: ERRADO.

    Referncias:[1] Guia do PMBok 4 Edio.

    84 Em uma organizao do tipo matricial forte, os gerentes de projeto tm o mais alto nvel de autoridade e poder.

    ComentriosDe acordo com a estrutura organizacional, a autoridade e poder de um gerente de projetos

    podero variar. O Guia do PMBok 4 Edio traz cinco tipos de estruturas conforme a tabela 3.

    Rogrio Arajo rogerioaraujo.wordpress.com 41

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Estruturas organizacionais

    FuncionalMatricial

    ProjetizadaCaractersticas do

    projeto Fraca Balanceada Forte

    Autoridade do gerente de projetos

    Pouca ou nenhuma Limitada

    Baixa a moderada

    Moderada a alta

    Alta a quase total

    Disponibilidade dos recursos

    Pouca ou nenhuma Limitada

    Baixa a moderada

    Moderada a alta

    Alta a quase total

    Quem controla o oramento do projeto

    Gerente funcional

    Gerente funcional Misto

    Gerente de projetos

    Gerente de projetos

    Funo do gerente de projetos

    Tempo parcial

    Tempo parcial

    Tempo integral

    Tempo integral

    Tempo integral

    Equipe administrativa do gerenciamento de

    projetosTempo parcial

    Tempo parcial

    Tempo parcial

    Tempo integral

    Tempo integral

    Tabela 3: Influncias da estrutura organizacional nos projetos.

    Constatamos ento que o mais alto nvel de autoridade e poder de um gerente de projetos se encontra na estrutura projetizada.

    Para finalizar, gostaria de trazer uma analogia da tabela 3 com a histria do Goku, do Dragon Ball [1]. Quem f de mangas e animes vai entender rapidinho. Quem no o conhece pode perguntar para seu filho adolescente que ele ir explicar ! A figura 4 traz essa analogia.

    Figura 4: Goku e as estruturas organizacionais.

    Rogrio Arajo rogerioaraujo.wordpress.com 42

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Gabarito preliminar: ERRADO.

    Referncias:[1] Dragon Ball: http://pt.wikipedia.org/wiki/Dragon_Ball Acerca de processos e reas de conhecimento da 4.a edio do PMBOK, julgue os itens seguintes.

    85 A rea de conhecimento do gerenciamento do escopo do projeto abrange os seguintes processos: coletar os requisitos, definir o escopo, desenvolver o cronograma, verificar escopo e controlar o escopo.

    ComentriosEssa questo uma daquelas que temos que ter muito cuidado (alis, qual questo do CESPE

    que no temos que ter cuidado? ). Nesse caso, o que quero enfatizar que, em uma lista de processos como essa, pode haver a possibilidade de passar batido algum que seja estranho, pois podemos j estar cansados pelo tempo da prova ou podemos no ter ateno redobrada para checar cada item da lista. Beleza? Ento a dica sair procurando algum intrometido (ou alguns), se houver, e risc-lo.

    Ento, vamos questo. Ela trouxe processos para saber se so da rea de conhecimento do Gerenciamento do Escopo. Os processos dessa rea so [1]:

    Coletar os requisitos: definio e documentao das necessidades das partes interessadas para alcanar os objetivos do projeto;

    Definir o escopo: desenvolvimento de uma descrio detalhada do projeto e do produto; Criar a EAP: subdiviso das entregas e do trabalho do projeto em componentes menores e

    mais facilmente gerenciveis; Verificar o escopo: formalizao da aceitao das entregas terminadas do projeto; e Controlar o escopo: monitoramento do progresso do escopo do projeto e escopo do

    produto e gerenciamento das mudanas feitas na linha de base do escopo.Porm, no meio da listagem citada pela questo, h um estranho no ninho: Desenvolver o

    cronograma. Esse carinha da rea de conhecimento do Gerenciamento de Tempo [1]: Definir as atividades: identificao das aes especficas a serem realizadas para produzir

    as entregas do projeto; Sequenciar as atividades: identificao e documentao dos relacionamentos entre as

    atividades do projeto; Estimar os recursos da atividade: estimativa dos tipos e quantidades de material, pessoas,

    equipamentos ou suprimentos que sero necessrios para realizar cada atividade; Estimar as duraes da atividade: estimativa do nmero de perodos de trabalho que

    sero necessrios para terminar atividades especficas com os recursos estimados; Desenvolver o cronograma: anlise das sequncias das atividades, suas duraes,

    recursos necessrios e restries do cronograma visando criar o cronograma do projeto; e

    Controlar o cronograma: monitoramento do andamento do projeto para atualizao do seu progresso e gerenciamento das mudanas feitas na linha de base do cronograma.

    Gabarito preliminar: ERRADO.

    Rogrio Arajo rogerioaraujo.wordpress.com 43

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Referncias:[1] Guia do PMBok 4 Edio.

    86 Os grupos de processos de planejamento e de monitoramento e controle servem como entrada de um para o outro reciprocamente.

    ComentriosPara responder a questo, temos que entender a figura 5 [1].

    Figura 5: Interaes nos processos de gerenciamento de projetos.

    Rogrio Arajo rogerioaraujo.wordpress.com 44

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    As setas escuras representam os relacionamento entre os grupos de processos e as setas claras, itens externos aos grupos.

    Observao 2: Esclarecimento sobre as setas da figura 5.

    Pela figura, percebemos que: Existe uma seta escura saindo do Grupo de Planejamento para de Monitoramento e

    Controle. Essa seta representa o fluxo do PGP (Plano de Gerenciamento de Projeto); e No existe uma seta escura fazendo o percurso contrrio do item acima.Com isso, conclumos que a questo est errada.

    Gabarito preliminar: ERRADO.

    Referncias:[1] Guia do PMBok 4 Edio.

    87 A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo realizar a anlise qualitativa de riscos, com o uso da atribuio de probabilidades numricas.

    ComentriosPodemos dividir a questo em duas perguntas: A probabilidade de ocorrncias de risco e suas conseqncias so avaliadas pelo processo

    realizar a anlise qualitativa de riscos? Essa avaliao faz uso da atribuio de probabilidades numricas?Vamos responder a primeira pergunta! A rea de conhecimento do Gerenciamento de Riscos

    possui os seguintes processos [1]: Planejar o gerenciamento dos riscos: definio de como conduzir as atividades de

    gerenciamento dos riscos de um projeto; Identificar os riscos: determinao dos riscos que podem afetar o projeto e de

    documentao de suas caractersticas; Realizar a anlise qualitativa dos riscos: priorizao dos riscos para anlise ou ao

    adicional atravs da avaliao e combinao de sua probabilidade de ocorrncia e impacto;

    Realizar a anlise quantitativa dos riscos: analisar numericamente o efeito dos riscos identificados, nos objetivos gerais do projeto;

    Planejar as respostas aos riscos: desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto;

    Monitorar e controlar os riscos: implementao de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao de novos riscos e avaliao da eficcia dos processos de tratamento dos riscos durante todo o projeto.

    Verificando o conceito do processo Realizar a anlise qualitativa dos riscos, percebemos que a resposta da primeira pergunta SIM! Vamos para a segunda pergunta!

    A Avaliao de probabilidade e impacto dos riscos uma das ferramentas utilizadas no processo citado, porm, o Guia do PMBoK 4 Edio no cita, em nenhum momento, que essa

    Rogrio Arajo rogerioaraujo.wordpress.com 45

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    avaliao faz uso da atribuio de probabilidades numricas [1]:A avaliao da probabilidade e do impacto feita para cada risco identificado. Os riscos

    podem ser avaliados em entrevistas ou reunies com participantes selecionados por sua familiaridade com as categorias dos riscos na agenda. So includos membros da equipe do projeto e, talvez, pessoas experientes externas ao projeto.

    O nvel de probabilidade de cada risco e seu impacto em cada objetivo so avaliados durante a entrevista ou reunio. Tambm so registrados detalhes explicativos, incluindo as premissas que justificam os nveis atribudos. As probabilidades e os impactos dos riscos so classificados de acordo com as definies fornecidas no plano de gerenciamento dos riscos. (Grifo meu)

    V-se ento que no h uso de atribuies de probabilidades numricas na ferramenta citada, o que notamos que a resposta da segunda pergunta seja NO!

    Entretanto, no mesmo processo, faz-se o uso da ferramenta Matriz de probabilidade e impacto que pode levar ao candidato a pensar que a questo est certa. Essa matriz especifica as combinaes de probabilidade e impacto que resultam em uma classificao dos riscos como de prioridade baixa, moderada ou alta. Podem ser usados termos descritivos ou valores numricos, dependendo da preferncia organizacional [2]. A tabela 4 mostra um exemplo dessa matriz.

    Probabilidade Ameaas Oportunidades

    0,90 0,05 0,09 0,18 0,36 0,72 0,72 0,36 0,18 0,09 0,05

    0,70 0,04 0,07 0,14 0,28 0,56 0,56 0,28 0,14 0,07 0,04

    0,50 0,03 0,05 0,10 0,20 0,40 0,40 0,20 0,10 0,05 0,03

    0,30 0,02 0,03 0,06 0,12 0,24 0,24 0,12 0,06 0,03 0,02

    0,10 0,01 0,01 0,02 0,04 0,08 0,08 0,04 0,02 0,01 0,01

    0,05 0,10 0,20 0,40 0,80 0,80 0,40 0,20 0,10 0,05

    Tabela 4: Matriz de probabilidade e impacto.

    Para entender a tabela acima, temos que: As clulas com cores mais escuras (com os nmeros maiores) representam alto risco; As clulas com cores em tom mdio (com os nmeros menores) representam baixo risco;

    e As clulas com cores claras (com os nmeros intermedirios) representam risco

    moderado.Como no mundo de projetos, os riscos podem ser tanto ameaas quanto oportunidades, a

    matriz tambm mostra as classificaes para riscos de oportunidades. Finalizando, os riscos podem ser priorizados para uma posterior anlise quantitativa e

    resposta com base na sua classificao.Acredito que o examinador tenha explorado essa definio da Matriz de probabilidade e

    impacto e tenha colocado propositalmente a ferramenta de Avaliao de probabilidade e impacto dos riscos.

    Rogrio Arajo rogerioaraujo.wordpress.com 46

  • CESPE 2010 MPU Cargo 25 Analista de Desenvolvimento de Sistemas

    Gabarito preliminar: ERRADO.

    Referncias:[1] Guia do PMBok 4 Edio.[2] Matriz de probabilidade e impacto: http://wpm.wikidot.com/tecnica:matriz-de-probabilidade-e-impacto

    88 As quatro possibilidades de trmino de projeto so absoro, integrao, esgotamento e extino.

    ComentriosO que o Guia do PMBoK 4 Edio fala sobre o trmino de um projeto. Esse trmino

    alcanado: Quando os objetivos tiverem sido atingidos; Quando se concluir que esses objetivos no sero ou no podero ser atingidos e o

    projeto for encerrado; ou Quando o mesmo no for mais necessrio.O Guia citou trs formas e a questo citou quatro possibilidades e, com isso, acredito que a

    questo deveria ser anulada.Essas possibilidades foram descritas pelo Kim Heldman [1].

    Gabarito preliminar: CERTO.

    Referncias:[1] Gerncia de Projetos - Guia Para o Exame Oficial do PMI. 3 Edio. Kim Hedman.

    89 Os riscos desconhecidos podem representar uma ameaa ou uma oportunidade, por isso, o gerente de projeto deve manter reserva dos seus recursos para control-los quando necessrio.

    ComentriosA rea de conhecimento Gerenciamento de Custos possui trs processos [1]: Estimar os custos: desenvolvimento de uma estimativa de custos dos recursos monetrios

    necessrios para terminar as atividades do projeto; Determinar o oramento: agregao dos custos estimados de atividades individuais ou

    pacotes de trabalho para estabelecer uma linha de base autorizada dos custos; e Controlar os custos: monitoramento do andamento do projeto para atualizao do seu

    oramento e gerenciamento das mudanas feitas na linha de base dos custos.No processo de Estimar os custos, utiliza-se a ferramenta Anlise das reservas [1]:As estimativas de custos podem incluir reservas de contingncias (algumas vezes chamadas

    de subsdios para contingncias) para considerar os custos das incertezas. A reserva para contingncias pode ser uma porcentagem do custo estimado, um nmero fixado ou pode ser desenvolvida atravs do uso de mtodos de anlise quantitativa.

    Conforme informaes mais precisas sobre o projeto se tornam disponveis, a rese