Ementa BACEN Analista de Sistemas

Analista BACEN Desenvolvimento Ementa

I NOÇÕES GERAIS SOBRE COMPUTADORES E SISTEMAS COMPUTACIONAIS:

1 Computadores: arquitetura
de computadores; componentes de um computador (hardware e software); linguagens de programação;
compiladores e interpretadores; sistemas de numeração e representação de dados;

Aritmética computacional.

2 Sistemas operacionais:

funções básicas; sistemas de arquivos e gerenciamento de
memória.

3 Redes de computadores:

fundamentos de comunicação de dados; meios físicos; serviços de
comunicação; redes locais e redes geograficamente distribuídas; arquitetura TCP/IP; protocolos e serviços.
4 Processamento distribuído e processamento paralelo. link

5 Entradas e saídas de dados.

II GERÊNCIA DE PROJETOS E GOVERNANÇA DE TI:

1 Visão do PMBOK 4ª edição sobre gerenciamento de projetos.

2 SCRUM.
3 Fundamentos de ITIL V3.

4 Fundamentos de COBIT. 4.1

III MÉTRICAS DE TAMANHO DE SOFTWARE:

1
Medição e estimativas de software em pontos de função (IFPUG/CPM 4.3 e NESMA).

IV ENGENHARIA DE SOFTWARE:

1 Conceitos gerais e disciplinas de engenharia de software. 2 Ciclo de vida de software. 3
Análise e projeto orientado a objetos com UML. 4 Análise de requisitos funcionais e não-funcionais. 5
Modelagem orientada a objetos. 6 Padrões de projeto. 7 Modelagem de dados. 7.1 Modelo relacional. 8
Processos de desenvolvimento de software. 8.1 Processo interativo e incremental. 8.2 Processos e práticas
ágeis de desenvolvimento de software. 8.3 Extreme Programming (XP). 9 Técnicas para planejamento e
priorização incremental de escopo em projetos ágeis. 10 Domain-driven Design (DDD). 11 Qualidade de
software. 11.1 Norma ISO12207. 11.2 Métricas de qualidade: coesão e acoplamento.

V MODELAGEM DE PROCESSOS DE NEGÓCIO:

1 Conceitos básicos. 2 Identificação e delimitação de processos de negócio. 3
Técnicas de mapeamento de processos (modelos AS-IS). 4 Técnicas de análise e simulação de processos. 5
Construção e mensuração de indicadores de processos. 6 Técnicas de modelagem de processos (modelos
TO-BE). 7 Modelagem de processos em UML e BPMN: notação, artefatos e atividades.

VI ACESSIBILIDADE E ENGENHARIA DE USABILIDADE:

1 Engenharia de usabilidade.

1.1 Conceitos básicos. 1.2 Critérios,
recomendações e guias de estilo, utilização de Folhas de Estilo (CSS). 1.3 Análise de requisitos de
usabilidade.

1.4 Concepção, projeto e implementação de interfaces. 2 Acessibilidade: recomendações de
acessibilidade para construção e adaptação de conteúdos do governo brasileiro na internet. 3 Usabilidade
para aplicativos em dispositivos móveis.

VII ARQUITETURA DE APLICAÇÕES: 1 Arquitetura de aplicações
para ambiente web. 1.1 Servidor de aplicações. 1.2 Servidor web. 1.3 Ambientes Internet, Extranet, Intranet
e Portal - finalidades, características físicas e lógicas, aplicações e serviços. 2 Sistemas de Gerenciamento de
Banco de Dados (SGBD). 3 Arquitetura em três camadas, modelo MVC. 4 Soluções de integração: Service-
Oriented Architecture (SOA), web services e REST. 5 Arquiteturas para desenvolvimento de aplicativos em
dispositivos móveis. 6 Computação na nuvem.

VIII DESENVOLVIMENTO: 1 Fundamentos: lógica de
programação; Operadores e expressões, Estruturas de controle, seleção, repetição e desvio. Estruturas de
dados; métodos de ordenação, pesquisa e hashing, estrutura de arquivos; paradigmas de programação;
programação orientada a objetos. 2 Linguagens e ambientes de programação: Java, C# e ASP.NET. 3
Desenvolvimento de sistemas web: HTML/HTML5, CSS3, Javascript, XML/XSD, JSON. 4 Testes. 4.1
Conceitos: verificação e validação, tipos de teste (unidade, integração, sistema/funcional, aceitação, carga,
desempenho, vulnerabilidade, usabilidade). 

4.2 Concordion 1.4.3. 

4.3 Testes de unidade em Java com JUnit
4 e mocking de classes. 

4.4 Automatização de testes funcionais com Selenium 2. 4.5 Testes de carga com
JMeter 2.9. 

5 Gestão de defeitos (Bugtracking). 

5.1 Mantis. 

6 Sistemas de Gerenciamento de Banco de
Dados Relacional. 

6.1 Modelo lógico. 6.2 Modelo físico. 6.3 Linguagem SQL. 

7 Arquitetura Java. 

7.1 JEE 6.
7.2 JSE 7. 

8 Programação Java. 8.1 Wicket 1.4 e Wicket 6. 8.2 Hibernate 3. 8.3 Spring Framework 3. 9
Servidores de aplicação. 9.1 Websphere 8.5. 9.2 IIS 8. 10 Java Lightweight Containers. 10.1 Jetty 1.7. 

11 Análise estática de código e métricas. 

11.1 PMD, Findbugs e Checkstyle. 

11.2 Cobertura. 

11.3 Complexidade Ciclomática. 

11.4 Ferramenta Sonar. 

12 Ferramenta de build: Maven 3. 

13 IDE. 

13.1 Eclipse 3.7. 

13.2 Visual Studio 2012.

14 Ferramentas de gerência de configuração.

15 Práticas ágeis. 

15.1 Integração Contínua. 

15.2 Test-driven Development (TDD). 

15.3 Acceptance Test-driven Development (ATDD) e Especificação por
Exemplo.

15.4 Refactoring.

15.5 Entrega contínua.

16 Subversion (SVN).

17 Jenkins.

18 Application Lifecycle Management (ALM).

18.1 Team Foundation Server (TFS) 2012.

IX PORTAIS CORPORATIVOS:

1 Conceitos
básicos: colaboração, personalização, gestão do conhecimento, gestão de conteúdo, taxonomia, single signon,
integração de sistemas, funcionalidades de web 2.0. 

2 Noções de sistemas de busca e indexação de
conteúdo, noções de análise das estatísticas de site. 

3 Plataforma Sharepoint 2010.

X SOLUÇÕES DE AUTOMAÇÃO E DE SUPORTE À DECISÃO:

1 Inteligência de negócios.

2 Processo de Data Warehousing.

2.1 Data Warehouses e Data Marts.

2.2 Modelagem multidimensional.

3 Recuperação e visualização de dados.
3.1 OLAP.

3.2 Painéis e dashboards.

3.3 Data Mining.

4 Integração de dados.

4.1 Extração, transformação e carga (ETL).

5 Qualidade de dados. 

6 Gestão de conteúdo (ECM).

7 Automação de processo de trabalho (workflow).

8 Gerenciamento de processos de negócio (BPM).

Complexidade ciclomática

Origem: Wikipédia, a enciclopédia livre.

Complexidade ciclomática (ou complexidade condicional) é uma métrica de software usada para indicar a complexidade de um programa de computador. Desenvolvida por Thomas J. McCabe em 1976, ela mede a quantidade de caminhos de execução independentes a partir de um código fonte.

Essa complexidade é computada através do grafo de fluxo de controle do programa: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta direcionada conecta dois nós se o segundo comando pode ser executado imediatamente após o primeiro.

A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa.

Uma estratégia de teste de software formulada por McCabe é testar cada caminho independente de um programa, de forma que a quantidade de casos de teste será a complexidade ciclomática do programa.¹

Índice

  [esconder] 

·        1 Descrição

·        2 Referências

·        3 Ver também

·        4 Leitura adicional

Descrição[editar | editar código-fonte]

Grafo de fluxo de controle de um programa simples. O programa começa executando no nó vermelho, entra numa estrutura de repetição. Ao sair do dela, entra numa estrutura de seleção e então termina no nó azul. Para esse grafo, E = 9, N = 8 e P = 1, resultando numa complexidade ciclomática de 3. M=9-8+2*1 E=9 setas N=8 nós

A complexidade ciclomática de uma seção do código fonte é a quantidade de caminhos independentes pelo código. Por exemplo, se o código fonte não contém estruturas de controle senão sequenciais a complexidade é 1, já que há somente um caminho válido através do código. Se o código possui somente uma estrutura de seleção contendo somente uma condição, então há dois caminhos possíveis, aquele quando a condição é avaliada em verdadeiro, e aquele quando a condição é avaliada em falso.

Matematicamente, a complexidade ciclomática de um programa estruturado é definida com referência ao grafo direcionado que contém os blocos básicos do programa, com uma aresta entre dois blocos se o controle pode passar do primeiro para o segundo imediatamente, sem blocos intermediários. A complexidade então é definida como:²

Em que:

·       – complexidade ciclomática

·       – quantidade de setas

·       – quantidade de nós

·       – quantidade de componentes conectados

Mesma função que a acima, mostrada como um grafo de fluxo de controle fortemente conectado, para o cálculo pelo método alternativo. Para esse grafo, E = 10, N = 8 e P = 1, então a complexidade ciclomática se mantém em 3.

Uma formulação alternativa é usar um grafo em que o ponto de saída é conectado ao ponto de entrada. Nesse caso, o grafo é dito fortemente conectado, e a complexidade ciclomática do programa é equivalente ao número ciclomático do grafo, definido como:²

Isso pode ser visto como o cálculo da quantidade de ciclos independentes que existem no grafo, isto é, os ciclos que não contém outros ciclos embarcados. Notar que, tendo em vista que o ponto de saída é conectado ao ponto de entrada, há pelo menos um ciclo para cada ponto de saída.

Para um programa único, ou subrotina ou método, P é sempre igual a 1. Entretanto, a complexidade ciclomática pode ser aplicada a diversos programas ou subprogramas simultaneamente, de forma que P será a quantidade de programas em questão. Pode-se demonstrar que a complexidade ciclomática de qualquer programa estruturado com somente um ponto de entrada e um ponto de saída é igual a quantidade de pontos de decisão – como condicionais de estruturas de seleção ou uma iteração dos laços das estruturas de repetição – mais um.^2 3

A complexidade ciclomática também pode ser estendida para programas com múltiplas saídas, definida como:^3 4

Em que:

·         – quantidade de pontos de decisão do programa

·         – quantidade de pontos de saída

Referências

1.      Ir para cima↑ A J Sojev. Basis Path Testing.

2.      ↑ ^{Ir para:a b c} McCabe. (Dezembro 1976). "A Complexity Measure". IEEE Transactions on Software Engineering: 308–320.

3.      ↑ ^{Ir para:a b} Belzer, Kent, Holzman and Williams. Encyclopedia of Computer Science and Technology. [S.l.]: CRC Press, 1992. 367–368 p.

4.      Ir para cima↑ Harrison. (Outubro de 1984). "Applying Mccabe's complexity measure to multiple-exit programs". Software: Practice and Experience. J Wiley & Sons.

Ver também[editar | editar código-fonte]

·        Complexidade

·        Programa de computador

·        Estrutura de controle

·        Qualidade de software

Leitura adicional[editar | editar código-fonte]

·        Thomas J. McCabe (Dezembro de 1976). A Complexity Measure (em inglês) IEEE Transactions on Software Engineering Vol. 2, Nº 4, p. 308 IEEE.