Conversando hoje pela manhã com o experientíssimo Arquiteto de Sistemas Sênior, o Sr. Claudio Teixeira, sobre requisitos funcionais e não-funcionais de um sistema distribuído que estamos projetando e desenvolvendo, nos deparamos com alguns pontos “extraordinários” de problemas que podem acontecer quando desenvolve-se produtos de software para corporações que não são do ramo de TI, por exemplo:

  • Armazenamento e versionamento de documentos;
  • Criptografia de dados e arquivos;
  • Ambiente redundante de servidores;
  • etc;

Descobrimos que estávamos indo um pouco além dos requisitos não-funcionais realmente necessários para que esse produto possa ser utilizado pelos seus usuários, saindo do escopo do aplicativo e entrando em escopo de software básico e infra, assim, relembramos velhos termos uvidos no passado como:

  • “Cuidado para o ótimo não virar inimigo do bom”;
  • “Keep It Simple, Stupid!” - KISS Theory;
  • “Make it work, then, make it better”;
  • etc;

Devemos nos lembrar sempre que todo software e hardware ( sistema ) tem suas qualidades e restrições, e que é impossível desenvolver um projeto que faça tudo o que o usuário deseja de uma única vez pois as funcionalidades e restrições estão ligados diretamente ao custo, prazo e qualidade do sistema, portanto devemos ter sempre em mentes as seguintes linhas gerais:

  • Não aumentar a complexidade do que já é complexo;
  • Criar componentes e utilizar “frameworks” de mercado para facilitar a manutenção;
  • Trabalhar com ciclo de vida de produto;

Sendo assim, toda vez que formos participar de um projeto de software, principalmente na etapa de venda e projeto, devemos estar cientes e principalmente deixar o cliente confortável com o que vai ser feito, quando vai ser entregue e que melhorias podem ser implementadas ao curto e médio prazo num sistema de informação.

Bom trabalho a todos.

PageRank