Logo Passei Direto
Buscar

AO2 - Engenharia de Software - NOTA 6.0 de 6.0

Ferramentas de estudo

Questões resolvidas

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.
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.
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.
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.
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.
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.

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

Questões resolvidas

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.
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.
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.
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.
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.
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.

Prévia do material em texto

AO2
Iniciado: 21 fev em 10:21
Instruções do teste

Pergunta 1 0,6 pts

Pergunta 2 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.
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 proposto aos projetistas a revisão da unidade, por ela estar claramente com baixa coesão.
A equipe deveria ter rejeitado a unidade, já que ela dependia de dados de entrada para ser testada.
A equipe deveria ter testado o programa completo, ao invés de submeter uma única unidade ao teste.
A equipe deveria ter solicitado outra unidade aos desenvolvedores, a fim de fazerem o teste em conjunto.
A equipe deveria ter providenciado um stub para sanar a necessidade de dados de entrada para a unidade.
Leia o texto a seguir:
Manifesto para Desenvolvimento Ágil de Software
Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o nós mesmos e
ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: indivíduos e
interações, mais que processos e ferramentas; software em funcionamento, mais que documentação
abrangente; colaboração com o cliente, mais que negociação de contratos; responder a
A+
A
A-
NOTA: 6.0 de 6.0

Pergunta 3 0,6 pts
mudanças, mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
(Fonte: Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html
(https://agilemanifesto.org/iso/ptbr/manifesto.html) . Acesso em: 09 mar. 2021)(adaptado).
Quando pensamos em método ágil para condução de projetos, um dos mais utilizados é o SCRUM.
E quando falamos de Backlog da Sipint, imediatamente, pensamos na
reunião realizada ao fim da sprint para validação do incremento que foi gerado ao longo da sprint.
lista de tarefas que a equipe de desenvolvimento deverá realizar para entregar um novo incremento.
lista de funcionalidades desejadas para o projeto que será desenvolvido, com a utilização do método SCRUM.
reunião diária que acontece, onde são discutidos o que foi feito e o que será realizado, e quais os impedimentos.
reunião realizada ao fim da sprint para avaliar seu desempenho e o que pode ser melhorado.
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.
A+
A
A-
https://agilemanifesto.org/iso/ptbr/manifesto.html
https://pt.wikipedia.org/wiki/Engenharia_de_software

Pergunta 4 0,6 pts
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?
Elicitação, Especificação, Análise e Validação.
Especificação, Elicitação, Análise e Validação.
Especificação, Análise, Elicitação e Validação.
Elicitação, Análise, Especificação e Validação.
Análise, Elicitação, Especificação e Validação.
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.
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.
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.
A+
A
A-
https://pt.wikipedia.org/wiki/Engenharia_de_Software
https://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge

Pergunta 5 0,6 pts
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.
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.
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.
Leia o texto a seguir:
 
Os pesquisadores procuram melhores meios de medir a manutenibilidade, com base nas
informações sobre os produtos; eles estão desenvolvendo novos modelos para nos mostrar as
interconexões entre produtos, processos e recursos. De maneira semelhante, os modelos nos
ajudarão a saber quanto esforço é necessário para manter um sistema, e quando é apropriado
descartar ou rejuvenescer um sistema legado.
 
Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall,
2004.
Considerando a abordagem das organizações em relação a seus sistemas legados, avalie as
seguintes asserções e a relação proposta entre elas.
 
I. As organizações que contam com sistemas legados normalmente optam por continuar com eles
por grandes períodos.
 
PORQUE
 
II. Os processos estruturados em sistema legado são difíceis de modelar em um sistema mais novo,
mesmo com aplicações de técnicas de requisitos e projeto.
 
A respeito dessas asserções, assinale a alternativa correta:
As asserções I e II são ambas proposições falsas.A+
A
A-

Pergunta 6 0,6 pts
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 proposições verdadeiras, e a II é uma justificativa da I.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
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.
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.
A+
A
A-

Pergunta 7 0,6 pts
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.
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:
II e III, apenas.
II, apenas.
III, apenas.
A+
A
A-

Pergunta 8 0,6 pts

Pergunta 9 0,6 pts
I, II e III.
I e III, apenas.
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.
 
Desenvolvedor.
Gerente do projeto.
Testador.
Cleaner.
Coach.
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;
A+
A
A-

Pergunta 10 0,6 pts
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 implementação do modelo cascata todas as linguagens de programação adotadas pela organização
são utilizadas juntas.
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.
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.
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 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.
Leia o texto a seguir:
 
Algumas partes do processo de identificação, definição e gerenciamento de requisitos estão
envolvidas em quase todas essas causas de fracasso de projetos. A falta de cuidado com o
entendimento, a documentação e o gerenciamento dos requisitos podem levar a uma grande
quantidade de problemas: a construção de um sistema que resolve o problema errado, que não
funciona como esperado, ou que é difícil para os usuários entenderem e utilizarem.
 
Fonte: PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: Prentice Hall,
2004. Adaptado.
Considerando as atividades próprias da etapa de análise de requisitos, avalie as afirmações que
seguem:
A+
A
A-
Salvo em 11:23 
I. É durante esta etapa que os requisitos são classificados entre os que deverão se tornar restrições
e os que se tornarão funções do futuro sistema.
II. Como a etapa de análise dos requisitos ocorre antes da elicitação, a equipe terá durante aquela a
chance de aumentar o entendimento do problema.
III. Um dos resultados obtidos durante a análise é a determinação do grau de prioridade do requisito,
ocasião em que o cliente terá participação decisiva.
É correto o que se afirma em:
III, apenas.
I e III, apenas.
II, apenas.
I, apenas.
I, II e III.
Enviar teste
A+
A
A-

Mais conteúdos dessa disciplina