A gerência de desenvolvimento de sistemas de uma empresa est...

Alternativa correta: B - caso de uso mais crítico deve ser atacado, preferencialmente, no final.

Para entender a questão, é essencial conhecer o processo de desenvolvimento de software baseado no Processo Unificado (PU), que é uma abordagem de desenvolvimento de software iterativo e incremental conduzida por casos de uso e centrada na arquitetura. Este processo divide o desenvolvimento em quatro fases principais: Iniciação, Elaboração, Construção e Transição.

A alternativa B é incorreta porque, no Processo Unificado, o desenvolvimento iterativo e incremental encoraja que os casos de uso mais críticos sejam tratados nas fases iniciais, especialmente na Elaboração, e não no final. Isso ocorre porque:

• Riscos elevados: As funcionalidades mais complexas ou críticas podem apresentar os maiores riscos técnicos e de negócios; lidar com elas cedo ajuda a mitigar esses riscos.
• Feedback precoce: Resolver os casos de uso críticos primeiro permite receber feedback mais cedo, o que é fundamental para alinhar as expectativas e refinar requisitos.
• Viabilidade técnica: Validar a abordagem arquitetural com os casos mais desafiadores assegura que a base da aplicação pode suportar toda a funcionalidade necessária.

Atacar os casos de uso críticos logo no início permite que ajustes significativos na arquitetura e no design do sistema sejam feitos quando o custo da mudança é relativamente baixo. Deixar para o final aumentaria os riscos e custos associados a mudanças significativas.

Portanto, iniciar o projeto trabalhando nos aspectos mais desafiadores e críticos é uma prática recomendada no Processo Unificado para se alcançar um desenvolvimento bem-sucedido e de menor risco.

A fase de elaboração possui como marca a arquitetura da solução, para validar a arquitetura é importante implementar o caso de uso mais critico.

Os casos de uso mais criticos, entenda-se mais dificil de serem resolvidos/implementados, geralmente vao ser o núcleo do sistema ou função mais importante, devem ser implementados primeiro. com isso o problema com maior risco de ser resolvido se resolve no comeco do projeto. Com isso desperdicios de tempo e dinheiro com o desenvolvimento de partes simples do projeto nao acontecem caso a equipe falhe em fazer o principal do projeto.

Os casos de uso mais críticos são atacados primeiro no RUP, com a justificativa de que eles definem a arquitetura, que deve ser estabilizada logo.

No XP as funcionalidades mais críticas são atacadas por último, com a justificativa de que os requisitos são instáveis e tudo pode ser mudado, então existe a chance de uma funcionalidade com grande impacto na arquitetura sofrer mudanças de requisito.