10/06/2015 Sistemi esperti e applicazioni pratiche: una visione alternativa.

Presentazione sul tema: "10/06/2015 Sistemi esperti e applicazioni pratiche: una visione alternativa."— Transcript della presentazione:

1 luca.padovano@alya.it 10/06/2015 Sistemi esperti e applicazioni pratiche: una visione alternativa.

2 AvantiIndietro luca.padovano@alya.it 10/06/2015Obiettivi Mostrare due esempi di semplicissimi Sistemi Esperti reali, cioè utilizzati effettivamente in applicazioni pratiche. Mostrare un esempio di ciclo di produzione per il software sviluppato in ambiente Client-Server. Introdurre alcune peculiarità della piattaforma tecnologica Microsoft.

3 AvantiIndietro luca.padovano@alya.it 10/06/2015 Assunto principale In molte applicazioni pratiche i modelli di processo sono estremamente semplificati; quindi le implicazioni teoriche sono limitate. Gli aspetti implementativi, progettuali e di project management sono i veri elementi critici del progetto.

4 AvantiIndietro luca.padovano@alya.it 10/06/2015 Sistema esperto. Di che ? Sistema automatico di ausilio alle decisioni Necessario alla riproduzione e alla sintesi di expertise

5 AvantiIndietro luca.padovano@alya.it 10/06/2015Regole….. L’automobile non parte: SE al motore arriva la benzina E il motore gira ALLORA problema di candele SE il motore non gira, E le luci non si accendono ALLORA problema di batteria SE il motore non gira, E le luci si accendono ALLORA problema di avviamento. ….

6 AvantiIndietro luca.padovano@alya.it 10/06/2015 …. e pesi R1 -> C1(0.7) e C2(0.3) –R: regola –C: conclusioni

7 AvantiIndietro luca.padovano@alya.it 10/06/2015Quindi Il problema è navigare lungo “l’albero delle scelte”, avendo la possibilità di selezionare il ramo “ottimo” secondo un certo approccio: –Statistico –Fuzzy set theory –Theory of evidence Dempster/Shafer –….

8 AvantiIndietro luca.padovano@alya.it 10/06/2015 Limiti attuali Manca una adeguata teoria della conoscenza Mancano adeguati paradigmi di rappresentazione ed elaborazione Percezione non paragonabile a quella umana

9 AvantiIndietro luca.padovano@alya.it 10/06/2015 Esempio #1 Esempio #1 A.P.S. (Application Processing System) in ambito finanziario

10 AvantiIndietro luca.padovano@alya.it 10/06/2015Descrizione A.P.S. (Application Processing System): sistema automatizzato di ausilio alle decisioni (D.S.S., Decision Support System) per l’erogazione di finanziamenti personali. Concetti principali: –Variabili di score –Scorecard –Policy Rules e Exception Rules –Cut off.

11 AvantiIndietro luca.padovano@alya.it 10/06/2015 Scorecard e variabili di score

12 AvantiIndietro luca.padovano@alya.it 10/06/2015 Policy e Exception rules

13 AvantiIndietro luca.padovano@alya.it 10/06/2015 Cut Off

14 AvantiIndietro luca.padovano@alya.it 10/06/2015 Definizione del punteggio Decisione Verifica policy rule Verifica exception rule Cut Off

15 AvantiIndietro luca.padovano@alya.it 10/06/2015Quindi…. Sistema molto semplice senza particolari problemi “teorici”: –Problemi computazionali/gestione informazione per scorecard “grandi” e applicazioni real-time (p.e. web-based). –Problemi statistici legati alla correzione dei valori sulle variabili di score.

16 AvantiIndietro luca.padovano@alya.it 10/06/2015 Raffinamento del processo ?

17 AvantiIndietro luca.padovano@alya.it 10/06/2015 Esempio #2 Esempio #2 Controllore di pianificazione biotecnica per allevamenti ittici

18 AvantiIndietro luca.padovano@alya.it 10/06/2015Descrizione Necessità di prevedere la crescita e la mortalità degli animali contenuti in un allevamento ittico sulla base di –Alimentazione –Specie –Dimensioni –Parametri ambientali

19 AvantiIndietro luca.padovano@alya.it 10/06/2015 Tabelle di pianificazione I parametri del modello, vengono conservati, per ciascuna specie ittica, in tabelle, organizzate per temperatura e dimensione. Tabelle di alimentazione Tabelle di crescita Tabelle F.C.R. (Factor Conversion Rate) Tabelle di mortalità

20 AvantiIndietro luca.padovano@alya.it 10/06/2015 Modello del processo

21 AvantiIndietro luca.padovano@alya.it 10/06/2015Ma….. Le variabili del processo sono così instabili (peculiarità della specie ittica, temperatura, cause di mortalità) che la pianificazione è solo a breve termine (10-15 giorni) e deve essere riallineata continuamente sulla base dei dati storici e dell’esperienza del pianificatore.

22 AvantiIndietro luca.padovano@alya.it 10/06/2015Quindi…. Sistema molto complicato con molti problemi “teorici” che non è vantaggioso o opportuno o possibile risolvere: –Problemi biologici legati alla definizione del modello. –Problemi statistici legati alla elaborazione dei dati storici.

23 AvantiIndietro luca.padovano@alya.it 10/06/2015 Raffinamento del processo ?

24 AvantiIndietro luca.padovano@alya.it 10/06/2015Conclusioni Molto spesso gli aspetti economici, tecnologici e di project management legati allo sviluppo di applicazioni SW prevalgono sugli aspetti teorici di implementazione del processo. La parte “esperta” del processo viene risolta “a mano” sulla base dell’esperienza. L’utilizzo di tecniche di IA raramente va oltre ad un generico raffinamento del modello statistico.

25 AvantiIndietro luca.padovano@alya.it 10/06/2015 La morale….. Gli aspetti teorici sono COMUNQUE e SEMPRE importantissimi e da questi non bisogna mai prescindere. Semplicemente, è necessario adeguare i propri sforzi alle reali esigenze del progetto.

26 luca.padovano@alya.it 10/06/2015 Il mondo Client-Server

27 AvantiIndietro luca.padovano@alya.it 10/06/2015 Il mondo Client-Server oggi….. Budget limitato, tempi ridotti. Passaggio da SW-House a SW-Factory. La componente tecnologica è primaria nello sviluppo di applicazioni. Il Web aumenta la complessità delle applicazioni riducendo la sofisticazione degli strumenti.

28 AvantiIndietro luca.padovano@alya.it 10/06/2015 Il “problema del secondo” La realizzazione di applicazioni SW solitamente si concentra non sulla applicazione in corso di sviluppo ma su una eventuale seconda applicazione, simile alla precedente e che possa giustificare gli investimenti.

29 AvantiIndietro luca.padovano@alya.it 10/06/2015 “Maturazione della competenza” Analisi: si acquisisce competenza in un particolare settore applicativo. Application Framework: si costruisce una piattaforma SW riutilizzabile. Semilavorato: si progetta una “quasi applicazione” che può essere riutilizzata con pochi aggiustamenti. Pacchetto: rivendibile as-is. Commessa Prodotto

30 luca.padovano@alya.it 10/06/2015 IN TEORIA….

31 AvantiIndietro luca.padovano@alya.it 10/06/2015

32 AvantiIndietro luca.padovano@alya.it 10/06/2015

33 luca.padovano@alya.it 10/06/2015 … E IN PRATICA

34 AvantiIndietro luca.padovano@alya.it 10/06/2015 Fasi del progetto “reale” Analisi narrow Param.narrow Riusabilità Param.wide Progetto Sviluppo Analisi wide Sviluppo Fase del “contingente” Fase del “pacchetto”

35 AvantiIndietro luca.padovano@alya.it 10/06/2015 Il principio necessità/opportunità E’ evidente che molte volte una metodica così articolata risulti non solo eccessiva ma addirittura dannosa per la corretta realizzazione del progetto. In ogni caso, i criteri di opportunità e di buon senso che vanno sempre applicati e che permettono di adeguare gli sforzi alle esigenze, non devono far dimenticare la necessità di organizzare il flusso delle attività secondo un processo chiaro, definito e facilmente ripetibile. Confondere la necessità con l’opportunità e il primo errore del progettista.

36 luca.padovano@alya.it 10/06/2015 La piattaforma Microsoft

37 AvantiIndietro luca.padovano@alya.it 10/06/2015 La piattaforma Microsoft Microsoft Visual Studio Tecnologia COM e DCOM TECNOLOGIA RAD Mono-piattaforma-multipurpose

38 luca.padovano@alya.it 10/06/2015 AFTER HOURS

39 AvantiIndietro luca.padovano@alya.it 10/06/2015 Le sei regole d’oro (LSD) GIGO: Garbage In Garbage Out CCCC: Commenti Convinti Chiari Cristallini SSSS: Scrivo Sempre Software Standardizzabile UUUU: Utilizzo Unicamente Utility Universali SAL: Stato Avanzamento Lavoro - Senza, Alimento Liti DEBUG: Dovendo Evidenziare Bachi, Utilizzo Grano salis

40 AvantiIndietro luca.padovano@alya.it 10/06/2015 I dieci comandamenti Si fa o non si fa (Principio di Karate Kid). La velocità di un plotone è data da quella del soldato più lento. Il codice rigido si spezza. Se non so chiedo, se so spiego. Interfaccia gonfia, l’utente ingrassa. L’analisi è il piccione del software monumento. Giusta visualizzazione di dati giusti. Se non riesco a focalizzarlo in 30 minuti ho sbagliato l’analisi. Se riesco a focalizzarlo in 30 minuti ma lo realizzo in 30 giorni, ho sbagliato strumento. Se riesco a focalizzarlo in 30 minuti e lo realizzo in 3 ore, ci sarà qualcos’altro che ti rovinerà la giornata.

41 AvantiIndietro luca.padovano@alya.it 10/06/2015 I due principi basilari Principio del velocipede Principio del Titanic