Construção de software - Software construction

Não deve ser confundido com desenvolvimento de software .
Desenvolvimento de software
Principais atividades
Paradigmas e modelos
Metodologias e frameworks
Disciplinas de apoio
Práticas
Ferramentas
Padrões e Corpos de Conhecimento
Glossários
Contornos

A construção de software é uma disciplina da engenharia de software . É a criação detalhada de software funcional significativo por meio de uma combinação de codificação , verificação , teste de unidade , teste de integração e depuração . Ele está vinculado a todas as outras disciplinas da engenharia de software , mais fortemente ao projeto e teste de software .

Fundamentos de construção de software

Minimizando a complexidade

A necessidade de reduzir a complexidade é impulsionada principalmente pela capacidade limitada da maioria das pessoas de manter estruturas e informações complexas em suas memórias de trabalho. A complexidade reduzida é alcançada enfatizando a criação de código que é simples e legível, em vez de inteligente. A minimização da complexidade é obtida por meio do uso de padrões e de várias técnicas específicas de codificação . Também é apoiado pelas técnicas de qualidade com foco na construção .

Antecipando mudança

Antecipar mudanças ajuda os engenheiros de software a construir software extensível, o que significa que eles podem aprimorar um produto de software sem interromper a estrutura subjacente. Pesquisas de mais de 25 anos mostraram que o custo do retrabalho pode ser 10 a 100 vezes (5 a 10 vezes para projetos menores) mais caro do que atender os requisitos da primeira vez. Dado que 25% dos requisitos mudam durante o desenvolvimento em média do projeto, a necessidade de reduzir o custo de retrabalho elucida a necessidade de antecipar a mudança.

Construindo para verificação

Construir para verificação significa construir software de forma que as falhas possam ser descobertas prontamente pelos engenheiros de software que escrevem o software , bem como durante testes independentes e atividades operacionais. Técnicas específicas que suportam a construção para verificação incluem seguir padrões de codificação para oferecer suporte a revisões de código , teste de unidade , código de organização para oferecer suporte a testes automatizados e uso restrito de estruturas de linguagem complexas ou difíceis de entender , entre outros.

Reuso

A reutilização sistemática pode permitir melhorias significativas na produtividade, qualidade e custo do software. Reutilizar tem duas facetas intimamente relacionadas:

  • Construção para reutilização: Crie ativos de software reutilizáveis.
  • Construção com reuso: Reutilizar ativos de software na construção de uma nova solução.

Padrões em construção

Os padrões, sejam externos (criados por organizações internacionais) ou internos (criados no nível corporativo), que afetam diretamente as questões de construção incluem:

Gerenciando construção

Modelo de construção

Vários modelos foram criados para desenvolver software , alguns dos quais enfatizam a construção mais do que outros. Alguns modelos são mais lineares do ponto de vista da construção, como os modelos em cascata e de ciclo de vida de entrega em etapas. Esses modelos tratam a construção como uma atividade que ocorre apenas após a conclusão de um trabalho de pré-requisito significativo - incluindo trabalho de requisitos detalhados , trabalho de design extensivo e planejamento detalhado . Outros modelos são mais iterativos , como prototipagem evolutiva , Extreme Programming e Scrum . Essas abordagens tendem a tratar a construção como uma atividade que ocorre simultaneamente com outras atividades de desenvolvimento de software , incluindo requisitos , design e planejamento , ou os sobrepõe.

Planejamento de construção

A escolha do método de construção é um aspecto fundamental da atividade de planejamento da construção. A escolha do método de construção afeta a extensão em que os pré-requisitos de construção (por exemplo , análise de requisitos , projeto de software , etc.) são realizados, a ordem em que são realizados e o grau em que se espera que sejam concluídos antes do trabalho de construção começa. O planejamento da construção também define a ordem em que os componentes são criados e integrados, os processos de gerenciamento da qualidade do software , a alocação de atribuições de tarefas a engenheiros de software específicos e as demais tarefas, de acordo com o método escolhido .

Medição de construção

Numerosas atividades de construção e artefatos podem ser medidos, incluindo código desenvolvido, código modificado, código reutilizado, código destruído, complexidade do código, estatísticas de inspeção de código, taxas de correção e localização de falhas, esforço e programação. Essas medições podem ser úteis para fins de gerenciamento de construção, garantindo a qualidade durante a construção, melhorando o processo de construção, entre outros motivos.

Considerações práticas

A construção de software é conduzida por muitas considerações práticas:

Projeto de construção

A fim de levar em conta as lacunas imprevistas no design do software , durante a construção do software, algumas modificações no design devem ser feitas em uma escala menor ou maior para dar corpo aos detalhes do design do software .

O baixo fan-out é uma das características de design consideradas benéficas pelos pesquisadores. A ocultação de informações provou ser uma técnica de design útil em programas grandes que os tornou mais fáceis de modificar por um fator de 4.

Linguagens de construção

Linguagens de construção incluem todas as formas de comunicação pelas quais um ser humano pode especificar uma solução de problema executável para um computador. Eles incluem linguagens de configuração, linguagens de kit de ferramentas e linguagens de programação :

  • Os idiomas de configuração são idiomas nos quais os engenheiros de software escolhem a partir de um conjunto limitado de opções predefinidas para criar instalações de software novas ou personalizadas.
  • As linguagens do kit de ferramentas são usadas para construir aplicativos a partir dos kits de ferramentas e são mais complexas do que as linguagens de configuração.
  • Linguagens de script são tipos de linguagens de programação de aplicativo que oferecem suporte a scripts que geralmente são interpretados em vez de compilados.
  • Linguagens de programação são o tipo mais flexível de linguagens de construção que usam três tipos gerais de notação:
    • Notações linguísticas que são distinguidas em particular pelo uso de cadeias de texto semelhantes a palavras para representar construções de software complexas e a combinação de tais cadeias semelhantes a palavras em padrões que têm uma sintaxe semelhante a uma frase.
    • Notações formais que se baseiam menos em significados cotidianos intuitivos de palavras e cadeias de texto e mais em definições apoiadas por definições precisas, inequívocas e formais (ou matemáticas).
    • Notações visuais que dependem muito menos das notações orientadas ao texto de ambas as construções linguísticas e formais e, em vez disso, dependem da interpretação visual direta e da colocação de entidades visuais que representam o software subjacente.

Os programadores que trabalham em uma linguagem que usam há três anos ou mais são cerca de 30% mais produtivos do que os programadores com experiência equivalente que são novos em uma linguagem. Linguagens de alto nível, como C ++, Java, Smalltalk e Visual Basic geram produtividade, confiabilidade, simplicidade e compreensão 5 a 15 vezes melhor do que linguagens de baixo nível, como assembly e C. O código equivalente precisa de menos linhas para ser implementado em linguagens de alto nível do que em linguagens de baixo nível.

Codificação

Artigo principal: Programação de computador

As seguintes considerações se aplicam à atividade de codificação de construção de software:

  • Técnicas para criar código-fonte compreensível , incluindo nomenclatura e layout do código-fonte. Um estudo mostrou que o esforço necessário para depurar um programa é minimizado quando os nomes das variáveis ​​têm entre 10 e 16 caracteres.
  • Uso de classes , tipos enumerados , variáveis , constantes nomeadas e outras entidades semelhantes:
    • Um estudo feito pela NASA mostrou que colocar o código em classes bem fatoradas pode dobrar a capacidade de reutilização do código em comparação com o código desenvolvido usando design funcional.
    • Um experimento mostrou que projetos que acessam matrizes sequencialmente, em vez de aleatoriamente, resultam em menos variáveis ​​e menos referências de variáveis.
  • Uso de estruturas de controle:
    • Um experimento descobriu que os loops com saída são mais compreensíveis do que outros tipos de loops.
    • Com relação ao nível de aninhamento em loops e condicionais, estudos mostraram que os programadores têm dificuldade em compreender mais de três níveis de aninhamento.
    • Demonstrou-se que a complexidade do fluxo de controle se correlaciona com baixa confiabilidade e erros frequentes.
  • Tratamento de condições de erro - erros planejados e exceções (entrada de dados incorretos, por exemplo)
  • Prevenção de violações de segurança em nível de código ( estouro de buffer ou estouro de índice de array , por exemplo)
  • Uso de recursos por meio do uso de mecanismos de exclusão e disciplina no acesso a recursos reutilizáveis ​​em série (incluindo threads ou bloqueios de banco de dados )
  • Organização do código-fonte (em instruções e rotinas ):
    • Rotinas altamente coesas mostraram-se menos sujeitas a erros do que rotinas com menor coesão. Um estudo de 450 rotinas descobriu que 50 por cento das rotinas altamente coesas eram livres de falhas, em comparação com apenas 18 por cento das rotinas com baixa coesão. Outro estudo de 450 rotinas diferentes descobriu que as rotinas com as taxas de acoplamento -coesão mais altas tinham 7 vezes mais erros do que aquelas com as taxas de acoplamento-coesão mais baixas e eram 20 vezes mais caras de corrigir.
    • Embora os estudos tenham mostrado resultados inconclusivos em relação à correlação entre os tamanhos das rotinas e a taxa de erros nelas, um estudo descobriu que as rotinas com menos de 143 linhas de código eram 2,4 vezes mais baratas para consertar do que as rotinas maiores. Outro estudo mostrou que o código precisava ser alterado pelo menos quando as rotinas tinham uma média de 100 a 150 linhas de código. Outro estudo descobriu que a complexidade estrutural e a quantidade de dados em uma rotina estavam relacionadas a erros, independentemente de seu tamanho.
    • As interfaces entre as rotinas são algumas das áreas de um programa mais sujeitas a erros. Um estudo mostrou que 39 por cento de todos os erros eram erros na comunicação entre as rotinas.
    • Os parâmetros não utilizados são correlacionados com uma taxa de erro aumentada. Em um estudo, apenas 17 a 29 por cento das rotinas com mais de uma variável não referenciada não apresentaram erros, em comparação com 46 por cento nas rotinas sem variáveis ​​não utilizadas.
    • O número de parâmetros de uma rotina deve ser 7 no máximo, pois a pesquisa descobriu que as pessoas geralmente não conseguem controlar mais do que cerca de sete blocos de informações de uma vez.
  • Organização do código-fonte (em classes , pacotes ou outras estruturas). Ao considerar a contenção , o número máximo de membros de dados em uma classe não deve exceder 7 ± 2. A pesquisa mostrou que esse número é o número de itens discretos que uma pessoa pode lembrar enquanto realiza outras tarefas. Ao considerar a herança , o número de níveis na árvore de herança deve ser limitado. Descobriu-se que as árvores de herança profunda estão significativamente associadas a taxas de falha aumentadas. Ao considerar o número de rotinas em uma classe, ele deve ser o menor possível. Um estudo em programas C ++ encontrou uma associação entre o número de rotinas e o número de falhas.
  • Documentação de código
  • Ajuste de código

Teste de construção

O objetivo dos testes de construção é reduzir a lacuna entre o momento em que as falhas são inseridas no código e o momento em que essas falhas são detectadas. Em alguns casos, o teste de construção é executado depois que o código foi escrito. Na programação teste-primeiro , os casos de teste são criados antes que o código seja escrito. A construção envolve duas formas de teste, que muitas vezes são realizadas pelo engenheiro de software que escreveu o código :

Reuso

Implementar a reutilização de software envolve mais do que criar e usar bibliotecas de ativos. Requer formalizar a prática de reúso , integrando processos e atividades de reúso ao ciclo de vida do software . As tarefas relacionadas à reutilização na construção de software durante a codificação e teste são:

Qualidade de construção

As principais técnicas usadas para garantir a qualidade do código conforme ele é construído incluem:

  • Teste de unidade e teste de integração . Um estudo descobriu que as taxas médias de detecção de defeitos dos testes de unidade e de integração são de 30% e 35%, respectivamente.
  • Desenvolvimento test-first
  • Uso de asserções e programação defensiva
  • Depurando
  • Inspeções . Um estudo descobriu que a taxa média de detecção de defeitos nas inspeções formais de código é de 60%. Em relação ao custo de localização de defeitos, um estudo descobriu que a leitura do código detectou 80% mais falhas por hora do que o teste. Outro estudo mostrou que custa seis vezes mais detectar defeitos de projeto por meio de testes do que por meio de inspeções. Um estudo da IBM mostrou que apenas 3,5 horas eram necessárias para encontrar um defeito por meio de inspeções de código, em comparação com 15 a 25 horas por meio de testes. A Microsoft descobriu que leva 3 horas para encontrar e corrigir um defeito usando inspeções de código e 12 horas para encontrar e corrigir um defeito usando testes. Em um programa de 700 mil linhas, foi relatado que as revisões de código eram várias vezes mais econômicas do que os testes. Estudos descobriram que as inspeções resultam em 20% a 30% menos defeitos por 1000 linhas de código do que práticas de revisão menos formais e que aumentam a produtividade em cerca de 20%. As inspeções formais geralmente ocuparão de 10% a 15% do orçamento do projeto e reduzirão o custo geral do projeto. Os pesquisadores descobriram que ter mais de 2 a 3 revisores em uma inspeção formal não aumenta o número de defeitos encontrados, embora os resultados pareçam variar dependendo do tipo de material que está sendo inspecionado.
  • Revisões técnicas . Um estudo descobriu que as taxas médias de detecção de defeitos de revisões informais de código e verificação documental são de 25% e 40%, respectivamente. Os walkthroughs mostraram ter uma taxa de detecção de defeitos de 20% a 40%, mas também foram caros, especialmente quando as pressões do projeto aumentaram. A leitura do código foi encontrada pela NASA para detectar 3,3 defeitos por hora de esforço contra 1,8 defeitos por hora para teste. Ele também encontra de 20% a 60% mais erros ao longo da vida do projeto do que diferentes tipos de teste. Um estudo de 13 revisões sobre reuniões de revisão, descobriu que 90% dos defeitos foram encontrados na preparação para a reunião de revisão, enquanto apenas cerca de 10% foram encontrados durante a reunião.
  • Análise estática (IEEE1028)

Estudos têm mostrado que uma combinação dessas técnicas precisa ser usada para atingir uma alta taxa de detecção de defeitos. Outros estudos mostraram que pessoas diferentes tendem a encontrar defeitos diferentes. Um estudo descobriu que as práticas de programação extrema de programação em pares , verificação de mesa , teste de unidade , teste de integração e teste de regressão podem atingir uma taxa de detecção de defeitos de 90%. Um experimento envolvendo programadores experientes descobriu que, em média, eles foram capazes de encontrar 5 erros (9 na melhor das hipóteses) de 15 erros por meio de testes.

80% dos erros tendem a se concentrar em 20% das aulas e rotinas do projeto. 50% dos erros são encontrados em 5% das aulas do projeto. A IBM conseguiu reduzir os defeitos relatados pelo cliente por um fator de dez para um e reduzir seu orçamento de manutenção em 45% em seu sistema IMS, reparando ou reescrevendo apenas 31 de 425 classes. Cerca de 20% das rotinas de um projeto contribuem com 80% dos custos de desenvolvimento. Um estudo clássico da IBM descobriu que poucas rotinas do OS / 360 sujeitas a erros eram as entidades mais caras. Eles tinham cerca de 50 defeitos por 1000 linhas de código e consertá-los custa 10 vezes o que seria necessário para desenvolver todo o sistema.

Integração

Uma atividade chave durante a construção é a integração de rotinas , classes , componentes e subsistemas construídos separadamente . Além disso, um sistema de software específico pode precisar ser integrado a outros sistemas de software ou hardware. As preocupações relacionadas à integração da construção incluem o planejamento da sequência em que os componentes serão integrados, a criação de andaimes para suportar as versões provisórias do software , a determinação do grau de teste e o trabalho de qualidade realizado nos componentes antes de serem integrados e a determinação dos pontos do projeto em que versões provisórias do software são testadas.

Tecnologias de construção

Problemas de tempo de execução orientado a objetos

Linguagens orientadas a objetos oferecem suporte a uma série de mecanismos de tempo de execução que aumentam a flexibilidade e adaptabilidade dos programas, como abstração de dados , encapsulamento , modularidade , herança , polimorfismo e reflexão .

Abstração de dados é o processo pelo qual dados e programas são definidos com uma representação semelhante em forma ao seu significado, enquanto oculta os detalhes de implementação. A pesquisa acadêmica mostrou que a abstração de dados torna os programas cerca de 30% mais fáceis de entender do que os programas funcionais.

Asserções, projeto por contrato e programação defensiva

Asserções são predicados executáveis ​​que são colocados em um programa que permitem verificações de tempo de execução do programa. O projeto por contrato é uma abordagem de desenvolvimento em que pré-condições e pós-condições são incluídas para cada rotina. A programação defensiva é a proteção de uma rotina de ser interrompida por entradas inválidas.

Tratamento de erros, tratamento de exceções e tolerância a falhas

Tratamento de erros refere-se à prática de programação de antecipar e codificar as condições de erro que podem surgir quando o programa é executado. O tratamento de exceções é uma construção de linguagem de programação ou mecanismo de hardware projetado para tratar a ocorrência de exceções, condições especiais que alteram o fluxo normal de execução do programa. A tolerância a falhas é uma coleção de técnicas que aumentam a confiabilidade do software, detectando erros e, em seguida, recuperando-os, se possível, ou contendo seus efeitos, se a recuperação não for possível.

Técnicas de construção baseadas em estado e baseadas em tabelas

A programação baseada em estado é uma tecnologia de programação que usa máquinas de estado finito para descrever os comportamentos do programa. Um método baseado em tabela é um esquema que usa tabelas para pesquisar informações em vez de usar instruções lógicas (como if e case).

Configuração de tempo de execução e internacionalização

A configuração de tempo de execução é uma técnica que vincula valores de variáveis ​​e configurações de programa quando o programa está em execução, geralmente atualizando e lendo arquivos de configuração em um modo just-in-time. Internacionalização é a atividade técnica de preparação de um programa, geralmente um software interativo, para oferecer suporte a vários locais. A atividade correspondente, localização , é a atividade de modificar um programa para oferecer suporte a um idioma local específico.

Veja também

Notas

Referências

links externos