CENTRO UNIVERSITÁRIO NOVE DE JULHO
CENTRO UNIVERSITÁRIO NOVE DE JULHO
Engenharia de Software
Engenharia de Software
Profº. Edson T. França
Software
Software
Sistemas
• Conjunto de elementos, entre os quais haja alguma relação
• Disposição das partes ou dos elementos de um todo, coordenados entre si, e que formam estrutura organizada
Sistemas Automatizados
Software
Hardware
SISTEMA
Software
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
Características do Software
Características do Software
1- desenvolvido ou projetado por engenharia 2- não se desgasta mas se deteriora
3- a maioria é feita sob medida em vez de ser montada a partir de componentes existentes
4-quando mais especializado o sistema, menor sua capacidade de adaptação a mudanças
Curva de falhas para o hardware
Curva de falhas para o hardware
tempo “desgaste” “mortalidade infantil” índice de falhas
Curva de falhas do software
Curva de falhas do software
índice de falhas mudança curva real curva idealizada tempo
Aplicações do software
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
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
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
Evolução do software
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 software - software houses
" Bibliotecas de Software
Evolução do software
Evolução do software
(1975 - hoje)# Sistemas distribuídos
# Redes locais e globais
# Uso generalizado de microprocessadores - produtos inteligentes
# Hardware de baixo custo
Evolução do software
Evolução do software
(Quarta era do software de computador)
$
Tecnologia orientada o objetos$
Sistemas especialistas e software de inteligência artificial usados na prática$
Software de rede neural artificialCrise de software
Crise de software
Refere-se a um conjunto de problemas encontrados no desenvolvimento de software:
1- As estimativas de prazo e de custo freqüentemente são As estimativas de prazo e de custo freqüentemente são
imprecisas
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
Crise de software
2- A produtividade das pessoas da área de software não A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços
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
Crise de software
3- A qualidade de software às vezes é menos que adequadaA qualidade de software às vezes é menos que adequada
Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software
4- O software existente é muito difícil de manterO 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
Crise de software
$
$ estimativas de prazo e de custoestimativas de prazo e de custo ↑↑
$
$ produtividade das pessoas produtividade das pessoas ↓↓
$
$ qualidade de software qualidade de software ↓↓
$
Causas dos problemas associados
Causas dos problemas associados
à crise de software
à crise de software
1
1-- PRÓPRIO CARÁTER DO SOFTWAREPRÓ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
Causas dos problemas associados
à crise de software
à crise de software
2
2-- FALHAS DAS PESSOAS RESPONSÁVEIS PELO FALHAS DAS PESSOAS RESPONSÁVEIS PELO DESENVOLVIMENTO DE SOFTWARE
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
Causas dos problemas associados à
Causas dos problemas associados à
crise de software
crise de software
3
3-- MITOS DO SOFTWAREMITOS DO SOFTWARE
Propagaram desinformação e confusão
4
4
administrativos
administrativos
4
4
cliente
cliente
4
4
profissional
profissional
4
4
tecnologia
tecnologia
Engenharia de Software
Engenharia de Software
uma visão genérica
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,DEFINIÇÃO%
DESENVOLVIMENTO eDESENVOLVIMENTOFASE DE DEFINIÇÃO:
FASE DE DEFINIÇÃO: ““o que”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 Análise de Requisitos:
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.
Engenharia de Software
Engenharia de Software
uma visão genérica
Engenharia de Software
Engenharia de Software
uma visão genérica
uma visão genérica
DESENVOLVIMENTO
DESENVOLVIMENTO:: “como”“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 algorítmicos 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.
Engenharia de Software
Engenharia de Software
uma visão genérica
uma visão genérica
FASE DE MANUTENÇÃO
FASE DE MANUTENÇÃO:: concentra-se nas
“mudanças”
“mudanças” que ocorrerão depois que o software for liberado para uso operacional
# Correção
# Adaptação
Engenharia de Software
Engenharia de Software
uma visão genérica
uma visão genérica
Correção:
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
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
Engenharia de Software
Engenharia de Software
uma visão genérica
uma visão genérica
Melhoramento Funcional
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.
Engenharia de Software
Engenharia de Software
uma visão genérica
uma visão genérica
ATIVIDADES DE PROTEÇÃO
ATIVIDADES DE PROTEÇÃO as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção.
Revisões
Revisões: efetuadas para garantir que a qualidade seja :
mantida à medida que cada etapa é concluída.
Documentação
Documentação:: é desenvolvida e controlada para garantir que informações completas sobre o software estejam disponíveis para uso posterior.
Engenharia de Software
Engenharia de Software
Métodos Ferramentas Pessoas ProdutividadeEstabelece uso de princípios sólidos de engenharia, com o intuito de obter , economicamente, software que seja confiável e funcione eficientemente em máquinas reais Fratz Bauer, 1969
Engenharia de Software
Engenharia de Software
abrange um conjunto de três elementos fundamentais:
Métodos
Métodos,, Ferramentas Ferramentas e e Procedimentos Procedimentos
MÉTODOS
MÉTODOS: proporcionam os detalhes de como fazer para construir o software
Engenharia de Software
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'
TesteEngenharia de Software
Engenharia de Software
FERRAMENTAS
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
Engenharia de Software
Engenharia de Software
PROCEDIMENTOS
PROCEDIMENTOS: constituem o elo de ligação entre os métodos e ferramentas
# Seqüê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
Engenharia de Software
Conjunto de
etapas que envolve
etapas
MÉTODOS, MÉTODOS FERRAMENTASFERRAMENTAS e PROCEDIMENTOS.PROCEDIMENTOS
' Essas etapas são conhecidas como componentes de
CICLOS DE VIDA DE SOFTWARE
CICLOS DE VIDA DE SOFTWARE
' Alguns ciclos de vida mais conhecidos são: Ciclo deCiclo de Vida Clássico
Vida Clássico, PrototipaçãoPrototipação, , ModeloModelo EspiralEspiral e
Técnicas de 4
Para escolha de um Ciclo de Vida de
Para escolha de um Ciclo de Vida de
software:
software:
# natureza do projeto e da aplicação
# métodos e ferramentas a serem usados
Ciclo de Vida Clássico
Ciclo de Vida Clássico
(Cascata)
(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
Cascata
Cascata
Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes ManutençãoAtividades do Ciclo de Vida Clássico
Atividades do Ciclo de Vida Clássico
1- ANÁLISE E ENGENHARIA DE SISTEMASANÁ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)
Atividades do Ciclo de Vida Clássico
Atividades do Ciclo de Vida Clássico
2- ANÁLISE DE REQUISITOS DE SOFTWAREANÁ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
Atividades do Ciclo de Vida Clássico
Atividades do Ciclo de Vida Clássico
3- PROJETOPROJETO
) 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,
Atividades do Ciclo de Vida Clássico
Atividades do Ciclo de Vida Clássico
4- CODIFICAÇÃOCODIFICAÇÃO
) tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador
Atividades do Ciclo de Vida Clássico
Atividades do Ciclo de Vida Clássico
5- TESTESTESTES
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
Atividades do Ciclo de Vida Clássico
6- MANUTENÇÃOMANUTENÇÃ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
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
$
Embora o Ciclo de Vida Clássico
tenha fragilidades, ele é
significativamente melhor do que uma
abordagem casual ao desenvolvimento
de software
Prototipação
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 protótipo
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.
Prototipação
Prototipação
fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitosAtividades da Prototipação
1
1-- OBTENÇÃO DOS REQUISITOS: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
2-- PROJETO RÁPIDO: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
5
5-- REFINAMENTO DOS REQUISITOS:REFINAMENTO DOS REQUISITOS: cliente e
desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de
iteração
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
6-- CONSTRUÇÃO PRODUTO: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á
Prototipação
Prototipação
$
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.
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
Espiral
Espiral
decisão de continuar ou não na direção de um sistema concluído
avaliação do
cliente engenharia
análise dos riscos planejamento
Espiral
Espiral
Atividades do Ciclo de Vida em
Atividades do Ciclo de Vida em
Espiral
Espiral
1
1-- PLANEJAMENTO:PLANEJAMENTO: determinação dos objetivos,
alternativas e restrições 2
2-- ANÁLISE DE RISCO:ANÁLISE DE RISCO: análise das alternativas e
identificação / resolução dos riscos 3
3-- CONSTRUÇÃO:CONSTRUÇÃO: desenvolvimento do produto no
nível seguinte 4
4-- AVALIAÇÃO DO CLIENTE:AVALIAÇÃO DO CLIENTE: avaliação do produto e
Ciclo de Vida em Espiral
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
Ciclo de Vida em Espiral
Ciclo de Vida em Espiral
!
o modelo é relativamente novo e não tem sido amplamente usado. Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta.Técnicas de 4
aGeraçã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 sistema seja especificado em uma linguagem de alto nível
alto nível e
4
4
a
a
Geração
Geração
Obtenção dos Requisitos Estratégia do “Projeto” Implementação usando 4GL TestesFerramentas do ambiente de
desenvolvimento de software de 4
aGeraçã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
Atividades das Técnicas de 4
aGeração
1- OBTENÇÃO DOS REQUISITOS: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"
Atividades das Técnicas de 4
aGeração
2- ESTRATÉGIA DE "PROJETO":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
Atividades das Técnicas de 4
aGeração
3- IMPLEMENTAÇÃO USANDO 4GL: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: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.
Técnicas de 4
Técnicas de 4
aaGeração
Geração
PROPONENTES:
PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de produtividade)
OPONENTES
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
Mudança na natureza de
Mudança na natureza de
desenvolvimento de software
desenvolvimento de software
métodos convencionais aplicação de técnicas de 4a Geração demanda global demanda por software 1970 1980 1990 2000Combinação dos Métodos de Ciclo de Vida
Combinação dos Métodos de Ciclo de Vida
obtenção dos requisitos preliminares modelo espiral técnicas 4G protomodelagem análise dos requisitos projeto codificação testes protomodelagem no. interação protomodelagem no. interação técnicas 4G modelo espiral no. interação
Conclusão
Conclusão
ENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE
pode ser vista como uma 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]