Testes de regressão são realizados somente durante a manutenção do software.

O teste de integração deve ser realizado logo após os testes individuais de unidades, obrigatoriamente por equipes diferentes da equipe de desenvolvimento.

O teste de unidade tem foco na menor unidade de um sistema, um programa. Testes em funções, procedimentos ou métodos não são considerados testes de unidade.

O teste alfa é conduzido pelo cliente em seu ambiente de uso final.

Testes de sistema não podem explorar requisitos não funcionais.

Uma condição de guarda é uma expressão booleana que precisa ser falsa para que uma transição ocorra.

Diagramas de estados não podem ser aninhados e, portanto, não são capazes de expressar situações complexas.

Não há como expressar a concorrência entre objetos por meio de diagramas de estados.

Um estado é uma condição ou situação na vida de um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento.

As combinações de eventos, estados e transições de estado para determinada classe não podem ser representadas em um único diagrama de estados.

A navegação em uma associação é unidirecional, da esquerda para direita e de cima para baixo, a menos que seja explicitado o procedimento contrário.

Em generalizações, atributos e operações são herdados pelas subclasses. Entretanto, relacionamentos de associação não são herdados.

Em uma associação entre duas classes, a própria associação pode ter atributos. Nesse caso, usa-se a classe de associação.

A agregação é um relacionamento particular de especialização, que especifica o relacionamento todo/parte entre o agregado e o componente.

A agregação é uma forma especial de composição com tempo de vida coincidente das partes pelo todo, ou seja, o objeto composto é responsável pela criação e destruição de suas partes.

Os diagramas de casos de uso são diagramas UML para modelagem de aspectos estáticos de sistemas.

O relacionamento de dependência que usa o estereótipo  especifica que um caso de uso incorpora recursos opcionais, ou seja, o sistema pode ser utilizado com ou sem os recursos adicionais.

O relacionamento de dependência que usa o estereótipo  especifica que o caso de uso de origem incorpora explicitamente outro caso de uso, que representa uma atividade significativa.

Em diagramas de casos de uso, não é possível utilizar relacionamento de generalização entre atores nem entre casos de uso.

O uso de pacotes permite formar grupos de casos de uso e de atores, de modo a facilitar a compreensão de um sistema complexo. Pacotes de atores refletem os tipos de usuários do sistema.

Exemplos de diagramas de modelagem UML que expressam partes estáticas de um sistema são: diagrama de classes e diagrama de atividades.

Exemplos de diagramas de modelagem UML que expressam partes dinâmicas de um sistema são: diagrama de caso de uso e diagrama de implantação.

Um diagrama de componentes é do tipo estrutural, e mostra partes internas, conectores e portas que implementam um componente.

O diagrama de comunicação enfatiza a ordem temporal de mensagens, que reagem a eventos externos e internos.

A UML é uma linguagem de programação orientada a objetos.

A manutenção de software é um processo geral de mudanças que ocorre antes ou depois que um sistema é entregue.

A manutenção corretiva para reparar defeitos de software diz respeito à mudança em um sistema para corrigir erros, que podem ser somente de codificação. Erros de projeto e de lógica não estão incluídos nessa categoria.

A manutenção adaptativa para adaptar o software a mudanças ambientais se refere a mudanças de diversos tipos, como uma nova plataforma de hardware. Mudanças de sistemas operacionais ou software em geral não estão incluídas nessa categoria.

A manutenção perfectiva tem como objetivo tornar o software perfeito, melhorar seu desempenho e sua manutenibilidade ou adicionar-lhe funcionalidade para satisfazer a novos requisitos.

A manutenção preventiva tem como objetivo detectar e corrigir falhas latentes no produto antes que elas virem falhas efetivas.

Requisitos funcionais descrevem as propriedades emergentes do sistema, como segurança e tempo de resposta.

Requisitos não funcionais são descritos de forma qualitativa e não quantitativa.

Requisitos são provenientes de pessoas relevantes para o sistema, e não de outros sistemas que interagem com o sistema que está sendo especificado.

A matriz de rastreabilidade não oferece suporte para requisitos funcionais.

Revisão de requisitos, prototipação e geração de casos de teste são exemplos de técnicas de validação de requisitos.

O RUP divide todo o projeto de software em três fases diferentes: concepção (ou iniciação), com ênfase no escopo do sistema; elaboração, com ênfase na arquitetura; e construção, com ênfase no desenvolvimento.

O RUP promove o uso de seis melhores práticas: desenvolva iterativamente; gerencie requisitos; use arquiteturas de componentes; modele visualmente (UML); verifique qualidade de software continuamente; e gerencie mudanças.

As disciplinas de suporte (apoio) do RUP são: gerenciamento de classes; gerenciamento de produto; e ambiente.

Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos artefatos. Exemplos de papéis no RUP são: analistas, desenvolvedores e testadores. Explicitamente, papéis de gerentes não fazem parte dos papéis possíveis no RUP.

As disciplinas de engenharia do RUP são: modelagem de negócios; requisitos; análise e projeto; implementação; teste; qualidade; e implantação.