Baixado 42 vezes
Mais conteúdo relacionado
Semelhante a Modelos de Processo de Software Parte 3
Modelos de Processo de Software Parte 3
- 1. Processo de Produção deSoftware Bacharelado em Engenharia de Software – Aula 17 Prof.ª M.ª Elaine Cecília Gatto
- 2. MODELOS DE PROCESSOS DEPRODUÇÃO DE SOFTWARE
- 3. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 4. Modelo de ProcessoEvolucionário • Produzem uma versão cada vez mais completo do software a cada iteração • Software evolui ao longo do tempo • Requisitos do negócio e do produto mudam • É um modelo de processo que foi projetado para desenvolver um produto que cresce e muda • São modelos iterativos
- 5. Modelo de ProcessoEvolucionário
- 6. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 7. Modelo de Prototipação •Objetivos gerais são definidos pelo cliente • Requisitos para funções e recursos não são identificados pelo cliente • Insegurança do desenvolvedor • Fazer um protótipo como uma primeira etapa pode ser uma forma de elucidar os detalhes das necessidades do cliente
- 8. Modelo de Prototipação •Usado como um modelo de processo isolado • Usado no contexto de qualquer um dos modelos de processo estudados • Auxilia os envolvidos a compreender melhor o que deve ser construído, a esclarecer os requisitos
- 9.
- 10. Modelo de Prototipação Comunicação: •Reunião com os envolvidos • Definição dos objetivos gerais do software • Identificação dos requisitos • Esquematização das áreas que precisam de definição mais ampla
- 11. Modelo de Prototipação PlanejamentoRápido: • Após a etapa de comunicação, uma iteração de prototipação é planejada rapidamente e ocorre a modelagem na forma de um projeto rápido
- 12. Modelo de Prototipação ModelagemProjeto Rápido: • Concentra-se em uma representação dos aspectos do software que serão visíveis para os usuários
- 13. Modelo de Prototipação Construçãode Protótipo: • Construção do protótipo propriamente dito
- 14. Modelo de Prototipação Entregae Feedback • O protótipo é entregue para todos os envolvidos e avaliados por eles • O feedback é usado para refinar ainda mais os requisitos
- 15. Modelo de Prototipação •Também chamado de Trow-Away. • Consiste na construção de protótipos que são usados unicamente para estudar aspectos do sistema, entender melhor seus requisitos e reduzir riscos.
- 16. Modelo de Prototipação •Possibilita a melhor compreensão das necessidades que devem ser atendidas. • O protótipo atua como um mecanismo para identificar os requisitos do software. • “Não transforme o protótipo grosseiro em um produto final, a qualidade ficará comprometida”
- 17. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 18. Modelo de PrototipaçãoEvolucionária • Também chamado de Cornerstone. • É uma técnica que pode ser entendida como um modelo independente, ou parte de outro modelo, em que protótipos cada vez mais refinados são apresentados ao cliente, para que o entendimento sobre os requisitos evolua de forma suave e consistente.
- 19. Modelo de PrototipaçãoEvolucionária • Este tipo de protótipo não é descartado como no modelo de Prototipação original. • Neste modelo o protótipo evolui lentamente até se transformar no sistema final. • Usuário tem uma ideia prévia do sistema final. • Desenvolvedores passam a desenvolver algo imediatamente.
- 20. Modelo de PrototipaçãoEvolucionária • Protótipos devem ser planejados mais cuidadosamente já que serão utilizados no produto final. • Os aspectos mais visíveis do sistema devem ser trabalhados com o cliente até que o produto seja aceitável.
- 21. Modelo de PrototipaçãoEvolucionária
- 22. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 23. Modelo Espiral • Éuma organização de ciclo de vida voltada para o tratamento de risco, interatividade e prototipação. • Característica Marcante: Realização de ciclos de prototipação para a redução de riscos de projeto.
- 24. Modelo Espiral • ModeloProposto por Barry Boehm em 1986. • Une a natureza iterativa da prototipação aos aspectos sistemáticos e controlados do modelo cascata. • Modelo baseado em experiências com projetos governamentais da TRW. • Ênfase na redução de riscos (orientado à redução de riscos). • O produto é desenvolvido em uma série de iterações.
- 25. Modelo Espiral • Abordagemorientada a risco para o processo de software. • Metodologia cíclica (ciclos iterativos). • O projeto é dividido em subprojetos. • Cada subprojeto aborda um ou mais elementos de alto risco, até que todos os riscos identificados tenham sido tratados.
- 26. Modelo Espiral • Realizaas iterações de forma organizada. • Inicia com pequenos protótipos (ou miniprojetos). • Avança para projetos cada vez maiores. • Permite que os requisitos sejam definidos progressivamente. • Permite avaliação de partes do produto. • Fornece realimentação quanto às decisões tomadas.
- 27. Modelo Espiral • Facilitao acompanhamento do progresso do projeto. • Requer gestão sofisticada. • Design do produto deve ser robusto. • Requer equipe disciplinada e experiente. • Usado em METODOLOGIAS ÁGEIS COMO EXTREME PROGRAMMING (XP)
- 28. Modelo Espiral • Abordaos principais riscos. • Expande o projeto através de protótipos, testes e replanejamento. • Adquire conhecimento mais completo dos potenciais problemas com o sistema.
- 29. Modelo Espiral • EXEMPLOSDE RISCOS: • Requisitos mal compreendidos • Problemas tecnológicos • Arquitetura • Desempenho • Dispositivos eletrônicos, elétricos, eletromecânicos, etc.
- 30.
- 31.
- 32.
- 33. Modelo Espiral • Primeirasiterações: • São mais baratas - tempo e recursos • Resolvem os maiores problemas do projeto • As atividades concretas desta fase variam de projeto para projeto
- 34. Modelo Espiral • O1.º circuito em volta da espiral: Resulta no desenvolvimento de uma especificação de produto; • Passagens subsequentes: desenvolvimento de um protótipo com progresso para versões mais sofisticadas.
- 35. Modelo Espiral • Passagenspelo planejamento: ajustes no planejamento. • Custo e cronograma: ajustados após a entrega do produto e feedback do cliente. • Número de iterações: ajustada pelo gerente do projeto.
- 36. Modelo Espiral • Incluiuma REVISÃO, de todas a atividades em uma etapa, por todas as principais partes envolvidas. • Objetivo da REVISÃO: assegurar que todas as partes estejam continuamente comprometidas com o projeto e de acordo com a metodologia para a fase seguinte.
- 37. Modelo Espiral • Noinicio do processo a equipe deve: • Explorar riscos • Construir um plano de gerenciamento de riscos • Planejar uma abordagem para o ciclo seguinte • Cada volta no ciclo faz o projeto avançar um nível em entendimento e mitigação de riscos.
- 38. Modelo Espiral • Percursotípico: • Passo 1: Determinar os objetivos, alternativas e restrições relacionadas à iteração que vai se iniciar • Passo 2: Identificar e resolver os riscos relacionados à iteração em andamento. • Passo 3: Avaliar as alternativas disponíveis. Utilização de protótipos para verificação da viabilidade de diferentes alternativas.
- 39. Modelo Espiral • Percursotípico: • Passo 4: Desenvolver artefatos desta iteração e certificar-se de que estão corretos • Passo 5: Planejar a próxima iteração • Passo 6: Obter concordância sobre a próxima iteração
- 40. Modelo Espiral • DIFICULDADE:experiência na identificação e análise de riscos. • É um modelo de ciclo de vida que pode ser aplicado ao longo da vida do software – não termina quando o software é entregue. • É um modelo para desenvolvimento de software em larga escala.
- 41. Modelo Espiral • Dependenteda especialização de avaliação de riscos para ter sucesso em sua aplicação. • Não há clareza sobre a quantidade de trabalho necessária para cada equipe em cada ciclo.
- 42. Modelo Espiral • Ogerenciamento é complexo e deve ser eficiente. • Adequado a projetos complexo, com alto risco e requisitos pouco conhecidos - pesquisa e desenvolvimento. • Muito utilizado em JOGOS ELETRÔNICOS.
- 43. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 44. Modelo de Entregaem Estágios • Estabelece que partes do sistema já estão prontas podem ser entregues antes de o projeto ser finalizado e que isso possa ser planejado. • É uma variação, melhor estruturada, do modelo de Prototipação Evolucionária e também do Modelo Cascata.
- 45. Modelo de Entregaem Estágios • Prevê que a cada ciclo a equipe planeje e saiba exatamente o que será entregue. • Cliente pode acompanhar diretamente a evolução do sistema. • Vários pontos de entrega para o cliente (continua)
- 46. Modelo de Entregaem Estágios • Funcionalidades uteis são postas nas mãos do cliente antes de completar o projeto. • O modelo não funciona se as etapas no nível Técnico e Gerencial não forem planejadas cuidadosamente. • Requisitos devem ser bem compreendidos. • Planejamento deve ser efetivo. • Precursora dos modelos iterativos como os métodos ágeis.
- 47. Modelo de Entregaem Estágios RAUL
- 48. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 49. Modelo de EntregaEvolucionária • É um misto de prototipação evolucionária e entrega em estágios em que se pode adaptar o cronograma de desenvolvimento a necessidades de última hora, em função de prioridades definidas.
- 50. Modelo de EntregaEvolucionária • Desenvolver uma versão do produto • Mostrar ao cliente a versão desenvolvida • Criar novas versões baseadas no feedback do cliente • Une a flexiilidade da Prototipação Evolucionária e o planejamento da Entrega em estágios
- 51. Modelo de EntregaEvolucionária • Grau de aproximação deste modelo em relação a: • Prototipação Evolucionária: se pretende acomodar todas as modificações • Entrega em Estágios: se as entregas continuarem sendo planejadas de acordo com o previsto e as modificações são acomodadas aos poucos nas entregas
- 52. Modelo de EntregaEvolucionária • A diferença está na ênfase • Prototipação Evolucionária: aspectos visíveis do sistema • Entrega Evolucionária: funcionalidades mais críticas do sistema
- 53. Modelos de Processosde Software Prescritivos/Clássicos/Tradicionais Codificar e Consertar Programador -Chefe Cascata Entrelaçado Subprojetos Redução de Riscos Modelo V Modelo W Incremental Evolucionário Prototipação Espiral Prototipação Evolucionária Entrega Evolucionária Entrega em Estágios Orientado a Cronograma Orientado a Ferramenta Concorrente
- 54. Modelo de Orientadoa Cronograma • Indica que se podem priorizar requisitos de forma que, se o tempo disponível acabar antes do projeto, pelo menos os requisitos mais importantes terão sido incorporados.
- 55. Modelo de Orientadoa Cronograma • Similar ao modelo de entregas em estágios • Não se sabe a priori quais funcionalidades serão entregues a cada ciclo • Prevê que os ciclos terminarão em determinada data • Funcionalidades implementadas até a data serão entregues • As funcionalidades mais importantes devem ser priorizadas e entregues primeiro
- 56. Modelo de Orientadoa Cronograma
- 57. Modelo de Orientadoa Cronograma • A cada iteração: um conjunto de requisitos é desenvolvido • O Projeto é encerrado quando: • O tempo limite é atingido • Ou quando todos os requistos foram atendidos
- 58. Modelo de Orientadoa Cronograma • Estratégia para garantir que haverá ALGUM produto disponível em determinada data • Modelo apropriado par quando a data de entrega é intransferível • A duração dos ciclos não é estabelecida
- 59. REFERÊNCIAS 1. TSUI, Frank;KARAM, Orlando. Fundamentos da Engenharia de Software. Tradução e Revisão Técnica de Edson Tanaka. 2.ª Edição. Rio de Janeiro: LTC, 2013. 2. WAZLAWICK, Raul Sidnei. Engenharia de Software: Conceitos e Práticas. 1.ª edição. Rio de Janeiro: Elsevier, 2013.
- 60. REFERÊNCIAS 3. PRESSMAN, R.S.; MAXIM, B. R. Engenharia de Software: Uma Abordagem Profissional. Tradução: João Eduardo Nóbrega Tortello. Revisão Técnica: Reginaldo Arakaki, Julio Arakaki, Renato Manzan de Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016. 4.FILHO, W. P. P. Engenharia de Software: Fundamentos, Métodos e Padrões. 3.ª Edição.Rio de Janeiro: LTC, 2015