O PAAD  foi elaborado com o propósito de ser utilizado em práticas acadêmicas de desenvolvimento de software para Sistemas Distribuídos. Ele é baseado no UP (Unified Process) e SCRUM onde tem por objetivo ser mais simplificado, enxuto e adequado à realidade e às necessidades da disciplina de Sistemas Distribuídos.

Buscamos, além de simplificar o processo e adequá-lo ao curso, trazer idéias e práticas de outros processos que possam enriquecê-lo (como valores e práticas do SCRUM e criar modelos de documentação específicos para ele.

Este processo - desenvolvido de forma iterativa e incremental Ágil - está em constante desenvolvimento e aprimoramento e diversas pessoas vêm participando desta construção com registro dos resultados em diversas publicações. O processo está aberto a receber contribuições com relação a sua melhoria.

Embora o processo seja baseado, essencialmente, no UP, são utilizados mais especificamente, três processos de desenvolvimento de software como orientadores na construção do PAS, quais sejam:

• RUP (Rational Unified Process) - O RUP (Rational Unified Process®) é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM que tem como meta garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis. Ele é centrada em uma arquitetura baseada em componentes facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. O RUP é guiado por casos de uso, projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação utilizando técnicas e práticas aprovadas comercialmente. http://www-306.ibm.com/software/awdtools/rup/
• XP (eXtreme Programming) - O XP é um processo leve, eficiente, flexível e de baixo risco para times pequenos emédios, que desenvolvem software com requisitos dinâmicos ou em constante mudança. A metodologia XP foi criada por Kent Beck, que no início dos anos 90 pensava sobre caminhos melhores para desenvolver software. Ele é baseado nos seguintes valores: simplicidade, comunicação, feedback e coragem. Para maiores detalhes sobre este processo ver BECK(2004).

O PAAD é um processo iterativo e incremental Ágil. Suas iterações são distribuídas - tal qual no Processo Unificado - em quatro fases, conforme ilustrado na figura a seguir:

Obs.: Figura em Desenvolvimento

para cada fase do UP existe uma fase equivalente no PAAD, diferenciando-se basicamente pela abrangência e pela nomenclatura de algumas fases. As principais diferenças e semelhanças entre os dois são listadas a seguir:

1. O PAAD é centrado apenas para projetos acadêmicos enquanto o UP também é focado na área comercial
2. A fase de concepção é opcional no PAAD, enquanto no UP é obrigatório.
3. O UP define para a fase de concepção o estudo de viabilidade e parte da análise, enquanto o PAAD não considera a viabilidade, busca apenas uma visão inicial para se trabalhar o sistema.
4. As fases de elaboração e construção são semelhantes nos dois processos. Na elaboração são definidas as análises de requisitos, de domínio e de projeto. A fase de construção é onde acontece a implementação e os testes do sistema que está sendo construído.
5. A fase de transição do RUP é representada pela validação no PAAD. Em ambos essa fase é a de entrega e instalação do produto gerado no cliente.

As fases são organizadas da seguinte forma:

Concepção

A fase de concepção representa o bloco inicial. Ela envolve a articulação da visão para o sistema e o estabelecimento de um projeto formal para construir o sistema. Deve ser algo mais do que uma boa idéia rabiscada em um papel de rascunho. No final desta fase deve-se ter definido o escopo do produto, um vislumbre dos riscos a serem encontrados e ter demonstrado que o projeto é viável do ponto de vista do negócio da organização. Estes itens serão a fundação para a próxima fase. Autoriza formalmente um projeto (PMBOK, 2004).

Nessa fase iremos:

• Iniciar documento de Visão do sistema:  Nessa atividade, dá-se uma visão geral do que será desenvolvido para que seja posto à prova.

• Iniciar Esboço da arquitetura: Principalmente ao respeito das partes novas, ou mais difíceis. Queremos apenas estabelecer que podemos definir uma arquitetura para o sistema.

• Identificar os riscos: Procuramos os primeiros riscos que poderiam fazer falhar o projeto e tentar achar uma solução para eles. Outros riscos, menos graves, serão identificado e tratado nas fases a seguir.

• Criar um protótipo: Queremos mostrar aos usuários como o sistema vai resolver o problema deles. Por exemplo, podemos criar uma seqüência de telas para mostrar como o sistema vai funcionar, ou podemos criar um protótipo mesmo.
• Implementar um caso de risco: Procuramos mostrar aos usuários a implementação de um caso de uso do sistema, com isso ganha-se satisfação e feedback. Essa implementação se torna importante pois consegue-se validar a arquitetura do sistema e verificar possíveis problemas.

Elaboração 

Segundo KRUCHTEN (2000), o propósito da fase de elaboração é analisar o domínio do problema, estabelecer uma arquitetura saudável, desenvolver o plano de projeto e eliminar os elementos de alto risco do projeto.

Para a maioria dos projetos, esta fase corresponde à transição de uma operação móvel, ágil, de pouco risco, para um alto custo, operação de alto risco que tem inércia significativa.

Embora o processo sempre tenha que acomodar mudanças, as atividades da fase de elaboração asseguram que a arquitetura, requisitos e planos são bastante estáveis e os riscos suficientemente mitigados, que se pode determinar o custo de maneira previsível e pode programar a conclusão do desenvolvimento. Conceitualmente, este nível de fidelidade corresponde ao nível necessário para uma organização comprometer-se a uma fase de construção de preço fixo.

(Kruchten, Philippe – Introdução ao RUP – Rational Unified Process, Tradução: Rüdiger, Debora, Ed. Ciência Moderna, Rio de Janeiro, 2003.)

Construção

Durante esta fase, serão priorizados os componentes essenciais juntamente com as características da aplicação que serão desenvolvidas e integradas ao produto que posteriormente serão testadas.

Essas atividades visam alcançar a funcionalidade associada a qualidade tão rápida quanto possível de ser realizada denotando condições a obtenção de versões úteis (alfa, beta e outros lançamentos de teste).

Validação

O foco desta fase é assegurar que o software esteja disponível para seus usuários finais. A Fase de Validação pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhados muito antes no ciclo de vida do projeto.

No fim do ciclo de vida da Fase de Validação, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição de fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Validação pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

As atividades realizadas durante uma iteração na Fase de Validação dependem da meta. Por exemplo, ao corrigir erros, normalmente bastam a implementação e o teste. Se, no entanto, novas características tiverem de ser adicionadas, a iteração será semelhante a uma da fase de construção, exigindo análise, design, etc.

A Fase de Validação entra quando uma baseline estiver desenvolvida o suficiente para ser implantada no domínio do usuário final. Isso normalmente requer que algum subconjunto usável do sistema tenha sido concluído com nível de qualidade aceitável e documentação do usuário, de modo que a transição para o usuário forneça resultados positivos para todas as partes.