<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Siccome la fase di analisi e design e' la piu' importante, la cosa migliore e'<br>
cercare delle soluzioni condivise dai partecipanti e soffermarsi sulle<br>
discussioni riguardanti le scelte architetturali e tecnologiche anche settimane<br>
prima di mettersi a sviluppare.<br></blockquote><div><br>Concordo, una analisi errata significa rifare tutto<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Visto che ci sono le due scuole, "web" e "standalone", perche' non pensare a<br>
entrambe? Magari un core unico, e due interfacce. Cosi' il team di sviluppo si<br>
potrebbe dividere in due o tre sotto-team: core, web, qt(o chi per lui), e, se<br>
necessario, DB.<br></blockquote><div><br>La vedo dura. Le filosofie come quella da te proposta somigliano molto a OpenERP. <br>Solo che richiederebbe un server (non web) e due client. Ovvero doppio lavoro per avere lo stesso prodotto.<br>
Il client web ha il pregio di funzionare anche standalone (non si puo' dire l'opposto).<br>Personalmente sono un pigro, fare due volte il lavoro non mi piace.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
C'e' da considerare la questione non banale delle licenze. Forse meglio<br>
scegliere prodotti piu' liberi/open source possibile.<br>
</blockquote></div><br>Infatti per il web proponevo TurboGears2, completamente Open in tutti i suoi componenti (Pylons, Genshi, SqlAlchemy, etc.)<br><br>Carlos<br>