Академический Документы
Профессиональный Документы
Культура Документы
Aula 1
Fundamentos Básicos da Engenharia de Software
Elementos de um Software
– Instruções
• Quando executadas produzem a função e o desempenho desejados
– Estruturas de Dados
• Possibilitam que os programas manipulem adequadamente a informação
– Documentos
• 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
Curva de falhas
para o Hardware
falhas “desgaste”
“mortalidade
infantil”
tempo
Curva de falhas
do Software
falhas
curva real
curva idealizada
tempo
mudança
Tipos de Software
BÁSICO programas de apoio a outros programas
DE TEMPO REAL monitora, analisa e controla eventos do mundo
real
COMERCIAL operações comerciais e tomadas de decisões
administrativas
CIENTÍFICO E DE algoritmos de processamento de números
ENGENHARIA
EMBUTIDO controla produtos e sistemas de mercados
industriais e de consumo
DE COMPUTADOR PESSOAL processamento de textos, planilhas eletrônicas,
diversões, etc.
DE INTELIGÊNCIA ARTIFICIAL algoritmos não numéricos para resolver problemas
que não sejam favoráveis à computação ou à
análise direta
Mobilie aplicativos para dispositivos móveis
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 software - software houses
• Bibliotecas de Software
• Cresce no 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
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)
• 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)
• Sempre que estivermos atrasados, 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)
• 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.
Mitos do Software
(cliente)
• 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 mais
do que uma ordem de magnitude mais dispendiosa do que a mesma mudança solicitada
nas fases iniciais.
Impacto
das Mudanças
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)
• 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.
Engenharia de Software
Preocupação
• Sistematizar o processo de criação e manutenção de software.
Engenharia de Software
Definições
• Boehm:
– Engenharia de software envolve a aplicação prática de conhecimento
científico para o projeto e construção de programas de computador e a
documentação associada necessária para desenvolvê-los, operá-los e
mantê-los.
Engenharia de Software
Definições
• IEEE Standard Glossary of Software Engineering terminology:
– Engenharia de software é uma abordagem sistemática para o
desenvolvimento, operação, manutenção de software
– Software:
• Programas de computador, procedimentos, regras, documentação
possivelmente associada, e dados sobre sua operação.
Engenharia de Software
Definições
• Fairley:
– Engenharia de software é a disciplina tecnológica e gerencial preocupada
com a produção sistemática e manutenção de produtos de software que
são desenvolvidos e modificados no prazo estabelecido e dentro das
estimativas de custo.
Engenharia de Software
Principais Metas
• Melhorar a qualidade de produtos de software, aumentar a
produtividade do pessoal técnico e aumentar a satisfação do
cliente.
Engenharia de Software
Elementos
• Abrange um conjunto de três elementos fundamentais:
– Métodos, Ferramentas e Procedimentos
Engenharia de Software
Métodos
• Proporcionam os detalhes de como fazer para construir o software
Engenharia de Software
Alguns Métodos
• Planejamento e estimativa de projeto
• Análise de requisitos de sistemas e de software
• Projeto da estrutura de dados
• Algoritmo de processamento
• Codificação
• Teste
• Manutenção
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
Procedimentos
• Constituem o elo de ligação entre os métodos e ferramentas
• Define a sequência em que os métodos serão aplicados
• Produz artefatos que precisam ser entregues
• Possui controles que ajudam assegurar a qualidade e coordenar
as alterações
• Estabelecem marcos de referência que possibilitam administrar o
progresso do software
Engenharia de Software
Atividade
– O conjunto de métodos, procedimentos e ferramentas definem ATIVIDADE
que são componentes dos PARADIGMAS da Engenharia de Software
Paradigmas de ES
• São os modelos de processos
– Possibilitam ao Gerente controlar o processo de desenvolvimento de
sistemas de software e ao Desenvolvedor obter a base para produzir, de
maneira eficiente, software que satisfaça os requisitos preestabelecidos
(Pressman)
• Define a ordem em que as atividades são executadas
• Ajuda a reduzir problemas no processo de desenvolvimento do
software
• Deve ser escolhido de acordo com:
– Natureza do projeto e do produto
– Métodos e ferramentas utilizados
– Controles e Produtos intermediários desejados
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, seqeencial ao
desenvolvimento de software
Ciclo de Vida Clássico
(Cascata)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do
Ciclo de Vida Clássico
• ANÁLISE E ENGENHARIA DE SISTEMAS
– Envolve a coleta de requisitos em nível do sistema, pouca quantidade de
projeto e a análise é de alto nível
– Visão essencial quando o software deve fazer interface com outros
elementos (hardware, pessoas e banco de dados)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do
Ciclo de Vida Clássico
• ANÁLISE DE REQUISITOS DE SOFTWARE
– A coleta de requisitos é intensificada e focada no software
– Concentra-se em entender o domínio da informação, a função,
desempenho e interfaces exigidos
– Os requisitos de sistema e de software são documentados e revistos com o
cliente
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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
– Concentra-se nos 4 atributos do programa:
• Estrutura de Dados,
• Arquitetura de Software,
• Detalhes Procedimentais e
• Caracterização de Interfaces
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
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
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do
Ciclo de Vida Clássico
• TESTES
– Concentram-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.
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do
Ciclo de Vida Clássico
• MANUTENÇÃO
– o software deverá sofrer mudanças depois que for entregue ao cliente
– Causas das mudanças:
• Erros
• Mudanças no ambiente
• Exigência do cliente para acréscimos funcionais e de desempenho
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Problemas com o
Ciclo de Vida Clássico
• Projetos reais raramente seguem o fluxo sequencial
• No início do processo é 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
Ciclo de Vida Clássico
(comentários)
• Embora o Ciclo de Vida Clássico tenha fragilidades, ele é
significativamente melhor do que uma abordagem casual de
desenvolvimento de software
Prototipação
• Possibilita ao desenvolvedor criar um modelo do software a
construído
• Idealmente, 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 em detalhes
os requisitos de entrada, processamento e saída
Prototipação
início
fim
obtenção
dos
requisitos
construção projeto
produto rápido
refinamento construção
protótipo protótipo
avaliação
protótipo
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)
iníci
o
fim
obtenção
dos
requisitos
construção projeto
produto rápido
construçã
refinament
o
o protótipo
protótipo
avaliação
protótipo
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
iníci
o
fim
obtenção
dos
requisitos
construção projeto
produto rápido
construçã
refinament
o
o protótipo
protótipo
avaliação
protótipo
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 1a.
atividade até que as necessidades do cliente sejam satisfeitas e o
desenvolvedor compreenda o que precisa ser feito.
iníci
o
fim
obtenção
dos
requisitos
construção projeto
produto rápido
construçã
refinament
o
o protótipo
protótipo
avaliação
protótipo
Atividades da
Prototipação
• 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.
iníci
o
fim
obtenção
dos
requisitos
construção projeto
produto rápido
construçã
refinament
o
o protótipo
protótipo
avaliação
protótipo
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
Problemas com a
Prototipação
• Desenvolvedor normalmente utiliza o que está disponível com o
objetivo de produzir rapidamente um protótipo
• Com o tempo acostuma-se com isso e esquece que essa
abordagem não é apropriada para o desenvolvimento do produto
final
Prototipação
(comentários)
• Ainda que possam ocorrer problemas, a prototipação é um ciclo
de vida eficiente
• A chave é definir as regras do jogo logo no começo
• O cliente e o desenvolvedor devem concordar que o protótipo seja
construído para auxiliar na descoberta de 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:
– Análise de Riscos
• 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
Ciclo de Vida em Espiral
Sistema construído
pela engenharia
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementação
usando 4GL
Testes
Ferramentas do ambiente de
desenvolvimento de software de 4GL
• 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
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
• Problemas:
– 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 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 4G
• Problemas:
– 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)
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
Atividades das
Técnicas de 4a Geração
• 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 4a Geração
(comentários)
• 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
ES baseada em componentes
• Baseado em reuso sistemático onde sistemas são integrados a
partir de componentes existentes
• Estágios do processo
– Análise de componentes
– Modificação de requisitos
– Projeto de sistema com reuso
– Desenvolvimento e integração
• Esta abordagem está se tornando cada vez mais usada à medida
que padrões de componentes têm surgido
• Reuso acidental vs. Reuso planejado
Processos Iterativos
• Requisitos de sistema sempre evoluem no curso de um projeto
– Algum retrabalho é necessário
• A abordagem iterativa pode ser aplicada a qualquer um dos
modelos genéricos do processo
• Duas abordagens (relacionadas)
– Desenvolvimento espiral
– Entrega incremental
Entrega incremental
• O sistema é entregue ao cliente em incrementos
– Cada incremento fornece parte da funcionalidade
• Os requisitos são priorizados
– Requisitos de prioridade mais alta são incluídos nos incrementos iniciais
• Uma vez que o desenvolvimento de um incremento é iniciado, os
requisitos são congelados
– Os requisitos para os incrementos posteriores podem continuar evoluindo
(e incluir requisitos já implementados)
Desenvolvimento incremental
Desenvolver
Validar Integrar
incremento do Validar sistema
incremento incremento
sistema
Sistema
final
Sistema incompleto
Desenvolvimento Incremental
Vantagens
• Incrementos podem ser entregues regularmente ao cliente e,
desse modo, a funcionalidade de sistema é disponibilizada mais
cedo
• Os incrementos iniciais agem como protótipos para elucidar os
requisitos para incrementos posteriores do sistema
• Menor risco de falha geral do projeto
• Os serviços de sistema de mais alta prioridade tendem a receber
mais testes
eXtreme Programming (XP)
• Uma abordagem baseada no desenvolvimento e na entrega de
incrementos de funcionalidade muito pequenos
• Baseia-se no aprimoramento constante do código, em testes
automatizados, no envolvimento do usuário na equipe e no
desenvolvimento em pares
O Processo Unificado
(RUP –Rational UnifiedProcess)
• É um processo baseado na UML
– Tenta cobrir todos os aspectos do desenvolvimento de software
• Fortemente focado na documentação do sistema
• Normalmente descrito a partir de três perspectivas
– Dinâmica: mostra as fases ao longo do tempo
– Estática: mostra atividades de processo
– Prática: sugere bons princípios e práticas de desenvolvimento
Modelo de fases do RUP
Fases do RUP
• Concepção
– Estabelecer o domínio de negócio para o sistema
• Elaboração
– Desenvolver um entendimento do domínio do problema e a arquitetura do
sistema
• Construção
– Projeto, programação e teste de sistema
• Transição
– Implantar o sistema no seu ambiente operacional
Boas práticas do RUP
• Desenvolver o software iterativamente
• Gerenciar requisitos
• Usar arquiteturas baseadas em componentes
• Modelar o software visualmente
• Verificar a qualidade de software
• Controlar as mudanças do software
Obrigado!