3. Estratégias de Engenharia de Software

3.1 Estratégia Priorizada

Critério	RAD (Rapid Application Development)	XP (Extreme Programming)
Organização dos Requisitos	- Requisitos de Negócio - Modelos de Interface - Modelos de Dados - Processos	- Histórias de Usuário - Critérios de Aceitação
Principais Forças	- Redução no tempo de elicitação - Visualização precoce - Alta satisfação do usuário - Detecção precoce de problemas	- Alta adaptabilidade - Feedbacks rápidos e contínuos - Validação precoce - Redução da documentação
Principais Limitações	- Menos adequado para sistemas complexos - Risco de foco excessivo em interfaces - Dependência de ferramentas CASE - Necessidade de comprometimento intenso	- Forte dependência do cliente - Dificuldades com documentação para conformidade - Escalabilidade limitada
Cenários Adequados	- Sistemas corporativos - Projetos com prazos curtos - Requisitos difíceis de articular - Validação de conceito	- Projetos com requisitos voláteis - Ambientes com foco em feedback rápido - Sistemas que evoluem incrementalmente - Equipes pequenas com cliente presente
Tendências Atuais	- Integração com DevOps - Adoção de ferramentas low-code/no-code - Adaptação mobile-first - Evolução para abordagens híbridas com métodos ágeis	- Integração com outros frameworks ágeis (Scrum, Kanban) - Adoção de práticas técnicas específicas - Adaptações para equipes distribuídas

A escolha do RAD (Rapid Application Development) como estratégia prioritária baseia-se nos seguintes fatores:

Necessidade de entregas rápidas e visuais
O projeto envolve funcionalidades com forte apelo visual e foco na experiência do usuário. O RAD facilita a entrega de protótipos de alta fidelidade desde as primeiras iterações, permitindo validação rápida com o cliente.
Disponibilidade intermitente do cliente
Embora o XP dependa de contato constante com o cliente, a realidade do projeto mostrou que o cliente nem sempre estaria disponível para feedback contínuo. O RAD se adapta melhor a essa limitação ao concentrar interações em ciclos de validação específicos.
Mudanças frequentes no escopo
O projeto apresentou alterações frequentes nos requisitos e prioridades. O RAD lida bem com esse tipo de incerteza, já que seus ciclos são iterativos e centrados em refinar os requisitos com base em entregas contínuas.
Curto prazo de execução do projeto
Considerando o calendário acadêmico, o tempo disponível para desenvolvimento é limitado. O RAD é adequado para projetos com prazos curtos, pois foca em entregas incrementais e ajustáveis sem a necessidade de ciclos de desenvolvimento longos.

MARSICANO, George. Requisitos de Software: Fundamentos, Evolução e Praticas 2025. Material interno não publicado.

Data	Versão	Descrição	Autor	Revisores
19/04/2025	1.0	Criação do documento	Cayo Alencar	Igor Daniel
26/05/2025	1.1	Atualizações e alterações	João Filipe, Pedro Henrique	Cayo Alencar
13/07/2025	1.2	Atualizações e alterações	Samara Alves	Pedro Henrique