Comentários: Eng. de Software/Governança de TI
Fernando Pedrosa – [email protected]
www.provasdeti.com.br
1


Analista de Finanças e Controle/Secretaria do
Tesouro Nacional
Professor da Equipe Itnerante
◦ Engenharia de Software e Governança de TI

Lugares por que passei
◦ Empresas Públicas (analista de sistemas)
◦ TJ/PE (analista judiciário)
◦ STJ (analista judiciário)

Certificações
◦ RUP 7.0, UML 2.2, ISO 27002, ITIL V3, COBIT 4.1, Scrum
Master, Product Owner, Java Programmer, Java Associate

Profile
◦ http://www.itnerante.com.br/profile/FernandoPedrosaLopes
www.provasdeti.com.br
2
Rede Social ITnerante
http://www.itnerante.com.br/
 Vídeo Aulas
http://www.provasdeti.com.br/
 Lista de Discussão TIMasters
http://br.groups.yahoo.com/group/ti
masters/

www.provasdeti.com.br
3
56. De acordo com Sommerville, no gerenciamento e modelagem de
negócio, as quatro principais atividades do processo são:
A) Estudo, Esboço, Implementação e Teste
B) Viabilidade, Planejamento, Projeto e Operação
C) Especificação, Desenvolvimento, Validação e Evolução
D) Requisito, Anteprojeto, Implementação e Implantação
E) Levantamento, Análise, Desenvolvimento e Manutenção
www.provasdeti.com.br
4
56. De acordo com Sommerville, no gerenciamento e modelagem de
negócio, as quatro principais atividades do processo são:
A) Estudo, Esboço, Implementação e Teste
B) Viabilidade, Planejamento, Projeto e Operação
C) Especificação, Desenvolvimento, Validação e Evolução
D) Requisito, Anteprojeto, Implementação e Implantação
E) Levantamento, Análise, Desenvolvimento e Manutenção
www.provasdeti.com.br
5



“Processo de software” é uma sequência de
atividades que resulta na produção do software
Para Sommerville, existem quatro atividades
fundamentais que são comuns para todos os
processos de software
Especificação
◦ Definições sobre o software que será produzido

Desenvolvimento
◦ Projeto e programação do software

Validação
◦ Conferir se o software atende as expectativas do cliente

Evolução
◦ Mudanças ao longo do tempo para refletir novos requisitos
www.provasdeti.com.br
6
57. O processo de Engenharia de Requisitos é realizado por meio da
execução de sete funções distintas: concepção, levantamento,
elaboração, negociação, especificação, validação e gestão. Nesse
contexto, observe a lista abaixo, que representa um conjunto de
questões a serem utilizadas como checklist dentro de uma dessas
funções:
1)
2)
Os requisitos foram claramente estabelecidos? Eles podem ser mal interpretados?
A fonte do requisito foi identificada?
6)
O requisito está limitado em termos quantitativos?
Que outros requisitos se relacionam a este requisito?
O requisito viola alguma restrição do domínio?
Pode-se relacionar o requisito a qualquer modelo de sistema que tenha sido criado?
7)
O requisito está relacionado aos objetivos globais do sistema/produto?
3)
4)
5)
www.provasdeti.com.br
7
A função é:
A) Elaboração
B) Negociação
C) Especificação
D) Validação
E) Gestão
www.provasdeti.com.br
8
A função é:
A) Elaboração
B) Negociação
C) Especificação
D) Validação
E) Gestão
www.provasdeti.com.br
9


Tanto Pressman como Sommerville organizam o
processo de Eng. de Requisitos em macroatividades
Sommerville
◦ Estudo de viabilidade, Elicitação e análise de Requisitos,
Especificação de Requisitos, Validação de Requisitos e
Gestão de Requisitos

Pressman
◦
◦
◦
◦
◦
◦
◦
Concepção – definição do escopo e natureza do problema
Levantamento – esclarecimento das necessidades do cliente
Elaboração – refinamento em um modelo de análise
Negociação – priorização de requisitos
Especificação – registro em um documento formal
Validação – checagem de corretude e consistência
Gestão – controle da evolução dos requisitos
www.provasdeti.com.br
10
58. A figura abaixo representa o ciclo de vida de software, conhecido
como modelo em cascata
www.provasdeti.com.br
11
Um dos estágios divide os requisitos em sistemas de hardware ou
de software, estabelecendo uma arquitetura geral do sistema. Envolve
a identificação e a descrição das abstrações fundamentais de software
e suas relações. Esse estágio é conhecido por:
A) Definição de requisitos
B) Projeto de sistema e software
C) Implementação e teste de unidade
D) Integração e teste de sistema
E) Operação e manutenção
www.provasdeti.com.br
12
Um dos estágios divide os requisitos em sistemas de hardware ou
de software, estabelecendo uma arquitetura geral do sistema. Envolve
a identificação e a descrição das abstrações fundamentais de software
e suas relações. Esse estágio é conhecido por:
A) Definição de requisitos
B) Projeto de sistema e software
C) Implementação e teste de unidade
D) Integração e teste de sistema
E) Operação e manutenção
www.provasdeti.com.br
13


Modelo Clássico, sistemático e sequencial,
organizado em várias etapas ou fases
Definição de Requisitos
◦ Definição dos serviços, restrições e objetivos do sistema

Projeto de SW e Sistema
◦ Tradução dos requisitos para sistemas de hardware ou
software, estabelecendo a arquitetura geral a ser utilizada

Implementação e Testes Unitários
◦ Programação das unidades e testes de cada uma delas

Integração e Testes de Sistema
◦ Unidades integradas e testadas como um sistema completo

Operação e Manutenção
◦ Sistema instalado e sendo utilizado, podendo envolver
correções de erros que não foram descobertos antes
www.provasdeti.com.br
14
59. Segundo Pressman, os elementos específicos do modelo de análise
são ditados pelo método de modelagem de análise usado. No entanto,
um conjunto de elementos genéricos é comum à maioria dos modelos
de análise. Nesse sentido, observe a figura abaixo, que ilustra o
modelo de estado UML e que representa os estados e eventos que
modificam um sistema. O diagrama de estados indica que ações são
realizadas em consequência de determinado evento
www.provasdeti.com.br
15
O diagrama de estados é utilizado quando se trata dos elementos de
análise do tipo:
A) Procedurais
B) Comportamentais
C) Orientados a Fluxo
D) Baseados em classe
E) Baseados em cenários
www.provasdeti.com.br
16
O diagrama de estados é utilizado quando se trata dos elementos de
análise do tipo:
A) Procedurais
B) Comportamentais
C) Orientados a Fluxo
D) Baseados em classe
E) Baseados em cenários
www.provasdeti.com.br
17
www.provasdeti.com.br
60. O Rational Unified Process (RUP) é um exemplo de modelo de
processo derivado da UML e do Processo Unificado de
Desenvolvimento de Software de Rumbaugh. O RUP reconhece que os
modelos convencionais de processo apresentam uma visão única do
processo. O RUP engloba três perspectivas, descritas a seguir.
I. Mostra as fases do modelo ao longo do tempo.
II. Mostra as atividades realizadas no processo.
III. Sugere as boas práticas a serem usadas durante o processo.
www.provasdeti.com.br
19
Essas perspectivas são conhecidas, respectivamente, como:
A) dinâmica, estática e prática
B) estática, dinâmica e prática
C) dinâmica, estática e organizacional
D) estática, dinâmica e funcional
E) dinâmica, estática e funcional
www.provasdeti.com.br
20
Essas perspectivas são conhecidas, respectivamente, como:
A) dinâmica, estática e prática
B) estática, dinâmica e prática
C) dinâmica, estática e organizacional
D) estática, dinâmica e funcional
E) dinâmica, estática e funcional
www.provasdeti.com.br
21
Eixo
dinâmico
Eixo
estático
www.provasdeti.com.br
22
61. A Extreme Programming é um dos métodos ágeis mais conhecidos
e usados, e envolve um número de práticas que se enquadram nos
princípios gerais da metodologia. Dois desses princípios são descritos
a seguir:
I. Os requisitos são gerenciados em cartões de histórias, sendo as
histórias incluídas em um release, determinadas pelo tempo
disponível e sua prioridade relativa
II. Espera-se que todos os desenvolvedores recriem o código
continuamente, tão logo os aprimoramentos do código forem
encontrados, o que torna o código simples e fácil de manter
www.provasdeti.com.br
23
Esses princípios são denominados, respectivamente:
A) integração contínua e refactoring
B) planejamento incremental e cliente on-site
C) planejamento incremental e desenvolvimento test-first
D) integração contínua e desenvolvimento test-first
E) planejamento incremental e refactoring
www.provasdeti.com.br
24
Esses princípios são denominados, respectivamente:
A) integração contínua e refactoring
B) planejamento incremental e cliente on-site
C) planejamento incremental e desenvolvimento test-first
D) integração contínua e desenvolvimento test-first
E) planejamento incremental e refactoring
www.provasdeti.com.br
25













Metáfora
Projeto simples
Pequenas versões
Refatoração
Programação em pares
Propriedade coletiva do código
Padrão de codificação
Ritmo sustentável
Reuniões em pé
Cliente sempre presente
Desenvolvimento orientado a testes
Integração contínua
Planejamento Incremental
www.provasdeti.com.br
26
62. Segundo Pressman, a medição permite obter o entendimento do
processo e do projeto, dando um mecanismo para avaliação objetiva.
Dentre as métricas para projeto OO, uma representa um Indicativo de
quantidade de esforço requerida para desenvolver o software e a outra
o potencial de reúso a ser aplicada durante o desenvolvimento do
sistema. Essa métrica é denominada número de:
A) subsistemas.
B) classes-chave
C) classes de apoio por classes-chave
D) scripts de cenário
E) classes de apoio
www.provasdeti.com.br
27
62. Segundo Pressman, a medição permite obter o entendimento do
processo e do projeto, dando um mecanismo para avaliação objetiva.
Dentre as métricas para projeto OO, uma representa um Indicativo de
quantidade de esforço requerida para desenvolver o software e a outra
o potencial de reúso a ser aplicada durante o desenvolvimento do
sistema. Essa métrica é denominada número de:
A) subsistemas.
B) classes-chave
C) classes de apoio por classes-chave
D) scripts de cenário
E) classes de apoio
www.provasdeti.com.br
28


Pressman propõe algumas métricas para medir o
esforço de desenvolvimento para processos
incrementais
Número de scripts de cenários
◦ Diretamente relacionado ao número de casos de testes e
tamanho da aplicação

Número de classes-chave
◦ Indicam o esforço necessário para desenvolver o software e
também o potencial de reúso do sistema

Número de classes de apoio
◦ Indicam o esforço necessário para desenvolver o software e
também o potencial de reúso do sistema

E outras...
www.provasdeti.com.br
29
63. Uma revisão técnica formal – FTR – é uma atividade de garantia da
qualidade, englobando walkthroughs, inspeções e revisões técnicas.
De caráter obrigatório, dois objetivos da FTR são, respectivamente:
A) Avaliar a tecnologia empregada na infraestrutura da rede utilizada
no teste/ verificar se o software satisfaz aos requisitos.
B) Avaliar se há suporte para multitarefa preemptiva/ avaliar a
tecnologia empregada na infraestrutura da rede utilizada no teste.
C) Verificar se o software satisfaz aos requisitos/ garantir que o
software tenha sido definido conforme os padrões predefinidos.
D) Garantir que o sistema funciona em cloud computing/ avaliar a
tecnologia empregada na infraestrutura da rede utilizada no teste
E) Garantir que o software tenha sido definido conforme os padrões
predefinidos/ Avaliar se há suporte para multitarefa preemptiva
www.provasdeti.com.br
30
63. Uma revisão técnica formal – FTR – é uma atividade de garantia da
qualidade, englobando walkthroughs, inspeções e revisões técnicas.
De caráter obrigatório, dois objetivos da FTR são, respectivamente:
A) Avaliar a tecnologia empregada na infraestrutura da rede utilizada
no teste/ verificar se o software satisfaz aos requisitos.
B) Avaliar se há suporte para multitarefa preemptiva/ avaliar a
tecnologia empregada na infraestrutura da rede utilizada no teste.
C) Verificar se o software satisfaz aos requisitos/ garantir que o
software tenha sido definido conforme os padrões predefinidos.
D) Garantir que o sistema funciona em cloud computing/ avaliar a
tecnologia empregada na infraestrutura da rede utilizada no teste
E) Garantir que o software tenha sido definido conforme os padrões
predefinidos/ Avaliar se há suporte para multitarefa preemptiva
www.provasdeti.com.br
31


Revisão Técnica Formal é uma atividade de
Controle de Qualidade
Os objetivos são:
◦ Achar erros de função, lógica ou implementação no
software
◦ Verificar que o software atende seus requisitos
◦ Garantir que o software foi representado de acordo com
padrões pré-definidos
◦ Alcançar um desenvolvimento de software uniformizado
◦ Tornar os projetos mais facilmente gerenciáveis
www.provasdeti.com.br
32
67. A UML – Unified Modeling Language – é uma linguagem visual
utilizada para modelar softwares baseados no paradigma de
orientação a objetos. Empregado normalmente nas fases de
levantamento e análise de requisitos, embora venha a ser consultado
durante todo o processo de modelagem e possa servir de base para
outros, um diagrama, exemplificado na figura abaixo, procura
identificar usuários, outros sistemas, ou mesmo algum hardware
especial, que utilizarão o software de algum modo, bem como os
serviços e funcionalidades.
www.provasdeti.com.br
33
A figura representa o diagrama
de:
A) Casos de uso
B) Fluxo de Dados
C) Entidades e relacionamentos
D) Processos e funções
E) Contexto
www.provasdeti.com.br
34
A figura representa o diagrama
de:
A) Casos de uso
B) Fluxo de Dados
C) Entidades e relacionamentos
D) Processos e funções
E) Contexto
www.provasdeti.com.br
35
68. Governança de TI pode ser definido como um conjunto de práticas,
padrões e relacionamentos estruturados, assumidos por executivos,
gestores, técnicos e usuários de TI de uma organização, com a
finalidade de garantir controles efetivos, ampliar os processos de
segurança, minizar os riscos, ampliar o desempenho, otimizar a
aplicação de recursos, reduzir os custos, suportar as melhores
decisões e, consequentemente, alinhar TI aos negócios. No que diz
respeito à descrição e visão macro de um processo de planejamento
estratégico empresarial típico, dois termos são definidos a seguir:
I. Refere-se ao tratamento de informações internas e externas acerca
do mercado, clientes, concorrentes, fornecedores, de cunho político,
legal, social e econômico, assim como à avaliação de oportunidades,
pontos fracos e pontos fortes, que servem de base para a revisão ou
elaboração da estratégia corporativa e competitiva.
www.provasdeti.com.br
36
II. Documenta as intenções da administração sobre como atingir os
objetivos estratégicos do negócio e estabelece as ações necessárias
para que os objetivos do negócio sejam atingidos.
Estes termos são conhecidos, respectivamente como:
A) Inteligência Corporativa e Plano Funcional
B) Inteligência Corporativa e Plano Estratégico
C) Inteligência Operacional e Plano Estratégico
D) Inteligência Competitiva e Plano Estratégico
E) Inteligência Competitiva e Plano Funcional
www.provasdeti.com.br
37
II. Documenta as intenções da administração sobre como atingir os
objetivos estratégicos do negócio e estabelece as ações necessárias
para que os objetivos do negócio sejam atingidos.
Estes termos são conhecidos, respectivamente como:
A) Inteligência Corporativa e Plano Funcional
B) Inteligência Corporativa e Plano Estratégico
C) Inteligência Operacional e Plano Estratégico
D) Inteligência Competitiva e Plano Estratégico
E) Inteligência Competitiva e Plano Funcional
www.provasdeti.com.br
38


Segundo Aragon, o Processo de Planejamento
Estratégico Empresarial contém os seguintes
elementos:
Inteligência competitiva
◦ Quais são os clientes do nosso mercado, concorrentes,
fornecedores, oportunidades, pontos fortes e fracos da
nossa empresa, etc.

Estratégia corporativa
◦ Em que negócio vamos atuar, que novo mercado será
desenvolvido? Qual será o nosso foco?

Estratégia competitiva e de posicionamento
◦ Como vamos nos diferenciar do mercado? Qual será a
nossa missão e posicionamento?
www.provasdeti.com.br
39

Plano estratégico
◦ Como a Administração irá atingir os objetivos do negócio?
Estabelece as ações necessárias para que estes objetivos
sejam atingidos

Planos funcionais
◦ Desdobram as estratégias em projetos e serviços que
devem ser desenvolvidos para atingir os objetivos de
negócio da empresa
◦ Planos de TI estão aqui
www.provasdeti.com.br
40
70. No âmbito da ITIL V3, entre os diversos processos de
gerenciamento que integram o macroprocesso “Desenho ou Projeto
de Serviços (Service Design)”, três são conhecidos, respectivamente,
como Gerenciamento de:
A) Redes de valor, outsourcing de serviços e incidentes
B) Nível de serviços, estratégias de serviços e qualidade
C) Disponibilidade de serviços, catálogo de serviços e acessos
D) Segurança da informação, fornecedores de serviços e capacidade
E) Dimensionamento e monitoramento, portfólio de serviços e
problemas
www.provasdeti.com.br
41
70. No âmbito da ITIL V3, entre os diversos processos de
gerenciamento que integram o macroprocesso “Desenho ou Projeto
de Serviços (Service Design)”, três são conhecidos, respectivamente,
como Gerenciamento de:
A) Redes de valor, outsourcing de serviços e incidentes
B) Nível de serviços, estratégias de serviços e qualidade
C) Disponibilidade de serviços, catálogo de serviços e acessos
D) Segurança da informação, fornecedores de serviços e capacidade
E) Dimensionamento e monitoramento, portfólio de serviços e
problemas
www.provasdeti.com.br
42
Estágio do Ciclo de Vida
Processos
Estratégia do Serviço
(4 processos)
Geração da Estratégia
Ger. de Portfólio de Serviços
Ger. Financeiro
Ger. de Demandas
Desenho do Serviço
(7 processos)
Ger.
Ger.
Ger.
Ger.
Transição do Serviço
(7 processos)
Ger. de Mudanças
Validação e Testes do Serviço
Ger. de Conhecimento
Avaliação
Ger. de Configuração e Ativos
Planejamento e Suporte da Transição
Gerenciamento de Liberação e Implantação
Operação do Serviço
(5 processos, 4 funções)
Ger. de Incidentes
Ger. de Problemas
Ger. de Acesso
Cumprimento de Requisição
Ger. de Eventos
Melhoria Contínua do Serviço
(3 processos)
Melhoria em 7 passos
Relatório de Serviços
Mensuração de Serviços
de
de
de
de
Catálogo de Serviços
Nível de Serviços
Capacidade
Disponibilidade
Ger. de Continuidade
Ger. de Fornecedores
Ger. de Segurança
da Informação
Funções:
Central de Serviços
Ger. Técnico
Ger. de Operações
Ger. de Aplicações
www.provasdeti.com.br
43