Engenharia de
Software
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
índice
de
falhas
“mortalidade
infantil”
“desgaste”
tempo
Curva de falhas do Software
curva real
índice de
falhas
mudança
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
operações comerciais e tomadas de
decisões administrativas
algoritmos de processamento de números
COMERCIAL
CIENTÍFICO E DE
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)
 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
software
sem
nenhum
background
em
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:
Será que o manual é usado?
Os profissionais sabem que ele existe?
Ele reflete a prática moderna de desenvolvimento de
software?
Ele é completo?
Mitos do Software (administrativos)
Meu
pessoal
tem
ferramentas
de
desenvolvimento de software de última geração;
afinal lhes compramos os mais novos
computadores.
Realidade:
É preciso muito mais do que os mais
recentes computadores para se fazer um
desenvolvimento de software de alta
qualidade.
Mitos do Software (administrativos)
Se nós estamos atrasados nos prazos, podemos
adicionar mais programadores e tirar o atraso.
Realidade:
O desenvolvimento de software não é um
processo mecânico igual à manufatura.
Acrescentar pessoas em um projeto torna-o
ainda mais atrasado. Pessoas podem ser
acrescentadas, mas somente de uma forma
planejada.
Mitos do Software (clientes)
Uma declaração geral dos objetivos é suficiente
para se começar a escrever programas podemos preencher os detalhes mais tarde.
Realidade:
Uma definição inicial ruim é a principal causa de
fracassos dos esforços de desenvolvimento de software.
É fundamental uma descrição formal e detalhada do
domínio da informação, função, desempenho,
interfaces, restrições de projeto e critérios de validação.
Mitos do Software (clientes)
Os requisitos de projeto modificam-se
continuamente, mas as mudanças podem ser
facilmente acomodadas, porque o software é
flexível.
Realidade:
Uma mudança, quando solicitada tardiamente
num projeto, pode ser maior do que mais do que
uma ordem de magnitude mais dispendiosa do
que a mesma mudança solicitada nas fases iniciais.
magnitude das mudanças
FASES
DEFINIÇÃO
DESENVOLVIMENTO
MANUTENÇÃO
CUSTO DE MANUTENÇÃO
1x
1.5 - 6x
60 - 100x
Mitos do Software (profissional)
Assim que escrevermos o programa e o
colocarmos em funcionamento nosso trabalho
estará completo.
Realidade:
Os dados da indústria indicam que entre 50 e 70%
de todo esforço gasto num programa serão
despendidos depois que ele for entregue pela
primeira vez ao cliente.
Mitos do Software (profissional)
Enquanto
não
tiver
o
programa
"funcionando", eu não terei realmente
nenhuma maneira de avaliar sua qualidade.
Realidade:
Um programa funcionando é somente uma parte
de uma Configuração de Software que inclui todos
os itens de informação produzidos durante a
construção e manutenção do software.
Engenharia de Software
Preocupação: Sistematizar o processo de
criação e manutenção de software.
Engenharia de Software
Definições
 Boehm: Engenharia de software envolve a
aplicação prática de conhecimento científico
para o projeto e construção de programas de
computador e a documentação associada
necessária para desenvolvê-los, operá-los e
mantê-los.
Engenharia de Software
Definições
 IEEE
Standard Glossary of Software
Engineering terminology:
Engenharia de
software é uma abordagem sistemática para o
desenvolvimento, operação, manutenção de
software.
Software:
programas
de
computador,
procedimentos,
regras,
documentação
possivelmente associada, e dados sobre sua
operação.
Engenharia de Software
Definições
 Fairley: Engenharia de software é a disciplina
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
abrange um conjunto
fundamentais:
de
três
elementos
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: 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
coordenar as alterações
assegurar a qualidade e
 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
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
Engenharia de
Sistemas
Análise de
Requisitos
ANÁLISE E ENGENHARIA DE
SISTEMAS
Projeto
Codificação
Testes
 envolve a coleta de requisitos em
nível do sistema, pequena
quantidade de projeto e análise
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
Análise de
Requisitos
 processo de coleta dos requisitos
é intensificado e concentrado
especificamente no software
Projeto
Codificação
Testes
 deve-se compreender o domínio
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
Engenharia
de SistemasAnálise de
Requisitos 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,
Codificação
 Arquitetura de Software,
Testes
Manutenção
 Detalhes Procedimentais e
 Caracterização de Interfaces
Atividades do Ciclo de Vida Clássico
CODIFICAÇÃO
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
 tradução das representações
do projeto para uma
linguagem “artificial”
resultando em instruções
executáveis pelo computador
Testes
Manutenção
Atividades do Ciclo de Vida Clássico
TESTES
Concentram-se:
Engenharia
de SistemasAnálise de
RequisitosProjeto
Codificação
Testes
 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
Manutenção
definida produza resultados
que concordem com os
esperados.
Atividades do Ciclo de Vida Clássico
MANUTENÇÃO
Engenharia de
Sistemas
Análise de
Requisitos
 o software deverá sofrer mudanças
depois que for entregue ao cliente
Projeto
Codificação
Testes
 causas das mudanças:
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) 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
projeto
rápido
construção
produto
construção
protótipo
refinamento
protótipo
avaliação
protótipo
Atividades da Prototipação
Obtenção dos Requisitos:
início
fim
construção
produto
obtenção
dos
requisitos
projeto
rápido
desenvolvedor e cliente definem os
objetivos gerais do software,
identificam quais requisitos são
conhecidos e as áreas que
necessitam de definições adicionais
construção
protótipo
refinamento
protótipo
avaliação
protótipo
Projeto Rápido: representação dos
aspectos do software que são
visíveis ao usuário (abordagens de
entrada e formatos de saída)
Atividades da Prototipação
início
fim
construção
produto
obtenção
dos
requisitos
Construção Protótipo:
implementação do projeto rápido
projeto
rápido
construção
protótipo
refinamento
protótipo
avaliação
protótipo
Avaliação do Protótipo: cliente e
desenvolvedor avaliam o protótipo
Atividades da Prototipação
início
fim
construção
produto
Refinamento dos Requisitos:
obtenção
dos
requisitos
projeto
rápido
construção
protótipo
refinamento
protótipo
avaliação
protótipo
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
início
fim
construção
produto
obtenção
dos
requisitos
Construção Produto: identificados
projeto
rápido
construção
protótipo
refinamento
protótipo
avaliação
protótipo
os requisitos, o protótipo deve ser
descartado e a versão de produção
deve ser construída considerando os
critérios de qualidade.
Problemas com a Prototipação
cliente não sabe que o software que ele vê não
considerou, durante o desenvolvimento, a
qualidade global e a manutenibilidade a longo
prazo. Não aceita bem a idéia que a versão final
do software vai ser construída e "força" a
utilização do protótipo como produto final.
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,
prototipação é um ciclo de vida eficiente 
a
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
avaliação
do cliente
direção de um
sistema
engenharia
concluído
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
planejamento
análise dos
riscos
avaliação
do
cliente
engenharia
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ção dos
Requisitos
Estratégia do
“Projeto”
Implementação
usando 4GL
Testes
Ferramentas do ambiente de
desenvolvimento de software de 4GL
O ambiente de desenvolvimento de software que
sustenta o ciclo de vida de 4a geração inclui as
ferramentas:
 linguagens não procedimentais para consulta de
banco de dados
 geração de relatórios
 manipulação de dados
 interação e definição de telas
 geração de códigos
 capacidade gráfica de alto nível
 capacidade de planilhas eletrônicas
Atividades das Técnicas de 4a Geração
1. obtenção dos Requisitos:
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
o
cliente descreve os requisitos os
quais são traduzidos para um
protótipo operacional
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"
Atividades das Técnicas de 4a Geração
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
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
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
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
Atividades das Técnicas de 4a Geração
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.
Obtenção dos
Requisitos
Estratégia do
“Projeto”
Implementaçã
o usando 4GL
Testes
Técnicas de 4a Geração (comentários)
PROPONENTES: redução dramática no tempo de
desenvolvimento do software (aumento de
produtividade)
OPONENTES: as 4GL atuais não são mais fáceis de
usar do que as linguagens de programação
 o código fonte produzido é ineficiente
 a manutenibilidade de sistemas usando técnicas 4G
ainda é questionável
Mudança na natureza de
desenvolvimento de software
demanda
global
demanda
por
software
aplicação de
técnicas de 4a
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
requisitos
protomodelagem
projeto
protomodelagem
no. interação
técnicas
4G
codificação
protomodelagem
no. interação
testes
sistema completo
manutenção
modelo espiral
técnicas
4G
modelo espiral
no. interaçã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,
2. DESENVOLVIMENTO e
3. MANUTENÇÃO.
Engenharia de Software uma visão genérica
Construção
Operação
Definição
“o que”
1. Análise de
Sistema
2. Planejamento
do Projeto
3. Análise de
Requisitos
Desenvolvimento
Manutenção
“como”
1. Projeto de
 Software
2. Codificação
3. Teste


SOFTWARE
PRODUTO
“mudanças”

1. Entender
2. Modificar
3. Revalidar
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:
desenvolvido.
“como”
o
software
vai
ser
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.
Engenharia de Software uma visão genérica
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 abordagem
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 abordagem
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 abordagem
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 abordagem 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 abordagem gerencial
Fatores 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 abordagem gerencial
Fatores 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 abordagem 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.
Engenharia de Software uma abordagem gerencial
Questões gerenciais
Os gerentes de software:
devem garantir que o produto tenha os
atributos funcionais e de qualidade desejados
pelo cliente.
Treinam empregados.
 desenvolvem
marketing.
planos
e
estratégias
de
Engenharia de Software uma abordagem 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 abordagem gerencial
Preocupações de gerenciamento de projeto:
estabelecer
qualidade.
procedimentos
para
garantia
de
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 abordagem gerencial
Problemas na área de gerenciamento:
falta de
software.
planejamento
para
projetos
falta de técnicas e procedimentos
selecionar gerentes de projeto.
de
para
falta de habilidade em estimar os recursos
necessários para o projeto.
Engenharia de Software uma abordagem gerencial
Problemas na área de gerenciamento:
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 abordagem 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.
Engenharia de Software uma abordagem gerencial
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
desenvolvedores de software.
de
avaliar
os
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?
,
Pontos a ponderar
• 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.
REFERÊNCIAS
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ANTUNES, Paulo Bessa. Direito Ambiental. 2ed. Amplamente Reformulado. 14ª ed., Rio de Janeiro: Atlas, 2012.
Amaral, Diogo Freitas, Ciência Política, vol I ,Coimbra,1990
AQUINO, Rubim Santos Leão de . et al. História das Sociedades Americanas. 7 ed. Rio de Janeiro: Record, 2000.
ARANHA, Maria Lúcia. Filosofando: Introdução á Filosofia. São Paulo: Moderna, 1993.
ARRUDA, José Jobson de A. e PILETTI, Nelson. Toda a História. 4 ed. São Paulo: Ática, 1996.
ASCENSÃO, José de Oliveira. Breves Observações ao Projeto de Substitutivo da Lei de Direitos Autorais. Direito da
Internet e da Sociedade da Informação. Rio de Janeiro: Ed. Forense, 2002.
BRANCO JR., Sérgio Vieira. Direitos Autorais na Internet e o Uso de Obras Alheias. Ed. Lúmen Júris, 2007.
BUZZI, Arcângelo. Introdução ao Pensar. Petrópolis; ed. Vozes, 1997.
CAPEZ, Fernando. Curso de Direito Penal. V. 2, Parte Especial. 10. Ed. São Paulo: Saraiva, 2010.
CERQUEIRA, João da Gama. “Tratado da Propriedade Industrial”, vol. II, parte II. Revista Forense: Rio de Janeiro,
1952.
CHAUÍ, Marilena. Convite á Filosofia. São Paulo,10ª. Ed.,Ática,1998.
COTRIM, Gilberto. História Global: Brasil e Geral. 6 ed. São Paulo: Saraiva, 2002.
CRETELLA JÚNIOR, José. Curso de Direito Administrativo. Rio de Janeiro: Forense, 2003.
DEON SETTE, MARLI T. Direito ambiental. Coordenadores: Marcelo Magalhães Peixoto e Sérgio Augusto Zampol
DINIZ, Maria Helena. Curso de direito civil brasileiro: teoria das obrigações contratuais e extracontratuais. 3. ed. São
Paulo: Saraiva, 1998, v. 3.
DI PIETRO, Maria Sylvia Zanella. Direito Administrativo. São Paulo: Atlas, 2005.
COELHO, Fábio Ulhoa. Curso de direito comercial. 6. ed. São Paulo: Saraiva, 2002, v. 1, 2 e 3.
REFERÊNCIAS
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
FERRAZ JUNIOR, Tercio Sampaio. Introdução ao Estudo do Direito: técnica, decisão, dominação. 6.ed. São Paulo:
Atlas, 2008.
FIORILLO, Celso Antonio Pacheco. Curso de Direito Ambiental Brasileiro. 13ª ed., rev., atual. E compl. – São Paulo
:Saraiva, 2012.
FRAGOSO, Heleno Cláudio. Lições de direito penal: especial. 11. ed. atual. por Fernando Fragoso. Rio de Janeiro :
Forense, 2005.
GONÇALVES, Carlos Roberto. Direito Civil Brasileiro, vol I: Parte Geral. São Paulo: Saraiva, 2007
GAGLIANO, Plablo Stolze & PAMPLONA FILHO, Rodolfo. Novo curso de direito civil, v. 1 - 5 ed. São Paulo: Saraiva.
2004.
GRINOVER, Ada Pellegrini et al. Código Brasileiro de Defesa do Consumidor comentado pelos autores do
anteprojeto. 8. ed. rev., ampl. e atual. Rio de Janeiro: FU, 2004.
JESUS, Damásio E. de. Direito Penal – V. 2 – Parte Especial dos Crimes Contra a Pessoa a dos Crimes Contra o
Patrimônio. 30 ed. São Paulo: Saraiva, 2010.
LAKATOS, Eva Maria. Introdução à Sociologia. São Paulo: Atlas, 1997
LAKATOS, E. M. & MARCONI, M. A. Sociologia Geral. São Paulo: Atlas, 1999
MARQUES, Claudia Lima. Contratos no Código de Defesa do Consumidor: o novo regime das relações contratuais.4.
ed. rev., atual. e ampl. São Paulo: RT, 2004.
MARTINS FILHO, Ives Gandra da Silva. Manual de direito e processo do trabalho. 18.ed. São Paulo: Saraiva, 2009.
MARTINS, Sérgio Pinto.Direito do Trabalho. 25.ed. São Paulo: Atlas, 2009.
MARTINS, Carlos Benedito. O que é Sociologia. Rio de Janeiro: Zahar, 1988
MEDAUAR, Odete. Direito Administrativo Moderno. São Paulo: RT, 2001.
MEIRELLES, Hely Lopes. Direito Administrativo Brasileiro. São Paulo: Malheiros, 1996.
MIRABETE, Julio Fabbrini. Processo penal. 18. ed. – São Paulo: Editora Atlas, 2006.
REFERÊNCIAS
•
•
•
•
•
•
•
•
•
•
•
•
MORAES, de Alexandre. Direito Constitucional. São Paulo: Atlas, 2004.
PEIXINHO, Manoel Messias. Os princípios da Constituição de 1988. Rio de Janeiro: Lúmen Júris, 2001.
Piçarra, Nuno, A separação dos poderes como doutrina e princípio constitucional: um contributo para o estudo das
suas origens e evolução, Coimbra, Coimbra Editora, 1989
NUCCI, Guilherme de Souza. Manual de processo penal e execução penal. 3. ed. – São Paulo: Editora Revista dos
Tribunais, 2007.
PEREIRA, Caio Mario da Silva. Instituições de direito civil, v.1. Rio de Janeiro: Forense. 2004.
POLETTI, Ronaldo. Introdução ao Direito. 4. ed., São Paulo: Saraiva, 2010..
PRADO, Luiz Regis. Curso de direito penal brasileiro. 11. ed. São Paulo : RT, 2007, v. 2.
REALE, Miguel. Lições Preliminares de Direito. 27.ed São Paulo: Saraiva, 2006.
REQUIÃO, Rubens. Curso de direito comercial. 8. ed. São Paulo: Saraiva, 1977, v. 1 e 2.
RUSSOMANO, Mozart Victor. Comentários à Consolidação das Leis do Trabalho. 3. ed. Rio de Janeiro: Forense,
2005.
SELL, Carlos Eduardo. Sociologia Clássica . Itajai: EdUnivali, 2002
VENOSA, Sílvio de Salvo. Direito Civil (Parte Geral), v.1 – 3 ed. São Paulo: Atlas. 2003.
ATENÇÃO
Parte deste material foi coletado na internet e não foi possível identificar a
autoria. Este material se destina para fins de estudo e não se encontra
completamente atualizado.
FIM
• _________________Obrigado pela atenção!!
•
Acimarney C. S. Freitas – Advogado – OAB-BA Nº 30.553
•
Professor de Direito do Instituto Federal de Educação Ciência e Tecnologia da Bahia – IFBA – campus de Vitória da
Conquista
•
Diretor do Instituto Federal de Educação Ciência e Tecnologia da Bahia – IFBA – campus de Brumado.
•
Bacharel em Teologia
•
Especialista em Direito Educacional - FTC
•
Especialista em Educação Profissional e de Jovens e Adultos - IFBA
•
Mestrando em Filosofia - UFSC
Email: [email protected]
Facebook: Ney Maximus