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

37. Linguagem de programação
TIOBE
index

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