-
Questão confusa.
Os modelos ágeis não reconhecem que modificações representam um risco? Eu até entendo que eles se adaptem às mudanças, mas não não reconhecer o risco?? E eles rejeitam mudanças em estágio avançado??
-
A questão é bem capciosa, acho que na alternativa "a" o elaborador queria usar a lógica ~(A e B) = ~A e ~B. Supondo A falso e B falso, a negação da verdadeiro. No material que estudo estudo, diz que a mudança não é vista como risco, mas como algo necessário para construir algo com melhor qualidade, no caso do XP, "se refatorar é bom refatore ao extremo". Já na segunda oração, penso que como esses modelos são iterativos e incrementais, então torna-se correto afirmar que: "Não rejeitam aquelas (modificações) em estágios avançados do desenvolvimento...", ENTRETANTO, caberia recurso, pois depois do "Não", deveria ter ":", pois do jeito que se apresenta a lógica que fica é: ~A e B (NÃO A: reconhecem que... e B: rejeitam aquelas...), portanto, supondo A falso e B falso, temos que ~A = verdadeiro e B = falso, portanto, ~A e B = falso, invalidando, portanto a assertiva.
Obs.: As alternativas restantes, tornam-se falsas sem qualquer ambiguidade quando se usa o "Não".
-
Concordo com o Paulo. Se não reconhecem riscos porque os rejeitam em fase final de construção? Mal feita e maldosa.
-
Só dá pra saber que o não significa "marque a errada" depois de ler todas as opções. Achei bem sacana!
-
O cara que fez essa questão tem um problema cerebral grave. Marquei a A por eliminação, mas se fosse V ou F, seria complicado.
Eles reconhecem que modificações representam risco sim. O fato de aceitar as modificações desde o início é justamente para antecipar o risco.
-
Do manifesto ágil:
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
Fonte: http://www.manifestoagil.com.br/principios.html
-
acho que deve ter pensando assim:
Não reconhecem que modificações representam um risco; e Não rejeitam aquelas em estágios avançados do desenvolvimento, próximos da entrega da versão final; Já que o XP abraça as mudanças sem problemas e realizam mudanças em qualquer estágio, já que nos métodos ágeis é mais valorizado do que seguir um plano específico.
-
Alternativa A muito mal elaborada. É claro que por eliminação acabamos chegando a essa alternativa. Mas achar que entendemos essa afirmação como ~(A^B) é complicado. Até porque pelas Leis de "De Morgan" ~(A^B) seria (~A) v (~B). Resumindo:
A FCC queria que você entendesse a afirmação assim: não reconhecem que modificações representam um risco e não rejeitam aquelas em estágios avançados do desenvolvimento, próximos da entrega da versão final. (~A) ^ (~B).
Lembrando que as Leis de "De Morgan" são as seguintes:
"não (A e B)" é o mesmo que "(não A) ou (não B)"
"não (A ou B)" é o mesmo que "(não A) e (não B)".
-
Palhaçada essa questão, muito mal elaborada!
-
Ele quis tirar do http://agilemanifesto.org
http://agilemanifesto.org/principles.html
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
-
Todos já sabem que, em algumas questões da FCC, deve-se marcar a menos errada. No caso dessa questão a menos errada é a letra (a). As outras todas estão completamente erradas.
Infelizmente temos que desenvolver essa habilidade para fazer provas dessa banca :/
-
A versão em Português dos Princípios Ágeis não fala nada sobre 2 semanas até 2 meses (http://agilemanifesto.org/iso/ptbr/principles.html), por isso tinha marcado a alternativa (E). "Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.". Mesmo considerando a tradução não oficial que fizeram do inglês, ela está errada porque a expressão "couple of" pode ser traduzida como "alguns/algumas", que seria o mais correto neste contexto (conforme comprova a tradução oficial).
"Os modelos ágeis de desenvolvimento NÃO acreditam que a entrega de software funcionando com frequência, a cada 2 semanas até 2 meses, é a principal medida de progresso do desenvolvimento."