SlideShare uma empresa Scribd logo
Engenharia de Software
Prof. Inês Ap. Gasparotto Boaventura
1. Semestre/2001
Tópicos
1- Introdução à Engenharia de Software
2 - Fundamentos Organizacionais de Sistemas
de Informação
3- Gerência de projeto de software
4- Gerenciamento para a qualidade de
software
5- Acompanhamento do processo de
desenvolvimento de software.
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
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
tempo
“desgaste”
“mortalidade
infantil”
índice
de
falhas
Curva de falhas do Software
índice de
falhas
mudança
curva real
curva idealizada
tempo
Aplicações do Software
B
BÁ
ÁS
SI
IC
CO
O programas de apoio a outros programas
D
DE
E T
TE
EM
MP
PO
O R
RE
EA
AL
L monitora, analisa e controla eventos do
mundo real
C
CO
OM
ME
ER
RC
CI
IA
AL
L operações comerciais e tomadas de
decisões administrativas
C
CI
IE
EN
NT
TÍ
ÍF
FI
IC
CO
O E
E D
DE
E
E
EN
NG
GE
EN
NH
HA
AR
RI
IA
A
algoritmos de processamento de números
E
EM
MB
BU
UT
TI
ID
DO
O controla produtos e sistemas de mercados
industriais e de consumo
D
DE
E C
CO
OM
MP
PU
UT
TA
AD
DO
OR
R
P
PE
ES
SS
SO
OA
AL
L
processamento de textos, planilhas
eletrônicas, diversões, etc.
D
DE
E I
IN
NT
TE
EL
LI
IG
GÊ
ÊN
NC
CI
IA
A
A
AR
RT
TI
IF
FI
IC
CI
IA
AL
L
algoritmos não numéricos para resolver
problemas que não sejam favoráveis à
computação ou à análise direta
Evolução do Software
(1950 - 1965)
 O hardware sofreu contínuas mudanças
 O software era uma arte "secundária" para a
qual havia poucos métodos sistemáticos
 O hardware era de propósito geral
 O software era específico para cada aplicação
 Não havia documentação
Evolução do Software
(1965 - 1975)
 Multiprogramação e sistemas multiusuários
 Técnicas interativas
 Sistemas de tempo real
 1a geração de SGBD’s
 Produto de 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
..... CRISE DE SOFTWARE (aflição crônica???)
Evolução do Software
(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
..... 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 freqüentemente
são imprecisas
“Não dedicamos tempo para coletar dados sobre o
processo de desenvolvimento de software”
“Sem nenhuma indicação sólida de produtividade, não
podemos avaliar com precisão a eficácia de novas
ferramentas, métodos ou padrões”
Crise de Software
(2) A produtividade das pessoas da área de software
não tem acompanhado a demanda por seus
serviços
“Os projetos de desenvolvimento de software
normalmente são efetuados apenas com um vago
indício das exigências do cliente”
Crise de Software
(3) A qualidade de software às vezes é menos que
adequada
Só recentemente começam a surgir conceitos
quantitativos sólidos de garantia de qualidade de
software
(4) O software existente é muito difícil de manter
A tarefa de manutenção devora o orçamento destinado
ao software
A facilidade de manutenção não foi enfatizada como
um critério importante
Crise de Software
estimativas de prazo e de custo 
produtividade das pessoas 
qualidade de software 
software difícil de manter 
Causas dos problemas associados à
Crise de Software
1. próprio caráter do Software
O software é um elemento de sistema lógico e
não físico (produto intangível)
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!!!
2. falhas das pessoas responsáveis pelo
desenvolvimento de Software
Gerentes sem nenhum background em
software
Os profissionais da área de software têm
recebido pouco treinamento formal em novas
técnicas para o desenvolvimento de software
Resistência a mudanças.
Causas dos problemas associados à
Crise de Software
3. mitos do Software
propagaram desinformação e confusão
administrativos
cliente
profissional
Causas dos problemas associados à
Crise de Software
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?
Meu pessoal tem ferramentas de desenvolvimento de
software de última geração; afinal lhes compramos
os mais novos computadores.
Mitos do Software (administrativos)
Realidade:
É preciso muito mais do que os mais recentes
computadores para se fazer um desenvolvimento de
software de alta qualidade.
Se nós estamos atrasados nos prazos, podemos
adicionar mais programadores e tirar o atraso.
Mitos do Software (administrativos)
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.
Uma declaração geral dos objetivos é suficiente
para se começar a escrever programas -
podemos preencher os detalhes mais tarde.
Mitos do Software (cliente)
Realidade:
Uma definição inicial ruim é a principal causa de fracassos dos
esforços de desenvolvimento de software.
É fundamental uma descrição formal e detalhada do domínio da
informação, função, desempenho, interfaces, restrições de
projeto e critérios de validação.
Os requisitos de projeto modificam-se
continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é
flexível.
Mitos do Software (cliente)
Realidade:
Uma mudança, quando solicitada tardiamente num projeto,
pode ser maior do que mais do que uma ordem de magnitude
mais dispendiosa do que a mesma mudança solicitada nas
fases iniciais.
FASES CUSTO DE MANUTENÇÃO
DEFINIÇÃO 1 x
DESENVOLVIMENTO 1.5 - 6x
MANUTENÇÃO 60 - 100x
magnitude das mudanças
Assim que escrevermos o programa e o colocarmos
em funcionamento nosso trabalho estará completo.
Mitos do Software (profissional)
Realidade:
Os dados da indústria indicam que entre 50 e 70% de todo
esforço gasto num programa serão despendidos depois que
ele for entregue pela primeira vez ao cliente.
Enquanto não tiver o programa "funcionando", eu
não terei realmente nenhuma maneira de avaliar
sua qualidade.
Mitos do Software (profissional)
Realidade:
Um programa funcionando é somente uma parte de uma
Configuração de Software que inclui todos os itens de
informação produzidos durante a construção e manutenção do
software.
Preocupação: Sistematizar o processo de
criação e manutenção de software.
 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
tecnologica 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
Definições
abrange um conjunto de três elementos fundamentais:
Métodos, Ferramentas e Procedimentos
Principais metas: melhorar a qualidade de
produtos de software, aumentar a
produtividade do pessoal técnico e aumentar
a satisfação do cliente.
métodos: proporcionam os detalhes de
como fazer para construir o 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
 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
 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
conjunto de etapas que envolve
métodos
ferramentas
procedimentos
Essas etapas são conhecidas como componentes de
CICLO DE VIDA DE SOFTWARE
ou Processo de Software
Engenharia de Software
Alguns ciclos de vida mais conhecidos são:
 Ciclo de Vida Clássico
 Prototipação
 Modelo Espiral
 Técnicas de 4a Geração
Engenharia de Software
para escolha de um Ciclo de Vida de Software:
 natureza do projeto e da aplicação
 métodos e ferramentas a serem usados
 controles e produtos que precisam ser
entregues
Ciclo de Vida Clássico (Cascata)
 modelo mais antigo e o mais amplamente
usado da engenharia de software
 modelado em função do ciclo da engenharia
convencional
 requer uma abordagem sistemática,
seqüencial ao desenvolvimento de software
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Cascata
Atividades do Ciclo de Vida Clássico
ANÁLISE E ENGENHARIA DE
SISTEMAS
 envolve a coleta de requisitos em
nível do sistema, pequena
quantidade de projeto e análise
de alto nível
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção  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
ANÁLISE DE REQUISITOS DE
SOFTWARE
 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
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
 se concentra em 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
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 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
Clássico (comentários)
Prototipação
 processo que possibilita que o desenvolvedor crie
um modelo do software que deve ser construído.
 idealmente, o modelo (protótipo) serve como um
mecanismo para identificar os requisitos de
software.
 apropriado para quando o cliente definiu um
conjunto de objetivos gerais para o software, mas
não identificou requisitos de entrada,
processamento e saída com detalhes.
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção
dos
requisitos
Prototipação
Atividades da Prototipação
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)
fim
início
construção
produto
refinamento
protótipo
avaliação
protótipo
construção
protótipo
projeto
rápido
obtenção
dos
requisitos
Construção Protótipo:
implementação do projeto
rápido
Avaliação do Protótipo:
cliente e desenvolvedor avaliam
o protótipo
Atividades da 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
requisitos
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.
Atividades da 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
requisitos
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.
Atividades da 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
requisitos
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.
Problemas com a Prototipação
desenvolvedor freqüentemente faz uma
implementação comprometida (utilizando o que
está disponível) com o objetivo de produzir
rapidamente um protótipo. Depois de um tempo ele
familiariza com essas escolhas, e esquece que elas não
são apropriadas para o produto final.
Ainda que possam ocorrer problemas, a prototipação
é 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 
Prototipação (comentários)
Ciclo de Vida em Espiral
 engloba as melhores características do ciclo de vida
Clássico e da Prototipação, adicionando um novo
elemento: a Análise de Risco
 segue a abordagem de passos sistemáticos do Ciclo de
Vida Clássico incorporando-os numa estrutura iterativa que
reflete mais realisticamente o mundo real
 usa a Prototipação, em qualquer etapa da evolução do
produto, como mecanismo de redução de riscos
decisão de continuar ou não
direção de um
sistema
concluído
avaliação
do cliente engenharia
análise dos
riscos
planejamento
Espiral
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
avaliação
do
cliente
engenharia
análise dos
riscos
planejamento
 é, atualmente, a abordagem mais realística para o
desenvolvimento de software em grande escala.
 usa uma abordagem que capacita o desenvolvedor e o
cliente a entender e reagir aos riscos em cada etapa
evolutiva.
 pode ser difícil convencer os clientes que uma abordagem
"evolutiva" é controlável
 exige considerável experiência na determinação de riscos
e depende dessa experiência para ter sucesso
Espiral (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.
Espiral (comentários)
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
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementação
usando 4GL
Testes
Técnicas de 4a Geração
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
1. obtenção dos Requisitos:
o cliente descreve os requisitos
os quais são traduzidos para um
protótipo operacional
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
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"
2. estratégia de "Projeto":
para pequenas aplicações é
possível mover-se do passo de
Obtenção dos Requisitos para o
passo de Implementação usando
uma Linguagem de 4G
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
Atividades das Técnicas de 4a 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)
3. implementação usando
4GL: os resultados desejados
são representados de modo que
haja geração automática de
código . Deve existir uma
estrutura de dados com
informações relevantes e que
seja acessível pela 4GL
Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
4. teste: o desenvolvedor
deve efetuar testes e
desenvolver uma
documentação significativa.
O software desenvolvido
deve ser construído de
maneira que a manutenção
possa ser efetuada
prontamente.
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
Técnicas de 4a Geração (comentários)
Mudança na natureza de desenvolvimento de
software
métodos
convencionais
aplicação de
técnicas de 4a
Geração
demanda
global
demanda
por
software
1970 1980 1990 2000
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
manutenção
protomodelagem
no. interação
protomodelagem
no. interação
técnicas
4G
modelo espiral
no. interação
sistema completo
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:
1. DEFINIÇÃO,
2. DESENVOLVIMENTO e
3. MANUTENÇÃO.
1. Revisões
2. Documentação
3. Controle de
Mudanças
C
C
Co
o
on
n
ns
s
st
t
tr
r
ru
u
uç
ç
çã
ã
ão
o
o
1. Entender
2. Modificar
3. Revalidar
Manutenção
“mudanças”
O
O
Op
p
pe
e
er
r
ra
a
aç
ç
çã
ã
ão
o
o
S
S
SO
O
OF
F
FT
T
TW
W
WA
A
AR
R
RE
E
E
P
P
PR
R
RO
O
OD
D
DU
U
UT
T
TO
O
O
A
A
At
t
ti
i
iv
v
vi
i
id
d
da
a
ad
d
de
e
es
s
s d
d
de
e
e A
A
Ap
p
po
o
oi
i
io
o
o
1. Análise de
Sistema
2. Planejamento
do Projeto
3. Análise de
Requisitos
Definição
“o que” Desenvolvimento
“como”
1. Projeto de
Software
2. Codificação
3. Teste

 
 
Engenharia de Software uma visão genérica
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.
Engenharia de Software uma visão genérica
 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.
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
algorítmicos e as características de interface.
Engenharia de Software uma visão genérica
 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.
Engenharia de Software uma visão genérica
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
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.
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.
Engenharia de Software uma visão genérica
Atividades de Proteção: as fases e etapas correlatas
descritas são complementadas por uma série de
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.
Engenharia de Software uma visão genérica
A Engenharia de Software também se preocupa com
questões gerenciais, que encontra-se do lado oposto
ao domínio da programação
Gerenciamento: necessário para coordenar as
atividades técnicas em projetos de produtos de
software.
Engenharia de Software uma aborgagem
gerencial
Em geral, um produto de software inclui:
-> Código fonte, e documentação relacionada:
 documento de requisitos
 especificação do projeto
 planos de teste
 princípios de operação
 procedimentos para garantia da qualidade
Engenharia de Software uma aborgagem
gerencial
Em geral, um produto de software inclui:
-> Cogido fonte, e documentação relacionada:
 relatórios de problemas com o software
 procedimentos de manutenção
 manuais do usuário
 instruções para instalação
 auxílio para treinamento
Engenharia de Software uma aborgagem
gerencial
Qualidade de software : preocupação principal dos
gerentes de software.
-> Principal atributo de qualidade: utilidade
-> outros atributos de qualidade:
- transportabilidade
- eficiência
- clareza
- confiabilidade
Engenharia de Software uma aborgagem
gerencial
Fatore de Qualidade e Produtividade :
Fatores que influenciam a qualidade:
 Habilidade Individual
 Comunicação da equipe
 Complexidade do produto
 Notações apropriadas
 Abordagens sistemáticas
 controle de mudanças
Engenharia de Software uma aborgagem
gerencial
Fatore de Qualidade e Produtividade :
Fatores que influenciam a qualidade:
 Adequação de treinamento
 Habilidades de gerenciamento
 Metas apropriadas
 Entendimento do problema
 Estabilidade dos requisitos
 Habilidades necessárias
Engenharia de Software uma aborgagem
gerencial
Questões gerenciais
Os gerentes de software:
 controlam os recursos e o ambiente no qual as atividades
técnicas ocorrem.
 responsáveis pela entrega do produto no prazo e dentro das
estimativas de custo.
 devem garantir que o produto tenha os atributos funcionais e
de qualidade desejados pelo cliente.
 Treinam empregados.
 desenvolvem planos e estratégias de marketing.
Engenharia de Software uma aborgagem
gerencial
Preocupações de gerenciamento de projeto:
 métodos para organizar e monitorar um projeto.
 técnicas de estimativa de custo.
 política de alocação de recursos.
 controle orçamentário.
 avaliação do progresso.
 realocação de recursos.
 ajustes no cronograma.
Engenharia de Software uma aborgagem
gerencial
Preocupações de gerenciamento de projeto:
 estabelecer procedimentos para garantia de qualidade.
 manter o controle de várias versões do produto.
 facilitar a comunicação entre os membros do projeto.
 comunicação com o cliente.
 estabelecer contratos com o cliente.
 garantir que os termos legais e contratuais do projeto sejam
cumpridos.
Engenharia de Software uma aborgagem
gerencial
Problemas na área de gerenciamento:
 falta de planejamento para projetos de software.
 falta de técnicas e procedimentos para selecionar gerentes de
projeto.
 falta de habilidade em estimar os recursos necessários para o
projeto.
 falta de um processo de desenvolvimento bem estabelecido.
 falta de estratégias para o gerente acompanhar o progresso
do projeto.
 falta de padrões e técnicas para medir produtividade.
Engenharia de Software uma aborgagem
gerencial
Fatores que melhoram o gerenciamento:
 treinar gerentes, e desenvolvedores de software.
 estabelecer o uso de padrões, procedimentos e
documentação.
 analisar dados de projetos passados para avaliar métodos
efetivos.
 definir objetivos em termos de qualidade desejada.
 definir qualidade em termos de produtos a ser entregues.
 Selecionar gerentes de projetos com habilidades para
gerenciamento.
 Desenvolver uma maneira de avaliar os desenvolvedores de
software.
Engenharia de Software uma aborgagem
gerencial
Conclusão
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]
Pontos a ponderar
 O software é o fator de diferenciação de muitos produtos e sistemas
baseados em computador. Apresente exemplos de dois ou três produtos e
de pelo menos um sistema em que o software, não o hardware, é o elemento
que faz a diferença.
 Nas décadas de 1950 e 1960, a programação de computador era uma forma
de arte aprendida num ambiente semelhante ao de aprendizes. Como os
primórdios afetaram as práticas de desenvolvimento de software atuais?
 Apresente cinco exemplos de desenvolvimento de software que seriam
adequados à prototipação. Cite duas ou três aplicações que seriam mais
difíceis de ser representadas em protótipos.
,
Pontos a ponderar
 Os mitos de software citados em aula são somente alguns entre muitos
outros. Liste mitos adicionais para cada uma das categorias apresentadas.
 Existe algum caso em que as fases genéricas do processo de engenharia de
software não se aplicam? Se assim for, descreva-o.
,

Mais conteúdo relacionado

Semelhante a Engenharia de software

Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
Nécio de Lima Veras
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Cris Fidelix
 
1 Qss
1 Qss1 Qss
1 Qss
lcbj
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
DevOps e App Insights
DevOps e App InsightsDevOps e App Insights
DevOps e App Insights
Guilherme Cardoso
 
Ciclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de SoftwareCiclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de Software
Eduardo Santos
 
Crise de software2
Crise de software2Crise de software2
Crise de software2
Tiago Pinhão
 
Senac QSS - 1) Intro
Senac QSS - 1) IntroSenac QSS - 1) Intro
Senac QSS - 1) Intro
lcbj
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
DevOps... O caminho! - Monitoramento de aplicações com App Insights
DevOps... O caminho! - Monitoramento de aplicações com App InsightsDevOps... O caminho! - Monitoramento de aplicações com App Insights
DevOps... O caminho! - Monitoramento de aplicações com App Insights
Adriano Bertucci
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
Erivelton Silva Rocha
 
Aula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdfAula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdf
Jadna Almeida
 
Aula 1 introdução à engenharia de software1 (1)
Aula 1   introdução à engenharia de software1 (1)Aula 1   introdução à engenharia de software1 (1)
Aula 1 introdução à engenharia de software1 (1)
Tiago Vizoto
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
EnricoGerezCamponoga
 
modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3
spawally
 
Analise aula2
Analise aula2Analise aula2
Analise aula2
Kelvin Wesley
 
152191 11993
152191 11993152191 11993
152191 11993
Junior Abs
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
Danilo Gois
 
Engenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - IntroEngenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - Intro
Rudson Kiyoshi Souza Carvalho
 
Qualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual StudioQualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual Studio
Adriano Bertucci
 

Semelhante a Engenharia de software (20)

Introdução à Engenharia de Software
Introdução à Engenharia de SoftwareIntrodução à Engenharia de Software
Introdução à Engenharia de Software
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
1 Qss
1 Qss1 Qss
1 Qss
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
DevOps e App Insights
DevOps e App InsightsDevOps e App Insights
DevOps e App Insights
 
Ciclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de SoftwareCiclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de Software
 
Crise de software2
Crise de software2Crise de software2
Crise de software2
 
Senac QSS - 1) Intro
Senac QSS - 1) IntroSenac QSS - 1) Intro
Senac QSS - 1) Intro
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
DevOps... O caminho! - Monitoramento de aplicações com App Insights
DevOps... O caminho! - Monitoramento de aplicações com App InsightsDevOps... O caminho! - Monitoramento de aplicações com App Insights
DevOps... O caminho! - Monitoramento de aplicações com App Insights
 
Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1Aula 03 de engenharia de software uespi 2011-1
Aula 03 de engenharia de software uespi 2011-1
 
Aula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdfAula 01 e 02 - Engenharia de Software.pdf
Aula 01 e 02 - Engenharia de Software.pdf
 
Aula 1 introdução à engenharia de software1 (1)
Aula 1   introdução à engenharia de software1 (1)Aula 1   introdução à engenharia de software1 (1)
Aula 1 introdução à engenharia de software1 (1)
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
 
modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3modelagem sistema da informação Unid 3
modelagem sistema da informação Unid 3
 
Analise aula2
Analise aula2Analise aula2
Analise aula2
 
152191 11993
152191 11993152191 11993
152191 11993
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
Engenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - IntroEngenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - Intro
 
Qualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual StudioQualidade de Software com Microsoft Visual Studio
Qualidade de Software com Microsoft Visual Studio
 

Último

AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL  INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL  INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
Consultoria Acadêmica
 
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
carlos silva Rotersan
 
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
Consultoria Acadêmica
 
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptxMAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
Vilson Stollmeier
 
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
Consultoria Acadêmica
 
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
Consultoria Acadêmica
 
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptxWorkshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
marcosmpereira
 

Último (7)

AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL  INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL  INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL INDÚSTRIA E TRANSFORMAÇÃO DIGITAL ...
 
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
Grau TÉCNICO EM SEGURANÇA DO TRABALHO I - LEGISLAÇÃO APLICADA À SAÚDE E SEGUR...
 
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
AE02 - FORMAÇÃO SOCIOCULTURAL E ÉTICA II UNICESUMAR 52/2024
 
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptxMAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
MAQUINAS-EQUIPAMENTOS-E-FERRAMENTAS.pptx
 
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
AE03 - ESTUDO CONTEMPORÂNEO E TRANSVERSAL ENGENHARIA DA SUSTENTABILIDADE UNIC...
 
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
AE03 - MATERIAIS DA CONSTRUÇÃO MECÂNICA UNICESUMAR 52/2024
 
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptxWorkshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
Workshop Gerdau 2023 - Soluções em Aço - Resumo.pptx
 

Engenharia de software

  • 1. Engenharia de Software Prof. Inês Ap. Gasparotto Boaventura 1. Semestre/2001
  • 2. Tópicos 1- Introdução à Engenharia de Software 2 - Fundamentos Organizacionais de Sistemas de Informação 3- Gerência de projeto de software 4- Gerenciamento para a qualidade de software 5- Acompanhamento do processo de desenvolvimento de software.
  • 3. 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
  • 4. 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
  • 5. Curva de falhas para o Hardware tempo “desgaste” “mortalidade infantil” índice de falhas
  • 6. Curva de falhas do Software índice de falhas mudança curva real curva idealizada tempo
  • 7. Aplicações do Software B BÁ ÁS SI IC CO O programas de apoio a outros programas D DE E T TE EM MP PO O R RE EA AL L monitora, analisa e controla eventos do mundo real C CO OM ME ER RC CI IA AL L operações comerciais e tomadas de decisões administrativas C CI IE EN NT TÍ ÍF FI IC CO O E E D DE E E EN NG GE EN NH HA AR RI IA A algoritmos de processamento de números E EM MB BU UT TI ID DO O controla produtos e sistemas de mercados industriais e de consumo D DE E C CO OM MP PU UT TA AD DO OR R P PE ES SS SO OA AL L processamento de textos, planilhas eletrônicas, diversões, etc. D DE E I IN NT TE EL LI IG GÊ ÊN NC CI IA A A AR RT TI IF FI IC CI IA AL L algoritmos não numéricos para resolver problemas que não sejam favoráveis à computação ou à análise direta
  • 8. 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
  • 9. 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
  • 10. 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 ..... CRISE DE SOFTWARE (aflição crônica???)
  • 11. Evolução do Software (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 ..... CRISE DE SOFTWARE (aflição crônica???)
  • 12. 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 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”
  • 13. 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”
  • 14. 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
  • 15. Crise de Software estimativas de prazo e de custo  produtividade das pessoas  qualidade de software  software difícil de manter 
  • 16. Causas dos problemas associados à Crise de Software 1. próprio caráter do Software O software é um elemento de sistema lógico e não físico (produto intangível) 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!!!
  • 17. 2. falhas das pessoas responsáveis pelo desenvolvimento de Software Gerentes sem nenhum background em software Os profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças. Causas dos problemas associados à Crise de Software
  • 18. 3. mitos do Software propagaram desinformação e confusão administrativos cliente profissional Causas dos problemas associados à Crise de Software
  • 19. 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?
  • 20. Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes compramos os mais novos computadores. Mitos do Software (administrativos) Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade.
  • 21. Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. Mitos do Software (administrativos) 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.
  • 22. Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos preencher os detalhes mais tarde. Mitos do Software (cliente) Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. É fundamental uma descrição formal e detalhada do domínio da informação, função, desempenho, interfaces, restrições de projeto e critérios de validação.
  • 23. Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. Mitos do Software (cliente) Realidade: Uma mudança, quando solicitada tardiamente num projeto, pode ser maior do que mais do que uma ordem de magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais.
  • 24. FASES CUSTO DE MANUTENÇÃO DEFINIÇÃO 1 x DESENVOLVIMENTO 1.5 - 6x MANUTENÇÃO 60 - 100x magnitude das mudanças
  • 25. Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo. Mitos do Software (profissional) Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente.
  • 26. Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua qualidade. Mitos do Software (profissional) Realidade: Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos durante a construção e manutenção do software.
  • 27. Preocupação: Sistematizar o processo de criação e manutenção de software.
  • 28.  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
  • 29.  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
  • 30.  Fairley: Engenharia de software é a disciplina tecnologica 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 Definições
  • 31. abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Procedimentos Principais metas: melhorar a qualidade de produtos de software, aumentar a produtividade do pessoal técnico e aumentar a satisfação do cliente.
  • 32. métodos: proporcionam os detalhes de como fazer para construir o software Engenharia de Software
  • 33.  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 Engenharia de Software
  • 34. 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
  • 35. 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
  • 36. conjunto de etapas que envolve métodos ferramentas procedimentos Essas etapas são conhecidas como componentes de CICLO DE VIDA DE SOFTWARE ou Processo de Software Engenharia de Software
  • 37. Alguns ciclos de vida mais conhecidos são:  Ciclo de Vida Clássico  Prototipação  Modelo Espiral  Técnicas de 4a Geração Engenharia de Software
  • 38. para escolha de um Ciclo de Vida de Software:  natureza do projeto e da aplicação  métodos e ferramentas a serem usados  controles e produtos que precisam ser entregues
  • 39. 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
  • 41. Atividades do Ciclo de Vida Clássico ANÁLISE E ENGENHARIA DE SISTEMAS  envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção  visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados)
  • 42. Atividades do Ciclo de Vida Clássico ANÁLISE DE REQUISITOS DE SOFTWARE  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 Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  • 43. 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 Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  • 44. 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
  • 45. 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
  • 46. Atividades do Ciclo de Vida Clássico MANUTENÇÃO  o software deverá sofrer mudanças depois que for entregue ao cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção  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
  • 47. 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
  • 48. Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software Clássico (comentários)
  • 49. Prototipação  processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.  idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software.  apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.
  • 51. 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) fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos
  • 52. Construção Protótipo: implementação do projeto rápido Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo Atividades da 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 requisitos
  • 53. 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. Atividades da 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 requisitos
  • 54. 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. Atividades da 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 requisitos
  • 55. 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.
  • 56. Problemas com a Prototipação desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final.
  • 57. 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  Prototipação (comentários)
  • 58. 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
  • 59. decisão de continuar ou não direção de um sistema concluído avaliação do cliente engenharia análise dos riscos planejamento Espiral
  • 60. 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 avaliação do cliente engenharia análise dos riscos planejamento
  • 61.  é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.  usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.  pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável  exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso Espiral (comentários)
  • 62.  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. Espiral (comentários)
  • 63. 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
  • 65. 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
  • 66. Atividades das Técnicas de 4a Geração 1. obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional Obtenção dos Requisitos Estratégia do “Projeto” Implementaçã o usando 4GL Testes 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"
  • 67. 2. estratégia de "Projeto": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G Obtenção dos Requisitos Estratégia do “Projeto” Implementaçã o usando 4GL Testes Atividades das Técnicas de 4a 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)
  • 68. 3. implementação usando 4GL: os resultados desejados são representados de modo que haja geração automática de código . Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL Atividades das Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do “Projeto” Implementaçã o usando 4GL Testes
  • 69. Atividades das Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do “Projeto” Implementaçã o usando 4GL Testes 4. teste: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
  • 70. 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 Técnicas de 4a Geração (comentários)
  • 71. Mudança na natureza de desenvolvimento de software métodos convencionais aplicação de técnicas de 4a Geração demanda global demanda por software 1970 1980 1990 2000
  • 72. 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 manutenção protomodelagem no. interação protomodelagem no. interação técnicas 4G modelo espiral no. interação sistema completo
  • 73. 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: 1. DEFINIÇÃO, 2. DESENVOLVIMENTO e 3. MANUTENÇÃO.
  • 74. 1. Revisões 2. Documentação 3. Controle de Mudanças C C Co o on n ns s st t tr r ru u uç ç çã ã ão o o 1. Entender 2. Modificar 3. Revalidar Manutenção “mudanças” O O Op p pe e er r ra a aç ç çã ã ão o o S S SO O OF F FT T TW W WA A AR R RE E E P P PR R RO O OD D DU U UT T TO O O A A At t ti i iv v vi i id d da a ad d de e es s s d d de e e A A Ap p po o oi i io o o 1. Análise de Sistema 2. Planejamento do Projeto 3. Análise de Requisitos Definição “o que” Desenvolvimento “como” 1. Projeto de Software 2. Codificação 3. Teste      Engenharia de Software uma visão genérica
  • 75. 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. Engenharia de Software uma visão genérica
  • 76.  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. Engenharia de Software uma visão genérica
  • 77. 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 algorítmicos e as características de interface. Engenharia de Software uma visão genérica
  • 78.  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. Engenharia de Software uma visão genérica
  • 79. 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 Engenharia de Software uma visão genérica
  • 80. 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. Engenharia de Software uma visão genérica
  • 81. 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 uma visão genérica
  • 82. Atividades de Proteção: as fases e etapas correlatas descritas são complementadas por uma série de 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. Engenharia de Software uma visão genérica
  • 83. A Engenharia de Software também se preocupa com questões gerenciais, que encontra-se do lado oposto ao domínio da programação Gerenciamento: necessário para coordenar as atividades técnicas em projetos de produtos de software. Engenharia de Software uma aborgagem gerencial
  • 84. Em geral, um produto de software inclui: -> Código fonte, e documentação relacionada:  documento de requisitos  especificação do projeto  planos de teste  princípios de operação  procedimentos para garantia da qualidade Engenharia de Software uma aborgagem gerencial
  • 85. Em geral, um produto de software inclui: -> Cogido fonte, e documentação relacionada:  relatórios de problemas com o software  procedimentos de manutenção  manuais do usuário  instruções para instalação  auxílio para treinamento Engenharia de Software uma aborgagem gerencial
  • 86. Qualidade de software : preocupação principal dos gerentes de software. -> Principal atributo de qualidade: utilidade -> outros atributos de qualidade: - transportabilidade - eficiência - clareza - confiabilidade Engenharia de Software uma aborgagem gerencial
  • 87. Fatore de Qualidade e Produtividade : Fatores que influenciam a qualidade:  Habilidade Individual  Comunicação da equipe  Complexidade do produto  Notações apropriadas  Abordagens sistemáticas  controle de mudanças Engenharia de Software uma aborgagem gerencial
  • 88. Fatore de Qualidade e Produtividade : Fatores que influenciam a qualidade:  Adequação de treinamento  Habilidades de gerenciamento  Metas apropriadas  Entendimento do problema  Estabilidade dos requisitos  Habilidades necessárias Engenharia de Software uma aborgagem gerencial
  • 89. Questões gerenciais Os gerentes de software:  controlam os recursos e o ambiente no qual as atividades técnicas ocorrem.  responsáveis pela entrega do produto no prazo e dentro das estimativas de custo.  devem garantir que o produto tenha os atributos funcionais e de qualidade desejados pelo cliente.  Treinam empregados.  desenvolvem planos e estratégias de marketing. Engenharia de Software uma aborgagem gerencial
  • 90. Preocupações de gerenciamento de projeto:  métodos para organizar e monitorar um projeto.  técnicas de estimativa de custo.  política de alocação de recursos.  controle orçamentário.  avaliação do progresso.  realocação de recursos.  ajustes no cronograma. Engenharia de Software uma aborgagem gerencial
  • 91. Preocupações de gerenciamento de projeto:  estabelecer procedimentos para garantia de qualidade.  manter o controle de várias versões do produto.  facilitar a comunicação entre os membros do projeto.  comunicação com o cliente.  estabelecer contratos com o cliente.  garantir que os termos legais e contratuais do projeto sejam cumpridos. Engenharia de Software uma aborgagem gerencial
  • 92. Problemas na área de gerenciamento:  falta de planejamento para projetos de software.  falta de técnicas e procedimentos para selecionar gerentes de projeto.  falta de habilidade em estimar os recursos necessários para o projeto.  falta de um processo de desenvolvimento bem estabelecido.  falta de estratégias para o gerente acompanhar o progresso do projeto.  falta de padrões e técnicas para medir produtividade. Engenharia de Software uma aborgagem gerencial
  • 93. Fatores que melhoram o gerenciamento:  treinar gerentes, e desenvolvedores de software.  estabelecer o uso de padrões, procedimentos e documentação.  analisar dados de projetos passados para avaliar métodos efetivos.  definir objetivos em termos de qualidade desejada.  definir qualidade em termos de produtos a ser entregues.  Selecionar gerentes de projetos com habilidades para gerenciamento.  Desenvolver uma maneira de avaliar os desenvolvedores de software. Engenharia de Software uma aborgagem gerencial
  • 94. Conclusão 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]
  • 95. Pontos a ponderar  O software é o fator de diferenciação de muitos produtos e sistemas baseados em computador. Apresente exemplos de dois ou três produtos e de pelo menos um sistema em que o software, não o hardware, é o elemento que faz a diferença.  Nas décadas de 1950 e 1960, a programação de computador era uma forma de arte aprendida num ambiente semelhante ao de aprendizes. Como os primórdios afetaram as práticas de desenvolvimento de software atuais?  Apresente cinco exemplos de desenvolvimento de software que seriam adequados à prototipação. Cite duas ou três aplicações que seriam mais difíceis de ser representadas em protótipos. ,
  • 96. Pontos a ponderar  Os mitos de software citados em aula são somente alguns entre muitos outros. Liste mitos adicionais para cada uma das categorias apresentadas.  Existe algum caso em que as fases genéricas do processo de engenharia de software não se aplicam? Se assim for, descreva-o. ,