Cs 1
2 gostaram499 visualizações
O documento discute os principais pré-requisitos e decisões iniciais para a construção de software, incluindo a definição correta do problema, especificação de requisitos, projeto de arquitetura e escolha da linguagem de programação e convenções a serem utilizadas.
Cs 1
- 1. Construção de Software Curso Engenharia de Software http://engenhariadesoftware.inf.br Fábio Nogueira de Lucena
- 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. 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. 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. “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. 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. 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. É 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. 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. Metáforas Compreendendo o Desenvolvimento de Software
- 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. 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. 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. 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. Pré-requisitos Meça duas vezes, corte uma
- 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. 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. Por que preparar? • Reduzir riscos
- 19. Apelo aos dados
- 20. Custo de correção • Quanto mais tarde a detecção de defeito, mais cara é a correção
- 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. Quais os pré-requisitos? • Definição do problema • Requisitos • Arquitetura de Software
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Principais decisões de Construção de Software
- 36. Principais decisões • Linguagem de Programação • Convenções de programação • Onda tecnológica
- 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. 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. 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. Convenções de Programação • Code Conventions for the Java Programming Language http://java.sun.com/docs/codeconv/
- 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. Considerações finais • Toda linguagem possui vantagens e desvantagens • Estabeleça convenções de programação
- 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