O documento descreve a crise do desenvolvimento de software nas décadas de 1960 a 1980, citando problemas como demanda maior que a capacidade de desenvolvimento e maus projetos. Também apresenta modelos de processo como o ciclo de vida clássico, prototipagem e espiral, destacando seus benefícios e limitações.

1. Análise de Sistemas
1º Módulo

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

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.

22. Quarta Geração

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.