ICT e Sistemi informativi Aziendali

Presentazione sul tema: "ICT e Sistemi informativi Aziendali"— Transcript della presentazione:

1 ICT e Sistemi informativi Aziendali
Materiale di supporto alla didattica

2 ICT e Sistemi informativi Aziendali
CAPITOLO V Sistemi informativi aziendali Par 1,2,3

3 Sommario Sistemi Informativi La funzione SI
Par 1,2,3 Sistemi Informativi La funzione SI Progettazione e sviluppo di software e sistemi

4 Sistema informativo un sistema informativo è un insieme di diversi componenti che consentono la produzione e la gestione dell’informazione. Questa sintesi estrema delle definizioni di sistema informativo mette in luce i tre ambiti attorno ai quali si articolano le diverse visioni sull’argomento presenti in letteratura: la determinazioni di quali sono i componenti di un sistema informativo; le funzioni (azioni) che esso svolge; l’oggetto delle azioni svolte ossia le informazioni. Come detto del capitolo 1, un sistema informativo è un insieme di diversi componenti che consentono la produzione e la gestione dell’informazione. Questa sintesi estrema delle definizioni di sistema informativo mette in luce i tre ambiti attorno ai quali si articolano le diverse visioni sull’argomento presenti in letteratura: q       la determinazioni di quali sono i componenti di un sistema informativo; q       le funzioni (azioni) che esso svolge; q       l’oggetto delle azioni svolte ossia le informazioni. In alcune definizioni le azioni che il sistema informativo è chiamato a eseguire sono espresse in modo generico: esso deve consentire all’azienda “di disporre delle informazioni” (De Marco et al., 1987) e, comunque, in generale deve essere in grado di produrre informazioni. Nelle definizioni maggiormente circostanziate relativamente a questo aspetto c’è, tuttavia, sostanziale consenso sul fatto che il sistema informativo debba supportare la raccolta, l’analisi, l’elaborazione, la memorizzazione e la diffusione delle informazioni (Turban et al., 2002; Alter, 2002; Laudon e Laudon 1996). L’informazione, viene considerata come una forma estensiva del concetto più basilare di dato. Laudon e Laudon (1991), ad esempio, definiscono l’informazione “come il risultato di dati modellati dagli umani in una forma utile e significativa”.

5 La disciplina dei sistemi informativi
Nell’ambito della ricerca e della didattica, con Sistemi Informativi si è soliti descrivere quell’area interdisciplinare risultante principalmente dall’intersezione di economia aziendale e Scienza dell’informazione. Semplificando si può affermare che mentre l’economia politica, l’economia aziendale e le discipline affini si occupano principalmente dei due fattori di produzione tradizionale, ossia il capitale e il lavoro, l’organizzazione dei sistemi informativi aziendali si interessa dello studio del fattore di produzione informazione”, ossia della risorsa principale di quella che viene chiamata società dell’informazione. Nell’ambito dei sistemi informativi sono poi sempre più presenti studi strettamente legati agli aspetti giuridici. Si pensi, per esempi, alla protezione dei dati, al diritto del lavoro nella trasformazione di normali rapporti lavorativi in rapporti di telelavoro o ai diritti d’autore nello sviluppo di nuovi sistemi informativi. In modo analogo nell’ambito dello sviluppo di nuove interfacce grafiche il contributo delle ricerche nell’area della psicologia sono sempre più indispensabili. In molti studi ai quali hanno partecipato anche psicologi del comportamento, si è cercato di stabilire in quali condizioni l’introduzione di un sistema informativo, che muta notevolmente l’ambiente lavorativo, abbia successo o meno. L’interazione fra tecnologia e organizzazione non rappresenta solo un interesse di ricerca, quanto e soprattutto una valenza progettuale, che si è venuta accentuando con l’apparire delle “tecnologie di organizzazione”, quali l’informatica e la telematica, cioè quei sistemi tecnologici che di fatto rac-chiudono al proprio interno modelli organizzativi e gestionali complessi (Ciborra, 1993). Il rapporto tra tecnologia e organizzazione costituisce quindi un tema oggetto di attenzione da parte di studiosi afferenti a discipline diverse ma anche quelle figure manageriali e professionali che si trovano a dover presidiare il rapporto tra tecnologie, gestione delle informazioni, e progettazione organizzativa. Esprime bene la visione della disciplina la definizione proposta da Angell e Smithson (1991) secondo i quali “i sistemi informativi sono sistemi sociali le cui caratteristiche sono pesantemente influenzate dagli obiettivi, dai valori e dalle tradizioni degli individui, dei gruppi, così come delle performance della tecnologia”. Risulta quindi evidente che i sistemi informativi siano un oggetto di difficile analisi teorica per almeno due ordini di ragione intrinseche alla loro stessa natura: la loro dinamicità tecnologica e la loro complessità concettuale.

6 Funzione Sistemi Informativi
La funzione sistemi informativi (FSI) è l'unità che, nell'ambito della struttura organizzativa aziendale, è delegata alla gestione dell’elaborazione e della distribuzione, a tutti i reparti dell’impresa, delle informazioni che sono necessarie al raggiungimento degli obiettivi aziendali. La funzione sistemi informativi (FSI) è l'unità che, nell'ambito della struttura organizzativa aziendale, è delegata alla gestione dell’elaborazione e della distribuzione, a tutti i reparti dell’impresa, delle informazioni che sono necessarie al raggiungimento degli obiettivi aziendali. Obiettivo primario della FSI è la diffusione della tecnologia informatica a supporto di tutti quei processi aziendali che, dopo un’attenta analisi costi/benefici, possono essere resi più efficaci ed efficienti attraverso l’attivazione di processi informativi automatizzati (Bertella, 1990). La funzione sistemi informativi è inoltre l’unità organizzativa preposta al governo del sistema informativo automatizzato e allo sviluppo e manutenzione delle attività informatiche in azienda.

7 Compiti della FSI Pianificazione, studio, concezione, progettazione, realizzazione, esercizio, manutenzione, valutazione delle prestazioni, attività di supporto agli utenti, relazioni con fornitori esterni, valutazione del fornitore e del sistema, acquisizione installazione delle procedure automatizzate I compiti generalmente assegnati sono: la pianificazione, lo studio, la concezione, la progettazione, la realizzazione, l’esercizio, la manutenzione, la valutazione delle prestazioni, le attività di supporto agli utenti e le relazioni con fornitori esterni, riguardo alla valutazione del fornitore e del sistema, e l’acquisizione e l’installazione delle procedure automatizzate (Cioffi G., 1989). La pianificazione del sistema informativo dell’azienda consiste nell’attività decisionale relativa alle linee di sviluppo applicativo e tecnologico dell’informatica in azienda. La FSI è anche incaricata dello sviluppo del sistema informativo. In alcuni casi, tuttavia, soprattutto negli ultimi anni, si riscontra la tendenza a demandare a fornitori esterni la realizzazione di parti del sistema informatico o di alcune applicazioni. In tale circostanza la FSI svolge un ruolo di coordinamento tra le aziende esterne incaricate di sviluppare le applicazioni e gli utenti finali. Talvolta la gestione e la realizzazione dei sistemi informatici può essere demandata completamente all’esterno. In questo caso si configura una situazione di outsourcing o esternalizzazione che tende a cancellare la funzione sistemi informativi dalla macro struttura dell’azienda, delegando ad altre funzioni (tipicamente quella “Organizzazione” ) o alla Direzione Generale, il presidio interno a controllo delle attività dell’outsourcer. Inoltre, mediante la gestione delle tecnologie informatiche, la FSI supporta l’attività di realizzazione del sistema informatico. Realizza quanto definito dagli utenti, le altre funzioni aziendali, che esplicitano i requisiti che la nuova procedura deve soddisfare. Sviluppa la parte automatizzata delle nuove procedure preoccupandosi del corretto funzionamento delle stesse e dell’ottenimento di adeguati livelli di efficienza. Alla FSI compete anche l’esercizio delle applicazioni realizzate. Per esercizio si intende l’insieme delle mansioni relative allo svolgimento e al controllo delle attività quotidiane che consentono l’utilizzo delle applicazioni informatiche da parte degli utenti. Appartengono all’esercizio compiti quali la gestione dell’hardware, ad esempio per i cambiamenti di configurazione, e del software, per esempio per le nuove release e per gli aggiornamenti, l’esecuzione delle procedure automatizzate, il controllo di funzionamento delle reti, la schedulazione delle elaborazioni batch, quelle cioè che sono realizzate non on line e il supporto agli utenti sia operativo sia formativo. La FSI è altresì responsabile della manutenzione del sistema. Per manutenzione si intende quell’insieme di attività volte alla correzione o alla modifica di alcuni aspetti della procedura automatizzata, o più frequentemente di alcuni errori presenti nel programma. Spesso l’esigenza di manutenzione nasce da cambiamenti esterni cui è necessario adeguare la procedura. Alla FSI competono, inoltre, le attività di analisi e di valutazione della corrispondenza delle prestazioni del sistema informativo con le scelte strategiche, tattiche e operative dell’azienda. La funzione sistemi è ancora responsabile delle attività di supporto all’informatica individuale e all’office automation incentrate sull’installazione, sulla formazione e sul supporto operativo relativo ai pacchetti di office automation. Tra le attività di supporto rientrano, in particolare, le attività di relazione con i fruitori del servizio informatico. Tali attività, svolte da figure professionali appositamente istituite, sono volte a presidiare aree specifiche di utenza per individuarne i fabbisogni e innescare meccanismi organizzativi in grado di provvedere al loro soddisfacimento. La FSI è, inoltre, responsabile delle attività di relazione con i fornitori. Valuta da un lato la disponibilità sul mercato della tecnologia informatica, dall’altro l’affidabilità dei fornitori e delle soluzioni proposte. La direzione della funzione sistemi è, infine, responsabile della gestione e dell’organizzazione delle risorse interne. Tra i principali compiti si rilevano l’attività di gestione del personale interno, l’attività di pianificazione programmazione e controllo della funzione, le correlate attività amministrative, il presidio delle metodologie e degli strumenti di supporto alle attività di sviluppo e di esercizio e l’attività di ricerca sulle tecnologie innovative. In estrema sintesi i principali compiti assegnati alla funzioni sistemi sono: - le attività necessarie all’analisi e alla valutazione del fabbisogno informativo; - la gestione del personale specializzato (analisti, programmatori, etc.); - la gestione dell’hardware e dei dispositivi di comunicazione, la manutenzione e l'aggiornamento del software aziendale;

8 Outsourcing della FSI Talvolta la gestione e la realizzazione dei sistemi informatici può essere demandata completamente all’esterno In questo caso si configura una situazione di esternalizzazione che tende a cancellare la Funzione Sistemi Informativi dalla macro struttura dell’azienda, delegando ad altre funzioni (tipicamente quella “Organizzazione”) o alla Direzione Generale, il presidio interno a controllo delle attività dell’outsourcer

9 Possibili approcci alle strategie ICT
Il livello di dipendenza di un’impresa dall’ICT è quantificabile in funzione delle procedure automatizzate che sono necessarie al raggiungimento degli obiettivi aziendali. Pertanto, nelle aziende in cui è rilevante il ruolo della gestione delle informazioni, quali ad esempio gli istituti di credito o i tour operator, il grado di penetrazione dell’ICT è di norma molto maggiore rispetto a quello di un’impresa che produce materie prime, quale ad esempio una cava di ghiaia. Quest’ultima, infatti, utilizzerà i sistemi informativi prevalentemente per eseguire compiti gestionali e di distribuzione. Le linee guida generali di una strategia legata alle tecnologie dell’informazione e della comunicazione sono determinate in funzione della strategia globale dell’impresa, che descrive le misure a lungo termine necessarie per il raggiungimento degli obiettivi prefissati, e identificabili nella maggior parte dei casi con aspettative di redditività, od incremento del valore azionario per i soci (shareholder value). Sulla scorta degli obiettivi che l’impresa persegue mediante l’utilizzo dell’ICT, si possono distinguere essenzialmente tre modelli strategici, classificati in Figura. Modello I: l’azienda sfrutta le opportunità tecnologiche per ridurre i costi di gestione. Un’azienda industriale, ad esempio, investe in applicazioni CAM (Computer Aided Manufacturing) per sostituire la costosa manodopera con processi di produzione automatizzati. In tale ottica strategica potrebbe rientrare anche l'introduzione di sistemi per la generazione di offerte nell’ambito del processo di vendita in modo da consentire alla struttura commerciale di presentare ai propri clienti un maggior numero di offerte ed una maggior livello di dettaglio e qualità delle stesse a parità di tempo. Modello II: attraverso l'automazione l’impresa tenta di migliorare, o di conservare, la propria posizione di mercato, offrendo, ad esempio, alla clientela nuovi servizi a valore aggiunto, differenziando in tal modo il proprio prodotto da quello della concorrenza. Modello III: l’azienda sfrutta le opportunità offerte dalla tecnologia per potersi adattare in modo più flessibile ai cambiamenti del mercato. In particolare attraverso le tecnologie delle telecomunicazioni e l’accesso a database comuni. In questo ambito un apporto fondamentale viene dalle reti Intranet e Extranet (ovvero architetture aziendali inter-aziendali di comunicazione che sfruttano le tecnologie Internet). Grazie al protocollo TCP/IP e all'interfaccia ipertestuale del Web, le Intranet possono risolvere problemi che le applicazioni di rete “tradizionali” non sono storicamente riuscite ad affrontare.

10 Pro e contro dell’outsourcing
Dopo aver determinato le procedure aziendale interessate ad un processo di automazione, si deve decidere se i progetto di sviluppo dovrà essere realizzato in proprio o da terzi. Tale decisione può riguardare l’intera area Sistemi Informativi, uno specifico servizio di elaborazione dati, la produzione globale della procedura automatizzata, o lo sviluppo di singoli applicativi. La decisione di acquistare da terzi procedure o servizi legati alla gestione dell’informazione, tradizionalmente gestiti all'interno dell'azienda, viene denominata outsourcing e vi si ricorre in genere quando non è disponibile un adeguato know-how aziendale o quando un fornitore esterno è in grado di fornire un più elevato livello qualitativo a costi ridotti. L'outsourcing emerge come uno degli strumenti manageriali, di carattere tattico e strategico, che hanno conosciuto la maggiore espansione nel corso dell'ultimo decennio e che, secondo autorevoli e diffuse proiezioni, continuerà a proporsi nei suoi diversi ambiti e nelle sue varie applicazioni come una via obbligata per la sopravvivenza sul mercato delle imprese, senza distinzione di industria, dimensione o missione aziendale. In particolare, nell’area dell’ICT, di outsourcing si è parlato fin dall'inizio del trattamento elettronico dei dati, ma in tempi più recenti il fenomeno ha assunto dimensioni molto diverse. Si è passati infatti dall'outsourcing di servizi legati alla gestione dei dati o alla programmazione, alla fornitura esterna di tutte (o di gran parte) delle funzionalità del sistema informativo. Un fenomeno che, soprattutto nel mondo della new economy, scardina la visione tradizionale dell’outsourcing secondo la quale l’esternalizzazione dovrebbe toccare solo funzioni e processi estranei all’attività fondamentale dell’azienda. In sintesi, considerare l'outsourcing esclusivamente come un mero mezzo di sopravvivenza o una soluzione nel breve termine risulta alquanto limitativo: l'outsourcing può infatti rappresentare uno strumento di pianificazione delle strategie a medio-lungo termine con il quale misurare e contenere i costi proporzionalmente allo sviluppo delle attività aziendali. L’esternalizzazione può tuttavia comportare degli svantaggi, quali ad esempio la dipendenza dall’outsourcer selezionato. La decisione tra sviluppo interno e l’esternalizzazione di una procedura automatizzata sono strettamente influenzati dal significato strategico della stessa e dalle potenzialità tecnologiche dell’azienda.

11 Ruolo della FSI Il ruolo della FSI è strettamente correlato alla specifica macrostruttura organizzativa definita all’interno dell’azienda, e, in particolare: al posizionamento della Funzione Sistemi nella macrostruttura organizzativa all’organizzazione interna della Funzione Sistemi Il ruolo della funzione sistemi informativi è strettamente correlato alla specifica macrostruttura organizzativa definita all’interno dell’azienda, ed in particolare: --al posizionamento della funzione sistemi nella macrostruttura organizzativa; --all'organizzazione interna della funzione sistemi. questi due aspetti dipendono di norma : - dalle dimensioni dell'azienda ; - dal ruolo strategico della tecnologia per il raggiungimento degli obiettivi aziendali; - dalla tipologia delle tecnologie e applicazioni gestite (es. applicazioni standard o specifiche procedure personalizzate); - dall'evoluzione sviluppo storica della funzione sistemi informativi aziendali; - dalla struttura organizzativa dell'azienda; - dal numero ed dalla tipologia di utenti interessati; - dall'assetto dell’azienda sul territorio (una sede o più sedi, nazionali o internazionali).

12 Collocazione della FSI
Sostanzialmente la FSI può essere collocata nella macrostruttura organizzativa secondo due possibili approcci: come centro di consulenza alla direzione (funzione di staff) come area (o sotto area) funzionale

13 Posizionamento della FSI nella macrostruttura organizzativa
Un’organizzazione che considera i sistemi informativi come funzione di staff sottolinea il carattere di servizio della tecnologia ponendoli alle dirette dipendenze della direzione , ma ad un livello superiore rispetto alle altre aree funzionali dell’azienda. quando ict e gestione dell’informazione hanno un ruolo di particolare rilievo strategico per l’intera azienda la funzione sistemi informativi può essere considerata come un’area funzionale. Tuttavia, in questo caso, il carattere di servizio dell’ict è meno marcato rispetto alla configurazione precedentemente illustrata. talvolta può accadere che la funzione sistemi informativi venga subordinata ad un’area funzionale: questa configurazione è spesso dovuta a motivazioni storiche. in passato infatti, era l'area contabile a sfruttare maggiormente i benefici dell’elaborazione dei dati (EDP – Electronic Data Processing) e per questo motivo quindi in alcune realtà aziendali la gestione dell’ICT e delle informazioni è tuttora assegnata alla funzione amministrazione. alcune aziende organizzano l’elaborazione elettronica dei dati, o parti di essa, in società giuridicamente autonome delegando gli aspetti strategici della gestione delle informazioni alla funzione organizzazione. a favore dell’autonomia del reparto di elaborazione elettronica dei dati giocano, ad esempio, la maggiore facilità di vendere a terzi il software prodotto in proprio, l’opportunità di verificare sul mercato delle tecnologie l’efficienza del proprio processo di produzione del software mediante un confronto in termini di qualità e prezzi, nonché la possibilità di perseguire una politica retributiva ed occupazionale indipendente nell’impresa e di adottare orari di lavoro più flessibili e più adatti al tipo di attività svolta. quest’ultimo punto è particolarmente importante se si pensa che un progetto di sviluppo del software, come descritto in precedenza, presenta delle peculiarità (es. l'importanza del lavoro di gruppo) non riscontrabili in altri ambiti.

14 L’organizzazione della FSI
L’individuazione delle funzioni operative, intese come aggregato di compiti, svolti dall’insieme dell’organismo personale della FSI, consentono di determinare, in prima approssimazione, le differenti unità organizzative di base della FSI.Tipicamente un’azienda necessita di un elevato livello di servizi informatici per il trattamento dei dati, delle informazioni e per l’automazione dei processi. Le funzioni in grado di assolvere a tali esigenze sono identificabili in: 1.    funzioni di sistema 2.      funzioni applicative; 3.    funzioni di esercizio; 4.      funzioni di staff. Rientrano nelle funzioni di sistema tutte quelle attività che riguardano la valutazione tecnico-economica, lo studio, la sperimentazione, il dimensionamento, l’installazione e il collaudo dell’hardware centrale e periferico, della rete di telecomunicazioni, dei sistemi operativi, dei sistemi database, dei sistemi data communication, dei sistemi per la sicurezza logica e fisica e dei linguaggi di programmazione. Altre attività delle funzioni di sistema sono: l’analisi dell’efficienza tecnica dei sistemi elaborativi, la definizione degli standard di natura tecnica, l’addestramento e l’assistenza agli utenti finali sul funzionamento dei sistemi. I compiti relativi alle funzioni applicative riguardano l’attività di sviluppo delle applicazioni in termini di analisi funzionale, di analisi tecnica, di programmazione, di produzione della documentazione, di messa a punto, collaudo e consegna all’esercizio. Le funzioni applicative si occupano altresì dello studio, valutazione e acquisizione di software applicativo prodotto all’esterno, della manutenzione delle applicazioni (correttiva, adattiva ed evolutiva) e, infine, dell’addestramento e assistenza agli utenti finali sul funzionamento delle applicazioni. Le funzioni di esercizio si interessano della produzione di informazioni tramite la gestione dei sistemi elaborativi e della esecuzione su di essi dei programmi applicativi, della presa in carico dell’hardware, del software e delle procedure applicative, della programmazione temporale dei lavori sugli elaboratori, della conduzione degli elaboratori e delle relative unità di input/output, dell’individuazione dei malfunzionamenti dell’hardware, del software di base e dei programmi applicativi; della gestione di sistemi elaborativi periferici e delle reti di trasmissione dati e infine del controllo del buon fine e della completezza tecnica delle elaborazioni. Alle funzioni di staff competono l’attività di auditing, ovvero, la rilevazione e il controllo dell’osservanza degli standard e della normativa tecnica nonché quelle volte alla sicurezza logica e fisica del sistema informatico, alla amministrazione dei dati, al controllo della qualità dei progetti applicativi e del servizio fornito, l’attività di pianificazione, programmazione e controllo dei progetti elaborazione automatica dei dati - EAD -, alla gestione dell’addestramento e alla formazione EAD, al supporto metodologico e alla definizione degli standard aziendali. Il grado di dettaglio nella definizione delle funzioni descritte dipende in larga misura dalle dimensioni aziendali: un’impresa di grandi dimensioni disporrà probabilmente di una funzione sistemi informativi strutturata in molteplici e dettagliate sotto-funzioni, mentre un'azienda di medie dimensioni potrà contare soltanto sull’impiego di un centro di elaborazione dati e su una unità di esercizio per lo sviluppo e manutenzione del software.

15 Modelli di partecipazione dei progetti si sviluppo del sw
Le singole unità della funzione sistemi possono essere ulteriormente classificate secondo differenti criteri. Nell’ambito dello sviluppo di sistemi applicativi (funzione applicativa) si può, ad esempio, distinguere tra aree di sviluppo specializzate (che si occupano della creazione di procedure automatizzate nei settori della gestione del personale, della contabilità, della gestione dei materiali, o della produzione) e aree tecniche (coinvolte ad esempio nello sviluppo dei data base aziendale). Questa distinzione è influenzata, tra l’altro, dalle modalità in cui è strutturata la collaborazione tra la funzione sistemi informativi ed le altre unità funzionali aziendali nell’ambito dello sviluppo delle applicazioni informatiche. La Figura illustra cinque possibili modelli. 15 L’organizzazione della Funzione sistemi – 5.3.2

16 Ingegneria del software
Settore della disciplina dei sistemi informativi, dedicato allo studio delle metodologie, delle tecniche e degli strumenti utilizzati nella produzione industriale del software visto come processo di collaborazione tra analisti, programmatori e utenti finali Affronta le problematiche di tipo manageriale, organizzativo e metodologico per permettere che il lavoro di analisti e progettisti possa essere condotto con la maggiore efficacia, avvalendosi di tecniche e modi di procedere sperimentati in contesti eterogenei Il sistema informativo rappresenta una componente fondamentale e sempre più rilevante di ogni organizzazione. Alla definizione di sistema informativo si può arrivare esaminando la missione e gli obiettivi di un’organizzazione, le risorse disponibili e i processi di gestione delle risorse. Recentemente il concetto di processo inteso come insieme di attività fra loro interrelate e finalizzate alla realizzazione di un risultato definito e misurabile, che coinvolge più risorse e che attraversa più strutture, è considerato elemento di omogeneizzazione dell’organizzazione (la cosiddetta “visione per processi”). In questo senso, i principali presupposti allo sviluppo di un sistema informativo riguardano l’identificazione delle procedure (ovvero delle modalità definite per l’esecuzione di una o più attività) oggetto di possibile automazione, delle relative risorse necessarie (sia in termine di dati che di persone) e la successiva scelta delle migliori tecnologie e metodologie per lo sviluppo. Nel corso degli anni la letteratura sui sistemi informativi ha portato alla formulazione di un gran numero di proposte metodologiche, che prevedono diverse fasi ed attività, al fine di strutturare e migliorare i processi di automazione delle procedure (progettazione del software) e più in generale di gestione dell’informazione. Ad oggi, la progettazione del software, rappresenta uno dei processi principali nella realizzazione di un sistema informativo, e gran parte della letteratura di riferimento spesso assimila tale processo a quello relativo all’intero sviluppo di un sistema informativo in quanto molti dei principi e delle metodologie sono comuni ai due ambiti. Lo progettazione e lo sviluppo del software può essere analizzato sotto due differenti prospettive: quella dell’utente finale e quella di chi crea la procedura automatizzata. Da un lato infatti i futuri utenti devono specificare le caratteristiche dei processi aziendali debbano essere supportati dall’ICT (analisi dei requisiti) dall'altro analisti e programmatori, hanno il compito di verificare la fattibilità tecnica delle specifiche richieste e concretizzarla in applicativi efficienti. Lo sviluppo applicazioni software di grandi dimensioni e particolarmente rilevanti per un sistema informativo, come la contabilità generale, la gestione ordini, i conti correnti in una banca, avviene secondo tecniche stabilite dall’ingegneria del software (software engineering) . Obiettivo delle pagine che seguono è quello di approfondire i temi relativi allo sviluppo, controllo ed evoluzione di sistemi informativi mediante l'applicazione dei metodi e principi dell'ingegneria del software.

17 Software life cycle Insieme delle fasi che si susseguono, dal momento in cui il software viene concepito, progettato, realizzato, alla sua messa in opera e manutenzione, sino alla sua dismissione Un progetto di sviluppo software segue sempre un modello di ciclo di vita Per molti anni software e sistemi informativi sono stati sviluppati in modo artigianale, ovvero senza attenersi a metodi e standard. Se questo approccio ha portato a qualche risultato in presenza di poche applicazioni di piccole dimensioni, nel caso di procedure complesse, è necessario stabilire delle metodologie da seguire, degli standard nelle notazioni, delle sequenze nelle attività. L'ingegneria del software, è quindi quel settore dell'informatica aziendale, e più in generale della disciplina dei sistemi informativi, dedicato allo studio delle metodologie, delle tecniche e degli strumenti utilizzati nella produzione industriale del software visto come processo di collaborazione tra analisti, programmatori ed utenti finali. L'ingegneria del software affronta le problematiche di tipo manageriale, organizzativo e metodologico, per permettere che il lavoro di analisti e progettisti possa essere condotto con la maggiore efficacia, avvalendosi di tecniche e modi di procedere sperimentati in contesti eterogenei. L’analisi complessiva delle funzioni svolte in questo ambito consente di valutare tutte le fasi del cosiddetto ciclo di vita del software (software lyfe cycle).

18 Modalità di sviluppo Fra i tanti procedimenti, ve n’è uno quasi ingegneristico, che prevede la creazione dei veri e propri programmi software solo in una fase conclusiva (sviluppo in fasi), al quale si contrappone una soluzione più rapida che prevede la realizzazione di un primo semplice prototipo per il quale non è fondamentale un’analisi precisa dei requisiti Un progetto di sviluppo software segue sempre un modello di ciclo di vita, sia esso il classico modello a cascata (e relative derivazioni) o quello prototipale, entrambi descritti di seguito.

19 Modello a cascata Il processo di sviluppo di un sistema informativo o di un suo sottosistema (procedura o classi di procedure) è suddiviso in una sequenza di fasi Ogni fase deve essere terminata prima di passare a quella successiva (non si ritorna indietro) e l’output da essa generato andrà a costituire l’input della fase seguente È possibile effettuare controlli di qualità sui singoli risultati parziali Questa metodologia, denominata anche "a cascata" o “waterfall”[1] (perché da una fase si passa a quella successiva senza ritornare indietro, come il flusso dell'acqua in una cascata), prevede la suddivisione del processo di sviluppo di un sistema informativo o di un suo sottosistema (procedura o classi di procedure) in una sequenza di fasi. Ogni fase deve essere terminata prima di passare alla successiva e l'output da essa generato andrà a costituire l’input della fase successiva. Uno dei principali vantaggi di tale approccio risiede nella possibilità di effettuare controlli di qualità sui singoli risultati parziali. [1] Ideata da Walker Royce nel Testo originale: "Managing the Development of Large Software Systems", pubblicato in Proceedings of IEEE Wescon, 1970, e successivamente in "International Conference on Software Engineering - Proceedings of the 9th Conference , Monterey”

20 Modello di sviluppo a cascata di Balzert
Fase di pianificazione (studio di fattibilità) Fase di analisi (definizione) Fase di progettazione Fase di implementazione (programmazione) Fase di collaudo e di installazione Fase di manutenzione Parallelamente ai sei livelli deve essere realizzata una documentazione di supporto che registra i risultati delle singole fasi di sviluppo In letteratura si rinvengono numerosi modelli dello sviluppo "a cascata", che si distinguono principalmente per la denominazione delle singole fasi e per la definizione dei loro contenuti. Tra i tanti, verrà di seguito considerato un modello a sei livelli (Balzert, 1994) così strutturato: q fase di pianificazione (o studio di fattibilità), q fase di analisi (o definizione), q fase di progettazione, q fase di implementazione (o programmazione), q fase di collaudo e di installazione, q fase di manutenzione. Parallelamente a questi sei livelli deve essere realizzata una documentazione di supporto, nella quale vengono registrati i risultati delle singole fasi di sviluppo

21 Critiche al modello di sviluppo a cascata
È un modello rigido che si fonda su due assunti discutibili Gli utenti sono in grado di esprimere esattamente le loro esigenze e, di conseguenza, è possibile definire in fase di analisi iniziale tutte le funzionalità che il software deve realizzare (immutabilità dell’analisi) È possibile progettare l’intero sistema prima di aver scritto una sola riga di codice (immutabilità del progetto) Il modello a cascata si fonda sul presupposto che introdurre cambiamenti sostanziali nel software in fasi avanzate dello sviluppo ha costi troppo elevati: ogni fase deve essere svolta in maniera esaustiva prima di passare a quella successiva. I limiti del waterfall model sono dati dalla sua rigidità e in particolare da due assunti di fondo molto discutibili: gli utenti sono in grado di esprimere esattamente le loro esigenze e di conseguenza è possibile definire in fase di analisi iniziale tutte le funzionalità che il software deve realizzare (immutabilità dell’analisi) è possibile progettare l’intero sistema prima di aver scritto una sola riga di codice (immutabilità del progetto) Nella realtà la visione che gli utenti hanno del sistema evolve man mano che il sistema prende forma e quindi le specifiche cambiano in continuazione. Nel campo della progettazione, l’evidenza empirica suggerisce come le idee migliori emergano spesso per ultime, quando cioè un progetto è già nella fase di implementazione. Inoltre problemi di prestazioni costringono spesso a rivedere le scelte di progetto. Per cercare di ovviare a questi problemi, al primo in particolare, è stato introdotto il concetto di prototipazione: prima di iniziare a lavorare sul sistema vero e proprio è meglio costruire velocemente un prototipo in grado di simulare in scala ridotta il funzionamento del sistema in modo da fornire agli utenti una base concreta per meglio definire le specifiche. Una volta esaurito il compito, il prototipo viene abbandonato e si procede a costruire il sistema vero secondo i dettami canonici del modello a cascata Questo approccio risulta però quasi sempre così dispendioso da annullare i vantaggi economici che il modello a cascata dovrebbe garantire. Già da parecchi anni si è giunti alla conclusione che il modello a cascata puro è in molti casi difficilmente applicabile alla realtà organizzativa e l’ingegneria del software si è orientata allo studio modelli di tipo evolutivo (detti anche modelli incrementali o iterativi/a spirale[1]), sebbene waterfall e prototyping restino ancora gli approcci più utilizzati. [1] Per modelli alternativi, quali quello incrementale e iterativo/a spirale (entrambi derivati dal modello a cascata) si rimanda rispettivamente a Barry Boehm, "Software Engineering Economics", 1981, Prentice Hall e Barry Boehm, "A Spiral Model of Software Development and Enhancement", 1988 "Computer" e al sito

22 Fase di pianificazione (o studio di fattibilità)
Si stabiliscono gli obiettivi del sistema informativo da sviluppare In un primo studio preliminare si analizza la fattibilità del progetto sotto il profilo tecnico (possibilità di utilizzo delle risorse esistenti) ed economico (stima costi / benefici) FASE DI PIANIFICAZIONE Nella fase di pianificazione (o studio di fattibilità), partendo dall’idea del progetto e dalla bozza dei contenuti, si stabiliscono gli obiettivi del sistema informativo da sviluppare. In un primo studio preliminare si analizza la fattibilità del progetto sotto il profilo tecnico ed economico. Per quanto riguarda la fattibilità dal punto di vista tecnico è necessario valutare, tra l’altro, se è possibile utilizzare componenti hardware e software già esistenti all’interno dell’azienda, se sarà necessario introdurre un nuovo modello di organizzazione dei dati, o se il software che si intende realizzare possa essere adeguatamente supportato dalla piattaforma hardware esistente. L’analisi di fattibilità sotto il profilo economico consente, invece, di stimare i costi e i benefici derivanti dallo sviluppo di una nuova procedura .

23 Fase di analisi (o definizione)
Serve a individuare le aspettative dell’utente finale in relazione al prodotto da realizzare attraverso la cosiddetta analisi dei requisiti. Spesso è utile eseguire a priori un’analisi dei processi aziendali. Sulla scorta di tali ricerche e di un’eventuale analisi delle aree di criticità si elabora un progetto di massima del software. FASE DI ANALISI (O DEFINIZIONE) Nella fase di analisi (o definizione) è necessario individuare le aspettative dell'utente finale in relazione al prodotto da realizzare attraverso la cosiddetta analisi dei requisiti. Inoltre, spesso come punto di partenza è utile eseguire un’analisi dei processi aziendali. Sulla scorta di tali ricerche e di un’eventuale analisi delle aree di criticità si elabora un progetto di massima del software. Le specifiche così determinate possono essere successivamente classificate secondo aspetti funzionali, qualitativi ed economici. Gli aspetti funzionali sono orientati a determinare: q l’area funzionale che il nuovo software/sistema deve supportare (ad esempio, se un sistema destinato all'individuazione dei percorsi ottimali per gli automezzi di un’azienda di trasporti, debba limitarsi a questo compito o se debba anche stampare le bolle di accompagnamento per ogni automezzo); q le modalità con cui il sistema informativo deve eseguire le funzionalità per cui è predisposto (ad esempio, nella fase di analisi di un Management Information System, descritto nel Cap. 4, deve essere previsto che i dati siano trasferiti dal sistema centrale su una stazione di lavoro PC per poi essere facilmente consultati dal management); q i modelli di organizzazione dei dati cui le diverse procedure dovranno avere accesso; q gli input e gli output del sistema; Le specifiche qualitative riguardano indicazioni per: q la configurazione dell’interfaccia utente; q le aspettative relative ai tempi di risposta; q l’affidabilità del sistema. Le specifiche di tipo economico riguardano invece i costi di esercizio e di manutenzione da sostenere. Tutti i risultati vengono riportati, nel modo più preciso possibile, in un documento denominato specifiche di programma, che verrà utilizzato per descrivere al software le aspettative inerenti l’utilizzo concreto. Tale documento sintetizza i problemi e le esigenze degli utenti in modo chiaro e univoco. Le specifiche contengono quindi: le funzionalità che il sistema dovrà avere, le prestazioni, l'ambiente di utilizzo, le interfacce esterne (con utenti, altro software, hardware), gli eventuali vincoli di progetto (tempi, risorse, ecc.), i requisiti di qualità (sarà diverso scrivere un software per una centrale nucleare o per una biblioteca). Parallelamente alle specifiche di programma vengono stabilite anche quelle relative al processo di sviluppo. Rispetto agli aspetti funzionali si focalizza l’attenzione, ad esempio, sulla necessità di collaborazione tra le singole aree operative nell’esecuzione di compiti relativi al progetto, sugli impatti organizzativi derivanti dall'introduzione del nuovo sistema. Le specifiche qualitative del processo di sviluppo riguardano la documentazione del programma o i test da realizzare sul software. Infine le specifiche economiche comprendono i costi di sviluppo, la durata di quest’ultimo, le risorse necessarie e quelle disponibili oltre che una stima dei possibili benefici.

24 Fase di analisi: aspetti funzionali
Sono orientati a determinare: l’area funzionale che il nuovo software/sistema deve supportare le modalità con cui il sistema informativo deve eseguire le funzionalità per cui è predisposto i modelli di organizzazione dei dati cui le diverse procedure dovranno avere accesso gli input e gli output del sistema

25 Fase di analisi: aspetti qualitativi
Sono orientati a determinare: la configurazione dell’interfaccia utente le aspettative relative ai tempi di risposta l’affidabilità del sistema

26 Fase di analisi: aspetti economici
Sono orientati a determinare: i costi di esercizio i costi di manutenzione i benefici (risparmi) che si potranno eventualmente ottenere

27 Fase di analisi: specifiche di programma
Documento che sintetizza i problemi e le esigenze degli utenti in modo chiaro e univoco Contiene le funzionalità che il sistema dovrà avere, le prestazioni, l’ambiente di utilizzo, le interfacce esterne (con utenti, altro software, hardware), gli eventuali vincoli di progetto (tempi, risorse ecc.), i requisiti di qualità

28 Fase di analisi: specifiche del processo di sviluppo
Si focalizza l’attenzione su: aspetti funzionali (necessità di collaborazione tra le singole aree operative o studio degli impatti organizzativi derivanti dall’introduzione del nuovo sistema) aspetti qualitativi (documentazione del programma, test da realizzare sul software) aspetti economici (costi di sviluppo, durata di quest’ultimo, risorse necessarie, risorse disponibili, stima dei possibili benefici)

29 Fase di progettazione Ha l’obiettivo primario di individuare le funzioni che costituiscono un processo, le loro relazioni e i dati necessari alla loro realizzazione Inoltre, si studiano le modalità di produzione, utilizzazione, aggiornamento, cancellazione e scambio di dati rilevanti nell’ambito delle singole funzioni Due possibili approcci: progettazione tradizionale (strutturata) e progettazione object oriented FASE DI PROGETTAZIONE La progettazione di un sistema informativo ha l’obiettivo primario di individuare le funzioni che costituiscono un processo, le loro relazioni e i dati necessari alla loro realizzazione. Inoltre, è necessario studiare le modalità di produzione, utilizzazione, aggiornamento, cancellazione e scambio di dati rilevanti nell’ambito delle singole funzioni. Due sono i possibili approcci alla progettazione: attraverso la progettazione tradizionale (o strutturata) la realtà aziendale o il singolo processo vengono analizzati attraverso due tipi di modelli quello dei dati e quello delle funzioni. Nel caso in cui, invece, la progettazione sia orientata agli oggetti (OOD - Object Oriented Design), queste “prospettive” della realtà aziendale vengono riunite in un unico modello oggetto.

30 Approcci alla progettazione
Progettazione tradizionale (strutturata): la realtà aziendale o il singolo processo vengono analizzati attraverso il modello dei dati e quello delle funzioni Progettazione object oriented: dati e funzioni della realtà aziendale vengono riuniti in un unico modello oggetto In entrambi gli approcci si parte dalle specifiche di programma per realizzare il progetto logico e il progetto fisico In entrambi i casi, sono le specifiche di programma a costituire la base la fase di progettazione che ha l’obiettivo di realizzare l’intero sistema informativo mediante una gerarchia di sottosistemi (moduli) che possono essere sviluppati e riutilizzati in modo indipendente tra loro. In un primo momento, definito progetto logico, vengono identificate le componenti (moduli) del sistema, e le connessioni fra esse. Un modulo può essere definito come una componente dedicata a svolgere una specifica funzione. Un modulo è costituito da due parti: interfaccia (la parte visibile dall'esterno) e logica applicativa (la parte “interna” del modulo, l'insieme degli elementi che gli permettono di svolgere le sue funzioni). Un sistema è quindi composto da vari moduli che interagiscono fra di loro. I moduli e le loro interazioni costituiscono l'architettura di un sistema software. Il prodotto del progetto logico è una descrizione dettagliata dei compiti che ogni modulo deve svolgere (cosa) e del modo in cui i vari moduli comunicano fra di loro. Nulla viene detto sul come i vari moduli svolgano i loro compiti. Il progetto fisico è invece orientato a definire le caratteristiche dell’ambiente hardware e del software del nuovo sistema. Secondo l'approccio tradizionale, ad esempio, i dati possono ad esempio essere organizzati, in un modello di database relazionale e un insieme di moduli di funzioni può essere destinato ad unico applicativo associandolo anche a elementi strutturali in grado di eseguire compiti generici (ad esempio: l'accesso ai dati, trattamento degli errori). Il risultato del progetto fisico determina: q la struttura generale (componenti) del sistema informativo (in un sistema di distribuzione, ad esempio, potrà includere un componente per la definizione delle quantità ed uno per la scelta del fornitore); q i moduli di programma con i quali vengono eseguite le varie procedure aziendali (nella scelta del fornitore, ad esempio, esiste un modulo in grado di selezionare tutti i fornitori più importanti e altri che eseguono una comparazione delle condizioni e della qualità offerte); q la sequenza con la quale i singoli moduli di programma dovranno essere elaborati; q la struttura logica dei dati dell’applicazione; q la struttura fisica dei dati e dei file di dati; q i primi test di prova.

31 Fase di implementazione (programmazione)
Serve a specificare nei minimi dettagli il progetto del sistema fino ai singoli comandi nel linguaggio di programmazione prescelto e in particolare schemi di dati (descrizione della struttura dei dati, dei file o dei database) cicli di programma o funzioni rappresentati da elementi strutturali del programma sotto forma di un diagramma strutturale interfacce utente Una volta terminata la fase di progetto bisogna implementare effettivamente il programma in un linguaggio di programmazione. La fase di implementazione (o programmazione) serve a specificare nei minimi dettagli il progetto del sistema fino ad arrivare a definire i singoli comandi e a tradurli nel linguaggio di programmazione prescelto, definendo: q schemi di dati (descrizione della struttura dei dati, dei file o dei database) q cicli di programma o funzioni (rappresentati da elementi strutturali del programma, sotto forma di un diagramma strutturale q interfacce utente. Per la configurazione dell’interfaccia utente si devono prendere in considerazione i principi di ergonomia dell'hardware e del software, valutando l'impatto dei nuovi programmi sugli utenti finali e analizzando, ad esempio, quali supporti di documentazione in linea siano necessari. Per la definizione di questi elementi è opportuno fare riferimento alla normativa ISO 9241 che da un lato definisce i parametri di usabilità (e cioè il livello al quale un prodotto può essere utilizzato da utenti specifici con efficacia, efficienza e soddisfazione) e dall'altro suggerisce come le misurazioni del livello di soddisfazione dell’utente, possano essere a loro volta utilizzate per valutare come ogni componente dell’attività del sistema influenza la qualità dell’intero progetto. Rientra nella fase di implementazione anche il system test (test di sistema) mediante il quale vengono verificati l’intera applicazione ed i singoli sottosistemi che la compongono.

32 Fase di collaudo e installazione
Dopo aver verificato se il programma soddisfa tutti i requisiti tecnico/funzionali Il collaudo può dimostrare con certezza la presenza di errori, non l’assenza (a meno di fare tutte le prove possibili, approccio economicamente insostenibile) Viene, inoltre, intensificato l’addestramento degli utenti finali Nella fase di collaudo e installazione dopo aver verificato se il programma soddisfa tutti i requisiti richiesti sotto un profilo tecnico funzionale, il software viene introdotto nell’azienda. Il collaudo può dimostrare la presenza di errori, non l'assenza (a meno di fare tutte le prove possibili). L'unico collaudo ideale (per cui se vi è un errore viene sicuramente identificato) è quello che prova il sistema in tutte le condizioni, tuttavia tale approccio risulta, nella maggior parte delle esperienze, economicamente insostenibile. Nella fase di installazione viene inoltre intensificato l'addestramento degli utenti finali che sempre più spesso rappresenta un presupposto fondamentale per il successo finale del nuovo sistema.

33 Fase di manutenzione Normalmente si estende per tutta la vita del sistema Vengono apportate modifiche e adattamenti e si provvede a eliminare errori non rilevati nel test o nel collaudo di sistema Spesso le modifiche sono dettate da cambiamenti nell’esigenze dell’utente, da aggiornamenti legislativi o da variazioni nell’architettura del sistema A essa può essere imputato oltre il 50% delle spese affrontate per l’intero ciclo di vita del software (TCO, Total Cost of Ownership) Nella fase di manutenzione che normalmente si estende per tutta la vita del sistema, vengono apportate modifiche ed adattamenti si provvede ad eliminare errori che non erano stati rilevati nel test di sistema o nella fase di collaudo. Spesso tali interventi sono richiesti da cambiamenti nell'esigenze dell'utente o da aggiornamenti legislativi (ad esempio, una nuova norma nell’ambito del diritto tributario va tenuta in considerazione nel calcolo delle ritenute sulla busta paga). Inoltre, la manutenzione del programma è resa necessaria da variazioni nell'architettura del sistema, che possono essere determinate dall’introduzione di nuovi elaboratori, software di sistema o componenti di rete. Numerose ricerche hanno evidenziato come, alla fase di manutenzione, che, come detto, si protrae per molti anni fino alla definitiva dismissione del software, può essere imputato oltre il 50% delle spese affrontate per l’intero ciclo di vita del software (TCO – Total Cost of Ownership). Come detto, il principale punto debole nello sviluppo "a cascata" del software è quello di essere fortemente incentrato sulla definizione di specifiche nella fase di analisi. Tale approccio può risultare efficace solo nel caso in cui il committente sia in grado di fornire i requisiti in modo chiaro e completo all'inizio del progetto, senza ripensamenti o aggiunte successive. Spesso invece errori e modifiche necessarie sono rilevati soltanto nelle fasi successive, ritardando notevolmente il progetto nel suo complesso. Inoltre spesso la comunicazione tra il analisti e programmatori e le aree aziendale interessate al nuovo sistema non è soddisfacente, e può accadere che gli utenti finali vengano coinvolti nel processo di sviluppo soltanto in fasi marginali.

34 Prototyping Si propone di sviluppare un progetto informatico creando, il più rapidamente possibile, una versione eseguibile del sistema informativo Non si esegue un’analisi dettagliata del progetto Nello sviluppo viene coinvolto il più possibile l’utente finale Si mira a eliminare le difficoltà di comunicazione tra specialisti informatici e utenti aziendali Il prototyping si propone di sviluppare un progetto informatico creando, il più rapidamente possibile, una versione eseguibile del sistema informativo o di un suo sottosistema, senza eseguire un’analisi dettagliata del progetto, ma coinvolgendo il più possibile l’utente finale nello sviluppo del software stesso. Uno dei principali obiettivi del prototyping riguarda l’eliminazione delle difficoltà di comunicazione tra specialisti informatici e utenti aziendali. Tali problemi insorgono, di norma, poiché gli informatici (analisti e programmatori), possiedono, soltanto ristrette conoscenze relative al settore dove il sistema dovrà essere implementato, e, da parte loro, gli utenti finali vedono nell’ICT come un semplice strumento per la soddisfazione immediata di tutte le loro esigenze. Dalla stretta collaborazione tra coloro che sviluppano il software e gli utenti delle aree aziendali nasce il prototipo, che nella sua prima versione simula soltanto determinate funzioni del sistema. Basandosi su questo primo accenno di soluzione si realizza passo dopo passo l’intero sistema ma, durante tutta questa fase, è necessario che continui ad esistere una stretta collaborazione tra committenti e specialisti. L’utente ha la possibilità di esprimere i propri desideri sulla scorta del prototipo esistente e di fornire suggerimenti per apportarvi modifiche. Questo processo viene denominato anche sviluppo evolutivo del software. Sebbene tale approccio finisca col trascurare esigenze di strutturazione sotto il profilo ingegneristico, mediante un’attiva partecipazione degli utenti nel processo di sviluppo è possibile ottenere un maggior livello di accettazione nella successiva fase di introduzione del sistema, e minori costi di manutenzione.

35 Critiche al prototyping
Vengono trascurate esigenze di strutturazione sotto il profilo ingegneristico Poiché spesso alla prototipizzazione segue lo sviluppo a cascata, i costi complessivi dello sviluppo risultano elevati