Questões de Concurso Comentadas para analista de ti

O SOLID é um acrônimo em inglês para cinco princípios de projeto que possuem o objetivo de fazer programas mais compreensíveis, flexíveis e sustentáveis. O acrônimo SOLID condensa cinco princípios fundamentais para a concepção de objetos que respondem aos problemas que afetam a escalabilidade e a longevidade de um sistema. Relativamente aos princípios e suas descrições, relacione a Coluna 1 à Coluna 2.
Coluna 1 1. Single Responsibility Principle (Princípio de responsabilidade única). 2. Open-Closed Principle (Princípio aberto/fechado). 3. Liskov Substitution Principle (Princípio de substituição de Liskov). 4. Interface Segregation Principle (Princípio de segregação de interface). 5. Dependency Inversion Principle (Princípio de inversão de dependência).
Coluna 2 ( ) Classe não deve ser obrigada a implementar métodos e interfaces que não serão utilizadas. ( ) Depende de abstrações e não de implementações. ( ) Uma classe deve ter uma e apenas uma razão para mudar. ( ) Objetos devem estar disponíveis para extensão, mas fechados para modificação. ( ) Uma subclasse deve ser substituível por sua superclasse.
A ordem correta de preenchimento dos parênteses, de cima para baixo, é:

Dentro das metodologias ágeis, TDD (Test-Driven Development ou Desenvolvimento Orientado a Testes) e BDD (Behavior Driven Development ou Desenvolvimento Orientando a Comportamentos) são considerados:

Os princípios GRASP (General Responsibility Assignment Software Patterns) definem diretrizes para atribuições de responsabilidades às classes e objetos durante a construção de Sistemas Orientados a Objetos. Os nove diferentes princípios apresentados em GRASP são: Criador, Especialista de informação, Baixo acoplamento, Controlador, Alta coesão e, EXCETO:

No paradigma Orientado a Objetos há, primeiramente, um processo de construção de modelos do domínio do problema, identificando e especificando um conjunto de objetos que interagem e comportam-se conforme os requisitos estabelecidos para o sistema segundo um processo de geração de uma especificação detalhada do software a ser desenvolvido, de tal forma que essa especificação possa levar à direta implementação no ambiente alvo. Esses dois processos são, respectivamente:

A Gestão de Configuração de Software não fornece um método de projeto, um modelo de ciclo de vida e tampouco define como a qualidade dos itens deve ser julgada. Ela fornece um fundamento sólido para todas as outras atividades de engenharia de software, estabelecendo funções da gestão de configuração. Relativamente às funções e suas descrições, relacione a Coluna 1 à Coluna 2.
Coluna 1 1. Identificação de configuração. 2. Controle de configuração. 3. Auditoria de configuração. 4. Contabilização da situação de configuração.
Coluna 2 ( ) Passos no processo de alteração que afetam uma configuração. ( ) Diferenças entre as versões. ( ) Modificações feitas por determinado programador. ( ) Itens que constituem uma configuração.
A ordem correta de preenchimento dos parênteses, de cima para baixo, é: