201483_213358_engsoft1_2014

Prévia do material em texto

ENGENHARIA DE SOFTWARE
Professor
George Hamilton
ENGENHARIA DE SOFTWARE
Parte I
Engenharia de Software
O termo foi criado na década de 1960 e utilizado 
oficialmente em 1968 na NATO Conference on 
Software Engineering (Conferência sobre Engenharia 
de Software da OTAN). 
Sua criação surgiu numa tentativa de contornar a crise do 
software e dar um tratamento de engenharia (mais 
sistemático e controlado) ao desenvolvimento de 
sistemas de software complexos. 
Objetivos
• Apresentar a engenharia de software e 
explicar a sua importância;
• Dirigir as respostas às questões-chave 
sobre engenharia de software;
• Apresentar questões éticas e 
profissionais e explicar por que elas são 
assunto para engenheiros de software
Motivação
• As economias de maioria das nações são 
dependentes de software.
• Cada vez mais sistemas são controlados por 
software.
• A engenharia de software se dedica às 
teorias, métodos e ferramentas para 
desenvolvimento de software profissional
• Os dispêndios com software representam 
uma fração significativa do PIB em todos os 
países desenvolvidos.
Motivação
• Os custos de software dominam os custos de 
sistemas computacionais.
• Em um PC, os custos de software são 
frequentemente maiores que o custo do hardware.
• Manter um software custa mais que desenvolvê-lo.
• Para sistemas com uma longa vida, os custos de 
manutenção podem ser muito maiores que os 
custos de desenvolvimento.
Questões
• O que é software?
• O que é engenharia de software?
• Qual é a diferença entre engenharia de 
software e ciência da computação?
• Qual é a diferença entre engenharia de 
software e engenharia de sistemas?
• O que é processo de software?
• O que é um modelo de processo de 
software?
• Quais são os custos da engenharia de 
software?
• Quais são os métodos da engenharia de 
software?
• O que é CASE (Computer-Aided Software 
Engeneering)
• Quais são os atributos de um bom software?
• Quais são os desafios-chave enfrentados 
pela engenharia de software?
Questões
O que é software?
• Programas de computador e documentação associada, tais 
como requisitos, modelos de projetos e manuais de 
usuário.
• Produtos de software podem ser desenvolvidos para um 
cliente particular ou para um mercado geral.
O que é software?
• Produtos de software podem ser:
– Genéricos – desenvolvidos para serem vendidos para 
uma grande variedade de clientes, por exemplo, 
softwares para PC, tais como Excel e Word.
– Personalizados – desenvolvidos para um único cliente 
de acordo com as suas especificações.
• Um software novo pode ser criado através do 
desenvolvimento de novos programas, da configuração de 
sistemas de software genéricos ou da reutilização de um 
software existente.
O que é Engenharia de 
Software?
• Engenharia de software é uma disciplina de 
engenharia relacionada com todos os 
aspectos da produção de software.
• Engenheiros de software devem -
dependendo do problema a ser resolvido, 
das restrições de desenvolvimento e dos 
recursos disponíveis - adotar uma 
abordagem sistemática e organizada para 
seu trabalho, além de usar ferramentas e 
técnicas apropriadas.
Qual é a diferença entre Engenharia 
de
Software e Ciência da Computação?
• A ciência da computação dedica-se à 
teoria e aos fundamentos;
• já a engenharia de software dedica-se 
aos aspectos práticos de 
desenvolvimento e de entrega de 
software para o uso.
Qual é a diferença entre Engenharia 
de
Software e Engenharia de Sistemas?
• A engenharia de sistemas dedica-se aos 
aspectos de desenvolvimento de sistemas 
baseados em computador, incluindo a 
engenharia de hardware, de software e de 
processo.
– A engenharia de software é parte desse processo 
que se dedica ao desenvolvimento da infra-
estrutura do software, controle, aplicações e 
banco de dados no sistema.
• Os engenheiros de sistema estão envolvidos 
na especificação, no projeto de arquitetura e 
na integração e implantação do sistema.
O que é Processo de 
Software?
• É um conjunto de atividades cuja meta é o 
desenvolvimento ou evolução de software.
• As atividades genéricas em todos os 
processos de software são:
– Especificação – o que o sistema deve fazer e 
suas restrições de desenvolvimento.
– Desenvolvimento – produção do sistema de 
software.
– Validação – verificação de que o software é o 
que o cliente deseja.
– Evolução – mudança do software em resposta 
às demandas de mudança.
O que é um modelo de
Processo de Software?
• Uma representação simplificada de um 
processo de software, apresentado sob uma 
perspectiva específica.
• Exemplos de modelos de processo são:
– Modelo de workflow – sequência de atividades;
– Modelo de fluxo de dados – fluxo de informações;
– Modelo de papel/ação – quem faz o quê.
• Modelos gerais de processo:
– Cascata;
– Desenvolvimento iterativo;
– Engenharia de software baseada em componentes.
Quais são normalmente os custos 
da
Engenharia de Software?
• Aproximadamente 60% dos custos são custos de 
desenvolvimento e 40% são custos de testes.
– Para software sob encomenda, os custos de 
evolução normalmente excedem de 
desenvolvimento.
• Os custos variam dependendo do tipo de sistema 
que está sendo desenvolvido e dos requisitos de 
atributos de sistema, tais como desempenho e 
confiabilidade.
• A distribuição de custos depende do modelo de 
desenvolvimento que é usado.
Distribuição de custos nas 
atividades
O que é CASE
(Computer-Aided Software 
Engineering)
• Sistemas de software que se destinam a 
fornecer apoio automatizado para as 
atividades de processo de software.
• Sistemas CASE são usados frequentemente 
para apoio ao método.
– Upper-CASE: Ferramentas para apoiar as 
atividades iniciais de processo de requisitos e de 
projeto;
– Lower-CASE: Ferramentas para apoiar as 
atividades finais tais como programação, 
debugging e teste.
Quais são os atributos de um bom 
Software?
O software deve fornecer a funcionalidade e o desempenho 
requeridos para o usuário e deve ser manutenível, confiável e 
aceitável.
• Facilidade de manutenção: O software deve evoluir para atender 
às necessidades de mudança;
• Confiança: O software deve ser confiável;
• Eficiência: O software não deve desperdiçar os recursos do 
sistema;
• Aceitabilidade: O software deve ser aceito pelos usuários para o 
qual foi projetado. Isso significa que ele deve ser compreensível, 
usável e compatível com outros sistemas.
Quais são os desafios-chave enfrentados
pela Engenharia de Software?
Heterogeneidade, Entrega e Confiança.
• Heterogeneidade
– Técnicas de desenvolvimento para construção de 
software que podem lidar com plataformas 
heterogêneas e ambientes de execução;
• Entrega
– Técnicas de desenvolvimento para conduzir a 
entrega mais rápida de software;
• Confiança
– Técnicas de desenvolvimento que mostram que o 
software pode ter a confiança dos seus usuários.
Responsabilidade profissional e ética
• A engenharia de software envolve 
responsabilidades mais amplas do que 
simplesmente a aplicação de habilidades 
técnicas.
• Os engenheiros de software devem se 
comportar de modo honesto e eticamente 
responsável para serem respeitados como 
profissionais.
• O comportamento ético é mais do que 
simplesmente a sustentação de leis.
Dilemas éticos
• Discordância, em princípio, das 
políticas da gerência sênior.
• Seu funcionário age de uma forma não 
ética e libera um sistema de segurança 
crítico sem finalizar o teste do sistema.
• Participação no desenvolvimento de 
sistemas de armamentos militares ou 
de sistemas nucleares.
Segundo o SWEBOK (Corpo de Conhecimento da Engenharia 
deSoftware), versão 2004, as áreas de conhecimento da 
Engenharia de Software são:
•Requisitos (Requirements) de Software 
•Projeto (Design) de Software 
•Construção (Construction) de Software 
•Teste (Testing) de Software 
•Manutenção (Maintenance) de software 
•Gerência de Configuração de Software 
•Gerência de Engenharia de Software 
•Processos de Engenharia de Software 
•Ferramentas e Métodos de Engenharia de Software 
•Qualidade (Quality) de Software 
ENGENHARIA DE SOFTWARE
Parte II
Software
1- INSTRUÇÕES
que quando executadas produzem a função e o 
desempenho desejados
2 - ESTRUTURAS DE DADOS
que possibilitam que os programas manipulem 
adequadamente a informação
3 - DOCUMENTOS
que descrevem a operação e o uso dos programas
Características do Software
1- desenvolvido ou projetado por engenharia, não 
manufaturado no sentido clássico
2- não se desgasta mas se deteriora
3- a maioria é feita sob medida em vez de ser 
montada a partir de componentes existentes
28
Curva de falhas para o hardware
tempo
“desgaste”
“mortalidade
infantil”
índice 
de 
falhas
29
Curva de falhas do software
índice de 
falhas
mudança
curva real
curva idealizada
tempo
Aplicações do software
BÁSICO coleção de programas escritos para dar 
apoio a outros programas
DE TEMPO REAL software que monitora, analisa 
e controla eventos do mundo real
COMERCIAL sistemas de operações comerciais e 
tomadas de decisões administrativas
CIENTÍFICO E DE ENGENHARIA 
caracterizado por algoritmos de processamento de 
números
Aplicações do software
EMBUTIDO usado para controlar produtos e 
sistemas para os mercados industriais e de consumo 
DE COMPUTADOR PESSOAL envolve 
processamento de textos, planilhas eletrônicas, 
diversões, etc.
DE INTELIGÊNCIA ARTIFICIAL faz uso de 
algoritmos não numéricos para resolver problemas que 
não sejam favoráveis à computação ou à análise direta
Evolução do software
(1950 - 1965)
� O hardware sofreu contínuas mudanças
� O software era uma arte "secundária" para 
a qual havia poucos métodos sistemáticos
� O hardware era de propósito geral
� O software era específico para cada 
aplicação 
� Não havia documentação
Evolução do software
(1965 - 1975)
�Multiprogramação e sistemas multiusuários 
� Técnicas interativas 
� Sistemas de tempo real
� 1a. geração de SGBD’s
� Produto de sofwtare - software houses
� Bibliotecas de Software
� Cresce nro. de sistemas baseado em computador
�Manutenção quase impossível
..... CRISE DE SOFTWARE 
Evolução do software
(1975 - hoje)
� Sistemas distribuídos
� Redes locais e globais
� Uso generalizado de 
microprocessadores - produtos 
inteligentes
� Hardware de baixo custo
� Impacto de consumo
Evolução do software
(Quarta era do software de computador)
� Tecnologias orientadas o objetos
� Sistemas especialistas e software de 
inteligência artificial usados na prática
� Software de rede neural artificial
� Computação Paralela
crise de software
Refere-se a um conjunto de problemas 
encontrados no desenvolvimento e 
manutenção de softwares.
Como o cliente 
explicou
Como o Lider de 
projeto entendeu
Como a equipe de 
projeto 
desenvolveu
O QUE O 
CLIENTE 
QUERIA
EXEMPLO DE RETRABALHO
crise de software
1- As estimativas de prazo e de custo 
freqüentemente são imprecisas
“Não dedicamos tempo para coletar dados sobre o
processo de desenvolvimento de software”
“Sem nenhuma indicação sólida de produtividade,
não podemos avaliar com precisão a eficácia de
novas ferramentas, métodos ou padrões”
crise de software
2- A produtividade das pessoas da área de software 
não tem acompanhado a demanda por seus 
serviços
“Os projetos de desenvolvimento de software 
normalmente são efetuados apenas com um vago 
indício das exigências do cliente”
crise de software
3- A qualidade de software às vezes é menos que 
adequada
Só recentemente começam a surgir conceitos 
quantitativos sólidos de garantia de qualidade 
de software
crise de software
4- O software existente é muito difícil de manter
A tarefa de manutenção devora o orçamento 
destinado ao software
A facilidade de manutenção não foi enfatizada 
como um critério importante
crise de software
� estimativas de prazo e de custo ↑
� produtividade das pessoas ↓
� qualidade de software ↓
� software difícil de manter ↑
Causas dos problemas associados 
à crise de software
1- PRÓPRIO CARÁTER DO SOFTWARE
O software é um elemento de sistema lógico e não 
físico. Conseqüentemente o sucesso é medido 
pela qualidade de uma única entidade e não 
pela qualidade de muitas entidades 
manufaturadas
O software não se desgasta, mas se deteriora
Causas dos problemas associados 
à crise de software
2- FALHAS DAS PESSOAS RESPONSÁVEIS PELO 
DESENVOLVIMENTO DE SOFTWARE
Gerentes sem nenhum background em software
Os profissionais da área de software têm recebido pouco 
treinamento formal em novas técnicas para o 
desenvolvimento de software
Resistência a mudanças.
Causas dos problemas associados à 
crise de software
3- MITOS DO SOFTWARE
Propagaram desinformação e confusão
4administrativos
4cliente
4profissional
Mitos do software (ADMINISTRATIVOS)
Mito: Já temos um manual repleto de padrões e 
procedimentos para a construção de software. Isso 
não oferecerá ao meu pessoal tudo o que eles 
precisam saber?
Mitos do software (ADMINISTRATIVOS)
Realidade: Será que o manual é usado?
Os profissionais sabem que ele existe? 
Ele reflete a prática moderna de 
desenvolvimento de software? Ele é 
completo? 
Mitos do software 
(ADMINISTRATIVOS)
Mito: Meu pessoal tem ferramentas de
desenvolvimento de software de última
geração; afinal lhes compramos os mais
novos computadores.
Realidade:É preciso muito mais do que os 
mais recentes computadores para se 
fazer um desenvolvimento de software 
de alta qualidade.
Mitos do software 
(ADMINISTRATIVOS)
Mito: Se nós estamos atrasados nos prazos,
podemos adicionar mais programadores e tirar
o atraso.
Realidade:O desenvolvimento de software 
não é um processo mecânico igual à 
manufatura. Acrescentar pessoas em um 
projeto torna-o ainda mais atrasado. 
Pessoas podem ser acrescentadas, mas 
somente de uma forma planejada.
Mitos do software (CLIENTE)
Mito: Uma declaração geral dos objetivos é suficiente 
para se começar a escrever programas - podemos 
preencher os detalhes mais tarde.
Mitos do software
(CLIENTE)
Realidade: Uma definição inicial ruim é a principal causa de 
fracassos dos esforços de desenvolvimento de software. É 
fundamental uma descrição formal e detalhada do domínio da 
informação, função, desempenho, interfaces, restrições de 
projeto e critérios de validação.
Mitos do software (CLIENTE)
Mito: Os requisitos de projeto modificam-se
continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é
flexível.
Mitos do software (CLIENTE)
Realidade:Uma mudança, quando solicitada 
tardiamente num projeto, pode ser maior 
do que a ordem de magnitude mais 
dispendiosa da mesma mudança solicitada 
nas fases iniciais.
Mitos do software (PROFISSIONAL)
Mito: Assim que escrevermos o programa e o
colocarmos em funcionamento nosso
trabalho estará completo.
Mitos do software (PROFISSIONAL)
Realidade: Os dados da indústria indicam
que entre 50 e 70% de todo esforço gasto
num programa serão despendidos depois
que ele for entregue pela primeira vez ao
cliente.
Mitos do software (PROFISSIONAL)
Mito: Enquanto não tiver o programa 
"funcionando", eu não terei realmente 
nenhuma maneira de avaliar sua qualidade.
Mitos do software (PROFISSIONAL)Realidade:Um programa funcionando é 
somente uma parte de uma Configuração 
de Software que inclui todos os itens de 
informação produzidos durante a 
construção e manutenção do software.
Abrange um conjunto de três elementos fundamentais: Métodos,
Ferramentas e Processos, para projetar, construir e manter grandes 
sistemas de software de forma profissional.
Engenharia de Software
� Planejamento e estimativa de projeto
� Análise de requisitos de software e de 
sistemas
� Projeto da estrutura de dados
� Algoritmo de processamento
� Codificação
� Teste
� Manutenção
MÉTODOS: proporcionam os detalhes de como fazer para
construir o software
Engenharia de Software
FERRAMENTAS: dão suporte automatizado aos 
métodos.
�Existem atualmente ferramentas para sustentar cada 
um dos métodos
�Quando as ferramentas são integradas é estabelecido 
um sistema de suporte ao desenvolvimento de software 
chamado CASE - Computer Aided Software 
Engineering 
Engenharia de Software
PROCESSOS: constituem o elo de ligação entre os
métodos e ferramentas
� Sequência em que os métodos serão aplicados
� Produtos que se exige que sejam entregues
� Controles que ajudam assegurar a qualidade e 
coordenar as alterações
� Marcos de referência que possibilitam administrar 
o progresso do software.
ENGENHARIA DE SOFTWARE
Conjunto de etapas que envolveMÉTODOS, 
FERRAMENTAS e PROCESSOS.
� Essas etapas são conhecidas como componentes de
CICLOS DE VIDA DE SOFTWARE
� Alguns ciclos de vida mais conhecidos são: Ciclo de
Vida Clássico, Prototipação, Modelo Espiral e 
Técnicas de 4a Geração
Para escolha de um Ciclo de Vida de software:
� natureza do projeto e da aplicação
�métodos e ferramentas a serem usados
� controles e produtos que precisam ser 
entregues
Ciclo de Vida Clássico (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
Lev de Req.
Análise de 
Requisitos 
Projeto 
Implementação
Testes 
Implantação
Cascata
Atividades do Ciclo de Vida Clássico
1- LEVANT. DE REQUISITOS
� 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)
Atividades do Ciclo de Vida Clássico
2- 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
�Modelagem conceitual
Atividades do Ciclo de Vida Clássico
3- 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
� se concentra em 4 atributos do programa: 
� Estrutura de Dados,
� Arquitetura de Software, 
� Detalhes Procedimentais e 
� Caracterização de Interfaces
Atividades do Ciclo de Vida Clássico
4- IMPLEMENTAÇÃO
� tradução das representações do projeto para 
uma linguagem de programação resultando em 
instruções executáveis pelo computador
Atividades do Ciclo de Vida Clássico
5- 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.
Atividades do Ciclo de Vida Clássico
6- IMPLANTAÇÃO
� Entrega do software ao cliente.
� Treinamentos.
Problemas com o Ciclo de Vida Clássico
� projetos reais raramente seguem o fluxo 
seqüencial que o modelo propõe
� logo no início é difícil estabelecer explicitamente 
todos os requisitos. No começo dos projetos 
sempre existe uma incerteza natural
�o cliente deve ter paciência. Uma versão 
executável do software só fica disponível numa 
etapa avançada do desenvolvimento
Prototipação
�processo que possibilita que o desenvolvedor crie um 
modelo do software que deve ser construído.
� idealmente, o modelo (protótipo) serve como um 
mecanismo para identificar os requisitos de software.
�apropriado para quando o cliente definiu um 
conjunto de objetivos gerais para o software, 
mas não identificou requisitos de entrada, 
processamento e saída com detalhes.
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção
dos
requisitos
Prototipação
Atividades da Prototipação
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.
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)
Atividades da Prototipação
3- CONSTRUÇÃO PROTÓTIPO: implementação 
do projeto rápido
4- AVALIAÇÃO DO PROTÓTIPO: cliente e 
desenvolvedor avaliam o protótipo
Atividades da Prototipação
5- REFINAMENTO DOS REQUISITOS: cliente e 
desenvolvedor refinam os requisitos do 
software a ser desenvolvido. Ocorre neste ponto um
processo de iteração que pode conduzir a atividade 1 até que as 
necessidades do cliente sejam satisfeitas e o desenvolvedor 
compreenda o que precisa ser feito.
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. 
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. Não aceita bem a idéia que a versão final do software vai ser 
construída e "força" a utilização do protótipo como produto final
�desenvolvedor freqüentemente faz uma 
implementação comprometida (utilizando o que 
está disponível) com o objetivo de produzir 
rapidamente um protótipo. Depois de um tempo ele 
familiariza com essas escolhas, e esquece que elas não são apropriadas 
para o produto final.
�ainda que possam ocorrer problemas, 
a prototipação é 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.
Ciclo de Vida em 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áticos 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
decisão de continuar ou não
na direção de um 
sistema concluídoavaliação
do cliente engenharia
análise dos
riscos
planejamento
Espiral
Atividades do Ciclo de Vida em Espiral
1- PLANEJAMENTO: determinação dos objetivos, 
alternativas e restrições
2- ANÁLISE DE RISCO: análise das alternativas e 
identificação / resolução dos riscos
3- CONSTRUÇÃO: desenvolvimento do produto no 
nível seguinte
4- AVALIAÇÃO DO CLIENTE: avaliação do produto e 
planejamento das novas fases
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
	 exige considerável experiência na determinação 
de riscos e depende dessa experiência para ter 
sucesso
90
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
91
Obtenção dos 
Requisitos
Estratégia do 
“Projeto” 
Implementação 
usando 4GL 
Testes 
4a Geração
92
Ferramentas do ambiente de 
desenvolvimento de software 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
93
Atividades das Técnicas de 4a Geração
1- 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"
94
Atividades das Técnicas de 4a Geração
2- ESTRATÉGIA DE "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) 
95
Atividades das Técnicas de 4a Geração
3- 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
4- TESTE: 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.