Inspeções e walkthroughs podem ser usadas para revisar artefatos. Uma walkthrough requer mais tempo de preparação dos revisores do que uma inspeção, também exige que seja feito o acompanhamento das soluções dos problemas identificados e a coleta de métricas associadas à revisão.

Em uma inspeção, os participantes têm papéis definidos. O moderador conduz reuniões e os inspetores devem, durante as reuniões, descrever os problemas identificados e soluções para os mesmos.

Um teste de unidade pode ser projetado usando-se uma estratégia caixa branca. Nesse caso, há um foco nos mecanismos internos da unidade sendo testada. A realização de testes caixa branca pode ser apoiada por métricas de cobertura.

A cobertura de linhas de código informa o percentual de linhas de código executadas. Essa métrica é calculada instrumentando-se manualmente o código, pois não há ferramentas que possibilitem o seu cálculo.

Um modelo de análise é menos abstrato que um de projeto e as classes em um modelo de análise não podem ser conceituais. As classes na análise podem modelar objetos persistentes, mas não transientes.

Uma importante responsabilidade da análise é definir a arquitetura do sistema, dividindo-o em subsistemas. Um subsistema expõe serviços via interfaces, que devem ser especificadas na análise.

Uma classe descreve objetos com as mesmas responsabilidades, relacionamentos, operações, atributos e semântica. As instâncias de uma classe têm, portanto, os mesmos valores para os seus atributos.

Um modelo de análise pode realizar casos de uso. A realização de um caso de uso descreve interações entre objetos. Na UML, essas realizações podem ser documentadas via diagramas de colaboração.

O modelo em cascata organiza o desenvolvimento em fases. Esse modelo encoraja a definição dos requisitos antes do restante do desenvolvimento do sistema. Após a especificação e a análise dos requisitos, têm-se o projeto, a implementação e o teste.

Um possível objetivo da prototipação é criar rapidamente um sistema experimental que possa ser avaliado por usuários finais. Um protótipo aprovado pelos usuários pode vir a ser usado como ponto de partida para a construção do sistema.

O Unified Software Process é guiado por casos de uso, focado na arquitetura, iterativo e incremental. A vida do software é organizada em ciclos e cada ciclo é dividido nas fases de requisitos, análise, projeto e implementação.

Processos de desenvolvimento que adotam o modelo ágil enfatizam a comunicação entre participantes, a realimentação e a simplicidade. Para atingir tais práticas, o Extreme Programming (XP) advoga práticas como a posse coletiva do código.

Nas hierarquias, cada classe derivada herda de mais de uma classe base.

Cada interface é implementada por mais de uma classe.

Uma instância da Classe4 pode ter uma referência para uma instância da classe ProdutoA1.

ProdutoA1 e ProdutoB1 têm uma mesma superclasse.

As classes ProdutoB1 e ProdutoB2 são generalizações da classe ProdutoB.

Se a Classe1 é abstrata, as Classe2 e Classe3 têm que ser abstratas.

No diagrama, as setas sólidas representam dependências e as setas pontilhadas representam associações.

A Classe5 implementa a Interface1 e a Classe6 implementa a Interface2.