PRINCÍPIOS DA ENGENHARIA DE
SOFTWARE – AULA 01
Prof.: Franklin M. Correia
E-mail:
franklin.correia@bonfim.ifbaiano.edu.br
APRESENTAÇÃO
 Franklin Matos Correia
 Bacharel em Ciência da Computação
 Faculdade Ruy Barbosa – 2009
 Especialista em...
OBJETIVO
Conhecer e aplicar as metodologias, ferramentas,
procedimentos e boas práticas de Engenharia
de Software.
AVALIAÇÕES
 2 Provas + Trabalho
 Prova 1 (P1)
 Prova 2 (P2)
 Trabalho (Tb)
 Nota Final = (P1 + P2 )*7 + Tb * 3
DATAS AVALIAÇÕES
 Prova 1 - 12/09/2013*
 Revisão caso tenham dúvidas na primeira aula
 Prova 2 - 10/10/2013
 Revisão c...
OBSERVAÇÕES & ALERTAS
 Itens negociáveis
 Datas das provas
 Nunca no dia da prova
 Tipo de trabalho
 Nunca no dia da ...
O QUE TEMOS PRA HOJE??
 Introdução a Engenharia de Software
 O que é software?
 O que é Engenharia de Software?
 Conce...
CRISE DO SOFTWARE
 Termo Engenharia de software usando 1968
durante a crise do software.
 Produção de um novo hardware u...
ENGENHARIA DE SOFTWARE
 O que é Engenharia de Software?
 Ramo da engenharia cujo foco é o desenvolvimento
dentro de cust...
O QUE É ENGENHARIA DE SOFTWARE
Linguagens de
programação
Banco de Dados Infraestrutura
OutrosProjetos
Engenharia de Softwa...
O QUE É SOFTWARE?
 Software não é apenas o arquivo executável /
programa
 É o Programa de computador, toda documentação
...
TIPO DE PRODUTO SOFTWARE
 Produto de Software de Prateleira / Genéricos
 Chamado de stand-alone
 Criados de forma genér...
PROCESSO DE SOFTWARE
 Método utilizado para desenvolver ou produzir
um software.
 Define o que faz, como será feito e qu...
PROCESSO DE SOFTWARE
 Capaz de responder as perguntas:
 O que é feito? ===> Produto
 Como é feito? ===> Passos
 Por qu...
MODELO DE PROCESSO DE SOFTWARE
 Deve incorporar uma estratégia de
desenvolvimento
definição do
problema
desenvolvimento t...
MODELO DE PROCESSO DE SOFTWARE
 A modelagem é uma técnica de engenharia bem
aceita
 modelos de arquitetura de casas e de...
MODELO DE PROCESSO DE SOFTWARE
MODELO DE PROCESSO DE SOFTWARE
 O que é?
 Simplificação da realidade
 Planos podem ser:
 Reais - Organização do sistem...
MODELO DE PROCESSO DE SOFTWARE
 Objetivo
 Auxiliar ao gerente: controlar o processo de
desenvolvimento de sistemas de so...
MODELO X PROCESSO
 Modelo de software : documento teórico, conjunto
de possíveis ações
 Processo de software: deve deter...
PROCESSO DE SOFTWARE
Estudo de
viabilidade
Relatório
de viabilidade
Levantamento
e análise de
requisitos
Especificação
de ...
PROCESSO DE SOFTWARE
 Estudo de viabilidade
 Econômica – relação custo/benefício;
 Técnica – tecnologia e capacitação;
...
PROCESSO DE SOFTWARE
 Especificação de requisitos
 Documento contendo os requisitos do usuário e do
sistema
 Funcionais...
MODELO DE PROCESSO DE SOFTWARE
 Exemplo de modelos de processo:
 Workflow – sucessão de atividades
 Fluxo de dados – fl...
CICLO DE VIDA DE UM SOFTWARE
 Uma estratégia de desenvolvimento que englobe
processos, métodos e ferramentas, e as fases ...
CICLO DE VIDA DE UM SOFTWARE
 Modelo em Cascata - ciclo clássico
 Paradigma Evolucionário
 Prototipação
 Incremental
...
 Método sistemático e sequencial
 O resultado de uma fase se constitui na entrada
da outra
 Cada fase é estruturada com...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Engenharia de Sistemas
 Envolve a coleta de requisitos (nível de sistemas)
 Pequena quantidade de projetos
 Análise d...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Análise de Requisitos
 Envolve a coleta de requisitos (nível de usuário) de
forma intensa
 Compreensão do domínio, fun...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Projeto
 Requisitos do software -> Representações
 Avaliação de qualidade
 Anterior a codificação
 Concentram em 4 a...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Codificação
 Implementação
 Tradução do projeto em código computacional
 Instruções executáveis pelo computador
 Lin...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Testes
 Concentra os aspectos lógicos internos
 Garante o teste de funcionalidade (código)
 Nos aspectos funcionais e...
MODELO EM CASCATA (CICLO CLÁSSICO)
Engenharia de
Sistemas
Análise de
Requisitos
Projeto
Codificação
Testes
Manutenção
 Manutenção
 Alterações depois de entrega efetuada
 Mudanças ocorrem por:
 Erros
 Adaptação para acomodação de mudanç...
PROBLEMAS COM MODELO EM CASCATA
 Projetos raramente seguem o fluxo do modelo
 Dificuldade de estabelecer os requisitos n...
MODELO EM CASCATA – COMENTÁRIO
 Mesmo com as fragilidades, ele é
significativamente melhor que uma abordagem
aleatória de...
Upcoming SlideShare
Loading in …5
×

Introdução a engenharia de software aula 01

2,167 views

Published on

Introdução a Engenharia de Software - Aula 01
Curso de Licenciatura em Ciência da Computação
IFibaiano - Senhor do Bonfim

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,167
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
134
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Introdução a engenharia de software aula 01

  1. 1. PRINCÍPIOS DA ENGENHARIA DE SOFTWARE – AULA 01 Prof.: Franklin M. Correia E-mail: franklin.correia@bonfim.ifbaiano.edu.br
  2. 2. APRESENTAÇÃO  Franklin Matos Correia  Bacharel em Ciência da Computação  Faculdade Ruy Barbosa – 2009  Especialista em Engenharia de Software  Faculdade Ruy Barbosa 2013
  3. 3. OBJETIVO Conhecer e aplicar as metodologias, ferramentas, procedimentos e boas práticas de Engenharia de Software.
  4. 4. AVALIAÇÕES  2 Provas + Trabalho  Prova 1 (P1)  Prova 2 (P2)  Trabalho (Tb)  Nota Final = (P1 + P2 )*7 + Tb * 3
  5. 5. DATAS AVALIAÇÕES  Prova 1 - 12/09/2013*  Revisão caso tenham dúvidas na primeira aula  Prova 2 - 10/10/2013  Revisão caso tenham dúvidas na primeira aula  Inclui também os assuntos da Prova 1  Trabalho – Seminário / Estudo de Caso – 17 e 24/10/2013  30 minutos.  Prova final  Assuntos do semestre inteiro.
  6. 6. OBSERVAÇÕES & ALERTAS  Itens negociáveis  Datas das provas  Nunca no dia da prova  Tipo de trabalho  Nunca no dia da apresentação / entrega  Itens inegociáveis  Quantidade de provas  Trabalho  Data do trabalho  4 aulas/dia  2 aulas +intervalo de 10 minutos + 2 aulas.  1 aula = 50 minutos
  7. 7. O QUE TEMOS PRA HOJE??  Introdução a Engenharia de Software  O que é software?  O que é Engenharia de Software?  Conceitos importantes  Tipos de Produtos  Processo de software  Fazes do processo de software  Modelos de Processo de software
  8. 8. CRISE DO SOFTWARE  Termo Engenharia de software usando 1968 durante a crise do software.  Produção de um novo hardware usando circuitos integrados  Aplicações inviáveis tornaram-se realizáveis  Construção informal de software  Atrasos exorbitantes  Alto custo de construção de software  Custo do hardware caindo e de software subindo  Criação de técnicas para controle da produção do software
  9. 9. ENGENHARIA DE SOFTWARE  O que é Engenharia de Software?  Ramo da engenharia cujo foco é o desenvolvimento dentro de custos adequados de sistemas de software de qualidade. Software é abstrato, intangível , não é limitado por materiais, ou controlado por leis físicas ou por processos de manufatura (Sommerville, 2003).
  10. 10. O QUE É ENGENHARIA DE SOFTWARE Linguagens de programação Banco de Dados Infraestrutura OutrosProjetos Engenharia de Software
  11. 11. O QUE É SOFTWARE?  Software não é apenas o arquivo executável / programa  É o Programa de computador, toda documentação associada(arquivos de configuração, manual de instalação e utilização) e o banco de dados.  Podem ser desenvolvidos para um cliente específico ou para um mercado geral
  12. 12. TIPO DE PRODUTO SOFTWARE  Produto de Software de Prateleira / Genéricos  Chamado de stand-alone  Criados de forma genérica, para qualquer empresa.  Controle de estoque  Controle de farmácia  Programas de Contabilidade  Produtos sob encomenda / Personalizados  Software criados com objetivo de prover uma solução específica para um cliente específico  Software para dispositivos eletrônicos: Geladeiras, jogões, micro-ondas  Sistema de controle de tráfego aéreo
  13. 13. PROCESSO DE SOFTWARE  Método utilizado para desenvolver ou produzir um software.  Define o que faz, como será feito e quando será feito
  14. 14. PROCESSO DE SOFTWARE  Capaz de responder as perguntas:  O que é feito? ===> Produto  Como é feito? ===> Passos  Por quem é feito? ===> Agente  O que usa? ===> Insumos  O que produz? ===> Resultados
  15. 15. MODELO DE PROCESSO DE SOFTWARE  Deve incorporar uma estratégia de desenvolvimento definição do problema desenvolvimento técnico integração da solução estado atual
  16. 16. MODELO DE PROCESSO DE SOFTWARE  A modelagem é uma técnica de engenharia bem aceita  modelos de arquitetura de casas e de grandes prédios  modelos matemáticos a fim de analisar os efeitos de ventos e tremores de terra --> causas
  17. 17. MODELO DE PROCESSO DE SOFTWARE
  18. 18. MODELO DE PROCESSO DE SOFTWARE  O que é?  Simplificação da realidade  Planos podem ser:  Reais - Organização do sistema  Comportamentais – dinâmica do sistema  Porque é importante construir modelos?  Melhor entendimento do sistema que está sendo construído  Especificar a estrutura e comportamento  Guia a construção do sistema  Documenta as decisões tomadas
  19. 19. MODELO DE PROCESSO DE SOFTWARE  Objetivo  Auxiliar ao gerente: controlar o processo de desenvolvimento de sistemas de software.  Auxiliar ao desenvolvedor: obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos pré-estabelecidos.
  20. 20. MODELO X PROCESSO  Modelo de software : documento teórico, conjunto de possíveis ações  Processo de software: deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e métricas para se avaliar como elas estão sendo realizadas
  21. 21. PROCESSO DE SOFTWARE Estudo de viabilidade Relatório de viabilidade Levantamento e análise de requisitos Especificação de requisitos Validação de requisitos Modelos de sistemas Requisitos do usuário e do sistema Documenta ção de requisitos
  22. 22. PROCESSO DE SOFTWARE  Estudo de viabilidade  Econômica – relação custo/benefício;  Técnica – tecnologia e capacitação;  Jurídica – aspectos legais  Levantamento de Análise de Requisitos  Entrevista  Observação  Reuniões
  23. 23. PROCESSO DE SOFTWARE  Especificação de requisitos  Documento contendo os requisitos do usuário e do sistema  Funcionais e não funcionais  Validação de requisitos  Avaliação do documento de requisitos – consistência e integridade
  24. 24. MODELO DE PROCESSO DE SOFTWARE  Exemplo de modelos de processo:  Workflow – sucessão de atividades  Fluxo de dados – fluxo de informação  Papel / Ação – representa os papeis das pessoas e as atividades pelas quais elas são responsáveis
  25. 25. CICLO DE VIDA DE UM SOFTWARE  Uma estratégia de desenvolvimento que englobe processos, métodos e ferramentas, e as fases de desenvolvimento...
  26. 26. CICLO DE VIDA DE UM SOFTWARE  Modelo em Cascata - ciclo clássico  Paradigma Evolucionário  Prototipação  Incremental  Espiral  Métodos Ágeis  Modelos Formais  Técnicas de 4ª Geração  Orientado a Reuso
  27. 27.  Método sistemático e sequencial  O resultado de uma fase se constitui na entrada da outra  Cada fase é estruturada como um conjunto de atividades que podem ser executadas por pessoas diferentes MODELO EM CASCATA (CICLO CLÁSSICO)
  28. 28. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  29. 29. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  30. 30.  Engenharia de Sistemas  Envolve a coleta de requisitos (nível de sistemas)  Pequena quantidade de projetos  Análise de alto nível  Importante quando o sistema fizer interface com outros elementos (hardware, pessoas e banco de dados) MODELO EM CASCATA (CICLO CLÁSSICO)
  31. 31. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  32. 32.  Análise de Requisitos  Envolve a coleta de requisitos (nível de usuário) de forma intensa  Compreensão do domínio, função, desempenho e interface necessários  Os requisitos são documentados e revistos com o cliente MODELO EM CASCATA (CICLO CLÁSSICO)
  33. 33. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  34. 34.  Projeto  Requisitos do software -> Representações  Avaliação de qualidade  Anterior a codificação  Concentram em 4 atributos  Estrutura de dados  Arquitetura  Detalhes de procedimentos  Caracterização de interface MODELO EM CASCATA (CICLO CLÁSSICO)
  35. 35. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  36. 36.  Codificação  Implementação  Tradução do projeto em código computacional  Instruções executáveis pelo computador  Linguagens de programação ( alto ou baixo nível )  Quanto mais coeso o projeto e os requisitos mais rápida é a codificação MODELO EM CASCATA (CICLO CLÁSSICO)
  37. 37. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  38. 38.  Testes  Concentra os aspectos lógicos internos  Garante o teste de funcionalidade (código)  Nos aspectos funcionais externos  Descobrir erros (teste de funcionalidade)  Entrada x produz saída y  Garantir a confiabilidade MODELO EM CASCATA (CICLO CLÁSSICO)
  39. 39. MODELO EM CASCATA (CICLO CLÁSSICO) Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
  40. 40.  Manutenção  Alterações depois de entrega efetuada  Mudanças ocorrem por:  Erros  Adaptação para acomodação de mudanças em processo organizacional  Exigência do cliente para acréscimo funcional  Em decorrência do desempenho MODELO EM CASCATA (CICLO CLÁSSICO)
  41. 41. PROBLEMAS COM MODELO EM CASCATA  Projetos raramente seguem o fluxo do modelo  Dificuldade de estabelecer os requisitos no início do projeto  O cliente deve ter paciência  Uma versão do produto só ficará disponível numa etapa avançada de desenvolvimento
  42. 42. MODELO EM CASCATA – COMENTÁRIO  Mesmo com as fragilidades, ele é significativamente melhor que uma abordagem aleatória de desenvolvimento.  Embora a entrega de uma versão “beta” seja tardia o resultado é satisfatório porem demorado.

×