Ao desenvolver o sistema, tínhamos sempre como diretrizes a escalabilidade, consistência e robustez do mesmo, uma vez que o sistema anterior que estava sendo utilizado certamente não suportaria a carga a que seria submetido devido a diversos fatores, que serão descritos mais além.
Durante a especificação o sistema foi modularizado, de onde foram delineados os seguintes subsistemas: sistema de cadastro, sistema financeiro do cliente, sistema de administração do cliente e sistema financeiro para controle interno. Estes foram os subsistemas principais, sendo que cada um ainda foi desmembrado em mais subsistemas e outros que não necessitariam uma interface gráfica com o usuário foram criados.
Nesta fase porém, senti muita falta de métodos para especificação e
design de software. Ainda assim, conseguimos especificar de maneira
satisfatória uma boa parte do sistema. O modelo utilizado para interação dos módulos
é um bom exemplo. Foi utilizado um modelo arquitetônico de repositório, pois não havia
necessidade de uma interação direta entre os módulos. Já no 2
semestre, com
a disciplina de Engenharia de Software, passei a ter um conhecimento maior das
ténicas de projeto que deveriam ser aplicadas. Entretanto, não pude aplicar tudo
corretamente, pois o sistema já estava especificado e mudá-lo naquele momento só
atrasaria o projeto.
O banco de dados utilizado como repositório é o PostgreSQL2.1. Anteriormente utilizávamos o MySQL2.2, que é bastante viável para pequenas aplicações, porém não possui muitas das características que um banco de dados deve ter para uma aplicação um pouco complexa, como: suporte a transações(ACID), CASCADING DELETING, múltiplos modos de indexação e uma maior robustez. Não pude, infelizmente, participar em todo o processo de modelagem do nosso banco de dados, mas juntamente com mais uma pessoa administro o banco de dados. Para configuração, administração e até mesmo para amprender muitos outros comandos SQL tive de consultar os três manuais do PostgreSQL [6].
Infelizmente, ao longo do tempo de desenvolvimento alguns dos defeitos estruturais da especificação começaram a surgir, alguns foram descobertos na fase de design e outros na parte da implementação. Outro problema que às vezes acarretava numa revisão do que havia sido especificado inicialmente era o surgimento de novas idéias que inicialmente não eram fundamentais para o projeto e passaram a ser, como por exemplo a inclusão de algum outro serviço/produto que seria oferrecido ao cliente. No entanto, não tivemos de fazer grandes mudanças radicais na especificação, só pequenos ajustes.