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.
