Alternativa A
A alternativa A está correta porque destaca o pilar central da Metodologia RAD: a colaboração intensa com o usuário final.
O que é a Metodologia RAD?
A sigla RAD significa Rapid Application Development (Desenvolvimento Rápido de Aplicações). Ela foi criada como uma alternativa ágil aos modelos tradicionais (como o Cascata/Waterfall), focando na velocidade de entrega e na qualidade do produto através de prototipagem iterativa.
Para que essa velocidade seja alcançada sem perder o foco nas necessidades reais, a participação ativa dos usuários é obrigatória durante todo o ciclo.
Análise Detalhada das Alternativas
Vamos analisar ponto a ponto para entender o raciocínio:
- Alternativa A (Correta):
- Por que certa? O RAD utiliza técnicas como JAD (Joint Application Development), que são reuniões intensivas onde desenvolvedores e usuários trabalham juntos para definir requisitos e validar protótipos rapidamente. Diferente do modelo tradicional, onde o usuário muitas vezes só vê o sistema pronto no final, no RAD ele é parte do processo de construção.
- Alternativa B (Incorreta):
- Embora a modularização seja uma boa prática de engenharia de software em geral, dizer que RAD e métodos tradicionais se assemelham apenas nisso não define uma característica distintiva ou fundamental do RAD. Além disso, o RAD enfatiza fortemente a reutilização de componentes pré-existentes, o que vai além da simples modularização.
- Alternativa C (Incorreta):
- Para atingir a rapidez, o RAD exige muitas reuniões e workshops. A ideia é resolver dúvidas e problemas imediatamente através do contato direto. Dizer que há "poucas reuniões" contradiz a natureza colaborativa da metodologia.
- Alternativa D (Incorreta - Selecionada na imagem):
- Esta é a armadilha comum. Descrever requisitos fixos desde o início é a marca do modelo Cascata (Waterfall). O RAD é iterativo, o que significa que os requisitos podem (e devem) ser refinados e alterados à medida que novos protótipos são apresentados e validados pelos usuários. Travar os requisitos iria contra o objetivo de agilidade e adaptação do RAD.
- Alternativa E (Incorreta):
- Uma limitação conhecida do RAD é a dificuldade em lidar com projetos extremamente complexos e de grande escala. Devido à ênfase na velocidade e na falta de documentação formal extensiva, projetos muito grandes tendem a acumular dívida técnica e problemas de manutenção sob o RAD.
Conclusão
A essência do RAD reside na interatividade e na flexibilidade. A necessidade de validação constante dos protótipos torna a colaboração entre desenvolvedores e usuários um requisito indispensável, tornando a Alternativa A a única afirmação verdadeira sobre a metodologia.