You are currently browsing the category archive for the 'Software Selections' category.
Completo il cliclo di articoli riguardanti la software selections, proponendo un estratto della ricerca di cui sono autore con un benchmark tra i software di statistica (Web e log analyser, i prodotti che consentono analisi e statistiche sulla navigazione in internet).
Non è stato facile orientarsi. Per un’azienda che intende dotarsi di questi strumenti può arrivare a spendere fino a 3/4 mila €uro all’anno (specie nel caso di gestione di più siti con applicativo server). Esistono soluzioni open source.
La mia personale gradatoria, su una base di 73 applicativi di Web e log analyser, come motiverò più avanti, è la seguente:
| Rank__ | Applicativo di web log analyser__________ | Link_____________________________ | Criteri % |
| 1 | ConversionLab - TrackSet | http://www.trackset.it/conversionlab/ | 87% |
| 2 | ShinyStat | http://www.shinystat.com/it/ | 83% |
| 3 | Site Meter | http://www.sitemeter.com/?a=howworks | 80% |
| 4 | Omniture SiteCatalyst | http://www.omniture.com/products/ | 77% |
| web_analytics/sitecatalyst | |||
| 5 | Click Tracks | http://www.clicktracks.com/ | 67% |
| 6 | Php-Stats | http://www.phpstats.net/ | 67% |
| 7 | Clicky – Web Analytics 2.0 | http://getclicky.com/ | 66% |
| 8 | ImetriX Web Analytics | http://www.imetrix.biz/ | 66% |
| 9 | WebTrends Analytics | http://www.webtrends.com/Products/ | 63% |
| WebTrendsAnalytics8.aspx | |||
| 10 | COGITO Monitor (di Expert System SpA – Modena) | http://www.expertsystem.net/ page.aspid=1521&idd=191 |
61% |
Criteri di ranking utilizzati nell’analisi/benchmark
I criteri tenuti in considerazione, hanno riguardato il rispetto e/o la presenza dei seguenti requisiti ricercati nell’analisi/benchmark effettuata:
1) Open Source
2) Possibilità ottenimento/disponibilità del codice sorgente
3) Mantenimento dati storici
4) Funzioni MKT avanzate:
a. Monitoraggio conversioni
b. Gestione obiettivi/ROI
5) Gestione multi utente:
a. Monitoraggio di più siti
b. Monitoraggio di più clienti
c. Gestione admin centralizzata
6) Piattaforma
7) DataBase
8) Business Intelligence
9) Benchmarking altri siti/categorie
10) Grafica-View
Il primo è risultato ConversionLab della TrackSet.
Nonostante non sia un applicativo di web analyser Open Source, il primo è risultato essere ConversionLab, per la completezza dei requisiti rispettati e per le funzionalità di analisi e di business intelligence presenti nell’applicativo.
ConversionLab ottimizza il ROI massimizzando le conversioni delle campagne pubblicitarie. Analizza il rendimento di ogni campagna promozionale. Studia l’efficacia della comunicazione in rapporto alle performance di conversione Individua i punti di forza e di debolezza delle pagine web. Studia i percorsi di visita in rapporto alle provenienze ConversionLab risulta essere un solo strumento di Web Analytics per rispondere in modo chiaro e preciso a tutte le esigenze di comunicazione e Marketing: valutare la redditività di ogni attività online per ottimizzare il web media-mix in funzione del ROI, capire i comportamenti dell’utenza per migliorare la propria comunicazione online, monitorare il raggiungimento dei propri obiettivi di marketing.
Per la società alal quale avevo fatto questa analisi, avevo consigliato una partnership commerciale e/o di sviluppo funzionalità. Trackset, tra l’altro, propone un programma specifico per i professionisti della comunicazione e dell’advertising online, le new media agency, le agenzie SEO/SEM. Il team di Trackset lavorerà a fianco dei partner, definendo la configurazione e i tool più adatti al perseguimento degli obiettivi strategici.
Google Analytics, per esempio, è risultato solo diciottesimo. Google Analytics fornisce tutte le informazioni necessarie sulle modalità con cui i visitatori hanno raggiunto il tuo sito e su come interagiscono con esso. Grazie a Google Analytics, si possono inserire gli obiettivi di conversione delle campagne e sulle iniziative che consentono un buon rendimento dell’investimento e migliorare il tuo sito allo scopo di ottenere un numero maggiore di conversioni.
La web analytics disponibile in Open Source
Riporto anche i risultati riguardante gli applicativi che svolgono funzioni di web analytics open source (freeware e/o GPL)
Per approfondimento e per avere l’analisi completa "Web_Analysis_Strumenti a confronto" (in pdf), potete richiederla con un e-mail al mio indirizzo: Richiesta documento.
Condividi questo articolo:
Technorati 
OKnotizie 
Delicious 
Segnalo 
Digg
Come già trattato nell’articolo precedente "Dallo studio di fattibilità; alla software selection: analisi e scelta degli strumenti e delle tecnologie", un team di sviluppo ha a disposizione un insieme ragionevolmente ampio di scelte e alternative. Inoltre, i diversi stili architetturali possono essere combinati per ottenere strutture e architetture complesse. I criteri principali (e iniziali) si riferivano alla scelta tra prodotti/applicazioni industriali e prodotti/applicazioni Open Source.
Introduzione metodologica alla scelta architetturale
Come si sceglie un’architettura?
Come si giunge a scegliere uno stile architetturale (o una combinazione di stili) tra i tanti possibili?
Se è vero che l’architettura di un sistema non è derivabile in modo diretto dalla natura e struttura del problema, quali criteri e linee guida occorre seguire nel progettare la soluzione? In realtà questo passaggio costituisce uno degli elementi più critici e complessi del lavoro iniziale della analisi architetturale.
In questa fase entrano in gioco aspetti quali l’esperienza del team di sviluppo, della sua capacità di analisi e sintesi, ma anche di intuito e di creatività. Il problema da risolvere in ordine allo sviluppo e/o reengineering di un sistema informativo è stato "osservato e studiato".
In generale, è difficile ricondurre la scelta di una soluzione architetturale a un mero processo o metodo sistematico che determina in modo meccanico quale alternativa preferire. Ci sono peraltro una serie di criteri e di linee guida che possono essere seguiti come qui di seguito andiamo ad enunciare.
Linee guida e aspetti considerati
a) Scelte architetturali già perseguite in casi simili: il DSSA – Domain Specific Software Architecture, l’ambiente e le caratteristiche del dominio applicativo dell’azienda.
Esempio: DSSA Domain Specific Software Architecture Activity Flow
(Fonte: The Domain-Specific Software Architecture Program)
In primo luogo, esistono soluzioni architetturali per specifici settori applicativi. Per esempio, nel caso dei sistemi di controllo, vi sono architetture di riferimento che possono essere raffinate e adattate al caso specifico. Nel mondo delle applicazioni per Internet, la stessa architettura J2EE (Java Platform, Enterprise Edition) identifica una serie di elementi e componenti per la costruzione di applicazioni distribuite client-server multilivello.
Il team di progetto, a fronte di un problema, può quindi innanzitutto valutare le scelte architetturali già perseguite in casi simili e che si sono rivelate efficaci per quel tipo di problemi. Negli anni scorsi, è stata creata l’espressione Domain Specific Software Architetture proprio per indicare soluzioni architetturali ottimali per "specifici domini applicativi".
b) L’analisi dei requisiti e dalle caratteristiche
Occorre chiedersi: quale architettura è più coerente con le richieste del committente?
Più in generale, la definizione dell’architettura di un sistema complesso viene effettuata studiando i requisiti (vedi anche "Implementazione di un CRM: un confronto tra approccio applicativo e organizzativo") e le caratteristiche del problema sia da un punto di vista funzionale che non funzionale.
I risultati di queste analisi sono confrontati con le caratteristiche e proprietà tipiche dei diversi stili e da questo nascono le ipotesi architetturali. Se il problema, per esempio, è l’integrazione di archivi dati gestiti da organizzazioni autonome, è evidente che nascono (almeno) due possibilità:
- o si consolidano tutti i dati in un archivio centrale, con un sistema client-server (magari a più livelli per ottimizzare le prestazioni complessive)
- oppure si adotta un’architettura P2P – Peer-to-Peer, nella quale ciascuno continua a essere "padrone e gestore unico" dei propri dati. In questo secondo caso, si pone il problema di come propagare query e operazioni di aggiornamento delle informazioni. Quindi si potrebbe pensare a un sistema P2P ibrido oppure a un’architettura composita P2P + publish-subscribe.
La scelta tra queste diverse alternative deve considerare il trade-off (vantaggi e svantaggi della scelta, considerando anche gli aspetti di costo-opportunità) che ciascuna soluzione comporta.
Se per esempio le funzioni e operazioni svolte da ciascun nodo autonomo sono le stesse e avvengono su dati assolutamente identici, non ha senso avere una replicazione dei sistemi: un sistema centralizzato (magari ridondato per garantire fault-tolerance e affidabilità) è la soluzione più conveniente dal punto di vista economico e gestionale. Se invece i diversi nodi hanno, almeno in parte, dati diversi con funzioni che possono mutare o evolvere in modo indipendente, è preferibile (se non obbligatorio) attuare una strategia distribuita P2P.
In ogni caso, è evidente che il team di progetto si trova di fronte a un insieme non limitato di alternative.
Spesso, esse non sono presenti solo o principalmente a livello di stile architetturale, ma anche e soprattutto a livello di variante o specifica implementazione dello stile o di combinazione di stili.
Sono l’esperienza, le competenze, l’intuito e la professionalità di un team di progetto a costituire la chiave di volta per affrontare questo passaggio in modo efficace e convincente.
c) Il deployment le infrastrutture IT: le prestazioni e l’efficienza del sistema
La scelta di un’architettura deve essere guidata anche da considerazioni di carattere prestazionale. Potrebbe essere necessario, per garantire un certo tipo di prestazioni, dover valutare quale architettura risulti più conveniente, oppure come una certa architettura debba essere rivista o adattata per conformarsi al problema specifico.
- Per esempio, dovendo gestire un alto carico di richieste in un sistema client-server multi-tier, potrebbe essere utile avviare studi che valutano, dal punto di vista della capacità complessiva di risposta, architetture a tre o quattro livelli, con diversi meccanismi di distribuzione delle funzioni applicative o dei criteri di replica e gestione dei tier intermedi.
- Da tempo, questo tipo di analisi è condotto simulando e studiando il comportamento delle diverse architetture tramite modelli matematici basati sulla teoria delle code (o tecniche simili). Tali approcci sono piuttosto diffusi in molti settori dell’ingegneria e sono certamente di ausilio anche al team di progetto.
d) II ruolo del middleware (Orchestration, ESB – Enterprise Service Bus e WorkFlow)
Da Wikipedia: con il termine middleware
oggi si intendono una serie di strumenti come DBMS, Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, servizi Web e architetture orientate ai servizi.
Un aspetto importante che influisce in modo significativo sull’attività di progettazione è la scelta del middleware. Infatti, è indubbio, e alcuni studi lo hanno dimostrato, che l’utilizzo di una particolare tecnologia di middleware influisce sulle scelte architetturali. Può persino accadere che l’adozione di un tipo di middleware renda più o meno facile (e persino possibile) la realizzazione di una soluzione basata su una specifica architettura.
- Tecnologie a eventi
Un caso esemplare è costituito dalle tecnologie di middleware a eventi (tipo JMS – Java Message Service).
Queste tecnologie forniscono operazioni e servizi per gestire la pubblicazione e ricezione di eventi: offrono il dispatcher e i servizi di publish, subscribe, push e pull.
- Architettura publish-subscribe
Dovendo realizzare un’architettura publish-subscribe, è indubbio che la disponibilità di questo tipo di tecnologia faciliti grandemente tutto il processo di sviluppo.
Il team di progetto può concentrarsi nell’identificazione dei diversi componenti dell’architettura, dei tipi di eventi da scambiare e della gestione della chiamata dei servizi offerti dal middleware, ignorando gli aspetti implementativi della gestione degli eventi.Questa architettura consente un’elevata scalabilità.
- Sistema client-server
Al contrario, se si dovesse realizzare un sistema client-server utilizzando un middleware a eventi, il team di progetto si troverebbe di fronte a problemi non marginali. Certamente è possibile realizzare una chiamata sincrona attraverso pubblicazioni di eventi e sottoscrizioni, ma il compito del team di progetto sarebbe alquanto ostico.
Chi richiede un servizio deve pubblicare un evento con le informazioni sul servizio richiesto.
Il ricevente deve essersi già sottoscritto a quel tipo di evento. In caso contrario, la richiesta va persa e il richiedente rimane inascoltato (senza avere meccanismi efficienti per venirlo a sapere in tempi rapidi).
Quando chi offre il servizio riceve l’evento di richiesta, deve generare un nuovo evento con la risposta.
Il richiedente del servizio deve essersi registrato per tempo, per poter essere sicuro di ricevere l’evento di risposta.
Come si può facilmente desumere, pensare di gestire interazioni client-server con questo meccanismo è semplicemente improponibile: appare quindi evidente che la scelta del middleware possa avere un’influenza più o meno significativa sull’architettura (e viceversa).
In generale, ogni tecnologia di middleware, in modo più o meno invasivo, induce uno o più stili architetturali. Esistono tecnologie di middleware molto semplici e flessibili che possono essere utilizzate per tutti gli stili architetturali.
Altre sono particolarmente adatte a realizzare solo uno o pochi stili.
- Adozione della RMI – Remote Method Invocation
Per esempio, con l”adozione della RMI – Remote Method Invocation, invocazione remota di metodi) si utilizza una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete.
Questa tecnologia include una API (application programming interface) il cui scopo esplicito è quello di rendere trasparenti al programmatore quasi tutti i dettagli della comunicazione su rete.
Essa consente, infatti, di invocare un metodo di un oggetto remoto (cioè appartenente a un diverso processo, potenzialmente su una diversa macchina) quasi come se tale oggetto fosse "locale" (ovvero appartenente allo stesso processo in cui è eseguita l’invocazione). In questo senso, la tecnologia RMI può essere ricondotta, da un punto di vista concettuale, all’idea di chiamata di procedura remota riformulata per il paradigma object-oriented (in cui, appunto, le procedure sono sostituite da metodi).
Con RMI è possibile realizzare sistemi client-server a più livelli e, con un po’ di programmazione aggiuntiva, anche sistemi P2P. Le architetture J2EE (Java Platform, Enterprise Edition) sono particolarmente adatti a sistemi client-server multi-tier con codice mobile di tipo COD (tramite gli applet), mentre può risultare (nella sua configurazione completa) particolarmente pesante e onerosa per gestire sistemi P2P con funzioni RE (Remote Evaluation).
Avendo scelto uno stile architetturale, è quindi necessario assicurarsi che il middleware prescelto sia compatibile con la scelta fatta. Il middleware gioca inoltre un ruolo importante anche nella scelta di componenti da integrare in un sistema informatico esistente o già parzialmente implementato.
Infatti, se il componente utilizza meccanismi di middleware e logiche di funzionamento (interfacce) non compatibili con il "sistema ricevente", si ha una situazione di integrazione impossibile ("rigetto") o estremamente costosa (è necessario costruire adattatori che facciano da interprete tra le diverse parti).
Ancora una volta, emerge un problema di scelta progettuale che vede il team di progetto giocare un ruolo essenziale. Nel determinare l’architettura del sistema e il middleware di supporto, il team di progetto deve assicurarsi che non vi sia architectural mismatch, cioè incompatibilità architetturali tra i diversi elementi dell’architettura e in particolare tra essi e il middleware scelto per implementarli.
Da dove partire: l’approccio Top-down e Bottom-up
In diverse circostanze, è emerso un tema particolarmente rilevante: nella progettazione e realizzazione di un sistema informatico si procede in modo top-down o bottom-up?
- L’approccio Top-down
Deriva direttamente dalla logica dello stepwise refinement:
si parte dall’astrazione massima e progressivamente la si raffina in funzioni elementari e quindi in codice. Più in generale, si definisce l’architettura del sistema e si raffinano i ai diversi componenti ed elementi che ne emergono.
"Scendendo" a livello di componente si giunge a progettare il modulo e quindi il codice dei singoli metodi o procedure.
- L’approccio Bottom-up
Si parte da componenti già pronti o facilmente realizzabili e li si assembla progressivamente fino a costituire il sistema completo.
È l’approccio che sfrutta al meglio i cicli di vita basati sul riuso di componenti (component-based development).
Technorati Tag: Studio di fattibilità,Software Selections,percorso decisionale e implementativo
La software selection segue dei percorsi di valutazione che prevedono un arco di attività e di approfondimenti che vanno dallo studio di fattibilità alla software selection.
Fonte: http://www.websitepromotion.it/content/view/50/83/
Gli aspetti che vengono tradizionalmente considerati nella software selection sono i seguenti:
- copertura funzionale (ampiezza e profondità);
- tecnologia del software;
- costi di avvio;
- canone di manutenzione annuale;
- costi di manutenzione ed aggiornamento;
- costi organizzativi;
- competenza del partner tecnologico;
- robustezza e possibili evoluzioni della soluzione.
I criteri sopra elencati non mi soddisfano. la software selection deve considerare che il software una volta che entra in funzione (se tutto va bene …), ha un impatto con l’organizzazione e con il Sistema Informativo esistente molto più ampio di quello che inizialmente si tende a (non) valutare. Molto spesso si assiste a riunioni di pianificazione di un progetto nelle quali si dibatte sui vari tipi di tecnologie:
- ambienti di sviluppo,
- middleware
- database
- strumenti di gestione delle configurazioni ecc.
La software selection, la scelta di una tecnologia, o di uno strumento di sviluppo, è particolarmente difficile e, poiché incide in modo significativo sullo svolgimento del progetto, è essenziale che sia compiuta sulla base di considerazioni tecnico-economiche adeguate, molto dettagliate quali, ad esempio, le seguenti.
- Copertura funzionale:
Gli applicativi, il middleware, l’infrastruttura IT, ecc. sono in grado di coprire i requisiti (architetturali, funzionali ed organizzativi) richiesti? - Qualità intrinseca della tecnologia:
Quali sono le prestazioni e funzioni garantite? - Allineamento con le caratteristiche del progetto:
È inutile scegliere una tecnologia eccellente, ma inadatta al progetto che si deve svolgere. - Compatibilità e vincoli tecnologici:
Questa tecnologia deve integrarsi con altri componenti preesistenti? Se sì, è in grado di farlo? Occorre tener presente le necessità e/o le compatibilità di integrazione/interoperabilità con il sistema informativo dell’azienda unitamente alla la scalabilità dell’applicazione con altri moduli o software del fornitore/partner tecnologico. - Transizione e facilità di apprendimento:
È semplice adottare questa tecnologia e quanto è già conosciuta dal team di progetto? - TCO – Total Cost of Ownership:
Quanto costa acquisire e soprattutto mantenere nel tempo una tecnologia? Spesso ci si concentra sul suo costo iniziale e non si presta attenzione ai costi di manutenzione e/o aggiornamento. Il TCO deve avere un’enfasi sui costi e/o canoni di assistenza e di manutenzione evolutiva negli anni. - Lock-in:
Quanto questa tecnologia vincolerà scelte future? Il personale IT sarà in grado di sostituirla in modo ragionevolmente facile, nel momento in cui ci fossero alternative più convenienti? - Affidabilità e del fornitore e indipendenza dal fornitore:
Quanto affidabile è il fornitore della tecnologia? L’implementatore può contare sul suo supporto stabile e competente? È assicurata indipendenza da fornitore?
Queste osservazioni sono solo alcune tra quelle che il responsabile di un progetto deve considerare al momento di una scelta tecnologica importante. Purtroppo, molto spesso queste decisioni sono governate da criteri di carattere commerciale o addirittura ideologico. È invece essenziale che tutti gli aspetti chiave di una scelta siano opportunamente considerati e pesati.
Per ulteriori approfondimenti e per proseguire questo percorso di software selection, consiglio di leggere anche l’articolo: “Scegliere un’architettura: linee guida e ruolo del middleware”.
Leonardo Milan
