1. Nome: Érika Santos
Curso: ADS
4º Semestre
Questionário – Parte 2
16
No início era comum a utilização do modelo cascata, que é um modelo estruturado e em que a
saída de uma etapa dá início a uma nova etapa.
Um dos graves problemas do modelo é sua abertura com relação a clientes e usuário no decorrer
das fases de desenvolvimento.
No modelo incremental, as partes do sistema são tratadas isoladamente e depois reunidas
quando completas.
A alternativa é desenvolver todo o sistema e realizar uma integração única.
17
O modelo iterativo é uma estratégia de planejamento de retrabalho onde o tempo de revisão e
melhorias é preestabelecido.
Sua diferença marcante em relação ao modelo incremental é que a saída de um incremento não
será necessariamente tratada como um refinamento futuro.
A ideia é desenvolver um software com modelo incremental e permitir que o desenvolvedor
aprenda com a fase inicial do sistema.
18
O engajamento com líderes, gerentes e comunidade de usuários;
Que os profissionais trabalhem bem em equipe e estejam comprometidos a aprimorarem
continuamente a qualidade e o custo-benefício dos projetos;
A configuração dos elementos essenciais para a refatoração e eliminação da lacuna técnica do
método escolhido;
E outros.
19
Podemos citar Kanban E XP (Extreme Programming).
O Kanban precisa de comunicação em tempo real e uma estrutura de trabalho definida.

2. Seus itens de trabalho devem ser representados em um quadro, permitindo que a equipe
visualize o estado de cada fase de trabalho a qualquer momento que necessário.
O modelo nasceu pela Toyota, quando a organização precisou alavancar a produção e controlar
o consumo de materiais.
Para o desenvolvimento de Software, auxilia no gerenciamento da carga de trabalho somada a
capacidade de equipe.
Isso permite transparência em processos, melhorias em planejamento, agilidade em saídas e
clareza quanto ao foco do sistema.
Extreme Programming é uma metodologia que visa à aplicação das consideradas boas práticas
na Engenharia de Software.
Um exemplo é o teste de software, já que procurar defeitos demanda muito tempo.
Sobre teste, o modelo XP prega testes constantes, e que o acompanhamento seja revisado,
refinado e atualizado.
Em outras palavras, é um modelo que considera tudo que pode ser considerado como bom.
Comparado ao Kanban, é diferente em termos de procedimento e acompanhamento, visto que
XP se preocupa ainda mais com o acompanhamento das partes e fases.
20
SCRUM é um modelo baseado em equipes, cada uma com suas respectivas atribuições, e um
ciclo a ser seguido.
O SCRUM procura elucidar processos e representar mudança de estados, tratar sobre
planejamento de produtos, e organizar o desenvolvimento de modo a obter um resultado
satisfatório.
Na metodologia SCRUM, as equipes participam de Sprints, que são reuniões baseadas nos
aspectos de projeto.
21
Participam Product Owner, Scrum Master e Time de Desenvolvimento.
O product owner é responsável por manter a integridade conceitual das novas funcionalidades,
bugs ou melhorias para que sigam a visão ideal de projeto.
O Scrum Master é um gerente ou líder técnico responsável pela equipe, e por promover reuniões
e remover obstáculos ao projeto.
E, por fim, o time de desenvolvimento é o responsável por entregar às tarefas necessárias a
entrega do produto.
22
O Sprint review mostra o que foi conseguido durante um Sprint e funciona como uma
demonstração de futuros incrementos.

3. O Sprint retrospective serve para indicar o que funcionou bem, o que pode ser melhorado e
quais atitudes tomarem.
23
Entre os artefatos SCRUM podemos citar Sprint Backlog e Product Backlog.
O product backlog serve para orientar tudo que uma aplicação necessita para ser entregue.
Indica o que foi tratado com o cliente, e as necessidades apontadas pela própria equipe.
O sprint backlog depende do product backlog, e tem base em reuniões para apontar tarefas a
serem entregues.
Um sprint pode durar em média até 8 horas.
24
Entre os desafios está o capital humano, pois a execução de métodos ágeis depende de
profissionais capazes de abstrair e coletar requisitos de cliente.
Ou seja, depende de treinamento e qualificação para a adequação do sistema as necessidades de
cliente e a um modelo que representa melhor retorno.
Também é impossível identificar com exatidão se o produto vai corresponder exatamente ao
planejamento, fazendo com que os modelos não sejam 100 % seguros.
É possível levar também em conta a proposta de novos requisitos pelo cliente e a necessidade de
alterações.
25
No acompanhamento do que está sendo proposto pela equipe versus planejamento.
Na identificação de necessidades e oportunidades com relação ao sistema.
Na possibilidade de reuniões mais produtivas e bem estruturadas.
Na proximidade de produto ao potencial ideal e com foco na qualidade e monitoramento
constantes.
Na adoção de boas práticas, para a entrega de um produto funcional.
26
A utilização de Ciclos de Desenvolvimento, onde há papéis, artefatos e cerimônias.
Os papéis indicam as responsabilidades em relação a requisitos, planejamento, processos e
desenvolvimento.
Os artefatos indicam procedimentos para gerenciar itens relacionados ao desenvolvimento de
produto, e envolvendo até mesmo a documentação.
As cerimônias indicam as reuniões que tratam da condição de desenvolvimento até a entrega.

4. 27
O arquiteto de Software deve ter um olhar apurado para enxergar além do que já foi proposto, e
para saber aplicar os modelos, técnicas e procedimentos corretos.
Isso tudo é importante, pois o cliente muitas vezes não tem conhecimento pleno sobre o que
venha a ser realmente viável e necessário em termos de adequação a estrutura de sua
organização.
Não significa fugir do que foi proposto, mas somar os requisitos pré-identificados a outras
oportunidades reconhecidas.
Quanto a modelos, técnicas e procedimentos, o arquiteto de software tem de saber com o que é
melhor lidar e como lidar.