Please enable JavaScript.

Coggle requires JavaScript to display documents.

METODOLOGIAS DE ENGENHARIA DE SOFTWARE, image, image, image, image, image,…

- - - - Dificuldade para cumprir o cronograma e prazos
      - Inflexibilidade e dificuldade para lidar com mudança de requisitos
      - Ausência de feedback contínuo
      - Dificuldade em atender às expectativas dos usuários finais
      - Há gasto de tempo para executar fases corretamente
      - Apresenta dificuldade para retornar e corrigir problemas detectados posteriormente
    - - Útil para projetos pequenos e equipes tecnicamente imaturas
      - Resolve a criação de software rapidamente se o escopo do trabalho é claramente definido
  - - - Equipes precisam ser maduras
      - É mais difícil de gerenciar (escopo, prazos e riscos mudam frequentemente)
      - Difícil de definir em um contrato comercial (requer que se cobre pelas mudanças)
    - - Há melhoria contínua
      - Permite o feedback do cliente
      - Mais flexível, permite entregas parciais do projeto ao cliente, o que reduz incertezas e define rumos
  - - - Fácil de usar
      - Identifica problemas cedo
      - Se preocupa em realizar testes
      - É bom para projetos simples com requisitos definidos
    - - É rígido
      - Demora de produzir entregáveis para o cliente
      - Há dificuldade de adaptação diante da mudança de requisitos (todo o sistema de testes tem que ser alterado)
  - - - Redução de riscos antes que se tornem problemáticos (consideração dos riscos técnicos em todos os estágios de evolução)
      - Estimativas mais realistas
      - Mais versátil para testar e lidar com mudanças
      - Não faz distinção entre desenvolvimento e manutenção
      - Tempo de implementação mais reduzido
    - - A avaliação dos riscos exige um analista com experiência
      - Aplica-se melhor a sistemas de grande porte
      - Erros na avaliação de riscos podem impactar o projeto
  - - - Prototipagem Rápida de Descarte: Explorar ideias e obter feedback do cliente para cada uma delas
      - Prototipagem Evolutiva: O protótipo desenvolvido inicialmente é refinado de forma incremental com base no feedback do cliente
      - Prototipagem Incremental: O produto final esperado é dividido em diferentes pequenos pedaços de protótipos e sendo desenvolvidos individualmente
      - Prototipagem Extrema: Usado principalmente para desenvolvimento web
    - - Flexibilidade no design
        
        O protótipo desenvolvido pode ser reutilizado pelo desenvolvedor para projetos mais complicados no futuro.
        
        Os erros podem ser detectados muito mais cedo economizando muito esforço e custo, além de melhorar a qualidade do software.
        
        Funcionalidades ausentes podem ser facilmente descobertas.
        
        Novos requisitos podem ser facilmente acomodados, pois há espaço para refinamento
        
        Os clientes conseguem ver o produto parcial no início do ciclo de vida (Maior satisfação e conforto do cliente)
    - - Pode haver muita variação nos requisitos cada vez que o protótipo é avaliado pelo cliente
      - Documentação deficiente devido aos requisitos do cliente em constante mudança
      - Dificuldade para os desenvolvedores acomodar todas as mudanças exigidas pelo cliente
      - Incerteza na determinação do número de iterações que seriam necessárias antes que o protótipo fosse finalmente aceito pelo cliente
      - Depois de ver um protótipo inicial, os clientes às vezes exigem que o produto real seja entregue em breve
      - Os desenvolvedores com pressa para construir protótipos podem acabar com soluções abaixo do ideal
      - O cliente pode perder o interesse no produto se não ficar satisfeito com o protótipo inicial
  - - - CONCEPÇÃO:define o escopo do software. É uma fase preliminar, é nessa etapa que se concentra o levantamento de requisitos, define preços e prazos da entrega do sistema e onde se avalia os possíveis riscos.
      - ELABORAÇÃO: plano do projeto, especificação de características e arquitetura. Aqui todas as análises de riscos são aprofundadas, como também os custos.
      - CONSTRUÇÃO": Ocorre o desenvolvimento/codificação do software
      - TRANSIÇÃO: implantação do software, assegurando que ele esteja disponível aos usuários finais. Nesta fase está incluída os testes e o treinamento dos usuários.
    - - Permite lidar com mudanças de requisitos vindas do cliente ou do projeto
      - Enfatiza a necessidade de uma documentação acurada
      - Força a integração durante o périodo de desenvolvimento, principalmente durante a fase de construção
    - - Depende da habilidade de profissionais experientes
      - Os processos de desenvolvimento são complexos e desorganizados
      - Impossível de reutilizar componentes em projetos com tecnologias novas
      - A integração em projetos com muitas equipes pode ser desorganizada
    - - DESENVOLVIMENTO ITERATIVO
      - GERENCIAMENTO DE REQUISITOS
      - USO DE COMPONENTES
      - VISIBILIDADE DE MODELOS
      - VERIFICAÇÃO DE QUALIDADE
      - CONTROLE DE MUDANÇAS
  - - - Reusabilidade
        
        Redução no tempo de desenvolvimento
        
        Redução no custo do projeto
        
        Maior flexibilidade
    - - Depende da robustez da biblioteca
        de componentes
  - - - VANTAGENS:
        
        reutilização de componentes
        
        rapida visibilidade devido aos prototipos
        
        baixo custo
        
        flexibilidade
        
        participação do usuário
        
        modularidade do sistema
        
        Desenvolvimento rápido
      - DESVANTAGENS:
        
        dificil acompanhamento
        
        falta de formalidade
        
        requisitos errôneos
        
        muito reuso de componentes
        
        falta de prazo
        
        Exige equipes grandes para projetos grandes, consequentemente exigindo mais custo
        
        dependência de usuário
      - CRIAÇÃO:Criado em 1991 por James Martin
      - ETAPAS: (1) Modelagem de negócio, (2) Modelagem de dados, (3) Modelagem do processo, (4) geração da aplicação, (5) teste e modificação
      - DESCRIÇÃO: Metodologia que exige um curto tempo de desenvolvimento e é dividida em cinco fases. O RAD (RAPID APPLICATION DEVELOPMENT) surgiu da Adaptação do RIPP, que por sua vez, surge do Modelo Incremental e Espiral
      - INDICAÇÃO: Deve ser utilzado para projetos pequenos, com a possibilidade do uso de classes já feitas, API
  - - - TIPOS DE PROTÓTIPO":
        
        Sistema Piloto: é usado não apenas com propósitos ilustrativos, mas como um núcleo básico operacional do sistema.
        
        Protótipo Autentico: é um sistema de software provisório e funcional, geralmente projetado para ilustrar aspectos específicos da interface de usuários ou parte da funcionalidade,
        
        Protótipo Funcional: é derivado do modelo do domínio do problema ou da especificação do software e serve para ajudar à equipe de desenvolvimento compreender questões relacionadas com a construção do sistema.
        
        Protótipo de Apresentação: oferece suporte ao início do projeto e é usado para convencer o cliente de que o futuro sistema é viável e que a interface do usuário se adequa aos requisitos.
      - DESCRIÇÃO:Consiste no desenvolvimento
        de software a partir da evolução de prototipos que representam o sistema no futuro. Em seu ciclo , o modelo permite a avaliação do prototipo, permitindo melhorias, alterações que encaminha o software a sua versão final.
      - Objetivos dos Protótipos:
        
        explorar e esclarecer os requisitos
        
        evoluir o protudo
        
        experimentos técnicos
      - VANTAGEM:
        
        Permite a verificação do produto final de forma antecipada, assim, podendo-se corrigir problemas ou fazer melhorias no prototipo
      - DESVANTAGENS:
        
        dificuldade na estimativa de prazo
        
        arquitetura mal definida
        
        Muito flexivel
        
        documentação ruim
        
        problemas de desempenho, portabilidade, manuntenção
- - - - Velocidade
      - Motivação da equipe
      - Prioridades podem ser alteradas
      - Menos erros
    - - Funções desordenadas e indefinições nos papeis de cada um da equipe podem fazer com que o processo trave
      - Prazos incertos, fora do que foi estipulado
      - Muito tempo gasto com reuniões podem atrasar o processo
      - Mudanças frequentes
      - Ausência de documentação
    - - Transparência: informações, requisitos, detalhes, status e cumprimento das metas devem ser conhecidos por todos
      - Inspeção: verificação constante dos artefatos
      - Adaptação: correção de pontos problemáticos e falhas, além de evoluir o que já funciona
    - - Sprint é cada fase do projeto em que determinado trabalho será realizado com duração de duas a três semanas (timebox)
      - Planning Sprint é uma reunião de definição do que será feito no sprint
      - Daily Scrum é uma reunião diária de até 15 minutos para alinhamento
      - Revisão do Sprint é uma reunião que acontece ao final do sprint
      - Retrospectiva do Sprint analisa as estratégias e desempenho da equipe
  - - - Ausência da avaliação de risco
      - Programação em par pode gerar aborrecimentos
      - Cliente tem que designar uma equipe para acompanhar o processo
      - Falta de documentação dificulta uso e manutenção do código
      - Requer muita disciplina da equipe
    - - Permite que se negocie as etapas de um projeto
      - Realiza testagens o que minimiza erros
    - - Abraçar mudanças
      - Trabalho de alta qualidade
      - Presumir simplicidade
      - Feedback rápido
      - Pequenos passos
      - Melhoria
      - Reflexão
      - Diversidade
    - - Comunicação
      - Simplicidade
      - Feedback
      - Coragem
      - Respeito
    - - Cliente participa ativamente do processo de desenvolvimento: recebe semanalmente, vê o progresso, é informado sobre mudanças
      - Jogos de planejamento (Planning Game) com a escrita de estórias
      - Desenvolvimento das funcionalidades é feito em iterações em período curto de tempo
      - Reuniões feitas em pé e de curta duração (Stand Up Meeting) para que o time se mantenha alinhado
      - Programação em par, em que uma dupla trabalha em um único computador
      - Testes constantes pelo uso Desenvolvimento Orientado a Testes (Test Driven Development), o conhecido TDD
      - Refatoração com melhoria contínua da programação
      - Código coletivo, não é preciso permissão para modificar
      - Padronização do código deve ser seguida
      - Design simples
      - Ritmo sustentável, com qualidade, atenção e disposição
      - Semana de 40 horas, sem horas extras
      - Integração contínua
  - - - Produção fica vulnerável aos imprevistos e outras circunstâncias externas. Pedidos não previstos, demandas instáveis ou pedidos emergenciais impactam o processo
      - Produção fica centralizada
      - Falta de disciplina da equipe afeta todo o sistema
    - - Estimula a priorização de atividades
      - Controle sobre as atividades
      - Flexibilidade do fluxo de trabalho
      - Evita sobrecarga
      - Comunicação integrada: status das tarefas fica visível para toda equipe
  - - - Mais eficiência nos processos
      - Maior agilidade
      - Melhores soluções
      - Aumento da produtividade
      - Redução de custos
      - Foco na experiência do cliente
      - Colaboração
    - - Faltam métricas para medir o que seriam os "desperdícios" e assim evita-los
    - - Entregas rápidas
      - Otimizar o todo
      - Construir qualidade
      - Fortalecer o time
      - Eliminar o desperdício
      - Adiar decisões
      - Amplificar conhecimento
  - - - Você só escreve o código que é necessário
      - Design mais modular
      - Mais fácil de manter
      - Mais fácil de refatorar
      - Alta cobertura
      - Testes documentam o código
      - Menos depuração
    - - O banco de dados e os arquivos externos não são testados
      - TDD parece ser difícil para GUI (interfaces gráficas de usuário) e bancos de dados relacionais.
      - Requer tempo adicional para escrever e manter casos de teste.
      - Testes TDD às vezes podem ser formulados ou aplicados incorretamente, pois os testes de unidade não funcionam conforme o esperado no domínio real e são necessários esforços para manter os conjuntos de testes
    - - Palco Vermelho: Criação de testes em que inicialmente os testes falham porque o código não é escrito
      - Palco Verde: Escrever código para que o teste passe. Para escrever práticas de código como “Keep it Simple (KISS) são recomendadas.
      - Fase de refatoração: Consiste em melhorar a qualidade do código sem alterar o comportamento real.
    - - Escreva testes e, em seguida, o código
      - Escreva um código somente quando o teste falhar
      - Escreva o código para fazer os testes passarem, elimine a duplicação
    - - .Net - Nunit
      - Java - Junit
      - C++ - gunit
      - Python — Pyunit
  - - - :red_flag:
        
        Trabalho em equipe: Incentiva-os a realizar tarefas em equipe
        
        Comunicação: Comunicação adequada entre o Cliente e os Desenvolvedores
        
        Simplicidade: Design do Produto, o Documento de Requisitos e outras documentações devem ser compreensíveis e diretos
        
        Reflexão: Respondendo e relatando corretamente; Raciocínio; Reconstrução como e quando necessário
        
        Ajustes frequentes: A equipe deve poder fazer os ajustes de acordo com a situação e as alterações necessárias
        
        Melhorar processos: A melhoria é um processo contínuo
        
        Foco: Cada membro da equipe sabe exatamente o que fazer, o que permite que eles concentrem sua atenção.
        
        Segurança Pessoal: Não há sugestões ruins em uma equipe de cristal, os membros da equipe devem se sentir seguros para discutir ideias abertamente sem medo.
        
        Ferramentas técnicas: Utilizar ferramentas permitam que a equipe identifique qualquer erro em menos tempo
    - - Facilitar e aprimorar a comunicação e a responsabilidade da equipe
      - A abordagem adaptativa permite que a equipe responda bem aos requisitos exigentes
      - Permite que a equipe trabalhe com aquele que eles consideram mais eficaz
      - As equipes conversam diretamente entre si, o que reduz a sobrecarga de gerenciamento
    - - A falta de planos pré-definidos pode levar à confusão e perda de foco.
      - A falta de estrutura pode atrasar equipes inexperientes.
      - Não está claro como uma equipe remota pode compartilhar conhecimento informalmente.
    - - (Representadas por diferentes cores do espectro)
        
        Crystal Clear
        
        Crystal Yellow
        
        Crystal Orange
        
        Crystal Orange Web
        
        Crystal Red
        
        Crystal Maroon
        
        Crystal Diamond & Sapphire
  - - - (1) CICLO DE VIDA DE PROJETO:
        
        Elaboração: quando riscos arquiteturais significantes são tratados.
        
        Construção: oca no detalhamento dos requisitos, no desenho, na implementação e nos testes da maior parte do software.
        
        Transição: 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.
        
        Concepção: 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.
      - (2) CICLO DE VIDA DA ITERAÇÃO: O OpenUP divide o projeto em iterações planejadas e com intervalos de tempo definidos, normalmente medidos em semanas.
      - (3) MICRO INCREMENTOS: O esforço pessoal está organizado em microincrementos. Eles representam pequenas unidades de trabalho que produzem um passo do progresso do projeto, constante e mensurável (normalmente medido em horas ou dias).
    - - Equilibrar as prioridades concorrentes para maximizar o benefício aos Stakeholders
      - Colaborar para alinhar os interesses e compartilhar o entendimento
      - Focar na arquitetura, o mais cedo possível, para reduzir o risco e organizar o desenvolvimento
      - Evoluir para continuamente obter feedback e promover melhorias
    - - Não é indicado para equipes grandes.
    - - Possui caráter minimalista,
      - Capacidade de customização de forma prática e simples
      - possui boas práticas de desenvolvimento
      - tem foco na redução de riscos e
        preserva as características do RUP
  - - - (1) Desenvolvimento de modelo abrangente: Analise de alto nível do escopo do sistema e do contexto
      - (2) Construção de lista de funcionalidades: O conhecimento coletado na primeira fase é utilizado para criar uma lista de novas funcionalides baseada nas funcionalidades existentes
      - (3) Planejar por funcionalidade: Após a criação da lista de funcionalidades, é feito o plano desenvolvimento e designado a um programador a lista de classes com as funcionalidades
      - (4) Detalhe por funcionalidade: Um pacote de design é produzido para cada funcionalidade. Um programador chefe seleciona um pequeno grupo de funcionalidades que devem ser desenvolvidos em duas semanas
      - (5) Construção por funcionalidade: Após a análise do design das funcionalidades, é feito o código para as classes, após passar por testes unitários e revisão de código, a funcionalidade é adicionada ao sistema
    - - Dá ao time um bom entendimento do escopo do projeto e contexto
      - Focado no usuário
      - Util em projetos em andamento
      - Quebra grandes funcionalidades em partes menores
    - - Necessita de um time grande
      - Depende de programadores-chefes
      - Enfatiza código individual, ao invés do código da equipe/time