1 / 26

Engenharia de Software: Teoria e Prática Por que Engenharia de Software

Engenharia de Software: Teoria e Prática Por que Engenharia de Software. Elaine Harada Teixeira de Oliveira Extraído do livro de Shari L. Pfleeger 1o. semestre/2004. Tópicos da aula. O que é engenharia de software? O histórico da engenharia de software O que é um ‘bom software’?

september
Download Presentation

Engenharia de Software: Teoria e Prática Por que Engenharia de Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Engenharia de Software: Teoria e PráticaPor que Engenharia de Software Elaine Harada Teixeira de Oliveira Extraído do livro de Shari L. Pfleeger 1o. semestre/2004

  2. Tópicos da aula • O que é engenharia de software? • O histórico da engenharia de software • O que é um ‘bom software’? • Por que uma abordagem de sistemas é importante • Como a engenharia de software vem mudando desde a década de 70 Capítulo 1

  3. Por que a engenharia de software? • Análise versus síntese de um problema O processo de análise Capítulo 1

  4. Por que a engenharia de software? • Análise versus síntese de um problema O processo de síntese Capítulo 1

  5. Por que a engenharia de software? • Método ou técnica: procedimento para a produção de um resultado. • Ferramenta: instrumento ou sistema automatizado para realizar alguma coisa. • Procedimento: receita de combinação de ferramentas e técnicas. • Paradigma: estilo de fazer algo, representa uma abordagem ou filosofia para a construção de software. Ex.: um chefe de cozinha prepara um molho combinando ingredientes em uma ordem e momentos específicos. Ex.: máquina de escrever, tesoura. Ex.: plano de testes. Ex.: cozinha francesa, chinesa, orientado a objetos, procedural. Capítulo 1

  6. Qualidade — Terminologias Terminologia padrão, segundo IEEE Standard 729 • Erro: erro humano • Defeito: resultado do erro evidenciado em algum desenvolvimento ou manutenção do produto • Falha: divergência entre o comportamento requerido para o sistema e o comportamento real. Como o erro humano causa uma falha Capítulo 1

  7. Perspectivas de Garvin (1984) sobre qualidade • Visão transcendental: algo que podemos reconhecer, mas não definir • Visão do usuário: conveniência para propósito pretendido • Visão do fabricante: conformidade com especificação • Visão do produto: relação com as características inerentes ao produto • Visão do mercado: dependência de quanto os consumidores estão dispostos a pagar Capítulo 1

  8. Abordagem de sistemas • Identificar atividades e objetos. • Definir as relações e fronteiras do sistema. • Considerar sistemas inter-relacionados. Participantes no desenvolvimento de software Capítulo 1

  9. Abordagem de sistemas O sistema respiratório Capítulo 1

  10. Abordagem de sistemas Definição do sistema de produção de contracheques Capítulo 1

  11. Identificar e analisar os requisitos Produzir e documentar todo o projeto Detalhar as especificações Identificar e projetar os componentes Construir cada componente Testar cada componente Integrar os componentes Fazer as modificações finais Manutenção contínua Análise e definição dos requisitos Projeto do sistema Projeto do programa Escrever os programas Testes das unidades Teste de integração Teste do sistema Entrega do sistema Manutenção Construindo uma casa versus um software Capítulo 1

  12. Membros de uma equipe de desenvolvimento Os papéis da equipe de desenvolvimento Capítulo 1

  13. Fatores-chave que mudaram a prática da engenharia de software (Wasserman) • Aspecto crítico do tempo para entrega do produto ao mercado, no caso de produtos comerciais • Mudanças na economia da computação (redução dos custos de hardware e aumento nos custos de desenvolvimento e manutenção) • Disponibilidade poderosa da computação em desktops • Aumento das redes locais e remotas • Disponibilidade e adoção da tecnologia orientada a objetos • Uso de interfaces gráficas • Imprevisibilidade do modelo de desenvolvimento de software cascata Capítulo 1

  14. Fatores-chave que mudaram a prática da engenharia de software (Wasserman) Os fatores-chave que mudaram o desenvolvimento de software Capítulo 1

  15. Disciplina de engenharia de software de Wasserman Oito noções fundamentais que formam a base de uma disciplina de engenharia de software efetiva: • Abstração • Métodos e notações de análise e projeto • Protótipo da interface com o usuário • Arquitetura de software • Processo de software • Reuso • Medição • Ferramentas e ambientes integrados Capítulo 1

  16. Abstração • Descrição de um problema com um nível de generalização que permite concentrar nos aspectos principais do problema, sem se perder nos detalhes Hierarquia simples de monitoração de equipamento Capítulo 1

  17. Arquitetura de software • A arquitetura de sistemas descreve o sistema em termos de um conjunto de unidades arquitetônicas e um mapa de como essas unidades se relacionam entre si. • Wasserman (1996) mostra cinco modos de dividir o sistema em unidades: • decomposição modular – baseada na atribuição de funções aos módulos • decomposição orientada a dados – baseada em estruturas de dados externas • decomposição orientada a eventos – baseada nos eventos com os quais o sistema deve lidar • projeto ‘de fora para dentro’ – baseado nas entradas dos usuários no sistema • projeto orientado a objetos – baseado na identificação de classes de objetos e suas inter-relações Capítulo 1

  18. Processo de desenvolvimento de software • Processo de desenvolvimento de software - qualquer descrição do desenvolvimento de software que contenha algumas das nove atividades ao lado, organizadas de tal modo que, juntas, produzam um código testado. • Análise e definição dos requisitos • Projeto do sistema • Projeto do programa • Escrever os programas • Testes das unidades • Teste de integração • Teste do sistema • Entrega do sistema • Manutenção Capítulo 1

  19. Processo de desenvolvimento de software Diferenças no desenvolvimento (Wasserman, 1996) Capítulo 1

  20. Medição • Palavra-chave: aprimoramento Utilizando medição para ajudar a encontrar uma solução Capítulo 1

  21. Exemplos de sistema de informação • Piccadily Television: TV regional britânica • Anunciante comercial tem diversas alternativas: • Propagandas de bebidas alcoólicas só podem ser apresentadas depois das 21 horas • Se um ator está em um programa, então um anúncio com o mesmo autor não pode ser transmitido antes de 45 minutos após o término do programa • Se um anúncio para a classe de produtos está programado para um dado intervalo comercial, então nenhum outro anúncio para outro produto dessa mesma classe pode ser apresentado nesse intervalo • Taxa depende do valor de tempo comprado • Software determina o controle de tempo do anúncio Capítulo 1

  22. Exemplos de sistema de informação Área de cobertura da Piccadilly Television Capítulo 1

  23. Exemplos de sistema de informação Diagrama de contexto da TV Piccadilly mostrando as fronteiras do sistema (Robertson e Robertson, 1994) Capítulo 1

  24. Exemplo de tempo real • Ariane-5, foguete espacial da European Space Agency • 4 de junho de 1996: atuou perfeitamente por 40 segundos, quando começou a sair do curso e foi destruído • Continha quatro satélites: o custo foi de U$ 500 milhões Capítulo 1

  25. Ariane-5 — definição de qualidade • Do relatório de Lionset al. (1996): • “… na documentação que demonstrou a alta qualidade do programa Ariane-5 com relação ao trabalho dos engenheiros em geral e também ao grau de perfeição e rastreabilidade dos documentos”. • “… o fornecedor do SRI … estava apenas seguindo as especificações que lhe foram dadas. … A exceção foi detectada mas tratada de maneira não apropriada, porque, segundo o enfoque adotado, o software deveria ser considerado correto até que fosse evidenciado um defeito”. Capítulo 1

  26. Referências Bibliográficas • GARVIN, D. What does ‘product quality’ really mean? Sloan Management Review, p.25-45, 1984. • LIONS, J. L. et al. Ariane 5 Flight 501 Failure: report by the inquiry board. European Space Agency, 1996. • PFLEEFER, Shari L. Engenharia de software: teoria e prática, 2. ed. São Paulo: Prentice Hall, 2004. • WASSERMAN, A. I. Toward a discipline of software engineering. IEEE Software, v.13, n.6, p.23-31. Nov. 1996. • ROBERTSON, James; ROBERTSON, Suzanne. Complete systems analysis: the workbook, the textbook, the answers. Nova York: Dorst House Publishing,1994. Capítulo 1

More Related