Dicas para o desenvolvimento de um software – Parte 4

Dicas para o desenvolvimento de um software - Parte 4O quarto artigo sobre dicas para desenvolver um software funcional abrange alguns conceitos ligeiramente mais avançados. Após as doze dicas abordadas nos três primeiros artigos, este envolve aspectos relacionados ao aperfeiçoamento das funcionalidades de um sistema. Agradeço novamente a todos os leitores que estão acompanhando os artigos, e espero que de alguma forma essas dicas tenham agregado um pouco mais de conhecimento.

 

Normalização de dados
Na maioria dos cursos relacionados a desenvolvimento de sistemas, é comum encontrar uma disciplina que mencione a Normalização de Dados, fundamental para a formação de analistas e programadores. Este assunto sugere uma série de procedimentos aplicados à modelagem de dados para garantir a boa estruturação de um banco de dados. Essa modelagem é responsável pela integridade, confiabilidade e desempenho das operações realizadas nas tabelas. Alguns dos pontos mais importantes abordados pela normalização de dados envolve a utilização imprescindível de chaves primárias, chaves estrangeiras, criação de tabelas intermediárias para relacionamentos muitos-para-muitos (N:N) e criação de tabelas para campos multivalorados, como e-mails e telefones. Além de ser uma prática essencial para o projeto de um sistema, a normalização de dados também garante a motivação dos relacionamentos entre as tabelas e facilita futuras manutenções na estrutura.
A modelagem do banco de dados de um sistema devem passar basicamente por três formas normais da normalização de dados, que consistem em eliminar campos repetitivos entre tabelas, impedir valores redundantes e relacionar as tabelas por meio de chaves estrangeiras. É muito importante estudar a aplicar este conceito dentro do desenvolvimento de um sistema.


Consultas compostas

Boa parte dos sistemas atuais possuem uma padronização para consultas de dados, normalmente pelos campos mais comuns da tabela. Por exemplo, em um cadastro de clientes, a consulta pode ser realizada por nome, cidade ou CPF. No entanto, há situações em que pode ser necessário consultar clientes por endereço, telefone, estado, profissão ou estado civil. Ok, basta então adicionar estes campos às opções de consulta, correto? Bem, é uma alternativa, mas imagine que o usuário também queira pesquisar os clientes que moram no estado de São Paulo, são do sexo masculino e também trabalhem como motorista. Neste caso, a solução é criar uma consulta composta, que consiste em uma busca por vários campos ao mesmo tempo. Uma ideia para implementar essa funcionalidade seria utilizar os mesmos campos de cadastro para a consulta de dados, ou seja, o usuário pode preencher quaisquer campos por quais deseja consultar, e ao clicar no botão de pesquisa o sistema verifica os campos preenchidos e concatena uma SQL internamente para enviar ao banco de dados. É uma funcionalidade bem interessante, mas caso for utilizá-la, atente-se às cláusulas where e and, e confira se a busca realmente corresponde ao que foi solicitado pelo usuário.

Exemplo de SQL Composta
Exemplo de SQL Composta

 

Integração com serviços web
Com o crescimento da internet e de recursos online, tornou-se comum a integração de sistemas desktop com serviços web para facilitar ou agilizar operações. Um exemplo bem prático é o envio de arquivos de Nota Fiscal Eletrônica. Nos primórdios de sua utilização, os usuários geravam um arquivo XML pelo sistema, acessavam outro aplicativo para envio do arquivo, validavam o XML e por fim imprimiam a DANFE. Todo este processo era trabalhoso e gerava dificuldades para os usuários. Felizmente, a integração dos sistemas desktop com os chamados WebServices possibilitou que este procedimento fosse realizado diretamente pela aplicação principal, sem a intervenção do usuário para manipular os arquivos XML. Além deste exemplo, outros serviços web também podem ser agregados à aplicação, como consulta de endereços por CEP, mapas de localização (Google Maps), feed de notícias e outros tipos de informações online. Os desenvolvedores podem ainda disponibilizar um módulo do sistema na web interligado com o sistema desktop, permitindo, por exemplo, que os usuários tenham acesso aos dados do sistema pela internet, sem necessariamente utilizarem o sistema desktop. A imagem abaixo ilustra o funcionamento do WebService da Serasa para consulta de CPF:

WebService - Consulta de CPF
Fonte: http://www.consultacpf.com/integracao.aspx

 
Cuidado com o que o seu cliente pede

Há muito que ser abordado neste último item, por tratar-se de uma questão mais voltada para análise do que desenvolvimento. Normalmente, os usuários que operam o sistema no dia-a-dia sentem necessidade de novos campos nas telas, botões para novas funcionalidades ou atalhos para agilizar as operações. É muito comum ouvirmos frases como:

“Há possibilidade de colocar um ‘botãozinho’ aqui?”
“Eu precisava de um campo aqui para digitar tal informação…”
“Preciso de uma tela nesse menu pra ficar mais fácil…”

É claro, bons analistas e desenvolvedores devem prestar o máximo de suporte, visando suprir qualquer necessidade do cliente. Mas há casos em que é preciso rejeitar a sugestão do cliente para garantir a integridade e simplicidade do software. Quando o cliente pede um novo campo na tela, deve-se fazer um estudo da real utilidade de sua inclusão, e se este também será útil para outros clientes que operam o mesmo sistema. É possível também que o campo já exista, mas não é de conhecimento do usuário. Neste ponto vale ressaltar a importância dos treinamentos do sistema para os usuários, além da capacitação da equipe de suporte para identificar esse tipo de situação. Uma simples orientação fornecida ao cliente pode evitar que a equipe de desenvolvimento adicione uma nova funcionalidade sem objetivo algum. Além disso, adicionar um novo campo, botão ou funcionalidade no sistema pode comprometer o visual, trazer inconsistências no cadastro ou causar redundância de informações. Analisar detalhadamente as sugestões de clientes sempre será uma atividade essencial durante o ciclo de vida de um software.

 

Obrigado novamente pela atenção, leitores!
Até breve!


Confira também as outras partes deste artigo:

Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Boa Noite, André.

    Desde o inicio do meu aprendizado(‘muitos anos atrás’), dei muita atenção a estrutura e relacionamento dos BDs, tentando compreender o que outros criaram, aproveitei conceitos que achei válidos, descartei outros, alguns achei absurdos. Sempre me diverti analisando um BD, por curiosidade ou para importar os dados.
    Hoje, sei que é preciso atualizar os conceitos de estrutura e relacionamento, para melhorar tanto a performance como a abrangência dos resultados de uma pesquisa. Tenho o meu melhor caso neste sentido, a pesquisa de pedidos, onde é possível selecionar qualquer informação, por período, cliente, tipo fiscal, outras informações relevantes, individualmente ou compostas, mas algumas podem envolver grande quantidade de dados, para compilar os relatórios adicionais, entra as orientações do artigo anterior.
    Esses ‘pedidos’ dos clientes, realmente podem ser um problema, mas você colocou muito bem, muitas vezes a função já existe e o que falta é a orientação para o cliente. Aceitar a inclusão de uma função, campo, nova tela, eu especifico no contrato de ‘Licença de uso’ e só será implantada se for útil para o software e para os outros usuários, mas, se gosto da sugestão, coloco como opção (parâmetro) e habilito para quem achar útil.
    Mais uma vez, obrigado pelos artigos.

    1. Isso mesmo, Gerson! Muitas vezes, uma simples orientação ao usuário evita que um erro seja reportado à equipe de desenvolvimento ou uma nova funcionalidade que já existe seja solicitada. Isso já nos faz entrar na questão da Engenharia de Valor, abordada em um dos artigos recentes do blog.
      A parametrização é uma boa tática para habilitar funcionalidades exclusivas para cada cliente, já que evita a necessidade de várias compilações a cada entrega e mantém a aplicação mais flexível às mudanças do mercado. Esse tema também já foi abordado no blog! 🙂

      Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.