Transcription
Processos deDesenvolvimento deSoftwareRicardo Argenton RamosUNIVASFEngenharia de Software I - Aula 2
A Engenharia de SoftwareUma Tecnologia em Camadastasnemaferrosmétodsoprocesdeadilauaqfoco nGerenciamento da Qualidade Total e filosofias similaresproduzem uma mudança cultural que permite odesenvolvimento crescente de abordagens mais maduras paraa Engenharia de SoftwareModelos de Processos2
ENGENHARIA DE SOFTWAREpode ser vista como uma abordagem dedesenvolvimentode software elaborada com disciplina e métodos bemdefinidos.“a construção por múltiplas pessoas de umsoftware com múltiplas versões” [Parnas 1987]Modelos de Processos3
Introdução O processo de software é visto por uma seqüênciade atividades que produzem uma variedade dedocumentos, resultando em um programasatisfatório e executável.Os níveis e arquitetura do processo de software éformada por: Nível Universal: possa utilizar em qualquer projeto;Nível Mundial: Específico para um determinado projeto;Nível Atômico: Seqüência algorítmica do projeto,específico para as tarefas do processo.Modelos de Processos4
Introdução O desenvolvimento de software tem-se caracterizado por umasobreposição de atividades necessárias para especificar,projetar e testar retorno dos resultados do software que estásendo criado.O feedback dessa atividade nos ajuda a compreender o que énecessário para criar um produto.A partir do feedback obtido em experiências com protótipos,podemos efetuar mudanças na forma e na construção conceitualdo software.O feedback possui quatro formas básicas: Medições da entidade do software: número derivado deresultados produzidos por processos executores; Corretiva: erros, faltas e falhas cometidas no software; Mudança: Modificar o software para eliminar defeitos; Aprimoramento: Aperfeiçoar o software.Modelos de Processos5
Modelos de Processo deSoftware Existem vários modelos de processo desoftware (ou paradigmas de engenharia desoftware)Cada um representa uma tentativa decolocar ordem em uma atividadeinerentemente caóticaModelos de Processos6
Modelos de Processo deSoftware O Modelo Sequencial Linear O Modelo de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos7
Modelos de Processo deSoftware O Modelo Sequencial Linear O Paradigma de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos8
O Modelo Cascata modelo mais antigo e o mais amplamenteusado da engenharia de softwaremodelado em função do ciclo da engenhariaconvencionalrequer uma abordagem sistemática,seqüencial ao desenvolvimento de softwareo resultado de uma fase se constitui naentrada da outraModelos de Processos9
O Modelo em CascataVerificar PlanoExploração deRequisitos de V & VconceitosRequisitosO quêProjeto de V & VProjetoImplementaçãoEvoluirTestesComoSistema de V & VTarefas de V & VOperaçãoSistemaInstalação ede V & VliberaçãoOperaçãoManutenção ede V & VoperaçãoFeedbackModelos de Processos10
O Modelo em CascataExploração de Conceitos / Informação eModelagemEngenharia deSistemasAnálise deRequisitosde requisitos do sistema, com uma pequena Envolve a elicitaçãoProjeto quantidade de projeto e análise de alto nível;Codificação como engenhariaPreocupa-se com aquilo que conhecemosprogressiva de produto de software;TestesIniciar com um modelo conceitual de alto nível para um sistema eManutençãoprosseguir com o projeto, implementação e testedo modelo físico dosistema.Modelos de Processos11
O Modelo em Cascata Análise de Requisitos de Softwareo processodede elicitação dos requisitos adoespecificamente nodeRequisitossoftwareProjetodeve-se compreender o domínioCodificação da informação, afunção, desempenho e interfacesexigidosTestesos requisitos (para o sistema e para o Manutençãosoftware) sãodocumentados e revistos com o clienteModelos de Processos12
O Modelo em Cascata Projetotradução dos requisitos do software para umconjunto de representações que podem seravaliadas quanto à qualidade, antes que acodificação inicieModelos de Processos13
O Modelo em Cascata Implementaçãotradução das representações do projeto para umalinguagem “artificial” resultando em instruçõesexecutáveis pelo computador e implementadonum ambiente de trabalho.Modelos de Processos14
O Modelo em CascataTestes Concentra-se: nos aspectos lógicos internos do software,garantindo que todas as instruções tenham sidotestadasnos aspectos funcionais externos, para descobrirerros e garantir que a entrada definida produzaresultados que concordem com os esperados.Modelos de Processos15
O Modelo em Cascata Manutençãoprovavelmente o software deverá sofrermudanças depois que for entregue ao clientecausas das mudanças: erros, adaptação dosoftware para acomodar mudanças em seuambiente externo e exigência do cliente paraacréscimos funcionais e de desempenhoModelos de Processos16
Problemas com o Modelo emCascata Projetos reais raramente seguem o fluxoseqüencial que o modelo propõe;Logo no início é difícil estabelecer explicitamentetodos os requisitos. No começo dos projetossempre existe uma incerteza natural;O cliente deve ter paciência. Uma versãoexecutável do software só fica disponível numaetapa avançada do desenvolvimento (nainstalação);Difícil identificação de sistemas legados (nãoacomoda a engenharia reversa).Modelos de Processos17
Problemas com o Modelo emCascata Embora o Modelo emCascata tenhafragilidades, ele ésignificativamente melhordo que uma abordagemcasual de desenvolvimentode software.Modelos de Processos18
O Modelo em Cascata O Modelo de processo em Cascata trouxecontribuições importantes para o processo dedesenvolvimento de software: Imposição de disciplina, planejamento egerenciamentoa implementação do produto deve ser postergada atéque os objetivos tenham sido completamente entendidos;Permite gerência do baseline, que identifica um conjuntofixo de documentos produzidos ao longo do processo dedesenvolvimento;Modelos de Processos19
Modelos de Processo deSoftware O Modelo Sequencial Linear O Paradigma de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos20
O Modelo de Prototipação o objetivo é entender os requisitos do usuárioe, assim, obter uma melhor definição dosrequisitos do sistema.possibilita que o desenvolvedor crie ummodelo (protótipo)do software que deve serconstruídoapropriado para quando o cliente não definiudetalhadamente os requisitos.Modelos de Processos21
O Paradigma de Prototipaçãopara obtenção dos requisitosObter RequisitosElaborar Projeto RápidoRefinamento do ProtótipoConstruir ProtótipoAvaliar ProtótipoModelos de Processos22
O Paradigma de Prototipaçãopara obtenção dos requisitos1- OBTENÇÃO DOS REQUISITOS:Obter Requisitosdesenvolvedor e cliente definem osobjetivos gerais do software,identificam quais requisitossão Projeto RápidoElaborarconhecidos e as áreas queRefinamento do Protótiponecessitam de definições adicionais.Construir ProtótipoAvaliar ProtótipoModelos de Processos23
O Paradigma de Prototipaçãopara obtenção dos requisitosObter Requisitos2- PROJETO RÁPIDO:Elaborar Projeto Rápidorepresentação dos aspectos doRefinamento do Protótiposoftware que são visíveis ao usuário(abordagens de entrada e formatosde saída)Construir ProtótipoAvaliar ProtótipoModelos de Processos24
O Paradigma de Prototipaçãopara obtenção dos requisitosObter RequisitosElaborar Projeto RápidoRefinamento do Protótipo3- CONSTRUÇÃO DO PROTÓTIPO:implementação rápida doprojetoConstruir ProtótipoAvaliar ProtótipoModelos de Processos25
O Paradigma de Prototipaçãopara obtenção dos requisitosObter RequisitosElaborar Projeto RápidoRefinamento do Protótipo4- AVALIAÇÃO DO PROTÓTIPO: clienteProtótipoe desenvolvedor avaliam Construiro protótipoAvaliar ProtótipoModelos de Processos26
O Paradigma de Prototipaçãopara obtenção dos requisitosObter RequisitosElaborarProjeto5- REFINAMENTO DO PROTÓTIPO:clientee RápidoRefinamentodo Protótipodesenvolvedorrefinamos requisitos dosoftware a ser desenvolvido.Construir ProtótipoAvaliar ProtótipoModelos de Processos27
O Paradigma de Prototipaçãopara obtenção dos requisitosObter RequisitosCONSTRUÇÃORefinamentodo ProtótipoDOPRODUTOElaborar Projeto RápidoConstruir ProtótipoAvaliar ProtótipoModelos de Processos28
O Paradigma de Prototipaçãopara obtenção dos requisitosObter Requisitos6- CONSTRUÇÃO PRODUTO:identificados os requisitos, oElaborarProjeto rsãode doproduçãoRefinamentoProtótipo deve serDOPRODUTOconstruída considerando oscritérios de qualidade.Construir ProtótipoAvaliar ProtótipoModelos de Processos29
Problemas com a Prototipação cliente não sabe que o software que ele vênão considerou, durante o desenvolvimento,a qualidade global e a manutenibilidade alongo prazodesenvolvedor freqüentemente faz umaimplementação comprometida (utilizando oque está disponível) com o objetivo deproduzir rapidamente um protótipoModelos de Processos30
Comentários sobre oParadigma de Prototipação ainda que possam ocorrer problemas, aprototipação é um ciclo de vida eficiente.a chave é definir as regras do jogo logo nocomeço.o cliente e o desenvolvedor devem ambosconcordar que o protótipo seja construídopara servir como um mecanismo para definiros requisitosModelos de Processos31
Modelos de Processo deSoftware O Modelo Sequencial Linear O Paradigma de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesO Modelo de Desenvolvimento ConcorrenteModelos de Métodos FormaisTécnicas de Quarta GeraçãoModelos de Processos32
O Modelo RAD RAD ( Rapid Application Development) é ummodelo sequencial linear que enfatiza umciclo de desenvolvimento extremamentecurtoO desenvolvimento rápido é obtido usandouma abordagem de construção baseada emcomponentes.Modelos de Processos33
O Modelo RAD Os requisitos devem ser bem entendidos e oalcance do projeto restritoO modelo RAD é usado principalmente paraaplicações de sistema de informaçãoCada função principal pode ser direcionadapara uma equipe RAD separada e entãointegrada para formar o todo.Modelos de Processos34
O Modelo RADEquipe #3Equipe #1Equipe #2Modelagemdo NegócioModelagemdo NegócioModelagemModelagemdos Dadosdo NegócioModelagemModelagemModelagemdo Processodos DadosGeração dados DadosModelagemAplicaçãodo ProcessoModelagemTeste eGeração daModificaçãodo ProcessoAplicaçãoTeste eGeração daModificaçãoAplicação60 a 90 diasTeste eModificaçãoModelos de Processos35
O Modelo RADDesvantagens: Exige recursos humanos suficientes para todasas equipesExige que desenvolvedores e clientes estejamcomprometidos com as atividades de “fogorápido” a fim de terminar o projeto num prazocurtoModelos de Processos36
O Modelo RAD Nem todos os tipos de aplicação sãoapropriadas para o RAD: Deve ser possível a modularização efetiva daaplicaçãose alto desempenho é uma característica e odesempenho é obtido sintonizando as interfacesdos componentes do sistema, a abordagem RADpode não funcionarModelos de Processos37
Modelos de Processo deSoftware O Modelo Sequencial Linear O Paradigma de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos38
Modelos Evolutivos deProcesso Existem situações em que a engenharia desoftware necessita de um modelo deprocesso que possa acomodar um produtoque evolui com o tempo.Modelos de Processos39
Modelos Evolutivos deProcesso quando os requisitos de produto e denegócio mudam conforme odesenvolvimento prosseguequando uma data de entrega apertada(mercado) - impossível a conclusão de umproduto completoquando um conjunto de requisitosimportantes é bem conhecido, porém osdetalhes ainda devem ser definidosModelos de Processos40
Modelos Evolutivos deProcesso modelos evolutivos são iterativospossibilitam o desenvolvimento de versõescada vez mais completas do softwareModelos de Processos41
Modelos de Processo deSoftware O Modelo Sequencial Linear O Paradigma de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos42
O Modelo Incremental o modelo incremental combina elementosdo modelo cascata (aplicado repetidamente)com a filosofia iterativa da prototipaçãoo objetivo é trabalhar junto do usuário paradescobrir seus requisitos, de maneiraincremental, até que o produto final sejaobtido.Modelos de Processos43
O Modelo �ogeralProjetoProjetoEngenharia �ãoTesteTesteModelos de ProcessosVersãoFinal44
O Modelo Incremental a versão inicial é frequentemente o núcleodo produto (a parte mais importante) a evolução acontece quando novascaracterísticas são adicionadas à medida quesão sugeridas pelo usuárioEste modelo é importante quando é difícilestabelecer a priori uma especificaçãodetalhada dos requisitosModelos de Processos45
O Modelo Incremental o modelo incremental é mais apropriadopara sistemas pequenosAs novas versões podem ser planejadas demodo que os riscos técnicos possam seradministrados (Ex. disponibilidade dedeterminado hardware)Modelos de Processos46
Modelos de Processo deSoftware O Modelo Sequencial Linear O Modelo de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos47
O Modelo Espiral (Boehm,1986) O modelo espiral acopla a natureza iterativa daprototipação com os aspectos controlados esistemáticos do modelo cascata.O modelo espiral é dividido em uma série deatividades de trabalho ou regiões de tarefa.Existem tipicamente de 3 a 6 regiões de tarefa.Combina as características positivas da gerênciabaseline (documentos associados ao processo);Modelos de Processos48
O Modelo Espiral (com 4 regiões)AVALIAR ALTERNATIVASIDENTIFICAR, RESOLVER RISCOSDETERMINAR OBJETIVOS,ALTERNATIVAS ERESTRIÇÕESRiskanalys isRiskanalys isRiskanalys isREVIEWRequirements planLife-cycle planDevelop mentplanIntegrati onand test p lanPLANEJAR PRÓXIMA FASEProt otyp e 3Prot otyp e 2Riskanalysis Prot oty pe 1Operati onalprotoyp eSim ul ati ons, m odels, b en ch marksConcept o fOperati onS/Wrequi rement sRequi rementvalid ati onProd uctdesi gnDetail eddesi gnCodeUni t tes tDesi gnV& VIntegr ati ontestAccep tancetestServ iceDESENVOLVER, VERIFICAR OPRODUTO NO PRÓXIMO NÍVELModelos de Processos49
O Modelo Espiral (com 4 regiões)AVALIAR ALTERNATIVASIDENTIFICAR, RESOLVER RISCOSDETERMINAR OBJETIVOS,ALTERNATIVAS ERESTRIÇÕESRiskanalys isRiskanalys iscada ciclo na espiralrepresenta umaREVIEWfase do processodeRequirements planLife-cycle plansoftwareDevelop mentplanIntegrati onand test p lanPLANEJAR PRÓXIMA FASERiskanalys isProt otyp e 3Prot otyp e 2Riskanalysis Prot oty pe 1Operati onalprotoyp eSim ul ati ons, m odels, b en ch marksConcept o fOperati onS/Wrequi rement sRequi rementvalid ati onProd uctdesi gnDetail eddesi gnCodeUni t tes tDesi gnV& VIntegr ati ontestAccep tancetestServ iceDESENVOLVER, VERIFICAR OPRODUTO NO PRÓXIMO NÍVELModelos de Processos50
O Modelo Espiral de Processo deSoftwareo ciclo mais internoestá concentradonas possibilidadesdo sistemaREVIEWRequirements planLife-cycle planRiskanalysis Prototy pe 1Concept o fOperati onModelos de Processos51
O Modelo Espiral de Processo deSoftwareo próximo ciclo estáconcentrado nadefinição dosrequisitos dosistemaRiskanalys isPrototypeSimul ati ons, models, benchmarksSWrequi rementsDevelopmentplanRequi rementvalidati onModelos de Processos52
O Modelo Espiral de Processo deSoftwareRiskanalys iso ciclo um poucomais externo estáconcentrado noprojeto do sistemaIntegrati onand test planprototype 3si mul ati ons, models, benchmarksProductdesi gnDesi gnV&VModelos de Processos53
O Modelo Espiral de Processo deSoftwareRisknalys isum ciclo ainda maisexterno estáconcentrado naconstrução dosistemaOperati onalprotoypeSimul ati ons, models, benchmarksDetail eddesi gnCodeUni t tes tIntegrati ontestAcceptancetestServ iceModelos de Processos54
O Modelo Espiral (com 4 regiões)AVALIAR ALTERNATIVASIDENTIFICAR, RESOLVER RISCOSDETERMINAR OBJETIVOS,ALTERNATIVAS ERESTRIÇÕES Riskanalys isnão existem fases fixas no modeloas fases mostradas na figura são meramenteexemplosa gerência decide como estruturar o projetoem fasesRiskanalys isRiskanalys isREVIEW Requirements planLife-cycle planDevelop mentplanIntegrati onand test p lanPLANEJAR PRÓXIMA FASEProt otyp e 3Prot otyp e 2Riskanalysis Prot oty pe 1Operati onalprotoyp eSim ul ati ons, m odels, b en ch marksConcept o fOperati onS/Wrequi rement sRequi rementvalid ati onProd uctdesi gnDetail eddesi gnCodeUni t tes tDesi gnV& VIntegr ati ontestAccep tancetestServ iceDESENVOLVER, VERIFICAR OPRODUTO NO PRÓXIMO NÍVELModelos de Processos55
Cada “loop”Espiraldo espiral(comé divididoO Modelo4 regiões)em 4setoresAVALIAR ALTERNATIVASIDENTIFICAR, RESOLVER RISCOSDETERMINAR OBJETIVOS,ALTERNATIVAS ERESTRIÇÕESRiskanalys isRiskanalys isESTABELECIMENTO DEOBJETIVOSRiskanalys isREVIEWRequirements planLife-cycle planPLANEJAMENTODevelop mentplanIntegrati onand test p lanPLANEJAR PRÓXIMA FASEAVALIAÇÃO EREDUÇÃO DERISCOS OperaProt otyp e 3ti onalprotoyp eProt otyp e 2Riskanalysis Prot oty pe 1Sim ul ati ons, m odels, b en ch marksConcept o fOperati onS/Wrequi rement sDetail eddesi gnDESENVOLVIMENTO ECodeVALIDAÇÃOUni t tes tRequi rementvalid ati onDesi gnV& VProd uctdesi gnIntegr ati ontestAccep tancetestServ iceDESENVOLVER, VERIFICAR OPRODUTO NO PRÓXIMO NÍVELModelos de Processos56
O Modelo Espiral de Processo deSoftwaresão definidos objetivosESTABELECIMENTO DEOBJETIVOSespecíficos para a fase do projetosão identificadas restrições sobreo processo e o produtoé projetado um plano degerenciamento detalhadosão identificados riscos doprojetodependendo dos riscos,estratégias alternativas podemser planejadasModelos de Processos57
O Modelo Espiral de Processo deSoftwarepara cada um dos riscosidentificados,AVALIAÇÃO ECOLOCAÇÃO DEuma análisedetalhada é executada.REDUÇÃO DEOBJETIVOSpassos são tomados para reduzir oRISCOSriscoModelos de Processos58
O Modelo Espiral de Processo deSoftwareAVALIAÇÃO EREDUÇÃO DERISCOSESTABELECIMENTO DEOBJETIVOSdepois da avaliação do risco, ummodelo de desenvolvimento éescolhido para o sistemaDESENVOLVIMENTOE VALIDAÇÃOModelos de Processos59
O Modelo Espiral de Processo deSoftwareAVALIAÇÃO ECOLOCAÇÃO DEREDUÇÃO DEOBJETIVOSRISCOSo projeto é revisto e é tomadauma decisão de continuidadese é decidido continuar, sãoprojetados planospara a próximaDESENVOLVIMENTOPLANEJAMENTOfase do projeto (próximo“loop”)E VALIDAÇÃOModelos de Processos60
O Modelo Espiralengloba as melhores características do ciclo devida Clássico e da Prototipação, adicionando umnovo elemento: a Análise de Risco segue a abordagem de passos sistemáticos doCiclo de Vida Clássico incorporando-os numaestrutura iterativa que reflete mais realisticamenteo mundo real usa a Prototipação em todas as etapas daevolução do produto, como mecanismo de reduçãode riscos Modelos de Processos61
Comentários sobre o Ciclo deVida em Espiral é, atualmente, a abordagem mais realísticapara o desenvolvimento de software emgrande escala. usa uma abordagem que capacita odesenvolvedor e o cliente a entender ereagir aos riscos em cada etapa evolutivapode ser difícil convencer os clientes queuma abordagem "evolutiva" é controlável Modelos de Processos62
Comentários sobre o Ciclo deVida em Espiral exige considerável experiência nadeterminação de riscos e depende dessaexperiência para ter sucesso o modelo é relativamente novo e não temsido amplamente usado. Demorará muitosanos até que a eficácia desse modelo possaser determinada com certeza absolutaModelos de Processos63
O Modelo Espiral (com 6 regiões)(win win)PlanejamentoAnálise de RiscosComunicaçãocom ClienteEngenhariaAvaliação do ClienteConstrução e LiberaçãoModelos de Processos64
O Modelo Espiral adiciona um novo elemento: a Análise de Riscousa a Prototipação, em qualquer etapa daevolução do produto, como mecanismo de reduçãode riscosexige considerável experiência na determinação deriscos e depende dessa experiência para tersucessoo modelo é relativamente novo e não tem sidoamplamente usado.Modelos de Processos65
Modelos de Processo deSoftware O Modelo Sequencial Linear O Modelo de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos66
O Modelo de Montagem deComponentes Utiliza tecnologias orientadas a objetoQuando projetadas e implementadasapropriadamente as classes orientadas aobjeto são reutilizáveis em diferentesaplicações e arquiteturas de sistemaO modelo de montagem de componentesincorpora muitas das características domodelo espiral.Modelos de Processos67
O Modelo de Montagem deComponentesPlanejamentoAnálise de RiscosComunicaçãocom ClienteAvaliação do ClienteEngenhariaConstrução e LiberaçãoModelos de Processos68
O Modeloidentificarde Montagem decomponentesComponentescandidatasprocurar PlanejamentoConstruir a nacomponentesiteração dona mClientese disponíveisAnálise de Riscoscolocar osnovoscomponentesna bibliotecaconstruir oscomponentesnãoAvaliação do ClientedisponíveisEngenhariaConstrução e LiberaçãoModelos de Processos69
O Modelo de Montagem deComponentes O modelo de montagem de componentes conduz aoreuso do softwarea reusabilidade fornece uma série de benefícios: redução de até 70% no tempo de desenvolvimentoredução de até 84% no custo do projetoíndice de produtividade de até 26.2 (normal da indústria é de16.9)esses resultados dependem da robustez da bibliotecade componentesModelos de Processos70
Modelos de Processo deSoftware O Modelo Sequencial Linear O Modelo de PrototipaçãoO Modelo RAD (Rapid Application Development)Modelos Evolutivos de Processo de Software também chamado Modelo CascataO Modelo IncrementalO Modelo EspiralO Modelo de Montagem de ComponentesTécnicas de Quarta GeraçãoModelos de Processos71
Técnicas de 4a Geração Concentra-se na capacidade de seespecificar o software para uma máquina emum nível que esteja próximo à linguagemnaturalEngloba um conjunto de ferramentas desoftware que possibilitam que: o sistema seja especificado em uma linguagemde alto nível eo código fonte seja gerado automaticamente apartir dessas especificaçõesModelos de Processos72
Ferramentas do Ambiente dasTécnicas de 4a Geração O ambiente de desenvolvimento de softwareque sustenta o ciclo de vida de 4a geraçãoinclui as ferramentas: linguagens não procedimentais para consulta de bancode dadosgeração de relatóriosmanipulação de dadosinteração e definição de telasgeração de códigoscapacidade gráfica de alto nívelcapacidade de planilhas eletrônicasModelos de Processos73
Técnicas de 4a GeraçãoObtenção dosRequisitosEstratégia do“Projeto”Implementaçãousando 4GLTestesModelos de Processos74
Técnicas de 4a GeraçãoOBTENÇÃO DOS REQUISITOS:Obtenção dos oRequisitoscliente descreve os requisitos, que sãotraduzidosEstratégiapara um protótipooperacionaldo“Projeto” o cliente podeestar inseguroquanto aosImplementaçãorequisitosusando 4GLTestes o cliente pode ser incapaz de especificar asinformações de um modo que uma ferramenta4GL possa consumir as 4GLs atuais não são sofisticadassuficientemente para acomodar a verdadeira"linguagem natural"Modelos de Processos75
Técnicas de 4a GeraçãoObtençãodosESTRATÉGIADO "PROJETO":Requisitos Para pequenas aplicações é possível moverEstratégia dose do passode Obtenção dos Requisitos“Projeto”Implementação usando umapara o passo de Implementação4GLlinguagem de quartausandogeraçãoTestes Para grandes projetos é necessáriodesenvolver uma estratégia de projeto. Deoutro modo ocorrerão os mesmos problemasencontrados quando se usa abordagemconvencional (baixa qualidade)Modelos de Processos76
Técnicas de 4a GeraçãoObtenção dosRequisitosEstratégia doIMPLEMENTAÇÃOUSANDO 4GL :“Projeto”Os resultadosdesejadossão representados deImplementaçãomodo que haja geraçãoautomáticausando4GL de código .Deve existir uma estrutura de dados comTestesinformações relevantes e que seja acessívelpela 4GLModelos de Processos77
Técnicas de 4a GeraçãoObtenção dosRequisitosEstratégia do“Projeto”Implementaçãousando 4GLTestesTESTES:O desenvolvedor deve efetuar testes edesenvolver uma documentação significativa.O software desenvolvido deve ser construídode maneira que a manutenção possa serefetuada prontamente.Modelos de Processos78
Comentários sobre asTécnicas de 4a Geração PROPONENTES: redução dramática no tempo de desenvolvimentodo software (aumento de produtividade)OPONENTES:OPONENTES as 4GL atuais não são mais fáceis de usar doque as linguagens de programaçãoo código fonte produzido é ineficientea manutenibilidade de sistemas usando técnicas4GL ainda é questionávelModelos de Processos79
Para escolha de um Modelo deProcesso de Software: natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam serentreguesModelos de Processos80
Processos de Desenvolvimento de Software Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 2
