Modelos de Desenvolvimento

•

UEPB

Áurea Cristina Garcia dos Santos

24/06/2024

Prévia do material em texto

Aula 30 (Profs Diego
Carvalho e Fernando
Pedrosa)
Concursos da Área Fiscal - Curso Básico
de Tecnologia da Informação - 2023
Autor:
Fernando Pedrosa Lopes , Thiago
Rodrigues Cavalcanti, Erick
Muzart Fonseca dos Santos,
Paolla Ramos e Silva , Diego
Carvalho, Renato da Costa, Equipe
Informática e TI
29 de Maio de 2023
https://t.me/kakashi_copiador
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Índice
..............................................................................................................................................................................................1) Metodologias de Desenvolvimento - Parte 2 3
..............................................................................................................................................................................................2) Questões Comentadas - Metodologias de Desenvolvimento - Parte 2 - Multibancas 21
..............................................................................................................................................................................................3) Lista de Questões - Metodologias de Desenvolvimento - Parte 2 - Multibancas 33
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
2
41

Galera, essa é a continuação da aula anterior! Dessa vez, nós vamos falar sobre modelos
evolucionários e seus subtipos, e também vamos falar sobre diversos modelos específicos que não
se encaixam em nenhuma das categorias vistas anteriormente. Esses modelos caem menos em
prova do que aqueles que vimos na aula anterior, mas eles também são importantes. Vem
comigo que essa aula é tranquilaaaaaaaaça...

Galera, todos os tópicos da aula possuem Faixas de Incidência, que indicam se o assunto cai
muito ou pouco em prova. Diego, se cai pouco para que colocar em aula? Cair pouco não significa
que não cairá justamente na sua prova! A ideia aqui é: se você está com pouco tempo e precisa ver
somente aquilo que cai mais, você pode filtrar pelas incidências média, alta e altíssima; se você tem
tempo sobrando e quer ver tudo, vejam também as incidências baixas e baixíssimas. Fechado?

Além disso, essas faixas não são por banca – é baseado tanto na quantidade de vezes que caiu em
prova independentemente da banca e também em minhas avaliações sobre cada assunto...
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
3
41
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
4
41

Antes de começarmos, eu acho oportuno dizer que a imensa maioria dos autores consideram o
modelo evolucionário/evolutivo como um tipo de modelo iterativo conforme mostra a imagem
acima! Um dos nossos autores consagrados, Roger Pressman afirma: “os modelos evolucionários
são iterativos, apresentando características que possibilitam desenvolver versões cada vez mais
completas do software”. Agora é hora de ver isso melhor...

Ele também afirma que softwares, assim como outros sistemas complexos, evoluem ao longo do
tempo. Conforme o desenvolvimento do projeto avança, as necessidades de negócio e de produto
mudam, tornando inadequado seguir um planejamento em linha reta de um produto final. Prazos
apertados tornam impossível completar um produto de software abrangente, porém uma versão
limitada tem de ser introduzida para aliviar e/ou atender às pressões comerciais ou da concorrência.

Em determinadas situações, faz-se necessário um modelo de processo que tenha sido projetado
especificamente para desenvolver um produto que evolua ao longo do tempo e os modelos
evolucionários possibilitam desenvolver versões cada vez mais completas de software. Eu já sei que
você está com uma dúvida na ponta da língua: professor, qual é a diferença entre o modelo
incremental e o modelo evolucionário? Pois é...

Na última edição do livro do Ian Sommerville, ele simplesmente desapareceu com o termo modelo
evolucionário e o considerou como sinônimo de modelo incremental – como se não houvesse
nenhuma diferença entre eles! Já Roger Pressman trata ambos quase como idênticos, a não ser por
uma diferença bastante sutil: de acordo com o autor, o modelo incremental sempre apresenta
uma funcionalidade operacional ou um produto de trabalho a cada iteração.

Já o modelo evolucionário, durante as primeiras iterações, pode gerar versões compostas apenas
por modelos em papel, documentação ou produtos não operacionais para o usuário. É possível, por
exemplo, ter uma iteração utilizada só para estudar melhor o produto. Isso é uma funcionalidade
operacional para o cliente? Não! É importante mencionar que muitas questões ignoram essa
diferença e simplesmente tratam o modelo evolucionário como modelo incremental!

Bem, pessoal... as implementações mais famosas do modelo evolucionário são: prototipagem e
espiral! Vamos estudá-las um pouco melhor :)

Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
5
41
Frequentemente, o cliente define uma série de objetivos gerais para o software, mas não identifica
detalhadamente os requisitos para funções e recursos. Em outros casos, o desenvolvedor encontra-
se inseguro quanto à eficiência de um algoritmo, quanto à adaptabilidade de um sistema
operacional ou quanto à forma em que deva ocorrer a interação homem/máquina. Em situações
assim e em muitas outras, o paradigma de prototipação pode ser a melhor abordagem.

Embora a prototipação possa ser utilizada como um modelo de processo isolado (stand-alone
process), ela é mais comumente utilizada como uma técnica passível de ser implementada no
contexto de outros processos. Independentemente da forma como é aplicado, quando os
requisitos estão obscuros, o paradigma da prototipação auxilia os interessados a compreender
melhor o que está para ser construído .

A prototipagem é utilizada quando não se conhecem bem os requisitos. Trata-se de uma forma de
entendê-los melhor para posteriormente desenvolver o software. Ela se configura como um
processo iterativo, interativo e rápido de desenvolvimento e o protótipo serve como um mecanismo
de identificação dos requisitos do software, que servirão para uma futura especificação ou serão
refinados e entregues ao cliente.

Um protótipo é uma versão inicial de um sistema de software utilizado para demonstrar
conceitos, experimentar opções de projeto e, geralmente, conhecer mais sobre o problema e
suas possíveis soluções. O desenvolvimento rápido e iterativo do protótipo é essencial para que os
custos sejam controlados e os stakeholders do sistema possam experimentá-lo no início do
processo de software.

Um protótipo de software pode ser usado em um processo de desenvolvimento de software para
ajudar a antecipar as mudanças que podem ser requisitadas:

a) No processo de engenharia de requisitos, um protótipo pode ajudar na elicitação e validaçãode requisitos do sistema.
b) Processo de projeto do sistema, um protótipo pode ser usado para estudar soluções
específicas de software e apoiar o projeto de interface com o usuário.

Protótipos do sistema permitem aos usuários ver quão bem o sistema dá suporte a seu
trabalho. Eles podem obter novas ideias para requisitos e encontrar pontos fortes e fracos do
software; podem, então, propor novos requisitos do sistema. Além disso, o desenvolvimento do
protótipo pode revelar erros e omissões nos requisitos propostos. A função descrita em uma
especificação pode parecer útil e bem definida.

No entanto, quando essa função é combinada com outras, os usuários muitas vezes percebem que
sua visão inicial foi incorreta ou incompleta. A especificação do sistema pode então ser
modificada para refletir o entendimento dos requisitos alterados. Enquanto o sistema está em
projeto, um protótipo do sistema pode ser usado para a realização de experimentos de projeto
visando à verificação da viabilidade da proposta.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
6
41

Por exemplo: um projeto de banco de dados pode ser prototipado e testado para verificar se suporta
de modo eficiente o acesso aos dados para as consultas mais comuns dos usuários. Prototipação
também é uma parte essencial do processo de projeto da interface de usuário. Devido à natureza
dinâmica de tais interfaces, descrições textuais e diagramas não são bons o suficiente para
expressar seus requisitos.

Dessa forma, a prototipação rápida com envolvimento do usuário final é a única maneira
sensata de desenvolver interfaces gráficas de usuário para sistemas de software. Um modelo de
processo para desenvolvimento de protótipos é apresentado na imagem seguinte. Os objetivos da
prototipação devem ser explicitados desde o início do processo (Ex: prototipar a interface de
usuário, prototipar um sistema para validação dos requisitos funcionais do sistema, etc).

O mesmo protótipo não pode cumprir todos os objetivos. Se os objetivos não são declarados, a
gerência ou os usuários finais podem não entender a função do protótipo. Consequentemente, eles
podem não obter os benefícios que esperavam do desenvolvimento do protótipo. O próximo
estágio do processo é decidir o que colocar e, talvez mais importante ainda, o que deixar de fora do
sistema de protótipo.

Para reduzir os custos de prototipação e acelerar o cronograma de entrega, pode-se deixar alguma
funcionalidade fora do protótipo. Você pode optar por relaxar os requisitos não funcionais, como
tempo de resposta e utilização de memória. Gerenciamento e tratamento de erros podem ser
ignorados, a menos que o objetivo do protótipo seja estabelecer uma interface de usuário. Padrões
de confiabilidade e qualidade de programa podem ser reduzidos.

O estágio final do processo é a avaliação do protótipo. Durante esse estágio, provisões devem ser
feitas para o treinamento do usuário, e os objetivos do protótipo devem ser usados para derivar
um plano de avaliação. Os usuários necessitam de um tempo para se sentir confortáveis com um
sistema novo e para se situarem em um padrão normal de uso. Uma vez que estejam usando o
sistema normalmente, eles descobrem erros e omissões de requisitos.

Já Pressman entende a prototipação conforme apresenta a imagem ao lado: o paradigma de
prototipação começa com a comunicação. Faz-se uma reunião com os envolvidos para definir os
objetivos gerais do software, identificar quais requisitos já são conhecidos e esquematizar quais
áreas necessitam, obrigatoriamente, de uma definição mais ampla. Uma iteração de prototipação
é planejada rapidamente e ocorre a modelagem (na forma de um “projeto rápido”).
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
7
41

Um projeto rápido se concentra em uma representação daqueles aspectos do software que serão
visíveis aos usuários finais (Por exemplo: o layout da interface com o usuário ou os formatos de
exibição na tela). O projeto rápido leva à construção de um protótipo, que é empregado e avaliado
pelos envolvidos, que fornecerão um retorno (também chamado de feedback), que servirá para
aprimorar os requisitos.

A iteração ocorre conforme se ajusta o protótipo às necessidades de
vários interessados e, ao mesmo tempo, possibilita a melhor
compreensão das necessidades que devem ser atendidas. Na sua forma
ideal, o protótipo atua como um mecanismo para identificar os requisitos
do software. Caso seja necessário desenvolver um protótipo operacional,
pode-se utilizar partes de programas existentes ou aplicar ferramentas
que possibilitem gerar rapidamente tais programas operacionais.

O que fazer com o protótipo quando este já serviu ao propósito descrito anteriormente? Na maioria dos
projetos, o primeiro sistema dificilmente é utilizável. Pode estar muito lento, muito grande, muito
estranho em sua utilização ou as três coisas juntas. Não há alternativa, a não ser começar de novo
e desenvolver uma versão redesenhada na qual esses problemas são resolvidos. O protótipo pode
servir, portanto, como “o primeiro sistema” – que pode ser jogado fora!

No entanto, essa pode ser uma visão idealizada. Embora alguns protótipos sejam construídos como
“descartáveis”, outros são evolucionários, no sentido de que evoluem lentamente até se
transformar no sistema real. Tanto os interessados como os engenheiros de software gostam do
paradigma da prototipação. Os usuários podem ter uma ideia prévia do sistema final, ao passo que
os desenvolvedores passam a desenvolver algo imediatamente.

Em outras palavras, protótipos são inviáveis de serem utilizados na maioria dos casos, por ser muito
lento e/ou muito grande e/ou muito difícil de utilizar. Em geral, os protótipos são descartados assim
que os objetivos de levantamento de requisitos são alcançados. No entanto, alguns preferem
refiná-los iterativamente até evoluir ao sistema final requisitado pelo usuário. O que vocês precisam
guardar de tudo isso?

Em suma, o que vocês precisam saber é que o modelo de prototipação/prototipagem se baseia na
ideia de construção de um protótipo que auxiliem a construção do produto de duas maneiras: (1)
ou para levantar os requisitos do sistema junto aos usuários e depois ser efetivamente
descartado; ou (2) para ser refinado, refinado e refinado até chegar ao sistema final desejado
pelos usuários.

O objetivo do processo de desenvolvimento exploratório é trabalhar com o cliente para
explorar os requisitos e entregar um sistema final. O desenvolvimento começa com as
partes do sistema compreendidas. O sistema evolui por meio da adição de novas
características propostas pelo cliente.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
8
41
O objetivo do processo de prototipação throwaway é compreender os requisitos do cliente
e, a partir disso, desenvolver melhor definição de requisitos para o sistema. O protótipo se
concentra na experimentação dos requisitos mal compreendidos do cliente, mas é
posteriormente descartado.

Quando uma questão não especificao tipo de prototipação, geralmente se trata de Prototipação
Throw-away/Descartável e, não, Evolucionária/Exploratória. Ian Sommerville declara: “O uso o
termo prototipação no sentido de processo iterativo de desenvolvimento de um sistema experimental
que não é destinado à disponibilização ao cliente”.

O Modelo em Espiral foi proposto
originalmente, em 1988, por Boehm. Sua
ideia era representar um processo de
software orientado a riscos. Em vez de
representar o processo como uma
sequência de atividades com algum
retorno entre uma atividade e outra, o
processo é representado como uma
espiral. Ele combina atividades de
desenvolvimento com aspectos gerenciais
(Planejamento, Tomada de Decisão,
Análise de Riscos, etc).

O modelo em espiral é também conhecido como prototipagem-em-etapas, por combinar, em
geral, o modelo em cascata com a prototipação. Cada loop representa uma fase do processo de
software. Dessa forma, o loop mais interno pode estar relacionado à viabilidade do sistema; o
próximo loop, à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. Divide-
se em quatro setores:

Definem-se os objetivos da do projeto (aumentar performance, consertar
funcionalidade, melhorar qualidade), identificam-se alternativas (reúso de
componentes, comprar pronto) e identificam-se restrições impostas (custo,
cronograma, entre outros).
Avaliam-se as alternativas identificadas em relação aos objetivos e
restrições. Frequentemente, esse processo identifica áreas de incerteza
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
9
41
(custos excessivos, falta de recursos) e resolve ou reduz os riscos
identificados - um protótipo pode ser construído.
Após a redução dos riscos, um modelo de desenvolvimento para o sistema é
selecionado (Exemplo: prototipação evolucionária, modelos formais,
modelo em cascata, modelos baseados em componentes). O software é
desenvolvido e, posteriormente, testado.
Revisa-se o projeto e decide-se sobre o prosseguimento ao próximo loop da
espiral. Se a decisão for pelo prosseguimento, são elaborados planos para a
próxima fase do projeto, e terminamos um loop.

De acordo com Pressman, cada espiral é dividida em cinco setores1:

É a comunicação em si
Estimativa de custos, cronograma e análise de riscos
Análise e design
Codificação e teste
Entrega e feedback

Vocês entenderam isso? O Pressman explica isso por meio da imagem acima! Percebam que o loop
mais interno (1) pode tratar do projeto de desenvolvimento de conceito, o segundo loop (2) pode
tratar do projeto de desenvolvimento de um produto, o terceiro loop (3) pode tratar do projeto de
melhoria e o último (4), mais claro, pode tratar do projeto de manutenção. Pode tratar de todo ciclo
de vida...

1 Na edição anterior, eram seis etapas no Modelo em Espiral (Planejamento, Análise de Riscos, Engenharia, Construção e Liberação, Avaliação do
Cliente e Comunicação com Cliente). Variações do modelo consideram entre três e seis setores da espiral. Infelizmente, cada autor pega a versão
original e adapta, criando sua versão, portanto vocês verão muitos nomes diferentes para cada setor.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
10
41
Cada loop é uma fase e a fase é escolhida de acordo com as necessidades do negócio! Já os
setores do processo são fixos para todos os loops. No entanto, Boehm utiliza uma divisão de setores
diferente do Pressman. No caso de dúvida na hora da prova, considerem a versão original do
Modelo de Boehm. Além disso, ao final de cada loop, há uma tomada de decisão a respeito do
projeto.

Vocês perceberam, pela imagem exibida anteriormente, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir se o
projeto continuará ou se será interrompido. Pessoal, por que esse modelo se destaca em relação
aos outros modelos? Porque ele enfatiza bastante um aspecto que o diferencia dos demais: Análise
de Riscos.

Este é um modelo complexo que precisa ser gerenciado por pessoas que tenham grande
experiência na avaliação de riscos. Geralmente, o modelo é utilizado em sistemas críticos e grandes!
Por fim, vamos ver um tema mais polêmico: ele é evolucionário ou é incremental? Pressman diz que
é iterativo, mas, não, incremental – sendo, então, evolucionário. Logo, é nele em que vamos nos
basear!

O conceito essencial do modelo é minimizar os riscos pelo uso repetido de protótipos e outros
meios. Ao contrário de outros modelos, em cada fase a análise de risco é realizada. O modelo
funciona através da construção de versões progressivamente mais completas do software,
iniciando no centro da espiral para o exterior. A cada volta, o cliente avalia o trabalho e são feitas
sugestões.

O modelo, então, se diferencia por ter uma abordagem cíclica, para aumentar incrementalmente
o grau de definição e de implementação de um sistema enquanto diminui seu grau de risco; e por
ter conjunto de marcos de ancoragem, para garantir o comprometimento dos interessados com
soluções exequíveis e mutuamente satisfatórias para o sistema. Vamos ver agora suas maiores
vantagens e desvantagens:

Suporta mecanismos de redução de riscos.
Exige analistas de risco bastante experientes.

Obtêm-se versões do sistema a cada iteração.
Exige uma equipe de desenvolvimento extremamente
qualificada.
Entregando produtos cada vez mais refinados e de
melhor qualidade.
Exige um gerenciamento de processo mais complexo.
Reflete as práticas reais de engenharia atual.

Não é recomendado resolver problemas mais simples e
pequenos.
Apresenta uma abordagem sistemática.

Apresenta estimativas realistas.

Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
11
41
==5617c==
Pessoal, é importante ver como esse modelo é tratado por Roger Pressman. De acordo com o autor,
o modelo espiral é um modelo de processo de software evolucionário que acopla a natureza
iterativa da prototipação com os aspectos sistemáticos e controlados do modelo cascata. Fornece
potencial para o rápido desenvolvimento de versões cada vez mais completas do software.
Usando-se o modelo espiral, o software será desenvolvido em uma série de versões evolucionárias.

Nas primeiras iterações, a versão pode consistir em um modelo ou em um protótipo. Já nas
iterações posteriores, são produzidas versões cada vez mais completas do sistema que passa pelo
processo de engenharia. Assim que esse processo evolucionário começa, a equipe de software
realiza atividades indicadas por um circuito em torno da espiral no sentido horário, começando pelo
seu centro. Os riscos são considerados à medida que cada revolução é realizada.

Diferente de outros modelos de processo, que terminam quando o software é entregue, o modelo
espiral pode ser adaptado para ser aplicado ao longo da vida do software. Em sua essência, a espiral
permanece em operação até que o software seja retirado. Trata-se de uma abordagem realista para
o desenvolvimento em larga escala. Pelo fatode o software evoluir à medida que o processo
avança, desenvolvedor e cliente compreendem e reagem melhor aos riscos em cada evolução.

Esse modelo usa a prototipação como mecanismo de redução de riscos e torna possível a
aplicação da prototipação em qualquer estágio do processo evolutivo do produto. Mantém a
abordagem em etapas sugerida pelo ciclo de vida clássico, mas a incorpora em uma metodologia
iterativa que reflete mais o mundo real. O modelo espiral requer consideração direta dos riscos
técnicos em todos os estágios e é capaz de reduzir riscos antes de se tornarem problemáticos.

Agora vamos falar sobre alguns modelos específicos que caem bem menos que os anteriores!
Professor, por que esse nome? Bem, é só para agrupar modelos que não se encaixam diretamente
em outros grupos. Comecemos pelos Métodos Formais, termo usado para indicar atividades que
contem com representações matemáticas de software, especificação formal, prova de
especificação, desenvolvimento transformacional, entre outros.

Esse modelo é utilizado em ambientes extremamente complexos com requisitos rigorosos. São
bastante lentos e dispendiosos, além de exigirem um treinamento intensivo. Em geral, são
utilizados para o desenvolvimento de sistemas que necessitam de grande robustez e confiabilidade
diante da possibilidade de perda de vidas ou sério prejuízo, caso haja falhas. Os chamados métodos
formais não são amplamente usados no desenvolvimento de software industrial.

A maioria das empresas de desenvolvimento de software não considera adequados com relação
aos seus custos. Por outro lado, a especificação formal é uma excelente maneira para descobrir
erros de especificação e apresentar a especificação do sistema de modo não ambíguo. As poucas
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
12
41
organizações que têm feito investimentos em métodos formais têm constatado menos erros no
software entregue aos clientes e tudo isso sem aumento de custos.

Os métodos formais podem ser adequados em termos de custo caso seu uso seja limitado a
partes do núcleo do sistema e caso as empresas desejem fazer alto investimento inicial nessa
tecnologia. Professor, pode dar um exemplo de método formal? Sim! O Método Cleanroom, que trata
o desenvolvimento semelhante a uma sala limpa de cirurgia. Vamos ver mais alguns detalhes
importante...

Métodos Formais são métodos utilizados para elaboração de sistemas computacionais dando
prioridade a sua coesão, isto porque estes métodos são desenvolvidos a partir de princípios
matemáticos que garantem a sua exatidão na capacidade de expressão das ideias vinculadas ao
projeto de software. Estes métodos foram desenvolvidos para auxiliar todas as etapas de
desenvolvimento de software2. Vejamos as etapas:

Busca formalizar os requisitos descobertos utilizando algum método formal, criando
uma modelagem com o uso de elementos.

Busca conceber o projeto de software, ou seja, nesta fase é pensado na arquitetura
do sistema com seus diversos componentes e suas interfaces, dados e
relacionamentos entre os mesmos.
Busca gerar esqueleto de código, a partir do modelo refinado, que pode servir como
base para implementação real do sistema.

Busca elaborar um protótipo funcional do sistema para validar se o mesmo, atende
as necessidades do cliente.

Busca verificar se o sistema desenvolvido foi concebido atendendo a todos os
Requisitos Funcionais e Não-Funcionais elicitados.

O uso de métodos formais pode ser aplicado durante todas as etapas de desenvolvimento do
software ou somente em algumas etapas ou partes do projeto de desenvolvimento. De acordo com
Roger Pressman, os métodos formais possibilitam especificar, desenvolver e verificar um sistema
baseado em computador através da aplicação de uma notação matemática rigorosa. Eles oferecem
um mecanismo que elimina muitos dos problemas difíceis de ser superados com outros modelos.

Ambiguidade, incompletude e inconsistência podem ser descobertas e corrigidas mais
facilmente — não por meio de uma revisão local, mas devido à aplicação de análise matemática.
Quando são utilizados métodos formais durante o projeto, servem como base para verificar a

2 Pode ser utilizado também para modelar hardwares.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
13
41
programação e, portanto, possibilitam que se descubra e se corrijam erros que, de outra forma,
poderiam passar despercebidos.

Embora não seja uma abordagem predominante, ele oferece a promessa de software sem defeitos.
No entanto, foram mencionados motivos para preocupação a respeito de sua aplicabilidade em um
ambiente de negócios: (1) atualmente, o desenvolvimento de modelos formais consome muito
tempo e dinheiro; (2) pelo fato de poucos desenvolvedores de software possuírem formação e
experiência necessárias para aplicação dos métodos formais, é necessário treinamento extensivo.

(3) É difícil usar os modelos como um meio de comunicação com clientes tecnicamente
despreparados (não sofisticados tecnicamente). Apesar de tais preocupações, a abordagem de
métodos formais tem conquistado adeptos entre os desenvolvedores de software que precisam
desenvolver software com fator crítico de segurança, bem como entre desenvolvedores que
sofreriam pesadas sanções econômicas se ocorressem erros no software.

Já Ian Sommerville afirma que, por mais de 30 anos, muitos pesquisadores têm defendido o uso
de métodos formais de desenvolvimento de software. Os métodos formais são abordagens
baseadas em matemática para o desenvolvimento de software, em que é definido um modelo
formal do software. É possível analisar formalmente esse modelo e usá-lo como base para uma
especificação formal de sistema.

Em princípio, é possível começar com um modelo formal de software e provar que o programa
desenvolvido é consistente com o modelo, eliminando-se, assim, falhas de software resultantes de
erros de programação. O ponto de partida para todos os processos formais de desenvolvimento é
um modelo formal de sistema, que serve como uma especificação de sistema. Para criar esse
modelo, você traduz os requisitos de usuário do sistema. Como assim, Diego?

Os requisitos de usuário são expressos em linguagem natural, diagramas e tabelas – a ideia é
representá-los em uma linguagem matemática que defina formalmente a semântica. A
especificação formal é uma descrição inequívoca do que o sistema deve fazer (sem ambiguidades).
Usando métodos manuais ou apoiados por ferramentas, é possível verificar se o comportamento
de um programa é consistente com a especificação.

As especificações formais não são apenas essenciais para uma verificação do projeto e
implementação do software. Elas são a maneira mais precisa de especificação dos sistemas e,
assim, de redução da possibilidade de mal-entendidos. Além disso, a construção de uma
especificação formal força uma análise detalhada dos requisitos, e essa é uma maneira eficaz
de descobrir problemas de requisitos.

Em uma especificação em linguagem natural, os erros podem ser ocultados pela imprecisão da
linguagem. Já as especificações formais, em geral, são desenvolvidas como parte de um processo
baseado em planos, no qual o sistema é completamente especificado antes do desenvolvimento.
Apesar dessas vantagens, os métodos formais tiveram um impacto limitado no
desenvolvimentoprático de software, mesmo para sistemas críticos.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
14
41

Pessoal, vocês já pararam para pensar por que a disciplina de Engenharia
de Software é denominada Engenharia de Software? Vamos contar essa
história: esse conceito surgiu em 1968, em uma conferência
organizada para discutir a Crise do Software. Essa crise foi o resultado
da introdução de circuitos integrados em computadores. E isso era
ruim, professor? Não, pelo contrário!

Desde o ingresso dos circuitos integrados, tornou-se possível e viável fazer aplicações
extremamente complexas. No entanto, o desenvolvimento de software era bastante informal e
incipiente, criando softwares, cujo custo superava as previsões, não confiáveis, difíceis de manter
e de desempenho insatisfatório. Naquela época, os custos de hardware estavam caindo, enquanto
os custos de software aumentavam rapidamente.

Novas técnicas e métodos eram necessários para controlar a complexidade inerente aos grandes
sistemas de software. E por que o nome engenharia de software? Porque foi uma tentativa de
contornar a crise ao utilizar princípios de engenharia, a fim de obter um software de maneira
econômica e que fosse confiável, dando um tratamento mais sistemático e controlado (comum às
engenharias) ao desenvolvimento de sistemas de software complexos.

Pessoal, pensem comigo: a engenharia evolui seus métodos há centenas de anos, enquanto o
desenvolvimento de software é bastante recente! Logo, faz sentido utilizar os conceitos
consolidados de engenharia para melhorar seus processos de desenvolvimento de software. Não
acham? Ok, professor! Mas o que isso tem a ver com reúso de componentes? Ora, a Engenharia é
especializada em produzir componentes reusáveis.

Engenheiros raramente fabricam um componente a partir do nada. Eles baseiam seus projetos em
componentes exaustivamente testados em outros sistemas. Quando se fala em Modelo baseado
em Componentes, refere-se a uma estratégia de engenharia de software na qual o processo de
desenvolvimento é voltado à reusabilidade. E qual a vantagem disso? Isso resulta em redução de
custos de produção e manutenção, entregas mais rápidas e aumento de qualidade.

A abordagem para desenvolvimento de software Component-Based Software Engineering (CBSE)
tem utilizado o reúso como peça principal. Essa abordagem depende de uma grande base de
componentes reusáveis e algum framework de integração. Apesar não termos valores precisos,
sabemos que os custos de desenvolvimento são menores que os custos de integração e de
teste.

Esses custos aumentam porque é necessário assegurar que os componentes utilizados realmente
satisfazem às especificações e funcionam com outros componentes. Agora voltando um pouco: o
que seria exatamente um componente? Pressman afirma que é um bloco de construção modular,
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
15
41
isto é, uma parte do sistema modular, executável, implantável, independente, padronizada e
reutilizável que encapsula a implementação e expõe um conjunto de interfaces do sistema.

Tem o objetivo de traduzir as informações coletadas durante a atividade de análise em um
documento que define um conjunto de requisitos de software. Devem ser incluídos dois tipos
de requisitos nesse documento: os Requisitos de Usuário e Requisitos de Sistema.

Nesta fase, é feita uma busca pelos componentes para implementar essa especificação.
Geralmente, não existe uma correspondência exata entre o componente encontrado e o
procurado. Muitas vezes, os componentes que podem ser usados fornecem apenas parte da
funcionalidade necessária.
Os requisitos são analisados usando as informações sobre os componentes encontrados, que
são modificados para refletir os componentes disponíveis. Quando as modificações são
impossíveis, a atividade de análise de componentes pode ser novamente realizada para
procurar alternativas.
O framework do sistema é projetado ou um framework existente é reutilizado. Os projetistas
levam em consideração os componentes reusados. Pode ser necessário projetar algum
software novo caso os componentes reusáveis não estejam disponíveis para aquisição para o
sistema.
Software que não pode ser adquirido externamente é desenvolvido e os componentes e os
sistemas COTS são integrados para criar os novos sistemas. A integração de sistema, neste
modelo, pode ser parte do processo de desenvolvimento, em vez de ser uma atividade
separada.
Processo de verificação de se um sistema atende às necessidades e expectativas do cliente.
Professor, o que são Sistemas COTS? Esse é o acrônimo de Commercial Off-The-Shelf, que
é um conjunto de soluções pré-fabricadas e disponíveis no mercado, podendo ser compradas
ou licenciadas, i.e., uma grande biblioteca de componentes prontos.

Os Componentes COTS são desenvolvidos por vendedores que os oferecem como produtos,
disponibilizam a funcionalidade almejada juntamente com as interfaces bem definidas, sendo que
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
16
41
essas interfaces permitem que o componente seja integrado ao software a ser desenvolvido. O
modelo de desenvolvimento baseado em componentes incorpora muitas das características do
modelo espiral.

Ele é evolucionário por natureza, demandando uma abordagem iterativa para a criação de
software. O modelo de desenvolvimento baseado em componentes desenvolve aplicações a partir
de componentes de software pré-empacotados e conduz ao reúso do software; sendo que essa
reusabilidade proporciona uma série de benefícios mensuráveis aos engenheiros de software.
O modelo evolucionário assume que recursos adicionais podem ser adicionados, se necessários.

No entanto, componentes de software de prateleira (COTS) não podem ser atualizados por uma
equipe de desenvolvimento particular. A ausência de código-fonte barra a equipe de
desenvolvimento de ajustar estes componentes de software para suas necessidades. Então, apesar
de conter algumas características do modelo em cascata e do modelo evolucionário, ele não pode
ser considerado como parte desses modelos.

A maioria dos processos de desenvolvimento de software vem considerando sistemas com
unidades cada vez menores de desenvolvimento, isto é, vem modularizando cada vez mais os
sistemas. A Engenharia de Software provê as bases para o desenvolvimento de software, já as
linguagens de programação permitem a abstração de unidades e composição destas de
inúmeras formas possíveis.

Sabe-se que no desenvolvimento de software existem propriedades que não se enquadram em
componentes da decomposição funcional, tais como: tratamento de exceções, restrições de tempo
real, distribuição e controle de concorrência. Vocês compreendem isso? A grande maioria das
unidades de programação podem ser decompostas em uma função, porém existem unidades
que não podem.

Qual o problema, professor? Bem, essas unidades normalmente ficam espalhadas em diversos
componentes do sistema afetando a performance e a semântica da aplicação.Vamos traduzir?
Quando nós modularizamos um sistema, torna-se mais fácil e intuitivo entender o
funcionamento de uma aplicação; essas unidades que não podem ser decompostas em funções
atrapalham esse entendimento.

Imaginem que temos um método que recebe um valor, realiza um processamento e devolve outro
valor. Uma função dentro desse método possui um tratamento de exceção! Galera, tratamento
de exceção não faz parte da funcionalidade principal, no entanto – mesmo assim – ela fica presente
no código (atrapalhando a modularização e o acoplamento). De fato, essas unidades podem ser
visualizadas e analisadas relativamente em separado.

Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
17
41
No entanto, sua implementação utilizando linguagens orientadas a objeto ou estruturadas torna-
se confusa e seu código encontra-se espalhado através do código da aplicação, dificultando a
separação da funcionalidade básica do sistema dessas propriedades. A Programação Orientada
a Aspectos (POA) é uma abordagem que permite a separação dessas propriedades ortogonais3
dos componentes funcionais de uma forma natural e concisa.

Ela se utiliza de mecanismos de abstração e de composição para a produção de código executável.
Vocês podem me perguntar: Professor, por que não podemos utilizar programação orientada a
objetos ou programação estruturada? Atualmente, conhecem-se vários problemas de programação
em que as técnicas de orientação a objetos ou de programação estruturada não são suficientes para
separar claramente todas as decisões de projeto que o programa deve implementar.

Isto se deve ao fato de que as abordagens mais utilizadas se concentram em encontrar e
compor unidades funcionais da decomposição do sistema. Já outras questões importantes não
são bem localizadas no projeto funcional. Exemplos disto podem ser propriedades que envolvem
várias unidades funcionais, tais como: sincronização, restrições de tempo, concorrência,
distribuição de objetos, persistência, etc.

Em suma, POA é um paradigma de desenvolvimento de software que separa responsabilidades,
requisitos e interesses de um sistema. A modularização dos aspectos produz uma arquitetura fácil
de projetar, implementar e manter. Muitos acham que esse paradigma veio para substituir a
Programação Orientada a Objetos (POO). Está certo isso? Claro que não! POA veio para
complementar a POO (visto que utilizá-la isoladamente não traz benefícios para o projeto).

Para tal, ela mantém o foco na separação de interesses (Separation of Concerns), que são
requisitos específicos que devem ser atendidos para satisfazer o objetivo de um sistema, mas
que não pertencem ao domínio do negócio. Há dois tipos: (1) Interesses Principais (Core
Concerns): capturam as funcionalidades centrais de um módulo; (2) Interesses Ortogonais
(Crosscutting Concerns): capturam funcionalidades periféricas.

Por que separar interesses? Porque, dessa forma, gera-se código de melhor qualidade; gera-se
maior modularidade; facilita-se atribuição de responsabilidade entre módulos distintos; promove-
se a reusabilidade de código; facilita-se a evolução de software; viabiliza-se a análise do problema
dentro de domínios específicos; entre outras tantas vantagens. Ok, professor... mas o que são
exatamente aspectos?

Aspectos são propriedades de um sistema envolvendo diversos componentes funcionais que não
podem ser expressos usando notações e linguagens atuais de uma maneira precisa (Ex:
sincronização, persistência, interação entre componentes, etc). Os interesses são carregados em

3 Quando duas propriedades sendo programadas devem ser compostas de maneira diferente e ainda coordenarem-se é dito que elas são ortogonais
entre si.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
18
41
um módulo chamado aspecto. Professor, um aspecto é um componente? Não, componentes podem
ser encapsulados em um procedimento generalizado (objeto, método, procedimento, etc).

Aspectos, em geral, não são unidades de decomposição funcional do sistema, mas propriedades
que envolvem diversas unidades de um sistema, afetando a semântica dos componentes funcionais
sistematicamente. Por exemplo: controle de concorrência em operações em uma mesma conta
bancária, registro das transações de uma determinada conta, política de segurança de acesso aos
usuários de um sistema, restrições de tempo real associadas à entrega de mensagens.

Dada a definição de componentes e aspectos, é possível colocar o objetivo da programação
orientada a aspectos: oferecer suporte para o programador na tarefa de separar claramente os
componentes dos aspectos, os componentes entre si e os aspectos entre si, utilizando-se de
mecanismos que permitam a abstração e composição destas, produzindo o sistema desejado4. E o
que Roger Pressman tem a dizer sobre esse paradigma? Vejamos...

Independentemente do processo de software escolhido, os desenvolvedores de software
complexos, invariavelmente, implementam um conjunto de recursos, funções e conteúdo
localizados. Essas características de software localizadas são modeladas como componentes (por
exemplo, classes orientadas a objetos) e, em seguida, construídas dentro do contexto da
arquitetura do sistema.

À medida que os modernos sistemas baseados em computadores se tornam mais sofisticados,
certas restrições – propriedades exigidas pelo cliente ou áreas de interesse técnico — se estendem
por toda a arquitetura. Algumas restrições são propriedades de alto nível de um sistema (Ex:
segurança, tolerância a falhas). Outras afetam funções (Ex: a aplicação de regras de negócio), sendo
que outras são sistêmicas (Ex: sincronização de tarefas ou gerenciamento de memória).

De acordo com o autor, o modelo orientado a aspectos é um paradigma de engenharia de software
relativamente novo que oferece uma abordagem metodológica e de processos para definir,
especificar, projetar e construir aspectos. Já Ian Sommerville nos oferece uma visão mais detalhada
– ele nos introduz o assunto da seguinte maneira: na maioria dos sistemas de grande porte, os
relacionamentos entre requisitos e componentes de programa são complexos.

Um único requisito pode ser implementado por uma série de componentes, e cada componente
pode incluir elementos de vários requisitos. Na prática, isso significa que mudar requisitos pode
envolver o entendimento e a alteração de vários componentes. Como alternativa, um componente
pode prover alguma funcionalidade central, mas também incluir o código que implementa vários
requisitos de sistema.

Mesmo quando parece haver reúso significativo em potencial, pode ficar caro reusar tais
componentes. O reúso pode envolver sua alteração para remover um código extra que não esteja

4 AspectJ é a mais famosa linguagem de programação orientada a aspectos.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
19
41
associado com a funcionalidade central do componente. O modelo orientado a aspectos é uma
abordagem para desenvolvimento de software que se propõe a resolver esse problema e tornar os
programasmais fáceis de manter e reusar.

Ela é baseada em abstrações chamadas aspectos, que implementam funcionalidade de sistema que
pode ser requerida em vários lugares diferentes em um programa. Eles encapsulam a
funcionalidade que cruza e coexiste com outra funcionalidade que existe no sistema e são usados
junto com outras abstrações, como objetos e métodos. O principal benefício de uma abordagem
orientada a aspectos é que ela suporta a separação de interesses.

Separar interesses em elementos diferentes em vez de incluir interesses diferentes na mesma
abstração lógica é uma boa prática de engenharia de software. Ao apresentar interesses
transversais como aspectos, esses interesses podem ser entendidos, reusados e modificados de
forma independente, sem a preocupação de onde o código é usado. Um exemplo clássico é a
autenticação de usuário...

A autenticação de usuário é uma funcionalidade que pode ser representada como um aspecto que
requisita um nome de usuário e uma senha. Isso pode ser automaticamente embutido no programa
sempre que uma autenticação for requerida. Digamos que você tenha um requisito de que a
autenticação de usuário seja requerida antes de qualquer alteração dos detalhes pessoais ser feita
no banco de dados – isso pode ser um aspecto.

1. (CESPE / Polícia Federal – 2021) Embora não seja dirigido a riscos, o modelo de
desenvolvimento de sistemas espiral de Boehm inclui, em seu framework, a etapa de análise e
validação dos requisitos.

Comentários:

O Modelo em Espiral foi proposto originalmente, em 1988, por Boehm. Sua ideia era representar
um processo de software orientado a riscos. Em vez de representar o processo como uma sequência
de atividades com algum retorno entre uma atividade e outra, o processo é representado como uma
espiral. Ele combina atividades de desenvolvimento com aspectos gerenciais (Planejamento,
Tomada de Decisão, Análise de Riscos, etc).

Gabarito: Errado

2. (VUNESP / TJM-SP – 2021) Algumas atividades que fazem parte do modelo espiral de
desenvolvimento de software são:

Construção – Implantação – Comunicação –
Planejamento – Modelagem

A ordem correta com que tais atividades são executadas, considerando o modelo espiral, é:

a) Comunicação, Planejamento, Modelagem, Construção e Implantação.
b) Construção, Implantação, Comunicação, Modelagem e Planejamento.
c) Modelagem, Planejamento, Construção, Implantação e Comunicação.
d) Planejamento, Construção, Implantação, Comunicação e Modelagem.
e) Planejamento, Modelagem, Comunicação, Construção e Implantação.

Comentários:

As atividades do modelo espiral são: Comunicação, Planejamento, Modelagem, Construção e
Implantação (ou Emprego).

Gabarito: Letra A

3. (CESPE / SERPRO – 2021) No modelo formal, as etapas do desenvolvimento do software
incluem especificação formal para definição de requisitos, refinamento para concepção de
projeto e prova para a verificação.

Comentários:

As etapas são especificação formal para definição de requisitos, refinamento para concepção de
projeto, síntese para implementação, prototipagem para a validação e prova para a verificação.
Logo, todas essas listadas no enunciado estão contempladas.

Gabarito: Correto

4. (COSEAC / UFF – 2019) Nos projetos, quando o time quebra o produto em vários pedaços
menores, trabalhando e entregando uma parte de cada vez, sem se preocupar com agilidade, e
somente quando esta parte estiver pronta o time parte para outro pedaço, iniciando uma nova
fase, constata-se um ciclo de vida:

a) preditivo.
b) iterativo e incremental.
c) adaptativo.
d) RUP.
e) cascata.

Comentários:

Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
22
41
Quebra o produto em vários pedaços menores? Entrega uma parte de cada vez? São todas
características do modelo iterativo e incremental. Somente quando essa parte estiver pronta o time
parte para outro pedaço? Sim, a equipe que está trabalhando no subsistema funcional somente
partirá para o outro subsistema funcional quando terminá-lo.

Gabarito: Letra B

a) Métodos Formais.
b) Business Process Management (BPM).
c) Capability Maturity Model Integration (CMMI)
d) Incremental.
e) Entidade e Relacionamento.

Comentários:

“Fornecer, de forma prioritária, um conjunto de funcionalidades iniciais básicas e, após esse
fornecimento, podemos melhorar e expandir as funcionalidades em versões de software posteriores,
até atingir todos os requisitos definidos” – todas são características do modelo incremental.

Gabarito: Letra D

6. (FADESP / IF-PA – 2019) O princípio fundamental é que, a cada ciclo, uma versão operacional
do sistema será produzida e entregue para uso ou avaliação detalhada do cliente. Os requisitos
têm de ser levantados e é preciso constatar que o sistema é modular. Esse é o modelo:

a) Incremental.
b) Espiral.
c) Cascata.
d) RAD.
e) XP.

Comentários:

Uma versão operacional a cada ciclo para avaliação do cliente em um sistema modular é uma
característica do modelo incremental.

7. (CETREDE / Prefeitura de São Gonçalo do Amarante - CE – 2019) Sobre Engenharia de
Software, marque a opção INCORRETA.

a) O modelo Cascata tem como característica intercalar as atividades de especificação,
desenvolvimento e validação. Esta abordagem, permite a entrega de um produto ao fim de um
longo ciclo de desenvolvimento e com baixa perspectiva de falha funcional.

b) A engenharia de software baseada em componentes baseia-se na existência de um número
significativo de componentes reusáveis, enfocando o desenvolvimento na integração destes
componentes.

c) No desenvolvimento exploratório, o objetivo do processo é trabalhar com o cliente para
explorar os requisitos e entregar o sistema final.

d) No processo de engenharia de requisitos, a etapa de elicitação e análise dos requisitos é
responsável pela derivação de requisitos através da observação de sistemas existentes,
discussões com usuários potenciais,análise de tarefas etc.

e) Especificação, projeto e implementação, validação e evolução do software são etapas
comuns em qualquer processo de software.

Comentários:

Todos os itens estão corretos, exceto o primeiro. A questão trata do modelo evolucionário ou
incremental (depende da versão do livro) e, não, do modelo em cascata.

Gabarito: Letra A

8. (CESPE / SLU-DF – 2019) No modelo de desenvolvimento de software em cascata, a
abordagem é orientada ao risco e as tarefas são organizadas nos seguintes ciclos: determinar
objetivos, identificar e resolver riscos, desenvolver e testar, e planejar a próxima iteração.

Comentários:

Opa... as fases e a característica de ser orientado a risco tratam do modelo em espiral e, não, do
modelo em cascata.

Gabarito: Errado

9. (COSEAC / UFF – 2019) Dos modelos de desenvolvimento de software, aquele que prioriza a
análise dos riscos envolvidos no desenvolvimento de cada parte do software é o modelo:
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
24
41

a) em cascata.
b) de prototipação.
c) incremental.
d) espiral.
e) baseado em componentes.

Comentários:

O modelo que prioriza a análise de riscos envolvidos no desenvolvimento é o modelo em espiral.

Gabarito: Letra D

10. (CESPE / MPC-PA – 2019) Os modelos espiral e RAD (Rapid Application Development) são
classificados, respectivamente, como modelos de processo de desenvolvimento
de software dos tipos

a) incremental e sequencial.
b) evolutivo e incremental.
c) evolutivo e sequencial.
d) incremental e evolutivo.
e) evolutivo e evolutivo.

Comentários:

Ambos são classificados como modelos de desenvolvimento de software do tipo evolutivo e
incremental.

Gabarito: Letra B

11. (INSTITUTO AOCP / UFFS – 2019) Assinale a alternativa que apresenta uma característica do
modelo espiral para engenharia de software.

a) Na etapa “engenharia”, são identificadas as alternativas e as restrições.
b) Contempla a análise de riscos, além das melhores características do ciclo de vida clássico e
prototipação.
c) O modelo espiral veio para substituir o modelo cascata, que caiu em desuso por sua alta
complexidade.
d) Esse modelo contempla as seguintes atividades: engenharia de sistemas, análise, projeto,
codificação, teste e manutenção.
e) Esse modelo define que, na etapa de desenvolvimento, deve ser adotada uma metodologia
ágil de desenvolvimento.

(a) Errado, essa é a etapa de planejamento; (b) Correto, tanto que é conhecido como uma
prototipação em etapas; (c) Errado, ele não veio para substituir o modelo em cascata e o modelo
em cascata não é altamente complexo; (d) Errado, as atividades são: planejamento, análise de
riscos, engenharia, construção e liberação, avaliação do cliente e comunicação com cliente; (e)
Errado, não existe essa definição.

Gabarito: Letra B

12. (COVEST-COPSET / UFPE – 2019) A respeito de modelos de processo de software, assinale a
alternativa correta:

a) O modelo em cascata é inconsistente com outros modelos de processos de engenharia, tendo
documentação produzida em cada fase do ciclo. Dessa forma, o processo torna-se pouco visível,
dificultando o monitoramento do progresso pelos gerentes, de acordo com o plano de
desenvolvimento.

b) No modelo espiral de Boehm, o processo de software é representado como uma espiral em
que cada volta representa uma fase do processo de software. O modelo não se tornou popular
devido a problemas ligados ao gerenciamento de riscos de projeto.

c) Existem alguns tipos de sistema para os quais o desenvolvimento e a entrega incrementais
não são a melhor abordagem. Por exemplo, alguns sistemas críticos, em que todos os requisitos
devem ser analisados na busca por iterações capazes de comprometer a proteção ou a
segurança do sistema.

d) Um modelo de processo para desenvolvimento de protótipos em que os objetivos da
prototipação são descobertos ao final de cada iteração, depois que os usuários experimentarem
os diversos protótipos produzidos ao longo do processo. Isso torna a abordagem pouco
previsível e mais incerta.

e) Na entrega incremental, os clientes podem usar os incrementos iniciais como protótipos e
visualizar o avanço gradativo no desenvolvimento, mas necessitam reaprender o uso do sistema
quando sua versão final estiver disponível.

Comentários:

(a) Errado, é um modelo consistente com outros modelos e o processo é visível, facilitando o
monitoramento do progresso; (b) Errado, ele se tornou popular justamente por ser voltado a riscos;
(c) Correto; (d) Errado, são descobertos no início do processo – além disso, isso torna a abordagem
mais previsível e certeira; (e) Errado, não é necessário reaprendê-lo visto que o sistema vai sendo
incrementado aos poucos, logo – ao final – estará da maneira especificada pelo usuário.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
26
41

Gabarito: Letra C

13. (FCC / TRF - 3ª REGIÃO – 2019) No modelo em espiral de processo de software (Boehm), antes
de cada atividade de prototipação, é sempre realizada uma atividade de:

a) plano de desenvolvimento.
b) validação de requisitos.
c) teste de aceitação.
d) análise de riscos.
e) plano de ciclo de vida.

Comentários:

Antes de cada atividade de prototipação, é realizada a análise de riscos.

Gabarito: Letra D

14. (FCC / TRF - 3ª REGIÃO – 2019) Considere o modelo de ciclo de vida de software constituído
por rotinas de trabalho com a participação de todos os membros da equipe, onde falhas não são
toleráveis e por isso, entre as atividades, duas têm grande importância no processo: uma delas
dedicada ao planejamento da etapa e outra à de análise de riscos. As atividades são apoiadas
pela geração de protótipos. Suporta o desenvolvimento de sistemas complexos e de grande
porte. Trata-se do modelo:

a) Interativo e Incremental.
b) RAD - Rapid Application Development.
c) Espiral.
d) Cascata.
e) Evolutivo.

Todas as características apresentadas no enunciado nos remetem ao modelo espiral – com ênfase
na análise de riscos.

Gabarito: Letra C

15. (IBFC / Prefeitura de Cuiabá - MT – 2019) Heitor é gerente de projeto e precisa decidir qual
modelo utilizará no processo de desenvolvimento do próximo software da empresa Brasil.
Quanto a alguns dos modelos do ciclo de vida de desenvolvimento de software, assinale a
alternativa incorreta.

a) Modelo Espiral: produto final é entregue rapidamente
b) Modelo Incremental: produzem o sistema de forma incremental até a sua versão final
c) Metodologias Ágeis: dura de 1(uma) a 4(quatro) semanas e aofinal de cada iteração deve
haver entrega ao cliente
d) Modelo em Cascata: componente do sistema é entregue por fases, podendo acontecer
paralelamente

Comentários:

(a) Correto, é a principal característica do RAD, mas o modelo espiral também tem esse potencial;
(b) Correto; (c) Correto, apesar de se referir especificamente ao Scrum; (d) Errado, tudo é entregue
ao final e as fases não podem ocorrer paralelamente.

Gabarito: Letra D

16. (COSEAC / UFF – 2019) Em relação aos modelos de processos de software, avalie se são
verdadeiras (V) ou falsas (F) as afirmativas a seguir:

I. O modelo de desenvolvimento orientado a reúso tem a vantagem da redução de riscos e de
custos.
II. O modelo de desenvolvimento incremental possui a vantagem da facilidade de mapear os
requisitos dos clientes dentro de incrementos de tamanho correto.
III. O modelo em cascata deve ser utilizado somente quando os requisitos forem bem
compreendidos.

As afirmativas I, II e III são, respectivamente:

a) V, F e V.
b) F, V e V.
c) V, F e F.
d) F, F e V.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
28
41
e) V, V e V.

Comentários:

(I) Correto, o modelo de desenvolvimento orientado a reúso realmente tem a vantagem da redução
de riscos e de custos; (II) Errado, apesar disso eu não consigo identificar o erro da questão, mas esse
foi o gabarito definitivo; (III) Correto, ele é adequado justamente quando os requisitos forem bem
compreendidos.

Gabarito: Letra A

17. (CESGRANRIO / PETROBRAS – 2018) O chefe dos desenvolvedores de sistemas de uma
empresa acompanhou o seguinte diálogo entre um de seus subordinados, um usuário e o diretor
de operações.

Diretor – Acho que já poderíamos começar o desenvolvimento daquele sistema que o
departamento de esportes pediu.

Usuário – Não é cedo demais? Ainda não temos todas as funcionalidades bem definidas.

Desenvolvedor – É verdade, mas acho que já é possível especificar e implementar algumas
funcionalidades mais importantes e construir uma primeira versão até o final do mês. Depois
acrescentaríamos outras funcionalidades à medida que as fôssemos construindo, gerando, a
partir da experiência do uso, versões sucessivas e cada vez mais completas.

Diretor – Acho isso ótimo, assim já teremos uma noção do impacto que o sistema poderá causar
no desempenho dos atletas. Comecemos logo, não temos um efetivo tão grande em TI.

Usuário – OK, vamos em frente, mas não contem nada para aquele especialista em risco. Já
temos muito trabalho pela frente. Nossa estrutura ainda não suporta esse tipo de cuidado; se
entrarmos nessa, o projeto vai atrasar. E mantenham o contato e o foco no objetivo: um produto
simples, mas de qualidade.

A partir desse episódio e refletindo sobre o que ouvira, o chefe dos desenvolvedores deverá optar
pelo modelo de processo de software:

a) RAD
b) incremental
c) cascata
d) espiral
e) baseado em componentes

Comentários:
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
29
41

(a) Errado. No RAD, não há versões intermediárias, visto que se trata de um processo de
desenvolvimento extremamente rápido; (b) Correto. O modelo incremental é realmente indicado
quando não há funcionalidades bem definidas, logo se inicia pelas mais importantes e são lançadas
versões sucessivas e cada vez mais completas posteriormente; (c) Errado. Se ainda não há
funcionalidades bem definidas, não se deve utilizar o modelo em cascata; (d) Errado. O modelo em
espiral é dirigido a riscos e a conversa deixa claro que não se deve contar com o especialista em risco
– como o risco não é considerado, não é recomendável utilizar o modelo em espiral; (e) Errado. Não
há nada que leve a crer que se trata do modelo baseado em componentes.

Gabarito: Letra B

18. (IADES / CFM – 2018) O Modelo Espiral (Spiral) foi originalmente proposto por Boehm (1986) e
é fortemente orientado à redução de riscos.

WAZLAWICK, R. S. Engenharia de Software: Conceitos e práticas. São Paulo: Elsevier, 2013.

Considerando o exposto e o Modelo Espiral de ciclo de vida de software, assinale a alternativa
correta:

a) O Modelo Espiral realiza uma etapa de cada vez, partindo para a próxima etapa apenas após
a anterior estar totalmente validada.

b) Tal modelo de ciclo de vida tem foco apenas na resolução de riscos de requisitos mal
compreendidos, fornecendo tempo suficiente para que estes possam ser entendidos e
implementados.

c) O projeto é dividido em subprojetos, cada qual abordando um ou mais elementos de alto
risco, até que todos os riscos identificados tenham sido tratados.

d) Cada iteração é iniciada sem planejamento prévio, resolvendo-se os problemas no momento
em que surgem.

e) O início do ciclo de vida do projeto se parece mais com o Modelo Cascata.

Comentários:

(a) Errado, esse item trata do modelo em cascata; (b) Errado, não se trata apenas de riscos de
requisitos mal compreendidos, mas diversos outros tipos de riscos como riscos de desempenho,
arquitetural, entre outros; (c) Correto, o projeto é realmente dividido em subprojetos abordando
um ou mais elementos de alto risco até que todos os riscos sejam identificados; (d) Errado, o
planejamento é realizado com base nos riscos identificados, e, em cada nova interação, é definida
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
30
41
==5617c==
uma abordagem; (e) Errado, ele divide o projeto em partes, no início com protótipos, identifica os
principais riscos, e, em cada ciclo, os riscos são mitigados.

Gabarito: Letra C

19. (FADESP / IF-PA – 2018) Usando o modelo ____________, o sistema é desenvolvido em ciclos,
sendo que os primeiros ciclos podem não conter todas as atividades. O produto resultante de
um primeiro ciclo pode ser uma especificação do produto ou um estudo de viabilidade. Os ciclos
subsequentes podem ser protótipos, chegando progressivamente a versões operacionais do
software, até se obter o produto completo. Modelos podem ser úteis para ajudar a levantar e
validar requisitos, mas pode ocorrer de os clientes e usuários só terem uma verdadeira dimensão
do que está sendo construído se forem colocados diante do sistema. Nestes casos, o uso da
__________________ é fundamental.

As expressões que completam corretamente os espaços em branco, respectivamente, são:

a) espiral, prototipação.
b) cascata, prototipação.
c) XP, conversa com os clientes.
d) espiral, cascata.
e) incremental, prototipação.

Comentários:

Usando o modelo espiral, o sistema é desenvolvido em ciclos, sendo que os primeiros ciclos podem
não conter todas as atividades. O produto resultante de um primeiro ciclo pode ser uma
especificação do produto ou um estudo de viabilidade. Os ciclos subsequentes podem ser
protótipos, chegando progressivamente a versões operacionais do software, até se obter o produto
completo. Modelos podem ser úteis para ajudar a levantar e validar requisitos, mas pode ocorrer de
os clientes e usuários só terem uma verdadeira dimensão do que está sendo construído se forem
colocados diantedo sistema. Nestes casos, o uso da prototipação é fundamental.

Gabarito: Letra A

20. (AOCP / UNIR – 2018) O desenvolvimento formal de sistemas é uma abordagem que tem
pontos diferentes ao modelo em cascata e usa uma base da transformação matemática modal
de uma especificação de sistemas em um programa executável.

Comentários:

O desenvolvimento formal de sistemas é uma variação do modelo em cascata, logo os pontos são
muito parecidos. Ademais, ele utiliza uma base de transformação matemática formal e, não,
modal.
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
31
41

Gabarito: Errado

2. (VUNESP / TJM-SP – 2021) Algumas atividades que fazem parte do modelo espiral de
desenvolvimento de software são:

Construção – Implantação – Comunicação –
Planejamento – Modelagem

A ordem correta com que tais atividades são executadas, considerando o modelo espiral, é:

a) preditivo.
b) iterativo e incremental.
c) adaptativo.
d) RUP.
e) cascata.

5. (IF-PA / IF-PA – 2019) Tem-se como boas práticas em projetos de software a definição dos seus
requisitos funcionais e suas funcionalidades. No decorrer dessa definição, pode surgir a
necessidade de fornecer, de forma prioritária, um conjunto de funcionalidades iniciais básicas e,
após esse fornecimento, podemos melhorar e expandir as funcionalidades em versões de
software posteriores, até atingir todos os requisitos definidos. Nesse caso, estamos aplicando
um modelo de processo de software denominado:
Fernando Pedrosa Lopes , Thiago Rodrigues Cavalcanti, Erick Muzart Fonseca dos Santos, Paolla Ramos e Silva , Diego Carvalho, Renato da Costa, Equipe Informática e TI
Aula 30 (Profs Diego Carvalho e Fernando Pedrosa)
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2023
www.estrategiaconcursos.com.br
https://t.me/kakashi_copiador
33
41