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...
DADOS LEVANTADOS EM 1987
 25% de projetos de software de grande porte para tempo
real e para telecomunicações nunca foram...
 O insucesso no desenvolvimento de software se
deve a vários motivos e, normalmente, tem uma
probabilidade maior de ocorr...
O processo de desenvolvimento
de um software
As atividades de desenvolvimento de software
passaram por uma transformação p...
Os modelos de processo de
desenvolvimento têm um papel muito
importante no contexto, pois nos permite:
 Definir as ativid...
Os modelos de processo de desenvolvimento ou
métodos da engenharia de software, também
conhecidos como “paradigmas da enge...
CICLO DE VIDA CLÁSSICO
 Análise do Sistema: Estabelecer necessidades e exigências de todos os
elementos do sistema (software, hardware e procedi...
Problemas na aplicação do modelo de ciclo
de vida clássico
Este paradigma é o mais antigo e o mais utilizado, pois ele é m...
Prototipação
A prototipação é um processo que capacita o
desenvolvedor a criar um modelo de software, podendo
ser: em pape...
 O cliente definiu um conjunto de objetivos gerais
para o software, mas não identificou requisitos de
entrada, processame...
Prototipação
A prototipação é um paradigma eficiente. A
chave está entre a
concordância do cliente e desenvolvedor, de
que...
Problemas na aplicação do
modelo de Prototipação:
 Cliente vê aquilo que parece ser uma versão de
trabalho do software, d...
O MODELO ESPIRAL
Este modelo foi desenvolvido com a finalidade
de abranger as melhores características tanto
do ciclo de v...
O modelo espiral define quatro importantes
atividades, a saber:
 Planejamento: determinação dos
objetivos, alternativas e...
 É a abordagem mais realista para o desenvolvimento de
sistemas e software de grande escala existente
atualmente. Usando ...
Problemas na aplicação do modelo
de espiral:
 Convencer grandes clientes de que a abordagem
evolutiva é controlável;
 Ex...
TÉCNICAS DE QUARTA GERAÇÃO
O modelo denominado de Técnicas de Quarta Geração
ou 4GT, abrange um amplo conjunto de software...
Quarta Geração
 Linguagens não-procedimentais para consulta de
banco de dados;
 Geração de relatórios;
 Manipulação de ...
Quarta Geração
Obtenção de Requisitos
 Descrição dos requisitos pelo cliente, que são
traduzidos para um protótipo operacional.
- Insegu...
Estratégia de Projeto
Dois casos de desenvolvimento:
1. Pequenas aplicações: é possível
pular esta etapa.
2. Grandes apli...
Implementação utilizando a 4GL
Resultados desejados representados
por geração automática de código.
Estrutura de dados c...
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...
Evolução do Software
 Primeira Geração (1950 a 1960): Sistemas em Batch, software sob medida,
desenvolvidos sem técnicas ...
A metodologia de desenvolvimento deve ser
estabelecida levando-se em consideração o porte do
sistema, as suas característi...
Questionário
1. Defina Engenharia de Software, com suas palavras e
comente sua importância no atual cenário de
desenvolvim...
Analise aula2
Próximos SlideShares
Carregando em…5
×

Analise aula2

283 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
283
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Analise aula2

  1. 1. Análise de Sistemas 1º Módulo
  2. 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. 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. 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. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. CICLO DE VIDA CLÁSSICO
  9. 9.  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.
  10. 10. 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.
  11. 11. 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:
  12. 12.  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
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17.  É 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
  18. 18. 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 .
  19. 19. 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:
  20. 20. 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.
  21. 21. Quarta Geração
  22. 22. 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
  23. 23. 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.
  24. 24. 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.
  25. 25. Testes Realizar testes. Possuir documentação significativa. Manutenção deve ser efetuada prontamente.
  26. 26. 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.
  27. 27. 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).
  28. 28. 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.
  29. 29. 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.

×