1 / 37

Processos de Software II

Processos de Software II. Modelo RAD. Modelo RAD ( Rapid Application Development. É o modelo seqüencial linear mas que enfatiza um desenvolvimento extremamente rápido; A “alta velocidade” é conseguida através de uma abordagem de construção baseada em componentes;

efrat
Download Presentation

Processos de Software II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Processos de Software II

  2. Modelo RAD

  3. Modelo RAD (Rapid Application Development • É o modelo seqüencial linear mas que enfatiza um desenvolvimento extremamente rápido; • A “alta velocidade” é conseguida através de uma abordagem de construção baseada em componentes; • Usado quando os requisitos são bem definidos e o escopo do sistema é restrito.

  4. Modelo RAD • Esse modelo se enquadra nas atividades genéricas. • Comunicação – para entender problema. • Planejamento – essencial tendo em vista que várias equipes trabalham em paralelo. • Modelagem – estabelece representações do projeto que servem de base para atividade de construção. • Construção – enfatiza uso de componentes preexistentes e aplicação da geração automática de código.

  5. modelagem do negócio modelagem do negócio modelagem do negócio modelagem dos dados modelagem dos dados modelagem do processo modelagem dos dados modelagem do processo geração da aplicação modelagem do processo geração da aplicação teste e modificação geração da aplicação teste e modificação teste e modificação Modelo RAD equipe # 3 equipe # 2 equipe # 1 60-90 dias

  6. modelagem do negócio modelagem dos dados modelagem do processo geração da aplicação teste e modificação Atividades do Modelo RAD Modelagem do negócio: o fluxo de informação entre as funções do negócio são modeladas de maneira a responder às questões:  que informação dirige o processo do negócio?  que informação é gerada?  quem gera a informação?  para onde a informação vai?  quem a processa?

  7. modelagem do negócio modelagem dos dados modelagem do processo geração da aplicação teste e modificação Atividades do Modelo RAD Modelagem dos dados: o fluxo de informação definido na fase anterior é refinado em um conjunto de objetos de dados que são necessários para dar suporte ao negócio; são identificadas as características de cada objeto e são definidos seus relacionamentos

  8. modelagem do negócio modelagem dos dados modelagem do processo geração da aplicação teste e modificação Atividades do Modelo RAD Modelagem do processo: os objetos de dados definidos são transformados para se obter o fluxo de informação necessário para implementar uma função do negócio; são criadas as descrições dos processamentos necessários para manipular esses objetos de dados

  9. modelagem do negócio modelagem dos dados modelagem do processo geração da aplicação teste e modificação Atividades do Modelo RAD Geração da aplicação: o modelo RAD assume o uso de técnicas de 4a. geração; ao invés de criar software de forma convencional, reusa componentes quando possível ou cria componentes reutilizáveis; ferramentas automatizadas são utilizadas para gerar software

  10. modelagem do negócio modelagem dos dados modelagem do processo geração da aplicação teste e modificação Atividades do Modelo RAD Teste e modificação: por reutilizar componentes, muitas vezes eles já foram testados, o que reduz o tempo de teste; os novos componentes devem ser testados e as interfaces devem ser exercitadas

  11. Modelo RAD • Quandousar? • As restrições de tempo impostaspeloprojetodemandam um escopo de escala • Quando a aplicaçãopode ser modularizada de forma quecadagrandefunçãopossa ser completada em menos de 3 meses • Cadagrandefunçãopode ser alocadaparaumaequipedistinta e, depoissãointegradasparaformar o todo

  12. Problemas com o Modelo RAD • Para projetosescaláveis, masgrandes, o RAD requerrecursoshumanossuficientesparacriar um númeroadequado de equipes; • RAD requer um comprometimento entre desenvolvedores e clientesparaque as atividadespossam ser realizadasrapidamente e o sistemasejaconcluído em um tempo abreviado; • Se o comprometimento for abandonadoporqualquer das partes, o projetofalhará; • Não é apropriadoquandoosriscossãograndes;

  13. Prototipação

  14. Prototipação • processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. • idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. • apropriado quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.

  15. início fim obtençãodosrequisitos projetorápido construçãoproduto construçãoprotótipo refinamentoprotótipo avaliaçãoprotótipo Prototipação

  16. construa/revise protótipo ouça o cliente teste do protótipo pelo cliente Prototipação Simplificando

  17. início fim obtenção dos requisitos projeto rápido construção produto construção protótipo refinamento protótipo avaliação protótipo Prototipação • 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 • 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)

  18. início fim obtenção dos requisitos projeto rápido construção produto construção protótipo refinamento protótipo avaliação protótipo Prototipação • Construção Protótipo: implementação rápida do projeto • Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo

  19. início fim obtenção dos requisitos projeto rápido construção produto construção protótipo refinamento protótipo avaliação protótipo Prototipação • Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. • Ocorre neste ponto um processo de iteração que pode conduzir à 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito.

  20. início fim obtenção dos requisitos projeto rápido construção produto construção protótipo refinamento protótipo avaliação protótipo Prototipação 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.

  21. Prototipação • Problemas: • 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. Não aceita bem a idéia de que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final; • desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele se familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final;

  22. Prototipação • Comentários: • Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente • A chave é definirem-se as regras do jogo logo no começo • O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos

  23. Espiral e Concorrente

  24. Modelo Espiral • engloba a natureza iterativa da Prototipação com os aspectos sistemáticos e controlados do Modelo Linear • fornece o potencial para o desenvolvimento rápido de versões incrementais do software • Cada Loop da espira é uma fase do desenvolvimento que sempre passa por 4 aspectos

  25. Modelo Espiral Planejamento Definição de Objetivos Análise de projeto Desenvolvimento e Validação Cada loop da espira é uma fase de desenvolvimento do software; Avaliação e redução de risco

  26. Modelo Espiral • é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala • usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva • pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável • exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

  27. Modelo de Desenvolvimento Concorrente • é representado como uma série de grandes atividades técnicas, tarefas e seus estados associados • ele define uma série de eventos que podem disparar transições de um estado para outro, para cada uma das atividades da engenharia de software • é freqüentemente usado como um paradigma para o desenvolvimento de aplicações Cliente/Servidor • pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto

  28. Modelo de Desenvolvimento Concorrente none Atividade de Análise em desenvolvimento sob inspeção aguardando mudanças sob revisão averiguado realizado

  29. Técnicas da 4ª Geração

  30. Técnicas de 4a Geração • Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. • Engloba um conjunto de ferramentas de software que possibilitam que: • o sistema seja especificado em uma linguagem de alto nível e • o código fonte seja gerado automaticamente a partir dessas especificações

  31. Obtenção dos Requisitos Estratégia do “Projeto” Implementação usando 4GL Testes Técnicas de 4a Geração

  32. Técnicas de 4ª Geração PROPONENTES:redução dramática no tempo de desenvolvimento do software (aumento de produtividade); OPONENTES:as 4GL atuais não são mais fáceis de usar do que as linguagens de programação; • o código fonte produzido é ineficiente • a manutenibilidade de sistemas usando técnicas 4G ainda é questionável

  33. Processo de Software – Conclusão ENGENHARIA DE SOFTWARE pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos. .....“a construção por múltiplas pessoas de um software de múltiplas versões” [Parnas 1987]

  34. Exercício • O que são modelos de engenharia de software? • Quais são as fases do Ciclo de Vida Clássico de Software? Descreva-as sucintamente. Dê dois exemplos de projetos de software que seriam adequados para esse modelo. • O que é o paradigma evolutivo da Engenharia de Software (ES)? Cite dois exemplos de modelos que empregam o paradigma evolutivo da ES. Para cada modelo que você citou dê dois exemplos de projetos de software que seriam adequados para esse modelo. • Descreva o paradigma de desenvolvimento em espiral. Compare este modelo com os outros paradigmas estudados (Ciclo de Vida Clássico e Evolutivo).

  35. Exercícios • Desenvolva um conjunto de tarefas para a atividade de comunicação. • Descreva um arcabouço do processo com suas próprias palavras. Quando se diz que as atividades de arcabouço são aplicadas a todos os projetos, isso quer dizer que as mesmas tarefas de trabalho são aplicadas a todos os projetos, independentemente do tamanho e da complexidade, explique. • O que é mais importante: o produto ou o processo?

  36. Qualidade Exercícios • A figura abaixo coloca as camadas da engenharia de software sobre uma camada denominada “qualidade”. Isso implica um programa de qualidade para toda a organização tal como de qualidade total. Pesquise e faça um esboço dos pontos-chave de um programa de gestão de qualidade total.

  37. Exercícios • Faça o download da documentação do CMMI do site da SEI na web e selecione uma área de processo diferente do planejamento. Faça uma lista das metas especificas e das práticas específicas associadas definidas para a área que você escolheu.

More Related