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.
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.
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.
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.

Erika questionario pt 2 (Eng Software III).

  • 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 detrabalho 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 retrospectiveserve 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 deSoftware 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.