Grátis: A engenharia é um processo fundamental que requer uma abordagem bem definida, envolvendo atividades-chave que permitem uma integração eficaz entre ... – Questões Respondidas

Matemática

Outros

A engenharia é um processo fundamental que requer uma abordagem bem definida, envolvendo atividades-chave que permitem uma integração eficaz entre a equipe de desenvolvimento de software e as partes interessadas. O processo de engenharia de requisitos é essencial para garantir o sucesso de um projeto de software. Ele começa com a identificação e a compreensão das necessidades e expectativas dos usuários e stakeholders. Isso envolve a coleta de requisitos de forma detalhada e precisa, por meio de entrevistas, questionários, workshops, entre outras técnicas.
Com base no texto apresentado e nos conteúdos relacionados ao tema, pode-se dizer que a Engenharia de Requisitos é o processo que envolve:
A A fase final de teste antes da implantação de um sistema.
B Elicitação, análise, especificação e validação de requisitos.
C Projetar e desenvolver software.
D Manutenção contínua do software após sua implantação.
E A fase inicial no desenvolvimento de software.

Matematicamente

há 3 semanas

Matematicamente

há 3 semanas

Avaliação I - Individual

UNIASSELVI

Respostas

Ed

há 3 semanas

A Engenharia de Requisitos é o processo que envolve a elicitação (coleta), análise, especificação e validação dos requisitos do sistema, garantindo que as necessidades dos usuários e stakeholders sejam compreendidas e documentadas corretamente. Analisando as alternativas: A) Fase final de teste antes da implantação — não corresponde à Engenharia de Requisitos, mas sim à fase de testes. B) Elicitação, análise, especificação e validação de requisitos — está correta, pois descreve as atividades principais da Engenharia de Requisitos. C) Projetar e desenvolver software — refere-se às fases de design e implementação, não à Engenharia de Requisitos. D) Manutenção contínua do software após implantação — é a fase de manutenção, não Engenharia de Requisitos. E) Fase inicial no desenvolvimento de software — é muito genérico e não especifica as atividades da Engenharia de Requisitos. Portanto, a alternativa correta é: B) Elicitação, análise, especificação e validação de requisitos.

Essa resposta te ajudou?

0

0

Libere essa resposta sem enrolação!

Craque Neto

Craque Neto

Cadastre-se ou realize login

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

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Avaliação I - Individual

UNIASSELVI

Mais perguntas desse material

O Design Thinking é uma poderosa abordagem centrada no ser humano que busca resolver problemas de maneira criativa e inovadora. É um processo iterativo e dinâmico que coloca a empatia, a colaboração e a experimentação em destaque. Essa abordagem coloca as necessidades e desejos dos usuários no centro do processo de design, permitindo uma compreensão profunda de suas experiências e pontos de vista. A empatia é a base para a criação de soluções que atendam verdadeiramente às suas demandas.
Os pilares do Design Thinking são fundamentais na elicitação de requisitos. Com base nestes pilares, analise as afirmativas a seguir:

I. A criatividade ajuda a manter a inspiração gerando formas ousadas de executar o projeto e implementar o código mesmo que não alinhado aos requisitos.

II. A inspiração consiste em um entendimento inicial do problema, fazendo com que a equipe de desenvolvimento esteja atenta e disposta a mergulhar nas possibilidades envolvidas.

III. A experimentação é o aprendizado com erros, onde estes erros são aceitáveis (por serem inevitáveis), pois geram conhecimento e são aprimorados continuamente.

IV. A empatia trata de se conectar com o outro, com as partes interessadas, buscando propor uma solução técnica que não foi evidenciada durante a elicitação de requisitos apenas para evitar desapontamentos.

É correto o que se afirma em:
I. A criatividade ajuda a manter a inspiração gerando formas ousadas de executar o projeto e implementar o código mesmo que não alinhado aos requisitos.
II. A inspiração consiste em um entendimento inicial do problema, fazendo com que a equipe de desenvolvimento esteja atenta e disposta a mergulhar nas possibilidades envolvidas.
III. A experimentação é o aprendizado com erros, onde estes erros são aceitáveis (por serem inevitáveis), pois geram conhecimento e são aprimorados continuamente.
IV. A empatia trata de se conectar com o outro, com as partes interessadas, buscando propor uma solução técnica que não foi evidenciada durante a elicitação de requisitos apenas para evitar desapontamentos.
A I, II e III, apenas.
B III e IV, apenas.
C I e II, apenas.
D II e III, apenas.
E IV, apenas.

O risco de negócios é uma realidade inerente a qualquer organização e refere-se à possibilidade de ocorrerem eventos ou circunstâncias que podem afetar negativamente seus objetivos e resultados. Esses riscos podem surgir de diversas fontes, como incertezas econômicas, mudanças no mercado, falhas operacionais, eventos imprevistos ou falta de conformidade com regulamentações.
Gerenciar requisitos também envolve riscos, principalmente os de negócio. Conforme Pressman e Maxim, (2016), quanto aos cinco principais riscos de negócios, analise as afirmativas a seguir:

I. Um risco de orçamento é aquele refletido no alto tempo para se desenvolver um projeto de software cujos requisitos não estão bem definidos.

II. Um risco gerencial pode se caracterizar quando a parte interessada (Stakeholder) responsável por aprovar mudanças de requisitos já não possui alinhamento e harmonia com os demais integrantes da área negocial.

III. Um risco estratégico é refletido num software que não entrega valor de acordo com a estratégia de negócios global da empresa.

IV. Um risco de mercado pode se caracterizar num sistema que atende aos requisitos coletados e aos interesses da empresa, gerando grande aceitação.

É correto o que se afirma em:
I. Um risco de orçamento é aquele refletido no alto tempo para se desenvolver um projeto de software cujos requisitos não estão bem definidos.
II. Um risco gerencial pode se caracterizar quando a parte interessada (Stakeholder) responsável por aprovar mudanças de requisitos já não possui alinhamento e harmonia com os demais integrantes da área negocial.
III. Um risco estratégico é refletido num software que não entrega valor de acordo com a estratégia de negócios global da empresa.
IV. Um risco de mercado pode se caracterizar num sistema que atende aos requisitos coletados e aos interesses da empresa, gerando grande aceitação.
A I, apenas.
B I e II, apenas.
C III, apenas.
D I e IV, apenas.
E I, II e III.

As partes interessadas em um projeto de software desempenham um papel fundamental em sua concepção e sucesso. Essas partes podem incluir clientes, usuários finais, gerentes de projeto, desenvolvedores, analistas de negócios e especialistas em domínio. Cada uma dessas partes interessadas traz perspectivas únicas e objetivos específicos para o projeto.
Dada a importância das partes interessadas (Stakeholders) num projeto de software, analise as afirmativas a seguir:

I. As partes interessadas (Stakeholders) devem ser envolvidas de forma plena para aumentar as chances de sucesso em projetos de software.

II. A importância de validar e verificar os requisitos coletados existe, podendo aumentar ainda mais o envolvimento das partes interessadas (Stakeholders).

III. A garantia de clareza e qualidade dos requisitos depende de uma comunicação constante entre a equipe de desenvolvimento de software e as partes interessadas (Stakeholders).

IV. As partes interessadas (Stakeholders), muitas vezes, não fornecem detalhes óbvios para fazer parte do seu dia a dia de trabalho, mas que são de fundamental importância para o Engenheiro de Requisitos.

É correto o que se afirma em:
I. As partes interessadas (Stakeholders) devem ser envolvidas de forma plena para aumentar as chances de sucesso em projetos de software.
II. A importância de validar e verificar os requisitos coletados existe, podendo aumentar ainda mais o envolvimento das partes interessadas (Stakeholders).
III. A garantia de clareza e qualidade dos requisitos depende de uma comunicação constante entre a equipe de desenvolvimento de software e as partes interessadas (Stakeholders).
IV. As partes interessadas (Stakeholders), muitas vezes, não fornecem detalhes óbvios para fazer parte do seu dia a dia de trabalho, mas que são de fundamental importância para o Engenheiro de Requisitos.
A I, II, III e IV.
B II e IV, apenas.
C I, II e III, apenas.
D I e II, apenas.
E III e IV, apenas.

Design Thinking é uma metodologia de desenvolvimento de produtos e serviços focados nas necessidades, desejos e limitações dos usuários. O grande objetivo do Design Thinking é converter dificuldades e limitações em benefícios para o cliente e valor de negócio para a sua empresa.
A partir do texto-base e dos conhecimentos sobre Design Thinking, analise as afirmativas a seguir:

I. O pilar inicial do Design Thinking é a inspiração, uma fase que contempla um entendimento inicial do problema e estudo das possibilidades envolvidas.

II. O Design Thinking é uma forma de projetar objetos renderizados, utilizando recursos computacionais, para observar sua alocação no espaço físico de uma empresa.

III. O Design Thinking inspira-se na habilidade humana de identificar padrões, ser intuitivo, gerar conceitos com um significado emocional para além da funcionalidade, e expressar ideias por meio de formatos distintos dos tradicionais símbolos e palavras.

É correto o que se afirma em:
I. O pilar inicial do Design Thinking é a inspiração, uma fase que contempla um entendimento inicial do problema e estudo das possibilidades envolvidas.
II. O Design Thinking é uma forma de projetar objetos renderizados, utilizando recursos computacionais, para observar sua alocação no espaço físico de uma empresa.
III. O Design Thinking inspira-se na habilidade humana de identificar padrões, ser intuitivo, gerar conceitos com um significado emocional para além da funcionalidade, e expressar ideias por meio de formatos distintos dos tradicionais símbolos e palavras.
A II e III, apenas.
B I, apenas.
C I e III, apenas.
D II, apenas.
E III, apenas.

Os modelos tradicionais, também denominados modelos pesados de processos de desenvolvimento de software, adotam uma abordagem sequencial, em que todas as fases do processo ocorrem em uma única etapa. Os modelos tradicionais de desenvolvimento de software são caracterizados por sua natureza linear e sequencial, onde cada fase do processo é realizada em uma ordem fixa e sem a possibilidade de retroceder para etapas anteriores. Isso significa que, uma vez concluída uma fase, não há espaço para revisitar ou reavaliar decisões tomadas anteriormente.
Com base no texto e os conhecimentos sobre os principais modelos de desenvolvimento de software, qual é o principal modelo pesado, também conhecido como ciclo de vida clássico?
A Modelo Ágil.
B Modelo Iterativo e Incremental.
C Modelo Espiral.
D Modelo Cascata.
E Extreme Programming.

O gerenciamento de requisitos é uma atividade essencial durante o ciclo de vida de um projeto de software. Consiste em identificar, documentar, analisar, priorizar e controlar os requisitos do sistema, garantindo que eles sejam compreendidos e atendidos adequadamente. No entanto, é importante reconhecer que os requisitos podem mudar ao longo do tempo devido a diversos fatores, como mudanças nas necessidades dos usuários, evolução do mercado ou avanços tecnológicos.
O processo de gerenciamento de mudanças de requisitos é responsável por lidar com essas alterações, e envolve os seguintes processos no gerenciamento de requisitos:

I. Desenvolver um projeto à parte com o único objetivo de atender às mudanças.

II. Mapear os melhores desenvolvedores e implementar as mudanças antes da validação dos requisitos.

III. Identificar quem será consultado e quem será apenas comunicado quanto às mudanças dos requisitos.

IV. Identificar quem são as partes interessadas (Stakeholders) que têm o poder de propor e aprovar as mudanças.

É correto o que se afirma em:
I. Desenvolver um projeto à parte com o único objetivo de atender às mudanças.
II. Mapear os melhores desenvolvedores e implementar as mudanças antes da validação dos requisitos.
III. Identificar quem será consultado e quem será apenas comunicado quanto às mudanças dos requisitos.
IV. Identificar quem são as partes interessadas (Stakeholders) que têm o poder de propor e aprovar as mudanças.
A IV, apenas.
B I, apenas.
C I, II e III, apenas.
D II e IV, apenas.
E III e IV, apenas.

A identificação e a mitigação precoce de falhas de requisitos são fundamentais para garantir o sucesso de um projeto de software, reduzindo riscos e aumentando a satisfação do cliente. Detectar e corrigir falhas nos requisitos logo no início do processo de desenvolvimento é crucial para evitar problemas que possam surgir nas fases posteriores do projeto. Quando os requisitos não são bem compreendidos, ou quando há ambiguidades ou inconsistências, podem ocorrer retrabalhos dispendiosos e atrasos significativos.
As falhas nos processo de engenharia de requisitos podem ocasionar diversos problemas na entrega e no uso de um software. Assinale a alternativa correta que caracteriza uma falha de requisitos refletida no software:
A Em um software de uma loja de varejo, na opção carrinho de compras, o cliente só consegue efetuar a compra de um único item de um produto por vez, não permitindo a inclusão de dois ou mais itens caso ele deseje uma quantidade maior do produto.
B Em um software de cadastro de usuários de uma empresa de transporte rodoviário de pessoas (ônibus), há a opção de selecionar o assento indicando se é corredor ou janela.
C Em um software de controle de frequência de alunos há a opção de registrar “presença”, “falta” ou “falta justificada”, sendo que é necessário um mínimo de 70% de comparecimento como critério de aprovação, cujo cálculo desconsidera o computo das faltas justificadas.
D Em um software de uma grande rede de hospitais há a opção para que o registro do paciente conste, de maneira opcional, uma pessoa de contato em caso de notificações e avisos sobre seu estado de saúde.
E Em um software de carro por aplicativo, há a opção de selecionar o carro.

O modelo incremental é uma abordagem de desenvolvimento de software que divide o projeto em incrementos ou partes menores. Cada incremento é planejado, projetado, desenvolvido, testado e implantado independentemente, adicionando funcionalidades ou aprimorando o sistema gradualmente.
Com base no excerto, qual das seguintes opções descreve corretamente o modelo incremental de desenvolvimento de software?
A O modelo incremental envolve a entrega de todo o software de uma só vez, após um longo período de desenvolvimento, onde uma etapa só começa após o término da outra, como ocorre num grande sistema para gestão financeira de uma multinacional.
B O modelo incremental divide o projeto em partes menores, entregando funcionalidades utilizáveis em incrementos sucessivos, visando uma entrega mais rápida ao cliente e permitindo maior flexibilidade nos ajustes decorrentes de mudanças.
C No modelo incremental, o software é desenvolvido de forma sequencial, sem a possibilidade de ajustes ou melhorias ao longo do processo, sendo um exemplo claro a aplicação desse modelo em softwares do tipo ERP (recursos empresariais), onde se entrega projeto para uma área ou setor por vez.
D O modelo incremental é realizado em uma única fase, e o sistema completo é entregue no final do projeto.
E No modelo incremental, o feedback dos usuários não é considerado, uma vez que o software é desenvolvido em etapas separadas.

BPMN (Business Process Model and Notation) é uma notação gráfica padrão que foi desenvolvida para representar processos de negócios de forma clara e compreensível. É uma linguagem visual que permite aos analistas de negócios, engenheiros de software e outras partes interessadas descrever, modelar, analisar e documentar processos de negócios de uma maneira padronizada.
Com base no texto, os principais elementos de BPMN, entre outros, são:
I. Raias.
II. Atividades.
III. Conectores.
A I e II, apenas.
B I, apenas.
C II, apenas.
D III, apenas.
E I, II e III.