O documento discute os fundamentos e considerações práticas da construção de software. Aborda tópicos como minimizar a complexidade, antecipar mudanças, construir para verificação, normas de construção, design de construção, linguagens de construção, codificação, testes, modelagem em V, reutilização, qualidade, integração e gestão da construção.

1. CONSTRUÇÃO
Alunos: Davi Saraiva, Alysson Victor, Renatto Alves Correa, Carlos
Eduardo Mota e Pedro Eduardo Peixoto
Professora: Adriana Souza
Engenharia de Software

2. 01
Introdução

3. Introdução
Construção de Software o termo Construção de software refere-se a criação
de um trabalho detalhado e significativo de um software por meio de testes unitários,
verificações e combinações de códigos. a área de construção de software possui
conexões com outras áreas de conhecimento, mais firmemente as áreas de Design de
Software e Testes de Software.
Isso por que o processo de construção de software implica
significativamente nessas outras áreas. Os limites entre o design, a construção e os
testes irão depender do ciclo de vida utilizado no projeto. embora alguns detalhes de
design possam ser realizados anteriores a construção, muito desse trabalho é realizado
na atividade de construção em si, assim como os testes de unidade e de integração.

4. Introdução
A construção de software tipicamente produz um grande volume de
itens de configuração (que necessitam do Gerenciamento de Projeto de
Software, sendo assim, também está ligada a configuração do software.)
A Construção de Software é semelhante a ciência da computação no
uso do seu conhecimento de algoritmos e o detalhamento de práticas de
codificação. (também se relaciona com a gerência de projetos, já que a
construção apresenta desafios consideráveis em sua própria gerência.)

5. 02
Fundamentos

6. Fundamentos
Minimizar complexidade:
A complexidade é um desafio no desenvolvimento de
software, pois as capacidades humanas de compreensão são
limitadas. Minimizar a complexidade é essencial para facilitar a
compreensão e manutenção do código. Isso pode ser alcançado
através da criação de código simples, legível e engenhoso,
usando padrões de projeto e técnicas específicas de codificação.

7. Programa simples que armazena a idade de 4 pessoas

8. Fundamentos
Antecipação de mudança:
O software está sujeito a mudanças ao longo do tempo,
seja devido a requisitos em evolução, ambientes externos ou
outras circunstâncias. Antecipar essas mudanças é fundamental
na construção de software, garantindo que o código seja flexível
e adaptável. Existem técnicas específicas para lidar com a
antecipação de mudanças durante a codificação.

9. Fundamentos
Construção para verificação:
Construir software de forma que as falhas possam ser
prontamente identificadas é um aspecto importante. Isso inclui
a aplicação de normas de codificação, revisão de código, teste
de unidades, automação de testes e uso de linguagens e
estruturas compreensíveis. A verificação da construção permite
a detecção precoce de erros e falhas no software.

10. Fundamentos
Normas de construção:
Existem normas que afetam diretamente a construção de
software, como métodos de comunicação, linguagem de
programação, plataforma e ferramentas utilizadas. Normas
externas, provenientes de organizações e especificações
reconhecidas, fornecem diretrizes para a construção. Além disso,
as organizações podem criar suas próprias normas internas para
promover a coordenação, minimizar a complexidade e garantir a
conformidade com padrões de qualidade.

11. 03
Considerações
Práticas

12. Design de Construção
No contexto do design de construção na engenharia de
software, durante o processo de desenvolvimento, certos
detalhes do design são abordados no nível de construção. Esses
detalhes são influenciados pelas restrições de projeto impostas
pelo mundo real e pelos problemas específicos que o software
deve solucionar. Os construtores de software são responsáveis
por realizar modificações, em diferentes escalas, a fim de
enriquecer os detalhes do design de software durante a etapa de
construção.

13. A capacidade de adaptar o design durante a construção é
fundamental para garantir a qualidade, a eficiência e a
adequação do software às necessidades do projeto. Ao considerar
as restrições de projeto e as questões práticas que surgem, os
construtores de software têm a oportunidade de enriquecer o
design, otimizando-o para atender aos requisitos específicos e
alcançar melhores resultados finais. Nesse sentido, os
construtores de software devem estar preparados para ajustar e
refinar o design conforme necessário

15. Linguagem de Construção
Linguagens de construção incluem todas as formas de comunicação
em que um homem pode especificar uma solução de um problema
executável para o computador.
O tipo mais simples de linguagem de construção é uma linguagem de
configuração, na qual engenheiros de software escolhem um conjunto
limitado de opções predefinidas para definir software que serão utilizados
para construção, criar instalações de software novas ou personalizadas.

16. Kit de ferramentas de linguagem são usadas para criar aplicativos em kits
(conjuntos integrados de partes reutilizáveis específicas do aplicativo) e são
linguagens de configuração mais complexas. Elas também contêm o mínimo de
informações sobre áreas de aplicação específicas e processos de desenvolvimento e
assim o exigem mais formação e habilidade para utilizá-las de forma eficaz.
Existem três tipos gerais de notação usada para linguagens de programação, que
são:
• Linguística
• Formal
• Visual

17. As notações linguísticas se diferenciam, principalmente, pelo uso de palavras-
chave para representar construções de software complexas. Essas palavras-chave
são combinadas em padrões que seguem uma estrutura de frase semelhante.
Notações formais contam com menos significados intuitivos, palavras comuns
e cadeias de texto, e, mais em definições de suporte preciso, sem ambiguidades e
definições formais (ou matemática).
Notações Visual baseiam-se muito menos sobre as notações de palavras
chaves da construção linguística e formal e em vez disso dependem a interpretação
visual direta e o posicionamento das entidades visual que representam o software
subjacente. Construção Visual tende a ser um pouco limitado pela dificuldade de
fazer. No entanto, também pode ser uma ferramenta poderosa nos casos em que a
tarefa de programação principal é simplesmente construir e “ajustar "uma
interface visual a um programa.

19. Codificando
As considerações seguintes se aplicam à codificação na atividade de construção software:
• Técnicas para criar código fonte compreensível, incluindo a nomeação e layout de código de origem.
• Utilização de classes, tipos enumerados, variáveis, constantes nomeados e outras entidades similares.
• Manutenção das condições de erro — tanto planejadas erros e excepções (entrada de dados incorreto, por
exemplo).
• Prevenção das violações de segurança de nível de código.
• Uso de recursos através da utilização de mecanismos de exclusão e disciplina no acessar série de recursos
reutilizáveis (incluindo threads ou bloqueios de banco de dados).
• Organização de código de origem (em declarações, rotinas, classes, pacotes ou outras estruturas).
• Documentação de código.
• Ajuste de código

20. Testando a Construção
Construção envolve duas formas de testes, que frequentemente são executadas pelo engenheiro
de software que escreveu o código:
• Testes unitários
• Testes de integração.
O objetivo dos testes de construção visa reduzir a lacuna entre o tempo em que os defeitos são
inseridos no código e o tempo que os mesmos são detectados. Em alguns casos, testes de
construção são executados depois de código foi escrito. Em outros casos, os testes podem ser
criados antes que código seja escrito.
Testes de construção envolvem tipicamente um subconjunto de tipos de testes, que são
descritos na área de conhecimento de teste de software. Por exemplo, testes de construção
normalmente não incluem testes de sistema, testes alfa, teste beta, stress testing, teste de
configuração, testes de usabilidade ou outros, mais tipos especializados dos testes.

21. Model V
Todo projeto de engenharia tem início com a definição dos requisitos. Esses requisitos estão
relacionados com os desejos e limitações dos clientes e stakeholders e vão definir as principais
características do produto final. Após essa definição, é possível de fato projetar, construir e
testar esse produto. O intuito do modelo V é ilustrar graficamente essas diferentes etapas.
Fluxo descendente na porção esquerda:
O projeto se inicia na parte superior esquerda (Fase 0), na qual são estudados os conceitos de
operações desejados para o produto e todas as limitações e restrições impostas por essas
operações.
Cada sistema definirá seus próprios requisitos técnicos, de acordo com os que já foram
definidos, e será responsável pela elaboração de um plano de projeto, contendo WBS,
cronogramas e orçamentos.

22. Sistemas muito complexos são divididos em subsistemas, que devem definir seus próprios
requisitos técnicos e planejamento de projeto, na Fase 2.(Nessa etapa, serão feitas definições
sobre as arquiteturas utilizadas em cada subsistema)
Após essas delimitações, os requisitos e restrições são estudados em níveis de diferentes
sistemas, na Fase 1.
A WBS é uma ferramenta utilizada para facilitar o gerenciamento de projetos por meio da
decomposição hierárquica do escopo do projeto em partes menores. Seu principal objetivo é
organizar as entregas do projeto.
Por fim, na fase 3, será feitas análises a nível de componentes. Quais as características
desejadas para os componentes? Quais componentes serão utilizados? Como será a integração
entre eles? Qual o custo do componente proposto?
Fluxo ao longo da porção horizontal:
A parte horizontal corresponde à Fase 4, na qual componentes são comprados ou fabricados e
softwares são criados. O projeto passa, de fato, a ter forma física e assim, pode ser testado.

23. Fluxo ascendente na porção direita:
Quando chegamos na parte direita do V, são iniciados os testes e validações. Essa porção do
diagrama permite verificar se os requisitos e definições feitos na parte esquerda do V foram de
fato atendidos nos diferentes níveis de projeto.Dessa forma, na medida que componentes,
subsistemas e sistemas são testados, verifica-se a coerência com o que foi definido da etapa de
design.
É valido ressaltar que o projeto não pode avançar para a fase de verificação de subsistemas de
a validação do componente não for adequada. Da mesma forma, não se pode avançar para a
validação do sistema, se o subsistema não estiver de acordo com o que foi projetado. Assim, as
Fases 3, 2, 1 e 0 devem ser retomadas em sequência. Na Fase 0, deve ser verificado se o
produto final atendeu aos desejos dos clientes e stakeholders.

26. Reutilização
Tal como consta a introdução de (IEEE1517-99): “Executando reutilização de software
implica mais do que criar e usar bibliotecas de recursos. É necessário formalizar a prática de
reutilização, integrando os processos de reutilização e atividades no ciclo de vida do software.“ No
entanto, a reutilização é suficientemente importante na construção de software, e que é incluída
aqui como um tópico.
As tarefas relacionadas com a reutilização na construção de software durante a
codificação e testes são:
• A seleção das unidades reutilizáveis, bancos de dados, procedimentos de ensaio ou testar dados.
• A avaliação da reutilização de código ou de teste
• A comunicação de informações de reutilização sobre o novo código, testar procedimentos ou
testar dados.

27. Qualidade da Construção
Numerosas técnicas existem para garantir a qualidade de como o código é
construído. As principais técnicas utilizadas para construção incluem:
• Testes de unidade e testes de integração
• Desenvolvimento orientado a teste
• Utilização de afirmações
• Depuração
• Revisões técnicas
• Análise estática
A técnica específica ou técnicas selecionadas dependem da natureza do software a ser
construído, bem como dos engenheiros de software no conjunto habilidades executando a construção.
Atividades de qualidade de construção são diferenciadas das outras atividades de qualidade pelo seu
foco. Atividades de qualidade de construção concentram-se no código e não nos artefatos que estão
intimamente relacionados ao código: desenhos pequenos — em vez de outros artefatos que estão
menos diretamente conectados com o código, como requisitos, design de alto nível e planos.

29. Integração
Uma atividade fundamental durante a construção é a integração das rotinas
construídas separadamente, classes, componentes e subsistemas. Além disso, um sistema
de software específico talvez precise ser integrado com outros sistemas de software ou
hardware.
Preocupações relacionadas com a integração da construção incluem
planejamento a sequência em que os componentes serão integrados, criando suporte para
apoiar a versões provisórias do software, determinar o grau de testes e trabalho de
qualidade realizado nos componentes antes de serem integrados e em que determinantes
pontos no projeto, versões provisórias do software são testadas.

33. 04
Gestão

34. Gestão de Construção
A Gestão de Construção é de suma importância para garantir um bom
andamento do processo construtivo do software, podemos dividi-la em três partes,
sendo elas:
• Modelos de Construção
• Planejamento de Construção
• Medição de Construção.

35. Modelos de Construção
Vários modelos podem ser utilizados no processo de construção de software,
onde o desenvolvimento só acontece após a definição detalhada dos requisitos do
sistema, design e planejamento do projeto como um todo. Diante disso, temos como
exemplo a escolha do ciclo de vida cascata que acarreta em um andamento linear
do projeto, fazendo uma separação explicita entre os processos que devem ser
feitos e dando ênfase na programação do sistema.
Também temos modelos iterativos, como a prototipagem evolutiva, Extreme
Programming (XP) e Scrum. Nestes dois modelos a programação do sistema tende a
ocorrer em paralelo com outras atividades, este fator os distingue completamente
do ciclo de vida cascata.

36. Planejamento de Construção
O planejamento da construção do software se inicia com a escolha do método
que será utilizado. Dependendo de qual for escolhido, a construção do software em
si pode começar mais cedo ou mais tarde.
Um bom planejamento da construção do projeto pode tornar todo o processo
construtivo mais simples, antecipando mudanças e poupando retrabalho. O
planejamento também é de suma importância para determinar a ordem que será
seguida durante todas as etapas do ciclo de vida.

37. Medição de construção
A medição das atividades que serão feitas na construção do software
é essencial para garantir que os processos sejam realizados da forma
correta. Levando isso em consideração, várias atividades podem e devem
ser medidas, dentre elas: o desenvolvimento de código, modificação de
código, reutilização de código, complexidade de código, possíveis falhas e
correção, esforço necessário para a conclusão do projeto, entre outros.

39. Referências:
SWEBOK – Software
Engineering Body Of
Knowledge