Nome do software + Problema a ser resolvido + Solução 
dada pelo padrão + Tempo de desenvolvimento

Nome do padrão + Problema a ser resolvido + Solução 
dada pelo padrão + Consequências

Nome do software + Problema a ser resolvido + 
Planejamento das atividades + Consequências

Nome do padrão + Problema a ser resolvido 
+ Planejamento das atividades + Tempo de 
desenvolvimento

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 O conceito de padrões de projetos em Engenharia de Software é fundamental para a criação de soluções robustas, reutilizáveis e eficientes em desenvolvimento de software. O entendimento sobre o que constitui um padrão de projeto é crítico não só para aplicá-los corretamente, mas também para avaliar seus impactos e aplicações em contextos reais.
 

 Um padrão de projeto, conforme definido por autores clássicos como Gamma et al. no seu famoso livro "Design Patterns: Elements of Reusable Object-Oriented Software", é formado por quatro componentes essenciais:
 

 <ul>
 <li>
 Nome do padrão: Facilita a discussão, documentação e até mesmo o ensino sobre o padrão. É uma referência curta e precisa que identifica o padrão entre os desenvolvedores.
 </li>
 
 
 <li>
 Problema: Descreve as circunstâncias e condições sob as quais o padrão pode ser aplicado, incluindo problemas específicos que ele se propõe a resolver.
 </li>
 

 <li>
 Solução: Não uma receita exata, mas uma descrição abstrata da estrutura de design necessária para resolver tal problema. Aborda as relações entre classes e objetos envolvidos no padrão.
 </li>
 

 <li>
 Consequências: Resultados e efeitos secundários da aplicação do padrão, incluindo trade-offs. A compreensão das consequências ajuda na decisão de aplicação do padrão e na compreensão dos benefícios e compromissos envolvidos.
 </li>
 
 </ul>
 

 Considerando as opções proporcionadas pela questão e utilizando o conhecimento dos elementos constitutivos dos Design Patterns, uma análise das alternativas mostra que:
 

 <ul>
 <li>A) Errada, porque inclui "Nome do software" e "Tempo de desenvolvimento", que não são elementos básicos de padrões de projeto.</li>
 
 <li>B) Correta, pois corresponde exatamente aos quatro elementos essenciais de um padrão de projeto descritos na literatura.</li>
 
 <li>C) Errada, uma vez que substitui o "Nome do padrão" por "Nome do software" e inclui "Planejamento das atividades", não usual em descrever padrões.</li>
 
 <li>D) Incorreta, pois também adiciona "Planejamento das atividades" e "Tempo de desenvolvimento" ao invés de "Solução" e "Consequências".</li>
 
 </ul>
 

 Portanto, a alternativa correta é B.
 

</body>
</html>

Regra de negócio, interface e configuração

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A arquitetura de uma aplicação em três camadas, ou 3-Tier, é uma das mais comuns em sistemas de informação, sendo fundamental para uma boa separação de responsabilidades dentro de aplicativos. Na arquitetura de três camadas, as principais componentes organizacionais são:
 <ul>
 <li>Camada de Apresentação: essa é a camada que o usuário final vê e interage. Seu principal objetivo é apresentar dados ao usuário e capturar a entrada de dados do usuário.</li>
 <li>Camada de Negócio: também chamada de camada lógica ou de domínio, essa camada contém a lógica de negócios essencial para o funcionamento da aplicação. Processa as solicitações feitas pela camada de apresentação, realiza operações lógicas e envia comandos para a camada de dados.</li>
 <li>Camada de Dados: responsável pelo armazenamento e recuperação de dados do sistema. Ela se comunica com a camada de negócio e geralmente integra sistemas de gerenciamento de banco de dados.</li>
 </ul>
 

 Vamos analisar detalhadamente cada alternativa:
 
 
 <ul>
 <li>A) Apresentação, negócio e dados:
 Correta. Corresponde exatamente à estrutura das três camadas de uma arquitetura 3-Tier, onde cada termo identifica corretamente sua camada correspondente.
 </li>
 
 <li>B) Configuração, usuário e arquivo:
 Incorreta. A alternativa mistura conceitos que não descrevem diretamente as camadas de uma arquitetura em três níveis. 'Usuário' e 'arquivo' não correspondem às categorias fundamentais desse modelo.
 </li>
 
 <li>C) Regra de negócio, interface e configuração:
 Incorreta. Embora 'Regra de negócio' possa ser associada à camada de negócio e 'interface' à camada de apresentação, 'configuração' não representa adequadamente nenhuma das três camadas fundamentais.
 </li>
 
 <li>D) Configuração, servidor e arquivo:
 Incorreta. Estes termos novamente não refletem as camadas caracterizadas na arquitetura 3-Tier. 'Servidor' e 'arquivo' são elementos que podem estar presentes, mas não definem as camadas em questão.
 </li>
 
 </ul>
 
 
 Portanto, a alternativa correta é A.
 

</body>
</html>

Modelo Espiral: produto final é entregue 
rapidamente

Modelo Incremental: produzem o sistema de forma incremental até a sua versão final

Metodologias Ágeis: dura de 1(uma) a 4(quatro) semanas e ao final de cada iteração deve haver entrega ao cliente

Modelo em Cascata: componente do sistema é entregue por fases, podendo acontecer paralelamente.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A escolha do modelo de ciclo de vida de desenvolvimento de software é crucial para o sucesso do projeto. Cada modelo oferece diferentes abordagens e benefícios dependendo das necessidades do projeto. Vamos detalhar cada modelo e entender a correção das alternativas apresentadas:
 
 
 <ul>
 <li>Modelo Espiral:
 Este modelo combina elementos do modelo cascata e prototipagem em etapas, enfatizando a avaliação de riscos. Ele é um modelo iterativo, onde cada espiral representa uma fase do projeto. Cada fase inclui planejamento, análise de riscos, engenharia e avaliação do cliente, com o objetivo de mitigar riscos antes de se avançar para a próxima etapa.
 Avaliação: A descrição na alternativa A pode induzir ao erro ao sugerir que o produto é entregue "rapidamente", pois embora o modelo permita desenvolvimentos rápidos de protótipos, o produto final pode levar mais tempo devido à natureza iterativa e à necessidade de revisões frequentes.
 </li>
 
 <li>Modelo Incremental:
 No modelo incremental, o software é desenvolvido em incrementos funcionais; cada incremento agrega novas funcionalidades ao software. Cada incremento passa por suas próprias fases de requisitos, design, implementação e testes. O modelo é eficaz quando os requisitos para funcionalidades principais são conhecidos antecipadamente.
 Avaliação: A alternativa B está correta, descrevendo adequadamente que o sistema é produzido de forma incremental.
 </li>
 
 <li>Metodologias Ágeis:
 A abordagem ágil é uma resposta à ineficiência dos modelos mais tradicionais frente à necessidade de rapidez e flexibilidade. As metodologias ágeis, como Scrum e XP, se concentram em entregas rápidas e frequentes de pequenas partes funcionais do software, aproveitando o feedback contínuo do cliente para orientar o desenvolvimento subsequente.
 Avaliação: A alternativa C é precisa ao mencionar a duração das iterações e a entrega ao cliente ao final de cada uma.
 </li>
 
 <li>Modelo em Cascata:
 O modelo em cascata é um dos mais antigos e tradicionais, onde as fases do desenvolvimento (como requisitos, design, implementação, verificação e manutenção) seguem uma sequência linear. Cada fase deve ser concluída antes de passar para a próxima, e geralmente não há retorno a fases anteriores.
 Avaliação: A alternativa D é incorreta, pois afirma que componentes podem ser entregues paralelamente, o que vai contra a natureza sequencial e rígida do modelo em cascata.
 </li>
 
 </ul>
 
 
 Portanto, a alternativa correta é D.
 

</body>
</html>

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 A técnica adequada de levantamento de requisitos é fundamental para o sucesso de projetos de desenvolvimento de software. Diferentes técnicas podem ser aplicadas dependendo do tipo do projeto, da complexidade dos requisitos, do contexto em que o software será usado e das partes interessadas envolvidas. É importante entender as diversas técnicas de levantamento para escolher a mais apropriada para cada cenário.
 
 Vamos analisar cada alternativa apresentada nesta questão:
 

 <ul>
 <li>A) Técnicas transversais:
 Esta alternativa é considerada incorreta, uma vez que não é reconhecida como um grupo padrão de técnicas de levantamento de requisitos na engenharia de software. Normalmente, as técnicas são classificadas como tradicionais, grupo, prototipagem, entre outras, mas "técnicas transversais" não é uma categoria comum nesta área.
 </li>
 

 <li>B) Técnicas tradicionais:
 As técnicas tradicionais de levantamento de requisitos são amplamente utilizadas e incluem métodos como entrevistas, questionários, observação e análise de documentos existentes. São consideradas essenciais para obter uma visão direta das necessidades dos stakeholders e do ambiente de negócios.
 </li>
 

 <li>C) Técnicas de elicitação de grupo:
 As técnicas de elicitação de grupo ajudam a capturar requisitos por meio do diálogo coletivo e colaboração entre múltiplos stakeholders. Técnicas como brainstorming, workshops e sessões JAD (Joint Application Development) são comuns nesta categoria e são eficazes para alcançar consenso e compreender as várias perspectivas dos usuários.
 </li>
 

 <li>D) Técnicas contextuais:
 Essas técnicas focam na observação direta de como os usuários interagem com sistemas em seu ambiente natural. Incluem métodos como análise de tarefas e etnografia. São particularmente úteis para desenvolver softwares que se ajustem de maneira eficaz e eficiente às necessidades diárias dos usuários.
 </li>
 
 </ul>
 
 
 Entendendo que a técnica de "Técnicas transversais" não é um termo típico ou reconhecido na engenharia de software para o levantamento de requisitos, e que as demais alternativas representam grupos válidos e bem-definidos de técnicas, podemos confirmar a escolha da alternativa correta para a pergunta dada.
 

 Portanto, a alternativa correta é A.
</body>
</html>

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 .red {
 color: red;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Renato, como analista de negócios responsável pelo levantamento de requisitos em uma empresa de varejo, precisa escolher a técnica mais adequada para essa tarefa. O levantamento de requisitos é uma fase crítica no desenvolvimento de software, pois é necessário entender exatamente o que os usuários precisam e como o sistema pode atender a essas necessidades.
 

 Existem várias técnicas efetivas para a elicitação de requisitos, cada uma adequada para diferentes contextos e tipos de projetos. Vamos analisar as opções listadas na questão para identificar a alternativa incorreta.
 

 <ul>
 <li>A) Etnografia:
 Esta técnica envolve a imersão do analista no ambiente onde o sistema será utilizado, permitindo uma observação direta de como os processos são conduzidos no dia a dia. Esta abordagem ajuda a identificar requisitos implícitos e verificar a adequação do sistema às necessidades reais dos usuários. Portanto, é uma técnica válida para levantamento de requisitos.
 </li>
 
 
 <li>B) IADI:
 A alternativa menciona "IADI" como uma técnica de levantamento de requisitos. No entanto, este termo não é reconhecido como uma técnica padrão no campo de engenharia de software para o levantamento de requisitos. Sem uma definição clara e aceitação na comunidade de desenvolvimento de software, essa opção é claramente a incorreta.
 </li>
 
 
 <li>C) Questionários:
 Questionários são amplamente utilizados para coletar informações de um grande número de usuários, especialmente quando estão dispersos geograficamente. Esta técnica permite coletar dados quantitativos e qualitativos, ajudando os analistas a entender as necessidades de diversos grupos de stakeholders. Por isso, é uma opção correta e eficaz para o levantamento de requisitos.
 </li>
 
 
 <li>D) Prototipagem:
 A prototipagem é uma técnica onde um modelo inicial do sistema é construído para testar ideias, integrar soluções e coletar feedback dos usuários. Isso permite iterar e refinar os requisitos do sistema de forma prática. É uma técnica particularmente útil para esclarecer requisitos não bem definidos ou complexos através do envolvimento direto dos usuários. Assim, também é uma técnica correta para levantamento de requisitos.
 </li>
 </ul>
 
 
 Portanto, a alternativa correta é B.
 

</body>
</html>

Questões de Tecnologia da Informação - Engenharia de Software