Você está na página 1de 11

CURSO CASOS DE USO EBOOK CASOS DE USO 

Home  Design de Software 

BUG DEFEITO ENGENHARIA DE REQUISI… EXCEPTION QUALIDADE DE SOFTWARE

A origem dos bugs de software


By Plínio Ventura On 29 Aug, 2016 Last updated 10 Feb, 2019
 6

Compartilhe!

 Facebook  Twitter  Google+  Pinterest

Qual é
a
origem
dos
bugs

de  software? As causas estão apenas no código fonte “bugados”?


Exception é o único efeito causado pelos bugs?

É algo surpreendente quando entendemos que a maior causa dos bugs


não está no código fonte.

Neste post vamos entender como os bugs surgem nos projetos de


software, e perceberemos  que o problema vai muito além de furos na
codi cação. 

Bugs são Defeitos


Em termos práticos, bug de software é um defeito no software. Por uma
questão de lógica tendemos a  pensar que apenas uma  coisa em
funcionamento pode ter defeito.
Se algo não está funcionando como deveria, há um defeito.

Mas é uma visão muito materialista acerca dessa questão.  Vamos


pensar em dois cenários distintos para compreender melhor este
raciocínio.

Bugs se manifestam apenas no


produto final?

Imaginemos um bebê que nasce com alguma de ciência, ou uma fruta


que nasce com alguma de ciência.

Quando um bebê nasce com alguma de ciência física, por exemplo,


identi ca-se tal de ciência a partir de algum exame físico no corpo do
bebê.

Se não há um corpo, a maioria entende que, em princípio, não há como


identi car a de ciência, pois “não há o que examinar”.

No caso da fruta, se tivermos por exemplo,  duas bananas coladas (ao


invés de separadas – quando eu era criança minha mãe falava que eram
bananas gêmeas, rs), o raciocínio aplicável é semelhante.

Identi ca-se a de ciência na banana porque ela está materializada. Se


não há banana, a maioria entende que não há como identi car a
de ciência, pois não há o que examinar.

Mas precisamos entender que antes de algo se materializar “de fato”, é


necessário haver um projeto daquilo, que é re etido em um modelo.
Não é plausível algo ser produzido sem um modelo anterior. Se assim
fosse, o mundo perderia sua lógica, pois haveria mágica ao invés de
engenharia!


/* Lembrando que mágica é uma ilusão. Todo efeito tem
causa, isso é uma lei (procure sobre Lei de Causa e Efeito)
para entender melhor.*/

No caso dos bebês, há modelos genéticos por trás do corpo


materializado, onde informações diversas estão organizadas para se
“compilar” o produto disso no corpo do bebê.  Por exemplo: material
genético dos pais, remédios tomados pela mãe durante a gestação,
estrutura do DNA da criança etc.

No caso da banana, vai na mesma linha.

Antes de se ter a banana houve um trabalho de se “projetar” a bananeira,


onde podemos considerar: qualidade das sementes, qualidade e trato do
solo, volume de chuvas no local, combate a pragas, fase da lua na data
da semeadura etc.
Está gostando do conteúdo? Entre em nossa lista VIP e receba as novidades direto no
e-mail!

Email*

Nome*

CADASTRAR

Marketing by

Quando falamos de software, pensamos que apenas o software


executável é origem dos bugs, pois é a parte mais material para nós, é a
mais perceptível.

Mas antes do software executável, que obviamente é produzido a partir


de um modelo de código fonte, várias outros modelos são produzidos
para se chegar até esse momento.

Bugs de software que não estão no


software?
Re ita rapidamente sobre as perguntas abaixo:

Se o software funciona mas está muito lento, é bug?


Se o software faz bem tudo que foi construído, mas não faz tudo
que estava no escopo, é bug?
Se o software faz mais coisas do que deveria fazer, é bug?
Se o software não faz tudo que está no escopo, é bug?
Se o software não faz corretamente o que está no escopo, é bug?
Se o software é difícil de usar, confunde o usuário, não possui help
etc. é bug?
Precisamos rever nossa visão a respeito de bugs de software…

Bugs vão muito além das exceptions

Isso que vemos acima é, sem dúvida, um bug. Um dos mais famosos,
talvez. E é uma exception de software, no software que talvez seja o
mais famoso do mundo: o sistema operacional Windows, principalmente
em suas versões mais antigas.

Mas bugs vão muito além das Exceptions.

Muito do conteúdo deste post são pontos que podem ser estudados no
livro  Software Testing, de Ron Patton. Eu acho este livro espetacular  e
recomendo não apenas para os pro ssionais de Qualidade de Software,
mas para qualquer Analista de Sistemas ou Gerente de Projetos que
trabalhem com produção de software.

Segundo este livro, bugs de software podem ser (a grosso modo)


classi cados, ou ter causa atribuída, a:

Performance proibitiva na execução do software.


Recursos não previstos implementados no software.
Recursos implementados no software mas ausentes no escopo.
Processamento incorreto – diferente do que estava no escopo.
Di culdades proibitivas em termos de usabilidade.

E a maioria das causas citadas acima não estão apenas na codi cação


(ou programação), que produz diretamente  o software executável, mas
re etem-se nesta entrega, obviamente.
As causas estão, na maioria dos casos, nos modelos produzidos que
servem de entrada para a produção do modelo de código fonte, que
quando compilado, geram o software executável (onde as exceptions
explodem).

A maior parte  do problema nasce no


início – nas Especificações
O grá co nos mostra
onde nascem os bugs de
um software, em quais
áreas (ou disciplinas) da
produção de software
eles são gerados.

Segundo Ron Patton (o


grá co está no livro que
citei)  a maior parte
dos bugs são gerados na
Especi cação, ou seja,
no início de tudo, na Concepção do software.

Isso pode soar estranho para alguns, pois como já citamos,


associamos defeito a algo já produzido, já materializado.

Mas como também citamos, um software não  se materializa do nada,


ele precisa ser modelado antes, ser projetado, ser “pensando”.

Causas comuns do nascimento dos


bugs em função de problemas de
Especificação
Como podemos ver no grá co anterior, não é apenas nos Requisitos que
está a causa dos bugs.

Temos uma grande parcela associada a problemas de design, uma


parcela menor em problemas de construção (aqui entra o código fonte),
e uma parcela menor atribuída a “outros fatores”.
Mas vou me ater aos bugs gerados nos requisitos, na concepção do
software, pois  eu defendo que o que começa errado fatalmente vai
terminar errado.  Além de ser a disciplina mais importante dos projetos
de software, e que muitas vezes é jogada para segundo plano, por uma
cultura de que “software bom é software rodando”.

Quando o assunto é especi cação de requisitos, as principais causas


que geram os bugs são:

Não houve Especi cação de Requisitos.


Houve Especi cação de Requisitos mas foi especi cado
incorretamente (geralmente sem o nível de detalhe e clareza
su cientes).
Mudanças de escopo que não foram re etidas na Especi cação de
Requisitos.
Houve Especi cação de Requisitos mas não houve comunicação
adequada com o time de projeto e desenvolvimento.

Isso é um tanto óbvio, não?

O Analista de Sistemas precisa entender que fazer software é um


processo de engenharia e que demanda, no caso de produção de
software, de re namento contínuo, onde o re namento vai sendo feito
conforme o nível de abstração de cada disciplina.

Produzir software não é apenas programar software!

A primeira vez que vi equipes de Testes e QA (QA – Quality Assurance)


trabalhando, abrindo defeitos (registrando bugs para posterior
correção)  para  processamentos lentos demais, telas difíceis de usar,
regras de negócio difíceis de entender, diagramas de classes com alto
acoplamento etc. eu pensei: esse povo é doido?

Depois vi que eles estavam certos e eu estava equivocado. Tive que


rever os meus conceitos…

Conclusão
Devemos realmente entender o problema do cliente, pensar a solução
em todos os detalhes, e então iniciar a tradução disso para software.
E software, como qualquer produto, antes precisa ser idealizado,
analisado, concebido, para então ser materializado.

E sem o devido cuidado na de nição do modelo inicial do sistema, que é


o modelo conceitual, por questões de causa e efeito, todo o trabalho
produzido nos modelos posteriores estará com sua qualidade
fatalmente comprometida, gerando bugs e mais bugs.

Se você gostou do conteúdo deste post, deixe seus comentários, para


ajudar outras pessoas a encontrarem este material! 🙂

Aceita uma dica?


Seja você um Desenvolvedor, um Analista de Negócios, Analista de
Testes ou Gerente de Projetos, entender melhor sobre a Concepção do
software fará toda a diferença na sua performance pro ssional.

Se você quiser dar um salto no seu curriculum quando o assunto é


Concepção de Software, conheça nosso curso sobre Engenharia de
Requisitos, onde  abordamos o tema Engenharia de Requisitos de uma
forma pragmática, voltada ao mercado, sem deixar de lado os
fundamentos mais relevantes da teoria.

Grande abraço!
Junte-se a milhares de leitores inteligentes e receba nossas novidades direto no seu e-
mail (é grátis)!

Email*

Digite o seu melhor e-mail

CADASTRAR

Marketing by

Related Posts via Categories


FAQ03 – Perguntas e Respostas sobre Engenharia de Software
FAQ01 – Perguntas e Respostas sobre Engenharia de Software
Funcionalidades do sistema – o que realmente é utilizado?
O Débito Técnico
FAQ05 – Perguntas e Respostas sobre Agilidade
Analista de Infraestrutura e Requisito Não Funcional
FAQ04 – Perguntas e Respostas sobre Engenharia de Software
O que é Scrum?
Controle de Versão e Requisitos de Software
A importância da boa documentação de software

 bug defeito Engenharia de Requisitos exception qualidade de software

6 Comments Até o Momento 🔒 Privacy Policy 


1 Login

 Recommend 1 t Tweet f Share Sort by Best

Join the discussion…


LOG IN WITH
OR SIGN UP WITH DISQUS ?

Name

Roberto Slomka • 4 years ago


Muito bom o artigo. É preciso chamar a atenção para o fato de que
construir software não é o mesmo que "cuspir código". Por
paradoxal que pareça a tecnologia (ferramentas e linguagens) é o
fator MENOS influente para a qualidade de software. Se assim não
o fosse, bastaria a melhor ferramenta para ter a melhor empresa de
software. É importantíssimo valorizar o elemento humano e suas
habilidades - principalmente as relacionadas à comunicação - para
obter o máximo em qualidade.
Só uma ressalva: bananeiras não nascem de sementes...
△ ▽ • Reply • Share ›

Plínio Ventura Mod > Roberto Slomka • 4 years ago


Oi Roberto, obrigado pela leitura!

Sua observação é muito pertinente. Muito relevante o que


disse, pois sem dúvida alguma, tecnologia é o menor
problema quando o assunto é produção de software. E o
fator humano, neste contexto tantas vezes menosprezado, é
a variável de maior influência na qualidade do produto final.

Mas ainda vivemos num mundo onde a Lei do Menor


Esforço faz parte do status quo. Infelizmente é necessário
que erremos muito para um dia, quando a dor foi muito
forte, reflitamos sobre outros caminhos.

Sobre a bananeira, realmente não sabia, rs. Sou muito


ignorante em assuntos agrônomos, por exemplo.

Abraço!
△ ▽ • Reply • Share ›

Diego Giglio • 4 years ago


Olá, Plínio. Novamente, um grande artigo.
Caiu-me como uma luva para discussões sobre o tempo investido
em engenharia de software. Algumas empresas insistem em ver
essa etapa como "demasiadamente demorada" ou tentam
desesperadamente estabelecer um prazo para sua conclusão, o
que de certa forma é conveniente para os tomadores de decisão
que, como explica o artigo, acabam atribuindo a responsabilidade
pela baixa qualidade (ainda que indiretamente) aos
desenvolvedores ou analistas.

Abraço e obrigado pela dica de leitura.


△ ▽ • Reply • Share ›
Plínio Ventura Mod > Diego Giglio • 4 years ago

Oi Diego. Eu quem agradeço sua leitura! :)

Pois é, essa realidade precisa ser mudada. É claro que a


Engenharia de Requisitos não deve ser um processo sem
fim, mas como demanda criação, reflexão, síntese etc., e é
o momento de entender o "core" da solução, não dá para
conduzi-lo como se fosse uma pastelaria, onde basta ter
gordura fervendo, joga-se o pastel e em 2 minutos está
pronto para comer.

Investir, com bom senso e foco prático, na Engenharia de


Requisitos com excelência, gera benefícios gigantes no
futuro dos sistemas, mas muitos tomadores de decisão são
imediatistas, não entendem (ou não querem entender às
vezes) que é melhor investir no início com o cuidado
necessário, do que produzir um software "todo bugado", e
diminuir suas margens e esgotar suas equipes.

Não há milagre, é engenharia aplicada, e se os pedreiros


tentarem levantar um prédio sem uma arquitetura bem feita

© 2020 - Até o Momento. All Rights Reserved.


Website Design: BetterStudio