Category: Qualidade

A importância da boa documentação de software

Documentação de Software

/* Quando falamos da importância da boa documentação de software, em projetos desta natureza, a imagem acima é talvez a melhor ilustração. É uma imagem “batida”, mas é sempre bom revisitá-la. */

Em projetos de software, quando ha especificação antes da construção, é muito comum o nível da documentação não estar bom, e isso gerar efeitos muito ruins no projeto. (more…)

A origem dos bugs de software

bugs de softwareQual é 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 codificação(more…)

Como ter mais qualidade no desenvolvimento de software

Como aumentar a qualidade no Desenvolvimento de Software - Qualidade Garantida - Cliente Satisfeito

Qualidade no desenvolvimento de software

Como aumentar a qualidade no Desenvolvimento de Software é um desejo de vários profissionais de software.

Talvez, as soluções mais eficazes para isso estão nas iniciativas mais simples.

Mas para que simplificar se podemos complicar né!

Esse ditado popular é péssimo, mas reflete um vício que temos que deveria ser urgentemente revisto por todos nós. Muitas vezes esquecemos, ou deixamos de pensar, que a quantidade de bugs num software é proporcional à sua complexidade.

(more…)

Caso de Uso – Include, Extend e Generalização

Caso de Uso e Programação

Fazer um Caso de Uso, dependendo do ponto de vista, não é algo muito diferente do que programar.  É possível fazer um bom trabalho, sob um mesmo ponto de vista, tanto na modelagem quanto na codificação.

Sabia que é possível utilizar uma linguagem de programação Orientada a Objetos e fazer um software com programação não orientada à objetos?

Sim, é possível fazer em C# ou Java, por exemplo, um software programado de maneira “quase” estruturada. Muito disso é POG!

Nessa mesma linha de raciocínio, é possível utilizar modelagem de caso de uso em um projeto, mas no fim das contas, ter algo mais próximo de diagramas de fluxo de dados do que de diagramas de Caso de Uso.

Obs.: infelizmente na área de software muitos profissionais dão pouca importância à qualidade, não se apegam os detalhes. Fazem as coisas por fazer, sem saber a fundo o que estão fazendo, ou porque estão fazendo.

Nem sempre é culpa do profissional, é uma área com muitos dirigentes despreparados.

Os diagramas de Caso de Uso são relevantes?

Relevante é. Mas depende da qualidade do que foi produzido.

Sempre haverá o profissional arrogante que vai analisar o diagrama de caso de uso e diz: “perdeu tempo fazendo isso? Um desenho com bonecos de palito, bolinhas e setinhas ligando as coisas?”.

Outro alguém pode falar: “para que especificar. Até minha mãe faz um diagrama melhor… desenhar bonecos e bolas não tem sentido, não agrega nada ao projeto!”.

/* Já ouvi um gerente sênior falando da mãe dele, como foi descrito.  Acontece… */

Excetuando a ironia e falta de gentileza, realmente, fazer um “desenho” (diagrama) com bonecos de palito e bolas, ligando estas coisas, sem ter sentido semântico algum nisso, com baixa qualidade no material produzido, não tem utilidade mesmo.

É perder tempo, tempo que poderia ser empregado em coisas mais úteis ao projeto.

Mas se for um trabalho bem feito, se for um diagrama produzido com qualidade, que realmente explora as possibilidades da técnica de modelagem de caso de uso, utiliza a técnica corretamente e ajuda a toda a equipe a entender e implementar o escopo do projeto da melhor forma, aí gera valor, aí torna-se relevante.
(more…)

O Débito Técnico

debito-tecnico-como-o-cliente-ve-como-o-desenvolvedor-ve-realidade-okNem sempre temos condições de fazer, da melhor maneira, o que tem que ser feito. Eu não gosto disso, mas a realidade nas empresas que produzem software, em muitos casos – mas não todos – não é muito legal, quando falamos da qualidade dos projetos executados.

Para entender melhor o que citei acima, entenda porque os projetos de software não costumam dar certo.

E se não dá para fazer tudo da melhor maneira possível, coisas ficam por fazer. Vamos entender estas coisas como sujeira. E vamos considerar que esta sujeira é jogada para debaixo do tapete.

Esta sujeira é o que chamamos, em projetos de software, de débito técnico, ou dívida técnica.
(more…)

Diferença de Requisito Funcional e Regra de Negócio

Diferença de Requisito Funcional e Regra de Negócio - Maça e Banana

Diferença de Requisito Funcional e Regra de Negócio é algo comum na cabeça de vários Analistas de sistemas.

Eu imagino que antes do lançamento do microcomputador, o termo “Regra de Negócio” era algo interpretado totalmente isolado dos softwares empresariais, ou talvez nem fosse um termo conhecido pelas pessoas.

Nos tempos atuais é difícil encontrar alguém que entende Regra de Negócio como algo isolado do software.

Quando se fala “Regra de Negócio”, praticamente sempre é no contexto de um sistema.

Estes dois conceitos  (requisito funcional e Regra de Negócio) se encontram (se cruzam) a toda hora na modelagem de um sistema, mas são coisas diferentes.

É possível uma empresa mais arcaica viver sem software, mas mesmo uma empresa arcaica não consegue viver sem regras de negócio.

(more…)