Você está na página 1de 1

2.

1 -
2.1.1 - Modelo em cascata, pois este dominio é bem específico, portanto bem
estabelecido antes de ser criado, alem de que um sistema para um carro pode ser
considerado um sistema embarcado e tambem um sistema critico
2.1.2 - Modelo evolucionario - por ser um software com realidade virtual,
pode ser dificil especificar o dominio, portanto a prototipacao pode ser a chave
para desvendar a vontade do cliente neste quesito e ir desenvolvendo conforme as
aprovacoes do cliente
2.1.3 - Orientado a reuso, por conta de ja existirem dados antigos e precisar
transpassar para o modelo novo, deve-se reaproveitar o que ja esta pronto,
principalmente a base de dados em uma linguagem universal
2.1.4 - Modelo de Prototipação - pois é focado na interface do usuário, já
que este sistema tende a ser mais interativo com o usuário e necessita de
protótipos navegáveis

2.2
Porque as tarefas mais importantes do sistema tendem a receber mais
prioridade no processo de criação do software, além de que as entregas são feitas
de forma incremental, ou seja, as funcionalidades vem chegando aos poucos mas já
funcionando para receber o feedback do cliente e a validação do software ocorre
mais rapidamente.

2.3
Para ir testando ao mesmo tempo que desenvolve, assim a validação do sistema
ocorre de forma rápida, pois as tarefas são desenvolvidas em paralelo

2.4
É importante pois na hora de desenvolver um software você deve levar em
consideração o que o cliente está pedindo, mas como profissional você deve saber
que nem tudo o que o usuário pede pode ser viável para o sitema, então deve haver
um intermédio entre a vontade do cliente e o que ele precisa e os requisitos do
sistema para funcionar da melhor maneira possível

2.6
Manter a Manutenibilidade em dia, focando neste quesito você consegue lidar
com mudanças no sistema, utilizar um método de arquitetura mais volátil, utilizaçã
de metodologias ageis durante o processo, pois é necessário rever os requisitos e
já implementar as novas mudanças o quanto antes. Tambem se pode usar o
desenvolvimento em espiral, já que o processo pode ser revisto e os requisitos
podem ser replanejados de forma rápida

2.7
Porque é pouco estruturado e se tem pouca visibilidade do processo

2.8
O estouro de prazos e aumento significativo dos custos podem ser uma das
razões, já que o processo e os requisitos serem replanejados toma tempo e dinheiro
a mais do cliente.

2.9

Você também pode gostar