Você está na página 1de 96

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

“mortalidade “desgaste”
índice
de infantil”
falhas

tempo
Curva de falhas do Software

curva real
índice de
mudança
falhas

curva idealizada

tempo
Aplicações do 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 processamento de textos, planilhas
PESSOAL eletrônicas, diversões, etc.
DE INTELIGÊNCIA algoritmos não numéricos para resolver
ARTIFICIAL 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)
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!!!
Causas dos problemas associados à
Crise de Software

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
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:
Realidade:
Será
Seráque
queoomanual
manualééusado?
usado?
Os
Osprofissionais
profissionaissabem
sabemque
queele
eleexiste?
existe?
Ele
Elereflete
refleteaaprática
práticamoderna
modernadededesenvolvimento
desenvolvimentode
desoftware?
software?
Ele
Eleéécompleto?
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:
Realidade:
ÉÉpreciso
precisomuito
muitomais
maisdodoque
queos
osmais
maisrecentes
recentes
computadores
computadorespara
parase
sefazer
fazerum
umdesenvolvimento
desenvolvimentode
de
software
softwarede
dealta
altaqualidade.
qualidade.
Mitos do Software (administrativos)

Se nós estamos atrasados nos prazos, podemos


adicionar mais programadores e tirar o atraso.

Realidade:
Realidade:
OOdesenvolvimento
desenvolvimentode
desoftware
softwarenão
nãoééumumprocesso
processomecânico
mecânico
igual
igualààmanufatura.
manufatura.
Acrescentar
Acrescentarpessoas
pessoasememum
umprojeto
projetotorna-o
torna-oainda
aindamais
mais
atrasado.
atrasado.Pessoas
Pessoaspodem
podemser
seracrescentadas,
acrescentadas,mas
massomente
somentede
de
uma
umaforma
formaplanejada.
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:
Realidade:
Uma
Umadefinição
definiçãoinicial
inicialruim
ruimééaaprincipal
principalcausa
causadedefracassos
fracassosdos
dos
esforços
esforçosde dedesenvolvimento
desenvolvimentode desoftware.
software.
ÉÉfundamental
fundamentaluma umadescrição
descriçãoformal
formaleedetalhada
detalhadadododomínio
domínioda
da
informação,
informação,função,
função,desempenho,
desempenho,interfaces,
interfaces,restrições
restriçõesde
deprojeto
projetoee
critérios
critériosde
devalidação.
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:
Realidade:
Uma
Umamudança,
mudança,quando
quandosolicitada
solicitadatardiamente
tardiamentenumnumprojeto,
projeto,pode
pode
ser
sermaior
maiordo
doque
quemais
maisdo
doque
queumaumaordem
ordemde
demagnitude
magnitudemais
mais
dispendiosa
dispendiosado
doque
queaamesma
mesmamudança
mudançasolicitada
solicitadanas
nasfases
fasesiniciais.
iniciais.
magnitude 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:
Realidade:
Os
Osdados
dadosda
daindústria
indústriaindicam
indicamque
queentre
entre50
50ee70%
70%de
detodo
todoesforço
esforço
gasto
gastonum
numprograma
programaserão
serãodespendidos
despendidosdepois
depoisque
queele
elefor
for
entregue
entreguepela
pelaprimeira
primeiravez
vezao
aocliente.
cliente.
Mitos do Software (profissional)

Enquanto não tiver o programa "funcionando", eu não


terei realmente nenhuma maneira de avaliar sua
qualidade.

Realidade:
Realidade:
Um
Umprograma
programafuncionando
funcionandoéésomente
somenteuma umaparte
partededeuma
uma
Configuração
Configuraçãode
deSoftware
Softwareque
queinclui
incluitodos
todosos
ositens
itensde
deinformação
informação
produzidos
produzidosdurante
duranteaaconstrução
construçãoeemanutenção
manutençãodo dosoftware.
software.
Preocupação: Sistematizar o processo de
criação e manutenção de software.
Engenharia de Software
Definições

 Boehm: Engenharia de software envolve a


aplicação prática de conhecimento científico para
o projeto e construção de programas de
computador e a documentação associada
necessária para desenvolvê-los, operá-los e
mantê-los.
Engenharia de Software
Definições

 IEEE Standard Glossary of Software Engineering


terminology: Engenharia de software é uma
abordagem sistemática para o desenvolvimento,
operação, manutenção de software

Software: programas de computador,


procedimentos, regras, documentação
possivelmente associada, e dados sobre sua
operação.
Engenharia de Software
Definições

 Fairley: Engenharia de software é a disciplina


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.
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.
Engenharia de Software

métodos:
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:
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:
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
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
Cascata

Engenhariade
Engenharia de
Sistemas
Sistemas
Análise de
Análise de
Requisitos
Requisitos
Projeto
Projeto
Codificação
Codificação
Testes
Testes
Manutenção
Manutenção
Atividades do Ciclo de Vida Clássico
ANÁLISE E ENGENHARIA DE
Engenharia de SISTEMAS
Sistemas
Análise de  envolve a coleta de requisitos em
Requisitos
Projeto nível do sistema, pequena
Codificação quantidade de projeto e análise
Testes de alto nível
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
Engenharia de
Sistemas  processo de coleta dos requisitos
Análise de
Requisitos
é intensificado e concentrado
Projeto especificamente no software
Codificação
 deve-se compreender o domínio
Testes da informação, a função,
Manutenção desempenho e interfaces
exigidos
 os requisitos (para o sistema e para
o software) são documentados e
revistos com o cliente
Atividades do Ciclo de Vida Clássico
PROJETO
 tradução dos requisitos do software para
um conjunto de representações que podem
Engenharia de ser avaliadas quanto à qualidade, antes
Sistemas
Análise de que a codificação se inicie
Requisitos
Projeto  se concentra em 4 atributos do
Codificação programa:
Testes  Estrutura de Dados,

Manutenção  Arquitetura de Software,


 Detalhes Procedimentais e
 Caracterização de Interfaces
Atividades do Ciclo de Vida Clássico
CODIFICAÇÃO
 tradução das representações
do projeto para uma
Engenharia de
Sistemas linguagem “artificial”
Análise de
Requisitos resultando em instruções
Projeto
executáveis pelo computador
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
TESTES
Concentram-se:
Engenharia de
Sistemas
Análise de
 nos aspectos lógicos internos
Requisitos do software, garantindo que
Projeto
todas as instruções tenham
Codificação sido testadas
Testes
 nos aspectos funcionais
Manutenção externos, para descobrir
erros e garantir que a
entrada definida produza
resultados que concordem
com os esperados.
Atividades do Ciclo de Vida Clássico
MANUTENÇÃO

Engenharia de  o software deverá sofrer mudanças depois que for


Sistemas entregue ao cliente
Análise de
Requisitos
Projeto
Codificação  causas das mudanças:
Testes erros, adaptação do
Manutenção 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
Clássico (comentários)

Embora o Ciclo de Vida Clássico tenha


fragilidades, ele é significativamente
melhor do que uma abordagem casual
ao desenvolvimento de software
Prototipação
 processo que possibilita que o desenvolvedor crie
um modelo do software que deve ser construído.
 idealmente, o modelo (protótipo)
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.
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
início Obtenção dos Requisitos:
fim desenvolvedor e cliente definem os
obtenção
dos objetivos gerais do software, identificam
construção
requisitos
projeto quais requisitos são conhecidos e as áreas
produto rápido que necessitam de definições adicionais

refinamento construção
protótipo protótipo Projeto Rápido: representação dos
avaliação aspectos do software que são visíveis ao
protótipo
usuário (abordagens de entrada e
formatos de saída)
Atividades da Prototipação
início
fim obtenção Construção Protótipo:
dos
requisitos
implementação do projeto
construção projeto
produto rápido rápido

refinamento construção
protótipo protótipo
avaliação Avaliação do Protótipo:
protótipo
cliente e desenvolvedor avaliam
o protótipo
Atividades da Prototipação
início Refinamento dos Requisitos:
fim obtenção cliente e desenvolvedor refinam
dos
requisitos os requisitos do software a ser
construção projeto
produto rápido desenvolvido.
Ocorre neste ponto um processo
refinamento construção
protótipo protótipo de iteração que pode conduzir a
avaliação 1a. atividade até que as
protótipo
necessidades do cliente sejam
satisfeitas e o desenvolvedor
compreenda o que precisa ser
feito.
Atividades da Prototipação
início
fim obtenção
dos Construção Produto:
requisitos
construção projeto identificados os requisitos, o
produto rápido
protótipo deve ser descartado e a
construção versão de produção deve ser
refinamento
protótipo
protótipo construída considerando os
avaliação
protótipo critérios de qualidade.
Problemas com a Prototipação

 clientenã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.
Prototipação (comentários)

Ainda que possam ocorrer problemas, a prototipação


é um ciclo de vida eficiente 
A chave é definir-se as regras do jogo logo no
começo 
O cliente e o desenvolvedor devem ambos concordar
que o protótipo seja construído para servir como
um mecanismo a fim de definir os requisitos 
Ciclo de Vida em Espiral
 engloba as melhores características do ciclo de vida
Clássico e da Prototipação, adicionando um novo
elemento: a Análise de Risco

 segue a abordagem de passos sistemáticos do Ciclo de


Vida Clássico incorporando-os numa estrutura iterativa que
reflete mais realisticamente o mundo real
 usa a Prototipação, em qualquer etapa da evolução do
produto, como mecanismo de redução de riscos
Espiral

planejamento
análise dos
riscos

decisão de continuar ou não

direção de um
avaliação sistema
do cliente engenharia
concluído
Atividades do Ciclo de Vida em Espiral
Planejamento: determinação dos
objetivos, alternativas e restrições
planejamento
Análise de Risco: análise das análise dos
riscos
alternativas e identificação / resolução
dos riscos
Construção: desenvolvimento do avaliação
do engenharia
produto no nível seguinte cliente

Avaliação do Cliente: avaliação do


produto e planejamento das novas
fases
Espiral (comentários)
 é, 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.
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
Técnicas de 4a Geração

Obtençãodos
Obtenção dos
Requisitos
Requisitos
Estratégiado
Estratégia do
“Projeto”
“Projeto” Implementação
Implementação
usando4GL
usando 4GL
Testes
Testes
Ferramentas do ambiente de
desenvolvimento de software de 4GL
O ambiente de desenvolvimento de software que sustenta o ciclo
de vida de 4a geração inclui as ferramentas:
 linguagens não procedimentais para consulta de
banco de dados
 geração de relatórios
 manipulação de dados
 interação e definição de telas
 geração de códigos
 capacidade gráfica de alto nível
 capacidade de planilhas eletrônicas
Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia do
“Projeto”
1. obtenção dos Requisitos: o Implementação
usando 4GL
cliente descreve os requisitos os Testes
quais são traduzidos para um
protótipo operacional

o cliente pode estar inseguro quanto aos requisitos


o cliente pode ser incapaz de especificar as informações de
um modo que uma ferramenta 4GL possa consumir
as 4GLs atuais não são sofisticadas suficientemente para
acomodar a verdadeira "linguagem natural"
Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia do
2. estratégia de "Projeto": “Projeto”
Implementação
para pequenas aplicações é usando 4GL
Testes
possível mover-se do passo de
Obtenção dos Requisitos para o
passo de Implementação usando
uma Linguagem de 4G
para grandes projetos é necessário desenvolver uma
estratégia de projeto. De outro modo ocorrerão os mesmos
problemas encontrados quando se usa abordagem
convencional (baixa qualidade)
Atividades das Técnicas de 4a Geração
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementação
3. implementação usando usando 4GL
Testes
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”
4. teste: o desenvolvedor Implementação
usando 4GL
deve efetuar testes e Testes
desenvolver uma
documentação significativa.
O software desenvolvido
deve ser construído de
maneira que a manutenção
possa ser efetuada
prontamente.
Técnicas de 4a Geração (comentários)

PROPONENTES: redução dramática no tempo de


desenvolvimento do software (aumento de
produtividade)
OPONENTES as 4GL atuais não são mais fáceis de
OPONENTES:
usar do que as linguagens de programação
 o código fonte produzido é ineficiente
 a manutenibilidade de sistemas usando técnicas 4G
ainda é questionável
Mudança na natureza de desenvolvimento de
software

demanda
global
demanda aplicação de
por técnicas de 4a
software Geração

métodos
convencionais

1970 1980 1990 2000


Combinação dos Métodos de Ciclo de Vida
obtenção dos requisitos
preliminares

análise dos protomodelagem técnicas modelo espiral


requisitos 4G

projeto protomodelagem técnicas


no. interação 4G

codificação
modelo espiral
no. interação
protomodelagem
no. interação

testes

sistema completo

manutenção
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,
DEFINIÇÃO
2. DESENVOLVIMENTO e
3. MANUTENÇÃO.
MANUTENÇÃO
Engenharia de Software uma visão genérica
Construção Operação
Definição
“o que” Desenvolvimento Manutenção
1. Análise de “como” “mudanças”
SOFTWARE
Sistema 1. Projeto de  
PRODUTO 1. Entender
2. Planejamento  Software
do Projeto 2. Modificar
2. Codificação 3. Revalidar
3. Análise de
3. Teste
Requisitos

Atividades de Apoio
 1. Revisões

2. Documentação
3. Controle de
Mudanças
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:
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 aborgagem
gerencial

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.
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.