Please enable JavaScript.

Coggle requires JavaScript to display documents.

Mapa Mental - INF014 - Coggle Diagram

- - - - O nome "cascata" foi atribuído em razão da sequência das fases, onde cada fase só começa quando a anterior termina; e da transmissão do resultado da fase anterior como entrada para a fase atual (o fim de cada fase resulta em um documento aprovado). Nesse modelo, portanto, é dada muita ênfase às fases de análise e projeto antes de partir para a programação, a fim de que o objetivo do software esteja bem definido e que sejam evitados retrabalhos
      - Etapas
        
        Análise de requisitos
        
        Projeto
        
        Codificação
        
        Testes
        
        Operação e manutenção
        
        Com o código pronto, é preciso testá-lo para verificar se ele realmente cumpre seu objetivo ou se houve algum erro. As falhas encontradas devem ser corrigidos pela equipe desenvolvedora antes de seguir para a próxima etapa.
        
        Nessa etapa, as pessoas programadoras codificam o software de acordo com os requisitos e as especificações do projeto. A duração dessa fase depende da quantidade de pessoas no time e também da complexidade e quantidade de funcionalidades do sistema.
        
        criação de um cronograma;
        
        definição de tarefas com base nos requisitos;
        
        estimativa da finalização de cada etapa;
        
        montagem do time de desenvolvimento;
        
        modelagem da interface e arquitetura do sistema
        
        Na primeira etapa é feito o levantamento de requisitos com o cliente, para entender suas expectativas e definir quais funcionalidades devem ser implementadas no sistema. É preciso que isso seja feito com cuidado para que o objetivo do software seja atingido, já que isso vai nortear todas as etapas seguintes.
        
        Desvantagens
        
        problemas financeiros devido à ultrapassagem do orçamento previsto;
        
        dificuldade em atender às expectativas dos usuários finais.
        
        dificuldade para cumprir o cronograma do projeto e os prazos de entrega;
  - - - A ideia é que a criação de um software seja pautada por vários ciclos curtos, em que funcionalidades são introduzidas, feedbacks coletados e requisitos revistos.
      - Vantagens
        
        escopo de software mais flexível;
        
        identificação precisa de erros e falhas durante a criação do sistema;
        
        redução de riscos a cada etapa do projeto;
        
        maior capacidade de modificar a direção de um projeto;
  - - - Do lado esquerdo do V ficam da análise de requisitos até o projeto, a codificação fica no vértice e os testes, desenvolvimento, implantação e manutenção, à direita
      - Etapas
        
        Lado esquerdo - antes da codificação
        
        Análise de requisitos
        
        Projeto do sistema
        
        Projeto do programa
        
        Lado direito - depois da codificação
        
        Testes de unidade e integração
        
        Testes de sistema
        
        Testes de aceitação
        
        Operação e manutenção
  - - - Cada iteração ou volta é dedicada a uma fase do processo de vida de um software (viabilidade do projeto, definição de requisitos, desenvolvimento e teste,...). Ao mesmo tempo, cada volta é seccionada em 4 setores
      - Etapas
        
        Definição de Objetivos
        
        desempenhos, funcionalidade, entre outros objetivos, são levantados. Visando alcançar esses objetivos são listadas alternativas e restrições, e cria-se um plano gerencial detalhado.
        
        Análise de Riscos
        
        as alternativas, restrições e riscos anteriormente levantados são avaliados. Neste setor (porém não apenas neste) protótipos são utilizados para ajudar na análise de riscos.
        
        Desenvolvimento e Validação
        
        um modelo apropriado para o desenvolvimento do sistema é escolhido, de acordo com o risco analisado no setor anterior (cascata, interativo,...).
        
        Planejamento da Próxima fase
        
        ocorre a revisão do projeto e a decisão de partir para a próxima fase.
  - - - Foca no desenvolvimento de software através da combinação e reuso de componentes, como partes menores formando um todo maior. Esses componentes podem ser substituídos e reutilizados como for mais interessante, Também é possível já comprar os componentes prontos, caso mais vantajoso para o projeto.
      - Componentes
        
        o componente é um elemento independente, que pode ser substituído e reusado, contudo, ele é significativo, pois tem uma função clara no contexto em que foi definido.
  - - - O objetivo dessa etapa é criar um modelo do produto final, que não precisa apresentar a qualidade técnica e o polimento do app finalizado. Na realidade, basta que essa versão transmita a ideia de usabilidade, estilo e propósito da sua solução.
      - Tipos
        
        Encenação
        
        Papel
        
        Volume
        
        O protótipo de volume é criado para ser apresentado e compartilhado. Portanto, já são modelos digitais, normalmente com alta fidelidade estética, pois servem para replicar a identidade visual da solução final, mesmo que não ofereça nenhuma funcionalidade real do produto finalizado.
        
        O bom e velho rascunho de papel e caneta. Embora seja um modelo mais simples, geralmente de baixa fidelidade, os protótipos de papel são excelentes na estruturação de uma ideia, justamente por serem tão práticos de elaborar. Esse é um modelo usado com frequência em software houses, durante a discussão de novas funcionalidades, interfaces e designs.
        
        Esse é um formato de prototipagem que aprimora as qualidades do modelo de volume, criando uma sequência de cenas que induzem o usuário à experiência de utilização do produto final. Um exemplo histórico dessa prototipagem é a keynote que lançou o primeiro iPhone ao mundo, apresentada por Steve Jobs em 2007.
        
        Ferramentas
        
        Adobe XD
        
        InVision
        
        Framer
        
        Axure.
  - - - Conceito
        
        Neste modelo, os requisitos são adquiridos em paralelo à evolução do sistema. O modelo evolutivo parte do princípio que o cliente não expõe todos os requisitos, ou os requisitos não são tão bem conhecidos, ou os requisitos ainda estão sofrendo mudanças. Desta forma, a análise é feita em cima dos requisitos conseguidos até então, e a primeira versão é entregue ao cliente. O cliente usa o software no seu ambiente operacional, e como feedback, esclarece o que não foi bem entendido e dá mais informações sobre o que precisa e sobre o que deseja (ou seja, mais requisitos).
  - - - Etapas
        
        Modelagem do negócio
        
        Modelagem dos dados
        
        Modelagem do processo
        
        Geração da aplicação
        
        Teste e Modificação
        
        1 more item...
        
        Essa é etapa em que todas as informações coletadas vão, de fato, serem transformadas em código para criar um protótipo testável do sistema
        
        os objetos de dados definidos na fase anterior são convertidos em informações necessárias para montar o fluxo de implementação das funções do negócio. Durante o percurso, otimizações e mudanças nos objetos de dados também podem ser feitas.
        
        estruturação dos dados do sistema. Ou seja, após analisar o fluxo de informações obtido na fase anterior, a equipe pode determinar quais são os objetos de dados cruciais para o negócio, separando-os em grupos de acordo com sua utilidade.
        
        fase de análise e negociação do projeto, na qual são definidos o escopo e os requisitos da aplicação.
  - - - Conceito
        
        Fases
        
        Concepção
        
        define o escopo do projeto, ou “business case”; onde é julgado se o projeto deve ir adiante ou ser cancelado.
        
        Elaboração
        
        elabora modelo de requisitos, arquitetura do sistema, plano de desenvolvimento para o software e identificar os riscos.
        
        Construção
        
        constrói o software e a documentação associada.
        
        Transição
        
        finaliza produto, define-se plano de entrega e entrega a versão operacional documentada para o cliente.
        
        É um modelo de processo iterativo e incremental, dividido em fases, orientado a casos de uso.
        O RUP usa templates que descrevem o que é esperado no resultado de cada fase ou cada iteração (IBM, 2004), identificando as competências e responsabilidades (arquiteto, analista, testador,...), as atividades e os artefatos.
- - - - :couple: :two_women_holding_hands: O Time Scrum :two_men_holding_hands:
        
        Eventos
        
        A Sprint
        
        :check: O Planejamento da Sprint
        
        :eight_spoked_asterisk: Máximo oito horas para uma Sprint de um mês de duração.
        
        :eight_spoked_asterisk: O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito.
        
        :eight_spoked_asterisk: O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box.
        
        CONCEITO
        
        :eight_pointed_black_star: É um time-boxed de um mês corrido ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado.
        
        :eight_pointed_black_star: São ciclos de tempo em que as pequenas partes do produto são planejadas, realizadas e entregue.
        
        :check: A Revisão da Sprint
        
        :eight_spoked_asterisk: É realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário.
        
        :eight_spoked_asterisk: O Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint.
        
        :eight_spoked_asterisk: Reunião informal
        
        :eight_spoked_asterisk: Duração de no máximo 4 horas para uma Sprint de um mês.
        
        :eight_spoked_asterisk: A apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração.
        
        :check: A Retrospectiva da Sprint
        
        :eight_spoked_asterisk: O Time Scrum inspeciona a si próprio e cria um plano para melhorias a serem aplicadas na próxima Sprint.
        
        :eight_spoked_asterisk: Ocorre depois da Revisão da Sprint e antes do planejamento da próxima Sprint.
        
        :eight_spoked_asterisk: Duração de no máximo 3 horas.
        
        :check: A Reunião Diária
        
        :eight_spoked_asterisk: É um evento time-boxed de 15 minutos para o Time de Desenvolvimento.
        
        :eight_spoked_asterisk: É mantida no mesmo horário e local todo dia para reduzir a complexidade.
        
        :eight_spoked_asterisk: O Time de Desenvolvimento planeja o trabalho para as próximas 24 horas.
        
        Os artefatos
        
        Transparência do Artefato
        
        Definição de “Pronto”
        
        :eight_pointed_black_star: É usado para assegurar quando o trabalho esta completado no incremento do produto.
        
        :eight_pointed_black_star: Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos.
        
        :eight_pointed_black_star: O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes.
        
        CONCEITO
        
        :eight_pointed_black_star: Representam o trabalho ou o valor para o fornecimento de
        transparência e oportunidades para inspeção e adaptação.
        
        O incremento
        
        CONCEITO
        
        :eight_spoked_asterisk: É a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores.
        
        O Backlog do Produto
        
        CONCEITO
        
        :eight_spoked_asterisk: É uma lista ordenada de tudo que é conhecido ser necessário no produto.
        
        O Backlog da Sprint
        
        CONCEITO
        
        :eight_spoked_asterisk: É um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
        
        CONCEITO
        
        :eight_pointed_black_star: São time-boxed, os quais têm a duração fixada e não pode ser reduzida ou aumentada. Garantir que a quantidade adequada de tempo seja gasta não permitindo desperdícios no processo.
        
        O Product Owner :silhouette:
        
        :eight_spoked_asterisk: Ou dono do produto, é o responsável por maximizar o valor do produto
        resultado do trabalho do Time de Desenvolvimento. É a única pessoa responsável por gerenciar o Backlog do Produto.
        
        O Time de Desenvolvimento :silhouettes:
        
        :eight_spoked_asterisk: Profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint.
        
        O Scrum Master :silhouette:
        
        :eight_spoked_asterisk: Ajuda todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.
      - :check: INSPEÇÃO
      - :check: TRANSPARÊNCIA
      - :check: ADAPTAÇÃO
    - - :eight_pointed_black_star: É um framework para desenvolver, entregar e manter produtos complexos. Dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível
  - - - :eight_pointed_black_star: Kanban é um sistema de controle e gestão do fluxo de produção em empresas e projetos que, através da gestão visual - uso de cartões coloridos(post-its) - , objetiva aumentar a eficiência da produção de uma empresa. Os cartões coloridos são afixados nos produtos, lugares comuns na empresa, murais e até nos computadores que possuem um módulo eletrônico do sistema. Essa facilidade de visualização e interpretação, faz com que a comunicação entre os funcionários seja muito mais rápida e efetiva, e todos saibam exatamente as tarefas que precisam ser feitas e as que já foram realizadas.
    - - Na atualidade, o quadro kanban ultrapassou os limites da indústria e passou a ser utilizado em diferentes áreas, como em equipes de marketing, prestação de serviços e desenvolvimento de softwares, funcionando como uma ferramenta de gestão de tarefas.
        
        A fabricante de automóveis Toyota desenvolveu o método Kanban na década de 1940, sendo classificado como uma parte do Sistema Toyota de Produção. O seu objetivo era promover o controle do estoque de materiais para que os produtos não excedessem e nem faltassem, trazendo equilíbrio para o seu estoque e linha de produção. Assim, por tratar-se de um sistema de controle e gestão de estoque e fluxo de peças, utiliza-se pequenos cartões coloridos, conhecidos como post-it, e que também recebe o nome de gestão visual, em razão do uso de cores como sinalizadores.
      - Os 4 Pilares
        
        Tipos
        
        :gear: Produção
        
        :pushpin: Os murais ou o software ficam disponíveis para todos os colaboradores responsáveis por executarem as tarefas naquela fase de produção. Os murais são divididos em 3 fases:
        
        :first_quarter_moon: 3 Fases
        
        :fast_forward: doing:
        
        1 more item...
        
        :no_entry: done:
        
        1 more item...
        
        :arrow_forward: to do:
        
        1 more item...
        
        :pushpin: Em cada uma das seções são afixados os cartões, que costumam conter uma breve explicação da tarefa, como o prazo para ser iniciada e finalizada e o nome do funcionário responsável.
        
        1 more item...
        
        :runner:Movimentação
        
        :pushpin: É utilizado por departamentos envolvidos em uma determinada tarefa, recebem uma notificação para iniciarem a produção ou aguardarem um alerta para realizá-la. Isto é, o ritmo de produção se torna proporcional ao padrão de consumo e ao giro dos itens. Quanto maior o consumo e giro, maior a quantidade produzida.
        
        :dart: Objetivos
        
        :pushpin: O Kanban pode ser considerado também como uma metodologia ágil exatamente por ter o objetivo de evitar a procrastinação e render mais no dia a dia. Isso acontece porque todo o sistema é pautado de uma forma organizada para tornar o workflow mais produtivo. Portanto, é um processo de melhoria contínua, onde o fluxo de trabalho segue por etapas de forma enxuta.
        
        :pushpin: É proporcionar um trabalho mais transparente e direcionado.
        
        :heart_eyes: Vantagens
        
        :bar_chart: De acordo com o The State of Agile, de 2018, 55% das empresas que optaram por adotar alguma metodologia ágil o fizeram para melhorar sua produtividade. Ou seja, melhorias estratégicas de negócios e produtividade são os pilares por trás da adoção de uma metodologia ágil.
        
        Otimiza a produtividade
        
        2 more items...
        
        :explode: Kanban + Scrum = ScrumBan
        
        O uso do scrum requer a identificação de uma lista de funcionalidades que devem ser feitas para que o produto atinja o objetivo projetado, que é chamada de Product Backlog e é traduzida em Sprints. É justamente nesse processo que o kanban pode ser adotado como um facilitador.
        
        1 more item...
        
        1 — Comece com o que você faz agora
        
        2 — Buscar mudanças evolucionárias e incrementais
        
        3 — Respeite o processo atual, papéis, títulos e responsabilidades
        
        4 — Liderança em todos os níveis
        
        :check: A melhoria contínua é uma missão de todos, por isso deve-se incentivar a participação ativa, inclusive com atos de liderança, de todos os colaboradores, não apenas de gerentes.Dessa forma, é possível identificar gargalos potenciais em seu processo. Ao corrigi-los, você otimiza o fluxo, reduz custos, maximiza a velocidade de entregas e aumenta o rendimento ideal.
        
        :check: Não há exigência de mudanças organizacionais. Ou seja, colaboradores que entregam bem, dentro dos conformes, continuam em suas funções. O objetivo é implementar, colaborativamente, as alterações, sem que haja aquele “medo” que costuma existir antes de mudanças na empresa.
        
        :check: Deve-se adequar através de pequenas e pontuais mudanças, evitando atritos dentro da equipe — já acostumada a um fluxo.
        
        :check: É corrigir o processo aos poucos, começando pela sua organização. O fluxo de trabalho a ser considerado deve ser o atual, evitando transformações que impactam a produtividade.
  - - - SIGLA
        
        CONCEITO
        
        :eight_pointed_black_star: É uma das práticas de desenvolvimento de software sugeridas por diversas metodologias ágeis. A ideia é fazer com que o desenvolvedor escreva testes automatizados de maneira constante ao longo do desenvolvimento. Mas, o TDD sugere que o desenvolvedor escreva o teste antes mesmo da implementação.
        
        Test Driven Development, ou Desenvolvimento Orientado a Testes.
    - - :pushpin: É testar uma única unidade do sistema. Geralmente, em sistemas orientados a objetos, essa unidade é a classe. A ideia é ter baterias de testes de unidade separadas para cada uma dessas classes e cada bateria preocupada apenas com a sua classe.
        
        :pushpin: Visam avaliar o comportamento de classes e métodos em específico
        
        :pushpin: Identificar quais são os comportamentos esperados dos métodos a serem desenvolvidos
      - Três Ciclos do TDD :recycle:
        
        Red
        
        :red_flag:Escrever um pequeno teste automatizado que, ao ser executado, irá falhar
        
        Green
        
        :green_apple: Implementar um código que seja suficiente para ser aprovado no teste recém-escrito
        
        Refactor/Blue
        
        :large_blue_circle: Refatorar o código, a fim dele ser melhorado, deixando-o mais funcional e mais limpo.
        
        Benefícios :moneybag:
        
        :pushpin: Qualidade externa do produto
        
        :pushpin: Mais segurança ao desenvolvedor na hora de mudanças
        
        :pushpin: Os testes automatizados, que rodam em questão de segundos, são executados o tempo todo. Caso algo pare de funcionar, o desenvolvedor é rapidamente notificado, e consegue corrigir o problema antes de mandar a versão para o cliente.
        
        :pushpin: Ajuda o desenvolvedor a escrever código de produção de qualidade
        
        Diferença do Uso TDD
        
        :pushpin: Obtém feedback do teste mais rápido.
        
        :pushpin: Divisão do trabalho em pequenas etapas. Quanto menos código escrito, menor será o custo de mudança.
        
        Produtividade :factory:
        
        Definição
        
        :pushpin: Linhas de código escritas com qualidade, de fácil manutenção, e que dão pouca (ou nada) de re-trabalho.
        
        Ferramentas :gear:
        
        .NET - NUnit
        
        1 more item...
  - - - :eight_pointed_black_star: O desenvolvimento de software enxuto é um conceito que enfatiza a otimização da eficiência e a minimização do desperdício no processo de desenvolvimento de software. O método propõe remover desperdícios para reduzir riscos e promover uma entrega mais ágil.
    - - O conceito de manufatura enxuta surgiu em meados do século 20 a partir de um processo de produção desenvolvido pela Toyota como parte de sua filosofia Toyota Way . A manufatura enxuta visava reduzir os defeitos do produto, eliminar o desperdício, aumentar a produtividade e incentivar a responsabilidade e a inovação. A abordagem acabou se espalhando para outras indústrias.
      - Os 7 Princípios
        
        Elimine o desperdício
        
        Construir com qualidade
        
        Amplie o aprendizado
        
        Adie o compromisso
        
        Entregue rápido
        
        2 more items...
        
        :pushpin: O objetivo é experimentar e aprender o máximo possível antes de se comprometer com decisões irreversíveis. Os desenvolvedores incorporam recursos e funcionalidades o mais tarde possível no processo para evitar ter que refazer o trabalho conforme o mercado muda.
        
        :pushpin: O conhecimento adquirido por um engenheiro de software deve ser compartilhado com todos os engenheiros da equipe de desenvolvimento de software. Isso ocorre por meio de revisão de código e compartilhamento em reuniões. Além disso, os engenheiros aprendem à medida que avançam e questionam suposições.
        
        :pushpin: Várias táticas são usadas para garantir que a qualidade seja incorporada ao processo Lean, como programação em pares e desenvolvimento orientado a testes
        
        :pushpin: Após cada iteração de desenvolvimento , os gerentes de projeto discutem os gargalos, identificam os desperdícios e desenvolvem um plano para eliminá-los.
        
        Benefícios :moneybag:
        
        Colaboração
        
        Melhoria continua
        
        Eficiência
        
        Flexibilidade
        
        2 more items...
        
        :pushpin: A abordagem Lean elimina o desperdício e entrega software rapidamente, tornando as organizações de desenvolvimento mais eficientes e reduzindo custos.
        
        :pushpin: O fluxo de trabalho incorpora comunicação constante com os clientes e feedback constante. Isso permite a melhoria contínua , ou Kaizen, em todas as partes da operação.
        
        :pushpin: Os princípios Lean amplificam o aprendizado e o respeito para incentivar a colaboração e o compartilhamento de conhecimento e evitar gargalos. As equipes têm o poder de tomar suas próprias decisões e trabalhar juntas no processo de tomada de decisão.
        
        Desafios
        
        Requisitos de treinamento da equipe
        
        Faltar métricas
        
        Sem limites
        
        2 more items...
        
        :pushpin: As equipes devem ser capazes de identificar o desperdício e medi-lo.
        
        :pushpin: As equipes e os membros da equipe devem ser treinados para que possam assumir o trabalho uns dos outros e se adaptar às mudanças nas iniciativas. Eles também devem ser capazes de organizar o trabalho e os deveres comerciais à medida que as prioridades mudam.
  - - - Tipos
        
        Crystal Clear
        
        Crystal Yellow
        
        Crystal Orange
        
        Crystal Orange Web
        
        Crystal Red
        
        2 more items...
        
        :pushpin: Tem também o tamanho de equipe de 21-40 membros onde os projetos que têm uma base de código em constante evolução que está sendo usada pelo público. Também é semelhante ao Crystal Orange, mas aqui eles não tratam de um único projeto, mas de uma série de iniciativas que requerem programação.
        
        :pushpin: Possui equipe de 21 a 40 integrantes, sendo dividida de acordo com suas habilidades funcionais. Aqui, o projeto geralmente dura de 1 a 2 anos e a liberação é necessária a cada 3 a 4 meses.
        
        :pushpin: Tem uma equipe pequena de 7 a 20 membros, onde o feedback é obtido de usuários reais. Esta variante envolve testes automatizados que resolvem bugs mais rapidamente e reduzem o uso de muita documentação.
        
        :pushpin: A equipe consiste de apenas 1 a 6 membros, o que é adequado para projetos de curto prazo em que os membros trabalham em um único espaço de trabalho.
      - :eight_pointed_black_star: A Crystal foca-se em princípios como as Pessoas, as Interações, a Comunidade, os Skills, o Talento e a Comunicação, fazendo com que o desenvolvimento de software corra da melhor forma. O core deste processo de desenvolvimento passa pela interação e simbiose que acontece entre as pessoas alocadas aos projetos e aos processos, de forma a tornar o desenvolvimento eficaz.
  - - - :eight_pointed_black_star: Feature Driven Development é uma metodologia ágil para desenvolvimento de softwares orientada pela modelagem, que se baseia no estudo de problemas e no entendimento dos processos interativos para propor soluções. Seu principal objetivo é entregar ao cliente um software funcional em tempo hábil.
      - Processos
        
        Desenvolver um modelo geral
        
        Gerar uma lista de funcionalidades
        
        Planejar por funcionalidade
        
        Modelar por funcionalidade
        
        Construir por funcionalidade
        
        1 more item...
        
        :pushpin: Assim como na primeira fase, nessa etapa é criada uma modelagem com as funcionalidades a serem desenvolvidas. A diferença dessa modelagem é que o programador chefe a cria de acordo com uma funcionalidade específica e a divide em classes, métodos e atributos.
        
        :pushpin: De acordo com a lista de funcionalidades é feito o planejamento de desenvolvimento delas. Para cada funcionalidade são designados programadores-chefe que ficarão responsáveis por algumas classes ou códigos.
        
        :pushpin: Nesta fase é criada uma lista de funcionalidades do sistema, descrevendo e identificando a área de domínio de cada uma delas. As funcionalidades são importantes para o processo porque cada uma é uma pequena tarefa que precisa ser implementada ao projeto, de modo que gere valor ao cliente.
        
        :pushpin: O primeiro momento é de conhecer para analisar o sistema e o contexto em que ele está inserido. A partir disso são estudados os domínios do sistema e um modelo geral é desenvolvido com base nesses estudos.
  - - - :eight_pointed_black_star: É uma metodologia leve para times de tamanho pequeno a médio, que desenvolva software em face a requisitos vagos que se modificam rapidamente.
      - Funcionamento
        
        :pushpin: É um método sistêmico para desenvolvimento de software. O processo inicia por um plano geral, ou seja, entender o problema como um todo, mas sem muitos detalhes e, posteriormente, reparte o problema em partes, para dar início ao seu desenvolvimento.
        
        Os 4 valores do XP
        
        Comunicação
        
        Simplicidade
        
        Feedback
        
        Coragem
        
        1 more item...
        
        :pushpin: É importante o feedback do cliente, por isso os ciclos curtos, a integração contínua etc.
        
        :pushpin: É um dos princípios do XP advindos do JIT. Assim, faça a coisa mais simples que pode funcionar, e lembrar que uma das filosofias do JIT é a eliminação de desperdício, assim, simplicidade é uma obrigação.
        
        :pushpin: Deve fluir constantemente através das técnicas a serem aplicadas no processo de desenvolvimento
        
        Práticas
        
        Jogo de planejamento
        
        Entregas frequentes
        
        Uso de metáforas
        
        2 more items...
        
        :pushpin: Durante a iteração de uma ou duas semanas, o que estiver com status de pronto deve ser entregue ao cliente, assim, a equipe recebe o feedback mais rapidamente. Não espere todo o projeto estar concluído, entregue frequentemente;
        
        :pushpin: é a prática que define o escopo a ser desenvolvido na próxima iteração.
  - - - Ciclos De Vida
        
        Pilares
        
        Metodologia Completa
        
        :pushpin: oferece todos os recursos necessários para um processo de software.
        
        Metodologia Customizável:
        
        :pushpin: adaptada de acordo com as reais necessidades da equipe e/ou, com as características inerentes de cada projeto.
        
        Metodologia Minimalista
        
        :pushpin: os processos são estruturados de forma a oferecer apenas seus elementos mais necessários (Papéis, Tarefas e Produtos de Trabalho).
        
        Concepção (Inception)
        
        Elaboração
        
        Construção (Construction)
        
        Transição (Transition)
        
        :pushpin: focada na transição do software para o ambiente do cliente e na obtenção da concordância dos stakeholders de que o desenvolvimento do produto está completo.
        
        :pushpin: foca no detalhamento dos requisitos, no desenho, na implementação e nos testes da maior parte do software.
        
        :pushpin: quando riscos arquiteturais significantes são tratados.
        
        :pushpin: onde os stakeholders e os membros da equipe colaboram para determinar o escopo e os objetivos do projeto, e determinar se o projeto deve ou não continuar.
      - Princípios
        
        :pushpin: Equilibrar as prioridades concorrentes para maximizar o benefício aos Stakeholders: promover práticas que permitam aos participantes do projeto e aos stakeholders desenvolver uma solução que maximize os benefícios para o stakeholder, e que seja compatível com as restrições impostas ao projeto.
        
        :pushpin: Colaborar para alinhar os interesses e compartilhar o entendimento: promover práticas que estimulem um ambiente de equipe saudável, permitam a colaboração e desenvolvam uma compreensão compartilhada do projeto.
        
        :pushpin: Focar na arquitetura, o mais cedo possível, para reduzir o risco e organizar o desenvolvimento: promover práticas que permitam à equipe focar na arquitetura para reduzir o risco e organizar o desenvolvimento.
        
        :pushpin: Evoluir para continuamente obter feedback e promover melhorias: promover práticas que permitam à equipe obter feedback dos stakeholders, o mais cedo possível e de forma contínua, e demonstrar valor incremental para eles.
      - O Processo Unificado Aberto, do inglês Open Unified Process (OpenUP) [1], é uma parte do Eclipse Process Framework (EPF), um framework de processo open source desenvolvido dentro da Eclipse Foundation. Ele fornece as melhores práticas de uma variedade de opiniões de líderes em desenvolvimento de software e da vasta comunidade de desenvolvimento de software que cobre um conjunto diverso de perspectivas e necessidades de desenvolvimento.
        OpenUP preserva as características essenciais do RUP/Unified Process, que inclui desenvolvimento iterativo e incremental, casos de uso e cenários na direção do desenvolvimento, gerenciamento de riscos e a abordagem de arquitetura-centrica. A Open UP é uma metodologia livre de ferramentas e de baixo formalismo que pode ser estendido a uma variada gama de tipos de projetos e não apenas desenvolvimento de software.
  - - - Manifesto Ágil
        
        O Manifesto Ágil é uma declaração de valores e princípios essenciais para o desenvolvimento de software. Embora seja relacionada a um setor tecnológico, os impactos do Manifesto e do desenvolvimento ágil proposto por ele são inegáveis para empresas de diversos setores.
        
        :scroll: Histórico do Movimento Ágil
        
        O documento foi criado em fevereiro de 2001, quando 17 profissionais, que já praticavam métodos ágeis como XP, DSDM, Scrum, FDD etc, se reuniram nas montanhas nevadas do estado norte-americano de Utah. Decidiram escrever um documento que serviria como grito de guerra aos novos processos de desenvolvimento de software. Nele estaria contido a declaração das crenças e valores que aquelas 17 pessoas possuíam.
        
        Os 4 valores Manifesto Ágil :diamond_shape_with_a_dot_inside:
        
        1 more item...
- - - - O objetivo da engenharia de linha de produtos de software é a reutilização estratégica em larga escala da funcionalidade em vários produtos de software dentro de um domínio, de modo que diferentes configurações de software adaptadas para diferentes clientes ou casos de uso sejam derivadas de uma base de código comum
    - - Redução dos Custos de Desenvolvimento
      - Aumento da Qualidade
      - Ciclos de desenvolvimento mais curtos
      - Melhor manutentibilidade
      - Melhora no calculo da precificação
- - - - A integração contínua (CI) é uma estratégia de desenvolvimento de software onde os desenvolvedores confirmam continuamente o código em pequenos incrementos (pelo menos diariamente, ou mesmo várias vezes ao dia), que é automaticamente compilado e testado antes de ser mesclado com o repositório compartilhado.
        
        Caracteristicas
        
        Repositorio Unico e Compatilhado
        
        Interação humana
        
        Teste unitarios
        
        Ferramentas
        
        Git
        
        NUnit ou JUnit
    - - Implantação contínua é uma extensão da integração contínua, pois implanta automaticamente todas as alterações de código em um ambiente de teste e/ou produção após o estágio de compilação.
        Isso significa que, além dos testes automatizados, você tem um processo de lançamento automatizado e pode implantar seu aplicativo a qualquer momento clicando em um botão.
        
        Caracteristicas
        
        Não há intervenção humana
        
        Teste automaticos
        
        Deploy instantaneo
        
        Ferramentas
        
        Docker
        
        Ant, Maven ou Gradle
  - - - Jenkins
      - CircleCI
      - Red Hat Ansible Automation Platform
      - Azure DevOps Server