Escolar Documentos
Profissional Documentos
Cultura Documentos
00000000000 - DEMO
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 1 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 2 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 3 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 4 de 103
00000000000
Esse curso protegido por direitos autorais (Copyright), nos termos da Lei 9.610/98.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 5 de 103
O CONCURSO
00000000000
REMUNERAO
(PROVAVELMENTE) R$8.863,84
VAGAS
CADASTRO RESERVA
EDITAL/AUTORIZAO:
http://www.concursosfcc.com.br/concursos/trt3r114/boletim_final_trt3r114.pdf
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 6 de 103
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.
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 7 de 103
2 Lugar ISS/Salvador
https://www.youtube.com/watch?v=vmU1n1J-aqQ
Veja outros depoimentos:
http://www.estrategiaconcursos.com.br/blog/depoimentos
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 8 de 103
CRONOGRAM
Aula
00
Data
12/05
Tpicos do Edital
01
14/05
02
17/05
03
24/05
04
31/05
05
07/06
- Processo Unificado.
06
14/06
07
21/06
08
28/06
- Aula Demonstrativa
09
05/07
10
12/07
- Padres de Projetos.
11
19/07
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 9 de 103
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
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 ;-)
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 10 de 103
R$8.863,84
R$8.863,84
R$8.863,84
R$8.863,84
R$8.863,84
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 11 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 12 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 13 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 14 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 15 de 103
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
Fim do ciclo
Prottipos operacionais
Prottipos operacionais
Prottipos operacionais
Prottipos no
operacionais
Prottipos operacionais
ou no operacionais
Prottipos operacionais
ou no operacionais
5
5
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 16 de 103
(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
ERREI
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 17 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 18 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 19 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 20 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 21 de 103
Desvantagens
Diviso inflexvel do projeto em estgios distintos.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 22 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 23 de 103
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.
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 24 de 103
Desvantagens
Diviso inflexvel do projeto em estgios distintos.
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 25 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 26 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 27 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 28 de 103
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
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 30 de 103
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?
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 31 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 32 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 33 de 103
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.
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
ERREI
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 35 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 36 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 37 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 38 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 39 de 103
ERREI
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 40 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 41 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 42 de 103
Comentrios:
Como ? Compreender as especificaes para chegar aos requisitos? No, isso no
faz sentido! compreender os requisitos para chegar especificao.
Gabarito: E
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 43 de 103
(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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 44 de 103
Gabarito: C
ACERTEI
ERREI
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 45 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 46 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 47 de 103
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
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 49 de 103
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?
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 50 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 51 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 52 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 53 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 54 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 55 de 103
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
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 57 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 58 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 59 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 60 de 103
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:
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 61 de 103
Gabarito: C
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 62 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 63 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 64 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 65 de 103
ERREI
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 66 de 103
Testar bom?
Iterar bom?
Integrar bom?
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 67 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 68 de 103
Refactoring
Programao
em Pares
Propriedade
Coletiva
Integrao
Contnua
Ritmo
Sustentvel
Metforas
Cliente
-site
Reunies
em P
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 69 de 103
Time
Coeso
Jogo do
Planejamento
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 70 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 71 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 72 de 103
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 73 de 103
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:
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 74 de 103
Gabarito: C
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 75 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 76 de 103
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!
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 77 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 78 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 79 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 80 de 103
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
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
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 83 de 103
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.
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 84 de 103
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
00000000000
ERREI
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 85 de 103
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
ERREI
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 86 de 103
CORRETAS
ERRADAS
00000000000
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 87 de 103
(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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 88 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 89 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 90 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 91 de 103
(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
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 93 de 103
Crystal.
XP.
DAS.
DSDM.
Scrum
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 94 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 95 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 96 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 97 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 98 de 103
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 99 de 103
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 100 de
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 101 de
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 102 de
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
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 103 de