Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software
Prof. M.Sc. Sílvio Bacalá Júnior
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Software
1. INSTRUÇÕES
• quando executadas produzem a função e o desempenho desejados
2. ESTRUTURAS DE DADOS
• possibilitam que os programas manipulem adequadamente a informação
3. DOCUMENTOS
• descrevem a operação e o uso dos programas
2
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
3
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Curva de falhas para o hardware
4
tempo
“desgaste” “mortalidade
infantil”
índice
de
falhas
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Curva de falhas do software
5
índice de
falhas
mudança
curva real
curva idealizada
tempo
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
6
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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 7
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
8
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Alguns problemas na construção de software • Questões que caracterizaram as preocupações com
o processo de desenvolvimento de software:
• por que o software demora tanto para ser concluído?
• por que os custos de produção têm sido tão elevados?
• por que não é possível detectar todos os erros antes que o software seja entregue ao cliente?
• por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
problema de comunicação entre cliente e fornecedor • Insatisfação do cliente com o sistema
"concluído“ ocorre devido aos projetos de desenvolvimento serem baseados em informações vagas sobre as necessidades e desejos do cliente;
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Falta de teste
• Qualidade do software é quase sempre suspeita, problema resultante da pouca atenção que foi dada, historicamente, às técnicas de teste de software (até porque o conceito de qualidade de software é algo relativamente recente);
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Programação sem controles
• a “cultura de programação” que ainda é difundida e facilmente aceita por estudantes e profissionais de Ciências da Computação;
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Como reduzir ou resolver estes problemas? • Não existe uma abordagem mágica que seja a
melhor para a solução destes problemas
• Os métodos devem ser suportados por um conjunto de ferramentas que permita automatizar o desenrolar das etapas do projeto
• Definição clara de critérios de qualidade e produtividade de software
• Estes aspectos caracterizam a ENGENHARIA DE SOFTWARE
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Definição
• Na literatura, pode-se encontrar diversas definições da Engenharia de Software:
• "O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais" [NAU 69].
• “Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto.” [Krakowiak, 85]
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
15
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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 16
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Evolução do software
• ( a partir 1975)
• Sistemas distribuídos
• Redes locais e globais
• Uso generalizado de microprocessadores - produtos inteligentes
• Hardware de baixo custo
• Impacto de consumo
17
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
18
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Crise de software
• Refere-se a um conjunto de problemas encontrados no desenvolvimento de software:
• Estimativas de prazo e de custo 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” 19
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Crise de software
• 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”
20
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Crise de software
• 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
• 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
21
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Crise de software
22
• estimativas de prazo e de custo
• produtividade das pessoas
• qualidade de software
• software difícil de manter
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Causas dos problemas associados à crise de software • PRÓPRIO CARÁTER DO SOFTWARE
• Elemento de sistema lógico e não físico.
• 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
23
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Causas dos problemas associados à crise de software • FALHAS DAS PESSOAS RESPONSÁVEIS PELO
DESENVOLVIMENTO DE SOFTWARE
• Gerentes com poucos fundamentos em software
• Os profissionais têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software
• Resistência a mudanças.
24
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Causas dos problemas associados à crise de software • MITOS DO SOFTWARE
• Propagaram desinformação e confusão
• administrativos
• cliente
• profissional
25
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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?
• Realidade: Será que o manual é usado?
• Os profissionais sabem que ele existe?
• Ele reflete a prática moderna de desenvolvimento de software? Ele é completo?
26
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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.
27
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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.
28
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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.
• 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. 29
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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.
• 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.
30
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Magnitude das mudanças
FASES CUSTO DE MANUTENÇÃO
DEFINIÇÃO 1 x
DESENVOLVIMENTO 1.5 - 6x
MANUTENÇÃO 60 - 100x
31
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Mitos do software (PROFISSIONAL) • Mito: Assim que escrevermos o programa e o
colocarmos em funcionamento nosso trabalho estará completo.
• 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.
32
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Mitos do software (PROFISSIONAL) • Mito: Enquanto não tiver o programa
"funcionando", eu não terei realmente nenhuma maneira de avaliar sua qualidade.
• 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.
33
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software
• Abrange três elementos fundamentais:
• Métodos,
• Ferramentas e
• Procedimentos
• MÉTODOS: proporcionam os detalhes de como fazer para construir o software
34
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
35
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
36
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software
• PROCEDIMENTOS: constituem o elo de ligação entre os métodos e ferramentas
• Sequência em que os métodos serão aplicados
• Produtos que devem ser entregues
• Controles que ajudam assegurar a qualidade e coordenar as alterações
• Marcos de referência que possibilitam administrar o progresso do software.
37
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
CICLOS DE VIDA DE SOFTWARE
• Conjunto de etapas que envolve MÉTODOS, FERRAMENTAS e PROCEDIMENTOS.
• Alguns ciclos de vida mais conhecidos são:
• Ciclo de Vida Clássico,
• Prototipação,
• Modelo Espiral e
• Técnicas de 4a Geração
38
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Escolha de um Ciclo de Vida de software Depende:
• da natureza do projeto e da aplicação
• dos métodos e ferramentas a serem usados
• dos controles e produtos que precisam ser entregues
39
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
40
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Diretivas do modelo cascata
• Duas diretivas importantes que norteiam o desenvolvimento segundo o modelo cascata:
• todas as etapas definidas no modelo devem ser realizadas, isto porque, em projetos de grande complexidade, a realização formal destas vai determinar o sucesso ou não do desenvolvimento; a realização informal e implícita de algumas destas etapas poderia ser feita apenas no caso de projetos de pequeno porte;
• a ordenação das etapas na forma como foi apresentada deve ser rigorosamente respeitada;
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Modelo em Cascata
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Modelo em Cascata
43
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • ANÁLISE E ENGENHARIA DE SISTEMAS
• 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)
44
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • 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 45
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • 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
46
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • CODIFICAÇÃO
• tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador
47
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • 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.
48
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida Clássico • MANUTENÇÃO
• provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente
• causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho
49
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Problemas com o Ciclo de Vida Clássico • Projetos reais raramente seguem o fluxo
sequencial que o modelo propõe
• 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
50
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Ciclo de Vida Clássico
• Apesar da fragilidades, é melhor do que uma abordagem casual ao desenvolvimento de software
51
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Prototipação
• busca contornar algumas das limitações existentes no modelo Cascata.
• A ideia é eliminar a política de "congelamento" dos requisitos antes do projeto do sistema ou da codificação.
• Interessante para alguns sistemas de grande porte os quais representam um certo grau de dificuldade para exprimir rigorosamente os requisitos;
• Através da construção de um protótipo do sistema, é possível demonstrar a viabilidade do sistema.
• É possível obter uma versão, mesmo simplificada do que será o sistema, com um pequeno investimento inicial.
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Formas de protótipo
• Protótipo em papel ou modelo executável
• retrata a interface homem – máquina, capacitando o cliente a compreender a forma de interação com o software
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Formas de Protótipo
• Protótipo de trabalho
• Um protótipo funcional, que implementa um subconjunto dos requisitos indicados
• Não é um sistema completo, e deixa a desejar em alguns aspectos. Normalmente a interface com o usuário não é implementada no protótipo.
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Formas de Protótipo
• Protótipo Evolutivo
• O protótipo usado para a definição do sistema acaba sendo usado como base do desenvolvimento, fazendo parte do código final.
• Protótipo Exploratório
• Serve apenas para a definição do que fazer, sendo abandonado em seguida.
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Modelagem por Prototipação
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Prototipação
• Possibilita que o desenvolvedor crie um modelo do software que deve ser construído.
• 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.
57
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Prototipação
58
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção
dos
requisitos
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades da Prototipação
• 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.
• 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)
59
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades da Prototipação
• CONSTRUÇÃO PROTÓTIPO:
• implementação do projeto rápido
• AVALIAÇÃO DO PROTÓTIPO:
• cliente e desenvolvedor avaliam o protótipo
60
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades da Prototipação
• 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.
• 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.
61
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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 ideia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final
• desenvolvedor frequentemente 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. 62
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
• ainda que possam ocorrer problemas, a prototipação é um ciclo de vida 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.
63
Problemas com a Prototipação
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
64
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Relembrando a aula passada...
65
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Crise de software
• estimativas de prazo e de custo
• produtividade das pessoas
• qualidade de software
• software difícil de manter
66
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Causas dos problemas associados à crise de software • MITOS DO SOFTWARE
• Propagaram desinformação e confusão
• administrativos
• cliente
• profissional
67
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Modelo em Cascata
68
Engenharia de Sistemas
Análise de Requisitos
Projeto
Codificação
Testes
Manutenção
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Prototipação
69
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção
dos
requisitos
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
70
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Ciclo de Vida em Espiral
71
decisão de continuar ou não
na direção de um sistema
concluído avaliação do
cliente construção
análise dos riscos planejamento
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades do Ciclo de Vida em Espiral • PLANEJAMENTO:
• determinação dos objetivos, alternativas e restrições
• ANÁLISE DE RISCO:
• análise das alternativas e identificação / resolução dos riscos
• CONSTRUÇÃO:
• desenvolvimento do produto no nível seguinte
• AVALIAÇÃO DO CLIENTE:
• avaliação do produto e planejamento das novas fases 72
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Comentários sobre o Ciclo de Vida em Espiral • Abordagem mais realística para o
desenvolvimento de software em grande escala.
• 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
73
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Comentários sobre o Ciclo de Vida em Espiral • Modelo relativamente novo e somente agora
tem sido usado.
• Demorará um pouco até que a eficácia desse modelo possa ser determinada com certeza absoluta.
74
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
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
75
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
4a Geração
76
Obtenção dos Requisitos
Estratégia do “Projeto”
Implementação usando 4GL
Testes
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Ferramentas do ambiente de desenvolvimento de software de 4ª 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 77
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades das Técnicas de 4a Geração • 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"
78
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades das Técnicas de 4a Geração • 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)
79
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Atividades das Técnicas de 4a Geração • 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
• 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.
80
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Comentários sobre as Técnicas de 4a Geração • PROPONENTES:
• redução dramática no tempo de desenvolvimento do software (aumento de produtividade)
• 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 manutenibilidade de sistemas usando técnicas 4G ainda é questionável
81
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Mudança na natureza de desenvolvimento de software
82
métodos
convencionais
aplicação de
técnicas de 4a
Geração
demanda global
demanda por
software
1970 1980 1990 2000
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Combinação dos Métodos de Ciclo de Vida
83
obtenção dos requisitos
preliminares
modelo espiral
técnicas
4G
protomodelagem
análise dos
requisitos
projeto
codificação
testes
manutenção
protomodelagem
no. interação
protomodelagem
no. interação
técnicas
4G
modelo espiral
no. interação
sistema completo
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • O processo de desenvolvimento de software
contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido:
• DEFINIÇÃO,
• DESENVOLVIMENTO e
• MANUTENÇÃO.
84
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • FASE DE DEFINIÇÃO: “o que” será desenvolvido. • Análise do Sistema:
• define o papel de cada elemento num sistema baseado em computador, atribuindo em última análise, o papel que o software desempenhará.
• Planejamento do Projeto de Software: • assim que o escopo do software é estabelecido, os riscos
são analisados, os recursos são alocados, os custos são estimados e, tarefas e programação de trabalho definidas.
• Análise de Requisitos: • o escopo definido para o software proporciona uma
direção, mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho inicie.
85
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • DESENVOLVIMENTO: “como” o software vai ser desenvolvido.
• Projeto de Software: • traduz os requisitos do software num conjunto de representações
(algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algoritmicos e as características de interface.
• Codificação: • as representações do projeto devem ser convertidas numa
linguagem artificial (a linguagem pode ser uma linguagem de programação convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador.
• Realização de Testes do Software: • logo que o software é implementado numa forma executável por
máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação.
86
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • FASE DE MANUTENÇÃO:
• concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para uso operacional
• Correção
• Adaptação
• Melhoramento Funcional
87
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • Correção:
• mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos.
• Adaptação:
• com o passar do tempo, o ambiente original (por exemplo a CPU, o sistema operacional e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente. 88
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • Melhoramento Funcional:
• a medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios. A manutenção perfectiva estende o software para além de suas exigências funcionais originais.
89
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Engenharia de Software uma visão genérica • ATIVIDADES DE PROTEÇÃO
• Revisões: • efetuadas para garantir que a qualidade seja
mantida à medida que cada etapa é concluída.
• Documentação: • desenvolvida e controlada para garantir que
informações completas sobre o software estejam disponíveis para uso posterior.
• Controle das Mudanças: • instituído de forma que as mudanças possam ser
aprovadas e acompanhadas. 90
Prof. Sílvio Bacalá Jr – www.facom.ufu.br/~bacala/ES
Conclusão
• ENGENHARIA DE SOFTWARE
• abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos.
• .....“a construção por múltiplas pessoas de um software de múltiplas versões” [Parnas 1987]
91
Recommended