Eng Soft

CNMP - Engenharia de Software
Aula 00
Vitor Almeida
AULA 00 - Modelos de Ciclos de Vida.
Sumrio
1.
Apresentao. ..................................................................................................................... 2
1.1.
A Banca. .......................................................................................................................... 2
1.2.
Metodologia das aulas.................................................................................................... 2
2.
Contedo programtico e planejamento das aulas (Cronograma). ................................... 3
3.
Bibliografia .......................................................................................................................... 3
4.
Conceitos Gerais ................................................................................................................. 4
5.
Ciclo de Vida do Software................................................................................................. 15
6.
Modelo em Cascata .......................................................................................................... 22
7.
Modelo Iterativo e Incremental ....................................................................................... 30
8.
Modelos Evolucionrios ................................................................................................... 36
9.
Lista de Questes Utilizadas na Aula. ............................................................................... 49
10.
Gabarito ........................................................................................................................ 62
Ol Concurseiros de Planto!
Estamos aqui com o objetivo de cobrir todo o assunto de Engenharia de
Software do cargo de ANALISTA DO CNMP rea Apoio Tcnico-Especializado
Especialidade: DESENVOLVIMENTO DE SISTEMAS.
Com relao a onde estudar, as duas principais referncias so os livros de
Pressman e Sommerville. Se voc no comprou um deles na sua graduao, considere
comprar os dois neste momento em que voc tem como objetivo passar em um
concurso na rea de TI.
Quanto a mim, atualmente sou Analista de Finanas e Controle da
Controladoria-Geral da Unio - CGU, trabalhando com auditoria de TI e cruzamento de
bases de dados. Antes, passei 03 anos como Analista em TI do Ministrio do
Planejamento, Oramento e Gesto - MP, envolvido com atividades de gesto e
governana de TI.
Passei por 15 provas de concursos diversos ao longo destes 03 anos,
colecionando algumas aprovaes. Fiz um depoimento bem legal l na rede Itnerante:
www.tiparaconcursos.net
Pgina 1 de 62

Aula 00
Vitor Almeida
http://www.itnerante.com.br/group/galeria-dos-aprovados/forum/topics/relembrandominha-aprova-o.
Espero ajud-los no rduo caminho rumo a aprovao. Qualquer dvida,

podem enviar um e-mail para vitor.almeida@tiparaconcursos.net.
1. Apresentao.
1.1.
A Banca.
A nossa banca ser a FCC, onde cada questo conter 05 opes de resposta e
somente uma correta. Recentemente, fiz um estudo com 224 questes da FCC (e de
outras
bancas
(http://www.itnerante.com.br/profiles/blogs/como-a-disciplina-de-
engenharia-de-software-cobrada-em-concursos) sobre que assuntos so mais cobrados. O
resultado para a FCC foi o seguinte:

Assunto
1.2.
Porcentagem de Questes
UML
29%
Metodologias geis
13%
Anlise e Engenharia de Requisitos
11%
APF / Mtricas
10%
RUP
10%
Ciclo de Vida / Modelos de Processos
7%
Testes
7%
Anlise Estruturada / DFD
4%
Qualidade
2%
Anlise e Projeto
2%
Ferramentas CASE
1%
Gerncia de Projetos de Software
1%
Usabilidade
1%
Refactoring
1%
Metodologia das aulas.
a) Teremos no curso aulas expositivas, descritivas e descontradas com, ao

menos, 35 pginas por aula.
b) Todas as aulas tero uma introduo terica sobre os assuntos seguida de
questes para fixao do contedo e para pegar o jeito da banca.
Pgina 2 de 62

Aula 00
Vitor Almeida
c) Tenham o cuidado de no menosprezar nada que esteja escrito na aula.

Fizemos um trabalho de engenharia reversa e tudo que aparecer j caiu ou vai
cair!
d) Qualquer dvida, mande um e-mail para vitor.almeida@tiparaconcursos.net.
2. Contedo programtico e planejamento das aulas (Cronograma).

O Contedo programtico est distribudo de forma a garantir o aprendizado
do aluno, seguindo uma sequncia lgica de assuntos.
Aula
Aula 00
15/12/14
Aula 01
22/12/14
Aula 02
26/12/14
Aula 03
12/01/15
Aula 04
15/01/15
Aula 05
19/01/15
Aula 06
22/01/15
Aula 07
02/02/15
Aula 08
09/02/15
Aula 09
16/02/15
Aula 10
23/02/15
Contedo a ser trabalhado

Modelos de Ciclos de Vida.
RUP
Metodologias geis de Desenvolvimento
BPM e BPMN.
Engenharia de Requisitos.
Anlise e Projeto.
UML
Testes.
Anlise de Pontos de Funo.
NBR ISO/IEC 12207. NBR ISO/IEC 9126. Modelos de gesto: bazar,
catedral e colaborativo.
Gesto de Configurao. ISO/IEC 14598-3. Padres de projeto
3. Bibliografia
1. Pressman, R. S. Software Engineering. A practioners approach. 7 Ed. McGraw Hill.
2010.
2. Sommerville, I. Software Engineering. 9 Ed. Addison-Wesley. 2011.
Pgina 3 de 62

Aula 00
Vitor Almeida
4. Conceitos Gerais
Quando a banca pede os conceitos gerais da engenharia de software, isso
significa que ela est ordenando ao concurseiro que leia o primeiro captulo das duas
principais referncias na rea de engenharia de software: Pressman e Sommerville.
Em nossa aula, no vamos fazer diferente. Por isso, a ideia aqui apresentar
um resumo desses captulos, focando naquilo que j caiu em concursos anteriores.
Se o tema engenharia de software, vamos iniciar nossos estudos definindo o
que o software.
CONCEITO DE SOMMERVILLE
Software de Computador programas de computador e documentao

associada. Produtos de software podem ser desenvolvidos para um cliente particular
ou podem ser desenvolvidos para um mercado geral.
CONCEITO DE PRESSMAN
Software de Computador o produto que profissionais de software

desenvolvem e ao qual do suporte no longo prazo. Abrange programas executveis
em um computador, contedos (ou estruturas de dados) e informaes descritivas
(tanto na forma impressa como na virtual).
Para desenvolver softwares, esses profissionais se utilizam da engenharia de
software. A primeira definio de Pressman para essa disciplina apresentada a
seguir:
Engenharia de software abrange um processo, um conjunto de mtodos e

um leque de ferramentas que possibilitam aos profissionais desenvolverem software
de altssima qualidade.
Falando em qualidade, Sommerville nos apresenta o que um software de
qualidade: o que satisfaz os requisitos solicitados pelo usurio. Deve ser fcil de
manter, ter boa performance, ser confivel e fcil de usar. Em seu primeiro captulo,
esse autor j nos cita 03 atributos de qualidade:
Pgina 4 de 62

Aula 00
Vitor Almeida
1. Manutenibilidade - O software deve evoluir para atender os requisitos que

mudam
2. Eficincia - O software no deve desperdiar os recursos do sistema
3. Usabilidade - O software deve ser fcil de usar pelos usurios para os quais ele
foi projetado
Entretanto, saiba que os atributos de qualidade esperados para um software
variam conforme sua aplicao. Assim, um software de um banco deve ser seguro,
enquanto que um jogo deve ser responsivo, sensvel aos comandos do usurio.
Para ningum dizer que no falei de flores, olha como o Sommerville define a
engenharia de software:
Engenharia de Software disciplina da engenharia que se preocupa com todos

os aspectos da produo de um software, desde os estgios iniciais de especificao
do sistema at a manuteno deste aps ter sido colocado em uso.
Sommerville no perde tempo e diferencia a engenharia de software da cincia
da computao. Enquanto esta ltima foca nas teorias e nos fundamentos, a primeira
se preocupa com os aspectos prticos do desenvolvimento e entrega de software til.
Outra comparao feita com a engenharia de sistemas, que engloba todos os
aspectos de sistemas complexos que so desenvolvidos e no apenas o software.
Pois bem, o software, em todas as suas formas e campos de aplicao, deve
passar por processos de engenharia. Neste sentido, vale a pena refinar o conceito de
engenharia de software (o conceito do IEEE visto no livro de Pressman):
CONCEITO DO IEEE
Engenharia de software aplicao e o estudo de uma abordagem sistemtica,

disciplinada e quantificvel no desenvolvimento, na operao e na manuteno do
software.
Observe que aqui temos um conceito conflitante com o de Sommerville.
Enquanto que o IEEE nos diz que a engenharia de software se preocupa no s com a
aplicao, mas tambm com o estudo da abordagem, Sommerville nos diz que a
preocupao da engenharia de software com os aspectos prticos.
Pgina 5 de 62

Aula 00
Vitor Almeida
Assim, se voc estiver de frente com uma questo, procure identificar qual o
autor foi utilizado como base para a questo, para no acabar tendo de se preocupar
com um possvel recurso posteriormente.
Pressman nos apresenta tambm o conceito da engenharia de software
dividida em camadas:
Observe que a base de tudo a qualidade. Ou seja, qualquer abordagem de

engenharia de software deve estar fundamentada em um comprometimento
organizacional com a qualidade. Alm dela, temos mais 03 camadas:
1. Processo: define uma metodologia que deve ser estabelecida para a entrega
efetiva de software. Se preocupa em quais e em que ordem as atividades sero
realizadas.
2. Mtodos: fornecem as informaes tcnicas para desenvolver software.
3. Ferramentas: fornecem suporte automatizado ou semiautomatizado para o
processo e para os mtodos.
Exemplificando, temos como processos de software o RUP e as metodologias
geis; como mtodos, as diversas atividades que so desenvolvidas em um processo,
como codificao e teste; e como ferramentas os softwares de modelagem, as
ferramentas CASE, as IDE, entre outras.
Mudando um pouco de assunto, algo que tambm cobrado em concursos
a diferena entre software e hardware. Mas, no estamos falando daqueles conceitos
que aprendemos no Jardim da Infncia de que software a parte lgica e hardware
a parte fsica. Estamos nos referindo s caractersticas apresentadas por Pressman
que diferenciam o software do hardware:
1. Software desenvolvido ou passa por um processo de engenharia; ele no
fabricado no sentido clssico.
Pgina 6 de 62

Aula 00
Vitor Almeida
2. Software no se desgasta.
3. Embora a indstria caminhe para a construo com base em componentes, a
maioria dos softwares continua a ser construda de forma personalizada (sob
encomenda).
Quanto ideia de que software no se desgasta, vale a pena fazermos um
comparativo dos grficos de tempo x defeitos do hardware em relao ao software:
Veja que o hardware tem um comportamento de se encontrar muitos erros no

incio do seu ciclo de vida, decorrentes de defeitos de projeto ou de fabricao, e ao
trmino, quando os componentes do hardware em uso comeam a se desgastar.
O software, por outro lado, no sofre desgaste. O que acontece que ao longo
do seu processo evolutivo, a cada grande mudana implementadas, uma srie de
erros, chamados de colaterais, so inseridos no software, tornando-o cada fez mais
pesado e de difcil manuteno, at que se chega deciso de se aposentar o
sistema.
Uma informao que pode aparecer ou ser cobrada em sua prova o custo da
engenharia de software. Sommerville nos diz que 60% desses custos com
desenvolvimento e 40% com os testes. Para softwares que evoluem, muitas vezes
os custos com manutenes evolutivas excedem os do desenvolvimento da primeira
verso do software.
Outra coisa que devemos estudar, antes de focarmos os processos de
desenvolvimento de software, so os princpios da engenharia de software. A verso
atual do Pressman apresenta os seguintes princpios:
1. A razo de tudo agregar valor ao cliente.
2. Mantenha simples (KISS Keep It Simple, Stupid).
Pgina 7 de 62

Aula 00
Vitor Almeida
3. Mantenha a viso.
4. O que voc produz, outros iro consumir.
5. Esteja aberto ao futuro.
6. Planeje para o reuso.
7. Pense.
Sommerville, entretanto, nos traz uma abordagem mais prtica e nos
apresenta os fundamentos da engenharia de software que devem ser utilizados no
desenvolvimento de todos os tipos de software:
1. Utilizao de um processo de desenvolvimento de software.
2. Confiana e performance so atributos de qualidade esperados por todos os
softwares.
3. O entendimento das especificaes e requisitos do software importante.
4. O uso dos recursos disponveis deve ser eficiente.
Por fim, temos tambm os mitos de software:
Mitos relativos ao software crenas infundadas sobre o software e sobre o

processo usado para cria-lo, que remontam aos primrdios da computao.
So eles:
MITOS DE GERENCIAMENTO
MITOS DOS CLIENTES
MITOS DOS PROFISSIONAIS DA

REA
J temos um livro que est cheio
Uma definio geral dos objetivos
Uma vez feito um programa e
de padres e procedimentos para
suficiente para comear a
colocado em uso, nosso trabalho
desenvolver software. Ele no
escrever programas podemos
est terminado
supre meu pessoal com tudo que
preencher detalhes
eles precisam saber?
posteriormente.
Se o cronograma atrasar,
Os requisitos de software mudam
At que o programa entre em
poderemos acrescentar mais
continuamente, mas as mudanas
funcionamento, no h maneira
programadores e ficarmos em dia
podem ser facilmente assimiladas,
de avaliar sua qualidade.
(algumas vezes denominado como
pois o software flexvel.
conceito da horda mongol.

Se eu decidir terceirizar o projeto
O nico produto passvel de
de software, posso simplesmente
entrega o programa em
relaxar e deixar essa empresa
funcionamento.
realiza-lo.
Pgina 8 de 62

Aula 00
Vitor Almeida
A engenharia de software nos far
criar documentao volumosa,
desnecessria e, invariavelmente,
ir nos retardar.
Isto posto, vamos ver como a FCC vem cobrando os conceitos gerais da
engenharia de software.
Questo 01 Prova: FCC - 2010 - DPE-SP - Agente de Defensoria - Programador
A Engenharia de Software
I. no visa o desenvolvimento de teorias e fundamentaes, preocupando-se
unicamente com as prticas de desenvolvimento de software.
II. tem como foco o tratamento dos aspectos de desenvolvimento de software,
abstraindo-se dos sistemas baseados em computadores, incluindo hardware e
software.
III. tem como mtodos as abordagens estruturadas para o desenvolvimento de
software que incluem os modelos de software, notaes, regras e maneiras de
desenvolvimento.
IV. segue princpios, tais como, o da Abstrao, que identifica os aspectos
importantes sem ignorar os detalhes e o da Composio, que agrupa as atividades
em um nico processo para distribuio aos especialistas.
correto o que se afirma em
a) III e IV, apenas.
b) I, II, III e IV.
c) I e II, apenas.
d) I, II e III, apenas.
e) II, III e IV, apenas.
Comentrios: vamos analisar cada uma das afirmativas:
unicamente com as prticas de desenvolvimento de software. Sommerville nos diz
que a diferena da cincia da computao para a engenharia de software que a
primeira foca na teoria e nas fundamentaes enquanto que a segunda se relaciona
com as prticas de desenvolvimento de software e a entrega de software til. Diante
Pgina 9 de 62

Aula 00
Vitor Almeida
desta afirmao, a assertiva estaria certa, no verdade? De fato, ela foi considerada
verdadeira.
S que o examinador no leu o captulo todo de Sommerville. Mais frente,
este autor declara que a engenharia de software no trata apenas do processo tcnico
de desenvolvimento de software. Tambm inclui o gerenciamento do projeto e o
desenvolvimento de ferramentas, mtodos e teorias que auxiliam na produo de
software.
Complementarmente, temos Pressman que nos diz tambm que a engenharia
se preocupa com o estudo da abordagem utilizada no desenvolvimento de software.
Ou seja, temos uma afirmativa questionvel, mas parece que ningum entrou com
recurso e ela continuou certa.
software. Sommerville tambm nos diz a diferena entre a engenharia de sistemas e
a engenharia de software. A primeira se preocupa com todos os aspectos do
desenvolvimento de sistemas baseados em computadores, incluindo o hardware, o
software e os processos de engenharia. A engenharia de software apenas parte da
engenharia de sistemas, se preocupando primariamente com o desenvolvimento do
software. Afirmativa correta.
desenvolvimento. Esse estruturada no tem relao com o paradigma de
programao estruturada. O examinador est falando que na engenharia de software
utilizamos abordagens organizadas e definidas. Bastante razovel, no ? Afirmativa
correta.
em um nico processo para distribuio aos especialistas. Quando estivermos
estudando a anlise e projeto orientado a objetos, passaremos por diversos princpios
e conceitos importantes. Por enquanto, saiba que, por meio da abstrao,
representamos o mundo real no sistema, trazendo apenas aquilo que importante
Pgina 10 de 62

Aula 00
Vitor Almeida
para o sistema. Assim, um objeto carro em um programa de uma locadora de

automveis ter certos atributos que no estaro representados em um programa de
registro de tempos em campeonatos com carros de corrida. Afirmativa errada.
Gabarito: D
Questo 02 Prova: FCC - 2010 - TRE-AM - Analista Judicirio - Tecnologia da
Informao
a) no tem como mtodo a abordagem estruturada para o desenvolvimento de
software, pois baseia-se exclusivamente nos modelos de software, notaes, regras
e tcnicas de desenvolvimento.
b) se confunde com a Cincia da Computao quando ambas tratam do
desenvolvimento de teorias, fundamentaes e prticas de desenvolvimento de
software.
c) tendo como foco apenas o tratamento dos aspectos de construo de software,
subsidia a Engenharia de Sistemas no tratamento dos sistemas baseados em
computadores, incluindo hardware e software.
d) tem como foco principal estabelecer uma abordagem sistemtica de
desenvolvimento, atravs de ferramentas e tcnicas apropriadas, dependendo do
problema a ser abordado, considerando restries e recursos disponveis.
e) segue princpios, tais como, o da Abstrao, que identifica os aspectos
Comentrios: Qualquer semelhana com a questo anterior no mera coincidncia!
Vamos analisar cada afirmativa:
software, pois baseia-se exclusivamente nos modelos de software, notaes, regras
e tcnicas de desenvolvimento. Acabamos de explicar que tem! Afirmativa errada.
software. Acabamos de ver que so reas do conhecimento distintas. Afirmativa
errada.
Pgina 11 de 62

Aula 00
Vitor Almeida

computadores, incluindo hardware e software. A engenharia de software no
subsidia a engenharia de sistemas com relao ao hardware do sistema. Afirmativa
errada.
problema a ser abordado, considerando restries e recursos disponveis. isso
mesmo, a engenharia de software organiza o desenvolvimento de software,
fornecendo ferramentas apropriadas e auxiliando no gerenciamento do projeto de
software, o que inclui a gesto das restries e recursos disponveis. Afirmativa
correta.
e) segue princpios, tais como, o da Abstrao, que identifica os aspectos
em um nico processo para distribuio aos especialistas. De novo! :) Afirmativa
errada, pois a abstrao ignora detalhes irrelevantes para o sistema.
Gabarito: D
Questo 03 Prova: FCC - 2008 - METR-SP - Analista Treinee - Cincias da
Computao
O objetivo da Engenharia de Software estabelecer uma sistemtica abordagem de
problema a ser abordado, considerando restries e recursos disponveis. A
Engenharia de Software
I. no se confunde com a Cincia da Computao, pois enquanto esta visa o
desenvolvimento de teorias e fundamentaes, a Engenharia de Software se
preocupa com as prticas de desenvolvimento de software.
II. tem como foco nico o tratamento dos aspectos de desenvolvimento de software,
o que a diferencia da Engenharia de Sistemas, que trata dos sistemas baseados em
Pgina 12 de 62

Aula 00
Vitor Almeida

desenvolvimento.
correto o que consta em
a) I e II, apenas.
b) III e IV, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, II, III e IV.
Comentrios: De novo! Me nego a comentar... :)
Gabarito: C
Questo 04 Prova: FCC - 2012 - TRT - 6 Regio (PE) - Tcnico Judicirio - Tecnologia
da Informao
Considere: uma disciplina que se ocupa de todos os aspectos da produo de
software, desde os estgios iniciais de especificao do sistema at a manuteno
desse sistema, depois que ele entrou em operao. Seu principal objetivo fornecer
uma estrutura metodolgica para a construo de software com alta qualidade. A
definio refere-se
a) ao ciclo de vida do software.
b) programao orientada a objetos.
c) anlise de sistemas.
d) engenharia de requisitos.
e) engenharia de software.
Comentrios: claro que a engenharia de software de Sommerville, pessoal!
Gabarito: E
Questo 05 Prova: FCC - 2013 - PGE-CE - Analista Ministerial rea Cincias da
Computao
Pgina 13 de 62

Aula 00
Vitor Almeida
Engenharia de Software a aplicao de abordagens sistemticas, disciplinadas e

quantificveis ao desenvolvimento, operao e manuteno de software, alm do
estudo dessas abordagens. Com relao Engenharia de Software, correto afirmar
que
(A) o trabalho termina assim que o software colocado em operao.
(B) ferramentas e computadores de boa qualidade so condies necessrias e
suficientes para que uma empresa produza software de qualidade.
(C) todo bom gerente (competente) pode gerenciar qualquer projeto de software
obter um produto de qualidade.
(D) se um projeto estiver atrasado, adicionar mais pessoas pode causar mais atrasos.
(E) os requisitos mudam com frequncia, mas sempre possvel acomod-los, pois
o software flexvel.
Comentrios: Observe que as alternativas A, B, C e E nos apresenta mitos citados pelo
Pressman. J a alternativa D nos traz uma verdade, que a negao de um dos mitos
do Pressman.
Gabarito: D
QUESTO 06 CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da
Informao - Arquitetura de Tecnologia
Os princpios de engenharia de software definem a necessidade de formalidades
para reduzir inconsistncias e a decomposio para lidar com a complexidade.
Comentrios: Por incrvel que parea, existem poucas questes que abordam os
princpios da engenharia de software. Eu tenho catalogada apenas esta do CESPE.
Mas no em Pressman que acharemos a resposta para a questo, mas em
Ghezzi!
Ghezzi traz em seu livro, Fundamentals of Software Engineering, Second
Edition, os seguintes princpios da engenharia de software:
1. Rigor e formalidade (sistematizao e formalizao das atividades de engenharia de
software).
Pgina 14 de 62

Aula 00
Vitor Almeida
2. Separao de conceitos (dividir para conquistar, ao se analisar o problema a ser

resolvido pelo software).
3. Modularizao (um sistema complexo deve ser dividido em mdulos).
4. Abstrao (nem todos os detalhes da realidade devem ser implementados no
software).
5. Antecipao de mudanas (capacidade de responder a mudanas no tempo
adequado, antecipando as necessidades de evoluo do software).
6. Generalidade (busca por solues gerais que podem ser reutilizadas em diversos
softwares).
7. Incrementalidade (desenvolva em etapas ou incrementos).
A necessidade de formalidade encontramos no primeiro princpio (Rigor e
Formalidade) e a decomposio encontramos no terceiro princpio (modularizao).
Logo, a questo est CERTA.
Observe que temos uma questo de 2010 pegando uma bibliografia de 2003,
trazendo princpios da poca em que processos mais formais de software (como o
RUP) dominavam o mercado. As metodologias geis trouxeram novos princpios, que
combinam mais com a abordagem do Pressman.
Gabarito: C
5. Ciclo de Vida do Software

Oi pessoal, vamos iniciar o estudo do Processo de Desenvolvimento de
Software. Este, na viso de Pressman uma srie de passos previsveis, um roteiro
que ajuda a criar um resultado de alta qualidade e dentro do prazo estabelecido.
J Sommerville nos diz o seguinte:

CONCEITOS DE SOMMERVILLE
Processo de Desenvolvimento de Software um conjunto de atividades

relacionadas que levam produo do produto software. Estas atividades podem
Pgina 15 de 62

Aula 00
Vitor Almeida
envolver o desenvolvimento do software do zero, a partir de uma linguagem de

programao, ou a evoluo de um software j existente.
Sommerville nos faz uma diferenciao do Processo de Desenvolvimento de
Software para o Modelo de Processo de Desenvolvimento de Software, sendo que
este ltimo uma representao simplificada do processo.
Ou seja, quando falamos em cascata, iterativo, incremental, evolucionrio etc.,
estamos nos referindo a modelos didticos de processo de desenvolvimento de
software que serviro de base para o desenvolvimento do processo de
desenvolvimento de software.
Assim, deixando bem clara essa diferena, enquanto que o modelo de processo
de software ser visto apenas em livros, o processo de desenvolvimento de software,
com todos os detalhes necessrios, ser encontrado em uso em uma empresa que
desenvolve software.
Um adendo: na dcada passada, muitos autores, inclusive o Sommerville e o
Pressman, gostavam de usar o nome Ciclo de Vida do Software para representar as
diversas atividades, etapas ou fases pelas quais o software passava at ser
aposentado.
Hoje, parece que estamos evoluindo para o consenso de se utilizar o termo
processo de desenvolvimento de software para abranger desde a concepo at o
descarte do software. Mas, no se iluda, ainda vemos muito ciclo de vida do

software por a...
Pois bem, antes de continuar nosso estudo, sinto que temos um outro
problema conceitual, uma vez que a gente acaba dizendo que um processo se divide
em fases, ou etapas, ou atividades, ou tarefas, como se todos esses termos fossem
sinnimos. O que acontece que tudo depende do autor (e da edio do livro).
Atualmente, Pressman usa a seguinte hierarquia dentro de um processo de
desenvolvimento de software:
CONCEITOS DE PRESSMAN
Processo um conjunto de atividades, aes e tarefas realizadas na criao de algum

produto de trabalhos.
Pgina 16 de 62

Aula 00
Vitor Almeida
Atividade esfora-se para atingir um objetivo amplo (por exemplo, comunicar-se

com os interessados) e utilizada independentemente do campo de aplicao,
tamanho do projeto, da complexidade de esforos ou do grau de rigor com que a
engenharia de software ser aplicada.
Ao envolve um conjunto de tarefas que resulta num artefato de software
fundamental. Exemplo: a ao projeto de arquitetura resulta no modelo de projeto de
arquitetura.
Tarefa se concentra em um objetivo pequeno, porm, bem definido (por exemplo,
realizar testes de unidades) e produz um resultado tangvel.
Sommerville, por outro lado, fala apenas em atividades (so quatro genricas,
que veremos j j) e subatividades. Aproveitando, este autor nos diz que um processo
de desenvolvimento de software tambm tem:
CONCEITOS DE SOMMERVILLE
Produtos a sada de uma atividade do processo.

Papel representa a responsabilidade de uma pessoa envolvida em um processo.
Exemplo: gerente de projetos, programador, testador etc.
Pr e Ps-condies so situaes que devem ocorrer antes ou depois de uma
atividade ser desenvolvida ou um produto ser entregue. Por exemplo, antes de se
iniciar o projeto pode ser que seja necessrio que todos os requisitos levantados na
etapa anterior sejam aprovados pelo cliente.
Quando formos responder as questes, veremos que no existe um padro na
nomenclatura e ficar se prendendo a o que uma atividade ou o que uma tarefa um
preciosismo que no necessrio para fazer uma boa prova.
Um processo de desenvolvimento de software possui atividades e um fluxo
dessas atividades. Vamos ver, primeiramente, quais so as atividades existentes em
um processo de desenvolvimento de software genrico.
Pressman apresenta o seguinte processo genrico, chamando cada uma dessas
etapas de Atividades Metodolgicas, as quais so compostas por um conjunto de
aes de engenharia de software:
1. Comunicao: Comunicao com as partes interessadas do projeto, buscando
entender os objetivos do software, e levantamento de requisitos.
Pgina 17 de 62

Aula 00
Vitor Almeida
2. Planejamento: Desenvolvimento do plano de projeto do software, que descreve

as atividades tcnicas que sero conduzidas, os riscos envolvidos, os recursos
necessrios, os produtos esperados e o cronograma de atividades.
3. Modelagem: Criao dos modelos para melhor entendimento dos requisitos
levantados e definio da arquitetura do software que atender estes requisitos.
4. Construo: Codificao e testes.
5. Implantao: Entrega do software ao cliente e avaliao do software pelo cliente.
Atreladas a este processo genrico existem atividades "guarda-chuva" ou de
apoio, que so aplicadas durante toda a execuo do processo, ajudando a controlar
o andamento do projeto, a gerir a equipe de desenvolvimento, a gerenciar riscos etc.
Pressman cita os seguintes exemplos de atividades de apoio:
1. Controle e Acompanhamento do Projeto: Avaliao do andamento do projeto em
relao ao plano do projeto e execuo de aes para garantir o cronograma
inicial.
2. Administrao de Riscos: Anlise de riscos que podem impactar na entrega e na
qualidade do software.
3. Garantia da Qualidade de Software: Execuo de atividades para garantia da
qualidade do software.
4. Revises Tcnicas: Avaliao dos artefatos gerados para encontrar erros que
podem influenciar as atividades subsequentes.
5. Medio: Definio e coleta de indicadores que auxiliam a verificao do
andamento dos trabalhos.
6. Gerenciamento de Configurao de Software: Gerencia o efeito de mudanas ao
longo do processo.
7. Gerenciamento da Reusabilidade: Define critrios para reuso de componentes.
8. Preparo e Produo de Artefatos de Software: So atividades para definir e criar
artefatos como modelos, documentos, formulrios, listas etc.
A abordagem de Sommerville, por outro lado, mais simplificada. Para este
autor, existem quatro atividades que esto presentes em todos os processos de
desenvolvimento de software:
Pgina 18 de 62

Aula 00
Vitor Almeida
1. Especificao de Software: So definidas as funcionalidades do software e

restries para sua operao.
2. Design (Projeto) e Implementao de Software: O software planejado e
produzido, conforme sua especificao.
3. Validao de Software: O software avaliado para verificar se atende as
necessidades do cliente.
4. Evoluo do Software: O software evolui para atender as necessidades de mudana
do cliente.
Deu para perceber que no existe um padro na definio das atividades
genricas de um processo de desenvolvimento de software, no verdade? E isso
um problema quando o examinador inventa de pegar uma bibliografia obscura para
elaborar uma questo.
Neste sentido, aconselho a voc compreender a seguinte sequncia, que
apresenta atividades inerentes ao processo de desenvolvimento de software, e que,
volta e meia, so cobradas em questes de concursos:
1. Anlise de Negcio: conhecimento do negcio, mapeamento dos processos de
negcio da organizao.
2. Engenharia de Requisitos: envolve o levantamento, a anlise e a especificao dos
requisitos, que so as funcionalidades e restries do software.
3. Anlise: constitui na modelagem do problema a ser resolvido por meio da
elaborao de diagramas para esclarecer os requisitos.
4. Projeto (Design): implica na elaborao da arquitetura do software. Neste
momento desenhada a soluo do sistema, definio da tecnologia e dos
componentes que formaro o software. Dizemos que, se na anlise, buscamos
entender o problema e modelar sua soluo, no projeto apresentamos como esta
soluo ser transformada em software.
5. Codificao (ou Desenvolvimento ou Implantao): criao de cdigo executvel.
6. Testes: verificao (o software foi desenvolvido corretamente) e validao (o
software reflete as necessidades do cliente) do sistema.
7. Implantao: momento em que o software instalado e colocado para funcionar
no cliente.
Pgina 19 de 62

Aula 00
Vitor Almeida
8. Evoluo (ou Manuteno): realizao de manutenes corretivas e evolutivas do

sistema.
Alm das etapas que compe o processo, este tambm possui um outro
aspecto importante: o Fluxo do Processo. Pressman nos apresenta os seguintes fluxos:
1. Fluxo de Processo Linear As atividades metodolgicas (ou etapas) ocorrem

em sequncia.
2. Fluxo de Processo Iterativo Repete uma ou mais etapas antes de prosseguir
para a seguinte.
3. Fluxo de Processo Evolucionrio As atividades so executadas de uma forma
circular, onde cada volta por cada uma das atividades conduz a uma verso
mais completa do software.
Pgina 20 de 62

Aula 00
Vitor Almeida
4. Fluxo de Processo Paralelo Uma ou mais atividades so executadas em

paralelo com outra(s) atividade(s).
Observe que o fluxo de processo e o conjunto de etapas previstas para o
processo definem os diferentes tipos de processos de software que existem (e que ns
vamos estudar na sequncia).
Mas, antes, vamos olhar algumas questes da FCC:
Questo 07 Prova: FCC - 2012 - MPE-AP - Analista Ministerial - Tecnologia da
Informao
Um processo de software um conjunto de atividades relacionadas que levam
produo de um produto de software. Existem muitos processos de software
diferentes, mas todos devem incluir quatro atividades fundamentais: especificao,
projeto e implementao, validao e
a) teste
b) evoluo.
c) prototipao.
d) entrega.
e) modelagem.
Comentrios: a questo avalia seu conhecimento acerca do modelo genrico de
processo do Sommerville. Como vimos, a nica atividade citada por este autor e que
no est presente na pergunta a evoluo do software.
Gabarito: B
Questo 08 Prova: FCC - 2011 - TRT - 23 REGIO (MT) - Tcnico Judicirio Tecnologia da Informao
No processo de desenvolvimento de software, a atividade que refere-se garantia
de que o sistema de software ir ao encontro de requisitos do produto, como
tambm assegurar que futuros requisitos possam ser atendidos:
a) Especificao.
b) Arquitetura de Software.
c) Anlise de Requisitos.
d) Implementao.
e) Suporte e Treinamento.
Pgina 21 de 62

Aula 00
Vitor Almeida
Comentrios: Ok pessoal, vou agora introduzir uma verdade verdadeira: a FCC gosta
da wikipedia. Fica de tarefa de casa, inclusive, a leitura de todos os verbetes da
enciclopdia on-line relacionados aos assuntos cobrados no edital, certo?
Em http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software temos
que "A arquitetura de um sistema de software remete a uma representao abstrata
daquele sistema. Arquitetura concernente garantia de que o sistema de software

ir ao encontro de requisitos do produto, como tambm assegurar que futuros
requisitos possam ser atendidos. A etapa da arquitetura tambm direciona as
interfaces entre os sistemas de software e outros produtos de software, como
tambm com o hardware bsico ou com o sistema operacional".
A mesma wikipedia apresenta os "passos/atividades" de um processo de
desenvolvimento de software, a saber:
1. Anlise Econmica
2. Anlise de requisitos de software
3. Especificao
4. Arquitetura de Software
5. Implementao (ou codificao)
6. Teste
7. Documentao
8. Suporte e Treinamento de Software
9. Manuteno
Este modelo de processo de software genrico, na verdade, citado
originalmente por Velloso (Velloso, F. Informtica. Conceitos Bsicos. 8 Ed. Ed.
Elsevier. 2011). Da cabe a voc decidir. O examinador usou o livro ou a wikipedia?
Pior, vale a pena estudar um livro de conceitos bsicos de informtica para
fazer uma prova de engenharia de software? Eu leria apenas a wikipedia .
Gabarito: B
6. Modelo em Cascata
O Modelo em Cascata foi o primeiro modelo de processo de software
publicado (em 1970). A ideia original que voc passava de uma atividade para outra
Pgina 22 de 62

Aula 00
Vitor Almeida
tal qual uma cachoeira corre para baixo. Este modelo prioriza o planejamento, tendo
em vista que voc precisa planejar e definir o cronograma de todas as atividades antes
de iniciar o trabalho.
No modelo em cascata, uma estratgia sequencial de avano entre as
atividades executada. O desenvolvimento do software se inicia com a especificao
dos requisitos e progride pelas etapas de planejamento, modelagem, construo,
testes e entrega, culminando no software completo ao trmino do processo.
Por causa disso, o modelo em cascata s utilizado em projetos
bastante especficos onde os requisitos so bem conhecidos, pois o aparecimento de
novos requisitos mais frente no fluxo de desenvolvimento resulta invariavelmente
em grande prejuzo, quer seja por eles no serem agregados ao projeto, quer seja pelo
aborto do projeto e a necessidade de se reiniciar o processo como um todo.
A figura a seguir, extrada de Pressman, apresenta o modelo em cascata de
maneira esquematizada. Observe que j definimos cada uma das atividades
anteriormente.
No entanto, Sommerville apresenta um modelo em cascata um pouco

diferente:
Pgina 23 de 62

Aula 00
Vitor Almeida
Estas atividades esto descritas a seguir:

1. Definio e Anlise de Requisitos: As funcionalidades e restries do software so
identificadas junto aos usurios e detalhadas.
2. Projeto do Sistema e do Software: Definio das abstraes e relacionamentos do
software e elaborao de uma arquitetura.
3. Implementao e Teste de Unidade: Construo das unidades que iro compor o
software previstas na fase anterior e teste de cada uma destas unidades.
4. Integrao e Teste de Sistema: As unidades so integradas e testadas como se
fosse um nico sistema.
5. Operao e Manuteno: O software instalado e colocado em uso. A
manuteno envolve a correo de erros no encontrados anteriormente e
melhorias decorrente da descoberta de novos requisitos.
A representao grfica de Sommerville apresenta um aspecto que foi previsto
inicialmente no modelo que era um loopback nas atividades, ou seja, o fluxo de
execuo poderia voltar para a atividade anterior, trazendo feedbacks da atividade
posterior. No entanto, a maioria das organizaes que usam o modelo em cascata
utilizam-no como se fosse estritamente linear.
Alm disso, o Sommerville j nos mostra a relao entre projeto e teste, que
ser apresentada de forma explcita no Modelo em V, que estudaremos j j
Pgina 24 de 62

Aula 00
Vitor Almeida
A pergunta clssica : "Preciso decorar as duas sequncias de atividades?".

Veja bem, em ambos os casos a sequncia: requisitos, modelagem, projeto,
codificao, testes e implantao seguida. Procure aprender esta sequncia lgica e no
decorar atividades, mas esteja preparado para uma pergunta que pergunte a sequncia do
modelo em cascata segundo um autor ou outro.
Antes de terminar, vale a pena falar do Modelo em V, que uma variante do

modelo em cascata. O modelo em V o modelo em cascata com uma representao
grfica do processo de testes. Observando a figura a seguir, retirada de Pressman, na
medida em que o fluxo avana na perna esquerda do V, as necessidades do cliente e a
arquitetura do software so definidas.
Ao trmino da codificao, a equipe de desenvolvimento avana pela perna

direita do V, realizando testes at o aceite final do cliente. O modelo em V permite
visualizar quando as atividades de verificao (testes do software) e validao
(aceitao do software pelo cliente) so aplicadas no processo.
Vamos ao que interessa:
Pgina 25 de 62

Aula 00
Vitor Almeida
Questo 09 Prova: FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento

e Manuteno
A principal metodologia tradicional utilizada no desenvolvimento de software o
modelo clssico tambm conhecido como cascata ou sequencial. Nesse modelo,
a) cada etapa tem associada ao seu trmino uma documentao que deve ser
aprovada para que a etapa posterior possa ter incio.
b) o projeto dividido em fases de maneira flexvel.
c) o custo das alteraes do software diminui medida que o desenvolvimento
progride.
d) utiliza-se o desenvolvimento incremental e iterativo.
e) os requisitos no podem ser estveis.
Comentrios: Analisando nossa questo, temos que:
aprovada para que a etapa posterior possa ter incio. Exato, esta afirmativa
apresenta-nos uma das principais caractersticas do modelo em cascata: as atividades
ocorrem sequencialmente. Assim, para que uma atividade tenha incio, a anterior
dever ser finalizada. Afirmativa correta.
b) o projeto dividido em fases de maneira flexvel. Claro que no, tudo ocorre
sequencialmente, como se fosse uma cascata. Primeiro uma atividade, depois a
outra...
progride. Pelo contrrio, aumenta! mais fcil corrigir um problema ou alterar uma
necessidade enquanto estamos analisando requisitos e no quando o software j est
pronto e entregue.
d) utiliza-se o desenvolvimento incremental e iterativo. Nada disso, j j falamos
dessas duas palavrinhas.
e) os requisitos no podem ser estveis. Pelo contrrio! Como o modelo no est
adaptado para lidar com mudanas, se os requisitos forem instveis, volteis, nosso
cascata no o mais adequado.
Pgina 26 de 62

Aula 00
Vitor Almeida
Gabarito: A
Questo 10 Prova: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da
Informao - Prova 3
O processo de engenharia de software denominado ciclo de vida clssico refere-se
ao modelo
a) em cascata.
b) incremental.
c) evolucionrio.
d) prototipagem.
e) de processo unificado.
Comentrios: O cascata tambm conhecido como ciclo de vida clssico.
Gabarito: A
Questo 11 Prova: FCC - 2012 - MPE-PE - Analista Ministerial - Informtica
Dentre os principais estgios do modelo de desenvolvimento em cascata est o
Projeto de sistema e software, que
a) a fase mais longa do ciclo de vida do sistema. O sistema instalado e colocado
em uso e efetuada a correo de erros que no foram descobertos em estgios
iniciais.
b) estabelece os servios, restries e metas do sistema por meio de consulta aos
usurios, e em seguida define em detalhes estes itens para serem utilizados como
uma especificao do sistema.
c) integra as unidades do programa ou programas como um sistema completo e
efetuam testes para garantir que os requisitos do software tenham sido atendidos.
d) aloca os requisitos tanto para sistemas de hardware como para sistemas de
software, por meio de uma arquitetura geral do sistema.
e) desenvolve o projeto de software como um conjunto de programas ou unidades
de programas para posteriormente serem aplicados os testes unitrios.
Comentrios: Lembra do cascata do Sommerville?
2. Projeto do Sistema e do Software: Definio das abstraes e relacionamentos do
software e elaborao de uma arquitetura.
Pgina 27 de 62

Aula 00
Vitor Almeida
Pois bem, falou em projeto, associe arquitetura do software. Assim, nosso

gabarito a alternativa D.
As demais alternativas se relacionam s seguintes etapas:
a) OPERAO E MANUTENO: a fase mais longa do ciclo de vida do sistema. O
sistema instalado e colocado em uso e efetuada a correo de erros que no foram
descobertos em estgios iniciais.
b) DEFINIO E ANLISE DE REQUISITOS: estabelece os servios, restries e metas
do sistema por meio de consulta aos usurios, e em seguida define em detalhes estes
itens para serem utilizados como uma especificao do sistema.
c) INTEGRAO E TESTES DE SISTEMA: integra as unidades do programa ou programas
como um sistema completo e efetuam testes para garantir que os requisitos do
software tenham sido atendidos.
e) IMPLEMENTAO E TESTES DE UNIDADE: desenvolve o projeto de software como
um conjunto de programas ou unidades de programas para posteriormente serem
aplicados os testes unitrios.
Gabarito: D
QUESTO 12 Prova: FCC - 2013 - ALERN - Analista Legislativo Habilitao Analista de
Sistemas
O primeiro modelo de desenvolvimento de software a ser publicado foi derivado de
processos mais gerais da engenharia de sistemas. Por causa do encadeamento entre
uma fase e outra, esse modelo conhecido como modelo em cascata ou ciclo de vida
de software. Dentre seus principais estgios se encontram a anlise e definio de
requisitos, o projeto de sistema e software e
(A) anlise de recursos e software.
(B) desenvolvimento incremental.
(C) gerao de relatrios de teste.
(D) pesquisa e testes.
(E) implementao e teste unitrio.
Comentrios: Observe que o examinador pede as etapas do modelo em cascata de
acordo com Sommerville:
Pgina 28 de 62

Aula 00
Vitor Almeida
Gabarito: E
QUESTO 13 Prova: FCC - 2013 - MPE-MA - Analista Ministerial Anlise e
Desenvolvimento de Sistemas
Um processo de desenvolvimento de software em geral tem como entrada os
requisitos do sistema e como sada um produto fornecido. Analise as afirmativas
sobre este tema.
I. O desenvolvimento de software envolve os estgios: anlise e definio de
requisitos, projeto do sistema, codificao, testes e entrega do sistema. Assim, o
ciclo de vida do software descreve a vida do produto de software desde sua
concepo at a implementao e entrega.
II. Um dos primeiros modelos propostos foi o cascata. Neste modelo o
desenvolvimento de um estgio deve terminar antes do prximo comear. O modelo
em V uma variao do modelo em cascata, que mostra como as atividades de teste
esto relacionadas com a anlise e o projeto. A codificao forma o V do vrtice.
III. O modelo em cascata pode ser incrementado com atividades de prototipao. A
prototipao um modelo de processo efetivo em que partes do sistema so
construdas rapidamente com o objetivo de validar os requisitos. Caso novas
alternativas sejam discutidas, deve-se comear o ciclo em cascata novamente,
abandonando-se o prottipo.
Est correto o que se afirma em
Pgina 29 de 62

Aula 00
Vitor Almeida
(A) I e II, apenas.

(B) II e III, apenas.
(C) II, apenas.
(D) I e III, apenas.
(E) I, II e III.
Comentrios: Vamos analisar cada afirmativa:
requisitos, projeto do sistema, codificao, testes e entrega do sistema. Assim, o
ciclo de vida do software descreve a vida do produto de software desde sua
concepo at a implementao e entrega. Nosso examinador esqueceu
propositadamente as etapas de manuteno (evoluo) do sistema e a provvel
aposentadoria deste. Afirmativa ERRADA.
Legal! Afirmativa CORRETA.
abandonando-se o prottipo. O examinador fez um samba misturando o modelo em
cascata com a prototipao (que, como veremos ao longo da aula, tanto pode ser uma
ferramenta para levantamento de requisitos como um modelo de processo de
software completo). Afirmativa ERRADA.
Gabarito: C
7. Modelo Iterativo e Incremental
Pgina 30 de 62

Aula 00
Vitor Almeida
Vamos falar de dois modelos bastantes famosos: o modelo iterativo e o modelo

incremental. Para Sommerville:
Modelo Incremental tem-se a ideia de se desenvolver uma implementao inicial,

apresent-la ao usurio e evoluir o software ao longo do tempo de acordo com o
feedback do usurio.
Temos ento que especificao, desenvolvimento e validao ocorrem em
paralelo para cada um dos incrementos do software que esto em construo.
Sommerville apresenta o modelo incremental da seguinte forma:
Pressman mais direto ao nos informar que a principal caracterstica deste

modelo a entrega de incrementos:
Modelo Incremental libera uma srie de verses, denominadas incrementos, que

oferecem, progressivamente, maior funcionalidade para o cliente medida que cada
incremento entregue.
Para deixar tudo bem mais claro, Pressman nos mostra uma figura que indicam
que vrios incrementos so produzidos ao mesmo tempo. Nosso modelo incremental
mistura fluxos de processos lineares e paralelos:
Pgina 31 de 62

Aula 00
Vitor Almeida
Um detalhe interessante de se falar j aqui que o modelo incremental de

desenvolvimento uma das bases para o desenvolvimento gil de software, o qual
estudaremos em breve em uma prxima aula.
Sommerville nos apresenta 03 vantagens do desenvolvimento incremental em
relao ao modelo em cascata:
1. O custo para acomodar mudanas menor, pois a quantidade de anlise e de
documentao a ser feita minimizada.
2. O feedback de usurios mais qualificado quando entram em contato
diretamente com o software do que quando analisam documentos e modelos
da engenharia de software.
3. possvel a entrega de software funcionando ao cliente mais rapidamente,
ainda que o software no possua todas as funcionalidades previstas
inicialmente.
Sommerville tambm nos diz o grande problema do modelo incremental: a
dificuldade de grandes empresas as quais possuem entraves burocrticos que no se
encaixam em um processo mais gil de desenvolvimento.
O modelo incremental tambm sofre no que concerne produo de
documentao, tendo em vista que vrios incrementos podem estar em
desenvolvimento em um instante de tempo. Alm disso, a tendncia ao longo do
tempo com a entrega de vrios incrementos a degradao da estrutura do sistema,
Pgina 32 de 62

Aula 00
Vitor Almeida
dificultando a incluso de novas mudanas sem um custo considervel de refatorao

do sistema.
O Modelo Iterativo muitas vezes confundido com o modelo incremental. Um
processo de desenvolvimento de software incremental quando a cada rodada
desenvolvido um pedao inteiro do software. J no iterativo, a cada iterao, se avana
no conhecimento do projeto, novos requisitos so elicitados e a arquitetura do software
revisada. No modelo incremental necessariamente teremos entrega de software ao

trmino de uma iterao, o que no verdade para o modelo iterativo.
A figura a seguir esclarece qualquer dvida que tenha persistido.
Ento, se o Leonardo da Vinci tivesse desenhado um pedao do quadro da

Monalisa de cada vez, ele teria realizado um desenvolvimento incremental. Mas, na
verdade, ele comeou desenhando um esboo, depois preencheu as reas com tinta e
depois pintou os detalhes, ou seja, ele desenvolveu iterativamente o quadro da
Monalisa. Ele foi conhecendo e especificando os requisitos da Monalisa cada vez
mais a cada iterao.
O detalhe que os modelos iterativo e incremental no so excludentes. O RUP,
por exemplo, um processo de desenvolvimento de software iterativo e incremental.
Alis, hoje em dia difcil de se ver o Modelo Iterativo ser implementado sozinho por
a. Pressman, em sua edio atual se limita a dizer que os modelos evolucionrios so
Pgina 33 de 62

Aula 00
Vitor Almeida
iterativos por natureza... O que j abre espao para estudarmos os modelos

evolucionrios em nossa aula. Mas, antes, vamos ver algumas questes da FCC:
Questo 14 Prova: FCC - 2009 - TJ-PI - Analista Judicirio - Anlise de Sistemas Desenvolvimento
Em se tratando de processo de desenvolvimento de software, um modelo que
utiliza o feedback mais do que o planejamento como seus mecanismos de controle
primrio para produzir testes regulares e as verses do software desenvolvido.
Assim, o seu desenvolvimento prescreve a construo de uma poro pequena, mas
abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir
cedo os problemas ou suposies, falhas que possam levar ao desastre. Trata-se do
modelo de processo
a) DSDM.
b) gil.
c) em cascata.
d) formal.
e) iterativo.
Comentrios: Associe o modelo iterativo ideia de se privilegiar o feedback do usurio
para se definir as prximas iteraes de desenvolvimento.
Esta a grande lio desta questo que, por sua subjetividade, gera um certo
desconforto nos concurseiros, haja vista que as metodologias geis tambm se
preocupam com o feedback dos usurios e em entregar uma poro inicial do software
para tentar minimizar riscos.
Ou seja, temos muitos modelos de processos geis que so iterativos, o que
deixa a questo muito confusa! Vamos pular essa !
Gabarito: E
Considere:
I. Modificaes devem ser ajustadas facilmente em mdulos isolados e fceis de
encontrar. Se no atendem a isso, um reprojeto dever ser necessrio.
Pgina 34 de 62

Aula 00
Vitor Almeida
II. Modificaes de tabelas devem ser especialmente fceis de fazer. Se qualquer

modificao no rpida e fcil de ser feita, indica-se a realizao de um reprojeto.
III. Modificaes devem ser fceis para serem feitas na forma de iteraes. Se elas
no so, haver um problema bsico tal como um projeto falho ou uma proliferao
de correes.
No contexto das bases para direcionar a implementao e anlise do processo
iterativo e incremental, est correto o que se afirma em
a) I e III, apenas.
b) III, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
Comentrios: Como vimos, podemos ter um processo iterativo e incremental, o que
implica em um desenvolvimento iterativo (a cada iterao, os requisitos do software
so cada vez melhor compreendidos) e incremental (teremos entrega de software
funcionando periodicamente, com as atividades muitas vezes acontecendo
paralelamente).
Para resolver a questo, vamos de wikipedia:
"Linhas bsicas para direcionar a implementao e anlise [no desenvolvimento
iterativo e incremental] incluem:
1. Qualquer dificuldade no projeto, codificao e teste de uma modificao deve ser
sinalizada para que possa ser re-projetada ou recodificada.
2. Modificaes devem ser ajustadas facilmente em mdulos isolados e fceis de
encontrar. Se no atendem a isso, algum re-projeto dever ser necessrio.
3. Modificaes de tabelas devem ser especialmente fceis de fazer. Se qualquer
modificao no rpida e fcil de ser feita, indica-se a realizao de um re-projeto.
4. Modificaes devem ser fceis para serem feitas na forma de iteraes. Se elas no
so, haver um problema bsico tal como um projeto falho ou uma proliferao de
correes.
Pgina 35 de 62

Aula 00
Vitor Almeida
5. Correes devem normalmente ser permitidas por somente uma ou duas iteraes.
Correes devem ser necessariamente para evitar re-projeto durante uma fase de
implementao.
6. A implementao existente deve ser analisada frequentemente para determinar
quo bem esto sendo atingidos os objetivos do projeto.
7. As ferramentas de anlise de programa devem ser usadas sempre que necessrio
para ajudar na anlise de implementaes parciais.
8. Reclamaes do usurio devem ser solicitadas e analisadas para registrar as
deficincias da implementao atual."
Um detalhe... isso a voc no vai achar em livro nenhum. apenas uma
traduo mal feita, muitas vezes de difcil compreenso, do verbete original em
ingls da wikipedia.
Gabarito: E
8. Modelos Evolucionrios
Vamos iniciar com Pressman:
Modelo Evolucionrio Produz uma verso cada vez mais completa do software a
cada iterao.
Ou seja, os modelos evolucionrios so iterativos por natureza, tendo como
Plus a ideia de que estes modelos foram projetados especificamente para desenvolver
um produto que evolua ao longo do tempo.
Complementando, saibam que o modelo de desenvolvimento evolucionrio
intercala as atividades de especificao, desenvolvimento e validao. Um sistema
inicial desenvolvido rapidamente baseado em especificaes abstratas. Este sistema
, ento, refinado com as entradas do usurio para produzir um sistema que satisfaa
suas necessidades.
Esta abordagem mais eficaz do que a abordagem em cascata na produo de
sistemas que atendam s necessidades imediatas dos usurios. A vantagem de um
processo de software baseado na abordagem evolucionria que a especificao pode
Pgina 36 de 62

Aula 00
Vitor Almeida
ser desenvolvida de forma incremental. medida que os usurios compreendem

melhor seu problema, esse conhecimento repassado para o desenvolvimento do
software.
Pressman nos apresenta os dois modelos mais famosos: a prototipao e o
modelo espiral.
O paradigma da Prototipao ideal para quando o cliente tem uma ideia geral
do software, mas no tem uma noo precisa dos requisitos. Prottipos tambm
ajudam para verificar se um algoritmo eficiente computacionalmente, se uma
interface est intuitiva, se o software est adequado a determinado sistema
operacional etc.
Pressman declara que a prototipao pode ser utilizada como um modelo de
processo de software por si s. Mas, o mais comum ser utilizada como uma
ferramenta dentro de um outro modelo de processo de software, dentro da etapa de
levantamento de requisitos.
Enquanto processo, Pressman representa graficamente a prototipao da
seguinte forma:
Onde cada uma das atividades apresentada a seguir:

1. Comunicao: Reunies com as partes interessadas para definio dos objetos do
projeto e levantamento dos requisitos j conhecidos.
Pgina 37 de 62

Aula 00
Vitor Almeida
2. Plano Rpido: Planejamento do prottipo.

3. Modelagem e Projeto Rpido: Modelagem e projeto do prottipo.
4. Construo de um Prottipo: Codificao do prottipo.
5. Emprego, Entrega e Retroalimentao: Entrega do prottipo para anlise do
cliente.
Novas iteraes ocorrem, com construo e melhoria do prottipo, at que
todos os objetivos so alcanados. A partir da, duas estratgias so possveis: descarte
do prottipo e construo do sistema do zero ou evoluo do prottipo at que ele resulte
no software a ser entregue.
A bibliografia apresenta dois modelos de processo de software que recebem a

alcunha de "prototipao":
Prototipao Evolucionria: Uma abordagem para o desenvolvimento do sistema
onde um prottipo inicial produzido e refinado atravs de vrios estgios at ser
considerado o sistema final.
Prototipao Descartvel: Um prottipo, o qual usualmente uma implementao
prtica do sistema, produzida para ajudar a levantar os problemas com os requisitos
e depois descartado. O sistema ento desenvolvido usando algum outro processo de
desenvolvimento. Veja que, em ltima instncia, a prototipao descartvel no um
processo em si mesma.
O objetivo da prototipao evolucionria fornecer aos usurios finais um
sistema funcionando. O desenvolvimento comea com aqueles requisitos que so
melhores compreendidos.
J a prototipao descartvel tenciona validar ou derivar os requisitos do
sistema. O processo de prototipao comea com aqueles requisitos que no so bem
compreendidos.
A prototipao evolucionria acelera a entrega do produto final e aumenta a
participao e engajamento do usurio no desenvolvimento. No entanto, mudanas
rpidas e falta de documentao levam a problemas de manuteno, gerenciamento
e fechamento de contrato com o cliente.
Pgina 38 de 62

Aula 00
Vitor Almeida
O modelo em espiral tem como principais caractersticas uma abordagem cclica

para alcanar progressivas melhorias na definio dos requisitos do sistema e a
implementao do sistema com diminuio ao longo do tempo dos riscos agregados.
Assim, nas primeiras iteraes o software consiste de um prottipo, que pode
ser descartado, enquanto que nas ltimas iteraes, o software apresenta-se em uma
verso completa, mais prxima da verso final.
O modelo em espiral apresenta duas caractersticas principais: a abordagem
cclica voltada para ampliar incrementalmente o grau de definio do sistema,
enquanto reduz os riscos, e uma srie de pontos de controle para assegurar o
comprometimento dos interessados.
Pressman apresenta a seguinte figura para representar o modelo, utilizando as
atividades previstas no seu modelo de processo de software genrico.
Porm, a verso original proposta por Boehm em 1988 a seguinte:
Pgina 39 de 62

Aula 00
Vitor Almeida
Assim, a ideia original do modelo em espiral que em cada iterao (cada loop
da espiral representa uma fase do processo de software) devem ocorrer as seguintes
atividades:
1. Determinao dos objetivos.
2. Avaliao e reduo de riscos.
3. Desenvolvimento e validao.
4. Planejamento da prxima iterao.
Boehm descreve o modelo em espiral como um gerador de modelos de
processos dirigidos a riscos e utilizado para guiar a engenharia de sistemas intensivos
de software.
Uma coisa importantssima e que voc no pode ir para a prova sem ela a
associao entre o modelo em espiral e a avaliao e a reduo de riscos. 100% das
questes que cobram o modelo em espiral citam a preocupao explcita com os riscos
como um dos grandes diferenciais desse modelo.
Vamos praticar:
Pgina 40 de 62

Aula 00
Vitor Almeida
Questo 16 Prova: FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas

No desenvolvimento de software, podem ser utilizados os chamados modelos
evolucionrios, cujo objetivo lidar com produtos que possam evoluir ao longo do
tempo. Assinale a alternativa que contm APENAS modelos evolucionrios de
a) UML e de qualidade.
b) Componentes e arqutipo.
c) Prototipagem e espiral.
d) Redes de Petri e certificao.
e) Semntico e validao.
Comentrios: Questo tranquila retirada de Pressman. Para esse autor, os dois
principais modelos evolucionrios so a prototipagem e o modelo em espiral.
Gabarito: C
Questo 17 Prova: FCC - 2011 - TRT - 1 REGIO (RJ) - Analista Judicirio - Tecnologia
da Informao
embasado na ideia de desenvolvimento de uma implementao inicial, expondo o
resultado aos comentrios do usurio e refinando esse resultado por meio de
diversas verses, at que seja desenvolvido um sistema adequado. No mbito do
processo de software, trata-se de
a) desenvolvimento evolucionrio.
b) modelo em cascata.
c) engenharia de software baseada em componentes.
d) desenvolvimento em espiral.
e) programao estruturada.
Comentrios: Aqui ainda bem que o examinador nos d um texto de Pressman sobre
o desenvolvimento evolucionrio. S que ele se esqueceu de que o desenvolvimento
em espiral (ou modelo em espiral) evolucionrio tambm.
Fica aqui uma dica clssica para a FCC: escolha a mais certa! Nosso gabarito
a alternativa A.
Gabarito: A
Pgina 41 de 62

Aula 00
Vitor Almeida
Questo 18 Prova: FCC - 2010 - MPE-RN - Analista de Tecnologia da Informao Engenharia de Software
O modelo em espiral difere principalmente dos outros modelos de processo de
software por
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.
d) possuir uma fase nica evolucionria.
e) no contemplar o projeto do produto.
Comentrios: A principal caracterstica do modelo em espiral a abordagem voltada
para o risco, da o gabarito.
Gabarito: B
Questo 19 Prova: FCC - 2012 - TRE-CE - Analista Judicirio - Anlise de Sistemas
No desenvolvimento de software em espiral (Boehm), cada loop est dividido em
quatro setores. NO se trata da denominao de um destes setores:
a) levantamento.
b) definio de objetivos.
c) avaliao e reduo de riscos
d) desenvolvimento e validao.
e) planejamento.
Comentrios: A espiral de Boehm tem 04 setores:
Gabarito: A
Questo 20 Prova: FCC - 2010 - TRT - 20 REGIO (SE) - Analista Judicirio - Tecnologia
da Informao
medida que se avana pelo modelo ocorre uma iterao e o software evolui para
estgios superiores, normalmente com aumento da complexidade. Cada iterao
Pgina 42 de 62

Aula 00
Vitor Almeida
est provida das atividades determinadas pelos quadrantes planejamento, avaliao

de alternativas e riscos, desenvolvimento do software e avaliao do cliente. No ciclo
de vida de desenvolvimento de software, trata-se da propriedade do modelo
a) Cascata.
b) Incremental.
c) Espiral.
d) Prototipao.
e) Balbrdia.
Comentrios: Modelo evolucionrio e que avalia os riscos = modelo em espiral.
Gabarito: C
Questo 21 Prova: FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas
O Ciclo de Vida de um Sistema especifica todas as fases de desenvolvimento, desde
sua concepo at o processo de manuteno e declnio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui caracterstica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prvio, realiza a execuo da fase, verifica o progresso
e os resultados da fase (riscos, lies aprendidas) e incrementa novos objetivos para
a fase seguinte, seguindo para a prxima iterao. O processo de software em
questo o
a) modelo espiral.
b) ciclo de vida em cascata.
c) modelo de desenvolvimento evolucionrio (prototipao).
d) modelo de desenvolvimento gil.
e) mtodo de desenvolvimento Cleanroom (Sala Limpa).
Comentrios: Riscos = espiral.
Gabarito: A
Questo 22 Prova: FCC - 2012 - MPE-PE - Tcnico Ministerial - Informtica
O processo de desenvolvimento de software conhecido como modelo em espiral
(Modelo espiral de Boehm), divide cada volta da espiral em quatro setores, sendo
um destes setores denominado de:
Pgina 43 de 62

Aula 00
Vitor Almeida
a) gerenciamento de configurao e mudana.

b) setor administrativo.
c) definio de objetivos.
d) refatorao.
e) estudos de caso.
Comentrios: Quais so os setores mesmo?
S tenha cuidado com as variaes de traduo, por isso que sempre trago as
figuras originais em ingls.
Gabarito: C
Questo 23 Prova: FCC - 2010 - BAHIAGS - Analista de Processos Organizacionais Anlise de Sistemas
No modelo em espiral do processo de software cada loop na espiral representa
a) uma disciplina de requisitos.
b) um enfoque de banco de dados.
c) uma tomada de deciso.
d) uma fase do processo.
e) um ciclo de programa.
Comentrios: Cada ciclo uma fase do processo, n pessoal? As demais opes so
absurdas.
Gabarito: D
No modelo de desenvolvimento de software em espiral, cada loop na espiral
representa
a) a necessidade de retornar ao incio da fase em que se encontra.
b) um processo de reengenharia.
Pgina 44 de 62

Aula 00
Vitor Almeida
c) uma disciplina de software.

d) uma fase do processo de software.
e) uma atividade paralela.
Comentrios: Acho que j vi uma questo desta em algum lugar... :)
Gabarito: D
QUESTO 25 Prova: FCC - 2014 - SABESP Analista de Gesto 01 (Sistemas)
Dentre os modelos de processo utilizados na engenharia de software, a Prototipao
Evolucionria
(A) indicada em situaes em que a equipe de desenvolvimento e o cliente
conhecem bem os requisitos do sistema e j se tem uma previso de que esses
requisitos pouco mudaro no decorrer do processo de desenvolvimento.
(B) utiliza uma abordagem sequencial e sistemtica (no iterativa) para o
desenvolvimento do prottipo, comeando com o levantamento de requisitos,
avanando para as fases de planejamento, modelagem, construo e implantao,
at se obter um software funcional.
(C) muito boa em relao previso de tempo para o desenvolvimento e em
relao gerncia do projeto, j que permite avaliar facilmente quando cada fase foi
realizada.
(D) pode ser interessante quando est sendo difcil fazer o cliente comunicar os
requisitos, pois o analista pode usar o prottipo como ferramenta para se comunicar
com o cliente e chegar a um acordo sobre o que deve ser desenvolvido.
(E) descarta intencionalmente todo o cdigo gerado assim que o objetivo do
prottipo for alcanado, da mesma forma como ocorre nos demais modelos de
processo iterativos.
Comentrios: vamos analisar cada alternativa:
(A) indicada em situaes em que a equipe de desenvolvimento e o cliente
conhecem bem os requisitos do sistema e j se tem uma previso de que esses
requisitos pouco mudaro no decorrer do processo de desenvolvimento. Pelo
contrrio, a prototipao evolutiva utilizada quando os requisitos no so
Pgina 45 de 62

Aula 00
Vitor Almeida
conhecidos ou quando estes apresentam grandes chances de mudar ao longo do

processo de desenvolvimento.
desenvolvimento do prottipo, comeando com o levantamento de requisitos,
avanando para as fases de planejamento, modelagem, construo e implantao,
at se obter um software funcional. Isso modelo em cascata!
(C) muito boa em relao previso de tempo para o desenvolvimento e em
relao gerncia do projeto, j que permite avaliar facilmente quando cada fase foi
realizada. Nada disso... esta dificuldade em se estimar tempo (e esforo) gera um dos
problemas da prototipao evolucionria que a elaborao e assinatura de um
contrato com o cliente.
requisitos, pois o analista pode usar o prottipo como ferramenta para se comunicar
com o cliente e chegar a um acordo sobre o que deve ser desenvolvido. Perfeito!
Gabarito tranquilo!
(E) descarta intencionalmente todo o cdigo gerado assim que o objetivo do
prottipo for alcanado, da mesma forma como ocorre nos demais modelos de
processo iterativos. Na prototipao evolucionria, o prottipo evolui para o sistema
final. Parte do cdigo gerado durante a criao do prottipo pode at ser mudado,
mas boa parte aproveitada.
Gabarito: D
Questo 26 Prova: FCC - 2012 - TJ-RJ - Analista Judicirio - Anlise de Sistemas
Dos diferentes modelos para o ciclo de vida de desenvolvimento de um software
correto afirmar que
a) o modelo em espiral o mais simples e o mais antigo.
b) o modelo em cascata o menos flexvel e mais simples.
c) a fase de especificao de requisitos pode estar ausente do modelo.
d) a fase de implementao sempre a ltima do modelo.
e) o modelo em cascata o mais recente e complexo.
Comentrios: Vamos analisar cada alternativa separadamente:
Pgina 46 de 62

Aula 00
Vitor Almeida
a) o modelo em espiral o mais simples e o mais antigo. O modelo mais antigo e

simples o cascata.
b) o modelo em cascata o menos flexvel e mais simples. Alternativa correta. No
cascata, uma atividade sucede a outra! Simples assim.
c) a fase de especificao de requisitos pode estar ausente do modelo. Como voc
vai construir um software sem saber o que o usurio do sistema quer?
d) a fase de implementao sempre a ltima do modelo. A ltima fase a evoluo.
Antes ainda temos os testes e a implantao para s ento chegarmos na codificao
do sistema.
e) o modelo em cascata o mais recente e complexo. no, o mais antigo e
simples!
Gabarito: B
Informao
Em relao ao ciclo de vida e desenvolvimento de um software-produto, considere:
I. Cascata
a. Ajuda a aumentar a qualidade pelo

planejamento e anlise dos riscos em
cada fase.
II. Espiral
b. Caso a reviso aponte que o projeto

est apto a entrar na fase seguinte, ele
permanece na fase corrente at que ele
seja aprovado.
III. Iterativo incremental
c. Eficiente no desenvolvimento de
projetos nos quais vrios sistemas
similares foram construdos
anteriormente.
IV. Prototipao Evolutiva
d. Apropriado para sistemas nos quais

os requisitos mudam rapidamente e
quando o cliente tem pressa na entrega
de um conjunto de requisitos.
Pgina 47 de 62

Aula 00
Vitor Almeida
Associam-se corretamente as colunas de Modelo e Caracterstica em:

a) I-a; II-b; III-c; IV-d; IV-e.
b) I-a; II-b; II-c; IV-d; III-e.
c) II-a; I-b; I-c; IV-d; III-e.
d) III-a; IV-b; IV-c; II-d; I-e.
e) IV-a; III-b; I-c; II-d; III-e.
Comentrios: A primeira coisa a procurar a relao espiral/risco que encontramos
facilmente, ento o Modelo em Espiral corresponde caracterstica a (II-A). Observer
que nossa FCC entregou a questo, pois a nica alternativa que atende a esta
associao a c).
Agora ficou fcil: I-b - uma caracterstica do modelo em cascata que cada
etapa ocorre no seu tempo. No temos paralelismo. Desta forma, ainda que j seja
possvel passar para uma prxima etapa, isto s ocorrer aps o trmino da etapa
atual.
I-c - isto mesmo, se vrios projetos similares j aconteceram, isto significa
que os requisitos j so conhecidos e esto estabilizados. Podemos ento utilizar o
modelo em cascata.
IV-d. Perfeito, com o uso de prottipos, os requisitos vo sendo descobertos e
validados na medida em que o projeto avana, assim as mudanas nos requisitos so
descobertas com mais facilidade.
III-e No se assuste, no existe caracterstica e... a FCC se esqueceu de colocar
e pra nossa surpresa a questo no foi anulada. Se no pode com a banca, junte-se a
ela :)
Gabarito: C
Sistemas
H diversos mtodos que podem ser utilizados na construo de sistemas de
informao. Sobre eles, analise:
I. O desenvolvimento feito em estgios formais, que devem evoluir em sequncia
e ter resultados definidos. Cada um precisa ser formalmente aprovado antes que o
Pgina 48 de 62

Aula 00
Vitor Almeida
prximo se inicie. indicado para grandes projetos que exijam especificaes

formais e rgido controle administrativo sobre cada estgio do desenvolvimento.
II. Consiste em desenvolver um sistema experimental de maneira rpida e barata
para que os usurios finais interajam com ele e o avaliem. Esse sistema refinado e
aperfeioado at que os usurios sintam que ele atende s suas necessidades,
podendo ser usado como modelo para criar o sistema final.
Os itens I e II referem-se, respectivamente,
(A) ao Ciclo de Vida de Sistema Tradicional e Prototipagem.
(B) ao Modelo Espiral e ao Modelo em Cascata.
(C) ao Modelo V e ao Modelo de Entrega por Estgios.
(D) aos Modelos Prescritivos e aos Modelos geis.
(E) ao Modelo Orientado a Cronograma e ao Modelo Orientado a Teste.
Comentrios: A primeira afirmativa fala em processo sequencial, necessidade de
finalizao e aprovao da etapa anterior antes de se iniciar a prxima e especificaes
formais (ou seja, requisitos estveis). Estamos falando do modelo em cascata, tambm
conhecido como ciclo de vida de sistema tradicional.
A segunda fala em um sistema experimental elaborado rapidamente e com
baixo custo. Temos aqui um prottipo. Ele pode ser usado como modelo para o
sistema final. Se h aproveitamento de cdigo neste processo temos a prototipagem
evolutiva. Caso o prottipo seja completamente descartado temos a prototipao
descartvel.
Gabarito: A
9. Lista de Questes Utilizadas na Aula.

Questo 01 Prova: FCC - 2010 - DPE-SP - Agente de Defensoria - Programador
unicamente com as prticas de desenvolvimento de software.
software.
Pgina 49 de 62

Aula 00
Vitor Almeida

desenvolvimento.
IV. segue princpios, tais como, o da Abstrao, que identifica os aspectos importantes
sem ignorar os detalhes e o da Composio, que agrupa as atividades em um nico
processo para distribuio aos especialistas.
correto o que se afirma em
a) III e IV, apenas.
b) I, II, III e IV.
c) I e II, apenas.
d) I, II e III, apenas.
e) II, III e IV, apenas.
Informao
software, pois baseia-se exclusivamente nos modelos de software, notaes, regras e
tcnicas de desenvolvimento.
software.
problema a ser abordado, considerando restries e recursos disponveis.
e) segue princpios, tais como, o da Abstrao, que identifica os aspectos importantes
Pgina 50 de 62

Aula 00
Vitor Almeida
Questo 03 Prova: FCC - 2008 - METR-SP - Analista Treinee - Cincias da

Computao
O objetivo da Engenharia de Software estabelecer uma sistemtica abordagem de
problema a ser abordado, considerando restries e recursos disponveis. A
Engenharia de Software
I. no se confunde com a Cincia da Computao, pois enquanto esta visa o
desenvolvimento de teorias e fundamentaes, a Engenharia de Software se preocupa
com as prticas de desenvolvimento de software.
II. tem como foco nico o tratamento dos aspectos de desenvolvimento de software,
o que a diferencia da Engenharia de Sistemas, que trata dos sistemas baseados em
desenvolvimento.
IV. segue princpios, tais como, o da Abstrao, que identifica os aspectos importantes
correto o que consta em
a) I e II, apenas.
b) III e IV, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, II, III e IV.
Questo 04 Prova: FCC - 2012 - TRT - 6 Regio (PE) - Tcnico Judicirio - Tecnologia
da Informao
Considere: uma disciplina que se ocupa de todos os aspectos da produo de
software, desde os estgios iniciais de especificao do sistema at a manuteno
desse sistema, depois que ele entrou em operao. Seu principal objetivo fornecer
uma estrutura metodolgica para a construo de software com alta qualidade. A
definio refere-se
Pgina 51 de 62

Aula 00
Vitor Almeida
a) ao ciclo de vida do software.

b) programao orientada a objetos.
c) anlise de sistemas.
d) engenharia de requisitos.
e) engenharia de software.
Questo 05 Prova: FCC - 2013 - PGE-CE - Analista Ministerial rea Cincias da
Computao
Engenharia de Software a aplicao de abordagens sistemticas, disciplinadas e
quantificveis ao desenvolvimento, operao e manuteno de software, alm do
estudo dessas abordagens. Com relao Engenharia de Software, correto afirmar
que
(A) o trabalho termina assim que o software colocado em operao.
(B) ferramentas e computadores de boa qualidade so condiesnecessrias e
suficientes para que uma empresa produza softwarede qualidade.
(C) todo bom gerente (competente) pode gerenciar qualquer projeto de softwaree
obter um produto de qualidade.
(D) se um projeto estiver atrasado, adicionar mais pessoas pode causar mais atrasos.
(E) os requisitos mudam com frequncia, mas sempre possvel acomod-los, pois o
software flexvel.
QUESTO 06 CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da
Informao - Arquitetura de Tecnologia
Os princpios de engenharia de software definem a necessidade de formalidades para
reduzir inconsistncias e a decomposio para lidar com a complexidade.
Questo 07 Prova: FCC - 2012 - MPE-AP - Analista Ministerial - Tecnologia da
Informao
Um processo de software um conjunto de atividades relacionadas que levam
produo de um produto de software. Existem muitos processos de software
diferentes, mas todos devem incluir quatro atividades fundamentais: especificao,
projeto e implementao, validao e
a) teste
Pgina 52 de 62

Aula 00
Vitor Almeida
b) evoluo.
c) prototipao.
d) entrega.
e) modelagem.
No processo de desenvolvimento de software, a atividade que refere-se garantia
de que o sistema de software ir ao encontro de requisitos do produto, como tambm
assegurar que futuros requisitos possam ser atendidos:
a) Especificao.
b) Arquitetura de Software.
c) Anlise de Requisitos.
d) Implementao.
e) Suporte e Treinamento.
Questo 09 Prova: FCC - 2011 - INFRAERO - Analista de Sistemas - Desenvolvimento
e Manuteno
A principal metodologia tradicional utilizada no desenvolvimento de software o
modelo clssico tambm conhecido como cascata ou sequencial. Nesse modelo,
aprovada para que a etapa posterior possa ter incio.
b) o projeto dividido em fases de maneira flexvel.
progride.
d) utiliza-se o desenvolvimento incremental e iterativo.
e) os requisitos no podem ser estveis.
Questo 10 Prova: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da
Informao - Prova 3
O processo de engenharia de software denominado ciclo de vida clssico refere-se ao
modelo
a) em cascata.
b) incremental.
Pgina 53 de 62

Aula 00
Vitor Almeida
c) evolucionrio.
d) prototipagem.
e) de processo unificado.
Questo 11 Prova: FCC - 2012 - MPE-PE - Analista Ministerial - Informtica
Dentre os principais estgios do modelo de desenvolvimento em cascata est o
Projeto de sistema e software, que
a) a fase mais longa do ciclo de vida do sistema. O sistema instalado e colocado
em uso e efetuada a correo de erros que no foram descobertos em estgios
iniciais.
b) estabelece os servios, restries e metas do sistema por meio de consulta aos
usurios, e em seguida define em detalhes estes itens para serem utilizados como uma
especificao do sistema.
c) integra as unidades do programa ou programas como um sistema completo e
efetuam testes para garantir que os requisitos do software tenham sido atendidos.
d) aloca os requisitos tanto para sistemas de hardware como para sistemas de
software, por meio de uma arquitetura geral do sistema.
e) desenvolve o projeto de software como um conjunto de programas ou unidades de
programas para posteriormente serem aplicados os testes unitrios.
Sistemas
O primeiro modelo de desenvolvimento de softwarea ser publicado foi derivado de
processos mais gerais da engenharia de sistemas. Por causa do encadeamento entre
uma fase e outra, esse modelo conhecido como modelo em cascata ou ciclo de vida
de software. Dentre seus principais estgios se encontram a anlise e definio de
requisitos, o projeto de sistema e software e
(A) anlise de recursos e software.
(B) desenvolvimento incremental.
(C) gerao de relatrios de teste.
(D) pesquisa e testes.
(E) implementao e teste unitrio.
Pgina 54 de 62

Aula 00
Vitor Almeida
QUESTO 13 Prova: FCC - 2013 - MPE-MA - Analista Ministerial Anlise e

Desenvolvimento de Sistemas
Um processo de desenvolvimento de softwareem geral tem como entrada os
requisitos do sistema e como sada um produto fornecido. Analise as afirmativas sobre
este tema.
requisitos, projeto do sistema, codificao, testes e entrega do sistema. Assim, o ciclo
de vida do software descreve a vida do produto de software desde sua concepo at
a implementao e entrega.
abandonando-se o prottipo.
Est correto o que se afirma em
(A) I e II, apenas.
(B) II e III, apenas.
(C) II, apenas.
(D) I e III, apenas.
(E) I, II e III.
Questo 14 Prova: FCC - 2009 - TJ-PI - Analista Judicirio - Anlise de Sistemas Desenvolvimento
Em se tratando de processo de desenvolvimento de software, um modelo que utiliza
o feedback mais do que o planejamento como seus mecanismos de controle primrio
para produzir testes regulares e as verses do software desenvolvido. Assim, o seu
desenvolvimento prescreve a construo de uma poro pequena, mas abrangente,
do projeto de software para ajudar a todos os envolvidos a descobrir cedo os
Pgina 55 de 62

Aula 00
Vitor Almeida
problemas ou suposies, falhas que possam levar ao desastre. Trata-se do modelo de

processo
a) DSDM.
b) gil.
c) em cascata.
d) formal.
e) iterativo.
Considere:
I. Modificaes devem ser ajustadas facilmente em mdulos isolados e fceis de
encontrar. Se no atendem a isso, um reprojeto dever ser necessrio.
II. Modificaes de tabelas devem ser especialmente fceis de fazer. Se qualquer
modificao no rpida e fcil de ser feita, indica-se a realizao de um reprojeto.
III. Modificaes devem ser fceis para serem feitas na forma de iteraes. Se elas no
so, haver um problema bsico tal como um projeto falho ou uma proliferao de
correes.
No contexto das bases para direcionar a implementao e anlise do processo iterativo
e incremental, est correto o que se afirma em
a) I e III, apenas.
b) III, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
Questo 16 Prova: FCC - 2013 - DPE-SP - Agente de Defensoria - Analista de Sistemas
No desenvolvimento de software, podem ser utilizados os chamados modelos
evolucionrios, cujo objetivo lidar com produtos que possam evoluir ao longo do
tempo. Assinale a alternativa que contm APENAS modelos evolucionrios de
a) UML e de qualidade.
b) Componentes e arqutipo.
Pgina 56 de 62

Aula 00
Vitor Almeida
c) Prototipagem e espiral.
d) Redes de Petri e certificao.
e) Semntico e validao.
Questo 17 Prova: FCC - 2011 - TRT - 1 REGIO (RJ) - Analista Judicirio - Tecnologia
da Informao
embasado na idia de desenvolvimento de uma implementao inicial, expondo o
resultado aos comentrios do usurio e refinando esse resultado por meio de diversas
verses, at que seja desenvolvido um sistema adequado. No mbito do processo de
software, trata-se de
a) desenvolvimento evolucionrio.
b) modelo em cascata.
c) engenharia de software baseada em componentes.
d) desenvolvimento em espiral.
e) programao estruturada.
O modelo em espiral difere principalmente dos outros modelos de processo de
software por
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.
d) possuir uma fase nica evolucionria.
e) no contemplar o projeto do produto.
Questo 19 Prova: FCC - 2012 - TRE-CE - Analista Judicirio - Anlise de Sistemas
No desenvolvimento de software em espiral (Boehm), cada loop est dividido em
quatro setores. NO se trata da denominao de um destes setores:
a) levantamento.
b) definio de objetivos.
c) avaliao e reduo de riscos
d) desenvolvimento e validao.
e) planejamento.
Pgina 57 de 62

Aula 00
Vitor Almeida
Questo 20 Prova: FCC - 2010 - TRT - 20 REGIO (SE) - Analista Judicirio - Tecnologia
da Informao
medida que se avana pelo modelo ocorre uma iterao e o software evolui para
estgios superiores, normalmente com aumento da complexidade. Cada iterao est
provida das atividades determinadas pelos quadrantes planejamento, avaliao de
alternativas e riscos, desenvolvimento do software e avaliao do cliente. No ciclo de
vida de desenvolvimento de software, trata-se da propriedade do modelo
a) Cascata.
b) Incremental.
c) Espiral.
d) Prototipao.
e) Balbrdia.
Questo 21 Prova: FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas
O Ciclo de Vida de um Sistema especifica todas as fases de desenvolvimento, desde
sua concepo at o processo de manuteno e declnio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui caracterstica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prvio, realiza a execuo da fase, verifica o progresso e
os resultados da fase (riscos, lies aprendidas) e incrementa novos objetivos para a
fase seguinte, seguindo para a prxima iterao. O processo de software em questo
o
a) modelo espiral.
b) ciclo de vida em cascata.
c) modelo de desenvolvimento evolucionrio (prototipao).
d) modelo de desenvolvimento gil.
e) mtodo de desenvolvimento Cleanroom (Sala Limpa).
Questo 22 Prova: FCC - 2012 - MPE-PE - Tcnico Ministerial - Informtica
O processo de desenvolvimento de software conhecido como modelo em espiral
(Modelo espiral de Boehm), divide cada volta da espiral em quatro setores, sendo um
destes setores denominado de:
a) gerenciamento de configurao e mudana.
Pgina 58 de 62

Aula 00
Vitor Almeida
b) setor administrativo.
c) definio de objetivos.
d) refatorao.
e) estudos de caso.
Questo 23 Prova: FCC - 2010 - BAHIAGS - Analista de Processos Organizacionais Anlise de Sistemas
No modelo em espiral do processo de software cada loop na espiral representa
a) uma disciplina de requisitos.
b) um enfoque de banco de dados.
c) uma tomada de deciso.
d) uma fase do processo.
e) um ciclo de programa.
No modelo de desenvolvimento de software em espiral, cada loop na espiral
representa
a) a necessidade de retornar ao incio da fase em que se encontra.
b) um processo de reengenharia.
c) uma disciplina de software.
d) uma fase do processo de software.
e) uma atividade paralela.
QUESTO 25 Prova: FCC - 2014 - SABESP Analista de Gesto 01 (Sistemas)
Dentre os modelos de processo utilizados na engenharia de software, a Prototipao
Evolucionria
(A) indicada em situaes em que a equipe de desenvolvimento e o cliente conhecem
bem os requisitos do sistema e j se
tem uma previso de que esses requisitos pouco mudaro no decorrer do processo de
desenvolvimento.
desenvolvimento do prottipo, comeando com o
Pgina 59 de 62

Aula 00
Vitor Almeida
levantamento de requisitos, avanando para as fases de planejamento, modelagem,

construo e implantao, at se
obter um softwarefuncional.
(C) muito boa em relao previso de tempo para o desenvolvimento e em relao
gerncia do projeto, j que permite
avaliar facilmente quando cada fase foi realizada.
requisitos, pois o analista pode usar o
prottipo como ferramenta para se comunicar com o cliente e chegar a um acordo
sobre o que deve ser desenvolvido.
(E) descarta intencionalmente todo o cdigo gerado assim que o objetivo do prottipo
for alcanado, da mesma forma como
ocorre nos demais modelos de processo iterativos.
Questo 26 Prova: FCC - 2012 - TJ-RJ - Analista Judicirio - Anlise de Sistemas
Dos diferentes modelos para o ciclo de vida de desenvolvimento de um software
correto afirmar que
a) o modelo em espiral o mais simples e o mais antigo.
b) o modelo em cascata o menos flexvel e mais simples.
c) a fase de especificao de requisitos pode estar ausente do modelo.
d) a fase de implementao sempre a ltima do modelo.
e) o modelo em cascata o mais recente e complexo.
Questo 27 Prova: FCC - 2010 - TRE-AM - Analista Judicirio - Tecnologia da Informao
Em relao ao ciclo de vida e desenvolvimento de um software-produto, considere:
I. Cascata
a. Ajuda a aumentar a qualidade pelo

planejamento e anlise dos riscos em
cada fase.
II. Espiral
b. Caso a reviso aponte que o projeto

est apto a entrar na fase seguinte, ele
permanece na fase corrente at que ele
seja aprovado.
Pgina 60 de 62

Aula 00
Vitor Almeida
III. Iterativo incremental
c. Eficiente no desenvolvimento de
projetos nos quais vrios sistemas
similares foram construdos
anteriormente.
IV. Prototipao Evolutiva
d. Apropriado para sistemas nos quais

os requisitos mudam rapidamente e
quando o cliente tem pressa na entrega
de um conjunto de requisitos.
Associam-se corretamente as colunas de Modelo e Caracterstica em:

a) I-a; II-b; III-c; IV-d; IV-e.
b) I-a; II-b; II-c; IV-d; III-e.
c) II-a; I-b; I-c; IV-d; III-e.
d) III-a; IV-b; IV-c; II-d; I-e.
e) IV-a; III-b; I-c; II-d; III-e.
Sistemas
H diversos mtodos que podem ser utilizados na construo de sistemas de
informao. Sobre eles, analise:
I. O desenvolvimento feito em estgios formais, que devem evoluir em sequncia e
ter resultados definidos. Cada um precisa ser formalmente aprovado antes que o
prximo se inicie. indicado para grandes projetos que exijam especificaes formais
e rgido controle administrativo sobre cada estgio do desenvolvimento.
II. Consiste em desenvolver um sistema experimental de maneira rpida e barata para
que os usurios finais interajam com ele e o avaliem. Esse sistema refinado e
aperfeioado at que os usurios sintam que ele atende s suas necessidades,
podendo ser usado como modelo para criar o sistema final.
Os itens I e IIreferem-se, respectivamente,
(A) ao Ciclo de Vida de Sistema Tradicional e Prototipagem.
(B) ao Modelo Espiral e ao Modelo em Cascata.
(C) ao Modelo V e ao Modelo de Entrega por Estgios.
(D) aos Modelos Prescritivos e aos Modelos geis.
Pgina 61 de 62

Aula 00
Vitor Almeida
(E) ao Modelo Orientado a Cronograma e ao Modelo Orientado a Teste.
10.Gabarito
01 D
11 D
21 A
02 D
12 E
22 C
03 C
13 C
23 D
04 E
14 E
24 D
05 D
15 E
25 D
06 C
16 C
26 B
07 B
17 A
27 C
08 B
18 B
28 A
09 A
19 A
10 A
20 C
Pgina 62 de 62

Idioma

Eng Soft

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Eng Soft

Enviado por

Direitos autorais:

Formatos disponíveis

CNMP - Engenharia de Software

AULA 00 - Modelos de Ciclos de Vida.

Metodologia das aulas.................................................................................................... 2

Contedo programtico e planejamento das aulas (Cronograma). ................................... 3

Conceitos Gerais ................................................................................................................. 4

Ciclo de Vida do Software................................................................................................. 15

Modelo em Cascata .......................................................................................................... 22

Modelo Iterativo e Incremental ....................................................................................... 30

Modelos Evolucionrios ................................................................................................... 36

Lista de Questes Utilizadas na Aula. ............................................................................... 49

CNMP - Engenharia de Software

Espero ajud-los no rduo caminho rumo a aprovao. Qualquer dvida,

engenharia-de-software-cobrada-em-concursos) sobre que assuntos so mais cobrados. O

resultado para a FCC foi o seguinte:

Anlise e Engenharia de Requisitos

Ciclo de Vida / Modelos de Processos

Anlise Estruturada / DFD

Gerncia de Projetos de Software

Metodologia das aulas.

a) Teremos no curso aulas expositivas, descritivas e descontradas com, ao

CNMP - Engenharia de Software

c) Tenham o cuidado de no menosprezar nada que esteja escrito na aula.

2. Contedo programtico e planejamento das aulas (Cronograma).

Contedo a ser trabalhado

CNMP - Engenharia de Software

Software de Computador programas de computador e documentao

Software de Computador o produto que profissionais de software

Engenharia de software abrange um processo, um conjunto de mtodos e

CNMP - Engenharia de Software

1. Manutenibilidade - O software deve evoluir para atender os requisitos que

Engenharia de Software disciplina da engenharia que se preocupa com todos

Engenharia de software aplicao e o estudo de uma abordagem sistemtica,

CNMP - Engenharia de Software

Observe que a base de tudo a qualidade. Ou seja, qualquer abordagem de

CNMP - Engenharia de Software

Veja que o hardware tem um comportamento de se encontrar muitos erros no

CNMP - Engenharia de Software

Mitos relativos ao software crenas infundadas sobre o software e sobre o

MITOS DOS CLIENTES

MITOS DOS PROFISSIONAIS DA

J temos um livro que est cheio

Uma definio geral dos objetivos

Uma vez feito um programa e

de padres e procedimentos para

suficiente para comear a

colocado em uso, nosso trabalho

desenvolver software. Ele no

escrever programas podemos

supre meu pessoal com tudo que

eles precisam saber?

Os requisitos de software mudam

At que o programa entre em

poderemos acrescentar mais

continuamente, mas as mudanas

programadores e ficarmos em dia

podem ser facilmente assimiladas,

de avaliar sua qualidade.

(algumas vezes denominado como

pois o software flexvel.

conceito da horda mongol.

O nico produto passvel de

de software, posso simplesmente