A opção da estrutura organizacional do projeto depende das características do projeto e de restrições externas, como uma política organizacional já existente. Portanto, é difícil prescrever essas estruturas, pois o que é eficaz (ou até mesmo viável) dependerá muito das circunstâncias. Os problemas a serem endereçados estão examinados em  Diretriz: Plano de Desenvolvimento do Software, que também apresenta uma estrutura de projeto padrão que pode ser adaptada às necessidades específicas de um projeto. A estrutura padrão de projeto também sugere um mapeamento de (Rational Unified Process, RUP) funções para as posições da organização. A forma e o tamanho da organização variam em cada fase e o Plano de Desenvolvimento de Software, que é um documento dinâmico, será atualizado para refletir essas mudanças.

De acordo com as estimativas de esforço para o projeto, a programação desejada, a estrutura organizacional e o mapeamento de funções escolhidas, o Coordenador de Projeto determina o perfil da equipe (número de pessoas ao longo do tempo e habilidades) necessário para o projeto. A estimativa de esforço para um projeto não é independente, naturalmente, do tamanho, da experiência, das habilidades e do nível da equipe - muito provavelmente, o Coordenador de Projeto fará suposições sobre a capacidade e outras qualidades da equipe ao elaborar a estimativa de esforço. No modelo da estimativa do COCOMO (consulte Tarefa: Planejar Fases e Iterações), recursos da equipe e experiência são os direcionadores de esforço principais. Portanto, a seleção de um esforço total aceitável (por meio do ajuste de vários orientadores de esforço COCOMO) e de um planejamento viável determinarão o perfil da equipe.

Em alguns casos, o Coordenador de Projeto pode saber com antecedência os números e as habilidades da equipe que estará disponível.  Nesses casos, com o tamanho e as habilidades da equipe definidos, somente o planejamento é variável, pressupondo-se que o escopo do projeto permanecerá inalterado.

O Coordenador de Projeto também deve estar ciente da ruptura que pode ser causada pela elevação de níveis de equipe muito rapidamente, como também do efeito potencialmente catastrófico sobre a produtividade causado pela tentativa de reduções radicais na programação, devido a aumentos nos números da equipe.

Formando Equipe das Fases de Elaboração e de Iniciação

Durante a fase de Iniciação, a ênfase recai sobre a definição e limitação do escopo e o desenvolvimento de um caso de uso de negócio para o projeto. Conseqüentemente, o tamanho da equipe é relativamente pequeno: um Coordenador de Projeto, um Arquiteto de Software e, talvez, um ou dois desenvolvedores, principalmente se houver necessidade de uma prova de conceito de protótipo para esclarecer os requisitos ou para dar suporte ao produto.

Durante a fase de Elaboração, a ênfase principal é a arquitetura e o protótipo arquitetural. Conseqüentemente, as tarefas de design no início da fase de elaboração são direcionadas para os aspectos arquiteturais e pouca atenção é dada aos detalhes das classes e seus atributos, que, embora identificados, ainda não são significativos para a arquitetura. Durante essas iterações, a maior parte do esforço é da equipe de arquitetura e de uma equipe designada para a criação do protótipo. A equipe de criação do protótipo, geralmente, reúne os programadores mais experientes. Nesse ponto, você tem uma pequena equipe de design concentrada em mecanismos e tecnologias genéricos. O grupo de teste se concentra na criação do ambiente de teste e no teste dos casos de uso iniciais.

A escolha de membros da equipe de arquitetura deve ser feita cuidadosamente: ela deve possuir não só habilidades superiores de análise e design, como também qualidades de liderança. Para comunicar a arquitetura à equipe maior durante a fase de construção, recomenda-se distribuir os membros da equipe de arquitetura entre as equipes de Construção. Os membros da equipe de arquitetura também precisam cobrir um espectro amplo de experiência de engenharia de software: design e implementação de software, ajuste de desempenho, gerenciamento de banco de dados, gerenciamento de rede e gerenciamento de configuração estão entre as principais habilidades que devem estar representadas na equipe de arquitetura.

Formando Equipe da Fase de Construção

A Fase de Construção é dedicada à manutenção da integridade arquitetural do sistema, embora também envolva o desenvolvimento contínuo de funcionalidades para o sistema. Isso requer o refinamento da arquitetura (portanto a "elaboração de linhas de base" e não o "congelamento" da arquitetura após a Fase de Elaboração) e uma equipe de arquitetura que esteja atenta aos designers e seus projetos.

A equipe de arquitetura poderá se distribuir entre as equipes de desenvolvimento, atuando como líderes técnicos e coordenando questões entre grupos com outros líderes técnicos. As equipes de Construção propriamente ditas devem ser equipes funcionais com conhecimentos de design e desenvolvimento, pois são responsáveis pelo design e pela implementação da funcionalidade a eles atribuída. Geralmente, uma equipe de Construção responsabiliza-se por um ou mais subsistemas com interfaces bem definidas. As mudanças efetuadas nessas interfaces ou a inclusão de novos subsistemas provocam mudanças arquiteturais e precisam ser cuidadosamente consideradas. No subsistema, a equipe tem uma liberdade relativa para projetar e implementar quando considerar necessário. No entanto, a comunicação entre as equipes é fundamental para garantir que elas não estejam criando os mesmos mecanismos de implementação paralelamente.

Em geral, as equipes de Construção são organizadas horizontalmente, ao longo de linhas de camadas. Uma equipe pode ser responsável pelas interfaces de bancos de dados ou pela infra-estrutura de comunicação, enquanto outras equipes se dedicam à funcionalidade do aplicativo. As equipes da camada "superior", conseqüentemente, precisam de mais conhecimento sobre o domínio de problemas e sobre o design da Interface do Usuário ou sobre a interface com sistemas externos. As equipes da camada "inferior" estão mais familiarizadas com a tecnologia de implementação. A composição dessas equipes deve refletir essas diversas demandas de habilidades.

Formando Equipe de Tarefas de Teste

A primeira questão referente a testes é sobre o seu grau de formalidade? Além disso, quanto você pode despender para atender aos seus objetivos de qualidade, sem sair de limites razoáveis do ponto de vista de custos e programação. Raramente, os projetos têm orçamento para efetuar todos os tipos de teste. Normalmente, os projetos selecionam um nível de teste que possam suportar. Lembre-se de que cada especificação de teste deve ser verificada e mantida. É muito negativo para o estado de espírito da equipe do projeto ter planos para a criação de várias especificações de teste e não poder implementar esses planos por falta de tempo suficiente.

Crie uma equipe específica para testes. Ao menos uma pessoa da equipe de teste deve ser procedente da equipe de captura de requisitos. A equipe de teste é responsável por

• Teste de Caixa-Preta. Testar os casos de uso fora do sistema com base no fluxo de eventos do caso de uso (consulte Produto de Trabalho: Caso de Uso).
• Teste de Caixa-Branca. Testar o envio atual de mensagens no caso de uso, com base nas visualizações de seqüência para os cenários.
• Teste do sistema. Estressar o sistema para revelar sua real natureza.

Não se esqueça de que esses procedimentos não consistem apenas na execução de testes - também envolvem a preparação do ambiente de teste, além da criação e verificação das especificações de teste.

Um grupo independente deve testar os casos de uso e o sistema inteiro. Ele deve realizar os testes e elaborar relatórios de teste. O trabalho de testar os casos de uso deve ser organizado para que haja algum responsável pelos testes de cada caso de uso.

Se não for possível um grupo independente testar os casos de uso, como em um projeto pequeno, você deve pelo menos certificar-se de que o responsável por um caso de uso de design não teste o caso de uso.

O teste de regressão automatizado deve ser usado em projetos médios e grandes. A equipe de teste precisará do suporte de alguns programadores. Esse fator é ainda mais importante durante o desenvolvimento iterativo, quando você não quer despender muito esforço reexecutando o mesmo conjunto de testes repetidamente.

Formando Equipe da Fase de Transição

Na Fase de Transição, o trabalho de desenvolvimento é concluído. Os testes beta são conduzidos e um release final é preparado. Se tiver sido feito um bom trabalho durante a fase de Construção, a equipe do projeto poderá ser reduzida, diminuindo o número de desenvolvedores e testadores. A combinação dos membros da equipe favorecerá os treinadores e os especialistas em logística de infra-estrutura, responsáveis pela implementação do produto na comunidade de usuários.

O arquiteto de software ou a equipe de arquitetura trabalha em um "modo de acompanhamento": eles ajudam a classificar relatórios de problemas, a priorizar propostas de alterações e a alterar pedidos, para garantir que os problemas não sejam corrigidos, por motivo de urgência, de uma forma que danifique a arquitetura. As tarefas de design diminuem durante a fase de transição e limitam-se à correção de problemas ou à introdução de aprimoramentos de última hora.