Please enable JavaScript.
Coggle requires JavaScript to display documents.
Modelos de processo de software - Coggle Diagram
Modelos de processo de software
Prototipação
Entender os requisitos do usuário para entender melhor os requisitos do sistema
Permite a criação de um modelo (Protótipo) do produto final
Obtenção de requisitos
Desenvolvedor e cliente juntos para definir objetivos gerais do software
Representação das partes visíveis do software
Implementação do projeto
Cliente e desenvolvedor avaliam o protótipo
Cliente e desenvolvedor refinam juntos o protótipo
Após concluir o protótipo, construir a versão final a partir dele
Pontos negativos
Prototipo não tem a preocupação com manutenibilidade
RAD
Os requisitos devem ser bem entendidos e o alcance do projeto restrito
Utilizado principalmente em aplicações de sistema de informação
Uma função principal pode ser direcionada para uma equipe separada e então integrada para formar o todo
Definição
RAD (Rapid Application Development) é um modelo sequencial linear que foca em um ciclo de desenvolvimento muito curto
O desenvolvimento rápido é obtido usando uma abordagem de construção voltada em componentes
Pontos negativos
Exigência de pessoas para todas as equipes
Exigência de que desenvolvedores e clientes estejam focados e determinados com as atividades de "fogo-rápido" para terminar o projeto em um prazo curto
Nem todos os projetos são apropriados para o RAD
Evolutivos
Incremental
Combina elementos do modelo cascata com características da prototipação
Objetivo
Interagir com o usuário para descobrir os requisitos de forma gradativa, até a conclusão do produto final
Versão inicial
É o núcleo do produto evolui quando o usuário solicita a adição de novas características
Apropriado para sistemas pequenos ou difíceis de estabelecer uma especificação detalhada dos requisitos
Novas versões
Planejadas com o foco no controle de riscos técnicos
Espiral
Engloba as melhores características do modelo cascata e da prototipação, adicionando a Análise de Riscos
Dividido em uma série de regiões (3 a 6) que delimitam atividades de arcabouço
Usa a prototipação em qualquer etapa da evolução do produto
Abordagem realista para o desenvolvimento de sistemas de grande porte
Exige a consideração direta dos riscos técnicos em todos os estágios do projeto
Funcionamento
Determinar os objetivos, alternativas e restrições
Identificar e resolver os riscos relacionados
Avaliar alternativas disponíveis. Podem ser feitos protótipos para analisar alternativas diferentes
Desenvolver os artefatos relacionados à iteração corrente e validar eles
Planejar a próxima iteração
Obter concordância em relação ao planejamento
Setores de cada loop
Definição de objetivos
Avaliação e redução de riscos
Planejamento
Desenvolvimento e validação
São modelos utilizados em desenvolvimento que precisam evoluir com o tempo
Modelos evolutivos são iterativos
Possibilitam o desenvolvimento de versões cada vez mais completas
Necessidades de evolução
Mudanças nos requisitos de produtos e de negócio durante o desenvolvimento
Prazo de entrega apertado (Impossível a conclusão do produto completo)
Quando um conjunto de requisitos importantes é bem conhecido, porém sem detalhes definidos
SCRUM
Framework simples para gerenciar projetos complexos
Ferramentas
Burndown
Kamban
Intercambio time
Sprints
Grooming
Prazo
Sprint review
Daily
Plainning
Mudanças
Cada um sabe seu papel
Quando usar?
Projetos grandes e pequenos
Pouvo domínio sobre tecnologia e negócio
Papéis
Scrum master
PO
Dev team
Extreme Programming (XP)
Valores
Coragem
Feedback
Comunicação
Simplicidade
Respeito
Princípios básicos
Trabalho de alta qualidade
Mudanças incrementais
Feedback rápido
Presumir simplicidade
Abraças mudanças
Levar ao extremo o conjunto de práticas que são ditas como boas na engenharia de software
Práticas
Desenvolvimento Orientado a Testes
Primeiro crie os testes unitários e depois crie o código para que os testes funcione
Jogos de planejamento (Planning Game)
O desenvolvimento é feito em interações semanais. Onde clientes e desenvolvedores se reúnem para priorizar as funcionalidades
Fases pequenas (Small Releases)
A liberação de pequenas versões funcionais do projeto, auxilia muito no processo de aceitação por parte do cliente
Metáfora
Procura facilitar a comunicação com o cliente entendendo qual a realidade dele, é preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto
Design Simples
Um projeto simples cumprindo todos os requisitos que o projeto solicita
Testes de Aceitação
São testes desenvolvidos pelo cliente e em conjunto de analistas e testadores para a aceitação de um determinado requisito do sistema
Semena de 40 horas
Trabalhar com qualidade buscando ter ritmo de trabalho saudável, visando sempre trabalhando motivado sempre
Propriedade Coletiva
Código fonte não tem dono e não se deve solicitar permissão para poder modificar o mesmo. Visando a equipe conhecer todas as partes do sistema
Programação Pareada
Programação realizada em dupla, visando sempre o código ser revisto e assim melhorando a qualidade do código
Refatoração
Tem o ideal de ter uma melhoria contínua da programação, tendo o mínimo de entrada de erros e mantendo sempre a compatibilidade com o código já existente
Integração Contínua
Realizar sempre as integrações continuamente. não permitir que tenha uma intervalo grande entre o desenvolvimento e a integração
RUP
Modelo de software proprietário
Hoje de propriedade da IBM
Utiliza abordagem da orientação a objetos e UML
Principal preocupação é atender ao negócio
Processo de software hibrido com iterações e referências de todos os outros modelos de processos de softwares
Perspectivas
estáticas
são as atividades do projeto
Dinâmicas
são as fases ao longo do tempo
Prática
é a busca por utilizar sempre as boas práticas
Fase dinâmica
Concepção
estabelecer Business case
definir escopo
identificar entidades externas
Elaboação
Entender o domínio do problema
Escolher um framework
Definir plano de projeto e identificar riscos
Construção
Fase de desenvolvimento, testes e finalizações
Transição
Entrega do software ao cliente, entrada do sistema em produção e implantação
Fase estática
Modelagem de negócio
Requisitos
Análise e projeto
Implementação
Teste
Implantação
Gerenciar configurações e mudanças
Gerenciar projetos
Configurar ambiente
Fase prática
Recomendação de boas práticas
Sugere uso de incrementos no projeto
Sugere gerenciar os requisitos e documentação
Apoia o uso da arquitetura baseada em componentes
Apois prática de modelar o projeto graficamente
Cascata
Modelo mais antigo e o mais amplamente
usado da engenharia de software
Modelado em função do ciclo da engenharia
convencional
Requer uma abordagem sistemática,
sequencial ao desenvolvimento de software
O resultado de uma fase se constitui na
entrada da outra
Engenharia de sistemas
Envolve a coleta de requisitos, com uma pequena quantidade de projeto e análise
É uma visão essencial quando o software deve fazer com outros elementos
Análise requisitos do software
Processo de coleta dos requisitos é intensificado e concentrado especificamente no software
Deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos
Os requisitos são documentados e revistos com o cliente
Projeto
Tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie
Codificação
Tradução das representações do projeto para uma linguagem "artificial" resultando em instruções executáveis pelo computador
Testes
Aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas
Aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados
Manutenção
Provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente
Causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho
Pontos negativos
Projetos normalmente não seguem o fluxo que o modelo propõe
Kanban
Função
Assegurar que o trabalho da equipe seja visualizado, que seu fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos.
Etapas
To Do
Para Fazer
In Progress
Em andamento
Done
Feito
O que é
O trabalho das equipes geram em torno de um quadro do Kanban, uma ferramenta usada para visualizar o trabalho e otimizar o fluxo do trabalho entre a equipe.
Objetivos
Auxiliar na conclusão de demandas
Otimizar sistema de produção
Aumentar a eficiência da produção
Melhorar as realizações de tarefas
Lean
Princípios
Produzir o necessário e eliminar o desperdício
Qualidade no processo
Crie conhecimento
Criado pela Toyota
Lean Mindset
Determinar e gerar valor percebido pelo cliente
Compreender processo de entrega e definir a sequencia para as atividades
Perseguir perfeição
Responder ao ritmo do cliente
Especificar valor
Fluxo contínuo