View Full Version : Con cosa realizzare questa applicazione ?
Ciao a tutti,
premesso che di programmazione conosco meno che zero chiedo a voi esperti di "indirizzarmi" nella scelta del linguaggio/soluzione piu' adatta per lo sviluppo di un'applicazione.
L'antefatto: anni fa' e' stata realizzata nella mia azienda, in maniera piu' o meno casereccia un'applicazione per il ns. business quotidiano.
In estrema sintesi l'utente deve inserire alcuni dati di input, il programma esegue alcuni calcoli piu' o meno complessi di tipo ingegneristico su questi dati ed altri dati gia' presenti nel programma, restituendo i risultati di tali calcoli a video e su un report Pdf.
Ognuno di questi "progetti" e' salvato in un database locale e su un server centrale (cosi' che tutti possano accedere al lavoro di tutti).
L'applicazione e' basata su un database Access (.mdb) e Java.
Attualmente il programma inizia a "risentire dell'eta'" e altri problemi, si sta' quindi pensando di "riscriverlo" ed ampliarlo con altre funzioni.
Purtroppo chi lo aveva a suo tempo sviluppato non c'e' piu' e non so' per quale motivo e' stato affidato a me il compito di pianificare lo sviluppo della nuova versione.
Ora le specifiche ci sono e ben documentate e la programmazione vera e propria sara' affidata ad una societa' esterna, rimane a me pero' il compito di decidere o quantomeno indirizzare verso la miglior soluzione in termini di linguaggi da impiegare.
La mia idea era quella di "travasare" il DB da Access ad un DB Open Source ed avere un'interfaccia un po' piu' moderna e leggera accessibile via browser Web.
L'applicazione dovra' avere il minor numero di richieste IT possibile (es. NET framework, Visual Basic runtime, etc.), magari essere "Portable", senz'altro funzionare Offline, e dovra' funzionare su PC con SO Windows XP e 7.
Mi sapreste consigliare la soluzione migliore ?
Grazie per la collaborazione
Io penso che la scelta del linguaggio dovresti lasciarla alla software house che si occuperà dello sviluppo. Sono loro che hanno le competenze tecniche per stabilire quale sia la soluzione che meglio risponde alle tue esigenze di committente.
...
:rotfl: :rotfl: :rotfl: :rotfl:
A volte mi faccio morire da solo.
Scherzi a parte, a te che importa della tecnologia che usano? Basta che non sia qualcosa di talmente esotico da non sapere se ci sarà ancora tra cinque anni o da non riuscire a trovare qualcuno che faccia la manutenzione nel caso in cui lo sviluppatore originale scompaia nelle nebbie. Ma soprattutto basta che non ti carichi di costi esorbitanti.
Del genere "ok per 100 euro te lo facciamo in ABAP" e poi paghi un milione e mezzo l'anno per la licenza SAP.
Io penso che la scelta del linguaggio dovresti lasciarla alla software house che si occuperà dello sviluppo. Sono loro che hanno le competenze tecniche per stabilire quale sia la soluzione che meglio risponde alle tue esigenze di committente.
...
:rotfl: :rotfl: :rotfl: :rotfl:
A volte mi faccio morire da solo.
Scherzi a parte, a te che importa della tecnologia che usano? Basta che non sia qualcosa di talmente esotico da non sapere se ci sarà ancora tra cinque anni o da non riuscire a trovare qualcuno che faccia la manutenzione nel caso in cui lo sviluppatore originale scompaia nelle nebbie. Ma soprattutto basta che non ti carichi di costi esorbitanti.
Del genere "ok per 100 euro te lo facciamo in ABAP" e poi paghi un milione e mezzo l'anno per la licenza SAP.
... mi piaccia o no questo mi e' stato chiesto di fare. Credo che i boss debbano decidere l'applicazione e' cosi semplice da poterla far sviluppare all'IT aziendale o effettivamente esternamente. Nel secondo caso vorrebbero arrivare con gia' qualche opzione proprio per evitare che vengano prposte cose "sovradimensionate", troppo costose (es. per licenze etc.) o nel futuro poco manutenibili...
Dunque aspetto lumi...
Mah, ragionandoci su il compito è complesso e interessante.
Diciamo che il programma per quanto esposto sembra fattibile con qualsiasi piattaforma general purpose.
Che strade abbiamo? Se avete un reparto IT, direi:
1. sviluppo interno, manutenzione interna
2. sviluppo esterno, manutenzione interna
3. sviluppo esterno, manutenzione esterna
Escludo il caso "sviluppo interno, manutenzione esterna" perchè sarebbe come dire che dopo lo sviluppo il reparto IT sarebbe esternalizzato e non è bello.
Io direi che i primi due casi, che coinvolgono i programmatori che già avete, richiedano una qualche indagine circa le preferenze di queste persone.
Nel primo caso si tratta di sapere quale piattaforma sia eventualmente già nota perchè se ne scegli una tecnicamente migliore ma non nota a chi dovrà scrivere il programma rischi di non riuscire neppure a sviluppare il programma o di impiegarci un tempo irragionevole. Lo stesso nel caso in cui il programma sia sviluppato esternamente: magari lo fai fare in Java ma chi dovrà aggiustarlo conosce solo .NET o viceversa.
Dico Java o .NET ma nel caso in cui la cosa sia gestita in tutto o in parte internamente potresti valutare piattaforme più esotiche, come Python o Smalltalk. E' vero che sono "più limitate" (non nella capacità ma nel contorno) ma se hai degli esperti sottomano guadagni nei tempi e nell'efficacia di sviluppo e/o manutenzione - questo nell'ipotesi che l'uso di strumenti noti incida in modo apprezzabile sullo sviluppo, affermazione che dal punto di vista logico non è vera in senso assoluto.
Quindi io certamente mi chiederei: "cosa sappiamo fare in azienda".
Il problema dei costi dipende dalla complessità del programma da sviluppare. Non sono chiaramente dei pirla quelli che pagano milioni di euro l'anno per avere SAP: valutano che l'uso di una soluzione interna costerebbe di più o - a volte sbagliando - ritengono di poter ammortizzare il costo fisso di un servizio.
Pur non avendo idea del genere di programma, dal tono mi sembra di capire che non parliamo di qualcosa il cui sviluppo possa richiedere decine di milioni di euro, quindi darei per vantaggioso l'uso di materiali a costo zero.
Se consideriamo l'insieme piattaforma + strumenti di sviluppo + documentazione + database direi che sia .NET che Java rispondano al requisito (Smalltalk non è gratuito, a python mancano dei pezzi, gli altri viaggiano o sull'esotico andante).
.NET ha il vantaggio di essere uno strumento specifico di Windows, che sarebbe il tuo bersaglio e Microsoft non è che venga dalla montagna del sapone in fatto di sviluppo di software.
Java sarebbe avvantaggiata dal fatto che ciò che è gratuito è anche ciò che c'è di meglio. E' sicuramente più "disponibile": con .NET sei limitato ad una decina di linguaggi, con Java ne hai 240. E non è accentrata nelle mani di un solo attore.
Mah, ragionandoci su il compito è complesso e interessante.
Diciamo che il programma per quanto esposto sembra fattibile con qualsiasi piattaforma general purpose.
Che strade abbiamo? Se avete un reparto IT, direi:
1. sviluppo interno, manutenzione interna
2. sviluppo esterno, manutenzione interna
3. sviluppo esterno, manutenzione esterna
Escludo il caso "sviluppo interno, manutenzione esterna" perchè sarebbe come dire che dopo lo sviluppo il reparto IT sarebbe esternalizzato e non è bello.
Io direi che i primi due casi, che coinvolgono i programmatori che già avete, richiedano una qualche indagine circa le preferenze di queste persone.
Nel primo caso si tratta di sapere quale piattaforma sia eventualmente già nota perchè se ne scegli una tecnicamente migliore ma non nota a chi dovrà scrivere il programma rischi di non riuscire neppure a sviluppare il programma o di impiegarci un tempo irragionevole. Lo stesso nel caso in cui il programma sia sviluppato esternamente: magari lo fai fare in Java ma chi dovrà aggiustarlo conosce solo .NET o viceversa.
Dico Java o .NET ma nel caso in cui la cosa sia gestita in tutto o in parte internamente potresti valutare piattaforme più esotiche, come Python o Smalltalk. E' vero che sono "più limitate" (non nella capacità ma nel contorno) ma se hai degli esperti sottomano guadagni nei tempi e nell'efficacia di sviluppo e/o manutenzione - questo nell'ipotesi che l'uso di strumenti noti incida in modo apprezzabile sullo sviluppo, affermazione che dal punto di vista logico non è vera in senso assoluto.
Quindi io certamente mi chiederei: "cosa sappiamo fare in azienda".
Il problema dei costi dipende dalla complessità del programma da sviluppare. Non sono chiaramente dei pirla quelli che pagano milioni di euro l'anno per avere SAP: valutano che l'uso di una soluzione interna costerebbe di più o - a volte sbagliando - ritengono di poter ammortizzare il costo fisso di un servizio.
Pur non avendo idea del genere di programma, dal tono mi sembra di capire che non parliamo di qualcosa il cui sviluppo possa richiedere decine di milioni di euro, quindi darei per vantaggioso l'uso di materiali a costo zero.
Se consideriamo l'insieme piattaforma + strumenti di sviluppo + documentazione + database direi che sia .NET che Java rispondano al requisito (Smalltalk non è gratuito, a python mancano dei pezzi, gli altri viaggiano o sull'esotico andante).
.NET ha il vantaggio di essere uno strumento specifico di Windows, che sarebbe il tuo bersaglio e Microsoft non è che venga dalla montagna del sapone in fatto di sviluppo di software.
Java sarebbe avvantaggiata dal fatto che ciò che è gratuito è anche ciò che c'è di meglio. E' sicuramente più "disponibile": con .NET sei limitato ad una decina di linguaggi, con Java ne hai 240. E non è accentrata nelle mani di un solo attore.
Molto interessante. Guarda, diciamo che a livello di soldi, licenze, etc. non c'e' problema, o quasi, a livello aziendale. Ma a livello di dipartimento i soldi per IT a noi dedicato e' prossimo allo zero. Quindi occorrera' sviluppare o far sviluppare qualcosa che sia il piu' semplice, manutenibile e upgradabile ed economico possibile.
In fin dei conti allo stato attuale stiamo parlando di un file Access di 30 MB e credo non moltissime righe di codice di Java....
Da profano e per sentito dire, chiedo... XAMPP installato localmente che a fine sessione comunica con il ns. server centrale non puo' essere sufficiente ?
Il problema di volerlo "semplice, manutenibile, estendibile" è che difficilmente qualcuno potrebbe dirti "no, noi lo facciamo complicato ma mai quanto difficile da aggiustare e certamente non potrai aggiungere funzioni".
Cioè puoi anche dire che siano dei requisiti e chi lo svilupperà potrà anche dirti che ne terrà conto ma difficilmente ciò che ne risulterà potrà effettivamente dirsi "semplice, manutenibile, estendibile".
XAMPP. L'idea di installare un insieme di strati per l'esecuzione di applicazioni distribuite allo scopo di eseguire una seconda applicazione distribuita mi lascia perplesso.
Occhio poi che le applicazioni distribuite che operino su dati condivisi sono questioni delicate. Quando andiamo a dire "ok, al termine dell'esecuzione scarico i dati sul server" già ci scontriamo con un problema di "granularità".
Un'applicazione distribuita che ammetta mutazioni dei dati condivisi deve cercare di farlo con il livello di granularità più piccolo possibile. Se io dico che il lavoro viene scaricato sul server al termine dell'esecuzione e ho due operatori al lavoro uno dei due rischia di aver perso l'intera giornata di lavoro perchè potrebbe aver prodotto delle mutazioni non compatibili con quelle intervenute a seguito del lavoro dell'altro.
Certo saperne di più sul programma aiuterebbe l'analisi. 30 megabyte di dati sono pochini per giustificare l'uso di un database. Se escludiamo che questa quantità possa mai accrescersi sensibilmente (cioè se non arriveremo alla soglia dei gigabyte prima che anche questa diventino un'inezia) il database più che un requisito è una cosa in più che può andare storta e lo toglierei dall'equazione.
Il problema di volerlo "semplice, manutenibile, estendibile" è che difficilmente qualcuno potrebbe dirti "no, noi lo facciamo complicato ma mai quanto difficile da aggiustare e certamente non potrai aggiungere funzioni".
Cioè puoi anche dire che siano dei requisiti e chi lo svilupperà potrà anche dirti che ne terrà conto ma difficilmente ciò che ne risulterà potrà effettivamente dirsi "semplice, manutenibile, estendibile".
XAMPP. L'idea di installare un insieme di strati per l'esecuzione di applicazioni distribuite allo scopo di eseguire una seconda applicazione distribuita mi lascia perplesso.
Occhio poi che le applicazioni distribuite che operino su dati condivisi sono questioni delicate. Quando andiamo a dire "ok, al termine dell'esecuzione scarico i dati sul server" già ci scontriamo con un problema di "granularità".
Un'applicazione distribuita che ammetta mutazioni dei dati condivisi deve cercare di farlo con il livello di granularità più piccolo possibile. Se io dico che il lavoro viene scaricato sul server al termine dell'esecuzione e ho due operatori al lavoro uno dei due rischia di aver perso l'intera giornata di lavoro perchè potrebbe aver prodotto delle mutazioni non compatibili con quelle intervenute a seguito del lavoro dell'altro.
Certo saperne di più sul programma aiuterebbe l'analisi. 30 megabyte di dati sono pochini per giustificare l'uso di un database. Se escludiamo che questa quantità possa mai accrescersi sensibilmente (cioè se non arriveremo alla soglia dei gigabyte prima che anche questa diventino un'inezia) il database più che un requisito è una cosa in più che può andare storta e lo toglierei dall'equazione.
mmmmh inizia a "parlare difficile" per me !
Comunque la presenza di un DB e' imprescindibile perche' i calcoli vengono elaborati sulla base di parametri contenuti in una quarantina di tabelle presenti attualmente nel DB di Access, parametri che non sarebbe possibile "organizzare" altrimenti. la dimensione di 30 MB si riferisce a quest'insieme di tabelle. A livello centrale lo "storico" di tutti gli utenti ammonta a qualche GB.
ESSE-EFFE
14-06-2010, 13:36
Ciao,
Prima di tutto dovresti avere le idee chiare su quello che vi serve. Avere specifiche ben documentate come hai scritto è già molto importante, però ad un certo punto parli di interfaccia Web e poi di applicazione portabile, che funzioni offline e sotto Windows XP. Quindi la parte Web a cosa servirebbe?
Anche io eviterei il "doppio" database, se non per questioni di backup, ma bisognerebbe capire meglio il discorso "server centrale".
Ovviamente la "soluzione migliore" non esiste. Ci sono sicuramente diverse strade ed una volta definite le specifiche puoi trovare varie opzioni che ti consentano di realizzare il progetto. Anche a basso costo e senza difficoltà a trovare chi vi faccia manutenzione. Come ti hanno già detto, però, dovresti discuterne con chi svilupperà il progetto.
Ciao,
Prima di tutto dovresti avere le idee chiare su quello che vi serve. Avere specifiche ben documentate come hai scritto è già molto importante, però ad un certo punto parli di interfaccia Web e poi di applicazione portabile, che funzioni offline e sotto Windows XP. Quindi la parte Web a cosa servirebbe?
Anche io eviterei il "doppio" database, se non per questioni di backup, ma bisognerebbe capire meglio il discorso "server centrale".
Ovviamente la "soluzione migliore" non esiste. Ci sono sicuramente diverse strade ed una volta definite le specifiche puoi trovare varie opzioni che ti consentano di realizzare il progetto. Anche a basso costo e senza difficoltà a trovare chi vi faccia manutenzione. Come ti hanno già detto, però, dovresti discuterne con chi svilupperà il progetto.
a breve avro' un incontro in proposito e potro' essere piu' preciso...
Intanto grazie !
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.