2.1. Considere as prioridades do projeto.
É claro que você quer construir um sistema que atenda às necessidades de seus usuários. Mas, há outros fatores concorrentes que você deve considerar em seu projeto, como os seguintes:
Cada uma dessas prioridades afeta o sistema como um todo. Nem sempre você poderá optar pela melhor modelagem possível, às vezes você terá que trabalhar naquela que é a mais econômica, outra vez será a mais segura, outra vez a que suporta a maior carga.
A definição dessas variáveis deve acontecer logo no início do projeto, antes mesmo de se iniciar a modelagem. Mudanças nas prioridades afetam a arquitetura, fazendo com que você utilize uma ou outra alternativa.
Cada caso de uso representa uma funcionalidade necessária para seu sistema. Alguns casos de uso podem ser mais importantes do que outros, e dado o seu orçamento e prazo disponível você pode ter que escolher quais casos de uso para implementar e quais deixar para outra versão do sistema. Talvez a primeira versão do sistema de geração de boletos implemente o básico: emitir boletos ao finalizar uma compra e emitir boletos para compras não pagas. A próxima versão vai lidar com recursos de integração bancária, por exemplo.
XVocê pode (e deve) projetar o sistema para ser modular. Dessa forma, quando os usuários mudarem de ideia (mudar uma regra de negócio), o seu design será fácil de mudar. No entanto, fazer sistemas flexíveis leva mais tempo para projetor e custará mais caro para construir. Você poderá implementar um sistema que gere qualquer tipo de boleto de pagamento, para qualquer tipo de banco, e qualquer empresa, tudo baseado em parâmetros, de forma flexível. Caso a empresa mude de banco, agência ou conta, será fácil mudar o sistema. Certamente, essa flexibilidade terá um custo maior, quase sempre a relação custo x benefício justifica valer a pena a flexibilidade.
XA maioria das arquiteturas de desenvolvimento modernas consideram a escalabilidade, a disponibilidade, confiabilidade, rastreabilidade, segurança, criptografia, etc. Uma arquitetura que seja capaz de gerar um boleto para um cliente deve ser a mesma capaz de gerar dezenas de boletos, de bancos diferentes de clientes e compras distintas sem nenhuma mudança significativa do projeto. “Fazer bem feito uma vez para servir para sempre”. Esse fundamento é essencial para evitar mudanças corretivas e adaptativas no futuro. Seu sistema deve funcionar em escala: “o que serve para um deve servir também para muitos”. Se o sistema deve funcionar em um ambiente 24/7, então você deve considerar uma arquitetura que prevê redundância a fim de que seu sistema suporte a grande maioria das possíveis falhas.
XA arquitetura que você define está intimamente ligada com a performance do sistema. Se o sistema não está rápido o suficiente, então os clientes do sistema podem deixar de usá-lo ou considerá-lo muito ruim. Se o sistema está rápido demais, pode ser que você tenha gasto muito mais do que o necessário. Para todo sistema a seguinte pergunta é sempre válida: “quão rápido é o desejável”. Você perceberá que a grande maioria dos sistemas esperam respostas entre 1 e 5 segundos como o desejável e 10 segundos como limite para momentos de pico. Acima disso podem ser considerados “sistemas lentos”.
XA grande maioria dos projetos de software obedecem a um orçamento. A modelagem e a construção devem estar alinhadas para não custarem acima do orçamento estipulado, do contrário, o sistema pode ficar sem partes construídas ou dar prejuízo à organização.
XAssim como o orçamento, aquele que paga pelo sistema possui requisitos de quando o sistema estará pronto para uso. Às vezes os prazos possuem um pouco de flexibilidade, outras vezes não. Consente-se em descobrir o que é mais flexível para o projeto: o prazo, o custo ou o escopo. Se o projeto andar mal (ou for mal estimado), um dos três aspectos será sacrificado.
X