Modelos de Processo de Software

(1)

Modelos de Processo de Modelos de Processo de

Software Software

Profa. Ellen Francine ([email protected])

(2)

Processo de Software

Fases Genéricas

MANUTENÇÃO MANUTENÇÃO

Entendimento Modificação

Revalidação CONSTRUÇÃO

CONSTRUÇÃO

SOFTWARE PRODUTO SOFTWARE PRODUTO

Projeto Codificação

Teste DEFINIÇÃO

DEFINIÇÃO Análise de Sistema Planejamento do Projeto

Análise de Requisitos

• Gerenciamento de Configuração

• Acompanhamento e Controle do

Projeto

• Aplicação de Métricas

• Gerenciamento de Risco

• Gerenciamento de Reusabilidade

• Atividades de SQA

• Documentação

(3)

Modelos de Processo de Software Modelos de Processo de Software Modelos de Processo de Software Modelos de Processo de Software

Um Processo de Software com Qualidade

PROCESSO DE PROCESSO DE

SOFTWARE SOFTWARE

eficiente controlado

definido medido

gerenciado

(4)



Existem vários modelos de processo de software.

– Paradigmas de Engenharia de Software.Paradigmas de Engenharia de Software



Genéricos, abstrações do processo.

– Usados para explicar diferentes abordagens para o desenvolvimento de software.



Tentativa de colocar ordem em uma

atividade inerentemente caótica.

(5)

Tópicos da Aula

 Modelos de Processo de Software

– Cascata

– Prototipação

– RAD

– Evolutivos

 Incremental

Espiral

Componentes

– Métodos Formais

– Técnicas de Quarta Geração

– …

(6)

O Modelo Cascata



Modelo mais antigo e mais amplamente utilizado da Engenharia de Software.

– Paradigma do Ciclo de Vida Clássico.Paradigma do Ciclo de Vida Clássico

– Modelo Seqüencial Linear.Modelo Seqüencial Linear



Sugere uma abordagem sistemática seqüencial para o desenvolvimento de software.

– Tem início em nível de sistema e avança ao longo da análise, projeto, codificação, teste e

manutenção.

(7)

O Modelo Cascata



Modelado em função do ciclo convencional de engenharia.

–

O resultado de uma fase constitui-se na entrada de outra.

Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação Testes

Manutenção

(8)

O Modelo Cascata

Projeto

Manutenção

Engenharia de Sistemas Engenharia de Sistemas

– Estabelecimento de requisitos para todos os todos os elementos do sistema

elementos do sistema e atribuição de um

subconjunto desses requisitos para o software.

 Visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas, banco de dados, etc.).

– Coleta de requisitos em nível do sistemasistema, com uma pequena quantidade de projetoprojeto e análiseanálise de alto nível.

(9)

O Modelo Cascata

Projeto

Manutenção

Análise de Requisitos de Software Análise de Requisitos de Software

– O processo de coleta dos requisitos é

intensificado e concentrado especificamente no software.

– Para entender a natureza do programa a ser construído:

Deve-se compreender o domínio da informaçãodomínio da informação do

software, a funçãofunção, o desempenhodesempenho e a interfaceinterface exigidos.

– Os requisitos (do sistema e do software) são documentados

documentados e revistosrevistos com o cliente.

(10)

O Modelo Cascata

Projeto

Manutenção

Projeto Projeto

– Tradução dos requisitos do software para

um conjunto de representaçõesrepresentações que podem ser avaliadas quanto à qualidade, antes que a

codificação se inicie.

– Concentra-se em quatro atributos distintos do programa: estrutura de dados, arquitetura doestrutura de dados arquitetura do

software

software, representações da interfacerepresentações da interface e detalhes detalhes procedimentais

procedimentais.

– Assim como os requisitos, o projeto deve ser

documentado e torna-se parte da configuração de software.

(11)

O Modelo Cascata

Projeto

Manutenção

Codificação (Geração de Código) Codificação (Geração de Código)

– Tradução das representações do projeto para uma linguagem de programação, resultando em

instruções executáveis pelo computador.

 Se o projeto for executado detalhadamente, a codificação pode ser executada mecanicamente.

(12)

O Modelo Cascata

Projeto

Manutenção

Testes Testes

– Concentram-se nos aspectos lógicos internosaspectos lógicos internos do software, garantindo que todas as instruções

tenham sido testadas.

– Concentram-se nos aspectos funcionais externosaspectos funcionais externos a fim de descobrir erros e garantir que as entradas definidas produzam resultados reais que estejam em conformidade com os resultados esperados.

(13)

O Modelo Cascata



Modelado em função do ciclo convencional de engenharia.

–

O resultado de uma fase constitui-se na entrada de outra.

Projeto

Manutenção

Manutenção Manutenção

– Provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente.

– Causas das mudanças:

Erros.Erros

Adaptação do software para acomodaracomodar mudanças em seu ambiente externo.

Exigência do cliente para melhoramentosmelhoramentos funcionais e de desempenho.

– Reaplica cada uma das fases precedentes a um programa existente.

(14)

Modelo Cascata: Problemas

 Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe.

 Modificações podem causar confusão à medida que o projeto prossegue.

 É difícil para o cliente estabelecer explicitamente todos os requisitos logo no início do projeto.

 Dificuldade do modelo em acomodar a incerteza natural que existe no começo do projeto.

(15)

Modelo Cascata: Problemas

 O cliente deve ter paciência. Uma versão

executável do software só fica disponível em uma etapa avançada do desenvolvimento.

 Um erro grosseiro pode ser desastroso, se não for detectado até que o programa executável seja revisto.

Embora o

Embora o Modelo Cascata Modelo Cascata tenha tenha fragilidades, ele é

fragilidades, ele é

significativamente melhor do que significativamente melhor do que

uma abordagem casual ao uma abordagem casual ao desenvolvimento de software.

desenvolvimento de software.

Embora o

Embora o Modelo Cascata Modelo Cascata tenha tenha fragilidades, ele é

fragilidades, ele é

significativamente melhor do que significativamente melhor do que

uma abordagem casual ao uma abordagem casual ao desenvolvimento de software.

desenvolvimento de software.

(16)

O Modelo Cascata



Contribuições importantes do modelo ao Contribuições processo de desenvolvimento de software:

– Produz um padrãopadrão no qual os métodos para

análise, projeto, codificação, testes e manutenção podem ser situados.

– Impõe disciplinadisciplina, planejamentoplanejamento e gerenciamentogerenciamento.

– A implementação do produto deve ser postergadapostergada até que os objetivos tenham sido completamente entendidos.

(17)

O Modelo de Prototipação



Possibilita que o desenvolvedor crie um

modelo (protótipo protótipo) do software que deve ser construído.



O objetivo é entender os requisitos do requisitos do usuário

usuário e, assim, obter uma melhor definição dos requisitos do sistema.

– Apropriado para quando o cliente não definiu detalhadamente os requisitos.

(18)

O Modelo de Prototipação

Obter Requisitos Obter Requisitos

Elaborar Projeto Rápido Elaborar Projeto Rápido

Construir Protótipo Construir Protótipo Avaliar Protótipo

Avaliar Protótipo Refinar Protótipo

Refinar Protótipo

(19)

O Modelo de Prototipação

Obtenção dos Requisitos Obtenção dos Requisitos

–

Desenvolvedor e cliente:

 Definem os objetivos gerais do software.

Identificam quais requisitos são conhecidos.

Identificam as áreas que necessitam de definições adicionais.

(20)

O Modelo de Prototipação

Projeto Rápido Projeto Rápido

–

Representação dos aspectos do software que são visíveis ao usuário.

Abordagens de entrada.

Formatos de saída.

(21)

O Modelo de Prototipação

Construção do Protótipo Construção do Protótipo

–

Implementação rápida do protótipo.

(22)

O Modelo de Prototipação

Avaliação do Protótipo Avaliação do Protótipo

–

Cliente e desenvolvedor avaliam o

protótipo.

(23)

O Modelo de Prototipação

Refinamento do Protótipo Refinamento do Protótipo

–

Cliente e desenvolvedor refinam os

requisitos do software a ser desenvolvido.

(24)

O Modelo de Prototipação

Refinar Protótipo CONSTRUÇÃO

CONSTRUÇÃO DO PRODUTO DO PRODUTO

Construção do Produto Construção do Produto

–

Identificados os requisitos, o protótipo deve ser descartado descartado e a versão de produção deve ser construída considerando os critérios de critérios de

qualidade

qualidade.

(25)

Prototipação: Problemas



O cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento: não

– Qualidade global.

– Manutenibilidade a longo prazo.



O desenvolvedor freqüentemente faz uma implementação comprometida

implementação comprometida.

– Utilizando o que está disponível com o objetivo de produzir rapidamente um protótipo.

(26)

O Modelo de Prototipação



Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente.



Definir as regras do jogo logo no começo. Definir as regras do jogo logo no começo.

– O cliente e o desenvolvedor devem concordar que o protótipo será construído para servir como um mecanismo para definição dos requisitos

mecanismo para definição dos requisitos.

Deve ser descartadodescartado (ao menos em parte).

O software real é submetido à engenharia visando à qualidade

qualidade e à manutenibilidademanutenibilidade.

(27)

O Modelo RAD



RAD (Rapid Application Development)

é um modelo seqüencial linear que enfatiza um ciclo de desenvolvimento extremamente ciclo

curto curto.



Trata-se de uma adaptação de “alta

velocidade” do modelo seqüencial linear modelo seqüencial linear.

(28)

O Modelo RAD



A abordagem engloba as seguintes fases:

1.

Modelagem do Negócio

2.

Modelagem dos Dados

3.

Modelagem do Processo

4.

Geração da Aplicação

5.

Teste e Modificação

(29)

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

Teste e Modificação

Equipe #2 _Modelagem

do Negócio

Modelagem dos Dados

Modelagem do Processo

Teste e Modificação Equipe #3

60 a 90 dias

(30)

O Modelo RAD

1- Modelagem do Negócio



O fluxo de informação entre as funções de funções de negócio

negócio é modelado de modo que responda as seguintes questões:

– Que informação direciona o processo de negócio?

– Que informação é gerada?

– Quem a gera?

– Para onde vai a informação?

– Quem a processa?

(31)

O Modelo RAD

2- Modelagem dos Dados

 O fluxo de informação definido como parte da fase de modelagem dos negócios é refinado em um conjunto de objetos de dadosobjetos de dados necessários para apoiar os

negócios.

 As característicascaracterísticas (atributos) de cada objeto são

identificadas e o relacionamentorelacionamento entre esses objetos é definido.

(32)

O Modelo RAD



A abordagem RAD engloba as seguintes fases:

–

Modelagem do Negócio

–

Modelagem dos Dados

–

Modelagem do Processo

–

Geração da Aplicação

–

Teste e Modificação 3- Modelagem do Processo

 Os objetos de dados definidos na fase de modelagem dos dados são transformados para obter o fluxo de informação necessário para implementar uma função de negócio.

 As descrições de processamento são criadas

adicionando, modificando, excluindo ou recuperando objetos de dados.

(33)

O Modelo RAD

4- Geração da Aplicação

 RAD assume o uso de técnicas de 4ª geração

(ferramentas automatizadas para facilitar a construção do software).

– Delphi, Visual Basic, Asp.net, etc.

 O processo RAD trabalha para reutilizar componentes de programa existentes (quando possível) ou criar

componentes reutilizáveis.

(34)

O Modelo RAD

5- Teste e Modificação

 Como o processo RAD enfatiza a reutilização, muitos dos componentes do programa já foram testados.

– Isso reduz o tempo de teste global.

– Entretanto… os novos componentes devem ser testados e todas as interfaces devem ser exaustivamente exercitadas.

(35)

O Modelo RAD



Se uma aplicação de negócio puder ser modularizada

modularizada, de modo que possibilite que cada função principal seja completada em um curto prazo curto prazo (por ex: 30 a 90 dias), ela é candidata ao RAD.

– Cada função principal pode ser tratada por uma equipe RAD distinta e depois integrada para

formar o todo.

(36)

Modelo RAD: Problemas



Para projetos grandes (mas escaláveis), RAD exige recursos humanos suficientes para recursos humanos

criar um número adequado de equipes.



Exige que desenvolvedores e clientes estejam comprometidos com atividades atividades

continuamente rápidas

continuamente rápidas, necessárias para obter um sistema completo sistema completo em um período período

muito curto

muito curto.

(37)

Modelo RAD: Problemas



Nem todos os tipos de aplicação são apropriadas para o RAD.

–

Deve ser possível a modularização efetiva modularização efetiva da aplicação . .

 Se o sistema não puder ser adequadamente modularizado, a construção dos componentes será problemática.

(38)

Modelo RAD: Problemas



Quando riscos técnicos riscos técnicos forem

elevados, o RAD não é adequado.

–

A nova aplicação faz uso intenso de novas novas tecnologias

tecnologias . .

–

O novo software exige um alto grau de interoperabilidade

interoperabilidade com programas

existentes.

(39)

Modelos Evolucionários (Evolutivos)



Existem situações em que a

engenharia de software necessita de um modelo de processo que possa

acomodar um produto que evolui com o evolui com o tempo

tempo.

(40)

Modelos Evolucionários (Evolutivos)



Requisitos de produto produto e de negócio negócio mudam conforme o desenvolvimento prossegue.



Requisitos básicos são bem conhecidos, mas os detalhes detalhes ainda devem ser definidos.



Prazos reduzidos de mercado tornam Prazos reduzidos impossível a conclusão de um produto completo.

– Uma versão reduzidaversão reduzida pode ser elaborada face à competitividade ou às pressões do negócio.

(41)



Modelo Cascata: desenvolvimento retilíneo. Modelo Cascata

– O sistema completo estará pronto depois que a seqüência linear for concluída.



Prototipação: entendimento dos requisitos. Prototipação

– Em geral, não é projetado para ajudar um sistema em produção.

Modelos Evolucionários (Evolutivos)

A natureza evolutiva do software A natureza evolutiva do software

não é considerada.

A natureza evolutiva do software A natureza evolutiva do software

não é considerada.

(42)



Modelos evolutivos são iterativos iterativos.

–

Possibilitam o desenvolvimento de versões versões cada vez mais completas do software.

Modelo Incremental

Modelo Espiral

Modelo de Desenvolvimento Concorrente

Modelos Evolucionários

(Evolutivos)

(43)

O Modelo Incremental



O Modelo Incremental combina:

–

Elementos do Modelo Cascata (aplicado repetidamente).

–

A filosofia iterativa da Prototipação.

(44)

O Modelo Incremental



Objetivo: trabalhar junto ao cliente para descobrir seus requisitos, de maneira

incremental, até que o produto final seja obtido.

–

A evolução acontece quando novas

características são adicionadas adicionadas à medida que

são sugeridas pelo cliente.

(45)

O Modelo Incremental



Clientes identificam, em um esboço, as funções a serem fornecidas pelo

sistema.

–

Funções mais mais e menos menos importantes.



Definem-se estágios de entrega estágios de entrega.

–

Cada estágio fornece um subconjunto subconjunto das funcionalidades do sistema.

Incremento.Incremento

(46)

O Modelo Incremental



Os incrementos incrementos são elaborados utilizando-se o processo de

desenvolvimento mais apropriado.



Incrementos concluídos são entregues entregues

ao cliente e colocados em operação operação.

(47)

Versões Idiárias Versões IdiáriasVersões Intermediárias

O Modelo Incremental

Versão Inicial Versão

Inicial

Versões Intermediárias

Versão Final Versão Final Descrição

geral Descrição

geral

Engenh aria de Sistema s

Análise de Requisit

os Análise

de Requisit

os

Projeto Projeto

Codifica ção Codifica

ção

Testes Testes

(48)

O Modelo Incremental



A versão inicial é frequentemente o núcleo núcleo do produto (a parte mais importante).



A funcionalidade do sistema melhora melhora a cada novo estágio que é entregue.

– Os incrementos são versões simplificadasversões simplificadas do produto final.

 Oferecem capacidadescapacidades que servem ao usuário.

Constituem uma plataforma para avaliaçãoavaliação.

(49)

O Modelo Incremental



Importante quando é difícil estabelecer a priori uma especificação detalhada especificação detalhada dos requisitos.



Útil quando não há mão-de-obra mão-de-obra disponível disponível para uma implementação completa, dentro do prazo de entrega estabelecido.



Os incrementos podem ser planejados de modo que os riscos técnicos riscos técnicos possam ser

gerenciados

gerenciados.

(50)

Modelo Incremental: Problemas



Incrementos devem ser relativamente pequenos

pequenos e produzir alguma funcionalidade

funcionalidade para o sistema.

–

Difícil mapear os requisitos do cliente

dentro de incrementos de tamanho correto.



Difícil identificar facilidades comuns facilidades comuns,

exigidas por todos os incrementos.

(51)

Programação Extrema (eXtreme Programming)



Evolução da abordagem incremental. Evolução

(Kent Beck, 1999)

–

Voltada para equipes de até 20 pessoas, engajadas no desenvolvimento de

software cujos requisitos são vagos vagos ou se

encontram em constante mudança constante mudança.

(52)

Programação Extrema (eXtreme Programming)

– Desenvolvimento e entrega de incrementosincrementos de funcionalidade muito pequenos.

– Envolvimento do cliente no processo.Envolvimento

– Constante melhoriamelhoria de código.

– Programação em paresem pares.

– 40 horas de trabalho.

– Refactoring Refactoring

 Abordagem disciplinada para tornar o código de um

software mais claro e de fácil manutenção, minimizando a probabilidade de inclusão de erros.

– Test firstTest first, code latercode later.

(53)

O Modelo Espiral



O Modelo Espiral combina:

– A natureza iterativaiterativa da Prototipação.

– Os aspectos controladoscontrolados e sistemáticossistemáticos do Modelo Cascata.



Fornece potencial para o desenvolvimento rápido de versões incrementais versões incrementais do software.



Dividido em um certo número de atividades ou regiões de tarefa regiões de tarefa.

– Existem, tipicamente, de 3 a 6 regiões de tarefa.

(54)

O Modelo Espiral

Revisão

Determinar objetivos, alternativas e

restrições

Planejar próxima fase

Avaliar alternativas Identificar, resolver riscos

Desenvolver, verificar produto no

próximo nível

Plano de requisitos Plano de ciclo de vida

Plano de desenvolvimento

Integração e plano de teste

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

Protótipo Operacional

Simulação, modelos, benchmarks Conceito de

operação

Validação de requisito

Requisitos de SW

Projeto V & V

Projeto

do produto Projeto detalhado Código Teste de

unidade Teste de

integração Teste de

aceitação Operação

Cada

Cada looploop na espiral na espiral representa uma

representa uma fasefase do do processo de software.

processo de software.

(55)

O Modelo Espiral

Revisão Plano de requisitos Plano de ciclo de vida

Análise

de risco Protó tipo 1

Conceito de operação

O O looploop mais interno está mais interno está relacionado à

relacionado à viabilidadeviabilidade do sistema.

do sistema.

(56)

O Modelo Espiral

Análise de risco

Protótipo 2

Simulação, modelos, benchmarks

Requisitos de SW

O próximo

O próximo looploop está está concentrado na definição concentrado na definição

dos dos requisitosrequisitos do do sistema.

sistema.

(57)

O Modelo Espiral

Análise de risco

Protótipo 3

Projeto V & V

Projeto do produto

O O looploop seguinte está seguinte está concentrado no

concentrado no projetoprojeto do sistema.

do sistema.

(58)

O Modelo Espiral

^Análise

de risco

Projeto detalhado Código Teste de

unidade Teste de

O O looploop ainda mais ainda mais externo está externo está concentrado na concentrado na construção

construção do sistema.do sistema.

(59)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

Definição dos Definição dos

Objetivos Objetivos

Objetivos

Objetivos Avaliação e Avaliação e

Redução de Riscos Redução de Riscos

Avaliação e Avaliação e

Planejamento Planejamento Planejamento

Planejamento Desenvolvimento e Desenvolvimento e Validação

Validação

Desenvolvimento e Desenvolvimento e

Validação Validação

(60)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

Objetivos Objetivos

– São definidos os objetivos específicosobjetivos específicos para cada fase do projeto.

– São identificadas restriçõesrestrições sobre o processo e o produto.

– É projetado um plano de gerenciamentoplano de gerenciamento detalhado.

– São identificados os riscos do projetoriscos do projeto e planejadas estratégias alternativas

estratégias alternativas.

(61)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

– É realizada uma análise detalhadaanálise detalhada para cada um dos riscos identificados.

– São tomadas providênciasprovidências para reduzir os riscos.

(62)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

– Depois da avaliação dos riscos, é escolhido um modelo de modelo de

desenvolvimento

desenvolvimento para o sistema.

(63)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

Planejamento Planejamento Planejamento Planejamento

– O projeto é revistorevisto e é tomada uma decisão sobre continuar com o próximo loop.

– Se a decisão for continuar, são traçados os planos

planos para a próxima fase do projeto.

(64)

O Modelo Espiral

Revisão

restrições

próximo nível

Análise de risco

Protó tipo 1

Protótipo 2

Protótipo 3

operação

Requisitos de SW

Projeto V & V

Projeto

unidade Teste de

–

Não existem fases fixas fases fixas no modelo.

–

A gerência gerência decide como

estruturar o projeto em fases.

(65)

O Modelo Espiral



Engloba as melhores características do Modelo Cascata e da Prototipação,

adicionando um novo elemento: a Análise de Análise de Riscos

Riscos.

– Risco: algo que pode dar errado.Risco

– Segue a abordagem de passos sistemáticos do Modelo Cascata, incorporando-os numa estrutura estrutura iterativa

iterativa.

– Usa a Prototipação em qualquer etapa da evolução do produto, como mecanismo de reduçãoredução de

riscos.

(66)

Modelo Espiral



É, atualmente, a abordagem mais realística para o desenvolvimento de sistemas e

software de grande porte grande porte.



Exige a consideração direta dos riscos riscos técnicos

técnicos em todos os estágios do projeto.

– Se aplicado adequadamente, pode reduzir os riscos antes que os mesmos fiquem

problemáticos.

(67)

Modelo Espiral: Problemas



Pode ser difícil convencer convencer os clientes que uma abordagem evolutiva é controlável.



Exige considerável experiência experiência na

determinação de riscos e depende dessa

experiência para ter sucesso.

(68)

O Modelo de Montagem de Componentes

 Incorpora características de tecnologias tecnologias orientadas a objeto

orientadas a objeto no Modelo EspiralModelo Espiral.

 É de natureza evolutiva demandando uma

abordagem iterativa para a criação do software.

 O modelo compõe aplicações a partir de componentes de software “empacotados”.

– Quando projetadas e implementadas apropriadamente, as classes são reutilizáveisreutilizáveis em diferentes aplicações e arquiteturas de sistema.

(69)

O Modelo de Montagem de Componentes

Planejamento

Análise de Riscos

Engenharia,

Construção e Liberação Avaliação do Cliente

Comunicação com Cliente

Planejamento

Avaliação do Cliente Comunicação

com Cliente

Identificar componentes

candidatos Procurar

componentes na biblioteca

Extrair

componentes, se disponíveis

Construir os componentes não disponíveis

Colocar os novos

componentes na biblioteca

Construir a n^a iteração do

sistema

(70)

O Modelo de Montagem de Componentes



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



A reusabilidade pode fornecer uma série de benefícios:

– Redução no tempo de desenvolvimento.

– Redução no custo do projeto.

– Aumento no índice de produtividade.

 Tais benefícios dependem da robustez da bibliotecarobustez da biblioteca de componentes.

(71)

O Modelo de Métodos Formais

 Especificar, desenvolver e verificar um sistema pela aplicação de uma rigorosa notação matemáticarigorosa notação matemática.

– Abrange um conjunto de atividades que levam à especificação especificação matemática formal

matemática formal do software.

– Tem como base a transformação matemática formaltransformação matemática formal de uma especificação de sistema em um programa executável.

(72)

O Modelo de Métodos Formais

(73)

O Modelo de Métodos Formais



No projeto...

–

Base para a verificação do programa verificação do programa, permitindo que se descubram erros que poderiam passar despercebidos.



No desenvolvimento...

–

Ambigüidade, não completitude Ambigüidade não completitude e inconsistência

inconsistência podem ser mais facilmente

descobertas pela análise matemática.

(74)

O Modelo de Métodos Formais



Abordagem particularmente adequada ao desenvolvimento de sistemas com rigorosas exigências de segurança segurança , confiabilidade confiabilidade e

garantia garantia.

– Eletrônica de aeronaves.

– Controle de tráfego aéreo.

– Dispositivos médicos.

– Telecomunicações.

(75)

Modelo de Métodos Formais:

Problemas



Preocupações quanto à aplicabilidade em ambientes comerciais:

– O desenvolvimento é lentolento e dispendiosodispendioso.

– Requer treinamento extensivotreinamento extensivo.

– Difícil utilizar os modelos como um mecanismo de comunicação

comunicação.

Clientes despreparados tecnicamente.

(76)

Cleanroom (Sala Limpa)



Exemplo mais conhecido do processo de Exemplo desenvolvimento formal.

– Desenvolvimento incrementalincremental do software.

– Cada estágio é desenvolvido e sua correção é demonstrada utilizando-se uma abordagem abordagem formal

formal.

– O teste de sistema visa a medir a confiabilidadeconfiabilidade do sistema.

Conduzido como um experimento estatístico.

(77)

Técnicas de Quarta Geração



Engloba um conjunto de ferramentas de software possibilitando que:

–

O sistema seja especificado em uma linguagem de alto nível

linguagem de alto nível.

–

O código-fonte seja gerado automaticamente

automaticamente a partir dessas

especificações.

(78)

Técnicas de Quarta Geração



Ferramentas de Apoio

– Linguagens não-procedimentais para:

Consulta de banco de dados (SQL).

Geração de relatórios (PostScript).

Manipulação de dados (XML).

Interação e definição de telas (Delphi, Visual Basic).

 Geração de código.

– Capacidade gráfica de alto nível.

– Capacidade de disposição em planilhas.

– Geração automática de HTML e linguagens similares para criação de páginas Web.

(79)

Técnicas de Quarta Geração

Obtenção dos Requisitos

Estratégia de

“Projeto”

Implementação usando 4GL

Testes

(80)

Técnicas de Quarta Geração

Estratégia de

“Projeto”

Testes

Obtenção dos Requisitos Obtenção dos Requisitos

– O cliente descreve os requisitos os quais são traduzidos para um protótipo operacionalprotó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 ser utilizada.

As 4GLs atuais não são suficientemente sofisticadas para acomodar a verdadeira linguagem natural.

(81)

Estratégia de

“Projeto”

Testes

Técnicas de Quarta Geração

Estratégia de “Projeto” Estratégia de “Projeto”

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

– Grandes Projetos

É necessário desenvolver uma estratégia de projetoestratégia de projeto.

De outro modo ocorrerão os mesmos problemas

encontrados quando se usa abordagem convencional (baixa qualidade).

(82)

Estratégia de

“Projeto”

Testes

Técnicas de Quarta Geração

Implementação usando 4GL 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.

(83)

Estratégia de

“Projeto”

Testes

Técnicas de Quarta Geração

Testes Testes

– O desenvolvedor deve efetuar testes e desenvolver uma documentaçãodocumentação significativa.

– O software desenvolvido deve ser construído de maneira que a manutençãomanutenção possa ser efetuada prontamente.

(84)

Técnicas de Quarta Geração



Proponentes

– Redução dramática no tempotempo de desenvolvimento do software.

Aumento de produtividadeprodutividade.



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 manutenibilidademanutenibilidade de sistemas usando técnicas 4GT ainda é questionável.

(85)

Metodologias Ágeis



SCRUM SCRUM



Crystal/Clear



FDD (Feature Driven Development) FDD

– Desenvolvimento Orientado a Funcionalidades



DSDM (Dynamic Systems Development DSDM Method)

– Método Dinâmico de Desenvolvimento de Sistemas



ASD (Adaptive Software Development) ASD

– Desenvolvimento Adaptável de Software

(86)

Metodologias Ágeis



XP (eXtreme Programming) XP



Pragmatic Programming Pragmatic Programming



Open Source Software Development Open Source Software Development



RUP (Rational Unified Process) RUP

(87)

Concluindo...

 Cascata, Prototipação, Evolutivos, Formais, Ágeis, ...

 Para escolha de um modelo de processo de softwaremodelo 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.

 Não são mutuamente exclusivos e freqüentemente são usados em conjunto.