Sistemas ES (01 Introducao)

Prévia do material em texto

Engenharia de Software
Introdução
Profa: Lauriana Paludo
lauriana.paludo@ifpr.edu.br
 
Profa. Lauriana Paludo – ES (Introdução) 
Introdução
 Objetivos
 Crise do Software
 Mitos do Software
 Definição de Engenharia de Software
 Aspectos do conhecimento de ES do SWEBOK
Objetivos
 Entender os principais aspectos do 
conhecimento da Engenharia de Software (ES)
 Compreender a importância da ES para 
construir software com qualidade
 Identificar os grandes desafios da ES
 
Profa. Lauriana Paludo – ES (Introdução) 
Como surgiu a ES?
 Softwares desenvolvidos de maneira artesanal (década 
de 50)
 Foco das pesquisas era o Hardware
 Softwares desenvolvidos sem técnica e o hardware 
escasso
 Passaram a surgir grandes sistemas
 Muitos problemas e não existia documentação
 Mais barato planejar do que corrigir!
 Analogia: como derrubar uma parede de uma casa 
sem saber onde estão as vigas e estruturas 
fundamentais?
 
Profa. Lauriana Paludo – ES (Introdução) 
Crise do Software: 70’s
 Disseminação do uso de computadores
 Programação individual para programação em grupo
 Problemas com a identificação de requisitos
 Difícil interação entre técnicos e clientes
 Falta de sistemáticas conhecidas para o 
desenvolvimento
 Baixa produtividade das equipes
 Problemas não se limitam ao software que não 
funciona adequadamente, mas abrange:
 desenvolvimento, testes, manutenção, suprimento, 
etc.
 
Profa. Lauriana Paludo – ES (Introdução) 
Crise do Software :70’s
 ES praticamente inexistente;
 O termo “crise do software” foi usado pela primeira vez 
com impacto por Dijkstra (1972)
 Expressava as dificuldades do desenvolvimento de 
software frente ao rápido crescimento da demanda por 
software, da complexidade dos problemas a serem 
resolvidos e da inexistência de técnicas estabelecidas 
para o desenvolvimento de sistemas que funcionassem 
adequadamente ou pudessem ser validados
 
Profa. Lauriana Paludo – ES (Introdução) 
Problemas relatados por Dijkstra 
em 1972
 Projetos que estouram o cronograma. 
 Projetos que estouram o orçamento. 
 Produto final de baixa qualidade ou não atendendo aos 
requisitos. 
 Produtos não gerenciáveis e difíceis de manter e evoluir. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Embora a Engenharia de Software tenha 
evoluído como ciência, sua aplicação na 
prática ainda é muito limitada. 
Crise do Software
 Problema: incapacidade de produzir ou manter 
software de alta qualidade com um custo 
razoável e dentro de um cronograma 
estabelecido
 
Profa. Lauriana Paludo – ES (Introdução) 
Consequências
 Prazos não eram cumpridos
 Baixa produtividade
 Recursos extrapolavam a estimativa
 A qualidade do software era questionável
 O produto final não refletia o que era 
solicitado
 Difícil e constante manutenção
 Não era possível conhecer os efeitos de uma 
mudança
 Transferência lenta de tecnologia...
 
Profa. Lauriana Paludo – ES (Introdução) 
Consequências
 Prazos não eram cumpridos
 Baixa produtividade
 Recursos extrapolavam a estimativa
 A qualidade do software era questionável
 O produto final não refletia o que era solicitado
 Difícil e constante manutenção
 Não era possível conhecer os efeitos de uma 
mudança
 Transferência lenta de tecnologia...
 
Profa. Lauriana Paludo – ES (Introdução) 
O PROBLEMA CONTINUA ? 
Gartner Group, 2000
 
Profa. Lauriana Paludo – ES (Introdução) 
Questionário aplicado à alta direção de 200 empresas 
de porte médio/grande, sobre as principais 
falhas/dificuldades com a Informática: 
- Cumprimento dos prazos 26,3% 
- Custos elevados 25,4% 
- Prioridade desenvolvimento x 
manutenção 25,4% 
- Manutenção dos sistemas em uso 21,1% 
- Recrutar profissionais qualificados 
18,4% 
Therac-25
 Equipamento de Radioterapia.
 Entre 1985 e 1987 se envolveu em 6 acidentes, 
causando mortes por overdoses de radiação.
 Software foi adaptado de uma antecessora, Therac-
6:
 falhas por falta de testes integrados
 falta de documentação
Fonte: página 382 do Pfleeger
 
Profa. Lauriana Paludo – ES (Introdução) 
Denver International Airport
 Custo do projeto: US$ 4.9 bilhões
 100 mil passageiros por dia / 1,200 vôos
 53 milhas quadradas
 94 portões de embarque e desembarque
 6 pistas de pouso / decolagem
 
Profa. Lauriana Paludo – ES (Introdução) 
Denver International Airport
 Erros no sistema automático de transporte de bagagens (misloaded, 
misrouted, jammed):
 Atraso na abertura do aeroporto com custo total estimado em 
US$360 Milhões
 86 milhões para consertar o sistema
 
Profa. Lauriana Paludo – ES (Introdução) 
Ariane 5
 
Profa. Lauriana Paludo – ES (Introdução) 
Ariane 5
 Projeto da Agência 
Espacial Européia que 
custou:
 10 anos.
 US$ 8 Bilhões.
 Capacidade 6 toneladas.
 Garante supremacia 
européia no espaço.
 
Profa. Lauriana Paludo – ES (Introdução) 
Vôo inaugural em 4/junho/1996
 
Profa. Lauriana Paludo – ES (Introdução) 
Resultado
 Explosão 40 
segundos após a 
decolagem.
 Destruição do 
foguete e carga 
avaliada em US$ 
500 milhões. 
 
Profa. Lauriana Paludo – ES (Introdução) 
O que aconteceu? (I)
 Fato: o veículo detonou suas cargas explosivas 
de autodestruição e explodiu no ar. Por que?
 Porque ele estava se quebrando devido às 
forças aerodinâmicas. Mas por que?
 O foguete tinha perdido o controle de direção 
(altitude). Causa disso?
 Os computadores principal e back-up desligaram 
ao mesmo tempo.
 
Profa. Lauriana Paludo – ES (Introdução) 
O que aconteceu? (II)
 De onde veio este erro?
 Um programa que convertia um valor em ponto 
flutuante para um inteiro de 16 bits recebeu como 
entrada um valor que estava fora da faixa 
permitida.
 
Profa. Lauriana Paludo – ES (Introdução) 
Especificamente:O que faltou?
strict precondition 1: 
 {
 Set."x"=FLPT and Set."y"=INT16 
and -32768 <= x <= +32767
} 
program code: 
 y := int(x);
postcondition: 
 {Set."x"=FLPT and Set."y"=INT16 and y=int(x)}
 
Profa. Lauriana Paludo – ES (Introdução) 
Ironia...
 O resultado desta conversão não era mais 
necessário após a decolagem...
 
Profa. Lauriana Paludo – ES (Introdução) 
Frustrações dos usuários
 Esperança que pelo menos parte da promessa da 
informática se cumpra; 
 Frustração pela pequena parte da promessa já 
cumprida, em razão de: 
- Erros, falhas e inadequação dos produtos de 
software 
- Insegurança na utilização 
- Prazos excessivamente longos 
- Custos altos e constantes 
- Constante necessidade de manutenções 
 
Profa. Lauriana Paludo – ES (Introdução) 
Frustrações dos desenvolvedores
 Baixa produtividade no desenvolvimento;
 Baixa qualidade do produto gerado (erros e 
adequação às necessidades do usuário); 
 Impossibilidade de cumprir prazos e custos; 
 Dificuldade em treinar os profissionais nas novas 
tecnologias; 
 Mudanças constantes em TI/SI (insegurança e 
necessidade constante de atualização) 
 
Profa. Lauriana Paludo – ES (Introdução) 
Quais são os problemas?
 A sofisticação do software ultrapassou nossa 
capacidade de construção.
 Nossa capacidade de construir programas não 
acompanha a demanda por novos programas.
 Nossa capacidade de manter programas é 
ameaçada por projetos ruins.
 
Profa. Lauriana Paludo – ES (Introdução) 
Perguntas que a ES quer responder:
 Porque demora tanto para concluir um projeto (não 
cumprimos prazos)?
 Porque custa tanto (uma ordem de magnitude a mais)?
 Porque não descobrimos os erros antes de entregar o 
softwareao cliente?
 Porque temos dificuldade de medir o progresso 
enquanto o software está sendo desenvolvido?
 
Profa. Lauriana Paludo – ES (Introdução) 
Causas óbvias
 Não dedicamos tempo para coletar dados sobre 
o desenvolvimento do software - resulta em 
estimativas “a olho”.
 Comunicação entre o cliente e o desenvolvedor 
é muito fraca.
 Falta de testes sistemáticos e completos.
 
Profa. Lauriana Paludo – ES (Introdução) 
Causas menos óbvias
 O Software não é desenvolvido ou projetado com 
engenharia;
 Gerentes sem experiência em desenvolvimento de 
software;
 Profissionais recebem pouco treinamento formal;
 Experiência do programador é adquirida através de 
tentativa e erro;
 Falta investimento (em ES);
 Falta métodos e automação.
 
Profa. Lauriana Paludo – ES (Introdução) 
Causas associadas à crise do 
software
1- PRÓPRIO CARÁTER DO SOFTWARE
2- FALHAS DAS PESSOAS RESPONSÁVEIS PELO 
DESENVOLVIMENTO DE SOFTWARE
3- MITOS DO SOFTWARE
 
Profa. Lauriana Paludo – ES (Introdução) 
O que é Software?
 Segundo PRESSMAN (2006) é um produto 
que os profissionais de software constroem e 
depois mantêm ao longo do tempo.
 SOMMERVILLE (2007) define como um 
conjunto de programas separados; arquivos 
de documentação e sites.
 
Profa. Lauriana Paludo – ES (Introdução) 
Software – definição clássica
 "um conjunto de instruções que, quando executadas, 
produzem a função e o desempenho desejados, 
estruturas de dados que permitam que as informações 
relativas ao problema a resolver sejam manipuladas 
adequadamente e a documentação necessária para um 
melhor entendimento da sua operação e uso".
 
Profa. Lauriana Paludo – ES (Introdução) 
Software – contexto da ES
 UM PRODUTO A SER "VENDIDO".
 É diferente dos "programas" que são concebidos num contexto 
mais restrito, onde o usuário ou "cliente" é o próprio autor 
– a documentação associada é pequena ou (na maior parte das 
vezes) inexistente 
– a preocupação com a existência de erros de execução não é 
um fator maior, o usuário e ao mesmo tempo autor do programa 
não terá dificuldades, em princípio, na detecção e correção de 
um eventual erro.
 Além do aspecto da correção, outras características não são 
também objeto de preocupação como a portabilidade, a 
flexibilidade e a possibilidade de reutilização.
 
Profa. Lauriana Paludo – ES (Introdução) 
Software – contexto da ES
 Um PRODUTO DE SOFTWARE é destinado ao uso por 
outras pessoas e não aos seus programadores. 
 Os usuários podem ter formações e experiências 
diferentes, o que significa que uma grande preocupação 
deve ser a sua INTERFACE, reforçada com uma 
documentação rica em informações para que todos os 
recursos oferecidos possam ser explorados de forma 
eficiente. 
 Ainda, os produtos de software devem passar por uma 
exaustiva bateria de TESTES, dado que os usuários não 
estarão interessados (e nem terão capacidade) de 
detectar e corrigir os eventuais erros de execução.
 
Profa. Lauriana Paludo – ES (Introdução) 
Software – Resumindo
 Um programa desenvolvido para resolver um dado 
problema e um produto de software destinado à 
resolução do mesmo problema são duas coisas 
totalmente diferentes.
 
 Esforço e o conseqüente custo associado ao 
desenvolvimento de um produto serão muito superiores.
 
Profa. Lauriana Paludo – ES (Introdução) 
Natureza do software
 Produto complexo
 Natureza abstrata (invisibilidade)
 Requisitos mudam continuamente
 Necessita evolução contínua
 Muitos riscos envolvidos
 Software não desgasta!
 Software não é sensível aos problemas ambientais que fazem 
com que o hardware se desgaste.
 Toda falha indica erro de projeto ou implementação
 Manutenção e evolução custam mais que o desenvolvimento 
(sistemas com vida longa)
 
Profa. Lauriana Paludo – ES (Introdução) 
Software hoje
 Tecnologia orientada a objetos
 Sistemas especialistas e software de 
inteligência artificial usados na prática
 Computação paralela
 Internet
 Aplicativos móveis
 Software embarcado
 
Profa. Lauriana Paludo – ES (Introdução) 
Software hoje
 É um negócio competitivo
 Principais direcionadores de competitividade: 
custo, adequação de prazo e qualidade
 Movimentação em adotar práticas da ES
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos do Software (Pressman)
 Administrativos
 Do cliente
 Do profissional 
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
gerenciamento
Mito 1. "Se a equipe dispõe de um manual repleto de padrões e 
procedimentos de desenvolvimento de software, então a equipe está 
apta a encaminhar bem o desenvolvimento."
Realidade 1. Isto verdadeiramente não é o suficiente... é preciso que a 
equipe aplique efetivamente os conhecimentos apresentados no 
manual... é necessário que o que conste no dado manual reflita a 
moderna prática de desenvolvimento de software e que este seja 
exaustivo com relação a todos os problemas de desenvolvimento que 
poderão aparecer no percurso...
 
Profa. Lauriana Paludo – ES (Introdução) 
Mito 2. "A equipe tem ferramentas de desenvolvimento de software de 
última geração, uma vez que eles dispõem de computadores de última 
geração."
Realidade 2. Ter à sua disposição o último modelo de computador 
(seja ele um mainframe, estação de trabalho ou PC) pode ser bastante 
confortável para o desenvolvedor do software, mas não oferece 
nenhuma garantia quanto à qualidade do software desenvolvido. Mais 
importante do que ter um hardware de última geração é ter 
ferramentas para a automatização do desenvolvimento de software (as 
ferramentas CASE)...
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
gerenciamento
Mito 3. "Se o desenvolvimento do software estiver atrasado, basta 
aumentar a equipe para honrar o prazo de desenvolvimento." 
Realidade 3. Isto também dificilmente vai ocorrer na realidade... 
alguém disse um dia que "... acrescentar pessoas em um projeto 
atrasado vai torná-lo ainda mais atrasado...". De fato, a introdução de 
novos profissionais numa equipe em fase de condução de um projeto 
vai requerer uma etapa de treinamento dos novos elementos da 
equipe; para isto, serão utilizados elementos que estão envolvidos 
diretamente no desenvolvimento, o que vai, conseqüentemente, 
implicar em maiores atrasos no cronograma.
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
gerenciamento
Mito 4. "Uma descrição breve e geral dos requisitos do software é o 
suficiente para iniciar o seu projeto... maiores detalhes podem ser 
definidos posteriormente." 
Realidade 4. Este é um dos problemas que podem conduzir um 
projeto ao fracasso, o cliente deve procurar definir o mais 
precisamente possível todos os requisitos importantes para o software: 
funções, desempenho, interfaces, restrições de projeto e critérios de 
validação são alguns dos pontos determinantes do sucesso de um 
projeto.
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
cliente
Mito 5. "Os requisitos de projeto mudam continuamente durante o seu 
desenvolvimento, mas isto não representa um problema, uma vez que 
o software é flexível e poderá suportar facilmente as alterações." 
Realidade 5. É verdade que o software é flexível (pelo menos mais 
flexível do que a maioria dos produtos manufaturados). Entretanto, não 
existe software, por mais flexível que suporte alterações de requisitos 
significativas com adicional zero em relação ao custo de 
desenvolvimento. O fator de multiplicação nos custos de 
desenvolvimento do software devido a alterações nos requisitos cresce 
emfunção do estágio de evolução do projeto, como mostra a figura 
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
cliente
 
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
cliente
Mito 6. "Após a edição do programa e a sua colocação em 
funcionamento, o trabalho está terminado." 
Realidade 6. O que ocorre na realidade é completamente diferente 
disto. Segundo dados obtidos a partir de experiências anteriores, 50 a 
70% do esforço de desenvolvimento de um software é despendido 
após a sua entrega ao cliente (manutenção).
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
profissional
Mito 7. "Enquanto o programa não entrar em funcionamento, é 
impossível avaliar a sua qualidade." 
Realidade 7. Na realidade, a preocupação com a garantia do software 
deve fazer parte de todas as etapas do desenvolvimento, sendo que, 
ao fim de cada uma destas etapas, os documentos de projeto devem 
ser revisados observando critérios de qualidade.
Mito 8. "O produto a ser entregue no final do projeto é o programa 
funcionando." 
Realidade 8. O programa em funcionamento é um dos componentes 
do software...além do software, um bom projeto deve ser caracterizado 
pela produção de um conjunto importante de documentos que 
permitam sua manutenção
 
Profa. Lauriana Paludo – ES (Introdução) 
Mitos e realidades do Software – do 
profissional
De nada adianta apenas estar consciente dos mitos.
 
Para produzir software com mais qualidade e 
confiabilidade é necessário utilizar um série de práticas, 
algumas das quais serão apresentadas nesta disciplina. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Conclusão
 “A Engenharia de Software forma um aglomerado de 
conceitos que dizem absolutamente nada e que geram no 
estudante desta área um sentimento de Nossa, li 15 kg de 
livros desta matéria e não aprendi nada. É tudo bom 
senso.”
 
Profa. Lauriana Paludo – ES (Introdução) 
Definição de Engenharia de Software
Vamos aprender: 
- Processos de engenharia de software são diferentes dependendo do 
tipo de software que se vai desenvolver. 
- Dependendo do nível de conhecimento ou estabilidade dos requisitos 
deve-se optar por um ou outro ciclo de vida. 
- Uma área aparentemente tão subjetiva como “riscos” pode ser 
sistematizada e tratada efetivamente como um processo de engenharia, 
sem as características de não determinismos e relatividade absoluta 
que usualmente se observa. 
- Existem formas objetivas e padronizadas para mensurar o esforço do 
desenvolvimento de software de forma a gerar números que sejam 
efetivamente realistas, o que já vem sendo comprovado em diversas 
empresas. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Não é simples conceituar e praticar a engenharia de 
software. Mas é necessário. 
 
“ A aplicação de abordagens sistemáticas, 
disciplinadas e quantificáveis ao 
desenvolvimento, operação e manutenção 
do software” (IEEE Computer Society, 2004)
 
Profa. Lauriana Paludo – ES (Introdução) 
Definição de Engenharia de Software
Definição de Engenharia de Software 
 A Engenharia de Software 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. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Definição de Engenharia de Software
 Métodos: proporcionam os detalhes de “como fazer” 
para construir o 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. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Talita
Máquina de escrever
Estimativa de tempo, valor financeiro, tamanhonullda equipe...
Definição de 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
 
Profa. Lauriana Paludo – ES (Introdução) 
Talita
Máquina de escrever
Ferramentas CASE: ambientes integrados
Definição de Engenharia de Software 
 Procedimentos: constituem o elo de ligação entre os 
métodos e ferramentas;
– Sequencia 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.
 
Profa. Lauriana Paludo – ES (Introdução) 
Talita
Máquina de escrever
Sequencia em que os métodos serão aplicados - é o que une os métodos com as ferramentas
Lembre! ES tem a ver com:
 
Profa. Lauriana Paludo – ES (Introdução) 
 
Sistemática
(princípios, métodos, ferramentas)
Desenvolvimento e Manutenção
Qualidade e Produtividade
Talita
Selecionar
Talita
Selecionar
Talita
Selecionar
Lembre! Características da ES:
 
Profa. Lauriana Paludo – ES (Introdução) 
 A ES se refere a software desenvolvido por grupos de 
indivíduos;
 Usa princípios de engenharia ao invés de arte, e
 Inclui tanto aspectos técnicos quanto não técnicos.
Talita
Selecionar
Talita
Selecionar
Tarefas da ES
 Análise do problema e 
identificação de requisitos
 Projeto (design)
 Codificação
 Testes e Integração do 
código
 Instalação e entrega do 
software
 Documentação
 Manutenção
 Controle de qualidade
 Treinamento
 Estimativas de recursos
 Gerência de projetos
 
Profa. Lauriana Paludo – ES (Introdução) 
SWEBOK
 
Profa. Lauriana Paludo – ES (Introdução) 
 O SWEBOK (Guide to the Software Engineering Body 
of Knowledge) é um documento criado com a finalidade 
de servir de referência em assuntos considerados como 
essenciais na área de Engenharia de Software e foi 
conduzido pelo IEEE (Institute of Electrical and Electronics 
Engineers).
SWEBOK – O porquê do guia
 
Profa. Lauriana Paludo – ES (Introdução) 
 Surgiu da necessidade da comissão de especialistas da 
área de Engenharia de Software, visando uma definição 
das fronteiras que a delimitam (SWEBOK, 2004).
 Subsídios para o reconhecimento da profissão de 
Engenheiro de Software.
SWEBOK - Objetivos
 
Profa. Lauriana Paludo – ES (Introdução) 
 Caracterizar o conteúdo da disciplina de engenharia de 
software;
 Estabelecer um conjunto apropriado de critérios e normas 
para a prática profissional da Engenharia de Software; 
 Marcar as fronteiras entre a Engenharia de Software e as 
demais disciplinas relacionadas; 
 Prover uma fundação para certificação individual e para 
licenciamento de profissionais.
SWEBOK – Áreas de Conhecimento 
versão 2010
 
Profa. Lauriana Paludo – ES (Introdução) 
1.Requisitos de Software
2.Projeto de Software
3.Construção de Software
4.Teste de Software
5.Qualidade de Software
6.Manutenção de Software
7.Processo de Engenharia de Software
8.Gerência de Configuração de Software
9.Gerência da Engenharia de Software
10.Disciplinas Relacionadas
Talita
Máquina de escrever
Limites da Engenharia de Software
Talita
Máquina de escrever
Análise
Talita
Máquina de escrever
Análise
Talita
Máquina de escrever
Programação
 Certificação CSDA (Certificação de Associação 
no Desenvolvimento de Software).
 Certificação CSDP (Certificação de 
Desenvolvimento Profissional de Software)
Certificações
 Uma das primeiras confusões que se faz nestaárea é 
confundir o desenvolvedor com o engenheiro de software. 
Isso equivale a confundir o engenheiro civil com o pedreiro ou 
com o mestre de obra. 
 Considerando com maior ênfase a definição de Engenharia de 
Software como o processo de estudar, criar e otimizar os 
processos de trabalho para os desenvolvedores de software, 
embora não seja consenso, considera-se, que as atividades de 
levantamento de requisitos, modelagem, design e codificação, 
não são típicas de um engenheiro de software, embora, muitas 
vezes, ele seja habilitado a realizá-las. 
 
Profa. Lauriana Paludo – ES (Introdução) 
O Engenheiro de Software
 
Profa. Lauriana Paludo – ES (Introdução) 
O Engenheiro de Software
 O desenvolvedor, seja ele analista, projetista, programador ou 
gerente de projeto, é um executor do processo de construção de 
software. 
 Os desenvolvedores, de acordo com seus papéis, tem a 
responsabilidade de descobrir os requisitos e transformá-los em 
um produto executável. 
 Mas o engenheiro de software tem um meta-papel em relação 
a isso. 
 Pode-se dizer que o engenheiro de software não coloca a mão 
na massa, assim como o engenheiro civil não vai à obra 
assentar tijolos ou concretar uma laje. 
Talita
Selecionar
 
Profa. Lauriana Paludo – ES (Introdução) 
O Engenheiro de Software
 Então, o engenheiro de software não é um desenvolvedor 
que trabalhe na produção de código.
Porém, a comparação com a engenharia civil termina por 
aqui, já que o engenheiro civil será o responsável pela 
especificação do projeto.
Na área da computação, a especificação do projeto fica a 
cargo do analista e projetista, o primeiro com a 
responsabilidade de identificar os requisitos e o segundo 
com a responsabilidade de desenhar uma solução que 
utilize a tecnologia para transformar estes requisitos em 
um sistema executável
Talita
Selecionar
 
Profa. Lauriana Paludo – ES (Introdução) 
O Engenheiro de Software
 O engenheiro de software assemelha-se assim mais ao 
engenheiro de produção.
 Ele deve fornecer aos desenvolvedores (inclusive 
analistas e projetistas), as ferramentas e processos que 
estes deverão usar e ele será o responsável por verificar 
que tais ferramentas e processos sejam efetivamente 
usados, que sejam usados de forma otimizada e que caso 
apresentem qualquer problema ele será responsável por 
realizar as modificações necessárias no próprio processo, 
garantindo assim sua contínua melhoria. 
Talita
Selecionar
Talita
Selecionar
Talita
Selecionar
 
Profa. Lauriana Paludo – ES (Introdução) 
Engenheiro de Software X Gerente de 
Projeto
 O gerente de projeto deve planejar e garantir que o 
projeto seja executado de forma adequada dentro dos 
prazos e orçamento especificados. 
 Mas o gerente de projeto tem uma responsabilidade mais 
restrita ao projeto em si e não ao processo de produção.
 Neste sentido, o gerente de projeto também é um 
executor, ele utiliza as disciplinas definidas no processo de 
engenharia de software para gerenciar seu projeto 
específico, mas ele não é necessariamente o responsável 
pela evolução destes processos nem necessariamente 
pela sua escolha. 
 - Este papel cabe ao engenheiro de software. 
 
Profa. Lauriana Paludo – ES (Introdução) 
Resumo dos papéis
 Engenheiro de Software: escolhe, especifica e reavalia os 
processos de planejamento, gerência e produção
 Gerente de Projetos: cuida de um projeto específico 
 Analista: desenvolvedor responsável pela compreensão do 
problema, ou seja, pelo levantamento de requisitos e sua 
modelagem 
 Projetista ou designer: leva em conta as especificações do 
analista e propõem a melhor tecnologia para produzir um 
sistema
 Programador: construir a solução física a partir das 
especificações do designer. Deve conhecer profundamente a 
linguagem e o ambiente de programação, além de ter 
conhecimentos de teste e depuração de software 
 
Profa. Lauriana Paludo – ES (Introdução) 
Evolução da ES
1940 – Não havia software.
 
1960 a 1980 – Crise do software (mitos). 
1980 a 1990 – Balas de prata (solução única). 
2000 – Métodos ágeis. 
2004 – Swebok. 
Atividades 
1) Exercícios 01 – Introdução à ES.
 
Profa. Lauriana Paludo – ES (Introdução) 
Leitura recomendada 
1. SANTIAGO, Marcos Rogerio. Ensaio do SWEBOK – Software 
Engineering Body Of Knowledge. Universidade Gama Filho, 
Goiania, 2011. Capítulo 2 – História e Definições Iniciais. 
2. Texto de André Furtado “Pontas de Iceberg do Caos no 
Desenvolvimento de Software”.
 
Profa. Lauriana Paludo – ES (Introdução) 
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71