Introducao

1.015 visualizações

Publicada em

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Introducao

  1. 1. Copyright © 2011 Fábio Nogueira de Lucena [email_address] Construir Software Idéias Análise Projeto Código
  2. 2. Conteúdo <ul><li>Quem cuida da criação de software
  3. 3. Engenharia de software (perspectivas)
  4. 4. Existem problemas no mundo
  5. 5. Elementos de uma solução computacional
  6. 6. Atividades e dependências entre elas para uma solução
  7. 7. Problema, solução e código
  8. 8. Por que análise, projeto e codificação?
  9. 9. Linguagens empregadas
  10. 10. Problemas de desenvolvimento e “regras de ouro”
  11. 11. Estímulo econômico para construir software
  12. 12. Revisão </li></ul>
  13. 13. Quem cuida da criação de software “ Esplanada dos Ministérios” Qual o percurso para software? Engenharia Civil Engenharia de Software Próxima da idéia (1957) Resultado (2000)
  14. 14. Engenharia de software (perspectivas) <ul><li>Algumas perspectivas </li><ul><li>Atividades
  15. 15. Artefatos
  16. 16. Pessoas
  17. 17. Processo
  18. 18. Métodos
  19. 19. Projeto
  20. 20. Qualidade </li></ul></ul>Ênfase em desenvolvimento <ul><ul><li>Alguns artefatos
  21. 21. Algumas atividades </li></ul></ul><ul><li>Não aborda processo
  22. 22. Não aborda gerência de projeto </li></ul>Esta apresentação:
  23. 23. Reconheça a existência de problemas <ul><li>Guerras
  24. 24. Baixa qualidade de serviços prestados
  25. 25. Custos elevados de produção
  26. 26. Cura de muitas enfermidades
  27. 27. ... </li></ul>Alguns podem ser “resolvidos” por computador Alvo da computação Problemas existentes
  28. 28. Computação pode resolver problemas Mas não todos os problemas
  29. 29. Elementos de solução computacional Software não é só código! DADOS CÓDIGO DOCUMENTOS
  30. 30. Atividades necessárias... <ul><li>Analisando... Problema é definido
  31. 31. Projetando... Modelo de solução que emprega computador
  32. 32. Implementando... Código obtido a partir do projeto </li></ul>... de toda solução computacional Solução computacional Implementação Projeto Análise
  33. 33. Dependência entre atividades <ul><li>Primeiro caracterize o problema Sem problema não há o que fazer
  34. 34. Depois crie o projeto (a solução computacional) Etapa laboriosa, extensa. Deve-se adquirir habilidades para tal.
  35. 35. Converta o projeto em código Sem projeto não há o que codificar. Considere a máquina conforme a liberdade possível. </li></ul>Problema  Solução  Código Análise Projeto Implementação
  36. 36. Problema <ul><li>O que é preciso? </li><ul><li>Compreendê-lo </li></ul><li>Como se faz? </li><ul><li>Analisando-o </li></ul><li>Como saber se foi compreendido? </li><ul><li>Validando com os usuários (clientes) </li></ul></ul>Antes da análise Após a análise “idealmente” Análise Atividade “mais difícil”
  37. 37. Projeto <ul><li>O que é preciso? </li><ul><li>Criá-lo (exige registro) </li></ul><li>Como se faz? </li><ul><li>Princípios de projeto
  38. 38. Exercitando o raciocínio lógico </li></ul><li>Como saber se está correto? </li><ul><li>Verificando a solução </li></ul></ul>
  39. 39. Algoritmo (parte de projeto detalhado) <ul><li>Abstração de um programa
  40. 40. Seqüência de passos de execução finita
  41. 41. Produz um resultado esperado </li></ul>Algoritmo = modelo de solução computacional Qualquer seqüência de passos cuja execução dá origem a um resultado desejado em tempo finito ... é exemplo de algoritmo!
  42. 42. Projeto não é só algoritmo <ul><li>Definição de partes da solução
  43. 43. Mecanismo de interação entre as partes
  44. 44. Influencia várias qualidades ... </li><ul><li>Facilidade de manutenção
  45. 45. Desempenho e outras ... </li></ul></ul>Projetista de software Criação de algoritmos Atividades de projeto de software Sem o projeto, não há o que codificar!
  46. 46. Código Está para Energia Gasolina Lâmpada Carro Assim como ... Programa Está para Computador
  47. 47. Programa <ul><li>O que é preciso? </li><ul><li>Linguagem de programação
  48. 48. Compreender algoritmo
  49. 49. Conhecer o computador </li></ul><li>Como se faz? </li><ul><li>Reescreva o projeto na linguagem de programação </li></ul><li>Como saber se está correto? </li><ul><li>Verificando e Validando (V&V) </li></ul></ul>Não é razoável escrever programa sem a existência de uma solução correspondente.
  50. 50. Algoritmo e programa correspondente Algoritmo Permutacao(p,S) Se S possui um caractere então Imprima p seguido de S Senão para i  0 até (n-1) faça S’  S – c i p’  p + c i Permutacao(p’,S’) fim para fim se #include <stdio.h> void Permutacao(char* p, char* S) { char Slinha[10], pLinha[10]; int c; if (strlen(S) == 1) printf(&quot;n%s%s&quot;,p,S); else for (c = 0; c < strlen(S); c++) { memset(Slinha,0,10); memset(pLinha,0,10); strncpy(Slinha,S,c); strcat(Slinha,S+c+1); strcat(pLinha,p); strncat(pLinha,S+c,1); Permutacao(pLinha,Slinha); } } Algoritmo (projeto) Programa em C Acrescenta detalhes da linguagem, computador ...
  51. 51. Por que análise, projeto e codificação? Problema Projeto Software Como poderia ser diferente? Análise Codificação Entender o problema Definir uma solução Escrever o software conforme a solução
  52. 52. SWEBOK® <ul><li>Requisitos
  53. 53. Projeto
  54. 54. Construção
  55. 55. Testes
  56. 56. Manutenção
  57. 57. Gerência de Configuração </li></ul><ul><li>Gerência de Projeto
  58. 58. Processos
  59. 59. Qualidade
  60. 60. Métodos e Ferramentas </li></ul>
  61. 61. Uma visão “bem” geral <ul><li>Requisitos (o que fazer?)
  62. 62. Projeto (como fazer?)
  63. 63. Construção (contruir)
  64. 64. Testes (localizar problemas)
  65. 65. Manutenção (evoluir)
  66. 66. Gerência de Configuração (gerir artefatos)
  67. 67. Gerência de Projeto (coordenar ações)
  68. 68. Processos (passos e produtos)
  69. 69. Qualidade (atender necessidades)
  70. 70. Métodos e Ferramentas (instrumentos) </li></ul>
  71. 71. Ordem <ul><li>Requisitos antes de Projeto
  72. 72. Projeto antes de Construção
  73. 73. Construção antes de Testes (exceto TDD)
  74. 74. Manutenção após Construção
  75. 75. Qualidade por todo o projeto
  76. 76. Gerência de Projeto por todo o projeto
  77. 77. Gerência de configuração por todo o projeto
  78. 78. Processo por todo o projeto
  79. 79. Métodos e ferramentas por todo o projeto </li></ul>
  80. 80. Algumas estão “sempre” em execução <ul><li>Processo
  81. 81. Gerência de Configuração
  82. 82. Métodos e Ferramentas
  83. 83. Gerência de Projeto
  84. 84. Qualidade </li></ul>
  85. 85. Requisitos <ul><li>Não é tópico realizado apenas no início de um projeto (ou seja, exige gerência)
  86. 86. Requisitos podem ser funcionais </li><ul><li>Calcular a nota final como média das notas </li></ul><li>Requisitos podem ser não funcionais </li><ul><li>Calcular pelo menos 1000 notas finais em 5s </li></ul></ul>
  87. 87. Projeto <ul><li>Compreende: </li><ul><li>Arquitetura
  88. 88. Projeto detalhado </li></ul><li>Arquitetura </li><ul><li>Principais componentes
  89. 89. Partes da solução e como interagem </li></ul><li>Projeto detalhado </li><ul><li>Detalhar o suficiente para permitir a construção </li></ul></ul>
  90. 90. Construção <ul><li>Criação do código
  91. 91. Testes de unidade
  92. 92. Testes de integração
  93. 93. Depuração </li></ul>
  94. 94. Testes <ul><li>Sempre implica na execução de programa
  95. 95. Ou seja, análise estática de código não é teste
  96. 96. São finitos
  97. 97. Deve ser possível definir resultados aceitáveis para uma dada entrada </li></ul>
  98. 98. Manutenção <ul><li>Software deve evoluir </li><ul><li>Atender novos requisitos
  99. 99. Corrigir erros </li></ul><li>Segundo o padrão IEEE Standard for Software Maintenance, IEEE 1219 </li><ul><li>“ modificação de um software, após entrega, para corrigir falhas, melhorar desempenho ou outros atributos, ou para se adaptar a um ambiente modificado”. </li></ul></ul>
  100. 100. Gerência de Configuração <ul><li>O desenvolvimento de software gera vários artefatos
  101. 101. Artefatos evoluem ao longo do tempo
  102. 102. Gerência de Configuração </li><ul><li>Identifica artefatos (itens de configuração)
  103. 103. Controla mudanças nos artefatos </li></ul><li>Baseline </li><ul><li>Conjunto de itens de configuração “aprovado”
  104. 104. Serve para referência posterior </li></ul></ul>
  105. 105. Ger ência de Projeto <ul><li>O desenvolvimento de um software pode envolver um ou mais projetos
  106. 106. Manutenção pode envolver um ou mais projetos
  107. 107. Gerência visa: planejar, dirigir, acompanhar e fechar um projeto </li><ul><li>Estimar esforço, alocar recursos, gerenciar riscos, contratar profissionais, ... </li></ul></ul>
  108. 108. Processos de software <ul><li>“Atividades realizadas por uma organização para produzir ou manter software”
  109. 109. A norma 12207 apresenta vários processos
  110. 110. MPS.BR visa a “melhoria de processo do software brasileiro” </li></ul>
  111. 111. Métodos e ferramentas <ul><li>Ambientes integradas de desenvolvimento, compiladores, ferramentas para builds, …
  112. 112. Métodos orientados a objetos, métodos formais, ... </li></ul>
  113. 113. Qualidade <ul><li>Satisfazer o uso pretendido do produto
  114. 114. Requisitos de software definem as características desejadas de qualidade
  115. 115. Ou seja, pode ser interpretada como conformidade aos requisitos </li></ul>
  116. 116. Empregadas no desenvolvimento de software Linguagens
  117. 117. Linguagens naturais <ul><li>Português
  118. 118. Inglês
  119. 119. Espanhol
  120. 120. Japonês, ... </li></ul>
  121. 121. Linguagens para computadores <ul><li>Padrões de bits 01110101000110110111...
  122. 122. Assembly Linguagem de montagem
  123. 123. Linguagens de “alto nível” Delphi, VB, C++, Java
  124. 124. ?? </li></ul>Mais abstração = maior produtividade Abstração crescente
  125. 125. Linguagens ao longo do tempo Linguagens naturais Linguagem de máquina Mais abstração Menos abstração Linguagem algorítmica Linguagem de programação Cérebro Cérebro Compilador UML “ Fronteira” homem-máquina
  126. 126. Outras questões relevantes do desenvolvimento de programas Processo de desenvolvimento
  127. 127. Problemas de desenvolvimento Pressa em codificar Falta de planejamento Conhecimento ingênuo
  128. 128. Suposição bem-aceita Processo bom, resultado bom! Processo ruim, resultado ruim! Desenvolver programas exige trabalho em equipe
  129. 129. Ausência de disciplina Ausência de disciplina = usuário insatisfeito Não confundir com ausência de formalidade. Formigas são “informais” e “disciplinadas”.
  130. 130. Ferramentas “boas” são suficientes? Bons instrumentos fazem boa música? Bom prato é obtido com um bom fogão? Emprego da Última tecnologia Não necessariamente
  131. 131. Estímulo ... <ul><li>Microsoft </li><ul><li>Empresa de maior valor de mercado do mundo
  132. 132. 50000 funcionários </li></ul><li>Wall-Mart </li><ul><li>Quinta maior
  133. 133. Quase 1,5 milhão de funcionários </li></ul><li>Comparação: </li><ul><li>Coca-cola está em 16o. </li></ul></ul>Software “bom” = Dinheiro Dados obtidos em www. forbes .com para 2003
  134. 134. Você acredita nisso? Não existe solução mágica! Lâmpada mágica para construção de software. COMPRE AGORA! Pague só em 60 dias!
  135. 135. Considerações finais <ul><li>Software “bom” é “difícil” de ser construído
  136. 136. Desenvolver programas exige raciocínio
  137. 137. Envolve atividades e artefatos
  138. 138. Envolve várias linguagens
  139. 139. Envolve análise, projeto
  140. 140. Envolve implementação </li></ul>Desenvolver software “bom” = muito esforço ?

×