Considere as seguintes afirmações sobre Engenharia de Software.
I - Trata da aplicação de abordagens sistemáticas, disciplinadas e quantificáveis para desenvolver, operar, manter e evoluir software. Ou seja, Engenharia de Software é a área da Computação que se preocupa em propor e aplicar princípios de engenharia na construção de software.
II - Assim como sistemas tradicionais de Engenharia, softwares também precisam de manutenção. Existem várias classificações para os tipos de manutenção que podem ser realizadas em sistemas de software. Manutenção preventiva tem como objetivo corrigir bugs reportados por usuários ou outros desenvolvedores. Por sua vez, manutenção corretiva tem como objetivo corrigir bugs latentes no código, que ainda não causaram falhas junto aos usuários do sistema.
III - Existem práticas de Engenharia de Software que podem ser adotadas para a produção de software com qualidade. Modernamente, por exemplo, diversas organizações usam revisões de código, isto é, o código produzido por um desenvolvedor somente entra em produção depois de ser revisado e inspecionado por um outro desenvolvedor do time.
Quais estão corretas?

Considere as seguintes afirmações sobre Engenharia de Requisitos.
I - Os requisitos de um sistema definem o que ele deve fazer e como ele deve operar.
II - A Engenharia de Requisitos inclui o conjunto de atividades realizadas com o objetivo de definir, analisar, documentar e validar os requisitos de um sistema.
III - Requisitos funcionais definem como um sistema deve operar, sob quais restrições e com qual qualidade de serviço. Como exemplos de requisitos funcionais temos desempenho, disponibilidade, tolerância a falhas, segurança, privacidade, interoperabilidade, capacidade, manutenibilidade e usabilidade.
Quais estão corretas?

Documentos de requisitos tradicionais possuem, muitas vezes, centenas de páginas e podem levar muito tempo para ficarem prontos. Os profissionais da indústria que apresentaram métodos ágeis perceberam — ou sofreram com — tais problemas e propuseram uma técnica pragmática para solucioná-los que ficou conhecida pelo nome de Histórias de Usuários. Quando usamos histórias de usuários, atividades de Engenharia de Requisitos ocorrem ao longo de todo o desenvolvimento, em praticamente todos os dias de uma iteração. Consequentemente, troca-se um documento de requisitos com centenas de páginas por conversas frequentes, nas quais o representante dos clientes explica os requisitos para os desenvolvedores da equipe. Assim, histórias de usuários favorecem comunicação verbal, em vez de comunicação escrita. Considere as seguintes afirmações.
I - Histórias não devem ser abertas para negociação. Uma vez definidas, não se pode usar histórias nas conversas entre clientes e desenvolvedores durante um sprint.
II - Histórias devem ser testáveis, isto é, elas devem ter critérios de aceitação objetivos.
III - Histórias devem ser independentes: dadas duas histórias, deve ser possível implementá-las em qualquer ordem. Para isso, idealmente, não devem existir dependências entre elas.
Quais caracterizam corretamente Histórias de Usuários?

Considere as seguintes afirmações sobre análise e modelos de análise.
I - Considerações de infraestrutura e outros modelos não funcionais devem ser postergados até a fase de projeto.
II - Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos requisitos de software e fornecer uma visão do domínio de informação, função e comportamento do sistema.
III - É importante representar os relacionamentos entre as classes e as funções, mesmo se o nível de interconexão for extremamente alto. Não se deve esforçar para reduzi-lo.
Quais estão corretas?

Observer, Façade e Decorator podem ser utilizados durante o desenvolvimento de software orientado a objetos, e são denominações de

Considere os seguintes elementos.
I - Adoção de ciclos curtos e iterativos de desenvolvimento
II - Menor ênfase em documentação, ou seja, apenas o essencial deve ser documentado.
III - Menor ênfase em planos detalhados, pois muitas vezes nem o cliente nem os engenheiros de Software têm, no início de um projeto, uma ideia clara dos requisitos que devem ser implementados.
Quais caracterizam corretamente processos ágeis?

Considere as seguintes afirmações sobre Scrum, XP e Kanban, alguns métodos ágeis bem conhecidos.
I - Scrum é um método ágil para gerenciamento de projetos, que não necessariamente precisam ser projetos de desenvolvimento de software.
II - XP é um método ágil voltado exclusivamente para projetos de desenvolvimento de software. Para isso, XP inclui um conjunto de práticas de programação, como programação em pares e integração contínua.
III - Scrum possui dois papéis importantes no time: Dono de Produto (Product Owner ou apenas PO) e o Scrum Master. Ao contrário de Scrum, Kanban não define uma lista fixa de papéis. Cabe ao time e à organização definir os papéis que existirão no processo de desenvolvimento.
Quais estão corretas?

Fatores de qualidade representam uma meta para todo projeto de software. Considere as seguintes definições de fatores de qualidade de software.
- ______________ é um fator avaliado medindo-se a frequência e a severidade das falhas, a precisão dos resultados gerados, o tempo médio entre defeitos, a capacidade de se recuperar de uma falha e a previsibilidade do programa.
- ____________ é um fator avaliado considerando-se fatores humanos, estética, consistência e documentação como um todo.
- ___________ é um fator mensurado considerando velocidade de processamento, tempo de resposta, consumo de recursos, vazão (throughput) e eficiência.
A alternativa que apresenta os termos que completam, correta e respectivamente, as lacunas acima é