Tecnologia da Informação

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.

Comentários fechados devido á spans!