Cs 1

1,115 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,115
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cs 1

  1. 1. Construção de Software Curso Engenharia de Software http://engenhariadesoftware.inf.br Fábio Nogueira de Lucena
  2. 2. Referência • Code Complete: A Practical Handbook of Software Construction, Steve McConnell 2nd edition, Microsoft Press, 2004 • HOME PAGE (apoio ao livro) http://www.cc2e.com/ • IMPORTANTE: o conteúdo destes slides foi obtido, em sua maior parte, do livro supracitado. Nossos agradecimentos e a devida citação.
  3. 3. Construção de Software? • ISO/IEC 12207:2008 identifica 43 processos (aquisição, fornecimento, desenvolvimento, operação, manutenção e retirada de operação de produtos de software). • Um deles: software construction process • Objetivo: produzir unidades de software executáveis que adequadamente refletem o projeto de software (software design).
  4. 4. Quais as atividades? • Codificação (programação) • Depuração (debugging) • Projeto detalhado (low-level design) • Testes unitários (unit tests) • Testes de integração • Integração
  5. 5. “Sinônimos” • Codificação (muitas vezes entendida como a mera transcrição de projeto existente para uma linguagem de programação e, construção, envolve criatividade e critérios) • Programação (mais adequado)
  6. 6. Alguns detalhes • Verificar se pré-requisitos estão prontos • Determinar como o código será testado • Projetar e escrever classes e rotinas • Selecionar estruturas de controle • Realizar testes de unidade • Reorganizar o código, formatá-lo, incluir comentários, ...
  7. 7. O que não é? • Gerência do projeto • Desenvolvimento dos requisitos • Arquitetura de software • Projeto da interface com o usuário • Testes de sistema • Manutenção
  8. 8. É importante? • Extensa (30% a 80% do tempo total) • Atividade central (após requisitos e arquitetura, antes dos testes de sistema) • Foco na construção pode aumentar produtividade individual (variação de um fator de 10 a 20) • Em alguns casos, o software é tudo • Será executada garantidamente
  9. 9. Produtos da CS • ISO/IEC 12207:2008 • Critérios de verificação são definidos para todas as unidades de software com base nos requisitos • Unidades de software definidas pelo projeto são produzidas • Consistência e rastreabilidade são estabelecidas entre unidades de software, requisitos e projeto • Verificação das unidades de software conforme os requisitos e o projeto é realizada
  10. 10. Metáforas Compreendendo o Desenvolvimento de Software
  11. 11. Metáfora (Aurélio) • “transferência de uma palavra para um âmbito semântico que não é o do objeto que ela designa” • Por exemplo, usar “raposa” para designar uma pessoa “astuta”.
  12. 12. Metáforas • David Gries: “escrever software é uma ciência” • Donald Knuth: “é uma arte” • Watts Humphrey: “é um processo” • Plauger e Kent Beck: “é como dirigir um carro” • Alistair Cockburn: “é um jogo”, ...
  13. 13. Outras • Escrever código (como uma carta?) (ignora planejamento e projeto) • Cultivar uma planta (ignora que você não o clima tem controle) • Cultura de ostras (incremento) • Construção de software (edificação) (uma pipa é diferente de 1000 pipas)
  14. 14. Por fim,... • Metáforas apenas facilitam a compreensão do processo de desenvolvimento de software relacionando-o com atividades conhecidas. • Tratar CS como construção civil, ilustra a diferença entre grandes e pequenos projetos. • Não são mutuamente exclusivas, combine- as.
  15. 15. Pré-requisitos Meça duas vezes, corte uma
  16. 16. Preparação • Deve ser adequada para as necessidades do projeto e ocorrer antes do início da construção • Diálogo absurdo: “Quero uma casa aqui, diz o cliente. O mestre de obras diz: claro, quando terminar eu aviso e inicia a construção.”
  17. 17. Qualidade • Qualidade no fim: Vamos testar • Qualidade no meio: Vamos construir com cuidado • Qualidade no início (preparação): Pleneja e projeta um produto de qualidade
  18. 18. Por que preparar? • Reduzir riscos
  19. 19. Apelo aos dados
  20. 20. Custo de correção • Quanto mais tarde a detecção de defeito, mais cara é a correção
  21. 21. Preparação depende do projeto • Diferentes projetos, diferentes preparações • Projeto simples, menos preparação (planejamento iterativo) • Projeto de software crítico (vidas em jogo), preparação extensiva (planejamento extensivo)
  22. 22. Quais os pré-requisitos? • Definição do problema • Requisitos • Arquitetura de Software
  23. 23. Definição do problema • Problema: Coordenadores de curso têm dificuldades para alterar o horário de disciplinas • É comum: Acrescentar tela similar ao Google Calendar (parece solução e não um problema)
  24. 24. Requisitos • Descrevem em detalhes o que um software deve fazer • Nomes associados: • Análise de Requisitos • Desenvolvimento de requisitos • Definição de requisitos • Especificação funcional, ...
  25. 25. Importância • Custos (para corrigir defeitos na especificação) • Segundo Steve McConnell: “Especificar requisitos corretamente é o segredo para o sucesso de um projeto, talvez ainda mais importante do que as técnicas de construção eficientes”.
  26. 26. Requisitos são estáveis? • Mesmo após a assinatura do cliente em uma especificação de requisitos, eles irão mudar • Quanto de mudança é normal? Estudos da IBM indicam 25% de mudanças nos requisitos, responsáveis por 70 a 85% das alterações em um projeto típico
  27. 27. Requisitos durante a CS • Avalie a qualidade dos requisitos (lista de verificação) • Certifique-se de que os custos das alterações nos requisitos são conhecidos • Estabeleça um procedimento para controle de alteração • Use estratégia compatível com alterações • Cancele o projeto • Considere o efeito comercial do projeto
  28. 28. Tarefa • Ambiente-se com a Lista de Verificação de Requisitos (Requirements Checklist) no portal de apoio ao livro Code Complete • Portal http://www.cc2e.com
  29. 29. Arquitetura • Etapa de alto nível de projeto de software (software design) • É a estrutura que irá acomodar as partes mais detalhadas do projeto de software (software design) • Outros termos: arquitetura de sistema e high-level design
  30. 30. Por que arquitetura? • Fornece orientação para programadores • Desmembra o trabalho (várias equipes trabalharem independentemente) • Arquitetura ruim torna a construção inviável • Custo (para correção)
  31. 31. Arquitetura inclui: • Visão geral do sistema • Interoperabilidade (grandes blocos) • Internacionalização/ • Classes principais localização • Projeto dos dados • Entrada/saída • Regras de negócio • Processamento de • Projeto de interface erros com o usuário • Tolerância a falhas • Gerenciamento de • Praticabilidade recursos • Robustez • Segurança • Comprar/construir • Desempenho • Reutilização • Extensibilidade • Estratégia de alteração
  32. 32. Tarefa • Ambiente-se com a Lista de Verificação de Arquitetura (Architecture) no portal de apoio ao livro Code Complete • Portal http://www.cc2e.com
  33. 33. Quanto de pré-requisitos? • Depende do projeto (acostume-se a considerar o contexto) • Em geral, 10 a 20% do esforço e 20 a 30% do tempo dedicado ao planejamento prévio, requisitos e arquitetura (não inclui projeto detalhado, parte de CS)
  34. 34. Não esqueça • Alguns projetos são mais sequenciais, outros mais iterativos • Uma definição inadequada do problema pode levar à solução do problema errado durante a construção • Não inicie a construção sem que os requisitos estejam corretos (custo de correção) • Se a arquitetura estiver errada, você estará resolvendo o problema certo, mas de maneira errada
  35. 35. Principais decisões de Construção de Software
  36. 36. Principais decisões • Linguagem de Programação • Convenções de programação • Onda tecnológica
  37. 37. Linguagem de programação TIOBE index
  38. 38. Um tratamento + formal • Lutz Prechelt, "An Empirical Comparison of Seven Programming Languages," Computer, vol. 33, no. 10, pp. 23-29, Oct. 2000, doi: 10.1109/2.876288
  39. 39. Algumas... • Assembly. Linguagem de baixo nível, formada por mnemônicos para linguagens de máquina. • Fortran. Primeira linguagem de alto nível e ainda “imbatível” em cálculos • SQL. Linguagem padrão de fato para consultas e atualizações em bancos de dados (linguagem declarativa)
  40. 40. Linguagem é religião? • Não. • Pode ser que exista opção de escolha. • Em geral, o projeto dita o uso de linguagens mais apropriadas
  41. 41. Convenções de Programação • Code Conventions for the Java Programming Language http://java.sun.com/docs/codeconv/
  42. 42. Onda tecnológica • Programas baseados em caracteres, depois interfaces gráficas, depois web, ... • Ferramentas para o desenvolvimento destes programas • (Sugestão) David Gries distingue programação em e para uma linguagem. Quem programa em limita-se às construções da linguagem. Quem programa para cria ideias e depois as converte para a linguagem alvo.
  43. 43. Considerações finais • Toda linguagem possui vantagens e desvantagens • Estabeleça convenções de programação
  44. 44. Tarefa • Ambiente-se com a Lista de Verificação de Decisões de Construção (Construction Decisions) no portal de apoio ao livro Code Complete • Portal http://www.cc2e.com

×