AO2 - Engenharia de Software NOTA 4.8
Pergunta 1
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 eACM a fim de promover a profissionalização da Engenharia
de Software
e criar um consenso sobreas á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.
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, Elicitação, Análise e Validação.
Elicitação, Especificação, Análise e Validação.
Análise,
Elicitação, Especificação e Validação.
Especificação, Análise, Elicitação e Validação.
Elicitação, Análise, Especificação e Validação.
Pergunta 2
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.
Testador.
Coach.
Desenvolvedor.
Cleaner.
Pergunta 3
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:
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 e
licitaçã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:
I, apenas.
II, apenas.
I e
III, apenas.
I, II e III.
III, apenas.
Pergunta 4
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.
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.
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.
Pergunta 5
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.
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-mail se mensagens de celular com a
empresa cliente.
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.
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.
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.
Pergunta 6
As asserções I e II são proposições verdadeiras, e a II é
uma justificativa da I.
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.
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.
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.
Pergunta 7
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 asserção
I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são as 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 as proposições verdadeiras, e a II é
uma justificativa da I.
Pergunta 8
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:
I, II e III.
II apenas.
I e II apenas.
II e
III apenas.
III apenas.
Pergunta 9
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.
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.
Pergunta 10
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í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.
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.
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), 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.
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 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 as únicas informações necessárias para medir a
manutenibilidade.