Appunti Sistemi informativi aziendali avanzato

Sistemi informativi aziendali avanzato

Materiale didattico e valutazione

Docente: Roberto Bernazzani

Materiale didattico: No libri (solo per approfondimento), slides ed appunti lezioni.

Esame: Mix di domande a risposta multipla e domande aperte (no prove intermedie, integrazioni orali, fuori appello), il voto può essere rifiutato un massimo di due volte (quindi 3 tentativi).

Cosa verrà valutato?

• Rilevanza di contenuto
• Chiarezza espositiva
• Eleganza di linguaggio (linguaggio tecnico)

Programma

Prima lezione: Lo sviluppo dei sistemi informativi

Ipotesi di diventare una figura chiamata C.I.O. (Chief Information Officer), ovvero il responsabile dei sistemi informativi, ossia il manager che si occupa delle informazioni e prende informazioni. È una figura che non è un tecnologo (sarebbe un CTO). D’ora in poi tutti i concetti saranno dal punto di vista di un CIO che deve prendere una decisione, facendo un'analisi di costi benefici, vantaggi e svantaggi.

Perché?

• Dato: fatti che rappresentano eventi (es. prezzo di un prodotto), qualcosa che acquisisco o dall'interno (numero dei dipendenti) o dall'esterno (tasso di disoccupazione, prezzi dei competitor) (dati endogeni od esogeni).
• Informazione: dati che sono stati elaborati e ricondotti ad una forma significativa ed utilizzabile per scopi conoscitivi (es. fatturato derivante dalla vendita di un prodotto in un periodo). Quindi un dato elaborato diventa informazione. Informazione = Dato elaborato.
• Conoscenza: capacità di usare dati e informazioni per prendere decisioni e intraprendere azioni (che generano dati). Calcolare un dato per avere un'informazione è perché ho un bisogno informativo, perché? Perché devo prendere decisioni.

(La biologia ha detto che qualsiasi organismo al mondo, aziende nel nostro caso, per vivere deve prendere decisioni, altrimenti morirà) N.B. Schema seguente (molto importante)

Per non morire, l’azienda deve prendere ottenere dati, da elaborare ed estrapolare informazioni. Le informazioni mi garantiscono la conoscenza e ciò mi permette di decidere. Lo schema funziona anche a ritroso, prendere una decisione, genera dei dati, che elaborati mi danno informazioni, mi garantiscono la conoscenza per la prossima decisione. Quest’area aziendale è FONDAMENTALE, perché raccogliere un dato sbagliato genera informazioni sbagliate, che con una conoscenza sbagliata mi faranno prendere decisioni sbagliate!!! Ecco perché informazione come fattore competitivo.

Definizione di sistema informativo

Essendo un sistema è un insieme di cose: (definizione prof. De Marco)

• Persone
• Apparecchiature
• Procedure aziendali

Il compito di questi tre elementi è quello di produrre le informazioni che servono per operare nell'impresa e gestirla (prendere decisioni).

Cosa c’è dentro il sistema informativo? Elementi costitutivi S.I.

1. Patrimonio di dati: input del processo di trasformazioni. Prima di tutto ho bisogno di dati, senza di esso non si innesca il meccanismo descritto prima.
2. Insieme di norme, regole e procedure: formano un nucleo operativo che serve all'azienda per l'acquisizione ed il trattamento dei dati. Si suddividono in:
   • Procedure organizzative
   • Procedure informatiche
3. Infrastruttura tecnologica: ovvero i mezzi e gli strumenti a supporto dei processi di raccolta, conservazione, trasferimento, elaborazione, recupero, distribuzione (far arrivare le informazioni a chi servono) e presentazione dei dati e delle informazioni.
4. Risorse umane:
   • Persone responsabili della realizzazione e gestione delle procedure, del governo e della conservazione del patrimonio di dati. Chi è operativo nell’area dei sistemi informativi.
   • Addetti alla gestione del sistema = coloro che si occupano della sua progettazione, realizzazione e manutenzione.
5. Insieme dei principi generali, dei valori e delle idee di fondo: caratterizzano la cultura aziendale e orientano il sistema, condizionandone i comportamenti. Cultura di base che influenza tutto quello che fa l’azienda e quindi influenza anche il sistema informativo.

Sfatiamo i miti

Il concetto di Sistema Informativo nasce molto prima dell’informatica. Nel momento in cui nasce l’azienda, inevitabilmente nasce un sistema informativo, azienda intesa anche come la semplice unione di persone, che insieme prendono decisioni in base a delle informazioni che hanno raccolto (tre pastori non portano al pascolo le pecore perché dal cielo pensano possa piovere).

I sistemi informativi sono molto di più dell’informatica, che si trova all’interno dei sistemi di informazioni, perché oggi noi gestiamo i dati per produrre l’informazione attraverso software di ICT. Quindi il SI è diverso dall’informatica, ma al massimo l’informatica è contenuta all’interno del Sistema Informativo (SI).

Guardando allo schema, dall’esterno verso l’interno. L’azienda si trova all’interno di un ambiente, con il quale interagirà (Stakeholders, che si trovano nell’ambiente con cui l’azienda interagisce). Dentro l’azienda c’è un sistema organizzativo, che permette all’azienda di funzionare. Il Sistema informativo a sua volta si trova all’interno del sistema organizzativo, essendo che è parte essenziale nella presa delle decisioni. Infine, come detto prima il Sistema informatico (ICT, i mezzi informatici), si trova all’interno del Sistema Informativo.

Basi di dati e DBMS

Basi di dati = collezione di dati, di interesse per una o più applicazioni, strutturati secondo un modello logico ben definito. È una raccolta organizzata di dati. Quindi non è una semplice “accozzaglia” di dati, ma gli viene data una struttura, diventa una Base di Dati = DATABASE.

Perché: per superare i problemi dell’approccio convenzionale a “files”. Le basi di dati (DataBase) vengono gestite da specifici software chiamati “Sistemi di gestione di basi di dati” (DBMS – DataBase Management System). Quindi sono software per gestire i database, quindi software che mi permettono di utilizzare quei dati.

Modelli logici dei dati

• Modelli logici: rappresentazione dei dati secondo un modello logico. “Insieme di concetti utilizzato per organizzare i dati di interesse e descriverne la struttura” (Atzeni)
• Tipologie di modelli: (evoluti negli anni)
  • Modello gerarchico ('60)
  • Modello reticolare ('60)
  • Modello relazionale ('70,'80) Oggi è lo standard nei DataBase delle aziende
  • Modello a oggetti ('80)
  • Modello XML ('90)
  • Modelli NoSQL (2000)

Il modello relazionale

Creato da IBM nel 1969 ed introdotto negli anni '80, deve la sua lunga vita alla sua semplicità, grazie ad un sistema tabella. Colonne rappresentano gli attributi, le righe rappresentano gli elementi.

Modello indipendente da specifiche tecnologie informatiche. Non importa se tu hai un PC Windows o Apple, hai tanta o poca RAM, SSD o HDD, non importa, funziona sempre. Questo è fondamentale per la sopravvivenza del modello logico di IBM. Il più diffuso in assoluto. Costruttore principale: Relazione (Tabella) che organizza i dati in insiemi di record a struttura fissa. Il DB Relazionale raccogliere i dati in tabelle collegate tra di loro. Ecco perché è nato RDBMS – Relational Database Management System che permette di gestire database di tipo relazionale.

Caratteristiche dei DBMS

Software che gestiscono collezioni di dati:

• Grandi
• Condivise
• Persistenti

Qualsiasi DBMS deve garantire almeno queste 4 caratteristiche:

1. Affidabilità: Se faccio più volte la stessa query (domanda), deve restituirmi sempre lo stesso risultato.
2. Privatezza: Chi non è autorizzato non deve poter accedere ai dati dall’esterno. Vale anche l’interno dell’azienda, il software DBMS deve garantire i cosiddetti “coni di visibilità”, ovvero non tutti i dipendenti dell’azienda possono avere la stessa visibilità dei dati, tramite un sistema a profili, alcuni profili vengono “limitati” nel vedere certi dati.
3. Efficacia/Efficienza: Capacità di estrarre i dati / Capacità di estrarre i dati con il minor sforzo possibile.
4. Consistenza – Integrità dei dati: La consistency, ovvero l’integrità dei dati, cioè che qualsiasi cosa accade, il dato deve rimanere integro, non devo perdere dati per colpa del software. Classico caso è l’accesso contemporaneo di alcuni software DBMS mal progettato, se in due andiamo a vedere gli stessi dati il DataBase cade. Questi DBMS non possono essere sul mercato.

Architettura standard dei DBMS

Livelli di astrazione: Vediamo dallo schema che il DBMS funge da filtro per chi accede ai dati del Data Base dall’esterno. Per esempio, gestiste tutti i software in azienda che hanno bisogno dei dati (di fatturazione, del sistema dei pagamenti, ecc.), ma nessuno può accedervi direttamente, devono passare per il DBMS. Ad oggi, per cambiare i DBMS non devo ristrutturare i dati e cambiare le applicazioni, prima non era così ed era anche molto oneroso.

Architetture

Come andiamo a concretizzare l’accesso dei dati al DBMS:

• Mainframe: All’inizio si è partito come i Mainframe. In azienda c’era un grande computer al quale si collegavano una serie di “Terminali” (o Dumb Client, ovvero client stupidi, non avevano nessuna capacità operativa, era tutto concentrato nel mainframe, dati e DBMS). I terminali mandavano la richiesta al Mainframe che faceva tutto. Questo è andato bene fino agli anni ’80 dove i dati erano pochi.
• Client/Server: Negli anni a seguire i dati esplodono, il Mainframe non riesce a gestire tutto il carico elaborativo. Quindi si è passati all’architettura Client/Server, che divide la rete in due tipologie: un elaboratore nella rete può essere un Client o un Server. Server = (to serve = offrire) un operatore che offre un servizio all’interno della rete, cambia nome in base al servizio che offre (data server, memorizza i dati, mail server, fa funzionare i servizi di posta elettronica, printer server, ecc.) | Client = usufruisce i servizi degli altri, è un cliente. La differenza rispetto al Mainframe è che in azienda ho tanti server, che sono differenziati in base al servizio che offrono. Inoltre, i Client di oggi sono più “intelligenti” dei Dumb Client, sono in grado di fare delle operazioni, quando necessità di un servizio chiama il server e si fa dare il servizio. I servizi si muovono nella LAN (la rete aziendale).
• Cloud Computing: Oggi si sta sviluppando una nuova tendenza delle architetture, il Cloud Computing. Ovvero alcuni servizi invece di muoversi sulla LAN, vanno fuori dall’azienda; quindi, vengono presi da qualcosa di esterno all’azienda, dal “computer di qualcun altro”. I dati non si trovano più localmente (LAN, rete locale), ma stanno su internet. Questo comporta dei benefici:
  • Capacità di storage è data dal provider (dipende da quanto pago), colui che mi offre il servizio.
  • Disponibilità dei dati ovunque ci troviamo (everywhere access).
  • Sicurezza dei dati (motivo più importante). Demando a qualcuno fuori dall’azienda l’onere di gestire i dati. Proteggere i dati è estremamente oneroso.

Ci sono anche degli svantaggi:

• La gestione è affidata a terzi, quindi i dati dipendono da una figura esterna all’azienda. Bisogna essere sicuri che il terzo garantisca la privacy dei dati, che non li venda a qualcuno ecc.
• Essendo everywhere access, l’accesso dipende dalla rete internet, in mancanza di rete non posso accedere ai dati di cui necessito.
• Potenziale dipendenza dal fornitore, nel caso in cui il provider che gestisce i dati spegne tutto ed io non posso accedere più ai dati? Questo sarebbe un problema. Posso minimizzare il problema andando dai leader del settore, per esempio se mi affidassi a Google difficilmente l’azienda chiuderà o che si crei un danno di immagine facendo trapelare i miei dati.

Il passaggio al WEB/CLOUD è una classica decisione presentata dal CIO.

Metodologie di sviluppo dei sistemi informativi

Il Sistema Informativo NON si compra, non è un software, quindi va CREATO. Ci sono due strade:

1. Sviluppo interno del Sistema Informativo: L’azienda non sarà la prima a creare un proprio Sistema Informativo internamente, quindi, negli anni è nata una METODOLOGIA, ovvero i passaggi da fare per arrivare a sviluppare il SI, attraverso l’esperienza dei predecessori. “Un approccio coerente e sistematico, basato su una particolare metodologia: filosofia di sviluppo dei sistemi, che indica agli sviluppatori quali step eseguire, come questi dovrebbero essere svolti e perché sono importanti nello sviluppo di un sistema informativo”. [Fitzgerald, 2002]
   • Waterfall model
   • Prototyping approach
   • Incremental delivery
   • Spiral model
2. Outsourcing: Mi rendo conto di non avere le competenze, le risorse finanziarie per farlo internamente, quindi esternalizzo.

Waterfall model

Una delle più utilizzate, nata negli anni ‘80. Letteralmente è un modello a cascata, formato da 7 fasi. L’output di una fase, diventa l’input della fase successiva. Banalmente “ci sono 7 cose da fare”, cominciamo dalla prima ed andiamo avanti.

Fasi del Waterfall model

1. Studio di fattibilità: Prima si pensa e poi si fa. Si analizza se è fattibile l’idea. Identifico l’Obiettivo da raggiungere e vedo se è fattibile, perché ho dei limiti: economici, temporali (Quando mi serve? Riesco a produrlo in tempo? competenze (devo essere capace di farlo). Posso anche forzare questi vincoli, posso trovare fonti di finanziamento, posso formare i miei dipendenti (è un costo) oppure outsourcing (assumo personale). Con risorse umane e finanziare in più, accorcio i tempi di realizzazione.
   • Obiettivi:
   • Stabilire se e quando avviare il progetto
   • Valutare le possibili opzioni di sviluppo
   • Valutare le risorse (umane e finanziarie) necessarie
   • Output: documento di fattibilità
   • Definizione preliminare del problema
   • Scenari e strategie di soluzione
   • Costi, tempi e modalità di sviluppo

   Al termine dell’analisi, il risultato viene scritto nel Documento di fattibilità, il quale esce con una risposta sulla fattibilità, ovvero è fattibile o no. Chi è coinvolto in questa fase? Ovviamente non viene coinvolta la parte “bassa” dell’azienda, ma lo studio viene effettuato dal top management ed eventualmente un consulente esterno.

2. Analisi dei requisiti: User requires definition, ovvero requisiti utente. Ovvero bisogna andare dall’utente finale e chiedere di cosa ha bisogno, cioè vado dal dipendente e gli chiedo di cosa ha bisogno, lui lo propone, io lo valuto e decido. Si risponde ad una serie di domande.
   • Obiettivi:
   • Cosa deve fare il sistema? (What)
   • Chi deve usare il sistema? (Who)
   • Perché viene sviluppato/utilizzato? (Why)
   • Quale supporto deve offrire? (What vs. How)
   • Dove (arch. HW-SW) verrà utilizzato? (Where)
   • Quando e per quanto tempo sarà usato? (When)
   • Richiede l’analisi/conoscenza del dominio applicativo e l’interazione con l’utente.

   Molti manager non vogliono andare a chiedere al dipendente di basso livello, ma questo è un grosso errore, perché chiede di sapere i bisogni del dipendente che svolge quella mansione e chiedere direttamente a lui. Il CEO non vuole farlo perché impiega tempo e denaro andare all’utente finale di ogni reparto aziendale, questo può colpire l’efficienza dell’azienda.

   Output: Specifica dei Requisiti. Anche qui serve un documento con la Specifica dei Requisiti per ogni dato raccolto per area aziendale. L’area logistica di cosa ha bisogno, l’area commerciale ecc. Ovviamente le specifiche raccolte devono essere validate dallo studio di fattibilità, deve essere realizzabile.

3. Progettazione (Fase tecnica dello sviluppo): Fase di Design, che in inglese significa progettare. Bisogna progettare la soluzione, ovvero l’architettura del sistema. La figura a cui ci si riferisce è un informatico che progetta a livello hardware e software il sistema.
4. Sviluppo e unit test: Il “muratore” del sistema è il programmatore, che inizia a scrivere il codice del software che permette di fare ciò che vuole l’informatico che ha progettato il sistema.