diff --git a/docs/base/references.md b/docs/base/references.md
index cc14e24..b3cadfa 100644
--- a/docs/base/references.md
+++ b/docs/base/references.md
@@ -10,10 +10,13 @@
[Paul] Johan Paul (2008). Quantitative Approach for Lightweight Agile Process Assessment. Acesso: 6 de novembro de 2024.
+[Kissflow] Team Kissflow (2024). What is Rapid Application Development (RAD)? An Ultimate Guide for 2024. Link: Acesso: 22 de novembro de 2024.
+
---
## Histórico de Versão
Data | Versão | Descrição | Autor | Revisores
---------- | ------ | ----------------------------------------------------------------------------------------------- | ------------- | -----------------------
-09/11/2024 | 1.0 | **Adição de Referências:** Pesquisa de Mercado + Processos de Engenharia de Software | Mateus Vieira | João Lucas, Pedro Gondim
\ No newline at end of file
+09/11/2024 | 1.0 | **Adição de Referências:** Pesquisa de Mercado + Processos de Engenharia de Software | Mateus Vieira | João Lucas, Pedro Gondim
+22/11/2024 | 1.1 | **Adição de Referências:** Processos de Engenharia de Software (RAD) | Mateus Vieira | Caio Lamego
diff --git a/docs/base/strategy.md b/docs/base/strategy.md
index e34a549..1bd8b25 100644
--- a/docs/base/strategy.md
+++ b/docs/base/strategy.md
@@ -2,56 +2,59 @@
**3.1 Estratégia Priorizada**
-- **Abordagem de Desenvolvimento de Software:** Híbrida
-- **Ciclo de Vida:** Iterativo
-- **Processo de Engenharia de Software:** Spiral
+- **Abordagem de Desenvolvimento de Software:** Ágil
+- **Ciclo de Vida:** Ágil
+- **Processo de Engenharia de Software:** RAD
**3.2 Quadro Comparativo**
-| Características | Spiral | Processo Unificado |
-|------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **Abordagem Geral** | Iterativo e baseado em ciclos de prototipação e análise de risco. | Iterativo, incremental com entregas constantes e revisões frequentes |
-| **Foco em Arquitetura** | Forte ênfase na identificação e mitigação de riscos arquiteturais logo no início dos ciclos, visando continuar ou interromper a construção. | Destaque na definição de uma arquitetura sólida durante as fases iniciais, orientando todo o desenvolvimento. |
-| **Estrutura de Processos** | Organizado em ciclos ou espirais, com fases de planejamento, análise de riscos, engenharia e avaliação. | Dividido em quatro fases (Concepção, Elaboração, Construção, Transição), cada uma com atividades específicas e incrementais |
-| **Flexibilidade de Requisitos** | Os requisitos são tratados como fixos para cada ciclo de desenvolvimento. | Permite ajustes nos requisitos a cada iteração, incorporando feedback contínuo. |
-| **Colaboração com Cliente** | Colaboração frequente com o cliente para revisão dos protótipos e definição de novas direções. | Interação contínua com clientes e usuários, especialmente nas fases de Concepção e Transição. |
-| **Complexidade de Processo** | Processo formal e complexo devido à análise de riscos e prototipação em cada iteração. | Processo estruturado e formal, exigindo conhecimento detalhado das fases e fluxos de trabalho. |
-| **Qualidade Técnica** | A qualidade técnica é garantida a cada ciclo por meio da análise de riscos e validação da arquitetura e funcionalidades. | Cada iteração produz um sistema funcional e testado, garantindo uma qualidade próxima ao produto final. |
-| **Práticas de Desenvolvimento** | Uso de prototipação e análise de riscos para guiar o desenvolvimento, com foco menor em práticas ágeis e maior em validação incremental. | Utiliza casos de uso e UML para modelagem, estruturando requisitos e implementações claramente, além de testes rigorosos para garantir a qualidade do produto. |
-| **Adaptação à CCAA** | Ideal para projetos complexos de longo prazo que exigem mitigação de riscos e maior feedback dos clientes. Pode ser adaptado para menor escala. | Ideal para projetos que exigem uma arquitetura bem estruturada desde o começo, com ciclos iterativos e incrementais, permitindo ajustes e melhorias contínuas. |
-| **Documentação** | Exige documentação clara e detalhada para cada fase e protótipo, incluindo plano de risco, justificativas e soluções. | Documentação detalhada, especialmente durante a Análise e Projeto, para suporte a equipes. |
-| **Controle de Qualidade** | Controle íntegro a partir da análise de risco em cada iteração do processo. | Inclui testes rigorosos em cada iteração e monitoramento contínuo dos riscos, identificados e mitigados nas fases iniciais. |
-| **Escalabilidade** | Adequado para projetos grandes em que a mitigação de riscos é crucial. | A estrutura modular permite que o sistema cresça com novas funcionalidades em ciclos futuros. |
-| **Suporte a Equipes de Desenvolvimento** | Suporte para equipes maiores e estruturadas com papéis bem definidos, com controle maior sobre os ciclos. | Suporta equipes maiores com papéis bem definidos, exigindo controle detalhado sobre o progresso em cada fase do projeto, promovendo organização e eficiência. |
+| Características | RAD (Rapid Application Development) | ScrumXP |
+|------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **Abordagem Geral** | Enfatiza o desenvolvimento rápido com prototipação e iterações curtas para atender rapidamente às mudanças nos requisitos do cliente. | Baseado em metodologias ágeis, combina Scrum (gestão de projetos) com práticas de desenvolvimento do XP (Extreme Programming) para entrega contínua de valor. |
+| **Foco em Arquitetura** | Arquitetura inicial mínima; foca em desenvolver rapidamente protótipos funcionais para validação. | Evolução contínua da arquitetura, com revisões frequentes e refatorações para manter a qualidade e a simplicidade. |
+| **Estrutura de Processos** | Dividido em quatro fases principais: planejamento de requisitos, design rápido, construção e implementação. | Estruturado em Sprints (Scrum), complementado por práticas técnicas do XP, como programação em pares e TDD. |
+| **Flexibilidade de Requisitos** | Alta flexibilidade; os requisitos podem mudar frequentemente com base no feedback dos protótipos e usuários. | Os requisitos são priorizados e refinados continuamente, permitindo mudanças rápidas e bem gerenciadas. |
+| **Colaboração com Cliente** | Envolvimento constante do cliente, que participa ativamente das validações dos protótipos e revisões. | Colaboração próxima e contínua com o cliente ou Product Owner para alinhar expectativas e priorizar entregas. |
+| **Complexidade de Processo** | Processo simples e flexível, focado em velocidade e adaptação, mas exige coordenação para evitar desorganização. | Processo altamente iterativo, mas com regras claras e rituais como planejamento, revisões e retrospectivas. |
+| **Qualidade Técnica** | Foco na entrega rápida; a qualidade técnica pode ser sacrificada em favor de prazos curtos. | Qualidade técnica é prioridade, com práticas como TDD, revisões de código e entrega incremental. |
+| **Práticas de Desenvolvimento** | Prototipação rápida, desenvolvimento iterativo, e foco em entrega rápida com feedback frequente. | Programação em pares, TDD, integração contínua, refatoração contínua e pequenas entregas frequentes. |
+| **Adaptação à CCAA** | Ideal para projetos de curto prazo e baixa complexidade, onde rapidez é mais importante que processos rígidos. | Adequado para equipes de pequeno a médio porte e projetos dinâmicos, com alta prioridade em feedback rápido e entregas contínuas. |
+| **Documentação** | Simples documentação no processo; o foco está no protótipo funcional, mas na fase final há especificação técnica completa | Documentação mínima, concentrando-se em histórias de usuário e critérios de aceitação escritos no backlog. |
+| **Controle de Qualidade** | A qualidade é validada principalmente por meio do feedback do cliente em protótipos e entregas rápidas. | Qualidade garantida por práticas de desenvolvimento técnico rigorosas (XP) e revisões regulares. |
+| **Escalabilidade** | Limitado a equipes pequenas e projetos simples devido à informalidade e ao foco em entregas rápidas. | Pode escalar com adaptações, mas é mais adequado para projetos ágeis com equipes pequenas a médias. |
+| **Suporte a Equipes de Desenvolvimento** | Suporte limitado para grandes equipes; promove colaboração intensa, mas exige comunicação direta e constante. | Estrutura altamente colaborativa e organizada, promovendo comunicação eficaz e trabalho em equipe. |
**3.3 Justificativa**
-Com base nas características do projeto e nas necessidades discutidas com a cliente, foi escolhida uma abordagem híbrida para o desenvolvimento pelos seguintes motivos:
+Com base nas características do projeto e nas necessidades discutidas com a cliente, foi escolhida uma abordagem baseada no **RAD (Rapid Application Development)** pelos seguintes motivos:
-- **Definição Fixa dos Requisitos e Documentação Assertiva:**
-Após conversa com a cliente, ficou claro que todos os requisitos devem ser definidos como fixos desde o início. Há também a necessidade de uma documentação precisa das modificações realizadas ao longo do desenvolvimento, para que possam ser mapeadas entre as reuniões.
+- **Prototipação Iterativa para Validação Contínua:**
+ A cliente expressou preferência por validar partes do sistema conforme ele é desenvolvido. O RAD facilita esse processo, entregando protótipos iterativos que podem ser avaliados e ajustados de maneira eficiente sem comprometer os requisitos principais.
-- **Flexibilidade no Modelo de Comunicação e Feedbacks:**
-O modelo de comunicação entre a equipe e a cliente foi definido como flexível, sem a obrigatoriedade de reuniões pré-datadas ou um plano de entregas fixo. Em vez disso, será feito um acompanhamento contínuo das mudanças até a entrega final e única da aplicação.
+- **Documentação Objetiva:**
+ Apesar do foco na entrega rápida, o projeto exige documentação que registre as mudanças e decisões tomadas durante o desenvolvimento. O RAD foca nos protótipos, portanto, indica exatamente a ideia de documentação mais simples e assertiva, equilibrando a produção com os registros.
-- **Ciclo de Vida Iterativo:**
-Ao longo do projeto, decidiu-se que o ciclo de vida mais adequado para o desenvolvimento é o Iterativo, permitindo revisões e feedbacks em partes do projeto. Essa abordagem possibilita adaptações graduais, garantindo flexibilidade para alterações ao longo do trabalho e culminando em uma única entrega ao final.
+- **Flexibilidade no Cronograma de Comunicação:**
+ Embora o modelo RAD seja iterativo, a comunicação foi definida como flexível, sem a obrigatoriedade de reuniões regulares. Esse alinhamento reforça o foco em ciclos rápidos de desenvolvimento com entregas intermediárias úteis para avaliação.
-- **Seleção do Modelo Spiral:**
-Considerando a maior parte das características do projeto, foi selecionado o modelo Spiral. Esta escolha se justifica pelos requisitos fixos e pelo foco na produção de protótipos, que serão aprimorados com base nos feedbacks da cliente. Esse modelo permite que cada etapa seja executada com segurança, minimizando os riscos de interrupção.
+- **Simplicidade no Controle de Qualidade:**
+ O modelo RAD prioriza o feedback do cliente em relação aos protótipos, garantindo que as entregas estejam alinhadas às expectativas sem introduzir processos complexos de validação.
+
+**Observação:** O RAD tem a ideia dos requisitos variáveis de acordo com os feedbacks do cliente. Entretanto, para esse projeto vamos modificar essa característica, pois a cliente já tem uma ideia bem definida do que deseja. Portanto, os requisitos serão fixos e não sofrerão alterações durante o desenvolvimento.
---
## 📚 Referências
-- **Eternal Sunshine Of The Mind (2013). The Spiral Model.** Link.
Acesso em: 6 de novembro de 2024.
+- **Team Kissflow (2024). What is Rapid Application Development (RAD)? An Ultimate Guide for 2024.** Link. Acesso em: 22 de novembro de 2024.
-- **Johan Paul (2008). Quantitative Approach for Lightweight Agile Process Assessment.**
Acesso em: 6 de novembro de 2024.
+- **Johan Paul (2008). Quantitative Approach for Lightweight Agile Process Assessment.** Acesso em: 6 de novembro de 2024.
## Histórico de Versão
-Data | Versão | Descrição | Autor | Revisores
----------- | ------ | ---------------------------------------------------------------------- | -------------------------- | ----------------------------------------
-06/11/2024 | 0.1 | Definição da abordagem, ciclo e processo junto ao quadro comparativo | Mateus Vieira, Caio Lamego | João Lucas, Pedro Gondim, Daniela Alarcão
-09/11/2024 | 0.2 | Finalização da justificativa para o processo de Engenharia de Software | Mateus Vieira, João Lucas, Pedro Gondim | Caio Lamego, Daniela Alarcão
-14/11/2024 | 0.3 | Referências | Daniela Alarcão |
+Data | Versão | Descrição | Autor | Revisores |
+---------- | ------ | ---------------------------------------------------------------------- | -------------------------- | ----------------------------------------- |
+06/11/2024 | 0.1 | Definição da abordagem, ciclo e processo junto ao quadro comparativo | Mateus Vieira, Caio Lamego | João Lucas, Pedro Gondim, Daniela Alarcão |
+09/11/2024 | 0.2 | Finalização da justificativa para o processo de Engenharia de Software | Mateus Vieira, João Lucas, Pedro Gondim | Caio Lamego, Daniela Alarcão |
+14/11/2024 | 0.3 | Referências | Daniela Alarcão | |
+22/11/2024 | 1.0 | Revisão da escolha de processo e concretização | Mateus Vieira | Caio Lamego |