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>

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 </style>
</head>
<body>
 A arquitetura cliente-servidor é um paradigma fundamental na construção de sistemas de redes onde várias máquinas usuárias (clientes) interagem com servidores dedicados a fornecer algum tipo de serviço (como banco de dados, arquivos, etc.). Avaliaremos as afirmações sobre essa estrutura para determinar sua correção.
 
 
 <ul>
 <li>I) Nessa arquitetura, por padrão, deve existir comunicação de um cliente com outros clientes.</li>
 Isso é incorreto. A arquitetura cliente-servidor não envolve comunicação direta entre clientes; ela foca em transações entre cliente e servidor. Clientes independentes podem se comunicar em algumas redes, mas isso iria além do modelo clássico de cliente-servidor.
 
 <li>II) Um servidor deve ser capaz de atender solicitações de múltiplos clientes de maneira simultânea.</li>
 Essa afirmação é correta e reflete uma das principais características dos servidores em uma arquitetura cliente-servidor. A capacidade de um servidor para processar solicitações simultâneas é crucial para a eficiência e rapidez do sistema, sendo frequentemente implementada através de técnicas de multithreading ou multiprocessamento.
 
 <li>III) Do lado do processo servidor, os serviços não podem ser distribuídos.</li>
 Esta afirmação é falsa. De fato, um dos avanços em arquiteturas de sistemas distribuídos é a possibilidade de distribuir serviços em múltiplos servidores, o que pode melhorar a redundância e a escalabilidade do sistema.
 
 <li>IV) Em termos de implementação, normalmente o processo do lado servidor é mais complexo que o processo do lado cliente.</li>
 Esta afirmação geralmente é verdadeira. O servidor precisa não apenas lidar com lógica de negócios e processamento de dados, mas também gerenciar questões de segurança, simultaneidade, persistência de dados, etc., enquanto o cliente muitas vezes tem uma lógica de apresentação mais simples e interfaces com o usuário.
 </ul>
 
 
 Com base na veracidade das afirmações avaliadas, os itens II e IV estão corretos e consistentes com os princípios da arquitetura cliente-servidor, enquanto os itens I e III estão incorretos.
 
 
 Portanto, a alternativa correta é C.
</body>
</html>

Questões de Tecnologia da Informação - Engenharia de Software - Arquitetura Cliente/Servidor