Appunti Sistemi informativi aziendali avanzato

SISTEMI INFORMATIVI AZIENDALI AVANZATO (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

Scritto

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 una 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 una

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) 1

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. 2

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:

a. Procedure organizzative

b. 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:

a. Persone responsabili della realizzazione e gestione delle procedure, del

governo e della conservazione del patrimonio di dati. Chi è operativo

nell’area dei sistemi informativi.

b. Addetti alla gestione del sistema = colore che si occupano della sua

progettazione, realizzazione e manutenzione.

Gli utenti della funzione sistemi informativi, non sono solo gli addetti a

quel reparto, ma sono tutti i dipendenti dell’azienda (attivi o passivi),

perché gli alimentano (inseriscono dati, anche senza saperlo).

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

l’azienda 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 3

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 (I Dati, primo dei 5 componenti)

- Base di dati = collezione di dati, di interesse per una o più applicazioni,

strutturati secondo un modello logico ben definito. È una raccolta organizzata di

dati. (N.B.) 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)

Non esiste più

Modello gerarchico (’60)

o Non esiste più

Modello reticolare (’60)

o Modello relazionale (’70,’80) Oggi è lo STANDARD nei DataBase delle



o aziende Più evoluto, di nicchia

Modello a oggetti (’80)

o Più evoluto, di nicchia

Modello XML (’90)

o Più evoluto, di nicchia

Modelli NoSQL (2000)

o 4

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

- Software applicativi che implementano il modello logico relazionale per la

gestione dei dati

- Indipendenza dei dati rispetto ai programmi ed al modello

Obiettivo:

logico

- Funzionalità principali:

Garantire accesso condiviso ai dati da parte di utenti ed applicazioni

o Linguaggi specifici per la gestione dei dai (SQL: Structured Query

o Language). Linguaggio utilizzato per interrogare i dati nei database.

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 i 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 5

4. Consistenza – Integrità dei dati La consistency, ovvero la 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

DBMS ARCHITETTURA STANDARD

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. 6

Architetture? Come andiamo a concretizzare l’accesso dei dati al DBMS: Mainfram 

Client Server WEB/CLOUD



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.

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)

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. 7

- 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:

Ovviamente 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 INFOMATIVI

Il Sistema Informativo NON si compra, non è un software, quindi va CREATO.

Ci sono due strade:

1) Posso svilupparlo internamente

2) Outsourcing, mi rendo conto di non avere le competenze, le risorse finanziarie

per farlo internamente, quindi esternalizzo. 8

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]

Esistono 4 modelli principali:

1. Waterfall model

2. Prototyping approach

3. Incremental delivery

4. Spiral model

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.

1° fase = STUDIO DI FATTIBILITA’

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 9

umane e finanziare in più, accorcio i tempi di realizzazione.

Quindi i tre vincoli sono strettamente legati tra loro.

- Obiettivi

Stabilire se e quando avviare il progetto

o Valutare le possibili opzioni di sviluppo

o Valutare le risorse (umane e finanziarie) necessarie

o

- Output: documento di fattibilità

Definizione preliminare del problema

o Scenari e strategie di soluzione

o Costi, tempi e modalità di sviluppo

o

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° fase = 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)

o Chi deve usare il sistema? (Who)

o Perché viene sviluppato/utilizzato? (Why)

o Quale supporto deve offrire? (What vs. How)

o Dove (arch. HW-SW) verrà utilizzato? (Where)

o Quando e per quanto tempo sarà usato? (When)

o Richiede l’analisi/conoscenza del dominio applicativo e l’interazione con

o 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° fase = 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° fase = 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.

10

Il modo più