Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti WP1.2 Chiara Francalanci – Politecnico di Milano.

Presentazione sul tema: "Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti WP1.2 Chiara Francalanci – Politecnico di Milano."— Transcript della presentazione:

1 Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti WP1.2 Chiara Francalanci – Politecnico di Milano

2 2 Obiettivi del secondo anno di attività Obiettivi:  Studio di problemi relativi all’analisi costi- benefici ex ante, cioè precedente alla progettazione  R.1.2.3  Studio di problemi relativi all’analisi costi- benefici ex post, cioè relativa alla gestione dei sistemi  R.1.2.3

3 3 Criticità  L’analisi costi-benefici deve tenere conto delle caratteristiche di adattatività e multi-canalità dei servizi MAIS  Le caratteristiche di adattatività e multi-canalità causano notevoli cambiamenti rispetto alle tradizionali tecniche di analisi costi-benefici, quali: L’adattatività intesa come gestione delle eccezioni comporta costi di progettazione aggiuntivi? L’adattatività intesa come allocazione dinamica delle risorse comporta risparmi? L’adattatività intesa come sostituibilità dei servizi comporta una ridistribuzione dei ritorni?

4 4 Temi di approfondimento dell’analisi costi-benefici  Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)  Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)  Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)  Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)

5 5 Temi di approfondimento dell’analisi costi-benefici  Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)  Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)  Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)  Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)

6 Valutazione benefici dell’allocazione dinamica delle risorse hardware  Obiettivo: condividere le risorse da parte di più clienti  Condivisione: garantire il rispetto dei requisiti di QoS massimizzare i profitti derivanti dai contratti di Service Level Agreement (SLA)  Motivazioni: alta variabilità del carico dei sistemi Internet  Componenti: Classificatore: identifica le richieste e le caratterizza in tempo reale in termini di effettivi requisiti di carico Predittore: previsione del carico applicativo che dovrà essere sostenuto nel breve termine (modelli ARMA e polinomial fitting) Controllore: alloca le risorse del sistema alle varie richieste con l’obiettivo di rispettare alcuni vincoli e criteri di ottimalità (configurazione dei server, allocazione delle applicazioni, routing e scheduling delle richieste)

7 Modello di costo e profitti derivanti dai contratti SLA  Costi associati all’uso dei server: energia elettrica, condizionamento, licenze software…  Solitamente si assume che il costo di un server sia proporzionale alla sua potenza di calcolo  Profitti derivanti dai contratti di SLA: Utility function (percentile, tempo di risposta medio,…) Contratti flat (vincoli di QoS stretti)

8  I profitti del Service Provider vengono valutati attraverso simulazione  L’uso di un controllore consente di migliorare i profitti anche di un ordine di grandezza rispetto al load balancing ed a politiche di scheduling tradizionali Valutazione benefici dell’allocazione dinamica delle risorse hardware

9 9 Temi di approfondimento dell’analisi costi-benefici  Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)  Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)  Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)  Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

10 Obiettivo  Descrizione di un modello di negoziazione automatica bilaterale  Il campo di applicazione del modello è una rete di tipo di DiffServ (vengono gestiti aggregati di traffico con QoS e non singoli flussi di traffico), gli attori della negoziazione sono ISP della rete Fornitore: gestore delle diverse classi di servizio Cliente: negozia le caratteristiche degli attributi dell’accesso alla rete  Il modello è adattabile al caso dell’erogazione di servizi multicanale

11 Modello di pricing Modello di negoziazione per servizi di rete  Attributi di negoziazione Caratteristiche tecniche del servizio (frequenza media dei token bucket, profondità media dei token bucket, ritardo medio nella trasmissione dei pacchetti, probabilità di superare la soglia di ritardo) Prezzo  Ciascun partecipante possiede delle proprie quality function per ciascun attributo (Q(x): R  [0,1])  La quality function totale è ottenuta come funzione (produttoria) delle quality function per le singole caratteristiche tecniche

12 Modello di pricing Modello di negoziazione per servizi di rete  I partecipanti definiscono una propria funzione di utilità V che tiene conto degli attributi e del prezzo, nel caso più semplice: Cliente: rapporto qualità prezzo V(X,p)=Q(X)/p Fornitore: prodotto qualità prezzo V(X,p)=Q(X)*p

13 Modello di pricing Modello di negoziazione per servizi di rete  Prezzo Il prezzo è un attributo particolare, ciascun partecipante ha un proprio modello per generare il prezzo da allegare a ciascun offerta Fornitore: ha un modello di prezzo esatto, che fornisce un valore per ogni combinazione delle caratteristiche tecniche negoziabili Cliente: non possiede un modello di prezzo esatto, ma riesce ad associare una fascia di prezzo ritenuta valida a ogni possibile combinazione delle caratteristiche tecniche negoziabili

14 Modello di pricing Strategie di negoziazione  Esistono due principali strategie di negoziazione Compromesso: un partecipante tenta, in vari modi, di avvicinarsi all’offerta appena formulata dalla controparte Stima del prezzo: la contro-offerta è generata attraverso una stima del modello di prezzo dell’avversario (questa strategia è attuabile dal cliente, in quanto il fornitore ha un modello esatto per calcolare il prezzo), cercando di minimizzarlo a parità di qualità

15 Modello di pricing Strategie di negoziazione: compromesso x P p x P p  Mi avvicino alla controparte scegliendo l’offerta con utilità più alta in un intorno di raggio  =  (t) crescente nel tempo secondo un andamento esponenziale o polinomiale

16 Modello di pricing Strategie di negoziazione: stima del prezzo  In un intorno si raggio crescente nel tempo, un partecipante tenta di scegliere l’offerta che minimizza la distanza tra la sua ultima offerta e la curva della stima del prezzo (lineare in figura)  Le funzioni  utilizzate sono lo stesse della strategia precedente x A p x A p

17 Modello di pricing Protocollo di negoziazione 1.Il fornitore fa la prima offerta (scegliendola tra una serie di offerte predefinite e massimizzando la propria V) 2.Il cliente risponde con una contro-offerta, inizia lo scambio reciproco di offerte 3.Condizione di uscita: un partecipante (es. il cliente) manda la propria offerta al tempo t+1 solo se vale la condizione Altrimenti accetta l’offerta della controparte al tempo t

18 Modelli di pricing Simulazioni e risultati  E’ stata testata la strategia di tipo “compromesso”: L’algoritmo è progettato per convergere, il tempo di convergenza tende a saturare aumentando il timeout La natura dell’agreement dipende fortemente dai “pattern di concessione” dei partecipanti, chi concede di più tende ad allontanarsi di più dai valori auspicati dei parametri che meno impattano sulla funzione di utilità, diventano impredicibili Gli agenti tendono a non far decrescere la loro utilità, modificando le caratteristiche del canale e il prezzo

19 Modelli di pricing Tempi di convergenza  Dipendono dal timeout associato al processo  Aumentano se i comportamenti dei partecipanti sono differenti (più o meno cooperativi)

20 20 Temi di approfondimento dell’analisi costi-benefici  Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)  Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)  Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)  Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

21 Valutazione dell’aumento della complessità di progettazione SW Requisiti non funzionali:  Flessibilità: “Capacità di un servizio (o di un insieme di servizi) di compensare a run-time violazioni dei vincoli di qualità”  Controllabilità: “Localizzazione delle attività di controllo sui vincoli di qualità”  Adattatività: “Capacità di un insieme di servizi di riorganizzare il flusso di interazione standard a fronte della continua violazione nel tempo dei vincoli di qualità”.

22 Costi di progettazione:  La progettazione concettuale si complica in funzione dei requisiti non- funzionali esaminati analisi dei requisiti: estrazione dei requisiti, valutazione degli scenari possibili, valutazione dei contenuti informativi fruibili in funzione del canale (o del dispositivo)… sviluppo: il costo di sviluppo cresce al crescere delle linee di codice da sviluppare (LOC)  Risparmi in termini di costi di integrazione sistemi informativi restano eterogenei, riduzione dei costi rispetto a EAI, resta l’integrazione di processo (razionalizzazione del procurement) Valutazione dell’aumento della complessità di progettazione SW

23 Costi di erogazione del servizio:  Risparmi in termini di costi da affrontare a fronte della mancata erogazione di un servizio è possibile rinegoziare il prezzo di erogazione invece di abortire la conversazione è possibile erogare su un canale diverso il servizio invece di interrompere la conversazione  Tanto più un ambiente è intrinsecamente incerto, tanto più il numero di violazioni è potenzialmente alto, tanto più l’adattatività fornisce benefici in termini di costi di erogazione Valutazione dell’aumento della complessità di progettazione SW

24 Costi di manutenzione:  Manutenzione potenzialmente più onerosa (conversazioni più complesse, più attori coinvolti)  Per mitigare l’onere della manutenzione: utilizzo modelli concettuali per supportare l’implementazione di nuove versioni che conservino tutte o una parte delle proprietà delle versione precedente (model checking, proprietà espresse attraverso formule LTL) utilizzo di pattern che formalizzano interazioni notevoli e che possano essere composti per ottenere interazioni più complesse (es. secondo modelli organizzativi) + pattern repository Valutazione dell’aumento della complessità di progettazione SW

25 Progettazione concettuale e requisiti funzionali e non funzionali s c commit  provider  End(QoS_Control)[]|  Beg(Production) [Received(null, provider, order)  (beav = 0)]|  End(Production)|   provider  s c  user  commit abort End(My_Control) [  Achieved(QoS_goal)  Done(Re-execute )]|   provider  Beg(Production) [Received(null, provider, order)  (beav = 1)]|  End(Production)|  End(My_control) [  Achieved(QoS_goal)   (Done(Re-execute< null, provider, production>)]| Re-execute End(My_Control) [Achieved(QoS_goal)|  begin Counter(n) End(My_Control) [  Achieved(provider, QoS_goal)]|  End(My_Control) [  Achieved(QoS_goal)]|Set(beav, 1) End(abort)[ ]|   End(commit)[ ]|  Conteggio eventi anomali Adatta il comportamento per esercitare una funzione di controllo Valutazione dell’aumento della complessità di progettazione SW

26  Stimati dei costi di progettazione di una conversazione adattativa sulla base della complessità ciclomatica di McCabe.  In generale, la complessità ciclomatica viene calcolata sul flusso di controllo di un programma descritto attraverso un grafo orientato. Questo tipo di metrica è derivata dalla teoria dei grafi dove, per un grafo orientato e fortemente connesso, viene definito il numero ciclomatico: v(g) = e-n+1, e: archi, n: nodi

27 27 Temi di approfondimento dell’analisi costi-benefici  Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)  Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)  Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)  Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

28 Valutazione della relazione fra costi e parametri di QoS  Per lo studio della qualità del servizio nell’ambito del progetto MAIS è stata effettuata una analisi delle fonti, costituite dai deliverables MAIS dell’anno 2003/2004 + alcuni rapporti.  E’ stato costituito quello che si definisce Registry delle qualità in cui sono stati riportate le dimensioni MAIS. Dall’analisi bottom up dei deliverables del progetto MAIS emergono circa 225 dimensioni di qualità.  Le qualità sono state classificate in base ai diversi livelli definiti in MAIS: Architectural Model Functional Model Context Model Channel Model Piattaforma MAIS

29 Valutazione della relazione fra costi e parametri di QoS

30 Livello dei requisiti di qualità Livello di qualità Costo della qualità Costo della non qualità Costo totale della qualità = Costo della qualità + Costo della non qualità

31 Valutazione della relazione fra costi e parametri di QoS  Si vogliono definire le relazioni tra il costo e le dimensioni di qualità nelle varie fasi di sviluppo e redesign dei servizi  Si vogliono definire i livelli accettabili della qualità considerando i costi implicati  Es. Availability

32 Valutazione della relazione fra costi e parametri di QoS  I costi della non qualità sono costi derivati dallo scostamento del servizio dai requisiti di qualità espressi dagli utenti. Sono suddivisi in: Costi diretti, legati all’insoddisfazione della clientela e corrispondente abbassamento dei ritorni Costi indiretti  I costi della non qualità indiretti sono classificati come: Tempo umano: ad esempio, scarsa qualità implica interventi extra sul sistema da parte del personale IT Risorse informatiche: ad esempio, il tempo di risorse impiegate nell’esecuzione di servizi inutili

33 33 Conclusioni  Nel terzo anno di attività si vuole: raffinare il modello di valutazione dei benefici dell’allocazione dinamica delle risorse hardware estendere il modello di negoziazione al caso molti-molti e multi- canale approfondire la relazione fra costi e parametri di qualità, arrivando, se possibile, alla definizione di un modello della non qualità verificare il modello della non qualità nel caso specifico della qualità dei dati