Transferir como PDF, PPTX
Carregado porLeinylson Fontinele
Aula 2 - Modelos de processos
O documento descreve diferentes modelos de processo de software, incluindo o modelo cascata, modelo de prototipação, modelo RAD e modelos evolutivos como o incremental e o espiral. Os modelos visam fornecer representações simplificadas dos processos de desenvolvimento de software.
Mais conteúdo relacionado
Semelhante a Aula 2 - Modelos de processos
Aula 2 - Modelos de processos
- 1. Modelos de Processode Software Leinylson Fontinele Pereira Engenharia de Software
- 2. Conjunto de atividadesrelacionadas que levam à produção de um produto de software (Sommerville, 2013) Incluem: 1. Produtos gerados em cada atividade 2. Papéis envolvidos 3. Pré e pós-condições das atividades Processo de software
- 3. •Processos de softwaresão complexos e dependem de vários fatores como: • Produto a ser desenvolvido • Equipe • Recursos disponíveis •Não existe um processo ideal, ele pode ser adaptado de acordo com o contexto. Motivação
- 4. •Envolvem criatividade efatores humanos •Decisões precisam ser tomadas ao longo do processo •Decisões erradas podem levar a prejuizos e perda de oportunidades Motivação Modelos de Processo de Software Como obter uma representação simplificada de um processo de software?
- 5. Modelos de Processode Software • Modelo Sequencial Linear ou Modelo Cascata • Modelo de Prototipação • Modelo RAD (Rapid Application Development) • Modelos Evolutivos de Processo de Software – Modelo Incremental – Modelo Espiral – Modelo de Montagem de Componentes – Modelo de Desenvolvimento Concorrente – Modelo Ágil – Processo Unificado • Modelo de Métodos Formais • Técnicas de Quarta Geração 5
- 6.
- 7. Modelo Cascata • Modelomais antigo e o mais amplamente usado da engenharia de software • Modelado em função do ciclo da engenharia convencional • Requer uma abordagem sistemática, seqüencial ao desenvolvimento de software • O resultado de uma fase se constitui na entrada da outra 7
- 8. Modelo Cascata 8 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção
- 9. Modelo Cascata 9 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção Engenharia de Sistemas • Envolve a coleta de requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível • Esta visão é essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados)
- 10. Modelo Cascata 10 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção Análise de Requisitos de Software • O 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 (para o sistema e para o software) são documentados e revistos com o cliente
- 11. Modelo Cascata 11 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção 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
- 12. Modelo Cascata 12 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção Codificação • Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador
- 13. Modelo Cascata 13 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção Testes • Concentra-se: • 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.
- 14. Modelo Cascata 14 Engenharia de Sistemas Análisede Requisitos Projeto Codificação Testes Manutenção 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
- 15. Problemas com oModelo Cascata • Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe • Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural • O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento 15
- 16. Variações do ModeloCascata (Wazlawick, 2013) 16
- 17. Variações do ModeloCascata (Wazlawick, 2013) 17
- 18. Modelo Cascata • Omodelo Cascata trouxe contribuições importantes para o processo de desenvolvimento de software: – Imposição de disciplina, planejamento e gerenciamento – a implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos 18
- 19.
- 20. Modelo de Prototipação •o objetivo é entender os requisitos do usuário e, assim, obter uma melhor definição dos requisitos do sistema. • possibilita que o desenvolvedor crie um modelo (protótipo)do software que deve ser construído 20
- 21. O Paradigma dePrototipação para obtenção dos requisitos 21 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo
- 22. O Paradigma dePrototipação para obtenção dos requisitos 22 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo 1- OBTENÇÃO DOS REQUISITOS: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais.
- 23. O Paradigma dePrototipação para obtenção dos requisitos 23 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo 2- PROJETO RÁPIDO: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída)
- 24. O Paradigma dePrototipação para obtenção dos requisitos 24 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo 3- CONSTRUÇÃO PROTÓTIPO: implementação rápida do projeto
- 25. O Paradigma dePrototipação para obtenção dos requisitos 25 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo 4- AVALIAÇÃO DO PROTÓTIPO: cliente e desenvolvedor avaliam o protótipo
- 26. O Paradigma dePrototipação para obtenção dos requisitos 26 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo 5- REFINAMENTO DO PROTÓTIPO: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.
- 27. O Paradigma dePrototipação para obtenção dos requisitos 27 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo CONSTRUÇÃO DO PRODUTO
- 28. O Paradigma dePrototipação para obtenção dos requisitos 28 Obter Requisitos Elaborar Projeto Rápido Construir Protótipo Avaliar Protótipo Refinamento do Protótipo CONSTRUÇÃO DO PRODUTO 6- CONSTRUÇÃO PRODUTO: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.
- 29. Problemas com aPrototipação • Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo • Desenvolvedor frequentemente faz uma implementação comprometida, com o objetivo de produzir rapidamente um protótipo 29
- 30. Modelo de Prototipação •Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente. • O cliente e o desenvolvedor devem concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos 30
- 31.
- 32. Modelo RAD • RAD(Rapid Application Development) é um modelo sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto • O desenvolvimento rápido é obtido usando uma abordagem de construção baseada em componentes. 32
- 33. Modelo RAD • Osrequisitos devem ser bem entendidos e o alcance do projeto restrito • Utilizado principalmente para aplicações de sistema de informação • Cada função principal pode ser direcionada para uma equipe RAD separada e então integrada para formar o todo. 33
- 34. Modelo RAD 34 Modelagem do Negócio Modelagemdos Dados Modelagem do Processo Geração da Aplicação Teste e Modificação Equipe #1 Modelagem do Negócio Modelagem dos Dados Modelagem do Processo Geração da Aplicação Teste e Modificação Equipe #2 Modelagem do Negócio Modelagem dos Dados Modelagem do Processo Geração da Aplicação Teste e Modificação Equipe #3 60 a 90 dias
- 35. Modelo RAD • Desvantagens: –Exige recursos humanos suficientes para todas as equipes – Exige que desenvolvedores e clientes estejam comprometidos com as atividades de “fogo- rápido” a fim de terminar o projeto num prazo curto 35
- 36. Modelo RAD • Nemtodos os tipos de aplicação são apropriadas para o RAD: – Deve ser possível a modularização efetiva da aplicação – Se alto desempenho é uma característica e o desempenho é obtido sintonizando as interfaces dos componentes do sistema, a abordagem RAD pode não funcionar 36
- 37.
- 38. Modelos Evolutivos • Sãomodelos utilizados no desenvolvimento de softwares que precisam evoluir com o passar do tempo • Modelos evolutivos são iterativos • Possibilitam o desenvolvimento de versões cada vez mais completas 38
- 39. Modelos Evolutivos • Necessidadesde evolução: – Mudanças nos requisitos de produto 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 os detalhes ainda devem ser definidos 39
- 40. Modelos Evolutivos • Tiposde Modelos Evolutivos: – O Modelo Incremental – O Modelo Espiral – O Modelo de Montagem de Componentes – O Modelo de Desenvolvimento Concorrente – O Modelo Ágil – O Processo Unificado
- 41.
- 42. Modelo Incremental • Combinaelementos do modelo cascata (aplicado repetidamente) com características da prototipação (interação com cliente) • Objetivo: – Interagir com o usuário para descobrir os requisitos de forma gradativa (incremental), até a conclusão do produto final 42
- 43. Modelo Incremental 43 Versão Inicial Descrição geralDescrição geral Descrição geral Versões Intermediárias Versão Final Análise Projeto Codificação Teste Engenharia de sistemas/informação
- 44. Modelo Incremental • Versãoinicial: – É o núcleo do produto (a parte mais importante) • 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, a priori 44
- 45. Modelo Incremental • Novasversões – Planejadas com o foco no controle de riscos técnicos (Ex. disponibilidade de equipamento) 45
- 46.
- 47. Modelo Espiral • Englobaas melhores características do Modelo Cascata e da Prototipação, adicionando um novo elemento: a Análise de Riscos – Modelo Cascata • Segue a abordagem de passos sistemáticos – Prototipação • Interatividade com o usuário – Modelo Espiral • Sistematização (Cascata) + interatividade (prototipação) + Análise de Riscos (novo)
- 48. Modelo Espiral • Divididoem 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: – Mecanismo de redução de riscos
- 49. Modelo Espiral • Abordagemrealista para o desenvolvimento de sistemas de grande porte • Exige a consideração direta dos riscos técnicos em todos os estágios do projeto – Aplicado adequadamente, pode reduzir os riscos antes que eles fiquem problemáticos
- 50. Modelo Espiral • Funcionamento: –Para cada volta na espiral: • Determinar os objetivos, alternativas e restrições relacionadas à iteração que vai se iniciar • Identificar e resolver os riscos relacionados • Avaliar alternativas disponíveis. Podem ser feitos protótipos para analisar a viabilidade de diferentes alternativas • Desenvolver os artefatos relacionados à iteração corrente e valida-los • Planejar a próxima iteração • Obter concordância em relação ao planejamento
- 51. Modelo Espiral (com4 regiões) 51 Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integr ation testAcceptance testService Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW DETERMINAR OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES PLANEJAR PRÓXIMA FASE AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL
- 52. Modelo Espiral (com4 regiões) 52 Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integr ation testAcceptance testService Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW DETERMINAR OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES PLANEJAR PRÓXIMA FASE AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL cada “loop” no espiral representa uma fase do processo de software
- 53. Modelo Espiral (com4 regiões) 53 Risk analysis Proto- type 1 Concept of Operation Requirements plan Life-cycle plan REVIEW o “loop” mais interno está concentrado nas possibilidades do sistema
- 54. Modelo Espiral (com4 regiões) 54 Risk analysis Prototype Simulations, models, benchmarks SW requirements Requirement validation Development plan o próximo “loop” está concentrado na definição dos requisitos do sistema
- 55. Modelo Espiral (com4 regiões) 55 Risk analysis prototype 3 simulations, models, benchmarks Design V&V Product design Integration and test plan o “loop” um pouco mais externo está concentrado no projeto do sistema
- 56. Modelo Espiral (com4 regiões) 56 Risk nalysis Opera- tional protoype Simulations, models, benchmarks Detailed design Code Unit test Integration testAcceptance testService um “loop” ainda mais externo está concentrado na construção do sistema
- 57. Modelo Espiral (com4 regiões) 57 Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integr ation testAcceptance testService Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW DETERMINAR OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES PLANEJAR PRÓXIMA FASE AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL • Não existem fases fixas no modelo • As fases mostradas na figura são meramente exemplos • A gerência decide como estruturar o projeto em fases
- 58. O Modelo Espiral(com 4 regiões) 58 Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integr ation testAcceptance testService Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW DETERMINAR OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES PLANEJAR PRÓXIMA FASE AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL AVALIAÇÃO E REDUÇÃO DE RISCOS ➢ Cada “loop” do espiral é dividido em 4 setores DESENVOLVIMENTO E VALIDAÇÃO PLANEJAMENTO DEFINIÇÃO DE OBJETIVOS
- 59. Modelo Espiral (com4 regiões) 59 são definidos objetivos específicos para a fase do projeto são identificadas restrições sobre o processo e o produto é projetado um plano de gerenciamento detalhado são identificados riscos do projeto dependendo dos riscos, estratégias alternativas podem ser planejadas DEFINIÇÃO DE OBJETIVOS
- 60. Modelo Espiral (com4 regiões) 60 AVALIAÇÃO E REDUÇÃO DE RISCOS para cada um dos riscos identificados, uma análise detalhada é executada. passos são tomados para reduzir o risco
- 61. Modelo Espiral (com4 regiões) 61 AVALIAÇÃO E REDUÇÃO DE RISCOS depois da avaliação do risco, um modelo de desenvolvimento é escolhido para o sistema DESENVOLVIMENTO E VALIDAÇÃO DEFINIÇÃO DE OBJETIVOS
- 62. Modelo Espiral (com4 regiões) 62 AVALIAÇÃO E REDUÇÃO DE RISCOS DESENVOLVIMENTO E VALIDAÇÃO PLANEJAMENTO o projeto é revisto e é tomada uma decisão de continuidade se é decidido continuar, são projetados planos para a próxima fase do projeto (próximo “loop” ) DEFINIÇÃO DE OBJETIVOS
- 63. Modelo Espiral (com6 regiões) 63 Planejamento Análise de Riscos Engenharia Construção e Liberação Avaliação do Cliente Comunicação com Cliente
- 64. Modelo Espiral • Englobaas melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco • Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos 64
- 65. Principais Fases doModelo Espiral • Desenvolvimento de Objetivos • Avaliação e Redução de Riscos • Desenvolvimento e Validação • Planejamento
- 66. Principais Fases doModelo Espiral • Desenvolvimento de objetivos – Definição dos objetivos específicos – Identificação de restrições do projeto e produto – Elaboração do plano de gerenciamento – Identificação do riscos do projeto • Os risco identificados influenciam no planejamento das estratégias
- 67. Principais Fases doModelo Espiral • Avaliação de redução de riscos – Todos os riscos identificados são analisados detalhadamente – Devem ser planejadas e executadas ações para reduzir os riscos – Ex: Se houver o risco de que existem requisitos não apropriados, pode-se desenvolver protótipos do sistema para verificar a importância dos requisitos
- 68. Principais Fases doModelo Espiral • Desenvolvimento e validação – Após a avaliação de risco, um modelo de desenvolvimento de sistema deve ser selecionado: • Se os riscos de interfaces forem os principais riscos identificados pode-se adotar o modelo de prototipação • Se o risco de integração de subsistemas for o principal risco identificado pode-se escolher o modelo em cascata
- 69. Principais Fases doModelo Espiral • Planejamento – O projeto é revisado e a decisão de prosseguir ao próximo loop é tomada – Para o próximo loop o planejamento será elaborado para a próxima fase do projeto
- 70. Vantagens • É, atualmente,a abordagem mais realística para o desenvolvimento de software em grande escala. • Estimativas (por exemplo: cronograma) tornam- se mais realísticas com o progresso do trabalho. • É mais versátil para lidar com mudanças. • Fácil de decidir quando testar • Não faz distinção entre desenvolvimento e manutenção.
- 71. Desvantagens • Pode serdifícil convencer os clientes de que a abordagem evolucionária é controlável. • Avaliação dos riscos exige muita experiência para o sucesso. – Se um risco não for descoberto, inevitavelmente ocorrerão problemas. • O modelo é relativamente novo e não tem sido amplamente utilizado.
- 72.
- 73. Atividade • Crie umaempresa de desenvolvimento de Software e dê um nome fantasia para sua empresa • A empresa é formada por uma equipe de 4 desenvolvedores: – Forme sua equipe e escolha o gerente de projeto • Baseado nos modelos de processo (Cascata, Prototipação, Incremental e Espiral) defina uma abordagem para o desenvolvimento de software (adotado na empresa) adotando as melhores características e as vantagens de cada modelo • Gravem em vídeo a rotina de um dia da empresa (sejam criativos!)