Logo Passei Direto
Buscar

Ferramentas de estudo

Mês do Cliente Passei Direto

Quer receber 70% de desconto para assinar o PasseIA?

Questões resolvidas

Leia o texto a seguir:

Cada estágio é, por si só, um processo (ou coleção de processos) que pode ser descrito como conjunto de atividades. E cada atividade envolve restrições, resultados e recursos. Por exemplo, a análise e definição dos requisitos precisa ter como entrada inicial uma declaração das funções e características desejadas para o produto, expressas pelo usuário. O resultado final desse estágio é um conjunto de requisitos, mas pode haver produtos intermediários à medida que o diálogo entre o usuário e o desenvolvedor resulta em mudanças e alternativas.

Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall, 2004.

Considerando os princípios que fundamentam o processo tradicional e o processo ágil de software, mais as suas respectivas abordagens em relação à qualidade de seus produtos, avalie as seguintes asserções e a relação proposta entre elas.
I. O Modelo em Cascata vem se mostrando mais adequado às demandas menos urgentes de criação de software, posto que, embora suas etapas demandem tempo maior para cumprimento, o produto final obtido tem atingido qualidade superior ao produto similar construído sob o paradigma de desenvolvimento ágil.

# PORQUE

II. As metodologias ágeis de desenvolvimento, como o próprio nome sugere, estruturam suas etapas para que entreguem produtos intermediários o mais rapidamente possível, a fim de sanar necessidades específicas do cliente, o que acaba influenciando negativamente na qualidade do produto final.

A respeito dessas asserções, assinale a alternativa correta.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
As asserções I e II são ambas proposições falsas.

Leia o texto abaixo:

Pressman e Maxim (2016, p. 33), dizem que um fluxo de processos descreve, em relação a uma sequência e ao tempo, como são organizadas as ações e tarefas de cada atividade.

Existem vários tipos de fluxo de processos: o fluxo paralelo, onde as atividades acontecem simultaneamente, já no fluxo linear, as atividades são executadas uma após a outra, ou seja, é necessário que uma atividade acabe para que a próxima seja iniciada, por exemplo. Existem ainda os fluxos evolucionário e interativo.

O modelo cascata foi um dos tipos mais utilizado até os anos 2000 e é considerado um modelo linear. Uma das formas de nomear as fases de um processo em cascata é: requisitos; projeto; implementação; teste e manutenção.

Cada uma das etapas nomeadas anteriormente gera produtos, que ao final do projeto comporão os entregáveis do projeto, sendo que o primeiro produto a ser produzido é o documento de Requisitos de Software. Com base nesses requisitos, serão elaborados os modelos arquiteturais da solução de software, que guiarão o desenvolvimento efetivo do software. Ao fim da implementação o software deve ser testado, e após o aceite do usuário será disponibilizado para produção.

Considerando o texto acima, assinale a alternativa correta.
Na fase de manutenção do modelo cascata, o objetivo é transformar os modelos elaborados em códigos de programas de computador. É neste momento que são aplicadas as diversas linguagens de programação.
Considerado o modelo cascata, a fase de requisitos do produto final costuma ser um documento de requisitos contendo todos os requisitos elicitados, analisados, especificados e validados.
Na fase de testes do modelo cascata, os testes do que foi produzido na fase de implementação são realizados. O objetivo é executar um programa com o objetivo de revelar a presença de defeitos. Aqui são realizados diversos tipos de teste exceto os testes unitários.
Na fase de implementação do modelo cascata todas as linguagens de programação adotadas pela organização são utilizadas juntas.
No modelo cascata, a fase de implementação é o momento de modelar o novo sistema, gerando várias representações ou modelos diferentes de soluções possíveis para o projeto. Isso pode ser feito por meio de três fases: arquitetura, detalhamento da arquitetura e testes.

Leia a situação hipotética abaixo:

Você trabalha no atendimento da área de TI e acaba de ser notificado sobre um problema no sistema mais importante da empresa. Já não é a primeira vez que esse sistema apresenta problemas, entretanto a última vez que isso aconteceu houve uma demora muito grande para a manutenção fosse realizada e disponibilizada para o usuário. Com isso, o usuário cobrava pela correção do problema, e você solicitava tais ajustes aos desenvolvedores, mas, no final, você percebeu que usuário e desenvolvedores atribuíram a demora a você.

Como Pfleeger (2004) afirma que a manutenibilidade é uma característica do sistema passível de ser medida pelo tempo médio gasto para a realização de reparos no sistema, você acredita ser possível demonstrar que a manutenibilidade deste sistema não está boa.

Considerando a situação apresentada, assinale a opção correta.
Pode-se dizer que se você registrar o momento em que o problema é relatado pelo usuário e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, você já tem algumas informações relevantes para medir a manutenibilidade de um sistema.
Quando há um problema em um software operacional (que está em produção) é importante registrar a ocorrência, sendo que, não se deve ter preocupação com o tempo que vai levar, a prioridade é o ajuste e a documentação do ajuste.
O tempo exigido para que a equipe de manutenção analise o problema e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, são as únicas informações necessárias para medir a manutenibilidade.
Quando há um problema em um software operacional (que está em produção), deve-se resolver o problema o quanto antes, pois uma vez realizada a manutenção e o problema solucionado, torna-se irrelevante documentar quais mudanças foram feitas.
O tempo perdido devido ao atraso de outros setores envolvidos na manutenção, o tempo exigido para que a equipe de manutenção analise o problema e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, são informações irrelevantes para medir a manutenibilidade.

Leia o texto a seguir:

Um profissional de Engenharia de Software em início de carreira foi designado para levantar requisitos em um projeto de grande porte. Dada a complexidade dos requisitos e a considerável quantidade de pessoas das quais poderiam ser coletados requisitos, aquele profissional resolveu programar reuniões entre grupos pequenos para que, juntos, pudessem descobrir as funções e restrições do futuro sistema. No entanto, após algumas sessões, ele percebeu que essa técnica de levantamento de requisitos não estava retornando bons resultados, já que, ao invés de expressarem suas necessidades, os futuros usuários permaneciam inibidos e calados na maior parte do tempo da reunião.

Considerando as informações apresentadas, assinale a alternativa correta.
O profissional deveria ter excluído conversas com os futuros usuários como forma de levantamento de requisitos. Ao invés disso, ele deveria ter considerado a análise de documentos para este fim.
Para superar o obstáculo da pouca expressividade dos futuros usuários, o profissional deveria ter colocado em prática a técnica de levantamento de requisitos via questionário, como forma de superar inibições.
A iniciativa de coletar requisitos junto aos futuros colaboradores é incorreta em sua origem, já que a ação indicada para o atingimento deste objetivo é a troca de e-mails e mensagens de celular com a empresa cliente.
O profissional deveria ter reunido todos os futuros usuários em uma única sessão e tê-los estimulado a expressarem suas necessidades em relação ao sistema de forma definitiva.
Ao perceber inibições ou pouco interesse em colaborar com o projeto por parte dos futuros usuários, o profissional deveria ter retornado a tarefa à organização em que trabalhava e se negado a prosseguir com aquele projeto.

Leia o texto abaixo:

O Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um documento criado sob o patrocínio da IEEE Computer Society e publicado pela mesma com a finalidade de servir de referência em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software. Por isso em seu conteúdo mais recente, o SWEBOK V3 publicado em 2014, foi sumarizado em 15 KAs (knowledge areas, em português, áreas de conhecimento) referentes a Engenharia de Software. Em sua 1ª versão publicada em 2004 haviam 10 KAs específicos a área citada anteriormente.

O SWEBOK surgiu através de uma parceria entre o IEEE, a Computer Society e ACM a fim de promover a profissionalização da Engenharia de Software e criar um consenso sobre as áreas de conhecimento da Engenharia de Software e seu escopo. Sendo iniciado em 1998 pelo Software Engineering Coordinating Committee (SWECC) e financiado por organizações como a ACM, a Boeing, o Conselho Canadense de Engenheiros Profissionais, Construx Software, MITRE Corporation, entre outras. O SWEBOK é recomendado para diversos tipos de público, em todo o mundo, com o objetivo de ajudar organizações a terem uma visão consistente da Engenharia de Software. É endereçado a gerentes, engenheiros de software, às sociedades profissionais, estudantes, professores e instrutores desta área de conhecimento.

O SWEBOK apresenta uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível mais alto são as Áreas do Conhecimento.

Fonte: https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge. Acesso: 09/03/2021.

Quando falamos sobre a área de conhecimento Requisitos de Software do SWEBOK, quais são seus processos em ordem de execução durante um projeto?
Especificação, Análise, Elicitação e Validação.
Análise, Elicitação, Especificação e Validação.
Elicitação, Análise, Especificação e Validação.
Elicitação, Especificação, Análise e Validação.
Especificação, Elicitação, Análise e Validação.

Material
páginas com resultados encontrados.
páginas com resultados encontrados.

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Escolha uma das opções e acesse esse e outros materiais sem bloqueio. 🤩

Cadastre-se ou realize login

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Questões resolvidas

Leia o texto a seguir:

Cada estágio é, por si só, um processo (ou coleção de processos) que pode ser descrito como conjunto de atividades. E cada atividade envolve restrições, resultados e recursos. Por exemplo, a análise e definição dos requisitos precisa ter como entrada inicial uma declaração das funções e características desejadas para o produto, expressas pelo usuário. O resultado final desse estágio é um conjunto de requisitos, mas pode haver produtos intermediários à medida que o diálogo entre o usuário e o desenvolvedor resulta em mudanças e alternativas.

Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall, 2004.

Considerando os princípios que fundamentam o processo tradicional e o processo ágil de software, mais as suas respectivas abordagens em relação à qualidade de seus produtos, avalie as seguintes asserções e a relação proposta entre elas.
I. O Modelo em Cascata vem se mostrando mais adequado às demandas menos urgentes de criação de software, posto que, embora suas etapas demandem tempo maior para cumprimento, o produto final obtido tem atingido qualidade superior ao produto similar construído sob o paradigma de desenvolvimento ágil.

# PORQUE

II. As metodologias ágeis de desenvolvimento, como o próprio nome sugere, estruturam suas etapas para que entreguem produtos intermediários o mais rapidamente possível, a fim de sanar necessidades específicas do cliente, o que acaba influenciando negativamente na qualidade do produto final.

A respeito dessas asserções, assinale a alternativa correta.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
As asserções I e II são ambas proposições falsas.

Leia o texto abaixo:

Pressman e Maxim (2016, p. 33), dizem que um fluxo de processos descreve, em relação a uma sequência e ao tempo, como são organizadas as ações e tarefas de cada atividade.

Existem vários tipos de fluxo de processos: o fluxo paralelo, onde as atividades acontecem simultaneamente, já no fluxo linear, as atividades são executadas uma após a outra, ou seja, é necessário que uma atividade acabe para que a próxima seja iniciada, por exemplo. Existem ainda os fluxos evolucionário e interativo.

O modelo cascata foi um dos tipos mais utilizado até os anos 2000 e é considerado um modelo linear. Uma das formas de nomear as fases de um processo em cascata é: requisitos; projeto; implementação; teste e manutenção.

Cada uma das etapas nomeadas anteriormente gera produtos, que ao final do projeto comporão os entregáveis do projeto, sendo que o primeiro produto a ser produzido é o documento de Requisitos de Software. Com base nesses requisitos, serão elaborados os modelos arquiteturais da solução de software, que guiarão o desenvolvimento efetivo do software. Ao fim da implementação o software deve ser testado, e após o aceite do usuário será disponibilizado para produção.

Considerando o texto acima, assinale a alternativa correta.
Na fase de manutenção do modelo cascata, o objetivo é transformar os modelos elaborados em códigos de programas de computador. É neste momento que são aplicadas as diversas linguagens de programação.
Considerado o modelo cascata, a fase de requisitos do produto final costuma ser um documento de requisitos contendo todos os requisitos elicitados, analisados, especificados e validados.
Na fase de testes do modelo cascata, os testes do que foi produzido na fase de implementação são realizados. O objetivo é executar um programa com o objetivo de revelar a presença de defeitos. Aqui são realizados diversos tipos de teste exceto os testes unitários.
Na fase de implementação do modelo cascata todas as linguagens de programação adotadas pela organização são utilizadas juntas.
No modelo cascata, a fase de implementação é o momento de modelar o novo sistema, gerando várias representações ou modelos diferentes de soluções possíveis para o projeto. Isso pode ser feito por meio de três fases: arquitetura, detalhamento da arquitetura e testes.

Leia a situação hipotética abaixo:

Você trabalha no atendimento da área de TI e acaba de ser notificado sobre um problema no sistema mais importante da empresa. Já não é a primeira vez que esse sistema apresenta problemas, entretanto a última vez que isso aconteceu houve uma demora muito grande para a manutenção fosse realizada e disponibilizada para o usuário. Com isso, o usuário cobrava pela correção do problema, e você solicitava tais ajustes aos desenvolvedores, mas, no final, você percebeu que usuário e desenvolvedores atribuíram a demora a você.

Como Pfleeger (2004) afirma que a manutenibilidade é uma característica do sistema passível de ser medida pelo tempo médio gasto para a realização de reparos no sistema, você acredita ser possível demonstrar que a manutenibilidade deste sistema não está boa.

Considerando a situação apresentada, assinale a opção correta.
Pode-se dizer que se você registrar o momento em que o problema é relatado pelo usuário e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, você já tem algumas informações relevantes para medir a manutenibilidade de um sistema.
Quando há um problema em um software operacional (que está em produção) é importante registrar a ocorrência, sendo que, não se deve ter preocupação com o tempo que vai levar, a prioridade é o ajuste e a documentação do ajuste.
O tempo exigido para que a equipe de manutenção analise o problema e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, são as únicas informações necessárias para medir a manutenibilidade.
Quando há um problema em um software operacional (que está em produção), deve-se resolver o problema o quanto antes, pois uma vez realizada a manutenção e o problema solucionado, torna-se irrelevante documentar quais mudanças foram feitas.
O tempo perdido devido ao atraso de outros setores envolvidos na manutenção, o tempo exigido para que a equipe de manutenção analise o problema e o tempo necessário para que essas mudanças sejam, de fato, efetivadas, são informações irrelevantes para medir a manutenibilidade.

Leia o texto a seguir:

Um profissional de Engenharia de Software em início de carreira foi designado para levantar requisitos em um projeto de grande porte. Dada a complexidade dos requisitos e a considerável quantidade de pessoas das quais poderiam ser coletados requisitos, aquele profissional resolveu programar reuniões entre grupos pequenos para que, juntos, pudessem descobrir as funções e restrições do futuro sistema. No entanto, após algumas sessões, ele percebeu que essa técnica de levantamento de requisitos não estava retornando bons resultados, já que, ao invés de expressarem suas necessidades, os futuros usuários permaneciam inibidos e calados na maior parte do tempo da reunião.

Considerando as informações apresentadas, assinale a alternativa correta.
O profissional deveria ter excluído conversas com os futuros usuários como forma de levantamento de requisitos. Ao invés disso, ele deveria ter considerado a análise de documentos para este fim.
Para superar o obstáculo da pouca expressividade dos futuros usuários, o profissional deveria ter colocado em prática a técnica de levantamento de requisitos via questionário, como forma de superar inibições.
A iniciativa de coletar requisitos junto aos futuros colaboradores é incorreta em sua origem, já que a ação indicada para o atingimento deste objetivo é a troca de e-mails e mensagens de celular com a empresa cliente.
O profissional deveria ter reunido todos os futuros usuários em uma única sessão e tê-los estimulado a expressarem suas necessidades em relação ao sistema de forma definitiva.
Ao perceber inibições ou pouco interesse em colaborar com o projeto por parte dos futuros usuários, o profissional deveria ter retornado a tarefa à organização em que trabalhava e se negado a prosseguir com aquele projeto.

Leia o texto abaixo:

O Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um documento criado sob o patrocínio da IEEE Computer Society e publicado pela mesma com a finalidade de servir de referência em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software. Por isso em seu conteúdo mais recente, o SWEBOK V3 publicado em 2014, foi sumarizado em 15 KAs (knowledge areas, em português, áreas de conhecimento) referentes a Engenharia de Software. Em sua 1ª versão publicada em 2004 haviam 10 KAs específicos a área citada anteriormente.

O SWEBOK surgiu através de uma parceria entre o IEEE, a Computer Society e ACM a fim de promover a profissionalização da Engenharia de Software e criar um consenso sobre as áreas de conhecimento da Engenharia de Software e seu escopo. Sendo iniciado em 1998 pelo Software Engineering Coordinating Committee (SWECC) e financiado por organizações como a ACM, a Boeing, o Conselho Canadense de Engenheiros Profissionais, Construx Software, MITRE Corporation, entre outras. O SWEBOK é recomendado para diversos tipos de público, em todo o mundo, com o objetivo de ajudar organizações a terem uma visão consistente da Engenharia de Software. É endereçado a gerentes, engenheiros de software, às sociedades profissionais, estudantes, professores e instrutores desta área de conhecimento.

O SWEBOK apresenta uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível mais alto são as Áreas do Conhecimento.

Fonte: https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge. Acesso: 09/03/2021.

Quando falamos sobre a área de conhecimento Requisitos de Software do SWEBOK, quais são seus processos em ordem de execução durante um projeto?
Especificação, Análise, Elicitação e Validação.
Análise, Elicitação, Especificação e Validação.
Elicitação, Análise, Especificação e Validação.
Elicitação, Especificação, Análise e Validação.
Especificação, Elicitação, Análise e Validação.

Prévia do material em texto

6/6/25 17:11Teste: AO2
Página 1 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
AO2
Iniciado: 6 jun em 16:40
Instruções do teste
 !
Pergunta 1 0,6 pts
Importante:
Caso você esteja realizando a atividade através do aplicativo "Canvas Student", é necessário que
você clique em "FAZER O QUESTIONÁRIO", no final da página.
6/6/25 17:11Teste: AO2
Página 2 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
Leia o texto a seguir:
 
Cada estágio é, por si só, um processo (ou coleção de processos) que pode ser descrito como
conjunto de atividades. E cada atividade envolve restrições, resultados e recursos. Por exemplo,
a análise e definição dos requisitos precisa ter como entrada inicial uma declaração das funções e
características desejadas para o produto, expressas pelo usuário. O resultado final desse estágio
é um conjunto de requisitos, mas pode haver produtos intermediários à medida que o diálogo
entre o usuário e o desenvolvedor resulta em mudanças e alternativas.
 
Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice
Hall, 2004.
Considerando os princípios que fundamentam o processo tradicional e o processo ágil de
software, mais as suas respectivas abordagens em relação à qualidade de seus produtos, avalie
as seguintes asserções e a relação proposta entre elas.
 
I. O Modelo em Cascata vem se mostrando mais adequado às demandas menos urgentes de
criação de software, posto que, embora suas etapas demandem tempo maior para cumprimento,
o produto final obtido tem atingido qualidade superior ao produto similar construído sob o
paradigma de desenvolvimento ágil.
 
PORQUE
 
II. As metodologias ágeis de desenvolvimento, como o próprio nome sugere, estruturam suas
etapas para que entreguem produtos intermediários o mais rapidamente possível, a fim de sanar
necessidades específicas do cliente, o que acaba influenciando negativamente na qualidade do
produto final.
 
A respeito dessas asserções, assinale a alternativa correta:
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
6/6/25 17:11Teste: AO2
Página 3 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 2 0,6 pts
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
As asserções I e II são ambas proposições falsas.
6/6/25 17:11Teste: AO2
Página 4 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
Leia o texto a seguir:
 
O desenvolvimento do sistema está completo quando ele pode ser considerado operacional, isto
é, quando o sistema está sendo utilizado pelos usuários em um ambiente real de produção.
Qualquer trabalho efetuado para modificar o sistema, depois que ele estiver em operação, é
considerado como manutenção.
 
Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice
Hall, 2004.
Considerando as motivações para sua aplicação e as características do processo de manutenção
de software, avalie as afirmações que seguem:
 
I. Por ser aplicada em um produto acabado, a manutenção não requer outro procedimento para
sua efetivação além do ajuste do código.
 
II. O processo de manutenção inclui a tomada de medidas preventivas para não seja necessária a
aplicação de novas manutenções futuras.
 
III. Um dos objetivos a serem atingidos por meio da aplicação da manutenção é a melhoria nas
funções já implementadas no sistema.
 
É correto o que se afirma em:
I e III, apenas.
I, II e III.
II e III, apenas.
III, apenas.
6/6/25 17:11Teste: AO2
Página 5 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 3 0,6 pts
II, apenas.
Leia o texto a seguir:
 
Quando se elabora um produto ou sistema, é importante seguir uma série de passos previsíveis –
um roteiro que ajude a criar um resultado de alta qualidade dentro do prazo estabelecido.
 
Fonte: PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem profissional. 8. ed.
Porto Alegre: AMGH, 2016.
Considerando os conceitos de Processos, Fases e Atividades e suas aplicações na Engenharia
de Software, avalie as afirmações que seguem:
 
I. Um processo de software corresponde a divisão de uma atividade e agrupa ações com um
objetivo comum.
 
II. É por meio da execução de uma atividade que a equipe poderá produzir artefatos
intermediários do produto final.
 
III. O fluxo dos processos caracteriza a organização das ações que se desenrolam em cada
atividade.
 
É correto o que se afirma em:
II e III apenas.
I e II apenas.
I, II e III.
6/6/25 17:11Teste: AO2
Página 6 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 4 0,6 pts
III apenas.
II apenas.
Leia o texto abaixo:
 
Pressman e Maxim (2016, p. 33), dizem que um fluxo de processos descreve, em relação a uma
sequência e ao tempo, como são organizadas as ações e tarefas de cada atividade.
Existem vários tipos de fluxo de processos: o fluxo paralelo, onde as atividades acontecem
simultaneamente, já no fluxo linear, as atividades são executadas uma após a outra, ou seja, é
necessário que uma atividade acabe para que a próxima seja iniciada, por exemplo. Existem
ainda os fluxos evolucionário e interativo.
O modelo cascata foi um dos tipos mais utilizado até os anos 2000 e é considerado um modelo
linear. Uma das formas de nomear as fases de um processo em cascata é: requisitos; projeto;
implementação; teste e manutenção.
Cada uma das etapas nomeadas anteriormente gera produtos, que ao final do projeto comporão
os entregáveis do projeto, sendo que o primeiro produto a ser produzido é o documento de
Requisitos de Software. Com base nesses requisitos, serão elaborados os modelos arquiteturais
da solução de software, que guiarão o desenvolvimento efetivo do software. Ao fim da
implementação o software deve ser testado, e após o aceite do usuário será disponibilizado para
produção.
Considerando o texto acima, assinale a alternativa correta.
Na fase de manutenção do modelo cascata, o objetivo é transformar os modelos elaborados em códigos de
programas de computador. É neste momento que são aplicadas as diversas linguagens de programação.
Considerado o modelo cascata, a fase de requisitos do produto final costuma ser um documento de requisitos
contendo todos os requisitos elicitados, analisados, especificados e validados.
6/6/25 17:11Teste: AO2
Página 7 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 5 0,6 pts
Na fase de testes do modelo cascata, os testes do que foi produzido na fase de implementação são realizados.
O objetivo é executar um programa com o objetivo de revelar a presença de defeitos. Aqui são realizados
diversos tipos de teste exceto os testes unitários.
Na fase de implementação do modelo cascata todas as linguagens de programação adotadas pela organização
são utilizadas juntas.
No modelo cascata, a fase de implementação é o momento de modelar o novo sistema, gerando várias
representações ou modelos diferentes de soluções possíveis para o projeto. Isso pode ser feito por meio de três
fases: arquitetura, detalhamento da arquitetura e testes.
Leia a situação hipotética abaixo:
 
Você trabalha no atendimento da área de TI e acaba de ser notificado sobre um problema no
sistema mais importante da empresa. Já não é a primeira vez que esse sistema apresenta
problemas, entretanto a última vez que isso aconteceu houve uma demora muito grande para que
a manutenção fosse realizada e disponibilizada para o usuário. Com isso, o usuário cobrava pela
correção do problema, e você solicitava tais ajustes aos desenvolvedores, mas, no final, você
percebeu que usuário e desenvolvedores atribuíram a demora a você.
Como Pfleeger (2004) afirma que a manutenibilidade é uma característica do sistema passívelde
ser medida pelo tempo médio gasto para a realização de reparos no sistema, você acredita ser
possível demonstrar que a manutenibilidade deste sistema não está boa.
Considerando a situação apresentada, assinale a opção correta.
Pode-se dizer que se você registrar o momento em que o problema é relatado pelo usuário e o tempo
necessário para que essas mudanças sejam, de fato, efetivadas, você já tem algumas informações relevantes
para medir a manutenibilidade de um sistema.
Quando há um problema em um software operacional (que está em produção) é importante registrar a
ocorrência, sendo que, não se deve ter preocupação com o tempo que vai levar, a prioridade é o ajuste e a
documentação do ajuste.
A+
A
A-
6/6/25 17:11Teste: AO2
Página 8 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 6 0,6 pts
 !
Pergunta 7 0,6 pts
O tempo exigido para que a equipe de manutenção analise o problema e o tempo necessário para que essas
mudanças sejam, de fato, efetivadas, são as únicas informações necessárias para medir a manutenibilidade.
Quando há um problema em um software operacional (que está em produção), deve-se resolver o problema o
quanto antes, pois uma vez realizada a manutenção e o problema solucionado, torna-se irrelevante documentar
quais mudanças foram feitas.
O tempo perdido devido ao atraso de outros setores envolvidos na manutenção, o tempo exigido para que a
equipe de manutenção analise o problema e o tempo necessário para que essas mudanças sejam, de fato,
efetivadas, são informações irrelevantes para medir a manutenibilidade.
Leia o texto a seguir:
 
Uma equipe de teste deparou-se com a necessidade de realizar o procedimento em uma unidade
do sistema e, como primeiro passo, prepararam a ferramenta de teste de unidade e submeteram
o código a ela. No entanto, verificaram que a unidade dependia de dados de entrada para seu
funcionamento.
Considerando as informações apresentadas, assinale a opção correta.
 
A equipe deveria ter solicitado outra unidade aos desenvolvedores, a fim de fazerem o teste em conjunto.
A equipe deveria ter testado o programa completo, ao invés de submeter uma única unidade ao teste.
A equipe deveria ter providenciado um stub para sanar a necessidade de dados de entrada para a unidade.
A equipe deveria ter rejeitado a unidade, já que ela dependia de dados de entrada para ser testada.
A equipe deveria proposto aos projetistas a revisão da unidade, por ela estar claramente com baixa coesão.
6/6/25 17:11Teste: AO2
Página 9 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
Leia o texto a seguir:
 
Os testes de software são uma função de controle de qualidade com um objetivo principal [...]. O
papel da SQA é o de garantir que os testes sejam planejados apropriadamente e conduzidos
eficientemente de modo que se tenha a maior probabilidade possível de alcançar seu objetivo
primário.
 
Fonte: PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem profissional. 8. ed.
Porto Alegre: AMGH, 2016.
Considerando o objetivo da aplicação dos testes, avalie as seguintes asserções e a relação
proposta entre elas.
 
I. O objetivo a ser alcançado em um procedimento de teste é o de encontrar defeitos no
programa.
 
PORQUE
 
II. Um teste que não retorna defeitos no programa indica que este programa está livre de defeitos.
 
A respeito dessas asserções, assinale a opção correta:
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
As asserções I e II são ambas proposições falsas.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
6/6/25 17:11Teste: AO2
Página 10 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 8 0,6 pts
 !
Pergunta 9 0,6 pts
Leia o texto a seguir:
 
Um profissional de Engenharia de Software em início de carreira foi designado para levantar
requisitos em um projeto de grande porte. Dada a complexidade dos requisitos e a considerável
quantidade de pessoas das quais poderiam ser coletados requisitos, aquele profissional resolveu
programar reuniões entre grupos pequenos para que, juntos, pudessem descobrir as funções e
restrições do futuro sistema. No entanto, após algumas sessões, ele percebeu que essa técnica
de levantamento de requisitos não estava retornando bons resultados, já que, ao invés de
expressarem suas necessidades, os futuros usuários permaneciam inibidos e calados na maior
parte do tempo da reunião.
Considerando as informações apresentadas, assinale a alternativa correta.
O profissional deveria ter excluído conversas com os futuros usuários como forma de levantamento de
requisitos. Ao invés disso, ele deveria ter considerado a análise de documentos para este fim.
Para superar o obstáculo da pouca expressividade dos futuros usuários, o profissional deveria ter colocado em
prática a técnica de levantamento de requisitos via questionário, como forma de superar inibições.
A iniciativa de coletar requisitos junto aos futuros colaboradores é incorreta em sua origem, já que a ação
indicada para o atingimento deste objetivo é a troca de e-mails e mensagens de celular com a empresa cliente.
O profissional deveria ter reunido todos os futuros usuários em uma única sessão e tê-los estimulado a
expressarem suas necessidades em relação ao sistema de forma definitiva.
Ao perceber inibições ou pouco interesse em colaborar com o projeto por parte dos futuros usuários, o
profissional deveria ter retornado a tarefa à organização em que trabalhava e se negado a prosseguir com
aquele projeto.
6/6/25 17:11Teste: AO2
Página 11 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
Leia o texto abaixo:
 
O Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um
documento criado sob o patrocínio da IEEE Computer Society e publicado pela mesma com a
finalidade de servir de referência em assuntos considerados, de forma generalizada pela
comunidade, como pertinentes a área de Engenharia de Software. Por isso em seu conteúdo
mais recente, o SWEBOK V3 publicado em 2014, foi sumarizado em 15 KAs (knowledge areas,
em português, áreas de conhecimento) referentes a Engenharia de Software. Em sua 1ª versão
publicada em 2004 haviam 10 KAs específicos a área citada anteriormente.
O SWEBOK surgiu através de uma parceria entre o IEEE, a Computer Society e ACM a fim de
promover a profissionalização da Engenharia de Software
(https://pt.wikipedia.org/wiki/Engenharia_de_software) e criar um consenso sobre as áreas de
conhecimento da Engenharia de Software e seu escopo. Sendo iniciado em 1998 pelo Software
Engineering Coordinating Committee (SWECC) e financiado por organizações como a ACM, a
Boeing, o Conselho Canadense de Engenheiros Profissionais, Construx Software, MITRE
Corporation, entre outras. O SWEBOK é recomendado para diversos tipos de público, em todo o
mundo, com o objetivo de ajudar organizações a terem uma visão consistente da Engenharia de
Software. É endereçado a gerentes, engenheiros de software, às sociedades profissionais,
estudantes, professores e instrutores desta área de conhecimento.
O SWEBOK apresenta uma classificação hierárquica dos tópicos tratados pela Engenharia de
Software (https://pt.wikipedia.org/wiki/Engenharia_de_Software) , onde o nível mais alto são
as Áreas do Conhecimento.
Fonte: https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge
(https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge) . Acesso: 09/03/2021.
Quando falamos sobre a área de conhecimento Requisitos de Software do SWEBOK, quais são
seus processos em ordem de execução durante um projeto?
Especificação, Análise, Elicitação e Validação.
Análise, Elicitação, Especificação e Validação.
Elicitação, Análise, Especificação e Validação.
https://pt.wikipedia.org/wiki/Engenharia_de_softwarehttps://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Engenharia_de_Software
https://pt.wikipedia.org/wiki/Engenharia_de_Software
https://pt.wikipedia.org/wiki/Engenharia_de_Software
https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge
https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge
https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge
6/6/25 17:11Teste: AO2
Página 12 de 12https://famonline.instructure.com/courses/44698/quizzes/215109/take
 !
Pergunta 10 0,6 pts
Salvo em 17:10 
Elicitação, Especificação, Análise e Validação.
Especificação, Elicitação, Análise e Validação.
Leia o texto a seguir:
 
Em um passado não tão remoto, época em que os processos de software mais largamente
utilizados eram baseados no modelo tradicional, sua função era específica e sua atuação se dava
em apenas uma fase do projeto de criação do software. Com a chegada das metodologias ágeis,
seu papel ganhou mais relevância e sua atuação se estende em várias etapas do processo, do
tratamento dos requisitos até a entrega do produto.
Assinale a alternativa que contém a função que condiz com a descrição feita no texto fornecido.
 
Gerente do projeto.
Cleaner.
Desenvolvedor.
Testador.
Coach.
Enviar teste

Mais conteúdos dessa disciplina