Please enable JavaScript.

Coggle requires JavaScript to display documents.

Modelos de Software - Coggle Diagram

- - - - A saída de uma fase é a entrada
        da(s) fase(s) seguinte(s)
        
        Fortemente influenciados pela
        Engenharia de Hardware
    - - Modelo Cascata
        
        Primeiro modelo de processo de software da
        história
        
        Propõe que, antes de produzir linhas de código: – Deve-se fazer análise e design detalhados para que, quando o código for efetivamente produzido, esteja o mais próximo possível dos requisitos do cliente– Ao final de cada fase, há uma atividade de revisão de documentação para que se avalie se o projeto de software pode passar para a fase seguinte
      - Modelo Cascata Dupla
        
        • Introdução de iterações (ciclos) entre cada fase – Voltar para corrigir problemas criados na fase anterior
  - - - Requisitos são priorizados, onde aqueles com a prioridade mais alta são incluídos nas versões (incrementos) iniciais
        
        Primeiros incrementos formarão o núcleo básico
        
        Se o desenvolvimento de um incremento é iniciado, seus requisitos são “congelados”, MAS os requisitos para incrementos posteriores podem continuar evoluindo
  - - - Desenvolve-se uma implementação inicial, expondo-a aos comentários do usuário
        
        Depois, refina-se esse resultado por meio de várias versões até que seja desenvolvido um sistema adequado
        
        Acomodam-se mudanças nos requisitos em desenvolvimento
    - - Sistema/modelo de sistema sem todos os elementosfuncionais, mas apenas com funcionalidades gráficas ealgumas básicas. Utilizado para aprovação de quemsolicita o software
    - - Processo é uma espiral, e cada volta ou ciclo é uma iteração, que funciona como um miniprojeto• Sem fases definidas
        
        Desenvolvimento e entrega de versões mais completas, como herança dos modelos incrementais
        
        • Natureza iterativa da prototipação nas primeiras versões
        
        Sistematização e controle do Modelo Cascata, por meio dos produtos de trabalho ao longo do trajeto na espiral
- - - - Conjunto de práticas leves e objetivas utilizadasem gestão de projetos de desenvolvimento desoftware
        
        Iterativa e incremental
      - Papéis
        
        Dono do produto
        
        Gerenciar as funcionalidades que serão implementadas
        
        Garantir o retorno sobre o investimento
        
        Definir a visão do produto
        
        Gerenciar a entrada de novos requisitos e sua ordem
        
        Gerenciar o plano de liberações de incrementos
        
        Gerenciar orçamento e riscos
        
        Aceitar ou rejeitar cada incremento entregue
        
        Scrum Master
        
        Orientar o dono do produto na criação e ordenação das funcionalidades do produto a implementar
        
        Garantir que as regras e os valores do Scrum estejam
        sendo cumpridos
        
        Utilizar técnicas de facilitação em reuniões com o dono
        do produto e com a equipe de desenvolvimento
        
        Atuar como líder do projeto, sem autoridade
        
        Equipe de desenvolvimento
        
        6 pessoas <= tamanho da equipe <=10 pessoas influencia
        da tomada de decisões
        
        Desenvolver os incrementos do produto, entregando-os
        ao final de cada iteração
        
        Realizar estimativas quanto ao tamanho dos itens da lista
        de funcionalidades a serem desenvolvidos
        
        Concordar ou não com as metas a serem cumpridas na
        construção de um incremento
        
        Sem papéis específicos, deve ser auto-gerenciável
      - Artefatos
        
        Backlog do produto
        
        Apenas o dono do produto (cliente ou seu representante) pode inserir, remover ou reordenar funcionalidades
        
        Lista construída pela equipe Scrum: dono do produto,
        scrum master e a equipe de desenvolvimento
        
        Não precisa ser completo no início
        
        Pode começar com funcionalidades mais evidentes, mas deve-se obter com o dono do produto mais informações sobre suas necessidades
        
        Na interação direta e contínua com o dono do produto é muito provável que funcionalidades mais relevantes surjam em relação àquelas do início do projeto
        
        Em geral, as funcionalidades de que se têm maior
        conhecimento são implementadas primeiro
        
        Backlog do sprint
        
        Representa o subconjunto de funcionalidades que será desenvolvido em cada iteração (ou sprint)
        
        Equipe de desenvolvimento define como o backlog do sprint será implementado, na forma de um plano, que deverá seguir um quadro de tarefas a fazer, em andamento, a verificar e concluídas
        
        Dono do produto compromete-se a não trazer mais funcionalidades para aquele sprint
        
        Incremento do produto
        
        Produto entregável de um sprint, preferencialmente
        pronto
        
        Dono do produto pode decidir se quer colocá-lo (ou não)
        em produção
        
        Essa decisão é tomada em uma reunião chamada de
        revisão do sprint
        
        Caso não concorde, alguma funcionalidade entregue no
        incremento pode retornar ao backlog do produto
        
        Eventos
        
        Sprint
        
        Iterações curtas de desenvolvimento do sprint backlog
        
        Duração média de 2 a 4 semanas
        
        Permite feedback constante do dono do produto
        
        Acomoda reuniões para planejar, acompanhar, revisar e
        retroalimentar a sprint
        
        Lista ordenada de funcionalidades (como requisitos ou
        histórias de usuários) a implementar em um projeto
    - - É a combinação de uma abordagem colaborativa, com
        um conjunto de boas práticas de engenharia de software.
        
        A proposta da XP não é ser uma metodologia radicalmente técnica e imediatista. O extremismo vem da proposta de usar ao máximo as boas práticas de engenharia de software já reconhecidos pela indústria.
      - Valores
        
        Comunicação: desenvolver software é muito mais do que saber programar: é entender as pessoas.
        
        Simplicidade: uma arquitetura simples é mais fácil de ser implementada do que uma complexa.
        
        Coragem: É necessário coragem para mudar, inovar, aceitar que não se sabe tudo e que desenvolvimento de software é uma atividade complexa.
        
        Feedback: Antecipe o feedback. Faça o cliente emitir suas opiniões sobre o software brevemente.
        
        Respeito: Encontrar culpados é uma forma eficiente de minar a sinergia da equipe. Criar oportunidades de aprendizado e colaboração valoriza os indivíduos e fortalece o comprometimento.
      - Práticas para o desenvolvimento
      - Sinergia entre práticas
      - Testes automatizados
      - Rafatorações
      - Programação pareada
      - Padronização do código
      - Propriedade coletiva
      - Repositório de código
      - Stand up Metting
      - Integração contínua
      - Build Ágil