A gerência do escopo de um projeto envolve a definição do escopo, a aprovação formal do escopo pelos interessados e o controle das mudanças no escopo do projeto. Por sua vez, a gerência do tempo do projeto envolve a identificação das atividades a serem executadas, a identificação das dependências entre atividades, a duração das atividades, a identificação da seqüencia na qual as atividades devem ser realizadas e a elaboração de cronogramas.

Há processos de projeto que podem ser categorizados como processos de gerenciamento de projetos. Entre tais processos, têm-se os processos de planejamento e os processos de controle. Os processos de planejamento envolvem a criação e a manutenção do plano de projeto, enquanto os processos de controle buscam garantir que os objetivos do projeto sejam atingidos.

O processo gerenciar projetos (manage projects) visa definir e documentar a natureza e o escopo do projeto. O processo gerenciar modificações (manage changes) visa avaliar as solicitações de modificações para determinar o impacto no sistema. O processo gerenciar dados (manage data) visa definir e implementar procedimentos de backup e recuperação de dados.

No domínio monitorar e avaliar (monitor and evaluate) encontra-se o processo gerenciar qualidade (manage quality). No domínio adquirir e implementar (acquire and implement), há o processo adquirir e manter software de aplicação (acquire and maintain application software). No domínio planejar e organizar (plan and organise), tem-se o processo garantir aderência a requisitos externos (ensure compliance with external requirements).

A área de processo medição e análise (measurement and analysis) visa a implementação da coleta, do armazenamento, da análise e do relato de dados para suprir as necessidades de informações gerenciais. A área gerência integrada de fornecedores (integrated supplier management) visa identificar fontes de produtos que satisfaçam os requisitos do projeto.

As áreas de processo verificação e validação são definidas no nível gerenciado (managed). A área análise causal e resolução (causal analysis and resolution) é definida no nível definido (defined). A área gerência quantitativa do projeto (quantitative project management) é definida no nível quantitativamente gerenciado (quantitatively managed).

O controle de qualidade envolve definir e aprovar processos que assegurem que a equipe de desenvolvimento seguiu os procedimentos e os padrões de qualidade do projeto. Uma abordagem para verificar a qualidade dos produtos de projeto é a realização de revisões de qualidade, nas quais se procura assegurar que padrões de qualidade definidos foram seguidos.

Os planos de qualidade podem conter informações sobre padrões de qualidade, procedimentos e ferramentas para executar atividades de garantia da qualidade, procedimentos para identificar requisitos de qualidade e cronograma para atividades de garantia da qualidade.

As revisões de software são voltadas para a garantia de qualidade e podem ser aplicadas ao longo do ciclo de desenvolvimento para a inspeção de variados artefatos. As revisões e os testes podem ser combinados na produção de software. Entre as técnicas de revisão, tem-se a walkthrough, que envolve uma equipe de profissionais durante a revisão.

O particionamento de equivalência e a análise de valor limite são técnicas estruturais de teste. O particionamento de equivalência visa minimizar a quantidade de casos de teste ao selecionar um caso de teste em cada classe de equivalência. Por sua vez, a análise de valor limite complementa o particionamento de equivalência, pois requer casos de teste nos limites de cada classe de equivalência. O uso da análise de valor limite tipicamente produz uma menor quantidade de casos de teste do que o mero uso do particionamento de equivalência.

O teste de software, uma atividade de validação e verificação, consiste em executar o produto para verificar a presença de defeitos e aumentar a confiança que o produto está correto. Na fase dedicada aos testes de unidade, procura-se identificar erros de lógica e de implementação nas unidades que compõem o sistema de software. Além disso, nessa fase, as unidades são integradas visando-se descobrir erros nas interfaces entre unidades.

Considerando que o projeto de um banco de dados relacional para modelo seja composto pelas relações PEDIDO, ITEM, CLIENTE e ENDERECO, é correto afirmar que, na relação PEDIDO, tem-se as colunas CODIGO, DATA e PRECO; na relação ITEM, tem-se apenas as colunas NUMERO, VALOR e QUANTIDADE; e MATRICULA é chave estrangeira na relação ENDERECO.

A cada entidade do tipo CLIENTE podem estar associadas várias entidades do tipo PEDIDO; MATRICULA é um atributo-chave; entre PEDIDO e ITEM há um relacionamento identificador; para se identificar cada entidade ITEM, basta NUMERO.

No RUP, é recomendado: desenvolver o sistema de software iterativamente; construir modelos usando a UML para representar tanto a visão estática, quanto a dinâmica; estruturar a arquitetura do sistema de software usando componentes modulares e avaliar o nível de qualidade dos artefatos em diversos momentos do ciclo de vida.

No rational unified process (RUP), o ciclo de vida de cada software é decomposto em quatro fases seqüenciais. Em um ciclo de vida, cada fase pode ser dividida em iterações; em cada interação podem ser realizadas atividades de variadas disciplinas, por exemplo, das disciplinas de implementação e de teste. A fase final em um ciclo está relacionada à transferência do sistema da comunidade de desenvolvimento para a de usuários.

O projeto de um software procura dividir o software em componentes que executem funções específicas e levar a interfaces que minimizem a complexidade de conexões entre os módulos. No projeto preliminar, procura-se transformar os requisitos em uma arquitetura de dados e software. No projeto detalhado, os componentes individuais podem ser refinados até o nível de interfaces, classes ou componentes preexistentes.

A análise de requisitos envolve atividades como: reconhecimento do problema; avaliação e síntese; modelagem; especificação e revisão. Durante a análise de requisitos, podem ser criados modelos, os quais se concentram naquilo que o sistema deve fazer, não em como ele o faz. Os modelos construídos quando da análise servem de base para o projeto. Quando da elaboração de modelos no projeto, serão considerados aspectos relacionados ao contexto de implementação.

Um documento WSDL descreve formalmente a interface do ponto de contato (endpoint) de um provedor de serviço e a localização física do serviço. Na porção concreta de uma definição WSDL, tem-se descrições de requisitos para que conexões sejam estabelecidas com o serviço. As estruturas de mensagens SOAP não podem ser definidas com WSDL, uma vez que tais mensagens têm as estruturas das mensagens usadas nos protocolos RPC (remote procedure call).