Aula ES 05/04

Agenda da aula de 05/04/19:
• NPS Aula anterior;

• Correção das Atividades Contínuas (AC2 e AC3);
• Liberação da AC4;
• OPE: Escolha do Cliente
• Conceitos ES: RUP (continuação);
• Conceitos ES: ES baseada em componentes;
• Conceitos ES: entregas iterativas e incrementais
(+ quadrante Wysocki);
• Chamada;
• NPS.
Engenharia de Software
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
– (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
– (1975 - hoje)
• Sistemas distribuídos
• Redes locais e globais
• Uso generalizado de microprocessadores - produtos inteligentes
• Hardware de baixo custo
• Impacto de consumo
CRISE DE SOFTWARE (aflição

crônica???)
– (Quarta era do software: atualidade)
• Tecnologias orientadas o objetos
• Sistemas especialistas e software de inteligência artificial usados na prática
• Software de rede neural artificial
• Computação Paralela
• Internet
• Dispositivos móveis
• Redes sociais
CRISE DE SOFTWARE (aflição

crônica???)
Crise de Software
• Refere-se a um conjunto de problemas encontrados no
desenvolvimento de software:
1. As estimativas de prazo e de custo frequentemente 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
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
• prazo e de custo X estimativas 
• produtividade das pessoas 
• qualidade de software 
• software difícil de manter 
Causas dos problemas
associados à Crise de Software
1. Natureza do Software
– O software é um elemento de sistema lógico e não físico (produto
intangível)
– Consequentemente, 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!!!
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.
3. Mitos do Software
– Propagaram desinformação e confusão
• administrativos
• cliente
• profissional
Mitos do Software
(administrativos)
• 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?
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
FASES CUSTO DE MANUTENÇÃO

DEFINIÇÃO 1x
DESENVOLVIMENTO 1.5 - 6x
MANUTENÇÃO 60 - 100x
Mitos do Software
(profissional)
• 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.
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.
Preocupação
• Sistematizar o processo de criação e manutenção 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.
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.
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.
Principais Metas
• Melhorar a qualidade de produtos de software, aumentar a
produtividade do pessoal técnico e aumentar a satisfação do
cliente.
Elementos
• Abrange um conjunto de três elementos fundamentais:
– Métodos, Ferramentas e Procedimentos
Métodos
• Proporcionam os detalhes de como fazer para construir o 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
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
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
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
(Cascata)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do
• 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
• 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
• 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
• 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
• 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
• 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
• 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
(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
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
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
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
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
Planejamento Análise de riscos

Coleta inicial dos
requisitos e
Análise de riscos baseada
planejamento do
nos requisitos iniciais
projeto
Análise de riscos baseada
Planejamento baseado na reação do cliente
nos comentários
do cliente Decisão de prosseguir/
não prosseguir
Protótipo de
software inicial
Avaliação do cliente
Protótipo no
nível seguinte
Sistema construído
pela engenharia
Avaliação do cliente Construção

Atividades do
• Planejamento:
– Determinação dos objetivos, alternativas e restrições
• Análise de Risco:
– Análise de alternativas e identificação / resolução de riscos
• Construção:
– Desenvolvimento do produto no nível seguinte
• Avaliação do Cliente:
– Avaliação do produto e planejamento das novas fases
(comentários)
• 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
(comentários)
– 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 4a Geração
• Concentra-se na capacidade de se especificar o software para 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
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
• 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
• 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
• 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
• 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
(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
Definir Atribuir Projetar a

requisitos requisitos aos arquitetura do
iniciais incrementos sistema
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!

Aula ES 05/04

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aula ES 05/04

Diunggah oleh

Hak Cipta:

Format Tersedia

Agenda da aula de 05/04/19:

• NPS Aula anterior;

CRISE DE SOFTWARE (aflição

CRISE DE SOFTWARE (aflição

FASES CUSTO DE MANUTENÇÃO

Planejamento Análise de riscos

Avaliação do cliente Construção

Definir Atribuir Projetar a

Anda mungkin juga menyukai