aula1-modelos

Prévia do material em texto

Engenharia de Software
© Pablo Dall'Oglio
Introdução à Engenharia de Software
Processos de desenvolvimento de software
Pablo Dall'Oglio
Engenharia de Software
© Pablo Dall'Oglio
O que é Engenharia de Software ?
“Engenharia de software é uma área do conhecimento da 
computação voltada para a especificação, desenvolvimento e 
manutenção de sistemas de software aplicando tecnologias e 
práticas de gerência de projetos e outras disciplinas, 
objetivando organização, produtividade e qualidade.”
Wikipedia
Engenharia de Software
© Pablo Dall'Oglio
Histórico da Engenharia de Software ?
� O termo Engenharia de Software (ES) foi criado em 1960;
� Utilizado oficialmente em 1968 na NATO (OTAN) Conference 
on Software Engineering;
� Surgiu na tentativa de contornar a CRISE DO SOFTWARE;
� A crise do software foi um termo utilizado nos anos 70, quando 
a engenharia de software era praticamente inexistente;
� A ideia era dar um tratamento sistemático e organizado ao 
desenvolvimento de sistemas complexos;
Engenharia de Software
© Pablo Dall'Oglio
A crise do software
� O termo expressava as dificuldades do desenvolvimento;
� A demanda por software era crescente;
� Os problemas estavam ficando mais complexos;
� inexistência de técnicas para o desenvolvimento;
� As causas da crise do software foram:
� Projetos estourando o orçamento;
� Projetos estourando o prazo;
� Software de baixa qualidade;
� Software muitas vezes não atingiam os requisitos;
� Projetos não gerenciáveis e o código difícil de manter.
Engenharia de Software
© Pablo Dall'Oglio
IEEE - SWEBOK
� Software Engineering Body of Knowledge;
� O SWEBOK cobre as seguinte áreas de conhecimento:
� Requisitos de Software;
� Projeto de Software;
� Construção de Software;
� Teste de Software;
� Manutenção de Software;
� Gerência de Configuração de Software;
� Gerência da Engenharia de Software;
� Processo de Engenharia de Software;
� Ferramentas e Métodos da Engenharia de Software;
� Qualidade de Software.
Engenharia de Software
© Pablo Dall'Oglio
Mas eu já sei programar !
� Programar é parte importante da Engenharia de Software;
� Mas não é tudo !
� Outras atividades importantes são:
� Estimar tamanho, custo cronograma de um projeto;
� Monitorar o andamento de um projeto;
� Testar o software;
� Controlar a evolução do software.
� Por vezes são tarefas mais complexas do que programar.
Engenharia de Software
© Pablo Dall'Oglio
Programas de aula
� Requisitos estáveis e bem definidos;
� Escopo pequeno (1-10 KLOCS);
� Prazos razoáveis;
� Equipes pequenas;
� Mão de obra gratuita;
� Não entra em produção;
� Ausência de cliente;
� Ausência de manutenção.
Engenharia de Software
© Pablo Dall'Oglio
Programas reais
� Em um programa do mundo real, devemos nos preocupar com 
fatores como:
� Escopo;
� Custo;
� Prazo;
� Qualidade.
� Quando um software é grande, esses fatores se tornam difíceis 
de gerenciar.
Engenharia de Software
© Pablo Dall'Oglio
Exemplo 1 – Agenda de contatos
� Objetivo
� Desenvolver um software para armazenar 
contatos (nome, telefone, e-mail);
� Defina:
� Custo para produção ?
� Quanto tempo vai levar para ficar 
pronto ?
� Quais as consequências em caso de 
defeito ?
Engenharia de Software
© Pablo Dall'Oglio
Exemplo 2 – Boing 777
� Objetivo
� Desenvolver um software para 
controlar todo o hardware do 
Boing 777;
� Defina:
� Custo para produção ?
� Quanto tempo vai levar para 
ficar pronto ?
� Quais as consequências em 
caso de defeito ?
Engenharia de Software
© Pablo Dall'Oglio
Exemplo 2 – Boing 777
� Tamanho
� Mais de 4 milhões de linhas;
� Linguagem dominante (>99%): Ada;
� Documentação
� Total de 79 sub-sistemas integrados;
� De 100 a 10.000 páginas por sub-sistema;
� Duração
� 4,5 anos de desenvolvimento;
� Ampla utilização de Engenharia de Software;
� Em operação desde 1995;
� Zero acidentes graves até 2006;
� http://www.boeing.com/news/techissues/pdf/statsum.pdf
Engenharia de Software
© Pablo Dall'Oglio
Outros exemplos
� Toyota Lexus LS460: > 7 MLOCs
� Windows XP: 40 MLOCs
� 1800 desenvolvedores;
� 2200 testadores;
� SAP: 250 MLOCs
� Ubuntu: 121 MLOCs
Engenharia de Software
© Pablo Dall'Oglio
Fazer software é arte ou engenharia ?
� Parte é arte, parte é engenharia;
� Não adianta ter somente inspiração;
� É preciso ter técnica;
� É preciso conhecer os métodos e metodologias;
� É preciso saber usar as ferramentas corretas;
� Se o cantor errar, a audiência vaia;
� Se o engenheiro civil errar o prédio pode cair;
� Se o médico errar o paciente pode morrer;
� E se o desenvolvedor de software errar, o que pode acontecer?
� Ver vídeo Erros de arquitetura e engenharia.flv;
Engenharia de Software
© Pablo Dall'Oglio
Caso real 1 – Therac 25
� Radioterapia controlada por computador
� Problema:
� Doses indevidas de radiação (100x);
� Causa:
� Software reutilizado de um hardware anterior;
� Software nunca testado com aquele hardware antes;
� Interface inapropriada (erro provocado por seq. teclas);
� Sistema simplesmente exibia MALFUNCTION e continuava;
� Software de sensores de falha com defeito;
� Relatos de problemas eram ignorados pela equipe de desenv.
� Consequências
� Ao menos 5 mortes entre 1985 e 1987;
Engenharia de Software
© Pablo Dall'Oglio
Caso real 2 – Ariane 5
� Problema:
� O foguete se auto-destruiu 40
segundos após o lançamento (ver vídeo);
� Causa:
� Software reutilizado do Ariane 4 sem ser adaptado para o 
novo hardware;
� Problemas de conversão de tipos numéricos e sinais;
� Ausência de testes em solo deste software;
� Defeito apresentado em vôo;
� Consequências
� Prejuízo de mais de US$ 370.000.000,00 em 1996;
� Ver ariane 5 explosion.flv.
Engenharia de Software
© Pablo Dall'Oglio
Tem exemplos mais próximos ?
� Somos rodados de softwares de grandes proporções:
� Em um banco:
� Sacar, depositar, transferir;
� Realizar pagamentos;
� Na Universidade:
� Consultar notas, frequências;
� Realizar matrículas;
� Na Prefeitura:
� Ao pagar tributos;
� Ao solicitar serviços (protocolo).
� Na Empresa:
� Registrar ponto, receber pagamento.
Engenharia de Software
© Pablo Dall'Oglio
O software em nossas vidas
� A sociedade está passando por mudanças profundas;
� O software está influenciando essas mudanças;
� As comunicações estão mais eficazes (twitter, facebook);
� Existe maior necessidade de integração;
� Software passou a fazer parte da vida das pessoas;
� Isto tem gerado também uma maior demanda por qualidade;
� Qualidade possui um custo, ainda não compreendido;
� O desafio da engenharia de software é:
� Gerar aplicações de qualidade com os recursos limitados 
disponíveis.
Engenharia de Software
© Pablo Dall'Oglio
Algumas estatísticas
� Dos projetos em software Chaos
Report (Standish Group, 2002):
� 34% são concluídos com sucesso;
� 51% não atingem completamente
os objetivos para os quais foram propostos;
� 15% são fracassados.
� 2010 IT Project Success Rates (DrDobbs, 2010):
� 47% são concluídos com sucesso;
� 36% não atingem completamente
 os objetivos para os quais foram propostos;
� 17% são fracassados.
Projetos de
Software
são muito
voláteis
Engenharia de Software
© Pablo Dall'Oglio
Processo de software
� Para ter qualidade é preciso organizar o processo de SW;
� Muitas metodologias surgiram ao longo dos anos para 
organizar o desenvolvimento de software;
� Uma metodologia propõe um processo;
� Mas o que é um processo ?
� Um processo é um conjunto ordenado de ações a atividades;
� Há muito tempo vem se tentando encontrar um modelo que 
melhore a produtividade e qualidade no processo;
� Vários processos foram propostos;
� A maioria deles enquadra-se dentro de um modelo:
� Cascata, Iterativo, evolucionário ou ágil;
Engenharia de Software
© Pablo Dall'Oglio
Modelo em cascata
Engenharia de Software
© Pablo Dall'Oglio
Modelo em cascata
� É um modelo sequencial de desenvolvimento de software;
� A origem do termo é um artigo publicado em 1970 por Royce;
� O projeto é dividido em fases de análise, projeto, 
implementaçãoe testes;
� Cada fase é executada de maneira sequencial. Primeiro é 
realizada todo o projeto para então o desenvolvimento;
� O processo só avança se a fase atual for concluída e aceita;
� Caso um erro ocorra, é necessário revisar etapas anteriores;
� Ex: 3 meses para análise, 2 meses para projeto,
4 meses para desenvolvimento e 1 mês para testes;
� Utilizado quando deseja-se previsibilidade.
Engenharia de Software
© Pablo Dall'Oglio
Análise
� É o estudo das características que o sistema deverá ter para 
atender às necessidades do cliente;
� Nesta etapa, estabelecem-se os requisitos do produto;
� Requisito = limitações e objetivos do software;
� Requisitos devem ser especificados de uma maneira 
apropriada para que sejam úteis posteriormente;
� Também é realizado um estudo da viabilidade do projeto para 
determinar se pode-se iniciar o projeto;
� É o início do seu ciclo de vida.
Engenharia de Software
© Pablo Dall'Oglio
Análise
� Descoberta do conhecimento;
� Busca descobrir “O QUE” o sistemas faz;
� Não há preocupação com a implementação;
� O Analista deverá, segundo Pressman:
� 1) Questionar o cliente sobre as tarefas do sistema (levantar 
os requisitos do sistema);
� 2) Conseguir abstrair informações sem importância para o 
sistema (Ex: Atividades ou processos manuais);
� 3) Conseguir mostrar o que realmente o sistema deverá fazer 
e indicar o que não deverá fazer (Exceções).
Engenharia de Software
© Pablo Dall'Oglio
Análise
� Exemplo:
� Permite ao usuário se cadastrar ou alterar seu cadastro no 
sistema para criar leilões, dar lances em leilões abertos ou 
abrir seu próprio leilão;
� O sistema deve autenticar o usuário no sistema mediante a 
informação de login e senha;
� Permite ao usuário efetuar um lance em leilões em aberto;
� Permite ao usuário cancelar um lance efetuado a em um 
leilão em aberto;
� Permite ao sistema do cliente obter a lista dos meios de 
pagamentos disponíveis.
Engenharia de Software
© Pablo Dall'Oglio
Projeto
� Nesta fase é criada a especificação do software;
� Nesta fase é definida a arquitetura do software;
� Arquitetura = estrutura + organização + fluxo + componentes 
+ camadas + banco de dados + interfaces;
� O projeto funciona como um guia do desenvolvimento;
� O projetista deve ter conhecimento da solução técnica;
� O projetista deve identificar restrições da arquitetura:
� Ex: Requisitos que não serão possivelmente atingidos.
� O projeto também é documentado e transforma-se em uma 
parte do software.
Engenharia de Software
© Pablo Dall'Oglio
Projeto
� Mais próximo da implementação;
� Preocupa-se em “COMO” o sistema irá executar uma tarefa;
� Há a preocupação com a arquitetura que será utilizada; 
� Como as partes (componentes) do sistema serão construídas;
� Como estas partes irão interagir;
� Deverá preparar o modelo para um fácil mapeamento a uma 
Linguagem de Programação;
Engenharia de Software
© Pablo Dall'Oglio
Implementação
� Consiste na implementação do sistema;
� Transforma a necessidade em um produto de software;
� Esta é a etapa em que são criados os programas;
� Quanto melhor o trabalho das etapas anteriores, mais 
eficiente é o trabalho realizado nesta etapa;
� Por que ?
� Menos dúvidas, definições claras;
� Conhecimento já adquirido. 
� Etapa facilitada pela utilização de ferramentas;
� IDEs, Design Patterns;
� Frameworks.
Engenharia de Software
© Pablo Dall'Oglio
Implementação
Engenharia de Software
© Pablo Dall'Oglio
Teste
� É a investigação sobre a qualidade do software;
� Existem vários tipos de testes:
� O funcional testa a funcionalidade do sistema;
� O estrutural testa as lógicas internas;
� O teste funcional inclui a utilização do produto para 
encontrar seus defeitos;
� Alguns testes (estrutural) podem ser automatizados;
� Um teste avalia o comportamento do software;
� “Testes podem mostrar a presença de erros, não a sua 
ausência.” (Dijkstra).
Engenharia de Software
© Pablo Dall'Oglio
Teste
function soma(a, b)
{
return a+b;
}
function testa_soma()
{
soma(1,2) == 3; ?
soma(5,5) == 10; ?
soma(30,40) == 70; ?
soma(101,202) == 303; ?
soma(34,50) == 84; ?
}
Engenharia de Software
© Pablo Dall'Oglio
Manutenção
� É o processo de melhoria e otimização contínua do software;
� Conforme a ISO/IEC 14764, podem ser:
� Manutenção corretiva: Corrigir falhas (bugs);
� Manutenção adaptativa: Manter o software em 
funcionamento após mudança em ambiente (ex: versão do 
sistema operacional);
� Manutenção perfectiva: Melhorar desempenho ou 
manutenibilidade. (ex: melhor algoritmo);
� Manutenção preventiva: Corrigir falhas antes que elas se 
tornem efetivas. (ex: rotina anual).
Engenharia de Software
© Pablo Dall'Oglio
Características
� Só avança quando o cliente valida e aceita a etapa atual;
� Pressupõe que o cliente sabe muito bem o que quer;
� Pressupõe que o cliente participa ativamente do projeto;
� Se ele não souber, teremos muitas alterações (voltar);
� Para funcionar, é necessário ter um conjunto de requisitos 
precisos e exatos;
� Este modelo minimiza a aprendizagem adquirida no decorrer;
� Como evita-se voltar atrás, novas ideias são rejeitadas;
� Existem casos em que é necessário “voltar”:
� Ex: Usuário solicitou uma mudança, ou equipe aprendeu uma 
forma mais eficiente de implementar um algoritmo;
Engenharia de Software
© Pablo Dall'Oglio
Modelo em cascata
� As etapas de desenvolvimento seguem uma sequência: a 
saída da primeira etapa “flui” para a segunda etapa e a saída 
da segunda etapa “flui” para a terceira e assim por diante.
Engenharia de Software
© Pablo Dall'Oglio
Fases do modelo em cascata
� Análise de requisitos;
� Projeto ou design;
� Implementação ou desenvolvimento;
� Teste;
� Manutenção.
Engenharia de Software
© Pablo Dall'Oglio
Adoção do Modelo em Cascata
� As etapas descritas são as principais, porém:
� Cada projeto pode ter suas próprias sub-etapas;
� Um projeto pode ter uma etapa extra ou separar uma etapa 
em duas etapas;
� Independente disso, a característica principal (sequência) não 
muda;
� O conceito básico permanece: Uma etapa fornece saída que 
serão usadas como entradas para a etapa seguinte;
� Portanto, é simples de reconhecer um processo de em 
cascata.
Engenharia de Software
© Pablo Dall'Oglio
Problemas do modelo
� Alguns problemas que surgem na aplicação do modelo:
� Projetos raramente seguem o fluxo sequencial;
� A interação é sempre necessária, criando problemas na 
aplicação do modelo;
� É difícil para o cliente especificar os requisitos claramente, 
o que acarreta a incerteza no início do projeto;
� O cliente deve ser paciente, pois uma versão funcional não 
estará disponível até o final do desenvolvimento;
� Qualquer erro ou mal-entendido, se não for detectado até 
que o software seja revisado, pode ser desastroso.
Engenharia de Software
© Pablo Dall'Oglio
Modelo evolutivo ou prototipação
Engenharia de Software
© Pablo Dall'Oglio
Modelo evolutivo
� Permite o desenvolvedor a criar um protótipo de software;
� Antecipa ao usuário final um modelo de sistema;
� Permite ao usuário avaliar a finalidade e identificar erros;
� Processo:
� Inicia com a coleta de requisitos;
� Segue para um projeto rápido com aspectos visíveis ao cliente;
� Segue para uma construção de um protótipo;
� O protótipo é avaliado pelo cliente;
� A avaliação é usada para refinar os requisitos.
Engenharia de Software
© Pablo Dall'Oglio
Modelo evolutivo
� Neste modelo, o software evolui a partir de protótipos;
� O papel do protótipo é auxiliar no refinamento de requisitos;
� O protótipo não possui a melhor solução em arquitetura;
� Idealmente deve ser descartado para evitar perda de tempo com 
correções;
� As vezes o cliente não compreende que é um software 
incompleto;
� Na ânsia de atender o cliente, encurta-se o prazo do projeto 
evoluindo o próprio protótipo;
� Como prejuízo, acaba-se utilizando uma arquitetura longe da 
ideal, com algoritmos ineficientes.
Engenharia de Software© Pablo Dall'Oglio
Processo iterativo ou espiral
Engenharia de Software
© Pablo Dall'Oglio
Introdução
� O modelo em cascata é inspirado na engenharia tradicional:
� Existe uma clara separação entre projeto e construção;
� Requisitos são previsíveis e devem ser levantados previamente;
� Em software, nem sempre é possível obter com exatidão todos 
os requisitos de um projeto antes de sua construção, pois:
� O cliente gera novos requisitos na medida que utiliza o SW;
� Mudanças econômicas e sociais geram novos requisitos;
� Ex: mudanças em legislação fiscal e tributária (NFE, RH);
� �Ex: mudanças de moeda (Cruzeiro Real).
� Ver Tacoma Bridge.flv
Engenharia de Software
© Pablo Dall'Oglio
Requisitos
� Os requisitos sempre mudam;
� O cliente gera novas demandas e novas interpretações sobre o 
na medida em que vê os resultados e usa as primeiras versões;
� A natureza dinâmica da economia atual determina constantes 
mudanças sobre o que realmente tem valor para os negócios:
� Ex: mudanças sociais, econômicas, naturais.
� Isto influencia diretamente nas aplicações, que devem 
suportar estes processos;
� Neste caso, é necessário saber o que fazer quando da 
mudança.
Engenharia de Software
© Pablo Dall'Oglio
Mudança de requisitos
� Poucos projetos de software não passam por mudanças;
� Na mudança, há duas opções: resistir ou adaptar;
� Resistir:
� Permite seguir um planejamento;
� Mantém custo, prazo, escopo;
� Muitas vezes desagrada ao cliente;
� Adaptar:
� Gera mudanças no planejamento;
� Renegocia custo, prazo, escopo;
� Permite atender as necessidades do cliente.
Engenharia de Software
© Pablo Dall'Oglio
Mudança de requisitos
� O modelo em cascata tentam minimizar as mudanças, evitar 
que elas ocorram ao longo das fases;
� O modelo em cascata avança em bloco, não lida bem com os 
que ficaram para trás;
� O desenvolvimento iterativo é uma nova metodologia para 
lidar com requisitos em um ambiente com mudanças;
� O planejamento é realizado iteração pós iteração;
� O modelo iterativo permite que, a cada iteração, possam ser 
realizadas correções constantes nas etapas anteriores;
� Entretanto, após cada iteração ainda não teremos um 
software completo e integrado.
Engenharia de Software
© Pablo Dall'Oglio
Mudança de requisitos
Engenharia de Software
© Pablo Dall'Oglio
Mudança de requisitos
Engenharia de Software
© Pablo Dall'Oglio
Processo iterativo
� No processo iterativo, o processo é dividido em pequenas 
iterações (ciclos);
� Cada iteração realiza um pequeno ciclo completo:
� Análise, projeto, desenvolvimento, testes;
� Permite detectar erros de projeto logo que elas ocorram;
� Correções podem ser realizadas no próximo ciclo;
� Ex: Duas semanas para analisar e implementar 5 novas 
funcionalidades;
� A cada ciclo, é entregue ao cliente uma parte funcional do 
projeto.
Engenharia de Software
© Pablo Dall'Oglio
Processo iterativo
� Para que sempre ocorram entregas as iterações possuem 
tamanho (tempo) fixo, mas as funcionalidades (escopo) é 
variável.
� O processo iterativo entrega um melhor custo-benefício.
Engenharia de Software
© Pablo Dall'Oglio
Comparação entre modelos
Engenharia de Software
© Pablo Dall'Oglio
Comparação entre modelos
� Modelo em cascata:
� Tenta minimizar as mudanças;
� Avança em bloco;
� Voltado para ambientes estáveis;
� 47% sucesso, 36% não atingiu, e 17% falhas.
� Modelo iterativo:
� Voltado para ambientes com mudanças;
� Planejamento é realizado a cada iteração;
� Permite realizar correções nas etapas anteriores;
� 61% sucesso, 28% não atingiu, e 11% falhas.
Engenharia de Software
© Pablo Dall'Oglio
Características
Iterativo Cascata
Engenharia de Software
© Pablo Dall'Oglio
Características :: Tempo
Engenharia de Software
© Pablo Dall'Oglio
Características :: Escopo
Engenharia de Software
© Pablo Dall'Oglio
Características :: Custo
Engenharia de Software
© Pablo Dall'Oglio
Características :: Resumo
Engenharia de Software
© Pablo Dall'Oglio
Bibliografia
� MURTA, Leonardo Gresta Paulino. Apresentação do Curso de 
Engenharia de Software 2;
� DALL'OGLIO, Pablo. Uma Ferramenta para Gerenciamento de 
Requisitos em Projetos Baseados em Extreme Programming;
� http://pt.wikipedia.org/wiki/Engenharia_de_software
Engenharia de Software
© Pablo Dall'Oglio
Próxima atividade
� Vídeo:
� Gerenciamento de projetos - Atraso no Cronograma.mp4
� Questões para debate:
� Relate problemas de desenvolvimento de sistemas que você já 
vivenciou pela falta de engenharia de software;
� Quais argumentos você usaria para tentar convencer o cliente 
a contratar um projeto iterativo ?
� Dado um problema, dividir as atividades em um modelo.
� exercicio1.pdf