-
segundo Pressman(7edição).pag.82
[...] o desenvolvimento ágil oferece benefícios importantes, no entanto não é indicado para todos os projetos, produtos, pessoas e situações.
o trecho citado casa com a ideia central da letra A. visto que, por ser um projeto um sistema grande, há uma complexidade totalmente diferente, cuja simplicidade dos modelos de desenvolvimentos ageis seriam inviaveis para manter o controle de um sistema grande. partindo então para um modelo de processo de software capaz de sustentar tal complexidade como UP / RUP"
-
Essa visão é reafirmada por Sommerville (9ª Edição, Pag. 41): "No entanto, devido a seu foco em pequenas equipes bem integradas, existem problemas em escalá-los para grandes sistemas."
-
O problema da letra E, ñ é o erro e sim a omissão de informações.
-
Qual é o erro da C?
-
Letra A: Certa. Metodologias ágeis, pelo fato de trabalharem com a entrega de pequenos incrementos, sobretudo, funcionais, não se preocupam com o padrão arquitetural do sistema como um todo, com o passar do tempo e o crescimento do sistema, isso pode se tornar um problema e a dificuldade para esse tipo de correção estrutural é muito grande.
Letra B: utilização de documentação não é estimulada pelas metodologias ágeis. Além disso, não é necessário que a equipe de desenvolvimento tenha conhecimento de toda a necessidade do projeto, esses requisitos podem ser esclarecidos de forma gradual e incremental.
Letra C: Existem processos de desenvolvimento de SW que são iterativos e incrementais mas não necessariamente são ágeis. O fato de um SW ser construído em pequenos blocos não significa que esse processo está sendo executado levando em consideração os princípios da agilidade, como por exemplo: despreocupação com documentação, foco nas pessoas, etc.
Letra D: Mais uma vez, documentação não deve ser foco das metodologias ágeis. Ademais, as poucas documentações que existem, como as histórias de usuários no XP, são feitas pelo próprio cliente e não pelo desenvolvedor.
Letra E: Essa alternativa me causou um pouco de confusão, mas acredito que o erro está na parte em que se fala sobre "objetivos de agilidade exigidos". As metodologias ágeis são, geralmente, adaptáveis e flexíveis. Soa estranho falar que existem objetivos de agilidade que DEVEM ser atingidos. De qualquer forma, é uma letra que eu poderia ter facilmente marcado.
-
Quanto ao item C o fato de existirem abordagem iterativas que não seja ágeis, como o RUP, não o anularia. Veja que em nenhum momento é afirmado que isso é uma característica exclusiva. O que o tornaria inválido é se existisse pelo menos uma onde "o sistema NÃO é construído em pequenos blocos, que irão compor uma versão a ser entregue aos usuários."
Agora se alguém conhecer poderia descreve-lo aqui, mas me parece que violaria os princípios1 e 3 do manifesto.
The Agile Manifesto is based on twelve principles:
1) Customer satisfaction by early and continuous delivery of valuable software
2) Welcome changing requirements, even in late development
3) Working software is delivered frequently (weeks rather than months)
4) Close, daily cooperation between business people and developers
5) Projects are built around motivated individuals, who should be trusted
6) Face-to-face conversation is the best form of communication (co-location)
7) Working software is the principal measure of progress
8) Sustainable development, able to maintain a constant pace
9) Continuous attention to technical excellence and good design
10) Simplicity—the art of maximizing the amount of work not done—is essential
11) Best architectures, requirements, and designs emerge from self-organizing teams
12) Regularly, the team reflects on how to become more effective, and adjusts accordingly
Agora quanto ao A, essa é uma afirmativa que tem sua validade, mas difícil cravá-la como 100% correta. Os métodos ágeis pregam times pequenos e isso poderia ser um limitante, mas há a possibilidade de usa-los em conjuntos com por exemplo um Scrum de Scrums.
-
Na boa, questão muito mal elaborada. Muito genérica essas assertivas.
Tanto a letra A, quanto a letra C podem estar corretas.
-
Li isso no pdf do curso do prof. Pedrosa e me deu confiança pra não marcar a c:
"As entregas são feitas através de pequenos releases (pedaços) de software funcionando"
Entendi que cada bloquinho seria algo funcional que poderia ser entregue ao usuário, mas é encaminhado para se juntar a outros bloquinhos e compor uma release que só será entregue qdo todos os bloquinhos estiverem prontos. Isso quebra a regra das entregas citada acima, pois gera uma espera por uma versão maior, com várias funcionalidades sendo entregues em conjunto.
-
a) Correto. Aqui temos a teoria e a prática: no início, tanto a teoria quanto a prática não recomendavam que as metodologias ágeis fossem aplicadas a sistemas grandes. No entanto, atualmente, isso já não é mais uma limitação. Hoje em dia, as metodologias ágeis adquiriram maturidade suficiente para desenvolver sistemas grandes e complexos. Porém, isso ainda está na teoria, por isso as questões ainda cobram.