Nos modelos entidade-relacionamento, o número de entidades que podem participar de um relacionamento é o grau desse tipo de relacionamento. A restrição de cardinalidade mínima é o número mínimo de instâncias de relacionamento em que cada entidade pode participar. Em um tipo relacionamento M:N, pode haver atributos que não são determinados por uma entidade única, mas pela combinação das entidades participantes de uma instância desse relacionamento.

Nos modelos entidade-relacionamento, para uma dada entidade, cada atributo multivalorado pode ter mais de um valor, enquanto cada atributo monovalorado tem um único valor; cada atributo composto pode ser dividido em partes menores; os atributos derivados podem ser calculados a partir de outros atributos; os tipos entidade fraca têm seus próprios atributos-chave.

As seguintes responsabilidades são típicas dos stubs usados nos testes dos softwares orientados a objeto: criar um objeto da classe em teste; interligar o objeto em teste a outros objetos necessários ao teste; levar o objeto em teste a um estado inicial; enviar seqüências de mensagens para o objeto em teste; coletar respostas do objeto em teste; avaliar as respostas providas pelo objeto em teste.

Os testes de integração verificam se os componentes do sistema funcionam em conjunto, se os componentes são chamados corretamente e se os componentes transferem dados corretos via suas interfaces. Nesses testes, os componentes são testados interligados; podem ser necessários drivers e stubs para simular componentes ainda não implementados; e, em sistemas de software orientados a objeto, os stubs podem ser classes.

O teste de caminho é uma abordagem estrutural para o projeto de testes em que podem ser usados fluxogramas. Essa abordagem de projeto pode ser empregada quando do projeto de testes de unidade. Em sistemas de software orientados a objetos, os testes de classes podem ser estruturais.

No modelo de processo de desenvolvimento embasado em entrega incremental, tem-se que o sistema é desenvolvido como uma série de incrementos, sendo que cada incremento provê um conjunto de funcionalidades. É fácil identificar os recursos que são comuns aos incrementos, pois todos os requisitos precisam ser detalhados quando do início do desenvolvimento.

No modelo em cascata de processo de desenvolvimento, os clientes devem definir os requisitos apenas durante a fase de projeto; e os projetistas definem as estratégias de projeto apenas durante a fase de implementação. As fases do ciclo de vida envolvem definição de requisitos, projeto, implementação, teste, integração, operação e manutenção. Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.

A análise orientada a objetos, o projeto orientado a objetos e a programação orientada a objetos compreendem atividades de engenharia de software voltadas à construção de sistemas orientados a objetos. Nesses sistemas, objetos interagem para prover serviços. No nível de programação, as interações ocorrem via interfaces das classes das quais os objetos são instâncias. Essas interfaces contêm membros públicos das classes.

Há métodos ágeis de desenvolvimento que empregam as práticas de programação em pares e teste de unidade. A programação em pares apóia a idéia de que o código é propriedade da equipe como um todo, tipicamente dificulta a refatoração (refactoring) e atua como um processo informal de revisão de código. Em relação aos testes de unidade, há métodos ágeis nos quais testes de unidade são escritos antes do código a ser testado.

Entre as características de alguns métodos ágeis de desenvolvimento de software, inclui-se ênfase na construção de modelos e na especificação detalhada do sistema e desenvolvimento em incrementos, processo no qual os clientes têm reduzida participação.