Please enable JavaScript.

Coggle requires JavaScript to display documents.

Metodologias de Desenvolvimento de Software, Lucas Afonso Rafael Matos …

- - - - Complexidade de Gestão: É mais complexo de gerenciar do que o simples Modelo Cascata.
      - Requer boa arquitetura: A arquitetura inicial precisa ser bem-feita para suportar os futuros incrementos sem quebrar.
      - Pode ser difícil definir o tamanho e o conteúdo de cada incremento.
    - - Combina o fluxo linear (como o Cascata) com a repetição (iteração).
      - O software é desenvolvido em "incrementos" (partes funcionais).
      - Cada incremento adiciona nova funcionalidade ao anterior.
      - O cliente pode ver e testar as partes do software à medida que ficam prontas.
      - Intrínsecas
        
        Iteração como Mecanismo de Apredizado Empirico
        
        Inspeção, Adaptação e Feedback
        
        O ciclo iterativo fornece oportunidades formais e regulares para a equipe inspecionar o trabalho e o processo de desenvolvimento, e subsequentemente adaptar os planos e a execução.
        
        Um pilar essencial da iteração é a integração do feedback do usuário.
        
        Otimização da Eficiência
        
        Esta eficiência resulta da capacidade de identificar e corrigir desvios ou informações falhas no inicio do ciclo, reduzindo drasticamente o custo de acomodar mudanças.
        
        O Incremento com Entrega de Valor e Flexibilidade
        
        Foco no Software Funcional
        
        A entrega de incrementos utilizáveis materializa este valor, pois cada parte funcional entrega, independentemente do seu tamanho.
        
        Flexibilidade e Resposta á Mudança
        
        A estrutura incremental permite que os processos tirem vantagem das mudanças, mesmos que elas surjam tardiamente no desenvolvimento, conferindo uma vantagem competitiva ao cliente.
    - - Feedback cedo: O cliente usa os primeiros incrementos e dá feedback que melhora o resto do projeto.
      - Gerenciamento de Risco: Os riscos mais altos são geralmente tratados nos primeiros incrementos.
      - Mais flexível: Permite mudanças nos requisitos entre um incremento e outro (muito melhor que o Cascata).
      - O cliente vê progresso real, o que aumenta a confiança.
  - - - Foco na Qualidade: O teste é planejado desde o início do projeto, junto com o desenvolvimento.
      - Reduz Defeitos: Encontrar falhas cedo é mais fácil, pois os planos de teste são criados enquanto os requisitos estão sendo definidos.
      - Clareza: Muito disciplinado, fácil de entender e gerenciar (assim como o Cascata).
      - Bom para projetos onde a falha é cara (ex: software médico, aviação).
    - - Inflexível: Assim como o Cascata, é muito rígido e não lida bem com mudanças nos requisitos.
      - Lento: O software só é testado (executado) de fato depois que a fase de codificação termina.
      - O cliente não vê o produto até o final.
      - Não é bom para projetos longos ou complexos onde os requisitos podem mudar.
    - - É uma evolução do Modelo Cascata.
      - Foco principal: Verificação e Validação (V&V).
      - Cada fase de desenvolvimento (lado esquerdo do V) tem uma fase de teste correspondente (lado direito do V).
      - Exemplo de conexão:
        
        Requisitos (Esquerda) -> Teste de Aceitação (Direita)
        
        Projeto de Arquitetura (Esquerda) -> Teste de Sistema (Direita)
        
        Projeto Detalhado (Esquerda) -> Teste de Integração (Direita)
        
        Codificação (O "bico" do V) -> Teste de Unidade (Direita)
  - - - Simples de entender e gerenciar
      - Disciplinado
      - Requisitos definidos no início
      - Bom para projetos com escopo estável
    - - Inflexível (difícil voltar atrás)
        
        Com essa abordagem cronológica, os projetos podem levar mais tempo para serem concluídos do que uma abordagem iterativa.
      - Cliente só vê o produto no final
        
        Os clientes não estão envolvidos nas fases de projeto e implementação.
      - Alto risco de falha se os requisitos mudarem
        
        Muitas vezes, os clientes não sabem extamente o que querem no início do processo, o que abre espaço para pedidos de alterações e novas funcionalidades mais tarde, quando são mais difíceis de atender.
    - - Fases lineares e sequenciais
        
        Projeto
        
        Nesta etapa, os desenvolvedores de software projetam uma solução técnica para os problemas definidos pelos requisitos do produto, incluindo cenários, layouts e modelos de dados.
        
        Teste
        
        A equipe de teste verificará as metodologias de gerenciamento de projetos e utilizará os documentos de design, as personas e os cenários de uso fornecidos pelo gerente de produto para criar seus casos de teste.
        
        Implementação
        
        Nesta fase, os programadores codificam os aplicativos com base nos requisitos e especificações do projeto, com alguns testes e implementação também sendo realizados.
        
        Requisitos
        
        A metodologia em cascata baseia-se na premissa de que todos os requisitos do projeto podem ser coletados e compreendidos antecipadamente.
        
        Manutenção
        
        Á medida que defeitos são encontrados e solicitações de alteração chegam dos usuários, uma equipe é designada para cuidar das atualizações e lançar novas versões do software.
      - Pouca sobreposição de fases; Foco forte em documentação
      - Aspecto
        
        Abordagem do projeto
        
        Segue uma abordagem linear e sequencial, onde cada fase é concluída antes de passar para a próxima.
        
        Flexibilidade
        
        Flexibilidade muito limitada - uma vez concluída uma fase, é difícil voltar atrás e fazer alterações.
        
        Envolvimento do cliente
        
        Envolvimento mínimo do cliente após a fase de levantamento de rquisitos.
        
        Planejamento
        
        É necessário um planejamento prévio extenso: todos os requisitos devem ser claramente definidos antes do início do desenvolvimento.
        
        Entrega
        
        Entrega final única ao término do projeto.
        
        Gestão de riscos
        
        O risco de falha é maior se os requisitos forem mal interpretados desde o início, pois os problemas podem não ser descobertos até uma fase posterior.
        
        Testes
        
        Os testes são realizados após a conclusão da fase de desenvolvimento.
        
        Ideal para
        
        Projetos com requisitos claramente defínidos e imutáveis, com construção ou fabricação.
  - - - Como o modelo exige a consideração dos riscos técnicos em todos os estágios de evolução, reduzirá os riscos antes que se tornem problemáticos;
      - As estimativas se tornam mais realistas e o tempo de implementação é reduzido;
      - Mais versátil para testar e lidar com mudanças;
      - Não faz distinção entre desenvolvimento e manutenção.
    - - Segundo PRESSMAN (2006), pode ser difícil convencer os clientes que o processo de evolução é controlável, pois ele exige competência considerável na avaliação dos riscos e depende dessa competência para ser bem sucedido;
      - Se um risco importante não for descoberto e gerenciado corretamente, fatalmente ocorrerão problemas;
      - 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.
    - - É uma evolução do modelo de entrega contínua;
        
        Segundo SOMMERVILLE (2011), o Modelo em Espiral “combina prevenção e tolerância a mudanças, assume que mudanças são um resultado de riscos de projeto e inclui atividades explícitas de gerenciamento de riscos para sua redução”.
      - Forte ênfase no gerenciamento de riscos;
        
        Identificação de Riscos
        
        Levantamento de riscos técnicos;
        
        Análise de incertezas nos requisitos;
        
        Consideração de fatores de mercado e aceitação do usuário.
        
        Análise dos Riscos
        
        Estimativa da probabilidade de cada risco ocorrer;
        
        Avaliação do impacto potencial no projeto;
        
        Ordenação dos riscos conforme severidade e urgência.
        
        Planejamento do Próximo Ciclo
        
        Revisão dos riscos que ainda permanecem;
        
        Identificação de novos riscos surgidos na iteração;
        
        Atualização do plano com prioridades, prazos e ações revisadas.
        
        Avaliação e Validação
        
        Testes para confirmar eficácia das ações mitigadoras;
        
        Verificação de aderência das soluções aos objetivos;
        
        Ajustes nas funcionalidades ou processos quando necessário.
      - Cíclico e evolutivo;
        
        Todas as etapas se repetem a cada nova "volta" no ciclo de desenvolvimento.
      - Envolvimento constante do cliente.
      - Iterações personalizáveis;
      - Prototipação frequente;
        
        PRESSMAN (2006) diz que o modelo é “uma abordagem realista do desenvolvimento de sistemas e softwares de grande porte … usando a prototipagem como mecanismo de redução de riscos”;
        
        É frequente o uso de protótipos para testar ideias e tecnologias críticas.
  - - - Reutilização de componentes: Os componentes são feitos para serem genéricos, autocontidos e independentes, permitindo que a mesma unidade seja utilizada em diferentes projetos ou partes do mesmo sistema.
        
        O desenvolvedor não precisa reinventar funcionalidades já consolidadas.
        
        O time pode se concentrar no que é realmente específico e inovador do projeto.
        
        A integração de componentes costuma ser mais rápida que desenvolvimento do zero
      - Escalabilidade e modularidade
        
        o código fica mais fácil de evoluir.
        
        o sistema fica mais organizado.
        
        cada componente pode ser escalado individualmente.
        
        é possível substituir módulos sem impacto global.
      - Testabilidade aprimorada: Componentes possuem interfaces bem definidas, podem ser testados isoladamente com testes unitários, simulados em integrações por meio de mocks ou stubs e, por serem autocontidos e terem poucas dependências, tornam os cenários de teste muito menos complexos.
        
        múltiplos ciclos de teste em outros projetos
        
        correções sucessivas
        
        revisão da comunidade
        
        validação por especialistas
      - Manutenibilidade aprimorada: O software pode ser corrigido, melhorado ou adaptado mais facilmente depois de entrar em produção.
        
        múltiplos ciclos de teste em outros projetos
        
        correções sucessivas
        
        revisão da comunidade
        
        validação por especialistas
    - - As adequações nos requisitos são inevitáveis, e isso pode resultar em um software que não atenda às reais necessidades dos usuários
      - Nem sempre componentes diferentes usam padrões iguais e seguem as mesmas convenções, então é preciso criar adaptadores, traduzir formatos de dados ou ajustar APIs.
      - O controle sobre a evolução do software se perde, uma vez que novas versões dos componentes reutilizáveis não estão sob o controle da organização que utiliza esses componentes
    - - Especificação de Requisitos: Comparável com outros processos, como por exemplo, o modelo cascata. As funções, as restrições e os objetivos do software são estabelecidos por meio da consulta aos usuários
      - Análise de Componentes: Com base na especificação de requisitos, é feita uma busca de componentes para implementar essa especificação. Nem sempre é possível encontrar uma combinação exata e os componentes que podem ser utilizados fornecem somente parte da funcionalidade requerida
      - Modificação de requisitos: durante esse estágio, os requisitos são analisados, utilizando-se as informações sobre os componentes que foram encontrados. Eles são então modificados para refletir os componentes disponíveis. Quando as modificações forem impossíveis, a atividade de análise de componentes é refeita, a fim de procurar soluções alternativas
      - Projeto de sistema com reuso: durante essa fase, a infraestrutura do sistema é projetada ou uma infraestrutura existente é reutilizada. Os projetistas levam em conta os componentes que são reutilizados e organizam a infraestrutura para lidar com esse aspecto
      - Desenvolvimento e integração: o software que não puder ser comprado, será desenvolvido, e os componentes e sistemas COTS (commercial off-the-shelf – sistemas comerciais de prateleira) serão integrados, a fim de atender por completo a especificação do usuário
      - Validação de sistema: o software deve ser validado para garantir que atende a especificação do usuário
  - - - É uma das abordagens mais eficazes de validação de requisitos. O protótipo é algo mais concreto que uma especificação de requisitos ou um modelo;
      - Visa reduzir os riscos do projeto, permitindo a descoberta de falhas nos requisitos em etapas iniciais, e que talvez sejam difíceis de detectar com outras técnicas de análise;
      - A criação de um fluxo constante de feedbacks entre a empresa e o seu cliente, melhorando a relação entre toda a equipe;
      - A otimização do investimento na criação da ferramenta com a eliminação de erros;
      - A maior agilidade na entrega de resultados por meio de um planejamento melhor estruturado.
    - - o sistema é construído inicialmente em uma versão simplificada, chamada protótipo.
        
        Esse protótipo serve para validar requisitos, alinhar expectativas, coletar feedback dos usuários e reduzir riscos antes de desenvolver o sistema final.
      - Coleta inicial de requisitos: descobrir o problema principal, identificar stakeholders e mapear o escopo mínimo necessário para o protótipo.
        
        riscos comuns
        
        Escopo excessivo
        
        Falta de clareza em quem vai validar.
      - Criação do protótipo: construir uma representação tangível do produto suficiente para validar hipóteses e colher feedback.
        
        riscos comuns
        
        Gastar tempo demais em pixels em vez de validar fluxo.
        
        Dar impressão de prontidão técnica quando é apenas interface.
      - Avaliação pelo usuário: Colher feedback real, validar hipóteses e identificar questões de usabilidade e entendimento.
        
        riscos comuns
        
        Amostra de usuários não representativa.
      - Refinamento: iterar o protótipo com base no feedback, priorizando correções que tragam maior validação de hipótese.
        
        riscos comuns
        
        Perder visão do produto final ao focar só no protótipo.
      - Conclusão: traduzir o protótipo validado em requisitos técnicos e construir o produto final com menor risco.
        
        riscos comuns
        
        Reusar protótipo mal feito como código de produção
        
        Não traduzir ajustes do protótipo em requisitos técnicos claros.
    - - Em uma prototipação para validar requisitos funcionais, o usuário não pode se ater aos requisitos estéticos e não funcionais;
      - Deve-se ter o cuidado para que o usuário não compare o desempenho de um protótipo com o desempenho do produto final.
      - Maior tempo de execução do ciclo de prototipagem.
      - Menor liberdade criativa durante a confecção do protótipo.
    - - Prototipação evolucionária ou incremental
        
        É aquela elaborada no primeiro momento do projeto e, conforme o desenvolvimento for avançando, esse protótipo é refeito, adaptado e alinhado às fases de elaboração.
      - Prototipação descartável
        
        Também é realizada em diversas etapas, mas não é incrementada nas fases seguintes. Ou seja, os protótipos abordam os detalhes de cada momento do projeto, e depois são descartados.
  - - - Muitas vezes é mais eficaz do que a abordagem cascata, no sentido de produzir sistemas que atendam às necessidades imediatas dos clientes.
      - A especificação pode ser desenvolvida gradativamente. À medida que os usuários desenvolvem uma compreensão melhor de seus problemas, isso pode ser refletido na melhoria do software em construção
    - - Como os softwares são desenvolvidos rapidamente, não é viável produzir documentos que reflitam cada versão do sistema
      - Os softwares frequentemente são mal estruturados → a mudança constante tende a corromper a estrutura do software
      - Incorporar modificações torna-se cada vez mais difícil e oneroso
      - O sistema pode nunca terminar, pois o cliente sempre pede uma alteração
    - - Tem como base a ideia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado tenha sido desenvolvido
      - Em vez de ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado concorrentemente com um rápido feedback por meio dessas atividades
      - o software cresce em versões sucessivas.
      - requisitos são ajustados ao longo do tempo
  - - - Progresso mensurável;
      - Economia de tempo;
      - Trabalho com modelos;
      - Integração mais rápida de sistemas;
      - Feedback constante.
    - - Dependência de usuários disponíveis e engajados;
      - Não adequado para sistemas muito complexos ou de missão crítica;
      - Requer equipe altamente experiente;
        
        Desenvolvedores juniores podem ter dificuldade de adaptação.
      - Alta dependência de ferramentas específicas;
      - Dificuldade de gerenciamento em projetos grandes;
    - - Desenvolvimento rápido por meio de protótipos;
      - Alto envolvimento do usuário;
      - Equipe multidisciplinar e altamente qualificada;
      - Uso intensivo de ferramentas CASE e geração automática de código;
      - Ciclos curtos de desenvolvimento;
      - Processo
        
        Modelagem do negócio;
        
        Identificar fluxos de trabalho;
        
        Mapear funções essenciais do projeto;
        
        Entender os objetivos e restrições organizacionais.
        
        Modelagem dos dados;
        
        Definir relacionamentos entre elas;
        
        Criar modelos como diagramas entidade-relacionamento.
        
        Identificar entidades;
        
        Modelagem do processo;
        
        Especificar entradas, saídas e regras de negócio.
        
        Testes constantes dos protótipos;
        
        Definir como os dados serão manipulados;
        
        Criar fluxos de processo;
        
        Geração da aplicação;
        
        Geração automática de formulários, relatórios e componentes;
        
        Construção de protótipos;
        
        Desenvolvimento modular em partes pequenas.
        
        Teste e Modificação;
        
        Correções rápidas;
        
        Ajustes solicitados pelo usuário em tempo real.
      - O processo se repete a cada ciclo de desenvolvimento;
      - É semelhante ao Agile ... em alguns aspectos
        
        Semelhanças ✅
        
        Entrega rápida;
        
        Ciclos curtos ;
        
        Flexível à mudanças;
        
        Foco em versionar/testar cedo;
        
        Diferenças ❎
        
        Estrutura por fases definidas (RAD) vs. ciclos iterativos contínuos (Agile);
        
        RAD depende fortemente de ferramentas enquanto o Agile foca mais nas pessoas;
        
        Requisitos mais definidos no início (RAD) vs. requisitos evoluindo sempre (Agile);
        
        RAD foca em protótipos; Agile foca em incrementos utilizáveis;
        
        Menos adequado para projetos complexos (RAD) vs. indicado para alta complexidade e mudança constante (Agile);
    - - A aplicação deve possuir requisitos muito bem definidos;
      - O sistema deve poder ser modularizado para o bom funcionamento do RAD;
      - Não é apropriado quando se tem um risco técnico alto ou quando não se tem equipe suficiente para suprir essa agilidade!
  - - - Redução de custos inesperados
      - Menor desperdício de recursos
      - Entregas com alta qualidade de forma eficiente
      - Altamente customizável
      - Framework estruturado
    - - Complexidade: O RUP é complexo com muitas fases e artefatos, o que pode ser um problema para times, organizações e projetos pequenos.
      - Implementação custosa: A documentação excessiva, cargos especializados e a necessidade por treinamento pode tornar o RUP muito custoso e demorado.
    - - Iterativo e Incremental: O software é entregue em pedaços, na qual cada iteração resulta em um software mais robusto
      - Documentação feita em UML
      - Utiliza uma abordagem orientada a objetos
      - Divisão em quatro fasesConstrução: Codificação do software
        
        Concepção: Levantamento de requisitos, definição de prazos e avaliação dos riscos
        
        Construção: Codificação do software
        
        Transição: Implantação do software, realização dos testes e treinamento do usuário
        
        Elaboração: Especificação de características e arquitetura
      - Diciplinas de engenharia
        
        Modelagem de negócios
        
        Requisitos
        
        Análise e Design
        
        Implementação
        
        Teste
        
        Implantação
      - Video Explicativo
- - - - Implantação automatica
        
        Implantação e entrega 100% automatizado de ponta a ponta tornando o processo previsivel
        
        Entregas automáticas e frequentes significam que o impacto e variação entre elas será menor
        
        Reduz drasticamente o risco associado e facilita reversões em caso de problemas
        
        Qualquer modificação minima na aplicação pode ser implementada a qualquer momento
        
        Drásticas reduções no tempo de ciclos de entrega, com funcionalidades e correções chegando aos usuários rapidamente
        
        DevOps
        
        Unifica as responsabilidades do time de desenvolvimento e operações
        
        Elimina o gargalo do hand-off entre uma equipe e outra
        
        Retira a burocracia do processo de deploy, poupando que novas features sejam acumuladas no processo de deploy
        
        Diminui o Risco associado ao deploy
        
        Engloba desde o desenvolvimento do software, testes automatizados e controle de qualidade, até o deploy, desempenho e testes de implantação
      - Implantação manual
        
        Processo tedioso, demorado, perigoso e burocratico
        
        É necessaria documentação pesada, que quase sempre termina incompleta ou ultrapassada
        
        Difícil de rastrear problemas de implantação e auditar o processo realizado na implantação
        
        A colaboração entre o time de desenvolvimento e operações é bem complicada
        
        Altos custos de cordeação entre grupos envolvidos na implantação
        
        Necessário um time de operação pra qualquer mudança no ambiente de produção
  - - - Tem bastante foco na eliminação de desperdícios e eficiência maxima
      - Especifica-se o valor do ponto de vista do cliente, em seguida, se identificam todas as etapas no fluxo de geração de valor, eliminando todas as etapas que não gerem valor
      - As etapas de criação de valor ocorrem em uma sequencia apertada para que o produto flua suavemente em direção ao cliente
      - As ideias são testadas quantas vezes forem necessárias antes de se gastar dinheiro com elas
    - - No Kanban, as tarefas ficam visíveis para todos, e identificar o estagio em que uma tarefa está é rápido e simples, apenas pelo posicionamento da tarefa em um quadro
      - Com uma visibilidade tão simples é mais facil identificar gargalos e acompanhar o processo como um todo.
      - A equipe nunca fica sem tarefas a fazer, pois, tarefas pendentes são facilmente identificaveis no quadro "A fazer"
    - - É pensada principalmente para equipes pequenas de 2 a 8 pessoas trabalhando em um mesmo ambiente
      - Tem como foco principal a comunicação limpa como meio de minimizar interrupções e problemas
    - - O XP nasceu com foco no chão de fábrica do software, levando boas práticas de desenvolvimento ao extremo. Seus valores são simplicidade, comunicação, feedback e coragem
    - - O Scrum estabelece regras claras sobre papéis, ritos e artefatos, guiando o time para entregas incrementais e flexíveis.
  - - - Cria-se um modelo generalizado do sistema, com um levantamento da lista de funcionalidades e um cronograma de entrega das mesmas
      - O ciclo de desenvolvimento das features é curto, fazendo pra cada feature um detalhamento, projeção, programação e testes de cada funcionalidade especifica
      - No fim de cada ciclo de desenvolvimento de funcionalidades, uma entrega nova é feita
      - Ele pode ser usado em conjunto com outras metodologias como o TDD e muitas vezes em conjunto com o SCRUM
  - - - Para o desenvolvimento de cada funcionalidade do sistema, um teste é criado antes, com a interface esperada e os resultados esperados
      - Uma vez que o teste inicial passa, é exigido que a funcionalidade seja já refatorada com as melhores boas praticas para manter o código limpo e manutenível
      - Assim cria-se a segurança de que a cobertura de testes do código fonte seja muito boa, uma vez que não se desenvolve nada sem antes possuir os testes da funcionalidade nova
      - Como toda nova feature possui uma bateria de testes automatizados, é mais difícil que uma alteração futura que quebre outras funcionalidades seja passada despercebida
      - Tem como resultado colateral um código menos acoplado, já que a criação de testes exige que o código seja quebrado em varias partes
  - - - Foca na definição da plataforma central. Identifica os pontos comuns (obrigatórios) e variáveis (opcionais) que a família de produtos deve possuir.
    - - Foca na construção de produtos individuais. Consiste em selecionar as opções desejadas da plataforma e adaptá-las para atender às necessidades específicas de um cliente.