Em relação à engenharia de requisitos, julgue o seguinte item.

O planejamento é o primeiro estágio essencial no processo de gerenciamento de requisitos e determina quando começa e termina o processo de levantamento dos requisitos.

Em relação à engenharia de requisitos, julgue o seguinte item.

O intuito do modelo de análise é fornecer uma descrição dos domínios de informação, funcional e comportamental necessários para um sistema baseado em computadores. O modelo se modifica dinamicamente à medida que a equipe aprende mais sobre o sistema a ser construído. 

Em relação à engenharia de requisitos, julgue o seguinte item.

O processo de verificações de realismo usa o conhecimento das tecnologias existentes para verificar os requisitos e assegurar que realmente podem ser implementados. Essa verificação deve considerar o orçamento e o cronograma para o desenvolvimento do sistema.

Em relação à engenharia de requisitos, julgue o seguinte item.

Na abordagem prototipação, a validação é feita através de um modelo executável do sistema em questão que é demonstrado para os usuários finais e clientes. 

Em relação à engenharia de requisitos, julgue o seguinte item.

A especificação de requisitos é o processo de escrever os requisitos de usuário e de sistema em um documento de requisitos. Idealmente, os requisitos de usuário e de sistema devem ser o mais subjetivo possível, pois representam as necessidades e a visão do usuário.

Em relação à engenharia de requisitos, julgue o seguinte item.

O documento de requisitos de software, às vezes denominado Especificação de Requisitos de Software (SRS — do inglês Software Requirements Specification), é uma declaração oficial de o que os desenvolvedores do sistema devem implementar.

Em relação a testes de software, julgue o seguinte item.

O objetivo do teste de release é verificar se o sistema atende a seus requisitos e é bom o suficiente para uso externo. Esses testes costumam ser um processo de teste de caixa-branca. 

Em relação a testes de software, julgue o seguinte item.

O desenvolvimento dirigido a testes (TDD, do inglês Test-Driven Development) é uma abordagem para o desenvolvimento de programas em que se intercalam testes e desenvolvimento de código. Desenvolve-se um código de forma incremental, em conjunto com um teste para esse incremento.

Em relação a testes de software, julgue o seguinte item.

O Teste beta é conduzido nas instalações de um ou mais usuários finais. Diferentemente do teste alfa, o desenvolvedor geralmente não está presente. Portanto, o teste beta é uma aplicação “ao vivo” do software em um ambiente que não pode ser controlado pelo desenvolvedor

Em relação a testes de software, julgue o seguinte item.

O teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces.

Em relação a testes de software, julgue o seguinte item.

Embora o objetivo principal do teste seja encontrar erros, uma boa estratégia de testes também avalia outras características de qualidade, como portabilidade, possibilidade de manutenção e processo de gerenciamento do projeto.

Em relação a testes de software, julgue o seguinte item.

O teste de software é um elemento de um tópico mais amplo, muitas vezes conhecido como verificação e validação (V&V).

Quanto à análise e ao projeto orientados a objetos, julgue o seguinte item.

No diagrama de implantação, em UML 2.0, o Device representa um dispositivo computacional, ou seja, um recurso físico com capacidade de processamento em que os artefatos podem ser implantados para execução. 

Quanto à análise e ao projeto orientados a objetos, julgue o seguinte item.

O diagrama de comunicação, em UML 2.0, mostra a comunicação, ou seja, o fluxo de mensagens que ocorre entre os objetos de um sistema de informação. Esse diagrama é utilizado quando a intenção é mostrar a colaboração entre os objetos.

Quanto à análise e ao projeto orientados a objetos, julgue o seguinte item.

No diagrama de pacotes, em UML 2.0, os estereótipos são mecanismos incorporados à UML a fim de aumentar a sua extensibilidade, ou seja, sua abrangência e seu poder de representação.

Quanto à análise e ao projeto orientados a objetos, julgue o seguinte item.

Em UML, na versão 2.0, o diagrama de máquina de estados possui um elemento chamado de barra de fork ou join que representa um recurso utilizado quando dois ou mais estados ocorrem em paralelo. 

Quanto à análise e ao projeto orientados a objetos, julgue o seguinte item.

Em UML, na versão 2.0 mais especificamente, no diagrama de atividade, o nó de bifurcação ou fork é utilizado para mostrar que dois ou mais fluxos de controle foram transformados em um único fluxo de controle.