Engenharia de Software - Introdução e Motivação (Marcello Thiry)

914 visualizações

Publicada em

Material de aula das disciplinas de Engenharia de Software
Introdução e Motivação
Universidade do Vale do Itajaí
Univali
Incremental Tecnologia
Versão em Português

Publicada em: Educação
0 comentários
9 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
914
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
86
Comentários
0
Gostaram
9
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Engenharia de Software - Introdução e Motivação (Marcello Thiry)

  1. 1. marcello.thiry@gmail.comIntrodução e motivação
  2. 2. O que você está fazendo aqui?
  3. 3. http://c4.quickcachr.fotos.sapo.pt/i/o51010754/6042055_Jtk8U.jpeg Eu deveria ter a resposta!?
  4. 4. Aqui diz que iremos aprender Engenharia de Software!! http://i0.wp.com/www.nerdglaze.com/wp- content/uploads/2013/08/nerdy-dude.jpg?resize=450%2C305
  5. 5. marcello.thiry@gmail.com http://ideas.scup.com/pt/files/2013/06/conte%C3%BAdo.jpg 1. Engenharia 2. Crise do Software 3. Relevância do software 4. Engenharia de Software 5. Software e suas características 6. Qualidade e Qualidade de Software 7. Tipos e domínios de software Conteúdo.
  6. 6. marcello.thiry@gmail.com criar, fabricar, construir, fazer, compor, inventar, ... Engenhar. https://awordfromafriend.files.wordpress.com/2014/10/blocktower.jpg?w=500
  7. 7. marcello.thiry@gmail.com criar, fabricar, construir, fazer, compor, inventar, ... Engenhar.
  8. 8. marcello.thiry@gmail.com Engenharia. Aplicar métodos científicos ou empíricos
  9. 9. marcello.thiry@gmail.com Engenharia. Aplicar métodos científicos ou empíricos para criar, melhorar e implementar
  10. 10. marcello.thiry@gmail.com Engenharia. Aplicar métodos científicos ou empíricos para criar, melhorar e implementar utilidades
  11. 11. marcello.thiry@gmail.com Uma utilidade deve realizar uma determinada função ou objetivo
  12. 12. Como desenvolver algo útil?
  13. 13. marcello.thiry@gmail.com  Estudar o problema  Planejar uma solução  Verificar a viabilidade econômica e técnica  Coordenar a construção
  14. 14. Mas o que é Software?
  15. 15. marcello.thiry@gmail.com John Tukey (1915-2000) https://en.wikipedia.org/?title=John_Tukey “In 1958, John Tukey, the world-renowned statistician, coined the term software” (SWEBOK, 2014)
  16. 16. marcello.thiry@gmail.com Conjunto de programas de computador, procedimentos e possível documentação associada, e dados relacionados à operação de um sistema de computador Software. (IEEE Std 610.12.1990)
  17. 17. marcello.thiry@gmail.com Documentação?! Sim, documentação! Mas, falaremos mais sobre isso durante a disciplina
  18. 18. marcello.thiry@gmail.com Apenas um lembrete: A parte difícil é produzir documentação útil!!!
  19. 19. Logo, Engenharia de Software...
  20. 20. marcello.thiry@gmail.com Engenharia de Software. Aplicar métodos científicos ou empíricos para criar, melhorar e implementar software
  21. 21. marcello.thiry@gmail.com “The term software engineering was used in the title of a NATO conference held in Germany in 1968” http://homepages.cs.ncl.ac.uk/brian.randell/NATO/
  22. 22. Como surgiu a Engenharia de Software?
  23. 23. Back in the day... Popular Science, Jan 1965, 107 Business Week, Nov 5, 1966, 127. http://thecomputerboys.com/?tag=crisis http://thecomputerboys.com/?tag=crisis
  24. 24. marcello.thiry@gmail.com “Software Crisis” or “Software Gap” Late 1960s, early 1970s...
  25. 25. marcello.thiry@gmail.com Late 1960s, early 1970s... •Vários projetos de software estavam falhando ou sendo abandonados • Atrasos • Acima do orçamento • Software não confiável e de difícil manutenção • Dificuldade em atender aos requisitos dos clientes A crise... https://kathleenkerridge.files.wordpress.com/2015/02/depre ssion-week-image-300x300.jpg?w=300
  26. 26. marcello.thiry@gmail.com Late 1960s, early 1970s... •Computadores mais potentes e linguagens de programação mais robustas • Crescimento da demanda • Software mais complexos • Mais pessoas envolvidas A crise... https://pamsblog666.files.wordpress.com/2011/06/computer20studies.jpg
  27. 27. marcello.thiry@gmail.com Late 1960s, early 1970s... •Formação de profissionais • Metodologias • Comunicação com clientes • Trabalho em equipe A crise... http://eolocomunicacion.com/wp-content/uploads/2015/05/fusionyadquisiciondempresas-e1431067600969.png
  28. 28. E hoje?
  29. 29. Software is everywhere...
  30. 30. marcello.thiry@gmail.com  The avionics system in the F-22 Raptor consists of about 1.7 Million LOC  The Boeing’s 787 Dreamliner contains about 6.5 million LOC  A premium-class automobile contains close to 100 million LOC http://spectrum.ieee.org/transportation/systems/this-car-runs-on-code LOC = lines of software code http://3.bp.blogspot.com/-- ae42w82PVo/VEU2EOJmQXI/AAAAAAAABoM/x5vv azR_BQM/s1600/homer-screaming.gif
  31. 31. marcello.thiry@gmail.com Computação ubíqua ou pervasiva? As pessoas nem percebem mais como a computação faz parte do dia a dia delas E qual o impacto disso no software? http://betanews.com/wp- content/uploads/2014/09/Internet-of-things.jpg
  32. 32. marcello.thiry@gmail.com Você percebe a relevância do software nos dias de hoje? E qual é o seu papel nisso tudo? https://portalbuzzuserfiles.s3.amazonaws.com/ou- 15436/userfiles/images/pointing%20finger.jpg
  33. 33. Vamos definir Engenharia de Software formalmente
  34. 34. marcello.thiry@gmail.com (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE Std 610.12.1990)
  35. 35. marcello.thiry@gmail.com (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE Std 610.12.1990)
  36. 36. marcello.thiry@gmail.com (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE Std 610.12.1990)
  37. 37. marcello.thiry@gmail.com (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE Std 610.12.1990)
  38. 38. marcello.thiry@gmail.com (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE Std 610.12.1990)
  39. 39. marcello.thiry@gmail.com
  40. 40. marcello.thiry@gmail.com http://mrbakersgrade6.weebly.com/uploads/ 2/4/7/6/24767728/6979844.jpg?339
  41. 41. marcello.thiry@gmail.com Systematic Principles Discipline Knowledge Maintenance Operation Development Reliable Application Technique Method Approach Quality Software Procedures Methodology Team Scientific Practical Design Tool Productivity
  42. 42. marcello.thiry@gmail.com E se você tivesse que explicar a natureza do software agora? Isso era uma pergunta!
  43. 43. Eu preciso entender a natureza do software...
  44. 44. marcello.thiry@gmail.com Frederick Phillips Brooks, Jr. (1931-) https://en.wikipedia.org/wiki/Fred_Brooks “In 1986, Fred Brooks wrote the famous paper No Silver Bullet – Essence and Accident of Software Engineering” http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf American computer architect, software engineer, and computer scientist. He is also the author of the seminal book “The Mythical Man-Month (1975)”.
  45. 45. marcello.thiry@gmail.com http://www.polyvore.com/cgi/img- thing?.out=jpg&size=l&tid=32131103 “… building software will always be hard. There is no silver bullet.” (Brooks, 1986) Não há uma técnica ou tecnologia única que pode melhorar algum aspecto do desenvolvimento de software 10x em 10 anos…
  46. 46. Por que?
  47. 47. marcello.thiry@gmail.com Essência Dificuldades no Desenvolvimento de Software Acidentes Inerente à natureza do software Mapear a especificação para o software e Verificar se a solução realmente atende às necessidades do negócio Relacionados com a produção do software e não são inerentes Brooks, 1986 A maioria dos métodos e técnicas atacam os acidentes
  48. 48. marcello.thiry@gmail.com Apenas um lembrete: Acidental Acontecer ao acaso Incidente Brooks “refired” his paper 10 years later in the book The Mythical Man-Month, 20th Anniversary Edition, 1995 problemas que os engenheiros criam e podem resolver Relacionado com o processo de implementação
  49. 49. Vamos iniciar com a Essência…
  50. 50. marcello.thiry@gmail.com
  51. 51. marcello.thiry@gmail.com Simple huh!? http://www.ideo.com/work/atm-interface
  52. 52. marcello.thiry@gmail.com Não existem duas partes iguais Se elas existem, deveríamos usar sub-rotinas Diferença com elementos usados em outros domínios Alta quantidade de estados Impossível enumerar todos
  53. 53. marcello.thiry@gmail.com Não há como abstrair completamente a complexidade por que ela é essencial Domínios complexos Aviação Telecomunicações Sistema bancário Área da saúde … Nós ainda precisaremos modelar e implementar estas complexidades
  54. 54. marcello.thiry@gmail.com Consequências técnicas Dificuldades de comunicação Falhas no produto, custos acima do planejado, atrasos, … Dificuldade de enumerar, entender e antecipar todos os estados possíveis Baixa confiabilidade, quebras de segurança Dificuldade de manutenção Introdução de defeitos, difícil de entender, difícil de usar
  55. 55. marcello.thiry@gmail.com Consequências gerenciais Visão geral do projeto é difícil Fraca gerência de conhecimento Rotatividade é um grande problema
  56. 56. marcello.thiry@gmail.com
  57. 57. marcello.thiry@gmail.com Software deve estar em conformidade com limitações arbitrárias Impostas por instituições humanas e sistemas normas e regras Sujeitas a alterações arbitrárias É difícil planejar Pode ocorrer mais tarde no projeto
  58. 58. marcello.thiry@gmail.com Software precisa estar em conformidade com sistemas existentes Software precisa estar em conformidade com seu ambiente http://www.ktckids.com/images/puzzlePieces.png
  59. 59. marcello.thiry@gmail.com
  60. 60. marcello.thiry@gmail.com Mudança contínua das necessidades dos usuários Ilusão de fácil maleabilidade http://pipllp.com/wp-content/uploads/2014/09/evolution-of-cars_CKO.jpg Maior pressão para modificar o software
  61. 61. marcello.thiry@gmail.com
  62. 62. marcello.thiry@gmail.com Onde está o software? Produto intangível http://img.gfx.no/806/806035/original.628x353.jpg Não há uma representação geométrica
  63. 63. marcello.thiry@gmail.com Nós precisamos usar diferentes representações para modelar diferentes aspectos do software Na UML 2.2 existem 14 tipos de diagramas http://i.stack.imgur.com/8tmN9.jpg
  64. 64. Como atacar a essência…
  65. 65. marcello.thiry@gmail.com Refinamento dos requisitos Desenvolvimento incremental Fazer o software crescer, não construi-lo Grandes projetistas Prototipação rápida Identificá-los, desenvolvê-los e mantê-los Reusar Comprar ao invés de desenvolver
  66. 66. E sobre os acidentes…
  67. 67. marcello.thiry@gmail.com Alguns avanços ajudaram a reduzir dificuldades acidentais… Linguagens de alto-nível Time-sharing Ambientes e ferramentas de programação Desenvolvimento orientado a objetos Verificação …
  68. 68. marcello.thiry@gmail.com http://www.infoq.com/articles/No-Silver-Bullet-Summary Leitura interessante… No Silver Bullet Reloaded Retrospective OOPSLA Panel Summary http://cliparts.co/cliparts/dc9/6kL/dc96kLRc7.png
  69. 69. Mas espere, tem mais…
  70. 70. marcello.thiry@gmail.com
  71. 71. marcello.thiry@gmail.com O Software se DESGASTA com o tempo? http://chrishowardbooks.com/img/easter-egg-graphics/car.png
  72. 72. Claro que não! Mas...
  73. 73. Estava funcionando antes... ... da maldita atualização! https://www.careeraddict.com/Surprised_Businessman.jpg
  74. 74. marcello.thiry@gmail.com O Software se DETERIORA quando... introduzimos um defeito ao modificá-lo ocorrem mudanças no ambiente que não puderam ser previstas pelo projetista
  75. 75. marcello.thiry@gmail.com Pressman, 2015
  76. 76. marcello.thiry@gmail.com Claro, estamos considerando que o software não veio “podre” de fábrica! http://spc.fotolog.com/photo/44/42/36/deselingue/1200006994_f.jpg
  77. 77. marcello.thiry@gmail.com E qual é o seu papel nisso tudo?
  78. 78. marcello.thiry@gmail.com Devemos nos preocupar com a qualidade do que entregamos! http://www.aw3i.com/images/posts/sid_zen_dressdown.jpg
  79. 79. marcello.thiry@gmail.com Qualidade? https://pbs.twimg.com/profile_images/434052607297191936/ZRHhp8Fx.jpeg
  80. 80. marcello.thiry@gmail.com x Considere estes dois produtos... http://hobby-armada.com/images/item/tamiya/sportscar/292.jpg http://cdn.inaxiom.net/web/wp-content/uploads/2011/08/Ford-Ka-2011-06.jpg
  81. 81. Qual tem mais qualidade? http://www.tvmost.com.hk/most/uploads/images/2015/Article/2015.07/2015.07.23/pigteammate/005.jpg
  82. 82. marcello.thiry@gmail.com Quais as características esperadas de cada um? Qualidade é o “grau no qual um conjunto de características inerentes satisfaz a requisitos” ISO 9000, 2015
  83. 83. marcello.thiry@gmail.com Problemas com a qualidade O carro esportivo não alcançou a potência estabelecida O carro popular está com um consumo superior ao esperado
  84. 84. marcello.thiry@gmail.com Classe* é uma “categoria ou classificação atribuída a diferentes requisitos da qualidade para produtos, processos ou sistemas que têm o mesmo uso funcional” Diferentes características técnicas 1 linha, 1 classe, ... 2 linha, 2 classe, ... Em inglês: Grade. PMBOK (2013) adota o termo “grau”* ISO 9000, 2015
  85. 85. marcello.thiry@gmail.com Pegou a ideia!? http://www.clickgratis.com.br/fotos-imagens/saca- rolha/aHR0cDovL2lzaG9wLnM4LmNvbS5ici9wcm9kdXRvcy8 wMS8wMS9pdGVtLzI4OC82LzI4ODY2N18zR0cuanBn.jpg http://www.clickgratis.com.br/fotos-imagens/saca- rolha/aHR0cHM6Ly91cGxvYWQud2lraW1lZGlhLm9yZy93aWtpcGVkaWEvY29tbW9ucy90aHVtYi9lL 2U1L0tvcmtlbnppZWhlcl8wMV9LTUouanBnLzIwMHB4LUtvcmtlbnppZWhlcl8wMV9LTUouanBn.jpg
  86. 86. marcello.thiry@gmail.com
  87. 87. marcello.thiry@gmail.com Difícil definir Difícil medir Diferentes percepções http://www.bms.co.in/wp-content/uploads/2014/11/Customer-Decision.jpg http://businessanalytics.pt/wp- content/uploads/2013/01/Lupa- 300x268.jpg
  88. 88. E Qualidade de Software?
  89. 89. marcello.thiry@gmail.com http://images.clipartpanda.com/happy-computer-user-happy-computeruser.png http://images.clipartpanda.com/stressor-clipart-computer-stress.jpg
  90. 90. marcello.thiry@gmail.com Capability of software product to satisfy stated and implied needs when used under specified conditions (ISO/IEC 25000, 2014) Software Quality.
  91. 91. marcello.thiry@gmail.com Capacidade de um produto de software de satisfazer às necessidades explícitas e implícitas quando utilizado sob condições especificadas (ISO/IEC 25000, 2014) Qualidade de software.
  92. 92. marcello.thiry@gmail.com Produto? https://pixabay.com/pt/caixa-papel%C3%A3o- pacote-parcela-brown-158523/
  93. 93. Artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. Additional words for products are material and goods. (PMBOK, 2013) also used by (ISO/IEC 25000, 2014) Product.
  94. 94. marcello.thiry@gmail.com O PMBOK diferencia os termos PRODUTO (tangível) e SERVIÇO (intangível) Um produto pode ser:  um componente de outro item  um aprimoramento de outro item  um item final PMBOK - Um Guia do Conhecimento em Gerenciamento de Projetos
  95. 95. marcello.thiry@gmail.com Produto de software Pronto para ser liberado ao usuário Precisa ser verificado e validado
  96. 96. marcello.thiry@gmail.com Capacidade de um produto de software de satisfazer às necessidades explícitas e implícitas quando utilizado sob condições especificadas (ISO/IEC 25000, 2014) Qualidade de software.
  97. 97. marcello.thiry@gmail.com Capacidade de um produto de software de satisfazer às necessidades explícitas e implícitas quando utilizado sob condições especificadas (ISO/IEC 25000, 2014) Qualidade de software.
  98. 98. Especificação do software http://blog.axen.pro/wp-content/uploads/2013/06/Writing-Quality-Software-Requirements.png
  99. 99. marcello.thiry@gmail.com Capacidade de um produto de software de satisfazer às necessidades explícitas e implícitas quando utilizado sob condições especificadas (ISO/IEC 25000, 2014) Qualidade de software.
  100. 100. marcello.thiry@gmail.com E o que não está escrito? O que o usuário espera?http://www.handymanstartup.com/wp- content/uploads/2013/02/IMG_Customer_rating_buttons.jpg
  101. 101. marcello.thiry@gmail.com Capacidade de um produto de software de satisfazer às necessidades explícitas e implícitas quando utilizado sob condições especificadas (ISO/IEC 25000, 2014) Qualidade de software.
  102. 102. marcello.thiry@gmail.com Does the USE really matters? https://d3ui957tjb5bqd.cloudfront.net/images/screenshots/products/7/79/79359/hammer-o.jpg?1393432661
  103. 103. Ok, entendi! Mas todo software é igual?
  104. 104. marcello.thiry@gmail.com Nós podemos classificar produtos de software? http://blog.globalknowledge.com/wp- content/uploads/2011/08/squarehole95615108.jpg
  105. 105. marcello.thiry@gmail.com
  106. 106. marcello.thiry@gmail.com
  107. 107. marcello.thiry@gmail.com Um produto de software pode ser: De prateleira - COTS http://tynmedia.com/tynmag/wp-content/uploads/sites/3/2015/07/comercio_electronico.jpg
  108. 108. marcello.thiry@gmail.com Definido por uma necessidade de mercado, disponível comercialmente e cuja adequação para uso foi demonstrada por um largo espectro de usuários Software de prateleira. COTS (commercial off-the-shelf) (ISO/IEC 25030, 2007)
  109. 109. marcello.thiry@gmail.com Um produto de software pode ser: De prateleira – COTS Sob encomenda - FD http://www.spd-haimhausen.de/wp-content/uploads/2010/02/bausteine.jpg
  110. 110. marcello.thiry@gmail.com Desenvolvido para uma aplicação específica a partir de uma especificação de requisitos do software (ISO/IEC 25030, 2007) Software sob encomenda. FD (fully developed) or custom software development
  111. 111. marcello.thiry@gmail.com Um produto de software pode ser: De prateleira – COTS Sob encomenda – FD De prateleira modificável – MOTS http://www.sundlep.com/wp-content/uploads/2015/02/web12.jpg
  112. 112. marcello.thiry@gmail.com Similar ao COTS, mas permite algum grau de adaptação (modificação de suas funcionalidades) a partir de necessidades específicas dos usuários Software de prateleira modificável. MOTS (modified off-the-shelf)
  113. 113. marcello.thiry@gmail.com Pressman considera 7 categorias gerais Desafios! Pressman, 2015
  114. 114. marcello.thiry@gmail.com  Software básico  Software aplicativo  Sw para engenharia e aplicações científicas  Software embarcado  Linhas de produto de software  Aplicações web e móveis  Inteligência Artificial
  115. 115. marcello.thiry@gmail.com E mais... http://betanews.com/wp-content/uploads/2014/09/Internet-of-things.jpg http://1.bp.blogspot.com/-7WLjdMquht4/VAANOVyBZSI/AAAAAAAAEZ8/JDIrrYWeJyc/s1600/Cloud-computing-concept_nobg.png
  116. 116. marcello.thiry@gmail.com E qual é o seu papel nisso tudo?
  117. 117. marcello.thiry@gmail.com http://mrbakersgrade6.weebly.com/uploads/ 2/4/7/6/24767728/6979844.jpg?339
  118. 118. References.  (Brooks, 1986). No Silver Bullet: Essence and Accident in Software Engineering. Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.  (Brooks, 1995). The Mythical Man-Month. Anniversary Edition. Addison Wesley.  (IEEE Std 610.12.1990). IEEE Standard Glossary of Software Engineering Terminology.  (ISO 9000, 2015). Quality management systems — Fundamentals and vocabulary.  (ISO/IEC 25000, 2014). Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE.  (ISO/IEC 25030, 2007). Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements.  (PMBOK, 2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 5th ed. Project Management Institute (PMI).  (Pressman, 2015). Software Engineering: A Practitioner's Approach. 8th ed. McGraw-Hill Education.  (SWEBOK, 2014). SWEBOK - Guide to the Software Engineering Body of Knowledge. Version 3.0. IEEE.

×