Modelos de Processo de Software

Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa

1o semestre de 2016

2

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]

3

Modelos de Processo de Software Ø  Existem vários modelos de processo de

software (ou paradigmas de engenharia de software)

Ø  Cada um representa uma tentativa de colocar ordem em uma atividade inerentemente caótica

4

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Modelo de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelo de Métodos Formais Ø  Técnicas de Quarta Geração

5

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Paradigma de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

6

O Modelo Cascata

Ø  modelo mais 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

O Modelo Cascata

Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação

Testes

Manutenção

8

Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação

Testes

Manutenção

O Modelo Cascata

Engenharia de Sistemas / Informação e Modelagem

Ø  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)

9

O Modelo Cascata

Engenharia de Sistemas

Análise de 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

10

O Modelo Cascata

Engenharia de Sistemas

Análise de 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

11

O Modelo Cascata

Engenharia de Sistemas

Análise de 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

12

O Modelo Cascata

Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação

Testes

Manutenção

Testes Ø  Concentra-se:

§  nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas

§  nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

13

O Modelo Cascata

Engenharia de Sistemas

Análise de 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

14

Problemas com o Modelo Cascata M  Projetos reais raramente seguem o fluxo

seqüencial que o modelo propõe M  Logo no início é difícil estabelecer

explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural

M  O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

15

Problemas com o Modelo Cascata M  Projetos reais raramente seguem o fluxo

seqüencial que o modelo propõe M  Logo no início é difícil estabelecer

explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural

M  O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

ü Embora o Modelo Cascata

tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

16

O Modelo Cascata

Ø  O modelo 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

17

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Modelo de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

18

O 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

Ø  apropriado para quando o cliente não definiu detalhadamente os requisitos.

19

O Paradigma de Prototipação para obtenção dos requisitos

Obter Requisitos

Elaborar Projeto Rápido

Construir Protótipo Avaliar Protótipo

Refinamento do Protótipo

20

O Paradigma de Prototipação para obtenção dos requisitos

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.

21

O Paradigma de Prototipação para obtenção dos requisitos

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)

22

O Paradigma de Prototipação para obtenção dos requisitos

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

23

O Paradigma de Prototipação para obtenção dos requisitos

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

24

O Paradigma de Prototipação para obtenção dos requisitos

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.

25

O Paradigma de Prototipação para obtenção dos requisitos

Obter Requisitos

Elaborar Projeto Rápido

Construir Protótipo Avaliar Protótipo

Refinamento do Protótipo CONSTRUÇÃO DO PRODUTO

26

O Paradigma de Prototipação para obtenção dos requisitos

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.

27

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 a longo prazo

Ø  desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo

28

Comentários sobre o Paradigma de Prototipação Ø  ainda que possam ocorrer problemas, a

prototipação é um ciclo de vida eficiente. Ø  a chave é definir-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

29

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Paradigma de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

30

O 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.

31

O Modelo RAD

Ø  Os requisitos devem ser bem entendidos e o alcance do projeto restrito

Ø  O modelo RAD é usado 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.

32

O Modelo RAD

Modelagem do Negócio

Modelagem dos 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

33

O 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

34

O Modelo RAD

Ø  Nem todos 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

35

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Paradigma de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

36

Modelos Evolutivos de Processo

Ø  Existem situações em que a engenharia de software necessita de um modelo de processo que possa acomodar um produto que evolui com o tempo.

37

Modelos Evolutivos de Processo Ø  quando os requisitos de produto e de

negócio mudam conforme o desenvolvimento procede

Ø  quando uma data de entrega apertada (mercado) - impossível a conclusão de um produto completo

Ø  quando um conjunto de requisitos importantes é bem conhecido, porém os detalhes ainda devem ser definidos

38

Modelos Evolutivos de Processo

Ø  modelos evolutivos são iterativos Ø  possibilitam o desenvolvimento de

versões cada vez mais completas do software

39

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Paradigma de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

40

O Modelo Incremental

Ø  o modelo incremental combina elementos do modelo cascata (aplicado repetidamente) com a filosofia iterativa da prototipação

Ø  o objetivo é trabalhar junto do usuário para descobrir seus requisitos, de maneira incremental, até que o produto final seja obtido.

41

O Modelo Incremental

Versão Inicial

Descrição geral Descrição

geral Descrição

geral Versões

Intermediárias

Versão Final

Análise Projeto

Codificação

Teste

Engenharia de sistemas/informação

42

O Modelo Incremental Ø  a versão inicial é frequentemente o

núcleo do produto (a parte mais importante) §  a evolução acontece quando novas

características são adicionadas à medida que são sugeridas pelo usuário

Ø  Este modelo é importante quando é difícil estabelecer a priori uma especificação detalhada dos requisitos

43

O Modelo Incremental Ø  o modelo incremental é mais apropriado

para sistemas pequenos Ø  As novas versões podem ser planejadas

de modo que os riscos técnicos possam ser administrados (Ex. disponibilidade de determinado hardware)

44

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Modelo de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

45

O Modelo Espiral

Ø  O modelo espiral acopla a natureza iterativa da prototipação com os aspectos controlados e sistemáticos do modelo cascata.

Ø  O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa.

Ø  Existem tipicamente de 3 a 6 regiões de tarefa

46

O Modelo Espiral (com 4 regiões)

R i s k a n a l y s i s

R i s k a n a l y s i s

R i s k a n a l y s i s

Risk anal ysis P r o t o -

t y p e 1 P r o t o t y p e 2

P r o t o t y p e 3 O p e r a - t i o n a l p r o t o y p e

C o n c e p t o f O p e r a t i o n

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s S / W

r e q u i r e m e n t s R e q u i r e m e n t

v a l i d a t i o n D e s i g n V & V

P r o d u c t d e s i g n D e t a i l e d

d e s i g n C o d e

U n i t t e s t I n t e g r a t i o n

t e s t A c c e p t a n c e t e s t S e r v i c e

I n t e g r a t i o n a n d t e s t p l a n

D e v e l o p m e n t p l a n

R e q u i r e m e n t s p l a n L i f e - c y c l e p l a n

R E V I E W

DETERMINAR OBJETIVOS, ALTERNATIVAS E

RESTRIÇÕES

PLANEJAR PRÓXIMA FASE

AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS

DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL

47

O Modelo Espiral (com 4 regiões)

R i s k a n a l y s i s

R i s k a n a l y s i s

R i s k a n a l y s i s

Risk anal ysis P r o t o -

t y p e 1 P r o t o t y p e 2

P r o t o t y p e 3 O p e r a - t i o n a l p r o t o y p e

C o n c e p t o f O p e r a t i o n

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s S / W

r e q u i r e m e n t s R e q u i r e m e n t

v a l i d a t i o n D e s i g n V & V

P r o d u c t d e s i g n D e t a i l e d

d e s i g n C o d e

U n i t t e s t I n t e g r a t i o n

t e s t A c c e p t a n c e t e s t S e r v i c e

I n t e g r a t i o n a n d t e s t p l a n

D e v e l o p m e n t p l a n

R e q u i r e m e n t s p l a n L i f e - c y c l e p l a n

R E V I E W

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

48

O Modelo Espiral de Processo de Software

Risk anal ysis P r o t o -

t y p e 1 C o n c e p t o f O p e r a t i o n

R e q u i r e m e n t s p l a n L i f e - c y c l e p l a n

R E V I E W

o “loop” mais interno está concentrado nas possibilidades do sistema

49

O Modelo Espiral de Processo de Software

R i s k a n a l y s i s

P r o t o t y p e

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s SW

r e q u i r e m e n t s R e q u i r e m e n t

v a l i d a t i o n D e v e l o p m e n t p l a n

o próximo “loop” está concentrado na definição dos requisitos do sistema

50

O Modelo Espiral de Processo de Software

R i s k a n a l y s i s

prot o t y p e 3

si m u l a t i o n s , m o d e l s , b e n c h m a r k s

D e s i g n V & V

P r o d u c t d e s i g n

I n t e g r a t i o n a n d t e s t p l a n

o “loop” um pouco mais externo está concentrado no projeto do sistema

51

O Modelo Espiral de Processo de Software

R i s k n a l y s i s

O p e r a - t i o n a l p r o t o y p e

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s

D e t a i l e d d e s i g n

C o d e U n i t t e s t

I n t e g r a t i o n t e s t A c c e p t a n c e

t e s t S e r v i c e

um “loop” ainda mais externo está concentrado na construção do sistema

52

R i s k a n a l y s i s

R i s k a n a l y s i s

R i s k a n a l y s i s

Risk anal ysis P r o t o -

t y p e 1 P r o t o t y p e 2

P r o t o t y p e 3 O p e r a - t i o n a l p r o t o y p e

C o n c e p t o f O p e r a t i o n

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s S / W

r e q u i r e m e n t s R e q u i r e m e n t

v a l i d a t i o n D e s i g n V & V

P r o d u c t d e s i g n D e t a i l e d

d e s i g n C o d e

U n i t t e s t I n t e g r a t i o n

t e s t A c c e p t a n c e t e s t S e r v i c e

I n t e g r a t i o n a n d t e s t p l a n

D e v e l o p m e n t p l a n

R e q u i r e m e n t s p l a n L i f e - c y c l e p l a n

R E V I E W

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

O Modelo Espiral (com 4 regiões)

53

O Modelo Espiral (com 4 regiões)

R i s k a n a l y s i s

R i s k a n a l y s i s

R i s k a n a l y s i s

Risk anal ysis P r o t o -

t y p e 1 P r o t o t y p e 2

P r o t o t y p e 3 O p e r a - t i o n a l p r o t o y p e

C o n c e p t o f O p e r a t i o n

S i m u l a t i o n s , m o d e l s , b e n c h m a r k s S / W

r e q u i r e m e n t s R e q u i r e m e n t

v a l i d a t i o n D e s i g n V & V

P r o d u c t d e s i g n D e t a i l e d

d e s i g n C o d e

U n i t t e s t I n t e g r a t i o n

t e s t A c c e p t a n c e t e s t S e r v i c e

I n t e g r a t i o n a n d t e s t p l a n

D e v e l o p m e n t p l a n

R e q u i r e m e n t s p l a n L i f e - c y c l e p l a n

R E V I E W

DETERMINAR OBJETIVOS, ALTERNATIVAS E

RESTRIÇÕES

PLANEJAR PRÓXIMA FASE

AVALIAR ALTERNATIVAS IDENTIFICAR, RESOLVER RISCOS

DESENVOLVER, VERIFICAR O PRODUTO NO PRÓXIMO NÍVEL

COLOCAÇÃO DE OBJETIVOS

AVALIAÇÃO E REDUÇÃO DE

RISCOS

Ø  Cada “loop” do espiral é dividido em 4 setores

DESENVOLVIMENTO E VALIDAÇÃO

PLANEJAMENTO

54

O Modelo Espiral de Processo de Software

COLOCAÇÃO DE OBJETIVOS

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

55

O Modelo Espiral de Processo de Software

AVALIAÇÃO E REDUÇÃO DE

RISCOS

COLOCAÇÃO DE OBJETIVOS

para cada um dos riscos identificados, uma análise detalhada é executada. passos são tomados para reduzir o risco

56

O Modelo Espiral de Processo de Software

AVALIAÇÃO E REDUÇÃO DE

RISCOS COLOCAÇÃO DE

OBJETIVOS

depois da avaliação do risco, um modelo de desenvolvimento é escolhido para o sistema

DESENVOLVIMENTO E VALIDAÇÃO

57

O Modelo Espiral de Processo de Software

AVALIAÇÃO E REDUÇÃO DE

RISCOS COLOCAÇÃO DE

OBJETIVOS

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” )

58

O Modelo Espiral Ø  engloba as melhores características do ciclo

de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco

Ø  segue a abordagem de passos sistemáti-cos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real

Ø  usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos

59

Comentários sobre o Ciclo de Vida em 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

60

Comentários sobre o Ciclo de Vida em Espiral Ø  exige considerável experiência na

determinação de riscos e depende dessa experiência para ter sucesso

Ø  o modelo é relativamente novo e não tem sido amplamente usado. Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta

61

Planejamento Análise de Riscos

Engenharia

Construção e Liberação

Avaliação do Cliente

Comunicação com Cliente

O Modelo Espiral (com 6 regiões)

62

O Modelo Espiral Ø  adiciona 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

Ø  exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso

Ø  o modelo é relativamente novo e não tem sido amplamente usado.

63

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Modelo de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

64

O Modelo de Montagem de Componentes Ø  Utiliza tecnologias orientadas a objeto Ø  Quando projetadas e implementadas

apropriadamente as classes orientadas a objeto são reutilizáveis em diferentes aplicações e arquiteturas de sistema

Ø  O modelo de montagem de componentes incorpora muitas das características do modelo espiral.

65

O Modelo de Montagem de Componentes

Planejamento Análise de Riscos

Avaliação do Cliente

Comunicação com Cliente

Engenharia Construção e Liberação

66

O Modelo de Montagem de Componentes

Planejamento Análise de Riscos

Avaliação do Cliente

Comunicação com Cliente

Engenharia Construção e Liberação

identificar componentes

candidatas

procurar componentes na biblioteca

extrair componentes se disponíveis

construir os componentes

não disponíveis

colocar os novos

componentes na biblioteca

Construir a na iteração do

sistema

67

Ø  O modelo de montagem de componentes conduz ao reuso do software

Ø  a reusabilidade fornece uma série de benefícios: §  redução de 70% no tempo de desenvolvimento §  redução de 84% no custo do projeto §  índice de produtividade de 26.2 (normal da

indústria é de 16.9) Ø  esses resultados dependem da robustez da

biblioteca de componentes

O Modelo de Montagem de Componentes

68

Modelos de Processo de Software Ø  O Modelo Sequencial Linear

§  também chamado Modelo Cascata Ø  O Modelo de Prototipação Ø  O Modelo RAD (Rapid Application

Development) Ø  Modelos Evolutivos de Processo de Software

§  O Modelo Incremental §  O Modelo Espiral §  O Modelo de Montagem de Componentes §  O Modelo de Desenvolvimento Concorrente

Ø  Modelos de Métodos Formais Ø  Técnicas de Quarta Geração

69

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

70

Ferramentas do Ambiente das Técnicas de 4a Geração

Ø  O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4a geração inclui as ferramentas: §  linguagens não procedimentais para consulta de

banco de dados §  geração de relatórios § manipulação de dados §  interação e definição de telas §  geração de códigos §  capacidade gráfica de alto nível §  capacidade de planilhas eletrônicas

71

Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto” Implementação

usando 4GL Testes

72

Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto” Implementação

usando 4GL Testes

OBTENÇÃO DOS REQUISITOS:

•  o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional

•  o cliente pode estar inseguro quanto aos requisitos

•  o cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir

•  as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural"

73

Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto” Implementação

usando 4GL Testes

ESTRATÉGIA DO "PROJETO":

•  Para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma linguagem de quarta geração

•  Para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade)

74

Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto” Implementação

usando 4GL Testes

IMPLEMENTAÇÃO USANDO 4GL : Os resultados desejados são representados de modo que haja geração automática de código . Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL

75

Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto” Implementação

usando 4GL Testes TESTES:

O desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.

76

Comentários sobre as Técnicas de 4a 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

77

Para escolha de um Modelo de Processo de Software:

Ø  Natureza do projeto e da aplicação

Ø  Métodos e ferramentas a serem usados Ø  Controles e produtos que precisam ser

entregues