Você está na página 1de 104

Aula 00

Tecnologia da Informao p/ TRT-MG (parte II) - Analista


Professor: Diego Carvalho

00000000000 - DEMO

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

AULA 00
SUMRIO

PGINA

Apresentao
1. Ciclo de Vida de Software
2. Processos de Desenvolvimento de Software
3. Modelo em Cascata
4. Modelos Iterativos e Incrementais
5. Modelos Evolucionrios
6. Scrum
7. Extreme Programming (XP)
8. Kanban
9. TDD (Test Driven Development)
10. BDD (Behavior Driven Development)
Fui bem? Fui mal? Mais ou menos?
Lista de Exerccios Comentados
Gabarito

01
12
15
18
36
41
46
67
86
86
86
87
88
103

APRESENTAO
Ol, pessoal. Sejam bem-vindos! Acaba de sair a autorizao para o Concurso do
Tribunal Regional do Trabalho 3 Regio (MG) Cargo: Analista Judicirio rea:
Tecnologia da Informao. Pessoal, deixa eu contar uma parada: finalmente saiu o
esperado concurso do TRT/MG! No importa se cadastro-reserva, no ltimo
concurso h seis anos chamaram um bocado de gente! Animem, pessoal!
TOP 4 DVIDAS DOS ALUNOS
00000000000

1.

Essa a Aula Demonstrativa (est disponvel para todos na internet) o restante do contedo estar
disponvel na Aula 01 (apenas para aqueles que adquirirem o curso).

2. Esse curso no possui vdeo-aulas! Estamos trabalhando para disponibiliz-las em cursos futuros a
partir do segundo semestre, logo isso no ocorrer ainda neste curso.
3. Esse curso contempla somente aquilo que est em seu cronograma. Ele no contempla todo edital de
tecnologia da informao, nem outras disciplinas, nem discursivas, estudos de caso, etc.
4. Existem questes de Mltipla Escolha (A, B, C, D, E) e existem questes de Certo/Errado (C, E). Quando
no h itens para escolha na questo, porque a questo da Modalidade Certo/Errado.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 1 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

O PROFESSOR.
Uma breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da
Computao pela Universidade de Braslia, ps-graduado em Gesto de Tecnologia
da Informao na Administrao Pblica e Analista de Finanas e Controle da
Secretaria do Tesouro Nacional. J passei por esses perrengues de concurseiro e sei
de duas coisas: a estrada difcil, mas o prmio compensa! E muito!

www.facebook.com/professordiegocarvalho
O nosso curso est cada vez mais completo e mais maduro. meu 38 curso aqui
no site, passando por rgos como: ANCINE, TRT/2, CEF, ISS/SP, TCE-RS, ANATEL,
TRT/1, ANTAQ, ISS/BA, DATAPREV, TJ/BA, TCE/SP, TCM/GO, CNMP, MPOG,
TRT/15, TCU, CD fora os Cursos Regulares. Observem que foram cursos de menor
envergadura at cursos de enorme envergadura!
Galera, l no site, ns professores temos algumas mtricas para medir se o nosso
desempenho nos cursos est bacana! Os alunos podem avaliar com notas e,
inclusive, escrever anonimamente o que acharam do professor e do curso.
Apresento abaixo o resultado de alguns cursos ministrados recentemente. Portanto,
confiem em mim... vocs vo aprender muito com esse curso!

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 2 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 3 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 4 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

00000000000

Esse curso protegido por direitos autorais (Copyright), nos termos da Lei 9.610/98.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 5 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

O CONCURSO

Concurso do Tribunal Regional do Trabalho 3 Regio (


- 2015
Analista Judicirio Apoio Especializado: Tecnologia da Informao
INFORMAES GERAIS

00000000000

REMUNERAO
(PROVAVELMENTE) R$8.863,84

VAGAS
CADASTRO RESERVA

EDITAL/AUTORIZAO:
http://www.concursosfcc.com.br/concursos/trt3r114/boletim_final_trt3r114.pdf

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 6 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

O CURSO...
Metodologias e prticas de desenvolvimento de software. Scrum. Extreme Programming (XP). Prticas geis. Kanban.
Test Driven Development. Behavior Driven Development. Engenharia de Software: Engenharia de Requisitos. Tcnicas
de levantamento de requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos. Verificao e validao
de requisitos. Requisitos funcionais e no funcionais. Mtricas de Software. Ponto de funo. Mtricas geis. Anlise
e projeto orientado a objetos. Processo Unificado. Testes. Processos de testes. Tipos e estratgias. Planejamento e
acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade. Tolerncia a falhas. Interoperabilidade.
Usabilidade. Integrao Contnua. Anlise automatizada e Reviso de cdigo. Linguagens de programao. Java.
HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS. Tecnologias Java. Java EE 6 e 7 (web profile
e full profile). Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST. SOAP. Padres de
Projetos. Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio ao desenvolvimento de
software: Maven. Gerenciadores de verso distribudos (Git e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da
Informao. Conceituao e papel da Informao nas organizaes. Implantao da gesto informacional: custos e
benefcios. Informao e confiabilidade: a validade dos dados.

O curso que eu proponho abranger todo o contedo acima, entretanto


impossvel e invivel esgotar cada ponto do edital em uma aula online de TI
(diferente de Direito). Logo, vou direcion-los pelo contedo da melhor maneira
possvel. Fiquem tranquilos! Eu sei como complicado ler muita coisa e vocs tm
outras disciplinas para estudar. Logo, vou ser simples e objetivo! Tranquilo? ;)
Alm disso, o cronograma ser seguido com a maior fidelidade possvel, mas ele
no esttico e poder haver alteraes no decorrer do curso. Eventualmente,
posso tirar o contedo de uma aula e colocar em outra de forma que o estudo de
vocs fique mais lgico, coeso e fcil de acompanhar; eventualmente, podemos
mudar a ordem das aulas. Ademais, vamos usar questes de diversas bancas.
Enfim, confiem em mim: o curso vai ajudar bastante! Qualquer dvida, qualquer
dvida mesmo... por mais simples que seja, s me chamar! Caso haja alguma
reclamao, problema, sugesto, comentrios, erros de digitao, etc, podem enviar
para o nosso frum que eu tento responder da maneira mais tempestiva possvel.
Ainda duvidam que PDF no d certo com Concursos de TI? Veja abaixo:
00000000000

6 Lugar ISS/Salvador
https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678
1 Lugar TRT/RJ
https://www.facebook.com/video.php?v=790616534367672

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 7 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

2 Lugar ISS/Salvador
https://www.youtube.com/watch?v=vmU1n1J-aqQ
Veja outros depoimentos:
http://www.estrategiaconcursos.com.br/blog/depoimentos

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 8 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

CRONOGRAM
Aula
00

Data
12/05

Tpicos do Edital

01

14/05

02

17/05

03

24/05

- Metodologias e prticas de desenvolvimento de software. Scrum. Extreme


Programming (XP). Prticas geis. Kanban. Test Driven Development. Behavior
Driven Development.
- Engenharia de Software: Engenharia de Requisitos. Tcnicas de levantamento de
requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos.
Verificao e validao de requisitos. Requisitos funcionais e no funcionais.
- Mtricas de Software. Ponto de funo. Mtricas geis.

04

31/05

- Anlise e projeto orientado a objetos.

05

07/06

- Processo Unificado.

06

14/06

07

21/06

- Testes. Processos de testes. Tipos e estratgias. Planejamento e


acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade.
Tolerncia a falhas. Interoperabilidade. Usabilidade. Integrao Contnua. Anlise
automatizada e Reviso de cdigo.
- Linguagens de programao. Java.

08

28/06

- Aula Demonstrativa

- HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS.


Tecnologias Java. Java EE 6 e 7 (web profile e full profile).
00000000000

09

05/07

- Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST.


SOAP.

10

12/07

- Padres de Projetos.

11

19/07

- Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio


ao desenvolvimento de software: Maven. Gerenciadores de verso distribudos (Git
e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da Informao. Conceituao e
papel da Informao nas organizaes. Implantao da gesto informacional:
custos e benefcios. Informao e confiabilidade: a validade dos dados.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 9 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

AS AULAS E AS DICAS
1 Pargrafos pequenos: observem que os pargrafos
tm, no mximo, cinco linhas. Isso serve para que a
leitura no fique cansativa e para que vocs no
desanimem no meio do material! Para tal, eu tento dividir
as disciplinas de maneira que as aulas fiquem objetivas e
pequenas (em termos de teoria), mas extensa (em
termos de exerccios).
3 Destaques em vermelho: quase todos os
pargrafos possuem alguma palavra ou frase destacada
em negrito e em vermelho. Isso ocorre por suas razes:
primeiro, para enfatizar alguma informao importante;
segundo, para facilitar a leitura vertical, i.e., aps uma
primeira leitura, a segunda pode ser passando apenas
pelos pontos em destaque.
5 Linguagem natural: essa uma aula para ser lida, o
que por si s j pode ser cansativo. Tentarei colocar a
linguagem mais coloquial possvel, simulando uma
conversa. Portanto, caso virem frases ou palavras em
itlico, ou uma palavra estrangeira ou a simulao de
uma conversa com vocs. Pode dar um exemplo,
professor? Acabei de dar! :-)
7 Diversas figuras: essas aulas estaro em constante
evoluo, sempre procura de explicar as matrias de
maneira mais compreensvel e com novas
informaes/questes. Para tal, na minha opinio,
fundamental a utilizao de figuras, grficos, painis, etc.
Em minha experincia, bem mais fcil memorizar a
partir de imagens.
9 Fazer Exerccios: muitos exerccios o meio pelo
qual vocs se situaro. Como assim, professor? na hora
de fazer os exerccios que vocs descobriro se esto
bem ou mal e avaliaro se precisam estudar mais ou
menos. Para tal, h um quadrinho ao final de cada bloco
de exerccios para vocs anotarem a quantidade de
questes respondidas corretamente ou incorretamente.
00000000000

2 Viso Geral: no se atenham a detalhes antes de


entender o bsico. Por que? Ora, no h nada mais
irritante do que ir para uma prova que vai cair, por
exemplo, RUP, saber vrios detalhes, mas no saber as
fases e disciplinas. Portanto, caso estejam iniciando os
estudos sobre uma matria, foquem em saber o bsico
para depois se especializarem.
4 Faam muitos exerccios: ler vrias bibliografias
muito trabalhoso e, geralmente, no vale o custobenefcio. Acredito que o que funciona mesmo entender
o bsico, depois fazer muitos exerccios e,
eventualmente, caso encontrarem algo que no
souberem, pesquisem-no separadamente. Alm disso,
voc vai pegando as manhas da banca.
6 Faam resumos: essa dica somente serve caso
vocs tenham disponibilidade. Caso haja pouco tempo
para estudar ou pouco tempo at a prova, no compensa!
Se no, faam resumos organizados, pois eles
economizaro um bom tempo de estudo em suas
prximas provas e sempre que descobrirem novas
informaes, insiram-nas no resumo.
8 Revisem antes da prova: no adianta querer
estudar coisas novas at o ltimo minuto antes da prova
e no revisar o que estudou h um ms. Vocs iro
esquecer e iro se irritar na hora da prova por no
lembrarem de conceitos simples. Tirem uma semana
para revisar seus resumos, decorarem algumas coisas
e, certamente, iro mais confiantes para a prova.
10 Simulado Final: ora, fazer um bloco de questes
depois de estudar a teoria tranquilo. No entanto,
lembrem-se que a memria de vocs no infinita e
vocs tm um milho de outras coisas para estudar e
decorar. Portanto, se possvel, ao fim do curso faremos
um simulado com questes escolhidas que foram
comentadas dentro das aulas.

Bem, pessoal! isso... sejam bem vindos! Espero que vocs curtam e tenham uma
leitura leve e despojada da aula, mas com muito foco, ateno e dedicao.
Qualquer dvida, podem entrar em contato comigo ficarei feliz em ajud-los. Bons
estudos, estou torcendo por vocs! Fiquem agora com algumas mensagens de
incentivo para anim-los ;-)

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 10 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

R$8.863,84
R$8.863,84
R$8.863,84
R$8.863,84
R$8.863,84
00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 11 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00
Metodologias e prticas de desenvolvimento de software. Scrum. Extreme Programming (XP). Prticas geis. Kanban.
Test Driven Development. Behavior Driven Development. Engenharia de Software: Engenharia de Requisitos. Tcnicas
de levantamento de requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos. Verificao e validao
de requisitos. Requisitos funcionais e no funcionais. Mtricas de Software. Ponto de funo. Mtricas geis. Anlise
e projeto orientado a objetos. Processo Unificado. Testes. Processos de testes. Tipos e estratgias. Planejamento e
acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade. Tolerncia a falhas. Interoperabilidade.
Usabilidade. Integrao Contnua. Anlise automatizada e Reviso de cdigo. Linguagens de programao. Java.
HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS. Tecnologias Java. Java EE 6 e 7 (web profile
e full profile). Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST. SOAP. Padres de
Projetos. Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio ao desenvolvimento de
software: Maven. Gerenciadores de verso distribudos (Git e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da
Informao. Conceituao e papel da Informao nas organizaes. Implantao da gesto informacional: custos e
benefcios. Informao e confiabilidade: a validade dos dados.

1. CICLO DE VIDA DE SOFTWARE


O Ciclo de Vida de Software se refere s fases pelas quais um sistema de software
atravessa desde sua concepo at sua retirada de produo. Galera, no
confundam Ciclo de Vida de Software com Ciclo de Vida de Desenvolvimento de
Software (inclusive, muitas bancas erram nesse ponto), entretanto fiquem relaxados,
porque essa diferena geralmente no cobrada.
Fazendo um paralelo com o PMBOK, o Ciclo de Vida do Projeto seria o Ciclo de
Vida do Desenvolvimento de Software e o Ciclo de Vida do Produto seria o Ciclo de
Vida do Software. O PMBOK diz que cada projeto deve especificar seu prprio ciclo
de vida, mas sugere fases genricas: Incio do Projeto, Organizao e Preparao,
Execuo do Trabalho e Encerramento do Projeto.
00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 12 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Da mesma forma que o Ciclo de Vida do Projeto est contido em um Ciclo de Vida
do Produto, o Ciclo de Vida de Desenvolvimento de Software est contido em um
Ciclo de Vida do Software. Fazendo um paralelo, podemos ver cada fase do ciclo
de vida do software como um projeto! Em outras palavras, podemos tratar a
Definio, Desenvolvimento, Operao e Retirada como um projeto.
O Ciclo de Vida apenas a ordem global das atividades desempenhadas no s no
desenvolvimento de software, mas tambm em sua evoluo, manuteno e
retirada. Infelizmente no h um consenso entre os autores a respeito dos estgios,
mas comum as seguintes fases: Definio ou Concepo, Desenvolvimento ou
Construo, Operao ou Utilizao e Retirada ou Aposentadoria.

00000000000

Na Definio, busca-se entender o problema a ser resolvido pelo software. No


Desenvolvimento, busca-se construir o software de acordo com uma srie de
requisitos. Na Operao, ocorre a entrega, distribuio, instalao, configurao,

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 13 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

utilizao e manuteno do software. Por fim, na Retirada, aposenta-se o software


de vez! isso... simples, no?! ;)

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 14 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

2. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE


De acordo com Sommerville, o termo Ciclo de Vida de Desenvolvimento de
Software foi criado originalmente para se referir ao Modelo em Cascata, sendo
atualmente bastante utilizado como um sinnimo de Processo ou Metodologia de
Desenvolvimento Software. E o que seria isso? Um conjunto de atividades, cuja meta
o desenvolvimento ou a evoluo de um software.
Sendo mais detalhista, o processo de desenvolvimento de software refere-se s
atividades, relacionamentos, artefatos, ferramentas, papis, etc necessrios para
construir, entregar e manter um produto de software. J o ciclo de vida de
desenvolvimento de software apresenta uma representao mais alto nvel do
processo de software executado.
Galera, vocs no precisam se preocupar com isso! Nunca vi essa diferena ser
cobrada em prova. Alis, comum que as bancas as tratem como sinnimos.
Pessoal, coloquei na imagem abaixo os principais grupos de modelos de
desenvolvimento de software. Essa classificao no um consenso entre os autores
e nem so mutuamente exclusivas, podendo haver combinao entre elas.

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 15 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

A tabela abaixo apresenta um comparativo entre os principais modelos de processos


de desenvolvimento de software, com as principais caractersticas a serem
observadas antes de escolher o ciclo de vida adequado. Pessoal, isso uma
orientao genrica, no exato para todos os conceitos, mas ajuda bastante a
entend-los. Vejamos a tabela:
MODELO
CASCATA
INCREMENTAL
EVOLUTIVO
RAD
PROTOTIPAGEM
ESPIRAL
RUP

FOCO

REQUISITOS

1 VERSO P / CLIENTE

GERENCIAMENTO

Documentos e
artefatos
Incrementos
operacionais
Evoluo dos
requisitos
Rapidez de
desenvolvimento
Dvidas nos
requisitos
Anlise
de Risco
Frameworks e
boas prticas

Bem conhecidos e estticos

Fim do ciclo

Mais abstratos; tratados em


mdulos
Pouco conhecidos

Prottipos operacionais

Prottipos operacionais

Escopo restrito; mais abstratos;


tratado em mdulos
Mais abstratos

Prottipos operacionais

Prottipos no
operacionais
Prottipos operacionais
ou no operacionais
Prottipos operacionais
ou no operacionais

Mais abstratos; evoludos com


o tempo
Mais abstratos; evoludos com
o tempo

5
5

A ltima coluna, referente ao gerenciamento, revela em uma escala de 1 a 5 a


dificuldade de gerenciamento de cada processo (sendo 1 mais simples e 5 mais
complexo). O que diferencia um processo de software de outro a ordem em que
as fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades presentes
em cada um, e os produtos entregues como resultado.
Pessoal, a qualidade de um produto de software depende fortemente da qualidade
do processo de software utilizado em seu desenvolvimento. Logo, essencial ter
um processo de software adequado para se obter produtos de software de
qualidade. Seguir um processo de software mal escolhido ou definido pode
ocasionar prejuzos no andamento do projeto.
00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 16 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE
TCE/TO Analista de Sistemas Quanto maior e mais
complexo o projeto de software, mais simples deve ser o modelo de processo a
ser adotado.
Comentrios:
Galera, no existe essa relao! Em geral, quanto mais complexo o projeto mais
complexo o modelo. No entanto, isso tambm no uma regra.
Gabarito: E
(CESPE
TCE/TO Analista de Sistemas - O modelo de ciclo de vida
do software serve para delimitar o alvo do software. Nessa viso, no so
consideradas as atividades necessrias e o relacionamento entre elas.
Comentrios:
Pelo contrrio, o alvo do software serve para delimitar o modelo de ciclo de vida a
ser escolhido. Ademais, so consideradas as atividades necessrias e o
relacionamento entre elas.
Gabarito: E
(CESPE
TCE/TO Analista de Sistemas A escolha do modelo do
ciclo de vida no depende de caractersticas especficas do projeto, pois o melhor
modelo sempre o mais usado pela equipe do projeto.
00000000000

Comentrios:
No faz o menor sentido! A escolha depende das caractersticas do projeto.
Gabarito: E
ACERTEI

Prof. Diego Carvalho

ERREI

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 17 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

3. MODELO EM CASCATA
Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico
ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos
esses nomes j caram em prova!). Esse nome devido ao encadeamento simples
de uma fase com a outra. Os estgios do modelo demonstram as principais
atividades de desenvolvimento. Observem a imagem mais abaixo!
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase
anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases! Vejamos:

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 18 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma


srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja
satisfeito com os resultados alcanados. Vocs conseguem perceber como essas
restries engessam o desenvolvimento?
Por
Sommerville

Por
Yourdon

Por Pressman
(4 Ed.)

Por Pressman
(6 Ed.)

Por Royce

Definio de
Requisitos

Requisitos
de Sistema

Comunicao

Elicitao de
Requisitos

Projeto de Sistema
e Software
Implementao e
Teste de Unidade
Integrao e Teste
de Sistema
Operao e
Manuteno

Requisitos
de Software
Anlise

Modelagem e
Engenharia do
Sistema/Informao
Anlise de Requisitos
de Software
Projeto

Planejamento

Projeto

Modelagem

Construo

Projeto

Gerao de Cdigo

Construo

Integrao

Codificao

Teste e Manuteno

Implantao

Teste de
Depurao
Instalao

Teste
Operao

Manuteno
de Software

Percebam que h diferenas gritantes entre os autores! Inclusive, h divergncias


at entre autor e ele mesmo, dependendo da verso do livro (Exemplo: Pressman
mudou as fases na ltima edio de seu livro). Professor, voc j viu isso cair em
prova? Sim, j vi! E o que aconteceu? Bem, polmica, recursos, etc! No h o que
fazer... minha classificao preferida a do Yourdon.
Na prtica, esses estgios no so completamente sequenciais, i.e., eles se
sobrepem e trocam informaes entre si. Na teoria, so fases sequenciais com o
resultado de cada fase consistindo em um ou mais documentos aprovados ou no,
dependendo dos problemas. Por exemplo: durante o projeto, so identificados
problemas com requisitos.
00000000000

De modo geral, grande parte dos modelos possuem as seguintes fases:


Planejamento: faz-se o esboo do escopo e dos requisitos, alm de
estimativas razoveis sobre recursos, custos e prazos.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 19 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Anlise e Especificao de Requisitos: durante essa fase, refina-se os


requisitos e o escopo e desenha-se o problema em questo.
Projeto: durante essa fase, incorpora-se requisitos tecnolgicos aos requisitos
essenciais do sistema e projeta-se a arquitetura do sistema.
Implementao: durante essa fase, codifica-se o software como um conjunto
de programas executveis pela mquina.
Teste: o programa testado como um sistema completo para garantir que
os requisitos de software foram atendidos.
Implantao, Operao e Manuteno: o sistema de software liberado para
o cliente, treina-se usurios, gerencia servios e realiza manutenes.
Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma
desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da
fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como
pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde
as primeiras fases do processo de desenvolvimento.

00000000000

Percebam que os riscos deveriam ser descobertos logo no incio do processo de


desenvolvimento, porm eles so descobertos somente aps o incio dos testes e
integrao. Vocs podem notar que, nesse instante (parte vermelha), o progresso
do projeto avana e retrai diversas vezes, porque o sistema est sendo corrigido
devido a requisitos modificados.
Vejam, tambm, que o projeto no terminou em seu deadline original. Como a
reduo dos riscos atrasou, todo andamento do projeto tambm atrasou. Dessa
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 20 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

forma, no se cumpriu nem o prazo do projeto e, provavelmente, nem o oramento


e talvez seu escopo tendo em vista que, quanto mais ao fim do projeto um erro
identificado, mais caras se tornam as modificaes.
Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um
custo de correo altssimo, visto que provavelmente ter que se refazer tudo
novamente. Ora, se eu peo a construo de um carro e voc constri uma moto,
o custo para corrigir esse erro ser altssimo.
Portanto no confundam essas duas coisas:
o erro ocorreu no incio e foi
identificado no incio, ter baixo custo de correo; se o erro ocorreu no incio e foi
identificado no final, ter alto custo de correo. O custo de correo de um erro
est mais focado no momento em que um erro identificado do que no momento
em que ele ocorre. Bacana?

00000000000

Outra maneira de visualizar o atraso por meio de um grfico Risco x Tempo,


comparando o modelo em cascata com o Modelo Iterativo e Incremental. Observem
que o Modelo Iterativo e Incremental j comea a reduzir os riscos desde o incio

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 21 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

do processo, em contraste com o Modelo em Cascata que acumula os riscos at a


fase de testes, integrao e implantao do sistema.
Galera, a grande vantagem do Modelo em Cascata que o desenvolvimento
dividido em fases distintas, padronizadas, etc (antigamente, os softwares eram
construdos artesanalmente). possvel colocar pessoas com perfis especficos para
cada fase, i.e., quem tem facilidade de se comunicar vai ser analista de requisitos,
programadores vo fazer a codificao, etc.
A grande desvantagem que - em projetos complexos demora-se muito para
chegar at a fase de testes, sendo que o cliente no v nada rodando at a
implantao. Ento, pode acontecer de, nas fases finais, os requisitos da organizao
no serem mais os mesmos daqueles do incio e o software no ter mais utilidade
para organizao.
Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese?
Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs
entenderam?
Vantagens
simples de entender e fcil de aplicar, facilitando
o planejamento.
Fixa pontos especficos para a entrega de artefatos.

Desvantagens
Diviso inflexvel do projeto em estgios distintos.

Funciona bem para equipes tecnicamente fracas.

Clientes s visualizam resultados prximos ao final


do projeto.
Atrasa a reduo de riscos.

fcil de gerenciar, devido a sua rigidez.


Realiza documentao extensa por cada fase ou
estgio.
Possibilita boa aderncia a outros modelos de
processo.
Funciona bem com projetos pequenos e com
requisitos bem conhecidos.
00000000000

Dificuldade em incorporar mudanas de requisitos.

Apenas a fase final produz um artefato de software


entregvel.
Cliente deve saber todos os requisitos no incio do
projeto.
No fornece feedback entre as fases.
Pressupe que os requisitos ficaro estveis ao
longo do tempo.
No funciona bem com projetos complexos e
orientados a objetos, apesar de compatvel.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 22 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESGRANRIO 2010 PETROBRS Analista de Sistemas Processos de


Negcio) No Ciclo de Vida Clssico, tambm chamado de Modelo Sequencial
Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta
pelas seguintes atividades:
a) Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e
Manuteno.
b) Modelagem e Engenharia do Sistema/Informao, Anlise de Requisitos de
Software, Projeto, Gerao de Cdigo, Teste e Manuteno.
c) Modelagem e Engenharia do Sistema/Informao, Projeto, Gerao de
Cdigo, Teste e Manuteno.
d) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo e
Manuteno e Anlise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo, Teste
Progressivo e Manuteno.
Comentrios:
Por
Sommerville

Por
Yourdon

Por Pressman
(4 Ed.)

Por Pressman
(6 Ed.)

Por Royce

Definio de
Requisitos

Requisitos
de Sistema

Comunicao

Elicitao de
Requisitos

Projeto de Sistema
e Software
Implementao e
Teste de Unidade
Integrao e Teste
de Sistema
Operao e
Manuteno

Requisitos
de Software
Anlise

Modelagem e
Engenharia do
Sistema/Informao
Anlise de Requisitos
de Software
Projeto

Planejamento

Projeto

Modelagem

Construo

Projeto

Gerao de Cdigo

Construo

Integrao

Codificao

Teste e Manuteno

Implantao

Teste de
Depurao
Instalao

00000000000

Teste

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 23 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00
Operao

Manuteno
de Software

A Letra B est correta de acordo com o Pressman 4 Edio, mas est errada de
acordo com o Pressman 6 Edio. Ademais, na questo ele sequer disse que era
de acordo com o Pressman. Portanto, percebam que um assunto polmico e que
as bancas deveriam ignorar, mas eventualmente elas cobram mesmo assim.
Gabarito: B
(CESPE
INMETRO Analista de Sistemas) Em uma empresa que tenha
adotado um processo de desenvolvimento de software em cascata, falhas no
levantamento de requisitos tm maior possibilidade de gerar grandes prejuzos
do que naquelas que tenham adotado desenvolvimento evolucionrio.
Comentrios:
Vantagens
simples de entender e fcil de aplicar, facilitando
o planejamento.
Fixa pontos especficos para a entrega de artefatos.

Desvantagens
Diviso inflexvel do projeto em estgios distintos.

Funciona bem para equipes tecnicamente fracas.

Clientes s visualizam resultados prximos ao final


do projeto.
Atrasa a reduo de riscos.

fcil de gerenciar, devido a sua rigidez.


Realiza documentao extensa por cada fase ou
estgio.
Possibilita boa aderncia a outros modelos de
processo.
Funciona bem com projetos pequenos e com
requisitos bem conhecidos.

Dificuldade em incorporar mudanas de requisitos.

Apenas a fase final produz um artefato de software


entregvel.
Cliente deve saber todos os requisitos no incio do
projeto.
No fornece feedback entre as fases.

00000000000

Pressupe que os requisitos ficaro estveis ao


longo do tempo.
No funciona bem com projetos complexos e
orientados a objetos.

O Modelo em Cascata, de fato, no reage bem a mudanas. J Modelo


evolucionrio mais adaptvel a mudanas por se utilizar de iteraes.
Gabarito: C

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 24 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem


de facilitar a realizao de mudanas sem a necessidade de retrabalho em fases
j completadas.
Comentrios:
Vantagens
simples de entender e fcil de aplicar, facilitando
o planejamento.
Fixa pontos especficos para a entrega de artefatos.

Desvantagens
Diviso inflexvel do projeto em estgios distintos.

Funciona bem para equipes tecnicamente fracas.

Clientes s visualizam resultados prximos ao final


do projeto.
Atrasa a reduo de riscos.

fcil de gerenciar, devido a sua rigidez.


Realiza documentao extensa por cada fase ou
estgio.
Possibilita boa aderncia a outros modelos de
processo.
Funciona bem com projetos pequenos e com
requisitos bem conhecidos.

Dificuldade em incorporar mudanas de requisitos.

Apenas a fase final produz um artefato de software


entregvel.
Cliente deve saber todos os requisitos no incio do
projeto.
No fornece feedback entre as fases.
Pressupe que os requisitos ficaro estveis ao
longo do tempo.
No funciona bem com projetos complexos e
orientados a objetos.

Pelo contrrio, h dificuldade de lidar com requisitos volteis, tendo em vista que
dependendo do erro, necessrio refaz-lo desde seu incio.
Gabarito: E
(CESPE 2008 TST Analista de Sistemas) No modelo de desenvolvimento
sequencial linear, a fase de codificao a que gera erros de maior custo de
correo.
00000000000

Comentrios:
Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um
custo de correo altssimo, visto que provavelmente ter que se refazer tudo
novamente. Ora, se eu peo a construo de um carro e voc constri uma moto, o
custo para corrigir esse erro ser altssimo.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 25 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Portanto no confundam essas duas coisas! Percebam o que eu disse: quanto mais
tarde se descobre um erro, mais caro se torna sua correo. Dizendo isso de outra
forma: erros nas fases iniciais possuem custo de correo altssimo. Uma coisa o
momento em que o erro ocorre (quanto mais cedo, mais caro); outra coisa o
momento em que um erro identificado (quanto mais tarde, mais caro). Bacana?
Percebam que erros nas fases iniciais possuem custos de correo mais altos. Logo,
o maior custo est na fase de codificao? No, est na fase de requisitos que a
fase inicial!
Gabarito: E
(CESPE
INMETRO Analista de Sistemas) Em um processo de
desenvolvimento em cascata, os testes de software so realizados todos em um
mesmo estgio, que acontece aps a finalizao das fases de implementao.
Comentrios:
Por
Sommerville

Por
Yourdon

Por Pressman
(4 Ed.)

Por Pressman
(6 Ed.)

Por Royce

Definio de
Requisitos

Requisitos
de Sistema

Comunicao

Elicitao de
Requisitos

Projeto de Sistema
e Software
Implementao e
Teste de Unidade
Integrao e Teste
de Sistema
Operao e
Manuteno

Requisitos
de Software
Anlise

Modelagem e
Engenharia do
Sistema/Informao
Anlise de Requisitos
de Software
Projeto

Planejamento

Projeto

Modelagem

Construo

Projeto

Gerao de Cdigo

Construo

Integrao

Codificao

Teste e Manuteno

Implantao

Teste de
Depurao
Instalao

00000000000

Teste
Operao

Manuteno
de Software

Todos em um mesmo estgio, no. A grande maioria dos testes ocorrem, de fato,
aps a finalizao das fases de implementao. No entanto, podem ocorrer testes
unitrios durante a prpria implementao, como mostra o quadro acima.
Gabarito: E

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 26 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(FCC - 2012 - - - Analista Judicirio - Anlise de Sistemas - E) Dos diferentes


modelos para o ciclo de vida de desenvolvimento de um software correto
afirmar que o modelo em cascata o mais recente e complexo.
Comentrios:
Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico
ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos
esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de
uma fase com a outra. Os estgios do modelo demonstram as principais atividades
de desenvolvimento. Observem a imagem mais abaixo!
Mais recente? No, muito antigo! Complexo? No, possui um encadeamento simples
de fases.
Gabarito: E
10. (CESPE 2008 SERPRO Analista de Sistemas) O modelo em cascata consiste
de fases e atividades que devem ser realizadas em sequncia, de forma que uma
atividade requisito da outra.
Comentrios:
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase
anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases! Vejamos: (...)
00000000000

Vimos isso exaustivamente: no modelo em cascata, uma fase s se inicia aps o


trmino e aprovao da fase anterior.
Gabarito: C
- SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informao
11. (FCC - Prova 3 - O processo de engenharia de software denominado ciclo de vida
clssico refere-se ao modelo incremental.
Comentrios:

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 27 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico


ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos
esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de
uma fase com a outra. Os estgios do modelo demonstram as principais atividades
de desenvolvimento. Observem a imagem mais abaixo!
No, modelo clssico se refere a modelo em cascata, sequencial, linear, tradicional,
waterfall, rgido ou monoltico.
Gabarito: E
12. (CESPE
AL/ES Analista de Sistemas - O modelo de desenvolvimento
em cascata descreve ciclos sequenciais, incrementais e iterativos, possuindo,
entre outras, as fases de requisitos e implementao.
Comentrios:
No! Ele no descreve ciclos, muito menos ciclos iterativos. Na verdade, essa a
definio de Modelo Iterativo e Incremental.
Gabarito: E
13. (CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento
seqencial linear, tambm chamado modelo clssico ou modelo em cascata,
caracteriza-se por no acomodar adequadamente as incertezas que existem no
incio de um projeto de software, em especial as geradas pela dificuldade do
cliente de explicitar todos os requerimentos que o programa deve contemplar.
Comentrios:

00000000000

Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma
desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da
fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como
pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde
as primeiras fases do processo de desenvolvimento.
Perfeito, lembrem-se que ele acumula riscos e no lida bem com requisitos volteis.
Gabarito: C

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 28 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

14. (CESPE
IPEA Analista de Sistema) No modelo em cascata de processo
de desenvolvimento, os clientes devem definir os requisitos apenas durante a
fase de projeto; e os projetistas definem as estratgias de projeto apenas durante
a fase de implementao. As fases do ciclo de vida envolvem definio de
requisitos, projeto, implementao, teste, integrao, operao e manuteno.
Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.
Comentrios:
Essa questo no faz sentido! Os clientes definem os requisitos durante a fase de
Definio de Requisitos. J os projetistas definem as estratgias de projeto apenas
durante a fase Projeto.
Gabarito: E
15. (CESPE 2008 TCE/TO Analista de Sistema No ciclo de vida em cascata,
possvel realizar alternadamente e simultaneamente as atividades de
desenvolvimento de software.
Comentrios:
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase
anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases! Vejamos: (...)
No, sequencial e linear. No pode ser alternado e simultneo!
00000000000

Gabarito: E
A abordagem sistemtica
16. (CESPE 2004 TJ/PA Analista de Sistema
estritamente linear para o desenvolvimento de software denominada modelo
em cascata ou modelo sequencial linear.
Comentrios:
Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico
ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos
esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 29 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

uma fase com a outra. Os estgios do modelo demonstram as principais atividades


de desenvolvimento. Observem a imagem mais abaixo!
Perfeito! Modelo em Cascata, Linear, Sequencial, Waterfall, etc.
Gabarito: C
17. (CESPE 2006 TSE Analista de Sistema
O modelo em cascata organiza
o desenvolvimento em fases. Esse modelo encoraja a definio dos requisitos
antes do restante do desenvolvimento do sistema. Aps a especificao e a
anlise dos requisitos, tm-se o projeto, a implementao e o teste.
Comentrios:
Por
Sommerville

Por
Yourdon

Por Pressman
(4 Ed.)

Por Pressman
(6 Ed.)

Por Royce

Definio de
Requisitos

Requisitos
de Sistema

Comunicao

Elicitao de
Requisitos

Projeto de Sistema
e Software
Implementao e
Teste de Unidade
Integrao e Teste
de Sistema
Operao e
Manuteno

Requisitos
de Software
Anlise

Modelagem e
Engenharia do
Sistema/Informao
Anlise de Requisitos
de Software
Projeto

Planejamento

Projeto

Modelagem

Construo

Projeto

Gerao de Cdigo

Construo

Integrao

Codificao

Teste e Manuteno

Implantao

Teste de
Depurao
Instalao

ste
Operao
00000000000

Manuteno
de Software

Perfeito! De fato, segue essa ordem!


Gabarito: C
INMTRO Analista de Sistema) No desenvolvimento de
18. (CESPE
software, o modelo em cascata estruturado de tal maneira que as fases que
compem o desenvolvimento so interligadas. Nessa situao, o final de uma
fase implica o incio de outra.
Comentrios:
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 30 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase


anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases! Vejamos: (...)
Perfeito, conforme a definio.
Gabarito: C
19. (CESPE 2010 BASA Analista de Sistema) No modelo em cascata, o projeto
segue uma srie de passos ordenados. Ao final de cada projeto, a equipe de
projeto finaliza uma reviso. O desenvolvimento continua e, ao final, o cliente
avalia a soluo proposta.
Comentrios:
De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma
srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja satisfeito
com os resultados alcanados. Vocs conseguem perceber como essas restries
engessam o desenvolvimento?
Ao final de cada projeto? No! Ao final de cada fase.
Gabarito: E
(CESPE
TRE/MT Analista de Sistema O modelo em cascata
apropriado para software em que os requisitos ainda no foram bem
compreendidos, pois focado na criao de incrementos.
00000000000

Comentrios:
Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese?
Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs
entenderam?

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 31 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Pelo contrrio, totalmente errado!


Gabarito: E
O modelo em cascata
21. (CESPE 2009 UNIPAMPA Analista de Sistema
sugere uma abordagem sistemtica e sequencial para o desenvolvimento de
software. Sua natureza linear leva a estados de bloqueio nos quais, para que
nova etapa seja iniciada, necessrio que a documentao associada fase
anterior tenha sido aprovada.
Comentrios:
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase
anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases! Vejamos: (...)
Perfeito! No basta terminar uma fase, necessrio que a sua documentao tenha
sido aprovada.
Gabarito: C
(CESPE 2004 ABIN Analista de Sistema) O modelo de desenvolvimento
seqencial linear, tambm denominado modelo em cascata, incompatvel com
o emprego de tcnica de anlise orientada a objetos no desenvolvimento de um
sistema de informao.
Comentrios:

00000000000

Vantagens
simples de entender e fcil de aplicar, facilitando
o planejamento.
Fixa pontos especficos para a entrega de artefatos.

Desvantagens
Diviso inflexvel do projeto em estgios distintos.

Funciona bem para equipes tecnicamente fracas.


fcil de gerenciar, devido a sua rigidez.

Clientes s visualizam resultados prximos ao final


do projeto.
Atrasa a reduo de riscos.

Realiza documentao extensa por cada fase ou


estgio.

Apenas a fase final produz um artefato de software


entregvel.

Prof. Diego Carvalho

Dificuldade em incorporar mudanas de requisitos.

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 32 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00
Possibilita boa aderncia a outros modelos de
processo.
Funciona bem com projetos pequenos e com
requisitos bem conhecidos.

Cliente deve saber todos os requisitos no incio do


projeto.
No fornece feedback entre as fases.
Pressupe que os requisitos ficaro estveis ao
longo do tempo.
No funciona bem com projetos complexos e
orientados a objetos, apesar de compatvel.

Ele compatvel, mas no recomendado! Por que, no? Imagina um projeto super
complexo que utiliza uma anlise orientada a objetos (que um modelo mais
sofisticado que a anlise estruturada). Lembre-se que, no Modelo em Cascata, voc
no pode errar, porque se voc errar, os riscos de o projeto falhar so enormes! Por
essa razo, ele no recomendvel, apesar de compatvel!
Gabarito: E
(CESPE 2004 TRE/AL Analista de Sistema) O modelo cascata ou ciclo de
vida clssico necessita de uma abordagem sistemtica, que envolve, em primeiro
lugar, o projeto e, em seguida, a anlise, a codificao, os testes e a manuteno.
Comentrios:
Por
Sommerville

Por
Yourdon

Por Pressman
(4 Ed.)

Por Pressman
(6 Ed.)

Por Royce

Definio de
Requisitos

Requisitos
de Sistema

Comunicao

Elicitao de
Requisitos

Projeto de Sistema
e Software
Implementao e
Teste de Unidade
Integrao e Teste
de Sistema
Operao e
Manuteno

Requisitos
de Software
Anlise

Modelagem e
Engenharia do
Sistema/Informao
Anlise de Requisitos
de Software
Projeto

Planejamento

Projeto

Modelagem

Construo

00000000000

Projeto

Gerao de Cdigo

Construo

Integrao

Codificao

Teste e Manuteno

Implantao

Teste de
Depurao
Instalao

Teste
Operao

Manuteno
de Software

Primeiro Projeto e depois Anlise? No, Anlise vem antes do Projeto!


Gabarito: E
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 33 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

24. (CESPE
MPE/AM Analista de Sistema) O modelo de desenvolvimento
seqencial linear tem como caracterstica principal a produo de uma verso
bsica, mas funcional, do software desde as primeiras fases.
Comentrios:
Vantagens
simples de entender e fcil de aplicar, facilitando
o planejamento.
Fixa pontos especficos para a entrega de artefatos.

Desvantagens
Diviso inflexvel do projeto em estgios distintos.

Funciona bem para equipes tecnicamente fracas.

Clientes s visualizam resultados prximos ao final


do projeto.
Atrasa a reduo de riscos.

fcil de gerenciar, devido a sua rigidez.


Realiza documentao extensa por cada fase ou
estgio.
Possibilita boa aderncia a outros modelos de
processo.
Funciona bem com projetos pequenos e com
requisitos bem conhecidos.

Dificuldade em incorporar mudanas de requisitos.

Apenas a fase final produz um artefato de software


entregvel.
Cliente deve saber todos os requisitos no incio do
projeto.
No fornece feedback entre as fases.
Pressupe que os requisitos ficaro estveis ao
longo do tempo.
No funciona bem com projetos complexos e
orientados a objetos.

Pelo contrrio, somente nas fases finais que se tem uma verso! Essa definio est
mais com cara de modelo de desenvolvimento em prototipagem.
Gabarito: E
(VUNESP - 2012 - SPTrans - Analista de Informtica) Uma das abordagens do
processo de desenvolvimento da engenharia de software prev a diviso em
etapas, em que o fim de uma a entrada para a prxima. Esse processo
conhecido como modelo:
00000000000

a) Transformao.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
Comentrios:
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 34 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase


anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada
aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases!
Gabarito: E
ACERTEI

ERREI

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 35 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

4. MODELOS ITERATIVOS E INCREMENTAIS


Como foi dito anteriormente, o Modelo em Cascata acumulava riscos e vrios
projetos comearam a fracassar ao utiliz-lo no mundo inteiro. Ento surgiu o
Modelo Iterativo como uma tentativa de resolver esse problema de acmulo de
riscos. Vejamos a diferena fundamental entre o Modelo em Cascata e o Modelo
Iterativo:
No Modelo em Cascata, caso haja cem requisitos, analisa-se os cem
requisitos, projeta-se os cem requisitos, codifica-se os cem requisitos, testase os cem requisitos, e assim, por diante, sequencialmente.
No Modelo Incremental, caso haja cem requisitos no projeto, divide-se os
cem requisitos em vinte miniprojetos de cinco requisitos e utiliza-se o modelo
em cascata para cada miniprojeto.
Galera, pensem s: possvel combinar a abordagem incremental com uma
abordagem iterativa para desenvolver os miniprojetos em paralelo e entregar partes
diferentes do projeto. A imagem abaixo apresenta os miniprojetos de cinco
requisitos sendo feitos iterativamente e paralelamente em um modelo iterativo e
incremental.

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 36 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Assim, os resultados so mais rpidos, h maior interao com o usurio e h um


feedback mais intenso possvel reagir mais facilmente a mudanas. Essa
abordagem permite gerenciamento e mitigao de riscos. Professor, mas eu fiquei
com uma dvida: qual a diferena entre Modelo Iterativo e Modelo Incremental? Ou
eles so exatamente a mesma coisa?
Bem, galera... eu nunca vi nenhuma prova cobrar essa diferena entre modelo
iterativo e modelo incremental! Na verdade, quando se fala em modelo iterativo,
presume-se que incremental e quando se fala em modelo incremental, presumese que iterativo. Eles frequentemente andam lado a lado, mas h pequenas
diferenas.
IMPORTANTE
Galera, j vi essas palavras serem trocadas dezenas de vezes. No entanto, muitas vezes a prpria banca erra e, s
vezes, no volta atrs! Infelizmente isso acontece =(

Iterativo: reiterado ou repetitivo.


Interativo: participao ou ao mtua.

Professor, mas e se cair em prova? Ora, caso caia em prova, a diferena que, no
modelo iterativo, h vrias equipes desenvolvendo uma parte do software a serem
integradas no fim e, no modelo incremental, lana-se a verso 1.0, adicionam-se
funcionalidades, lana uma verso 2.0, adicionam-se mais funcionalidades e assim
por diante.

00000000000

Modelo Incremental: observem que a imagem mostra um artista com uma ideia
completa sobre o quadro, mas ele desenvolve cada parte separadamente at
integrar as partes em uma imagem completa. como se fosse um quebra-cabeas
em que cada parte entregue funcionando e depois integrada. Produz builds, i.e.,
partes do software.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 37 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Modelo Iterativo: observem que a imagem mostra um artista com um esboo do


quadro, sendo que ele desenvolve vrias verses do quadro at chegar ao resultado
final. como se fosse uma viso abstrata da imagem, que em seguida vai sendo
melhorada at chegar a uma viso mais concreta. Produz releases, i.e., verses
constantemente melhoradas da imagem.
Uma das vantagens do modelo iterativo e incremental que o cliente pode receber
e avaliar as entregas do produto mais cedo, j no incio do desenvolvimento do
software. Alm disso, h maior tolerncia a mudanas com consequncia direta de
reduo do risco de falha do projeto, i.e., ele acomoda melhor mudanas. Ele
aumenta o reso e a qualidade.

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 38 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o


processo de desenvolvimento de software modelado como uma sequncia
linear de fases, enfatizando um ciclo de desenvolvimento de breve durao.
Comentrios:
Na verdade, no linear iterativo.
Gabarito: E
27. (CESPE - 2011 TJ/ES - Analista Judicirio - Anlise de Sistemas - Especficos) O
modelo de processo incremental de desenvolvimento de software iterativo,
assim como o processo de prototipagem. Contudo, no processo incremental,
diferentemente do que ocorre no de prototipagem, o objetivo consiste em
apresentar um produto operacional a cada incremento.
Comentrios:
De fato, no modelo iterativo e incremental, apresenta-se sempre um produto a cada
incremento. J na prototipao, no. Idealmente, ele serve apenas para identificar
requisitos.
Gabarito: C
00000000000

(CESPE TJ/DF - Analista Judicirio - Anlise de Sistemas) No modelo de


desenvolvimento incremental, embora haja defasagem entre os perodos de
desenvolvimento de cada incremento, os incrementos so desenvolvidos em
paralelo.
Comentrios:
Questo perfeita. Os incrementos so codificados no exatamente em paralelo h
uma pequena defasagem.
Gabarito: C

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 39 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE UNIPAMPA - Anlise de Sistemas) No modelo de


desenvolvimento incremental, a cada iterao so realizadas vrias tarefas. Na
fase de anlise, pode ser feito o refinamento de requisitos e o refinamento do
modelo conceitual.
Comentrios:
Perfeito, a fase seguinte fase de requisitos e busca refin-los.
Gabarito: C
ACERTEI

ERREI

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 40 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

5. MODELOS EVOLUCIONRIOS
Antes de comearmos, eu acho oportuno explicar porque alguns autores
consideram o Modelo Evolucionrio como um tipo de Modelo Iterativo. Um dos
nossos guias, Pressman diz: Os modelos evolucionrios so iterativos, apresentando
caractersticas que possibilitam desenvolver verses cada vez mais completas do
software. Vamos ver isso melhor?
Ok, o tema agora Modelos Evolucionrios! Esse modelo baseia-se na ideia de
desenvolvimento de uma implementao inicial, expondo o resultado aos
comentrios do usurio e refinando esse resultado por meio de vrias verses at
que seja desenvolvido um sistema adequado ou descartando-o. Existem dois tipos
fundamentais de desenvolvimento evolucionrio:
Desenvolvimento Exploratrio (ou Evolutivo): comea com as partes do sistema
compreendidas e evolui por meio da adio de novas caractersticas propostas
pelo cliente at entregar o sistema final.
Prototipao Throwaway: tambm conhecida como descartvel, tem o intuito de
compreender os requisitos do cliente e, a partir disso, desenvolver melhor
definio de requisitos para o sistema.
Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por
que? Porque a especificao pode ser desenvolvida de forma incremental. medida
que os usurios compreendem melhor seu problema, isso pode ser refletido no
sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):
00000000000

O processo no visvel: se os sistemas so desenvolvidos rapidamente, no


vivel economicamente produzir documentos para cada verso do sistema.
Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem
a corromper a estrutura do software e tornar mudanas difceis e caras.
O Pressman recomenda o Desenvolvimento Evolucionrio para sistemas de
pequeno e mdio porte (at 500 mil linhas de cdigo). J para sistemas maiores e
mais complexos, esses problemas supracitados tornam-se mais graves. difcil

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 41 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

estabelecer uma arquitetura estvel, tornando difcil integrar as contribuies das


equipes.
Vamos resumir? um modelo que apresenta uma verso inicial aos usurios, com
os requisitos mais bem compreendidos, para refinamento do resultado verso a
verso. Pode ser Evolucionrio (quando evolui at o sistema final) ou Throwaway
(quando descartado). Ademais, recomendado para sistemas de pequeno e
mdio porte.

Um esboo simples do processo de desenvolvimento evolucionrio apresentado


na imagem acima. As atividades de especificao, desenvolvimento e validao so
intercaladas, em vez de separadas, com feedback rpido que permeia as atividades.
H dois modelos principais de desenvolvimento evolucionrio: Prototipagem e
Espiral.
00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 42 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(FGV 2008 Senado Federal Analista de Sistemas) No modelo evolucionrio,


a mudana constante tende a corromper a estrutura do software.
Comentrios:
Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por
que? Porque a especificao pode ser desenvolvida de forma incremental. medida
que os usurios compreendem melhor seu problema, isso pode ser refletido no
sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):
O processo no visvel: se os sistemas so desenvolvidos rapidamente, no
vivel economicamente produzir documentos para cada verso do sistema.
Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem
a corromper a estrutura do software e tornar mudanas difceis e caras.
Logo, percebemos que exatamente isso que acontece!
Gabarito: C
31. (CESPE
DETRAN/DF Analista de Sistemas) O modelo de processo de
desenvolvimento de software evolucionrio parte do desenvolvimento de uma
implementao inicial cujos resultados so apresentados aos clientes e refinados
por meio de vrias verses at que se alcance o sistema adequado. A
prototipao, como processo, tem por objetivo compreender as especificaes
do software para se chegar aos requisitos para o sistema.
00000000000

Comentrios:
Como ? Compreender as especificaes para chegar aos requisitos? No, isso no
faz sentido! compreender os requisitos para chegar especificao.
Gabarito: E

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 43 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE
TJ/DF Analista de Sistemas) A prototipao evolucionria no
gera problemas de manuteno de sistema porque o desenvolvimento rpido
e no sofre grandes mudanas.
Comentrios:
Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por
que? Porque a especificao pode ser desenvolvida de forma incremental. medida
que os usurios compreendem melhor seu problema, isso pode ser refletido no
sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):
O processo no visvel: se os sistemas so desenvolvidos rapidamente, no
vivel economicamente produzir documentos para cada verso do sistema.
Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem
a corromper a estrutura do software e tornar mudanas difceis e caras.
Gera problemas, sim! Muitas mudanas tendem a corromper a estrutura do software
e isso as torna difceis e caras.
Gabarito: E
(CESPE
TJ/DF Analista de Sistemas) A prototipao evolucionria
permite que a verso inicial do prottipo seja desenvolvida e refinada em
estgios sequenciados, at que se chegue verso final do sistema.
Comentrios:
00000000000

Ok, o tema agora Modelos Evolucionrios! Esse modelo baseia-se na ideia de


desenvolvimento de uma implementao inicial, expondo o resultado aos
comentrios do usurio e refinando esse resultado por meio de vrias verses at que
seja desenvolvido um sistema adequado ou descartando-o. Existem dois tipos
fundamentais de desenvolvimento evolucionrio:
Desenvolvimento Exploratrio (ou Evolutivo comea com as partes do sistema
compreendidas e evolui por meio da adio de novas caractersticas propostas
pelo cliente at entregar o sistema final.
Perfeito, essa a prototipao evolucionria ou exploratria.
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 44 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Gabarito: C
ACERTEI

ERREI

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 45 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

6. SCRUM
Algum de vocs sabe de onde vem esse nome? No? Ento eu vou contar! Esse
nome vem do Rugby e utilizado como uma metfora para refletir o alto grau de
cooperao necessria para obter sucesso. Imagino que poucos de vocs entendam
as regras desse esporte, portanto vou explicar de forma bastante objetiva o porqu
dessa metfora ser utilizada.
Nesse esporte, um time pontua quando a bola cruza a linha de gol e toca o cho
sendo carregada ou por meio de um passe. Caso o jogador seja derrubado, ele
deve soltar a bola, e a jogada se reinicia! Deve haver intensa troca de passes entre
os jogadores, de modo a deix-los menos vulnerveis a serem derrubados por
outros jogadores.

00000000000

Bem... cada jogada se inicia quando um Scrum realizado, isto , forma-se uma
parede de fora entre os jogadores, como mostra a imagem acima. Observem que
os jogadores se renem de forma bastante prxima, unindo suas foras e
habilidades para trabalhar em conjunto e harmonicamente a fim de conseguir
recuperar a bola.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 46 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Percebam, portanto, que o time inteiro deve trabalhar para que a equipe possa
pontuar. Diferentemente do Futebol Americano, no h um quarterback ou uma
estrela do time todos tm sua funo e so igualmente importantes! Pois , a
histria fica ainda mais interessante: vamos ver uma das recomendaes de ataque
do rugby.
Pensem continuamente em seu alinhamento em relao ao jogador que carrega a
bola e aos jogadores ao seu redor. Trabalhe duro para estar disponvel quando
necessrio. Observem como isso importante em metodologias geis: trabalhar
duro para ajudar a equipe a obter xito nunca existe: Acho que no h nada aqui
para eu fazer agora!
Acho que agora ficou mais fcil entender de onde vem esse nome vamos teoria?
Antes de comear, uma observao: o Guia Oficial do Scrum um documento to
pequeno (so apenas 18 pginas) que eu recomendo fortemente que vocs leiamno por inteiro, pois ser muito til! Tem verso em portugus, gratuito, ento no
custa nada l-lo. Bem... agora sim vamos ao trabalho!
Scrum um framework (isto , possui uma estrutura processual) leve, simples de
entender e extremamente difcil de dominar, para desenvolver e manter produtos
complexos e adaptativos, enquanto entrega produtiva e criativamente produtos
com o mais alto valor possvel. Complicado ou no? Galera, percebam que ele no
um processo ou uma tcnica para construir produtos.
Ele um framework em que pode ser empregado vrios processos e tcnicas. Pode
ser definido como um conjunto de papis, eventos, artefatos e regras associadas a
uma equipe. Ele fundamentado em teorias empricas de controle de processo e
emprega uma abordagem iterativa e incremental (maximizando as oportunidades
de feedback) para aperfeioar a previso e controle de riscos.
00000000000

O empirismo afirma que o conhecimento vem da experincia e da tomada de


decises com base naquilo que verdadeiro e conhecido. Para tal, ele emprega
uma abordagem iterativa e incremental para aperfeioar e otimizar a previsibilidade
e controle de riscos, fundamentando-se para tal em trs pilares fundamentais:
transparncia, inspeo (verificao) e adaptao.
Transparncia: aspectos significativos (e padronizados) devem estar visveis
aos responsveis pelos resultados. Por exemplo: uma linguagem comum a
todos os participantes.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 47 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Inspeo: os usurios devem frequentemente inspecionar os artefatos e o


progresso, para detectar indesejveis variaes (no pode ser frequente a
ponto de atrapalhar a execuo das tarefas).
Adaptao: o processo ou material sendo produzido deve ser adaptado
sempre que um inspetor verificar desvios que tornem o resultado inaceitvel
e, para tanto, ele tem quatros oportunidades (as reunies).
O Scrum define o conceito de Time Scrum que um time auto-organizvel (escolhe
qual a melhor forma para realizar seu trabalho) e multifuncional (possui todas as
competncias e no depende de outros de fora da equipe). o responsvel por
entregar produtos de forma iterativa e incremental, maximizando as oportunidades
de realimentao.
As entregas ou verses incrementais de produto (conhecido como pronto)
garantem que uma verso potencialmente funcional do produto do trabalho esteja
sempre disponvel. Agora o mais importante: o Time Scrum composto por:
Product Owner, um Scrum Master e uma Equipe de Desenvolvimento galera, no
confundam Equipe de Desenvolvimento com Time Scrum.
Product Owner:
o responsvel por maximizar o valor do produto e do trabalho da equipe de
desenvolvimento, sendo o nico que pode gerenciar o Product Backlog. Ele pode
at delegar as atividades de gerenciamento, mas ainda ser considerado o
responsvel pelos resultados. A Equipe de Desenvolvimento s responde a ele!
Equipe de Desenvolvimento
A Equipe de Desenvolvimento no reconhece ttulos para seus integrantes, todos
so considerados desenvolvedores (no importa o que faam). A Equipe deve ter
entre 3 e 9 integrantes, de modo que no seja pequena demais que haja restries
de habilidades nem grande demais que seja complicado de gerenciar.
00000000000

Scrum Master
o facilitador que garante que o Scrum seja entendido e aplicado. Ademais, ele
deve comunicar claramente a viso, objetivo e itens do Product Backlog; ensinar a
equipe a criar itens claros e concisos; treinar a equipe de desenvolvimento em
autogerenciamento e interdisciplinaridade; remover impedimentos; entre outros.
Certa vez, uma aluna me falou o seguinte: Professor, na minha opinio, o controle
e gerenciamento do projeto no descentralizado nesses trs papis. O Product
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 48 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Owner que responde pelo sistema, logo o gerenciamento e controle no


descentralizado centralizado no PO!. Eu resolvi, ento, fazer uma historinha para
que ela pudesse entender melhor. mais ou menos assim...
Imaginem que Joo deseja construir uma casa. Para tal, ele contrata uma renomada
empresa de engenharia. A empresa ir fornecer todo seu know-how por meio de
uma Equipe de Construo de Casas, que ser composta por uma Equipe de
Pedreiros, um Mestre de Obras e... por voc! Sim, voc far parte da Equipe de
Construo de Casas como principal parte interessada.
Vamos dar um nome para voc? Voc ocupar o cargo de Dono da Casa. Ora,
ento, a Equipe de Construo de Casas ser composta por uma Equipe de
Pedreiros, um Mestre de Obras e o Dono da Casa. E qual a funo de cada um?
Bem, a Equipe de Pedreiros composta por 3 a 9 pedreiros multidisciplinares i.e.,
todos dominam todas as atividades de um pedreiro.
Eles so os responsveis por colocar a mo na massa, levantar parede, fazer o
concreto, alinhar o piso, etc. J o Mestre de Obras o grande facilitador! Como
assim, professor? Ele vai retirar os impedimentos que aparecem no decorrer do
nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele ir buscar uma
maneira de reduzir os impactos dessa ausncia.
Os pedreiros esto desmotivados, distrados, descuidados? Ele ir arrumar uma
maneira de solucionar isso. Um pedreiro saiu na porrada com outro? Ele ir
intermediar o conflito. Alm disso, ele o cara que vai trazer a demanda do Dono
da Casa, entender o que ele quer e passar de maneira simples, clara e objetiva para
a Equipe de Pedreiros.
E, por fim, ele tambm ir treinar a equipe para que ela seja auto gerencivel e
interdisciplinar. E voc? Qual a sua funo? Voc o Dono da Casa voc que
gerencia o que ser feito e o que no ser feito. Voc o responsvel pelo que ser
entregue. A Equipe de Pedreiros responde a voc! O Mestre de Obras responde a
voc!
00000000000

Voc o cara que tem que tentar fazer essa casa ficar o melhor possvel (Mximo
Valor Agregado). Voc o cara que vai priorizar o que deve ser feito primeiro. Voc
o cara que coloca ou tira atividades da lista atividade a serem realizadas. Voc
o nico cara que pode simplesmente cancelar determinada atividade. Pessoal, h
pequenas diferenas, mas a metfora evidente.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 49 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

A Equipe de Construo de Casas o Scrum Team; a Equipe de Pedreiros o


Development Team; o Mestre de Obras o Scrum Master; e o Dono da Casa o
Product Owner. Bacana? Cada um desses tem atividades bem definidas. E o controle
sobre essas atividades descentralizado, ou seja, o Dono da Casa no interfere na
parte tcnica dos pedreiros, que no interferem no trabalho do Mestre de Obras.
Pensem em uma repartio pblica que contm uma Coordenao dividida em 4
gerncias. Ora, o controle e a gesto so descentralizados, feitos por cada gerncia
mesmo que todas elas tenham que responder ao coordenador. Bem, acredito que
dessa forma consegui convenc-la e faz-la entender melhor o papel de cada um
desses caras. Certinho? Ficou mais claro agora?
Mudando de assunto, os Eventos Scrum so eventos time-boxed (isto , com
durao mxima predefinida) usados para criar uma rotina e minimizar a
necessidade de reunies no definidas pelo Scrum. Lembrem-se de que a Sprint
tem um ms ou menos e iniciada imediatamente aps a concluso da sprint
anterior.
As Sprints so compostas por uma Reunio de Planejamento da Sprint, por Reunies
Dirias, pelo Trabalho de Desenvolvimento, por uma Reviso da Sprint e pela
Retrospectiva da Sprint. Uma sprint se inicia imediatamente aps a concluso da
sprint anterior e tem duraes coerentes em todo o esforo de desenvolvimento.
Durante a sprint proibido realizar mudanas que afetem o seu objetivo.
Alm disso, proibido mudar a composio da equipe ou diminuir as metas de
qualidade, apesar disso o escopo pode ser sempre clarificado e renegociado. Uma
sprint pode ser cancelada antes de seu time-box terminar e isso somente pode ser
feito pelo Product Owner (sob influncia de stakeholders, equipe de
desenvolvimento, entre outros).
00000000000

Isso pode ocorrer caso o seu objetivo se torne obsoleto, mas ocorrem tambm
devido curta durao e a cancelamentos, porm so raros os casos. O trabalho a
ser realizado na Sprint planejado na Reunio de Planejamento da Sprint
(Proporcional a 8 horas). Essa reunio consiste em duas perguntas que devem ser
adequadamente respondidas:
1. O que ser entregue como resultado do incremento da prxima Sprint?
2. Como o trabalho necessrio para entregar o incremento ser realizado?

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 50 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Na primeira parte, a Equipe de Desenvolvimento tenta prever as funcionalidades


e sero desenvolvidas durante a Sprint. Na segunda parte, a Equipe de
Desenvolvimento decide como ir construir essas funcionalidades durante a Sprint
e desenvolve o Sprint Backlog. Portanto, a primeira parte trada do O que fazer? e
a segunda trata do Como fazer?.

O Product Owner pode estar presente durante a segunda parte da reunio para
clarificar itens do Backlog do Produto. A Reunio Diria (Proporcional a 15 minutos)
um evento que busca criar um plano para as prximas 24 horas e inspecionar o
trabalho desde a ltima Reunio Diria. Ela ocorre sempre no mesmo horrio e no
mesmo local e cada integrante deve responder as seguintes perguntas:
00000000000

1. O que foi completado desde a ltima reunio?


2. O que ser feito at a prxima reunio?
3. Quais os obstculos que esto no caminho?
As Reunies Dirias melhoram a comunicao entre os integrantes, eliminam a
necessidade de outras reunies, identificam e removem impedimentos, destacam e
promovem rpidas tomadas de deciso, e melhoram o nvel de conhecimento da

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 51 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Equipe. A Reviso da Sprint (Proporcional a 4 horas) executada no final da Sprint


para inspecionar o incremento e adaptar o Backlog do Produto, se necessrio.
Esta uma reunio informal e a apresentao do incremento destina-se a motivar
e obter comentrios e promover a colaborao. Nesta reunio, discute-se entre
outras coisas: o que foi bem e o que no foi; problemas ocorridos e como foram
resolvidos; Product Backlog; projees de datas. O resultado o Product Backlog
revisado e ajustado.
A Retrospectiva da Sprint (Proporcional a 3 horas) uma chance para o Scrum Team
inspecionar a si prprio e criar um plano de melhorias para a prxima sprint. Ela
inspeciona como foi a ltima sprint em relao s pessoas, s relaes, aos
processos e s ferramentas. Pode identificar e ordenar os itens que se tornaram
potenciais de melhorias e cria um plano para implementar melhorias no trabalho.

00000000000

O Documento de Viso definido pelo Product Owner e representa como os


clientes, usurios finais, gerentes, stakeholders, executivos, entre outros, visualizam
o resultado final do produto que ser criado. Prticas como Burndown/Burnup tm
sido utilizadas para prever o progresso, sem substituir a importncia do empirismo,
como mostra a imagem.
O Product Backlog uma lista ordenada (por valor, risco, prioridade etc) de tudo
que deve ser necessrio no produto, e uma origem nica dos requisitos para
qualquer mudana a ser feita no produto. Ele nunca (EU DISSE: NUNCA!) estar
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 52 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

completo e existir enquanto o produto tambm existir. O ciclo de vida da SCRUM


baseado em trs fases principais, divididas em sub-fases:
1) Pr-Planejamento (Pre-game Phase): define o sistema sendo desenvolvido. Criase o Product Backlog, que contm todos os requisitos atuais e informaes sobre
o planejamento do projeto. Cria-se tambm uma arquitetura de alto nvel.
2) Desenvolvimento (Game Phase): o sistema desenvolvido em sprints, por meio
de uma abordagem iterativa. A cada sprint, novas funcionalidades so
adicionadas de modo tradicional, i.e., anlise, projeto, implementao, etc.
3) Ps-Planejamento (Post-game Phase): aps a fase de desenvolvimento so feitas
reunies para analisar o progresso do projeto e demonstrar o software atual para
os clientes. Aqui so feitas as etapas de integrao, testes finais e documentao.

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 53 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

34. (FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software - A)


Um dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software a implantao de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco
previsveis. Para tanto, o gerenciamento distribudo por meio de trs agentes
independentes que so: Product Owner, Scrum Team e Scrum Master.
Comentrios:
Guia Scrum diz que o Scrum Team dividido em Product Owner, Scrum Master e
Development Team. No entanto, a FCC deu a resposta como correto. Por que? No
fao ideia!
Gabarito: C
(FCC - 2010 - TRE-RS - Analista Judicirio - Analista de Sistemas Suporte - E Os
princpios Scrum so usados para guiar as atividades de desenvolvimento dentro
de um processo que incorpora as seguintes atividades de arcabouo: requisitos,
anlise, projeto, evoluo e entrega. Em cada atividade de arcabouo, as tarefas
de trabalho ocorrem dentro de um padro de processo chamado sprint.
Comentrios:
Perfeito, isso mesmo! Trata-se de uma Sprint.
00000000000

Gabarito: C
(FCC - 2010 - TRF - 4 REGIO - Analista Judicirio - Tecnologia da InformaoE) Na fase de desenvolvimento do Scrum, o software desenvolvido em
processos iterativos denominados Sprint.
Comentrios:
Perfeito, isso mesmo! Trata-se tambm de uma Sprint.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 54 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Gabarito: C
37. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - E) Em
reunio, toda conversao restringida s respostas dos elementos s perguntas
colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver at
a prxima reunio?". As Scrum meetings ocorrem diariamente.
Comentrios:
Perfeito! Essa uma das trs perguntas feitas pelo Scrum Master e a Scrum Meeting
citada a Daily Scrum Meeting ou Reunio Diria.
Gabarito: C
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - A) Em relao s
regras do Scrum, incorreto afirmar que o Sprint deve ser realizado num perodo
mximo de 40 dias e ter uma equipe de trabalho no superior a 10 pessoas.
Comentrios:
De fato, est incorreto! O perodo mximo de 30 dias e a equipe de trabalho varia
de 3 a 9 pessoas.
Gabarito: C
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - B) Em relao s
regras do Scrum, incorreto afirmar que se o Sprint tomar um rumo no
desejado, possvel dissolv-lo e comear um novo Sprint, baseando num novo
Sprint Backlog.
00000000000

Comentrios:
Na verdade, no correto! possvel dissolver uma sprint e comear outra
baseando-se em um no sprint backlog quem pode fazer isso o Product Owner.
Gabarito: E
40. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - C) Em relao s
regras do Scrum, incorreto afirmar que as reunies durante um Sprint devem

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 55 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

ser dirias, sempre mesma hora e no mesmo local e no devem durar mais
que 30 minutos.
Comentrios:
Bem, ela deve durar no mximo 15 minutos, no entanto a questo diz que no deve
durar mais que 30 minutos (o que no errado!). Portanto, no incorreto afirmar
isso correto afirmar isso!
Gabarito: E
41. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - D) Em relao s
regras do Scrum, incorreto afirmar que toda conversao restringe as respostas
dos participantes s trs perguntas do Scrum Master: O que desenvolveu desde
a ltima reunio? Que dificuldades encontrou durante o seu trabalho? O que
planeja desenvolver at a prxima reunio?
Comentrios:
Na verdade, no incorreto! Essas so, de fato, as perguntas a serem feitas.
Gabarito: E
42. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - E) Em relao s
regras do Scrum, incorreto afirmar que com base nas respostas s trs
perguntas, o Scrum Master deve imediatamente tomar decises, quando
necessrias, para remover todas as situaes que impeam a agilidade do
trabalho.
00000000000

Comentrios:
Tambm no incorreto! exatamente isso que o Scrum Master deve fazer.
Gabarito: E
43. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - A)
Durante a realizao do Sprint, o Backlog pode ser modificado por qualquer um
dos elementos da equipe, desde que acordado nas reunies semanais.
Comentrios:
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 56 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Backlog? Qual Backlog? A questo deveria ter dito! De todo modo, o Product
Backlog s pode ser modificado pelo Product Owner e o Sprint Backlog s pode ser
modificado pelo Development Team (em termos de atividades e, no, objetivos).
Gabarito: E
44. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - B) O
Sprint deve ser realizado num perodo no superior a 30 dias e ter um objetivo
bem claro, baseado no Backlog.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
45. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - C)
Modificao no Backlog prerrogativa do Scrum Master, quando achar
necessrio, em qualquer momento no decorrer do Sprint.
Comentrios:
Scrum Master apenas um facilitador! Quem pode modificar o Product Backlog
o Product Owner.
Gabarito: E
46. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistema - D) No
possvel dissolver um Sprint. Se houver algum risco de ele tomar um rumo no
desejvel, novas funcionalidades devem ser implementadas para garantir o
prazo do projeto.
00000000000

Comentrios:
No. possvel, sim, dissolver uma sprint.
Gabarito: E

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 57 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

47. CC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - E) O foco


na produtividade se estende s Scrum Meetings e a conversao pautada em
discusses por toda a equipe.
Comentrios:
Na verdade, as discusses ocorrem mais entre as pessoas da equipe de
desenvolvimento.
Gabarito: E
48. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - B) No
SCRUM, o produto final, a data final e o custo do projeto so determinados ao
longo do projeto.
Comentrios:
isso mesmo so todos definidos ao longo do projeto!
Gabarito: C
49. (FCC AFR/SP Analista de Sistemas O conceito de sprint aplica-se ao
modelo gil do processo de engenharia de software denominado:
a)
b)
c)
d)
e)

Crystal.
XP.
DAS.
DSDM.
Scrum

00000000000

Comentrios:
Sprint? Trata-se do Scrum!
Gabarito: E
(FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas E) Enquanto o
XP mais receptivo a mudanas durante a iterao, no SCRUM as solicitaes
do cliente devem aguardar o trmino da iterao em andamento.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 58 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Comentrios:
O Scrum Guide diz: Durante a sprint: no so feitas mudanas que podem afetar o
objetivo da sprint. (...)Se a Equipe de Desenvolvimento determina que tem excesso ou
falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o Product
Owner. A questo trata de solicitaes do cliente, sem especificar se modifica os
objetivos da sprint ou no. De todo modo, acredito que podemos considerar que
so solicitaes que modificam os objetivos da sprint, portanto item verdadeiro.
Gabarito: C
51. (CESPE - 2013 - ANP - Analista Administrativo - rea 5) De acordo com a
metodologia Scrum, a constituio ideal da equipe de desenvolvimento para que
o trabalho se mantenha gil deve ser de menos de trs pessoas.
Comentrios:
Na verdade, recomenda-se entre trs e nove participantes. Com menos de trs
participantes, reduz-se a interao, que gera um menor ganho de produtividade.
Gabarito: E
(CESPE - 2012 - ANAC - Analista Administrativo - rea 4) O nico papel definido
pelo Scrum com autoridade para cancelar uma Sprint o do product owner.
Comentrios:
De fato, apenas o Product Owner pode cancelar uma sprint.
00000000000

Gabarito: C
(CESPE - 2012 - ANAC - Analista Administrativo - rea 4) Uma sprint do Scrum
tem durao prevista de 2 meses.
Comentrios:
Uma sprint deve ter entre duas e quarto semanas.
Gabarito: E

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 59 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

54. (CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Arquitetura de


Tecnologia) O Scrum utilizado, como funo primria, para o gerenciamento
de projetos de desenvolvimento de software, mas tambm tem sido usado como
extreme programming e outras metodologias de desenvolvimento.
Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um
grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum.
Comentrios:
Questo perfeita. Scrum est para o PMBOK, assim como o XP est para o RUP. Ele
pode ser utilizado, em teoria, em qualquer contexto em que se necessite atingir um
objetivo comum entre um grupo de pessoas.
Gabarito: C
(CESPE - 2013 - ANTT - Analista Administrativo Analista de Sistemas) Entre os
vrios papis do SCRUM, o product owner a nica pessoa responsvel por
gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
Comentrios:
Literalmente retirado do Guia Scrum perfeito!
Gabarito: C
(CESPE - 2013 - SERPRO - Analista de Informtica Analista de Sistemas) Scrum
um processo de desenvolvimento que tem como ponto de partida um
conjunto de requisitos bem definidos.
00000000000

Comentrios:
Conjunto de requisitos bem definidos? No, o contrrio. Geralmente, trata-se de
requisitos pouco definidos.
Gabarito: E
57. (CESPE - 2013 TCE-RO - Analista de Informtica Analista de Sistemas) Na
metodologia Scrum, a equipe trabalha nos processos e no h cargos na equipe.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 60 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Como um dos papis necessrios, o Scrum Master deve garantir que o processo
seja entendido e atuar como facilitador para ajudar a equipe.
Comentrios:
exatamente isso! Lembrem-se de que no h cargos, mas papis!
barito: C
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) Em um
projeto gerido com a metodologia Scrum, um produto estar, ao final de cada
sprint, completamente testado, estando 100% completos todos os requisitos do
product backlog.
Comentrios:
Galera, essa muito fcil! Nenhum produto estar nunca completamente testado,
ademais o Product Backlog tambm nunca estar completo.
Gabarito: E
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) O escopo,
a importncia e a estimativa de um Sprint do Scrum so definidos pelo product
owner.
Comentrios:
Opaaaa... Product Owner no trata de estimativas. Entendam: escopo e importncia
so definidos pelo PO, no entanto quem define estimativas a Equipe de
Desenvolvimento.
00000000000

Gabarito: E
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) A
metodologia Scrum, gil para gerncia de projetos, baseia-se em ciclos de 30
dias, denominados sprints, em que se trabalha para alcanar objetivos bem
definidos.
Comentrios:

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 61 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Perfeito, isso mesmo.


Gabarito: C
61. (CESPE - 2011 ECT - Analista de Informtica Analista de Sistemas) Para que
se obtenha sucesso na utilizao do Scrum, o cliente deve se tornar parte da
equipe de desenvolvimento do software, participando diretamente do processo.
Comentrios:
Bem, o cliente no se torna parte da equipe de desenvolvimento. H sim uma
forte integrao, no entanto dizer que faz parte da equipe de desenvolvimento
um completo absurdo. No entanto, o CESPE no entendeu dessa maneira.
Gabarito: C
(CESPE - 2011 MEC - Analista de Informtica Analista de Sistemas) O
framework scrum engloba conceitos como times scrum, eventos com durao
fixa (time-boxes), artefatos e regras. So exemplos de eventos que tm durao
fixa: a reunio de planejamento da verso para entrega, a sprint, a reunio diria,
a reviso da sprint e a retrospectiva da sprint.
Comentrios:
Cara, a questo peca um pouco em dizer que um evento com durao fixa. Por
que, professor? Porque o conceito de time-box aquilo que tem uma durao
mxima fixa (Ex: Sprint <= 30 dias). Eu entendo que caberia recurso nessa questo.
00000000000

Gabarito: C

(CESPE - 2011 MEC - Analista de Informtica Analista de Sistemas) 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.
Comentrios:
Galera, item perfeito! Muito bem escrito!
Gabarito: C
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 62 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

64. (CESPE - 2010 MPU - Analista de Informtica Analista de Sistemas) Um


princpio chave do Scrum o reconhecimento de que desafios
fundamentalmente empricos no podem ser resolvidos com sucesso utilizandose uma abordagem tradicional de controle. O Scrum adota uma abordagem
emprica, aceitando que o problema no pode ser totalmente entendido ou
definido, focando na maximizao da habilidade da equipe de responder de
forma gil aos desafios emergentes.
Comentrios:
Questo perfeita, retirada do Guia Scrum!
Gabarito: C
(CESPE - 2010 MPU - Analista de Informtica Analista de Sistemas) A
metodologia Scrum facilitada por um scrum master, que atua como um
mediador entre a equipe e qualquer influncia desestabilizadora, alm de
assegurar que a equipe esteja utilizando corretamente as prticas de Scrum,
motivando e mantendo o foco na meta da sprint.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
(CESPE - 2012 TER-RJ - Analista de Informtica Analista de Sistemas) A
metodologia scrum prega que a equipe complete e entregue partes do produto
final constantemente ao final de cada interao. Essa interao deve ser curta e
possuir tempo de execuo definido previamente.
00000000000

Comentrios:
J li isso 800x e as bancas continuam errando! Escreve-se ITERAO e, no,
INTERAO! A questo deveria ter sido anulada, mas no foi! =/
Gabarito: C

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 63 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

67. (CESPE - 2013 ANCINE Analista de Sistemas) Na reunio de planejamento do


sprint backlog, se o product owner afirmar que todos os requisitos do produto
foram identificados, correto concluir que o backlog do produto est completo,
visto que este uma lista ordenada de todos os requisitos necessrios para o
desenvolvimento do produto.
Comentrios:
Galera, correto concluir que o backlog do produto est completo? No! O Product
Backlog nunca est completo, pois os requisitos esto sempre mudando.
Gabarito: E
(CESPE - 2013 ANCINE Analista de Sistemas) Se for averiguado, em uma
organizao, que o Scrum Master gerencia o backlog do produto, correto
afirmar que houve falha na execuo de papis, visto que cabe unicamente ao
product owner gerenciar o backlog do produto.
Comentrios:
Perfeito! Somente o Product Owner pode gerenciar o Product Backlog.
Gabarito: C
(CESPE - 2010 MPU Analista de Sistemas) Scrum um processo gil de
produo de software que mantm o foco na entrega da maior parte do
produto, no menor tempo possvel.
Comentrios:

00000000000

Galera, essa questo polmica! O Scrum preconiza que se entregue primeiro as


funcionalidades mais importantes (coincidentemente, as mais importantes podem
representar a maior parte, mas no necessariamente). Ademais, a questo d a
entender que o Scrum busca entregas rpidas e, no, geis. Portanto, em minha
opinio est incorreta. No entanto, o gabarito oficial foi verdadeiro.
Gabarito: C
70. (CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e
Manuteno de Sistemas) No Scrum, o Product Owner (PO) responsvel por
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 64 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

definir a viso do produto e remover os impedimentos, enquanto o Scrum


Master (SM) responsvel por elaborar e manter o Product Backlog, bem como
por ajudar o PO a executar suas atividades dirias.
Comentrios:
Os papeis esto invertidos, i.e., PO elabora e mantm o Product Backlog e define a
viso do produto. J o SM remove impedimentos e auxilia o PO a executar suas
atividades dirias.
Gabarito: E
71. (CESPE - 2013 - ANP - Analista Administrativo - rea 5) O ciclo de vida da
metodologia Scrum se divide nas fases de pr-planejamento, desenvolvimento
e ps-planejamento. O documento denominado product backlog gerado na
fase de desenvolvimento.
Comentrios:
Na verdade, na fase de Pr-Planejamento.
Gabarito: E
72. (CESPE - 2012 - TCE-ES - Auditor de Controle Externo - Tecnologia da
Informao) O Product Backlog, um dos artefatos utilizados na metodologia gil
denominada Scrum, constitui-se da lista priorizada de todos os requisitos do
produto final.
Comentrios:

00000000000

Sprint Backlog contm a lista de requisitos da sprint e o Product Backlog contm


todos os requisitos do produto final. Apesar do todos, est correta! Quando
dizemos que o Product Backlog nunca est completo, porque ele dinmico
ele muda!
No incio, ele ser pequeno, com o passar do tempo ele vai aumentando,
eventualmente diminuindo, e assim por diante. Em determinado momento,
provavelmente na ltima sprint, ele conter todos os requisitos do produto final.
Gabarito: C
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 65 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

73. (CESPE - 2014 ANATEL Arquitetura de Solues) O Scrum um conjunto


simples e eficaz de regras e ferramentas que so utilizadas para maximizar
resultados. O ScrumMaster exerce o papel de facilitador e motivador da equipe,
alm de garantir que as regras e as ferramentas sejam utilizadas com vistas
criatividade do trabalho e ao retorno do investimento.
Comentrios:
Scrum Master
o facilitador que garante que o Scrum seja entendido e aplicado. Ademais, ele deve
comunicar claramente a viso, objetivo e itens do Product Backlog; ensinar a equipe
a criar itens claros e concisos; treinar a equipe de desenvolvimento em
autogerenciamento e interdisciplinaridade; remover impedimentos; entre outros.
De fato, ele o facilitador e motivador da equipe ele garante que as regras e
ferramentas sejam de fato utilizadas.
Gabarito: C
ACERTEI

ERREI

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 66 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

7. EXTREME PROGRAMMING (XP)


Em 1996, Kent Beck desenvolveu um novo paradigma de
desenvolvimento de software que rompia com grande parte
das metodologias tradicionais e a batizou de Extreme
Programming. Por que extremo? Porque ele recomenda que
as boas prticas sejam levadas ao extremo! Ahn? Como
assim, professor?

Testar bom?
Iterar bom?
Integrar bom?

Ento vamos testar toda hora!


Ento vamos iterar toda hora!
Ento vamos integrar toda hora!

O XP uma metodologia gil de desenvolvimento de software para equipes


pequenas, coesas e multidisciplinares cujos projetos possuem requisitos vagos e em
constante mudana. Ele parte do princpio de que o cdigo-fonte a melhor
documentao, pois qualquer outra se torna rapidamente desatualizada e perde
sua confiabilidade.
No eXtreme Programming, todos os requisitos so expressos como cenrios
(tambm chamados histrias do usurio), que so implementados diretamente
como uma srie de tarefas. Os programadores trabalham em pares e desenvolvem
testes para cada tarefa antes da escrita do cdigo. Sempre que h integrao, h
novos testes e o usurio prioriza esses requisitos para o desenvolvimento.
A equipe de desenvolvimento avalia cada cenrio e o divide em tarefas. Cada tarefa
representa uma caracterstica discreta do sistema e um teste unitrio pode ent
ser projetado para essa tarefa. Os Testes de Aceitao (ou Testes de Cliente) so
especificados pelo cliente e mantm o foco nas caractersticas e na funcionalidade
do sistema total que so visveis e que podem ser revistas pelo cliente.
00000000000

Os testes de aceitao so obtidos de histrias de usurios implementadas como


parte de uma verso de software. O desenvolvimento incremental apoiado por
pequenos e frequentes releases do sistema e por uma abordagem de descrio de
requisitos baseada nos cenrios do cliente. Ademais, o envolvimento do cliente em
tempo integral facilita o desenvolvimento e melhora a qualidade do produto.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 67 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

PROCESSO PARA DESENVOLVER UM INCREMENTO

Prtica
Planejamento
Incremental

Pequenos
Releases

Descrio
Os requisitos so registrados em cartes de histrias e as
histrias a serem includas em um release so determinadas
pelo tempo disponvel e sua prioridade relativa. Os
desenvolvedores dividem essas histrias em tarefas.
O conjunto mnimo til de funcionalidade que agrega valor ao
negcio desenvolvido primeiro. Releases do sistema so
frequentes e adicionam funcionalidade incrementalmente ao
primeiro release.
00000000000

Projeto
Simples

realizado um projeto suficientemente simples de modo que


atenda aos requisitos atuais e nada mais. Deve-se lembrar que
um cdigo simples no cdigo fcil.

Um framework automatizado de teste unitrio usado para


Desenvolvimento escrever os testes para uma nova parte da funcionalidade
Test-First
antes que esta seja implementada. Portanto, primeiro se
escreve o teste, depois faz-se a implementao.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 68 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Refactoring

Espera-se que todos os desenvolvedores recriem o cdigo


continuamente to logo os aprimoramentos do cdigo forem
encontrados. Isso torna o cdigo simples de entender e fcil
de manter.

Programao
em Pares

Os desenvolvedores trabalham em pares, um verificando o


trabalho do outro e fornecendo apoio para realizar sempre
um bom trabalho. Eles utilizam o mesmo mouse, teclado e
monitor.

Propriedade
Coletiva

Os pares de desenvolvedores trabalham em todas as reas do


sistema, de tal maneira que no se formem ilhas de
conhecimento, com todos os desenvolvedores de posse de
todo o cdigo. Qualquer um pode mudar qualquer coisa.

Integrao
Contnua

To logo o trabalho em uma tarefa seja concludo, este


integrado ao sistema como um todo. Depois de qualquer
integrao, todos os testes unitrios do sistema devem ser
realizados.

Ritmo
Sustentvel

Metforas

Grandes quantidades de horas extras no so consideradas


aceitveis, pois, no mdio prazo, h uma reduo na
qualidade do cdigo e na produtividade. Trabalhar por longos
perodos se torna contraproducente (Recomenda-se 40 horas
semanais).
A equipe se comunica sobre o desenvolvimento de software
por meio de metforas, caso consiga encontrar uma que
realmente faa sentido dentro do contexto e possa facilitar a
comunicao.
00000000000

Cliente
-site

Um representante do usurio final do sistema deve estar


disponvel em tempo integral para apoiar a equipe. No XP, o
cliente um membro da equipe de desenvolvimento e
responsvel por trazer os requisitos do sistema.

Reunies
em P

Reunies so realizadas em p para no se perder o foco nos


assuntos, produzindo reunies mais rpidas, somente
abordando as tarefas realizadas e tarefas a realizar pela
equipe no futuro.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 69 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Time
Coeso

Jogo do
Planejamento

A equipe de desenvolvimento formada por pessoas


engajadas e multidisciplinares, i.e., elas possuem habilidades
para diversas reas do projeto.

O planejamento de um release e das iteraes so feitos com


base nas histrias e conta com a colaborao de toda equipe
de desenvolvimento, inclusive o cliente, divididos em papeis:
negcio e tcnico. Os clientes priorizam e os desenvolvedores
avaliam e estimam.

Vejamos o Processo Extreme Programming! Sabe-se que a abordagem orientada a


objetos o paradigma de desenvolvimento preferido do XP e envolve um conjunto
de regras e prticas constantes no contexto de quatro atividades metodolgicas
principais: Planejamento, Projeto, Codificao e Teste. Observem-nas na imagem
abaixo como funciona:

00000000000

O XP apresenta cinco Valores Fundamentais1:


Comunicao: para se desenvolver um sistema de software, exige-se comunicar
os requisitos de sistema para os desenvolvedores. Em metodologias formais de
desenvolvimento de software, esta tarefa realizada por meio de
documentao. O Extreme Programming favorece projetos simples, metforas

MNEMNICO: CorSim ComFeRe Coragem, Simplicidade, Comunicao, Feedback, Respeito.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 70 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

comuns, a colaborao dos usurios, programadores e outros stakeholders, a


comunicao verbal frequente e o feedback.
Simplicidade: XP incentiva que se comece com a soluo mais simples.
Funcionalidades adicionais podem ser acrescentadas posteriormente. Alega-se
que desenvolver funes que no so necessrias hoje pode ser prejudicial, na
medida em que futuramente essa funo pode no ser mais til. Codificao e
projeto de necessidades futuras incertas implicam o risco de gastar recursos em
algo no mais necessrios, embora talvez atrasando aspectos cruciais.
Feedback: o feedback ocorre quando os testes unitrios ou testes de integrao
retornam o estado do sistema aps a implementao das mudanas. Ademais,
como os clientes participam do desenvolvimento de testes, eles podem dar um
feedback instantneo. Dessa forma, o cliente pode orientar o desenvolvimento
em uma possvel recodificao do sistema. Quando o cliente traz um novo
requisito, recebe um feedback de tempo e oramento.
Coragem: a coragem permite que os desenvolvedores se sintam confortveis
com ao refatorar o seu cdigo, quando necessrio. Eventualmente, h de se ter
coragem para jogar fora um cdigo ou para remover um cdigo obsoleto, no
importa quanto esforo e tempo se gastou para produzi-lo. Alm disso, coragem
significa persistncia, pois um programador pode se encontrar preso em um
problema complexo durante um dia inteiro sem conseguir resolver.
Respeito: aqui se inclui o respeito pelos outros, assim como o auto-respeito.
Membros devem respeitar seu prprio trabalho, sempre se esforando para
oferecer alta qualidade e buscando o melhor projeto para a soluo atravs de
refatorao. Ningum na equipe deve se sentir desvalorizado ou ignorado. Isso
garante um alto nvel de motivao e incentiva a lealdade dentro da equipe. Este
valor muito dependente dos outros valores.
00000000000

Da mesma forma que h valores fundamentais, h tambm princpios bsicos!


Galera, no confundam Valores Fundamentais com Princpios Bsicos! Eles tambm
so cinco e devem ser seguidos por equipes que forem usar XP em projetos. Os
princpios serviro pra ajudar na escolha de alternativas de soluo de problemas
durante o curso do projeto. So eles:
Feedback Rpido: retorno tempestivo do cliente, i.e., o sistema apresentado e,
a cada mudana, h um novo retorno positivo ou negativo do cliente.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 71 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Abraar Mudanas: mudanas devem ser bem-vindas e ocorrero de acordo


com o melhor entendimento do projeto.
Presumir Simplicidade: todo problema deve ser tratado para ser resolvido da
forma mais simples possvel.
Mudanas Incrementais: a soluo deve ser aperfeioada a cada iterao de
modo a satisfazer, ao fim, as expectativas do usurio.
Trabalho de Qualidade: a qualidade jamais deve ser comprometida. Essa uma
das razes para se ter a codificao dos testes antes da codificao do sistema.
No eXtreme Programming, as novas verses de software podem ser compiladas
vrias vezes por dia e os incrementos so entregues para os clientes
aproximadamente a cada duas semanas. Quando um programador compila o
sistema para criar uma nova verso, ele deve executar todos os testes
automatizados existentes bem como os testes para a nova funcionalidade.
A nova compilao do software ser aceita somente se todos os testes foram
executados com sucesso. Um preceito essencial da engenharia de software
tradicional projetar mudanas. Em outras palavras, voc deve antecipar mudanas
futuras para o software e projet-lo de tal maneira que essas mudanas possam ser
implementadas facilmente.
O eXtreme Programming, contudo, descarta esse princpio alegando que projetar
para a mudana , geralmente, um esforo completamente intil. As mudanas
antecipadas muitas vezes no ocorrem e as solicitaes de mudana realizadas so
completamente diferentes, causando diversos prejuzos ao sistema. Entenderam o
problema?
00000000000

O problema com a implementao de mudanas no antecipadas que elas


tendem a degradar a estrutura do software, fazendo com que as mudanas tornemse cada vez mais difceis de implementar. O Extreme Programming lida com este
problema defendendo que o software deve passar por refatoramento
constantemente.
Isso significa que a equipe de programao procura por possveis melhorias no
software, implementando-as imediatamente. Portanto, o software deve sempre ser
fcil de compreender e alterar quando novas histrias de usurio so

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 72 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

implementadas. Essa agilidade muito importante no desenvolvimento gil de


software.

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 73 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

SECONT/ES Auditor do Estado Tecnologia da Informao)


74. (CESPE
Mtodos geis de desenvolvimento de sistemas foram propostos principalmente
para apoiar o desenvolvimento de aplicaes de negcios nas quais os requisitos
de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses mtodos est o extreme programming, que envolve um nmero de
prticas, como o planejamento incremental, a definio de um ritmo de trabalho
sustentvel e a diviso das equipes de trabalho por meio da especializao de
seus membros.
Comentrios:
A questo est quase toda correta, exceto pela ltima parte! O XP recomenda que
no haja especializao de membros, apresentando uma equipe coesa e
multidisciplinar, i.e., todos participam de todas as atividades.
Gabarito: E
75. (CESPE 2012 MPE/PI Analista Ministerial Cargo 6) O XP (Extreme
Programming) um mtodo gil, que preconiza a criao de um caso de teste
unitrio antes do incio da codificao.
Comentrios:
O XP , de fato, um mtodo gil que preconiza o Test-First Design como uma de
suas prticas, i.e., primeiro cria-se o teste para depois codificar a funcionalidade
referente a esse teste.
00000000000

Gabarito: C
76. (CESPE 2011 EBC
alista de Sistemas Engenharia de Software) O XP
segue um conjunto de valores, princpios e regras bsicas que visam alcanar
eficincia e efetividade no processo de desenvolvimento de software. Os valores
so cinco: comunicao, simplicidade, feedback, coragem e respeito.
Comentrios:

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 74 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

De fato, esses so os valores preconizados pelo XP: Comunicao, Simplicidade,


Feedback, Coragem e Respeito.
Gabarito: C
(CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Em XP,
a prtica denominada programao em pares (pair programming) realizada
por um desenvolvedor em dois computadores, com o objetivo de aumentar a
produtividade.
Comentrios:
Na verdade, so dois desenvolvedores utilizando apenas um computador.
Observem que o intuito aumentar a qualidade do software por meio da reviso
constante pelo par.
Gabarito: E
78. (CESPE 2011 STM Analista Judicirio Analista de Sistemas) O Extreme
Programming (XP), que se inclui entre os mtodos geis, apresenta, entre outras,
as seguintes caractersticas: pequenos releases, projeto simples, refactoring,
programao em pares e propriedade coletiva.
Comentrios:
Perfeito, todas essas so caractersticas do Extreme Programming.
00000000000

Gabarito: C

79. (CESPE 2010 ABIN Oficial Tcnico de Inteligncia Desenvolvimento e


Manuteno de Sistemas) Na Extreme Programming, os requisitos so expressos
como cenrios e implementados diretamente como uma srie de tarefas. O
representante do cliente faz parte do desenvolvimento e responsvel pela
definio de testes de aceitao do sistema.
Comentrios:
Perfeito, os requisitos so expressos como cenrios (ou estrias de usurio) e
implementados como tarefas. Ademais, recomenda-se o Cliente On-Site, i.e., um
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 75 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

representante do usurio final do sistema deve estar disponvel em tempo integral


para apoiar a equipe.
Gabarito: C
(CESPE - 2012 ANAC Analista de Sistemas) Para o mtodo gil de
desenvolvimento conhecido como extreme programming, todos os requisitos
funcionais so expressos como cenrios (histrias do usurio) que so
implementados diretamente como uma srie de tarefas.
Comentrios:
Perfeito, exatamente isso!
Gabarito: C
81. (CESPE - 2012 ANAC Analista de Sistemas) A tcnica conhecida como
refactoring constantemente aplicada no desenvolvimento baseado no mtodo
gil extreme programming.
Comentrios:
Perfeito, uma tcnica amplamente preconizada!
Gabarito: C
(CESPE - 2012 ANAC Analista de Sistemas) No modelo extreme
programming, os testes de software s so realizados na etapa final de
desenvolvimento do software e, somente nessa etapa, os programadores
trabalham, obrigatoriamente, em pares, utilizando cada um o prprio
computador.
00000000000

Comentrios:
Primeiro, Testes de Software no ocorrem somente na etapa final de
desenvolvimento, eles so realizados a todo momento. Ademais, programadores
trabalham em pares a todo instante: um computador para dois programadores.
Gabarito: E

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 76 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE - 2012 ANAC Analista de Sistemas) Na metodologia gil XP (extreme


programming), as metforas so formas de transmitir ideias complexas de
maneira simples, ou seja, utiliza-se uma linguagem simples entre a equipe e o
cliente, com o objetivo de que, entre as inmeras variveis de controle em
projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco
no tempo, em detrimento do planejamento do release.
Comentrios:
A primeira parte da questo est perfeita, i.e., metforas ajudam a transmitir ideias
complexas de maneira simples. No entanto, o objetivo dela no obter maior foco
no tempo. Ademais, o planejamento da release dependente do tempo, logo no
h essa distino de foco!
Gabarito: E
84. (CESPE - 2013 ANTT Analista de Sistemas) So prticas ou princpios
recomendados no modelo de desenvolvimento de software XP (eXtreme
Programming) proposto por Kent Beck: programao em pares; semana de
trabalho de 40 horas; refatorao sem piedade; desenvolvimento orientado a
testes TDD (Test Driven Development); e desenvolvimento de metforas
arquiteturais.
Comentrios:
Vamos verificar? Programao em Pares, ok. Semana de 40 horas, ok.
Desenvolvimento orientado a testes TDD, ok. Desenvolvimento de metforas
arquiteturais, ok. Refatorao sem piedade, como ? Sem piedade? Galera, no fao
ideia de onde o CESPE tirou isso! No entanto, melhor no brigar com a banca.
00000000000

Gabarito: C
(CESPE IPEA Analista de Sistemas) A extreme programming (XP) um
mtodo de desenvolvimento gil. Nele, os requisitos so expressos como
cenrios implementados diretamente como uma srie de tarefas.
Comentrios:
Perfeito, essa uma questo muito comum em concursos!

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 77 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Gabarito: C
(CESPE - 2010 MPU Analista de Sistemas) 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.
Comentrios:
XP um mtodo gil de desenvolvimento de software com requisitos vagos e em
constante mudana, devendo ser usado por equipes de pequeno a mdio porte,
formadas se possvel por representantes de todos os stakeholders.
Gabarito: E
TRE.MG Analista de Sistemas - Extreme programming um
87. (CESPE mtodo centrado no usurio, na produtividade do desenvolvimento e na
documentao de apoio.
Comentrios:
Centrado na documentao de apoio? No!
Gabarito: E
(CESPE - 2009 TRE.BA Analista de Sistemas) A metodologia XP prev valores
e princpios bsicos para serem considerados durante o desenvolvimento de
software. Feedback, coragem e respeito so exemplos de valores; mudanas
incrementais, abraar mudanas e trabalho de qualidade so exemplos de
princpios bsicos.
00000000000

Comentrios:
Perfeito! Valores Fundamentais: Feedback, Coragem, Respeito, Comunicao e
Simplicidade; Princpios Bsicos: Feedback Rpido, Abraar Mudanas, Presumir
Simplicidade, Mudanas Incrementais e Trabalho de Qualidade.
Gabarito: C

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 78 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Os


quatro valores fundamentais da metodologia XP so: comunicao, simplicidade,
feedback e coragem.
Comentrios:
Na verdade, so cinco valores fundamentais! Todos esses e mais um: Respeito. No
entanto, a banca deu como verdadeiro!
Gabarito: C
(CESPE - 2006 TSE Analista de Sistemas
Processos de desenvolvimento
que adotam o modelo gil enfatizam a comunicao entre participantes, a
realimentao e a simplicidade. Para atingir tais prticas, o Extreme Programming
(XP) advoga prticas como a posse coletiva do cdigo.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
- ANAC - Analista Administrativo - Tecnologia da Informao)
91. (CESPE Extreme Programming um modelo de processo de desenvolvimento de
software para equipes com grande nmero de pessoas, que desenvolvem
software com base em requisitos vagos e que so modificados rapidamente.
Comentrios:
00000000000

Grande nmero de pessoas? No, equipes de pequeno e mdio porte!


Gabarito: E
(CESPE - ANTAQ - Analista Administrativo - Informtica) O extreme
programming (XP) constitui mtodo gil de desenvolvimento de software. Uma
das prticas que se enquadram nos princpios dos mtodos geis a
programao em pares, que promove o compartilhamento da autoria do cdigo
do sistema. Alm dessa vantagem, a programao em pares atua como processo
informal de reviso porque cada linha de cdigo vista por pelo menos duas
pessoas.
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 79 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Comentrios:
Perfeito! A Programao em Par promove a Propriedade Coletiva! Alm disso, serve
como uma reviso informal.
Gabarito: C
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da
Informao - Parte II) O processo XP (extreme programming) envolve a
realizao das atividades de planejamento, de projeto, de codificao e de teste.
Comentrios:
Perfeito, essas so as atividades do Processo XP!
Gabarito: C
94. (CESPE - 2013 - STF - Analista Judicirio - Anlise de Sistemas de Informao) XP
(Extreme Programming) uma metodologia gil voltada para equipes pequenas
e mdias que desenvolvam software baseado em requisitos vagos e se
caracteriza por possibilitar modificaes rpidas.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
00000000000

(CESPE - 2013 - TCE-RO - Analista de Informtica) No mtodo XP (eXtreming


programming), os sistemas so concebidos a partir de uma metfora e descritos
em estrias do usurio. Esse mtodo busca facilitar a comunicao com o cliente,
entendendo a realidade deste e guiando o desenvolvimento com o uso de
estria simples.
Comentrios:
Perfeito! Metforas simplificam o entendimento!
Gabarito: C
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 80 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) XP um mtodo


de desenvolvimento de software em que os requisitos so especificados em user
stories; requisitos, arquitetura e design surgem durante o curso do projeto; e o
desenvolvimento ocorre de maneira incremental.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
97. (FCC - 2012 - TST - Tcnico Judicirio Programao A) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que duas pessoas trabalhem
juntas para criar o cdigo correspondente a uma histria.
Comentrios:
Perfeito, exatamente isso!
Gabarito: C
(FCC - 2012 - TST - Tcnico Judicirio Programao B) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que a equipe XP e os clientes
trabalhem de forma separada para no mudar o compromisso bsico definido
para a verso a ser entregue.
00000000000

Comentrios:
No. Lembram-se do Cliente On-Site? Pois , cliente sempre presente para auxiliar
com seu conhecimento sobre a rea de negcio.
Gabarito: E
(FCC - 2012 - TST - Tcnico Judicirio Programao C) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele segue rigorosamente o princpio FDD Feature Driven Development.
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 81 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Comentrios:
No, ele segue rigorosamente o princpio TDD (Test-Driven Development).
Gabarito: E
100. (FCC - 2012 - TST - Tcnico Judicirio Programao D) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que depois que as histrias forem
desenvolvidas e o trabalho preliminar do projeto for feito, a equipe XP avance
diretamente para o cdigo.
Comentrios:
No, ele recomenda que se faa uma srie de testes unitrios antes da codificao
em si.
Gabarito: E
101. (FCC - 2012 - TST - Tcnico Judicirio Programao E) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele inclui um conjunto de regras e prticas que
ocorrem no contexto de 3 atividades de arcabouo: projeto, implementao e
entrega.
Comentrios:
Na verdade, so quatro atividades: Planejamento, Projeto, Codificao e Teste.
00000000000

Gabarito: E
102. (FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas A) No XP, os
testes so escritos antes da atividade de desenvolvimento e todas as
funcionalidades s possuem valor se forem testadas e obtiverem unanimidade
de aprovao.
Comentrios:
Perfeito, isso mesmo! Teste primeiro, codifica depois!
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 82 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Gabarito: C
103. (FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas C) No XP, no
h indicao de que necessrio criar documentao no cdigo porm, os
documentos tradicionais so reduzidos aos aspectos mais relevantes, visando
obter no final do processo, apenas artefatos de grande importncia para o
projeto.
Comentrios:
O XP indica documentaes, sim! Elas so simples, como Cartes CRC!
Gabarito: E
104. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao A)
Na XP (eXtreme Programming) deve-se usar o modelo em cascata para o
desenvolvimento do software.
Comentrios:
No! Deve-se utilizar o Modelo Iterativo e Incremental.
Gabarito: E
105. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao B)
Na XP (eXtreme Programming) os programadores desenvolvem o software
criando primeiramente os testes.
00000000000

Comentrios:
Perfeito! Testa primeiro, codifica depois.
Gabarito: C
106. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao C)
Na XP (eXtreme Programming) deve ser evitada a comunicao pessoal entre
clientes e desenvolvedores, sempre dando preferncia a outros meios de
comunicao mais formais.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 83 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Comentrios:
Pelo contrrio, deve-se estimular a comunicao pessoal entre clientes e
desenvolvedores e evitar outros meios mais formais.
Gabarito: E
107. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao D)
Na XP (eXtreme Programming) os programadores desenvolvem o software
fazendo todos os testes possveis no trmino do desenvolvimento.
Comentrios:
No, testes so feitos a todo momento.
Gabarito: E
108. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao E) Na
XP (eXtreme Programming) deve-se projetar todas as funes possveis com a
mxima previso do que ocorrer no futuro, antes do desenvolvimento do
software, a fim de evitar alteraes desnecessrias.
Comentrios:
Pelo contrrio! XP lida bem com mudanas.
Gabarito: E
PRODEST - Analista de Sistemas) Projetar detalhadamente
109. (CESPE todo o software antes de iniciar a sua implementao uma prtica
recomendada pelo XP. O software deve ser projetado para atender tanto aos
requisitos atuais quanto aos potenciais requisitos futuros. Para atingir esse
objetivo, so analisados os possveis cenrios de evoluo futura e so
empregados padres de projeto para facilitar a manuteno.
00000000000

Comentrios:
Projetar detalhadamente? No! O Manifesto gil j dizia: responder a mudanas
mais valorizado do que seguir um plano especfico.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 84 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

Gabarito: E
PRODEST - Analista de Sistemas) Constituem prticas
110. (CESPE recomendadas pelo XP a colocao rpida de uma verso simples em produo,
a liberao das novas verses em curtos intervalos de tempo, a programao
em duplas, a refatorao (refactor) dos cdigos produzidos, a adoo de
padres para a codificao; a integrao e o teste contnuos de cdigos; a
limitao em 40 horas da carga de trabalho semanal.
Comentrios:
Perfeito, isso mesmo!
Gabarito: C
PRODEST - Analista de Sistemas) O XP um processo que visa
111. (CESPE a um desenvolvimento gil e portanto no recomenda os testes de unidade, pois
eles consomem muitos recursos. Durante o desenvolvimento, o primeiro teste
recomendado o smoke test que foca os detalhes de funcionamento. O smoke
test realizado aps as unidades serem integradas. Aps o smoke test,
realizado o teste de sistema.
Comentrios:
Como ? XP recomenda veementemente a utilizao de testes de unidade!
Gabarito: E
ACERTEI

Prof. Diego Carvalho

00000000000

ERREI

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 85 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

8 KANBAN
[E a, que tal vir comigo para ver a teoria e os exerccios desse assunto?]

ACERTEI

ERREI

9. TDD
[E a, que tal vir comigo para ver a teoria e os exerccios desse assunto?]

ACERTEI

ERREI

10. BDD
00000000000

[E a, que tal vir comigo para ver a teoria e os exerccios desse assunto?]

ACERTEI

Prof. Diego Carvalho

ERREI

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 86 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

FUI BEM? FUI MAL? MAIS OU MENOS?


ASSUNTO

CORRETAS

ERRADAS

Ciclo de Vida de Software


Processos de Desenvolvimento de Software
52. Modelo em Cascata
Modelos Iterativos e Incrementais
Modelos Evolucionrios
Scrum
Extreme Programming (XP)
Kanban
TDD (Test Driven Development)
BDD (Behavior Driven Development)
TOTAL

00000000000

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 87 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

LISTA DE EXERCCIOS COMENTADOS

(CESPE
TCE/TO Analista de Sistemas Quanto maior e mais
complexo o projeto de software, mais simples deve ser o modelo de processo a
ser adotado.
(CESPE
TCE/TO Analista de Sistemas - O modelo de ciclo de vida
do software serve para delimitar o alvo do software. Nessa viso, no so
consideradas as atividades necessrias e o relacionamento entre elas.
(CESPE
TCE/TO Analista de Sistemas A escolha do modelo do
ciclo de vida no depende de caractersticas especficas do projeto, pois o melhor
modelo sempre o mais usado pela equipe do projeto.
(CESGRANRIO 2010 PETROBRS Analista de Sistemas Processos de
Negcio) No Ciclo de Vida Clssico, tambm chamado de Modelo Sequencial
Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta
pelas seguintes atividades:
a) Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e
Manuteno.
b) Modelagem e Engenharia do Sistema/Informao, Anlise de Requisitos de
Software, Projeto, Gerao de Cdigo, Teste e Manuteno.
c) Modelagem e Engenharia do Sistema/Informao, Projeto, Gerao de
Cdigo, Teste e Manuteno.
00000000000

d) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo e


Manuteno e Anlise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo, Teste
Progressivo e Manuteno.
(CESPE
INMETRO Analista de Sistemas) Em uma empresa que tenha
adotado um processo de desenvolvimento de software em cascata, falhas no

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 88 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

levantamento de requisitos tm maior possibilidade de gerar grandes prejuzos


do que naquelas que tenham adotado desenvolvimento evolucionrio.
(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem
de facilitar a realizao de mudanas sem a necessidade de retrabalho em fases
j completadas.
(CESPE 2008 TST Analista de Sistemas) No modelo de desenvolvimento
sequencial linear, a fase de codificao a que gera erros de maior custo de
correo.
(CESPE
INMETRO Analista de Sistemas) Em um processo de
desenvolvimento em cascata, os testes de software so realizados todos em um
mesmo estgio, que acontece aps a finalizao das fases de implementao.
(FCC - 2012 - - - Analista Judicirio - Anlise de Sistemas - E) Dos diferentes
modelos para o ciclo de vida de desenvolvimento de um software correto
afirmar que o modelo em cascata o mais recente e complexo.
10. (CESPE 2008 SERPRO Analista de Sistemas) O modelo em cascata consiste
de fases e atividades que devem ser realizadas em sequncia, de forma que uma
atividade requisito da outra.
- SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informao
11. (FCC - Prova 3 - O processo de engenharia de software denominado ciclo de vida
clssico refere-se ao modelo incremental.
12. (CESPE
AL/ES Analista de Sistemas - O modelo de desenvolvimento
em cascata descreve ciclos sequenciais, incrementais e iterativos, possuindo,
entre outras, as fases de requisitos e implementao.
00000000000

13. (CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento


seqencial linear, tambm chamado modelo clssico ou modelo em cascata,
caracteriza-se por no acomodar adequadamente as incertezas que existem no
incio de um projeto de software, em especial as geradas pela dificuldade do
cliente de explicitar todos os requerimentos que o programa deve contemplar.
14. (CESPE
IPEA Analista de Sistema) No modelo em cascata de processo
de desenvolvimento, os clientes devem definir os requisitos apenas durante a
fase de projeto; e os projetistas definem as estratgias de projeto apenas durante
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 89 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

a fase de implementao. As fases do ciclo de vida envolvem definio de


requisitos, projeto, implementao, teste, integrao, operao e manuteno.
Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.
15. (CESPE 2008 TCE/TO Analista de Sistema No ciclo de vida em cascata,
possvel realizar alternadamente e simultaneamente as atividades de
desenvolvimento de software.
A abordagem sistemtica
16. (CESPE 2004 TJ/PA Analista de Sistema
estritamente linear para o desenvolvimento de software denominada modelo
em cascata ou modelo sequencial linear.
O modelo em cascata organiza
17. (CESPE 2006 TSE Analista de Sistema
o desenvolvimento em fases. Esse modelo encoraja a definio dos requisitos
antes do restante do desenvolvimento do sistema. Aps a especificao e a
anlise dos requisitos, tm-se o projeto, a implementao e o teste.
18. (CESPE
INMTRO Analista de Sistema) No desenvolvimento de
software, o modelo em cascata estruturado de tal maneira que as fases que
compem o desenvolvimento so interligadas. Nessa situao, o final de uma
fase implica o incio de outra.
19. (CESPE 2010 BASA Analista de Sistema) No modelo em cascata, o projeto
segue uma srie de passos ordenados. Ao final de cada projeto, a equipe de
projeto finaliza uma reviso. O desenvolvimento continua e, ao final, o cliente
avalia a soluo proposta.
(CESPE
TRE/MT Analista de Sistema O modelo em cascata
apropriado para software em que os requisitos ainda no foram bem
compreendidos, pois focado na criao de incrementos.
00000000000

O modelo em cascata
21. (CESPE 2009 UNIPAMPA Analista de Sistema
sugere uma abordagem sistemtica e sequencial para o desenvolvimento de
software. Sua natureza linear leva a estados de bloqueio nos quais, para que
nova etapa seja iniciada, necessrio que a documentao associada fase
anterior tenha sido aprovada.
(CESPE 2004 ABIN Analista de Sistema) O modelo de desenvolvimento
seqencial linear, tambm denominado modelo em cascata, incompatvel com

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 90 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

o emprego de tcnica de anlise orientada a objetos no desenvolvimento de um


sistema de informao.
(CESPE 2004 TRE/AL Analista de Sistema) O modelo cascata ou ciclo de
vida clssico necessita de uma abordagem sistemtica, que envolve, em primeiro
lugar, o projeto e, em seguida, a anlise, a codificao, os testes e a manuteno.
MPE/AM Analista de Sistema) O modelo de desenvolvimento
24. (CESPE
seqencial linear tem como caracterstica principal a produo de uma verso
bsica, mas funcional, do software desde as primeiras fases.
(VUNESP - 2012 - SPTrans - Analista de Informtica) Uma das abordagens do
processo de desenvolvimento da engenharia de software prev a diviso em
etapas, em que o fim de uma a entrada para a prxima. Esse processo
conhecido como modelo:
a) Transformao.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
(CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o
processo de desenvolvimento de software modelado como uma sequncia
linear de fases, enfatizando um ciclo de desenvolvimento de breve durao.
27. (CESPE - 2011 TJ/ES - Analista Judicirio - Anlise de Sistemas - Especficos) O
modelo de processo incremental de desenvolvimento de software iterativo,
assim como o processo de prototipagem. Contudo, no processo incremental,
diferentemente do que ocorre no de prototipagem, o objetivo consiste em
apresentar um produto operacional a cada incremento.
00000000000

(CESPE TJ/DF - Analista Judicirio - Anlise de Sistemas) No modelo de


desenvolvimento incremental, embora haja defasagem entre os perodos de
desenvolvimento de cada incremento, os incrementos so desenvolvidos em
paralelo.
(CESPE UNIPAMPA - Anlise de Sistemas) No modelo de
desenvolvimento incremental, a cada iterao so realizadas vrias tarefas. Na

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 91 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

fase de anlise, pode ser feito o refinamento de requisitos e o refinamento do


modelo conceitual.
(FGV 2008 Senado Federal Analista de Sistemas) No modelo evolucionrio,
a mudana constante tende a corromper a estrutura do software.
DETRAN/DF Analista de Sistemas) O modelo de processo de
31. (CESPE
desenvolvimento de software evolucionrio parte do desenvolvimento de uma
implementao inicial cujos resultados so apresentados aos clientes e refinados
por meio de vrias verses at que se alcance o sistema adequado. A
prototipao, como processo, tem por objetivo compreender as especificaes
do software para se chegar aos requisitos para o sistema.
(CESPE
TJ/DF Analista de Sistemas) A prototipao evolucionria no
gera problemas de manuteno de sistema porque o desenvolvimento rpido
e no sofre grandes mudanas.
(CESPE
TJ/DF Analista de Sistemas) A prototipao evolucionria
permite que a verso inicial do prottipo seja desenvolvida e refinada em
estgios sequenciados, at que se chegue verso final do sistema.
34. (FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software - A)
Um dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software a implantao de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco
previsveis. Para tanto, o gerenciamento distribudo por meio de trs agentes
independentes que so: Product Owner, Scrum Team e Scrum Master.
(FCC - 2010 - TRE-RS - Analista Judicirio - Analista de Sistemas Suporte - E) Os
princpios Scrum so usados para guiar as atividades de desenvolvimento dentro
de um processo que incorpora as seguintes atividades de arcabouo: requisitos,
anlise, projeto, evoluo e entrega. Em cada atividade de arcabouo, as tarefas
de trabalho ocorrem dentro de um padro de processo chamado sprint.
00000000000

(FCC - 2010 - TRF - 4 REGIO - Analista Judicirio - Tecnologia da InformaoE) Na fase de desenvolvimento do Scrum, o software desenvolvido em
processos iterativos denominados Sprint.
37. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - E) Em
reunio, toda conversao restringida s respostas dos elementos s perguntas
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 92 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver at
a prxima reunio?". As Scrum meetings ocorrem diariamente.
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - A) Em relao s
regras do Scrum, incorreto afirmar que o Sprint deve ser realizado num perodo
mximo de 40 dias e ter uma equipe de trabalho no superior a 10 pessoas.
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - B) Em relao s
regras do Scrum, incorreto afirmar que se o Sprint tomar um rumo no
desejado, possvel dissolv-lo e comear um novo Sprint, baseando num novo
Sprint Backlog.
40. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - C) Em relao s
regras do Scrum, incorreto afirmar que as reunies durante um Sprint devem
ser dirias, sempre mesma hora e no mesmo local e no devem durar mais
que 30 minutos.
41. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - D) Em relao s
regras do Scrum, incorreto afirmar que toda conversao restringe as respostas
dos participantes s trs perguntas do Scrum Master: O que desenvolveu desde
a ltima reunio? Que dificuldades encontrou durante o seu trabalho? O que
planeja desenvolver at a prxima reunio?
42. (FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - E) Em relao s
regras do Scrum, incorreto afirmar que com base nas respostas s trs
perguntas, o Scrum Master deve imediatamente tomar decises, quando
necessrias, para remover todas as situaes que impeam a agilidade do
trabalho.
00000000000

43. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - A)


Durante a realizao do Sprint, o Backlog pode ser modificado por qualquer um
dos elementos da equipe, desde que acordado nas reunies semanais.
44. (FCC - 201 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - B) O
Sprint deve ser realizado num perodo no superior a 30 dias e ter um objetivo
bem claro, baseado no Backlog.
45. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - C)
Modificao no Backlog prerrogativa do Scrum Master, quando achar
necessrio, em qualquer momento no decorrer do Sprint.
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 93 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

46. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - D) No


possvel dissolver um Sprint. Se houver algum risco de ele tomar um rumo no
desejvel, novas funcionalidades devem ser implementadas para garantir o
prazo do projeto.
47. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - E) O foco
na produtividade se estende s Scrum Meetings e a conversao pautada em
discusses por toda a equipe.
48. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - B) No
SCRUM, o produto final, a data final e o custo do projeto so determinados ao
longo do projeto.
AFR/SP Analista de Sistemas) O conceito de sprint aplica-se ao
49. (FCC modelo gil do processo de engenharia de software denominado:
a)
b)
c)
d)
e)

Crystal.
XP.
DAS.
DSDM.
Scrum

(FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas E) Enquanto o


XP mais receptivo a mudanas durante a iterao, no SCRUM as solicitaes
do cliente devem aguardar o trmino da iterao em andamento.
51. (CESPE - 2013 - ANP - Analista Administrativo - rea 5) De acordo com a
metodologia Scrum, a constituio ideal da equipe de desenvolvimento para que
o trabalho se mantenha gil deve ser de menos de trs pessoas.
00000000000

(CESPE - 2012 - ANAC - Analista Administrativo - rea 4) O nico papel definido


pelo Scrum com autoridade para cancelar uma Sprint o do product owner.
(CESPE - 2012 - ANAC - Analista Administrativo - rea 4) Uma sprint do Scrum
tem durao prevista de 2 meses.
54. (CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Arquitetura de
Tecnologia) O Scrum utilizado, como funo primria, para o gerenciamento
de projetos de desenvolvimento de software, mas tambm tem sido usado como
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 94 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

extreme programming e outras metodologias de desenvolvimento.


Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um
grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum.
(CESPE - 2013 - ANTT - Analista Administrativo Analista de Sistemas) Entre os
vrios papis do SCRUM, o product owner a nica pessoa responsvel por
gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
(CESPE - 2013 - SERPRO - Analista de Informtica Analista de Sistemas) Scrum
um processo de desenvolvimento que tem como ponto de partida um
conjunto de requisitos bem definidos.
57. (CESPE - 2013 TCE-RO - Analista de Informtica Analista de Sistemas) Na
metodologia Scrum, a equipe trabalha nos processos e no h cargos na equipe.
Como um dos papis necessrios, o Scrum Master deve garantir que o processo
seja entendido e atuar como facilitador para ajudar a equipe.
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) Em um
projeto gerido com a metodologia Scrum, um produto estar, ao final de cada
sprint, completamente testado, estando 100% completos todos os requisitos do
product backlog.
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) O escopo,
a importncia e a estimativa de um Sprint do Scrum so definidos pelo product
owner.
(CESPE - 2012 BASA - Analista de Informtica Analista de Sistemas) A
metodologia Scrum, gil para gerncia de projetos, baseia-se em ciclos de 30
dias, denominados sprints, em que se trabalha para alcanar objetivos bem
definidos.
00000000000

61. (CESPE - 2011 ECT - Analista de Informtica Analista de Sistemas) Para que
se obtenha sucesso na utilizao do Scrum, o cliente deve se tornar parte da
equipe de desenvolvimento do software, participando diretamente do processo.
(CESPE - 2011 MEC - Analista de Informtica Analista de Sistemas) O
framework scrum engloba conceitos como times scrum, eventos com durao
fixa (time-boxes), artefatos e regras. So exemplos de eventos que tm durao

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 95 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

fixa: a reunio de planejamento da verso para entrega, a sprint, a reunio diria,


a reviso da sprint e a retrospectiva da sprint.
(CESPE - 2011 MEC - Analista de Informtica Analista de Sistemas) 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.
64. (CESPE - 2010 MPU - Analista de Informtica Analista de Sistemas) Um
princpio chave do Scrum o reconhecimento de que desafios
fundamentalmente empricos no podem ser resolvidos com sucesso utilizandose uma abordagem tradicional de controle. O Scrum adota uma abordagem
emprica, aceitando que o problema no pode ser totalmente entendido ou
definido, focando na maximizao da habilidade da equipe de responder de
forma gil aos desafios emergentes.
(CESPE - 2010 MPU - Analista de Informtica Analista de Sistemas) A
metodologia Scrum facilitada por um scrum master, que atua como um
mediador entre a equipe e qualquer influncia desestabilizadora, alm de
assegurar que a equipe esteja utilizando corretamente as prticas de Scrum,
motivando e mantendo o foco na meta da sprint.
(CESPE - 2012 TER-RJ - Analista de Informtica Analista de Sistemas) A
metodologia scrum prega que a equipe complete e entregue partes do produto
final constantemente ao final de cada interao. Essa interao deve ser curta e
possuir tempo de execuo definido previamente.
67. (CESPE - 2013 ANCINE Analista de Sistemas) Na reunio de planejamento do
sprint backlog, se o product owner afirmar que todos os requisitos do produto
foram identificados, correto concluir que o backlog do produto est completo,
visto que este uma lista ordenada de todos os requisitos necessrios para o
desenvolvimento do produto.
00000000000

(CESPE - 2013 ANCINE Analista de Sistemas) Se for averiguado, em uma


organizao, que o Scrum Master gerencia o backlog do produto, correto
afirmar que houve falha na execuo de papis, visto que cabe unicamente ao
product owner gerenciar o backlog do produto.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 96 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

(CESPE - 2010 MPU Analista de Sistemas) Scrum um processo gil de


produo de software que mantm o foco na entrega da maior parte do
produto, no menor tempo possvel.
70. (CESPE - 2013 - INPI - Analista de Planejamento - Desenvolvimento e
Manuteno de Sistemas) No Scrum, o Product Owner (PO) responsvel por
definir a viso do produto e remover os impedimentos, enquanto o Scrum
Master (SM) responsvel por elaborar e manter o Product Backlog, bem como
por ajudar o PO a executar suas atividades dirias.
71. (CESPE - 2013 - ANP - Analista Administrativo - rea 5) O ciclo de vida da
metodologia Scrum se divide nas fases de pr-planejamento, desenvolvimento
e ps-planejamento. O documento denominado product backlog gerado na
fase de desenvolvimento.
72. (CESPE - 2012 - TCE-ES - Auditor de Controle Externo - Tecnologia da
Informao) O Product Backlog, um dos artefatos utilizados na metodologia gil
denominada Scrum, constitui-se da lista priorizada de todos os requisitos do
produto final.
73. (CESPE - 2014 ANATEL Arquitetura de Solues) O Scrum um conjunto
simples e eficaz de regras e ferramentas que so utilizadas para maximizar
resultados. O ScrumMaster exerce o papel de facilitador e motivador da equipe,
alm de garantir que as regras e as ferramentas sejam utilizadas com vistas
criatividade do trabalho e ao retorno do investimento.
SECONT/ES Auditor do Estado Tecnologia da Informao)
74. (CESPE
Mtodos geis de desenvolvimento de sistemas foram propostos principalmente
para apoiar o desenvolvimento de aplicaes de negcios nas quais os requisitos
de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses mtodos est o extreme programming, que envolve um nmero de
prticas, como o planejamento incremental, a definio de um ritmo de trabalho
sustentvel e a diviso das equipes de trabalho por meio da especializao de
seus membros.
00000000000

75. (CESPE 2012 MPE/PI Analista Ministerial Cargo 6) O XP (Extreme


Programming) um mtodo gil, que preconiza a criao de um caso de teste
unitrio antes do incio da codificao.

Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 97 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

76. (CESPE 2011 EBC Analista de Sistemas Engenharia de Software) O XP


segue um conjunto de valores, princpios e regras bsicas que visam alcanar
eficincia e efetividade no processo de desenvolvimento de software. Os valores
so cinco: comunicao, simplicidade, feedback, coragem e respeito.
(CESPE
0 TRE/BA Tcnico Judicirio Programao de Sistemas) Em XP,
a prtica denominada programao em pares (pair programming) realizada
por um desenvolvedor em dois computadores, com o objetivo de aumentar a
produtividade.
78. (CESPE 2011 STM Analista Judicirio Analista de Sistemas) O Extreme
Programming (XP), que se inclui entre os mtodos geis, apresenta, entre outras,
as seguintes caractersticas: pequenos releases, projeto simples, refactoring,
programao em pares e propriedade coletiva.
79. (CESPE 2010 ABIN Oficial Tcnico de Inteligncia Desenvolvimento e
Manuteno de Sistemas) Na Extreme Programming, os requisitos so expressos
como cenrios e implementados diretamente como uma srie de tarefas. O
representante do cliente faz parte do desenvolvimento e responsvel pela
definio de testes de aceitao do sistema.
(CESPE - 2012 ANAC Analista de Sistemas) Para o mtodo gil de
desenvolvimento conhecido como extreme programming, todos os requisitos
funcionais so expressos como cenrios (histrias do usurio) que so
implementados diretamente como uma srie de tarefas.
81. (CESPE - 2012 ANAC Analista de Sistemas) A tcnica conhecida como
refactoring constantemente aplicada no desenvolvimento baseado no mtodo
gil extreme programming.
00000000000

(CESPE - 2012 ANAC Analista de Sistemas) No modelo extreme


programming, os testes de software s so realizados na etapa final de
desenvolvimento do software e, somente nessa etapa, os programadores
trabalham, obrigatoriamente, em pares, utilizando cada um o prprio
computador.
(CESPE - 2012 ANAC Analista de Sistemas) Na metodologia gil XP (extreme
programming), as metforas so formas de transmitir ideias complexas de
maneira simples, ou seja, utiliza-se uma linguagem simples entre a equipe e o
cliente, com o objetivo de que, entre as inmeras variveis de controle em
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 98 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco
no tempo, em detrimento do planejamento do release.
84. (CESPE - 2013 ANTT Analista de Sistemas) So prticas ou princpios
recomendados no modelo de desenvolvimento de software XP (eXtreme
Programming) proposto por Kent Beck: programao em pares; semana de
trabalho de 40 horas; refatorao sem piedade; desenvolvimento orientado a
testes TDD (Test Driven Development); e desenvolvimento de metforas
arquiteturais.
(CESPE IPEA Analista de Sistemas) A extreme programming (XP) um
mtodo de desenvolvimento gil. Nele, os requisitos so expressos como
cenrios implementados diretamente como uma srie de tarefas.
(CESPE - 2010 MPU Analista de Sistemas) 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.
87. (CESPE TRE.MG Analista de Sistemas - Extreme programming um
mtodo centrado no usurio, na produtividade do desenvolvimento e na
documentao de apoio.
(CESPE - 2009 TRE.BA Analista de Sistemas) A metodologia XP prev valores
e princpios bsicos para serem considerados durante o desenvolvimento de
software. Feedback, coragem e respeito so exemplos de valores; mudanas
incrementais, abraar mudanas e trabalho de qualidade so exemplos de
princpios bsicos.
00000000000

(CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Os


quatro valores fundamentais da metodologia XP so: comunicao, simplicidade,
feedback e coragem.
(CESPE - 2006 TSE Analista de Sistemas
Processos de desenvolvimento
que adotam o modelo gil enfatizam a comunicao entre participantes, a
realimentao e a simplicidade. Para atingir tais prticas, o Extreme Programming
(XP) advoga prticas como a posse coletiva do cdigo.
- ANAC - Analista Administrativo - Tecnologia da Informao)
91. (CESPE Extreme Programming um modelo de processo de desenvolvimento de
Prof. Diego Carvalho

www.estrategiaconcursos.com.br
00000000000 - DEMO

Pg. 99 de 103

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

software para equipes com grande nmero de pessoas, que desenvolvem


software com base em requisitos vagos e que so modificados rapidamente.
(CESPE - ANTAQ - Analista Administrativo - Informtica) O extreme
programming (XP) constitui mtodo gil de desenvolvimento de software. Uma
das prticas que se enquadram nos princpios dos mtodos geis a
programao em pares, que promove o compartilhamento da autoria do cdigo
do sistema. Alm dessa vantagem, a programao em pares atua como processo
informal de reviso porque cada linha de cdigo vista por pelo menos duas
pessoas.
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da
Informa - Parte II) O processo XP (extreme programming) envolve a
realizao das atividades de planejamento, de projeto, de codificao e de teste.
94. (CESPE - 2013 - STF - Analista Judicirio - Anlise de Sistemas de Informao) XP
(Extreme Programming) uma metodologia gil voltada para equipes pequenas
e mdias que desenvolvam software baseado em requisitos vagos e se
caracteriza por possibilitar modificaes rpidas.
(CESPE - 2013 - TCE-RO - Analista de Informtica) No mtodo XP (eXtreming
programming), os sistemas so concebidos a partir de uma metfora e descritos
em estrias do usurio. Esse mtodo busca facilitar a comunicao com o cliente,
entendendo a realidade deste e guiando o desenvolvimento com o uso de
estria simples.
(CESPE - 2013 - MPU - Analista - Desenvolvimento de Sistemas) XP um mtodo
de desenvolvimento de software em que os requisitos so especificados em user
stories; requisitos, arquitetura e design surgem durante o curso do projeto; e o
desenvolvimento ocorre de maneira incremental.
00000000000

97. (FCC - 2012 - TST - Tcnico Judicirio Programao A) O XP (Extreme


Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que duas pessoas trabalhem
juntas para criar o cdigo correspondente a uma histria.
(FCC - 2012 - TST - Tcnico Judicirio Programao B) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que a equipe XP e os clientes

Prof. Diego Carvalho


103

www.estrategiaconcursos.com.br

00000000000 - DEMO

Pg. 100 de

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

trabalhem de forma separada para no mudar o compromisso bsico definido


para a verso a ser entregue.
(FCC - 2012 - TST - Tcnico Judicirio Programao C) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele segue rigorosamente o princpio FDD Feature Driven Development.
100. (FCC - 2012 - TST - Tcnico Judicirio Programao D) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele recomenda que depois que as histrias forem
desenvolvidas e o trabalho preliminar do projeto for feito, a equipe XP avance
diretamente para o cdigo.
101. (FCC - 2012 - TST - Tcnico Judicirio Programao E) O XP (Extreme
Programming) utiliza uma abordagem orientada a objetos como seu paradigma
de desenvolvimento predileto. Ele inclui um conjunto de regras e prticas que
ocorrem no contexto de 3 atividades de arcabouo: projeto, implementao e
entrega.
102. (FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas A) No XP, os
testes so escritos antes da atividade de desenvolvimento e todas as
funcionalidades s possuem valor se forem testadas e obtiverem unanimidade
de aprovao.
103. (FCC - 2012 - -PE - Analista Judicirio - Anlise de Sistemas C No XP, no
h indicao de que necessrio criar documentao no cdigo porm, os
documentos tradicionais so reduzidos aos aspectos mais relevantes, visando
obter no final do processo, apenas artefatos de grande importncia para o
projeto.
00000000000

- TRE-SE - Analista Judicirio - Tecnologia da Informao A)


104. (FCC Na XP (eXtreme Programming) deve-se usar o modelo em cascata para o
desenvolvimento do software.
105. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao B)
Na XP (eXtreme Programming) os programadores desenvolvem o software
criando primeiramente os testes.

Prof. Diego Carvalho


103

www.estrategiaconcursos.com.br

00000000000 - DEMO

Pg. 101 de

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

106. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao C)


Na XP (eXtreme Programming) deve ser evitada a comunicao pessoal entre
clientes e desenvolvedores, sempre dando preferncia a outros meios de
comunicao mais formais.
107. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao D)
Na XP (eXtreme Programming) os programadores desenvolvem o software
fazendo todos os testes possveis no trmino do desenvolvimento.
108. (FCC - 2007 - TRE-SE - Analista Judicirio - Tecnologia da Informao E) Na
XP (eXtreme Programming) deve-se projetar todas as funes possveis com a
mxima previso do que ocorrer no futuro, antes do desenvolvimento do
software, a fim de evitar alteraes desnecessrias.
PRODEST - Analista de Sistemas) Projetar detalhadamente
109. (CESPE todo o software antes de iniciar a sua implementao uma prtica
recomendada pelo XP. O software deve ser projetado para atender tanto aos
requisitos atuais quanto aos potenciais requisitos futuros. Para atingir esse
objetivo, so analisados os possveis cenrios de evoluo futura e so
empregados padres de projeto para facilitar a manuteno.
PRODEST - Analista de Sistemas) Constituem prticas
110. (CESPE recomendadas pelo XP a colocao rpida de uma verso simples em produo,
a liberao das novas verses em curtos intervalos de tempo, a programao
em duplas, a refatorao (refactor) dos cdigos produzidos, a adoo de
padres para a codificao; a integrao e o teste contnuos de cdigos; a
limitao em 40 horas da carga de trabalho semanal.
PRODEST - Analista de Sistemas) O XP um processo que visa
111. (CESPE a um desenvolvimento gil e portanto no recomenda os testes de unidade, pois
eles consomem muitos recursos. Durante o desenvolvimento, o primeiro teste
recomendado o smoke test que foca os detalhes de funcionamento. O smoke
test realizado aps as unidades serem integradas. Aps o smoke test,
realizado o teste de sistema.
00000000000

Prof. Diego Carvalho


103

www.estrategiaconcursos.com.br

00000000000 - DEMO

Pg. 102 de

Tpicos de TI para Analista do TRT/3 Regio (MG)


Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 00

1
E
11
E
21
C
31
E
41
E
51
E
61
C
71
E
81
C
91
E
101
E
111
E

2
E
12
E
22
E
32
E
42
E
52
C
62
C
72
C
82
E
92
C
102
C
112
-

3
E
13
C
23
E
33
C
43
E
53
E
63
C
73
C
83
E
93
C
103
E
113
-

4
B
14
E
24
E
34
C
44
C
54
C
64
C
74
E
84
C
94
C
104
E
114
-

5
C
15
E
25
E
35
C
45
E
55
C
65
C
75
C
85
C
95
C
105
C
115
-

6
E
16
C
26
E
36
C
46
E
56
E
66
C
76
C
86
E
96
C
106
E
116
-

7
E
17
C
27
C
37
C
47
E
57
C
67
E
77
E
87
E
97
C
107
E
117
-

8
E
18
C
28
C
38
C
48
C
58
E
68
C
78
C
88
C
98
E
108
E
118
-

9
E
19
E
29
C
39
E
49
E
59
E
69
C
79
C
89
C
99
E
109
E
119
-

10
C
20
E
30
C
40
E
50
C
60
C
70
E
80
C
90
C
100
E
110
C
120
-

E a, querem mais teoria? Mais exerccios? Tem muito mais! Essa apenas a aula demonstrativa, o restante
desta aula e as outras vm em breve! Espero que vocs venham comigo... grande abrao ;)
00000000000

Prof. Diego Carvalho


103

www.estrategiaconcursos.com.br

00000000000 - DEMO

Pg. 103 de

Você também pode gostar