SlideShare uma empresa Scribd logo
1 de 30
Análise de Sistemas
1º Módulo
CRISE DO SOFTWARE NAS
DÉCADAS DE 60,70,80.
Pode-se dizer que essa crise é de:
 Tecnologia: o hardware caminha mais rápido que o
software;
 Oferta: a demanda é maior que a capacidade de
desenvolvimento;
 Manutenção: maus projetos e recursos escassos não
permitem manutenção.
Apesar dos investimentos feitos nestes 30 anos, o
desenvolvimento de software tem sido, em muitos casos, o
gargalo para o término do desenvolvimento de sistemas.
DADOS LEVANTADOS EM 1987
 25% de projetos de software de grande porte para tempo
real e para telecomunicações nunca foram terminados;
 uma porcentagem semelhante de sistemas deste tipo
tiveram o desenvolvimento terminados mas não se tornou
operacional;
 cerca de 10% de projetos iniciados em empresas de
informática são descontinuados;
 40% dos 260 projetos de software aplicativos na área de
manufatura aeroespacial não vão ser terminados.
 O insucesso no desenvolvimento de software se
deve a vários motivos e, normalmente, tem uma
probabilidade maior de ocorrência em sistemas de
grande porte. Muitas vezes, problemas surgem de
uma especificação mal feita ou incompleta, onde os
projetista acabam assumindo as interpretações ou os
pontos faltantes.
 Outras vezes, o insucesso é devido à mudança de
objetivos, quando o produto final não atende mais às
propostas iniciais [Melnikoff, 1998].
O processo de desenvolvimento
de um software
As atividades de desenvolvimento de software
passaram por uma transformação profunda: no
início da década dos 60, o objetivo fundamental era a
programação, sem considerar os aspectos de
análise, projeto e testes. Por outro lado, a disciplina
de engenharia de software de hoje focaliza não um
programador, mas uma equipe de profissionais, com
papéis bem definidos, almejando a obtenção de um
sistema integrado de software.
Os modelos de processo de
desenvolvimento têm um papel muito
importante no contexto, pois nos permite:
 Definir as atividades a serem executadas em um
projeto de software;
 Introduzir consistência entre os muitos projetos da
mesma organização;
 Introduzir pontos de verificação para o controle
gerencial.
Os modelos de processo de desenvolvimento ou
métodos da engenharia de software, também
conhecidos como “paradigmas da engenharia de
software”, são:
 O Ciclo de Vida Clássico;
 Prototipação;
 Modelo Espiral;
 Técnicas de quarta geração.
CICLO DE VIDA CLÁSSICO
 Análise do Sistema: Estabelecer necessidades e exigências de todos os
elementos do sistema (software, hardware e procedimentos manuais).
 Análise de Requisitos (do Software): Detalhar os dados que serão
manipulados e as funções que serão executadas pelo software.
 Projeto: Transformar os requisitos do software nos seus principais
componentes: estrutura e algoritmo do código; estrutura de dados e
interfaces com usuários e outros sistemas.
 Codificação:
Traduzir o desenho do software em programas que possam ser
executados por computador.
 Teste: Identificar erros de codificação, desenho ou
análise, “eventualmente” existentes no software.
 Manutenção: Repetir as fases anteriores para corrigir erros do
software, adaptar suas funções a novos requisitos e ampliá-
lo, adicionando-se novas funções.
Problemas na aplicação do modelo de ciclo
de vida clássico
Este paradigma é o mais antigo e o mais utilizado, pois ele é melhor do que
uma abordagem casual ao desenvolvimento de software, mas existem
problemas aos quais devemos estar atentos, para saber contornar:
 Os projetos reais raramente seguem o fluxo seqüencial que o modelo
propõe. Alguma interação sempre ocorre e traz problemas na aplicação do
paradigma;
 Para o cliente é difícil em um primeiro momento declarar todas as
exigências explicitamente. O ciclo de vida clássico exige isso e tem
dificuldade de como dar a incerteza que existe no começo do projeto;
 Cliente deve ter paciência. Uma versão do programa não estará
disponível até um ponto tardio do cronograma projetado. Um erro, se
não for detectado até que o programa de trabalho seja revisto, poderá
ser desastroso.
Prototipação
A prototipação é um processo que capacita o
desenvolvedor a criar um modelo de software, podendo
ser: em papel, baseado em um PC, um protótipo de
trabalho, um programa existente que executa uma parte
ou toda função desejada (mas que ainda necessita de
ajustes em um novo esforço de desenvolvimento).
Uma abordagem de prototipação pode representar a
melhor abordagem, quando:
 O cliente definiu um conjunto de objetivos gerais
para o software, mas não identificou requisitos de
entrada, processamento e saída detalhados;
 O desenvolvedor não tem certeza da eficiência de
um algoritmo, da adaptabilidade de um sistema
operacional ou da forma de interação homem-
máquina.
Prototipação
Prototipação
A prototipação é um paradigma eficiente. A
chave está entre a
concordância do cliente e desenvolvedor, de
que o protótipo serve apenas para
definir os requisitos.
Problemas na aplicação do
modelo de Prototipação:
 Cliente vê aquilo que parece ser uma versão de
trabalho do software, desconhecendo que o protótipo é
na verdade uma versão “rústica” do sistema, feita sem
considerar aspectos de qualidade e facilidade de
manutenção do software.
 Quando o cliente descobre que o que esta vendo é na
realidade um modelo e este precisa ser
reconstruído, este exige que sejam feitos “alguns
acertos” de forma que o protótipo se torne viável para
uso. O que é sem dúvida uma catástrofe.
O MODELO ESPIRAL
Este modelo foi desenvolvido com a finalidade
de abranger as melhores características tanto
do ciclo de vida clássico como da
prototipação, acrescentando a análise de
riscos, que falta nos outros paradigmas.
O modelo espiral define quatro importantes
atividades, a saber:
 Planejamento: determinação dos
objetivos, alternativas e restrições;
 Análise de Riscos: análise de alternativas e resolução
de riscos;
 Engenharia: desenvolvimento do produto no nível
seguinte;
 Avaliação feita pelo cliente: avaliação dos resultados
da engenharia.
 É a abordagem mais realista para o desenvolvimento de
sistemas e software de grande escala existente
atualmente. Usando a abordagem evolucionária
capacita o desenvolvedor e o cliente a reagir aos riscos
de cada etapa evolutiva.
 Uma outra característica importante é que ela permite
ao desenvolvedor aplicar a abordagem de prototipação
em qualquer etapa da evolução do produto. Mantém a
abordagem de passos sistemáticos do ciclo de vida
clássico, incorporando-o numa estrutura iterativa que
reflete mais realisticamente o mundo real.
O MODELO ESPIRAL
Problemas na aplicação do modelo
de espiral:
 Convencer grandes clientes de que a abordagem
evolutiva é controlável;
 Exige considerável experiência do engenheiro de
software em detectar e avaliar riscos . O sucesso
depende disso.
 Pelo fato do modelo ser relativamente novo e ainda
não ter sido amplamente usado como os dois modelos
anteriores, demorará ainda alguns anos até que sua
eficácia possa ser determinada com certeza .
TÉCNICAS DE QUARTA GERAÇÃO
O modelo denominado de Técnicas de Quarta Geração
ou 4GT, abrange um amplo conjunto de software que
permitem ao desenvolvedor especificar alguma
característica do software num nível elevado.
Este paradigma concentra-se na capacidade de se
especificar um software a uma máquina em um nível que
esteja próximo da linguagem natural.
Atualmente o ambiente de desenvolvimento de software
baseado no paradigma 4GT inclui alguma, ou todas, as
seguintes ferramentas:
Quarta Geração
 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ódigo de programas;
 Capacidade gráfica de alto nível;
 Capacidade de planilha eletrônica.
Quarta Geração
Obtenção de Requisitos
 Descrição dos requisitos pelo cliente, que são
traduzidos para um protótipo operacional.
- Insegurança quanto aos requisitos
- Incapacidade de especificação de
informações.
- 4GL’s não são sofisticadas a ponto de
acomodar a
- verdadeira linguagem Natural
Estratégia de Projeto
Dois casos de desenvolvimento:
1. Pequenas aplicações: é possível
pular esta etapa.
2. Grandes aplicações: necessária
estratégia do projeto.
Implementação utilizando a 4GL
Resultados desejados representados
por geração automática de código.
Estrutura de dados com informações
relevantes e acessível pela 4GL.
Testes
Realizar testes.
Possuir documentação significativa.
Manutenção deve ser efetuada
prontamente.
Problemas na aplicação do modelo
de técnicas de quarta geração
Alguns problemas do modelo 4GT são:
 Usar modelos baseados em 4GT sem planejamento para
grandes projetos, é incorrer nas mesmas dificuldades
encontradas para se desenvolver software usando
abordagens convencionais;
 O software desenvolvido em 4GT deve ser construído de
modo que possibilite rápida manutenção;
 Com raras exceções, o domínio atual para 4GT limita-se a
aplicações comerciais. Somente agora ferramentas CASE
estão suportando o uso das 4GT para geração automática
de “esqueletos” de código para aplicações de engenharia e
tempo real.
Evolução do Software
 Primeira Geração (1950 a 1960): Sistemas em Batch, software sob medida,
desenvolvidos sem técnicas de engenharia (programação arte); programador-
usuário (sistemas sem documentação) - muita evolução da ciência pouca da técnica;
 Segunda Geração(1960-1979): Sistemas Multiusuário (interação homem-
máquina); evolução de técnicas interativas: sistemas em tempo real ; sistemas de
gerenciamento de banco de dados; surgimento das Software-Houses e dos pacotes
de software: evolução de técnicas de manutenção;
 Terceira Geração: (desde 1979): Sistemas distribuídos: redes locais e globais;
comunicações digitais ; acesso instantâneo a base de dados; Sistemas Especialistas;
Inteligência Artificial; integração da informática com outras tecnologias
(automóveis, eletrodomésticos, bens de capital,....). Crescimento de empresas de
software, que vendem diferenciação...
 Quarta Geração: Inteligência Artificial: disseminação de sistemas baseados em
redes neuronais e algoritmos genéticos para reconhecimento de padrões,
aprendizado e processamento parecidos com os humanos: Orientação a Objetos e
Linguagens de quarta geração (especificando o resultado esperado e não a ação para
se conseguir esse resultado).
A metodologia de desenvolvimento deve ser
estabelecida levando-se em consideração o porte do
sistema, as suas características (tempo real ou
não, centralizado ou distribuído, tipo de
aplicação, etc.), o tamanho e o perfil da equipe de
desenvolvimento, a infra estrutura de apoio ao
processo de desenvolvimento, entre os principais
fatores. A não observação da adequabilidade de uma
metodologia a um desenvolvimento pode causar
mais transtornos do que as vantagens prometidas
pela literatura, causando descrédito nos
projetistas, nos gerentes e nos clientes.
Questionário
1. Defina Engenharia de Software, com suas palavras e
comente sua importância no atual cenário de
desenvolvimento de Software.
2. Comente a imagem do Slide 5
3. Na sua opinião, por que é importante estudar
engenharia de software.

Mais conteúdo relacionado

Mais procurados

Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 

Mais procurados (20)

Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Introdução a engenharia de software aula 01
Introdução a engenharia de software   aula 01Introdução a engenharia de software   aula 01
Introdução a engenharia de software aula 01
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Gerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptxGerenciamento da Qualidade de Software 1.pptx
Gerenciamento da Qualidade de Software 1.pptx
 
Capitulo 02 sommerville
Capitulo 02 sommervilleCapitulo 02 sommerville
Capitulo 02 sommerville
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Mitos do Desenvolvimento de Software
Mitos do Desenvolvimento de SoftwareMitos do Desenvolvimento de Software
Mitos do Desenvolvimento de Software
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
 
Gerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptxGerenciamento da Qualidade de Software 5.pptx
Gerenciamento da Qualidade de Software 5.pptx
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Modelos de ciclo de vida de software
Modelos de ciclo de vida de softwareModelos de ciclo de vida de software
Modelos de ciclo de vida de software
 
Cap1 introd-engenharia de software
Cap1 introd-engenharia de softwareCap1 introd-engenharia de software
Cap1 introd-engenharia de software
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Engenharia de Software Pressman
Engenharia de Software PressmanEngenharia de Software Pressman
Engenharia de Software Pressman
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
Artigo - OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE D...
 

Semelhante a Analise aula2

T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
wilsonguns
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
Erivelton Silva Rocha
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
Robson Silva Espig
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de software
luacal
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
Tiago Vizoto
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
erysonsi
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
erysonsi
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
erysonsi
 

Semelhante a Analise aula2 (20)

T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Es2 modelo de processo de software
Es2 modelo de processo de softwareEs2 modelo de processo de software
Es2 modelo de processo de software
 
Ciclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de SoftwareCiclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de Software
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
Crise de software2
Crise de software2Crise de software2
Crise de software2
 
Aula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdfAula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdf
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
RAD
RADRAD
RAD
 
modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Projeto de Sistemas - Aula002
Projeto de Sistemas - Aula002Projeto de Sistemas - Aula002
Projeto de Sistemas - Aula002
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
 

Analise aula2

  • 2. CRISE DO SOFTWARE NAS DÉCADAS DE 60,70,80. Pode-se dizer que essa crise é de:  Tecnologia: o hardware caminha mais rápido que o software;  Oferta: a demanda é maior que a capacidade de desenvolvimento;  Manutenção: maus projetos e recursos escassos não permitem manutenção. Apesar dos investimentos feitos nestes 30 anos, o desenvolvimento de software tem sido, em muitos casos, o gargalo para o término do desenvolvimento de sistemas.
  • 3. DADOS LEVANTADOS EM 1987  25% de projetos de software de grande porte para tempo real e para telecomunicações nunca foram terminados;  uma porcentagem semelhante de sistemas deste tipo tiveram o desenvolvimento terminados mas não se tornou operacional;  cerca de 10% de projetos iniciados em empresas de informática são descontinuados;  40% dos 260 projetos de software aplicativos na área de manufatura aeroespacial não vão ser terminados.
  • 4.  O insucesso no desenvolvimento de software se deve a vários motivos e, normalmente, tem uma probabilidade maior de ocorrência em sistemas de grande porte. Muitas vezes, problemas surgem de uma especificação mal feita ou incompleta, onde os projetista acabam assumindo as interpretações ou os pontos faltantes.  Outras vezes, o insucesso é devido à mudança de objetivos, quando o produto final não atende mais às propostas iniciais [Melnikoff, 1998].
  • 5.
  • 6. O processo de desenvolvimento de um software As atividades de desenvolvimento de software passaram por uma transformação profunda: no início da década dos 60, o objetivo fundamental era a programação, sem considerar os aspectos de análise, projeto e testes. Por outro lado, a disciplina de engenharia de software de hoje focaliza não um programador, mas uma equipe de profissionais, com papéis bem definidos, almejando a obtenção de um sistema integrado de software.
  • 7. Os modelos de processo de desenvolvimento têm um papel muito importante no contexto, pois nos permite:  Definir as atividades a serem executadas em um projeto de software;  Introduzir consistência entre os muitos projetos da mesma organização;  Introduzir pontos de verificação para o controle gerencial.
  • 8. Os modelos de processo de desenvolvimento ou métodos da engenharia de software, também conhecidos como “paradigmas da engenharia de software”, são:  O Ciclo de Vida Clássico;  Prototipação;  Modelo Espiral;  Técnicas de quarta geração.
  • 9. CICLO DE VIDA CLÁSSICO
  • 10.  Análise do Sistema: Estabelecer necessidades e exigências de todos os elementos do sistema (software, hardware e procedimentos manuais).  Análise de Requisitos (do Software): Detalhar os dados que serão manipulados e as funções que serão executadas pelo software.  Projeto: Transformar os requisitos do software nos seus principais componentes: estrutura e algoritmo do código; estrutura de dados e interfaces com usuários e outros sistemas.  Codificação: Traduzir o desenho do software em programas que possam ser executados por computador.  Teste: Identificar erros de codificação, desenho ou análise, “eventualmente” existentes no software.  Manutenção: Repetir as fases anteriores para corrigir erros do software, adaptar suas funções a novos requisitos e ampliá- lo, adicionando-se novas funções.
  • 11. Problemas na aplicação do modelo de ciclo de vida clássico Este paradigma é o mais antigo e o mais utilizado, pois ele é melhor do que uma abordagem casual ao desenvolvimento de software, mas existem problemas aos quais devemos estar atentos, para saber contornar:  Os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. Alguma interação sempre ocorre e traz problemas na aplicação do paradigma;  Para o cliente é difícil em um primeiro momento declarar todas as exigências explicitamente. O ciclo de vida clássico exige isso e tem dificuldade de como dar a incerteza que existe no começo do projeto;  Cliente deve ter paciência. Uma versão do programa não estará disponível até um ponto tardio do cronograma projetado. Um erro, se não for detectado até que o programa de trabalho seja revisto, poderá ser desastroso.
  • 12. Prototipação A prototipação é um processo que capacita o desenvolvedor a criar um modelo de software, podendo ser: em papel, baseado em um PC, um protótipo de trabalho, um programa existente que executa uma parte ou toda função desejada (mas que ainda necessita de ajustes em um novo esforço de desenvolvimento). Uma abordagem de prototipação pode representar a melhor abordagem, quando:
  • 13.  O cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída detalhados;  O desenvolvedor não tem certeza da eficiência de um algoritmo, da adaptabilidade de um sistema operacional ou da forma de interação homem- máquina. Prototipação
  • 14. Prototipação A prototipação é um paradigma eficiente. A chave está entre a concordância do cliente e desenvolvedor, de que o protótipo serve apenas para definir os requisitos.
  • 15. Problemas na aplicação do modelo de Prototipação:  Cliente vê aquilo que parece ser uma versão de trabalho do software, desconhecendo que o protótipo é na verdade uma versão “rústica” do sistema, feita sem considerar aspectos de qualidade e facilidade de manutenção do software.  Quando o cliente descobre que o que esta vendo é na realidade um modelo e este precisa ser reconstruído, este exige que sejam feitos “alguns acertos” de forma que o protótipo se torne viável para uso. O que é sem dúvida uma catástrofe.
  • 16. O MODELO ESPIRAL Este modelo foi desenvolvido com a finalidade de abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando a análise de riscos, que falta nos outros paradigmas.
  • 17. O modelo espiral define quatro importantes atividades, a saber:  Planejamento: determinação dos objetivos, alternativas e restrições;  Análise de Riscos: análise de alternativas e resolução de riscos;  Engenharia: desenvolvimento do produto no nível seguinte;  Avaliação feita pelo cliente: avaliação dos resultados da engenharia.
  • 18.  É a abordagem mais realista para o desenvolvimento de sistemas e software de grande escala existente atualmente. Usando a abordagem evolucionária capacita o desenvolvedor e o cliente a reagir aos riscos de cada etapa evolutiva.  Uma outra característica importante é que ela permite ao desenvolvedor aplicar a abordagem de prototipação em qualquer etapa da evolução do produto. Mantém a abordagem de passos sistemáticos do ciclo de vida clássico, incorporando-o numa estrutura iterativa que reflete mais realisticamente o mundo real. O MODELO ESPIRAL
  • 19. Problemas na aplicação do modelo de espiral:  Convencer grandes clientes de que a abordagem evolutiva é controlável;  Exige considerável experiência do engenheiro de software em detectar e avaliar riscos . O sucesso depende disso.  Pelo fato do modelo ser relativamente novo e ainda não ter sido amplamente usado como os dois modelos anteriores, demorará ainda alguns anos até que sua eficácia possa ser determinada com certeza .
  • 20. TÉCNICAS DE QUARTA GERAÇÃO O modelo denominado de Técnicas de Quarta Geração ou 4GT, abrange um amplo conjunto de software que permitem ao desenvolvedor especificar alguma característica do software num nível elevado. Este paradigma concentra-se na capacidade de se especificar um software a uma máquina em um nível que esteja próximo da linguagem natural. Atualmente o ambiente de desenvolvimento de software baseado no paradigma 4GT inclui alguma, ou todas, as seguintes ferramentas:
  • 21. Quarta Geração  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ódigo de programas;  Capacidade gráfica de alto nível;  Capacidade de planilha eletrônica.
  • 23. Obtenção de Requisitos  Descrição dos requisitos pelo cliente, que são traduzidos para um protótipo operacional. - Insegurança quanto aos requisitos - Incapacidade de especificação de informações. - 4GL’s não são sofisticadas a ponto de acomodar a - verdadeira linguagem Natural
  • 24. Estratégia de Projeto Dois casos de desenvolvimento: 1. Pequenas aplicações: é possível pular esta etapa. 2. Grandes aplicações: necessária estratégia do projeto.
  • 25. Implementação utilizando a 4GL Resultados desejados representados por geração automática de código. Estrutura de dados com informações relevantes e acessível pela 4GL.
  • 26. Testes Realizar testes. Possuir documentação significativa. Manutenção deve ser efetuada prontamente.
  • 27. Problemas na aplicação do modelo de técnicas de quarta geração Alguns problemas do modelo 4GT são:  Usar modelos baseados em 4GT sem planejamento para grandes projetos, é incorrer nas mesmas dificuldades encontradas para se desenvolver software usando abordagens convencionais;  O software desenvolvido em 4GT deve ser construído de modo que possibilite rápida manutenção;  Com raras exceções, o domínio atual para 4GT limita-se a aplicações comerciais. Somente agora ferramentas CASE estão suportando o uso das 4GT para geração automática de “esqueletos” de código para aplicações de engenharia e tempo real.
  • 28. Evolução do Software  Primeira Geração (1950 a 1960): Sistemas em Batch, software sob medida, desenvolvidos sem técnicas de engenharia (programação arte); programador- usuário (sistemas sem documentação) - muita evolução da ciência pouca da técnica;  Segunda Geração(1960-1979): Sistemas Multiusuário (interação homem- máquina); evolução de técnicas interativas: sistemas em tempo real ; sistemas de gerenciamento de banco de dados; surgimento das Software-Houses e dos pacotes de software: evolução de técnicas de manutenção;  Terceira Geração: (desde 1979): Sistemas distribuídos: redes locais e globais; comunicações digitais ; acesso instantâneo a base de dados; Sistemas Especialistas; Inteligência Artificial; integração da informática com outras tecnologias (automóveis, eletrodomésticos, bens de capital,....). Crescimento de empresas de software, que vendem diferenciação...  Quarta Geração: Inteligência Artificial: disseminação de sistemas baseados em redes neuronais e algoritmos genéticos para reconhecimento de padrões, aprendizado e processamento parecidos com os humanos: Orientação a Objetos e Linguagens de quarta geração (especificando o resultado esperado e não a ação para se conseguir esse resultado).
  • 29. A metodologia de desenvolvimento deve ser estabelecida levando-se em consideração o porte do sistema, as suas características (tempo real ou não, centralizado ou distribuído, tipo de aplicação, etc.), o tamanho e o perfil da equipe de desenvolvimento, a infra estrutura de apoio ao processo de desenvolvimento, entre os principais fatores. A não observação da adequabilidade de uma metodologia a um desenvolvimento pode causar mais transtornos do que as vantagens prometidas pela literatura, causando descrédito nos projetistas, nos gerentes e nos clientes.
  • 30. Questionário 1. Defina Engenharia de Software, com suas palavras e comente sua importância no atual cenário de desenvolvimento de Software. 2. Comente a imagem do Slide 5 3. Na sua opinião, por que é importante estudar engenharia de software.