I SISTEMI INFORMATIVI COME AREA DI STUDIO

Secondo Couger (1995)  i SI sono emersi come area di studio subito dopo la comparsa dei computer per uso commerciale ovvero negli anni '60.

I SI appartengono alla categoria delle scienze artificiali.

Secondo Simon, il SI è visto come un artefatto che si colloca tra realtà aziendale e realtà direzionale. Quest'ultima esercita responsabilità di indirizzo e controllo.

Secondo Simon, esistono dei criteri per qualificare un oggetto artificiale, tra questi l'essere creato dall'uomo, imitare alcuni aspetti degli oggetti naturali, caratterizzarsi in termini di funzioni e obiettivi. I SI rispondono a tutti questi elementi distintivi.

Dall'avvento del computer hanno preso consistenza tre indirizzi si studio:

la computer science

la software engineering

i sistemi informativi.

Il forte legame tra i primi due con il computer e la facile riconducibilità dei principi giuda ad algoritmi ed espressioni matematiche hanno fatto si che attorno a questi temi si delineasse  presto un carattere specifico. Per questo motivo quello che si intende, si studia e si ricerca negli ambiti di discipline come la software engineering e la computer science trova un ampio accordo.

Più complesso è stato il percorso per i sistemi informativi.

Secondo Stowell e Mingers la disciplina dei SI riguarda il compito di progettare i SI partendo da presupposti che riguardano la natura sociotecnica di questo compito. Tali presupposti si riferiscono a una particolare epistemologia circa i SI e determinano i modo in cui il sistema verrà sviluppato.

Noi sosteniamo che la fondamentale differenza tra computer science e SI è che la computer science è centrata su un paradigma funzionalista mentre per i SI bisogna considerare concetti alternativi.

Una definizione più vicina al nostro capito i interesse è fornita da Hall e Fagen che vedono il SI come un insieme di oggetti e relazioni tra questi oggetti e i loro attributi.

Alcune caratteristiche riprese da D 636h75g e Marco sono:

esistenza in un ambiente esterno ad essi

presenza di più sottosistemi

capacità di trasformare un input in output

tendenza verso un fine

entropia

La parola sistema assume spesso due significati:

il primo è quello di insieme di pari e delle relazioni tra esse, il secondo è quello di scatola nera (black box) in cui vengono introdotti dei dati. Entrambi si rivelano utili e posono coesistere tra loro.

La pratica indica che gli obiettivi di un SI sono di tipo organizzativo, come ad esempio il miglioramento delle prestazioni riferite ad una determinata area aziendale, la velocizzazione dei flussi di dati, la riduzione dei costi, il miglioramento della relazione con il cliente.

Gli aspetti sociali del sistema informatico segnano una linea di demarcazione tra la computer science e i SI nonostante facciano parte di un'unica voce.

Alcune definizioni di SI:

Buckingham (1987) definisce un SI come un sistema che raccoglie , memorizza, elabora e distribuisce informazioni che riguardano un'organizzazione in modo che l'informazione si accessibile e utile a coloro che desiderano usarla, tra questi manager, addetti, clienti e cittadini. Questa definizione continua dicendo che nel SI vi è un insieme di attività umane che può implicare o meno l'uso dei computer.

o   Quest'ultima affermazione circa la non indispensabilità del computer era molto frequente in passato. Oggi è difficile parlare di SI e non imbattersi in computer.

Reix (1988) definisce un SI come un insieme organizzato di risorse: hardware, software, personale, dati e procedure che permettono di acquisire, trattare, memorizzare, comunicare delle informazioni.

De Marco (1988) definisce il SI come un insieme di persone, apparecchiature, procedure aziendali il cui compito è quello di riprodurre informazioni che servono per operare nell'impresa e gestirla.

Secondo la UK Academy of Information Systems, lo studio dei SI e il loro sviluppo è un tema multidisciplinare e riguarda le attività strategiche, manageriali ed operative coinvolte nella raccolta, elaborazione, memorizzazione, distribuzione ed uso dell'informazione e delle tecnologie ad essa associate, sia nella società, sia nell'organizzazione.

La multidisciplinarità, sostenuta anche da Avison, è una caratteristica dei SI. Per caratterizzare la multidisciplinarità indica che negli studi e nella pratica di SI si fa spesso ricorso alla computer science, alla sociologia, al management, a cui aggiunge anche la psicologia, la linguistica, la scienza politica, la semiologia, l'etica, l'ergonomia e la matematica.

Contenuti dell'insegnamento di sistemi informativi

Nel corso degli studi sui SI abbiamo assistito a diversi tentativi a costruire un curriculum comune che permettesse di raggiungere un accordo sui contenuti minimi. È sempre stata un'impresa difficile sia per la relativa novità del tema, sia per l'evoluzione tecnologica che ha imposto schemi e argomenti al campo di studio.

I tentativi ufficiali più noti sono stati effettuati prevalentemente da associazioni accademiche, riviste di riferimento, associazioni professionali.

I primi curricula sono orientati all'utilizzo di macchine in termini di hardware e software e di sistema i successivi iniziano a distinguere la computer science e i SI.

La proposta di curriculum è preceduta da una rigorosa analisi del settore sia in termini di domanda del mercato sia data la provenienza degli studiosi promotori, e criteri di collocazione del SI nel mondo scientifico.

A questo proposito gli autori sostengono che l'ambito di studio SI copre due grandi aree:

acquisizione, impiego e gestione delle risorse e servizi tecnologici: si riferisce al fatto che ogni organizzazione ha bisogno di una funzione che si occupi di mettere a disposizione di chi ne necessita tecnologia e applicazioni.

sviluppo ed evoluzione dei sistemi per l'utilizzo delle informazione nei processi organizzativi: punto moto ricco di implicazioni. Vi  è lo stretto collegamento tra informazione e organizzazione, inoltre viene usata l'espressione system development.

Il curruculim proposto da couger, prevede una forte valenza organizzativa che va oltre gli algoritmi e il software di sistema in cui si muove la computer science e oltre alle telecomunicazioni.

Nel 1997  De Marco segnala che a volta c'è un'evidenza immediata di come il SI non sia allineato con l'organizzazione. Osservò che le organizzazioni cambiano più rapidamente nei sistemi informatici e che l'automazione, a volte diventa fattore di freno al cambiamento.

Veniva dunque riconosciuto che gli aspetti organizzativi avevano assunto un ruolo determinante e quindi tale circostanza doveva tradursi in una forte esperienza.

Nel 2002 si lavora al documento IS 2002. Dal rapporto emerge in maniera netta l'interdisciplinarità degli studi di SI.

Si tratta di 4 insiemi:

focus dell'attività e dell'organizzazione

pensiero critico ed analitico

comunicazione interpersonale e gruppi

tecnologia

dalla loro intersezione nasce il curriculum sistemi informativi.

La proposta finale di curriculum definisce come il ruolo dell'informatica personale sia diventato dominante unitamente all'attenzione al mondo e-business e all'ambiente in cui deve essere sviluppato il SI.

Linee di ricerca nei sistemi informativi

Oltre ai contenuti della didattica è utile esaminare, al fine di una migliore comprensione, anche i filoni di ricerca più seguiti.

Numerosi sono stati gli studi affrontati su questo argomento.

Keen, notò una forte presenza di temi relativi alla tecnologia.

Per quanto riguarda le metodologia di ricerca, Banbasat e Galliers figurano:

ricerca-intervento

esperimento di laboratorio

indagini

studi longitudinali

grouded theory

studi di caso

Come gia detto, riguardo alle metodologie usate prevale un approccio positivista.

Le metodologie di ricerca poi seguite sono:

indagini

esperimenti di laboratorio

studi di casi

LO SVULIPPO DEI SISTEMI INFORMATIVI

Considerazioni generali e fonti della letteratura scientifica

Ogni sistema informativo, implica che qualcuno l'abbia progettato e prodotto i termini progettare e produrre implicano l'ingegneria, ma non nel caso di un SI.

Richiamando le definizioni espresse, il SI comprende vari oggetti, attori e processi.

Per quanto riguarda gli oggetti, prevalentemente le macchine e i sistemi di connessione, il mercato offre numerose possibilità.

Con riferimento alle persone, il problema è più delicato, ma con il coinvolgimento e la formazione molti aspetti possono essere affrontati e risolti.

La parte più complessa è il software.

Il software consiste nell'insieme di programmi che venono usati in un sistema di elaborazione dati, ma anche nei supporti di memorizzazione che lo contengono.

Pressman , che è uno degli studiosi più autorevoli nel campo del software, definisce il software come istruzioni che eseguite svolgono una funzione prestabilita con prestazioni prestabilite; strutture di dati mediante le quali i programmi trattano adeguatamente le informazioni; documenti che descrivono le operazioni e l'uso dei programmi.

Il prodotto software può essere visto in due modi diversi ed ha una natura differente per chi lo sa e per chi lo produce.

L'utilizzatore vede un insieme di funzionalità che semplificano e accelerano le proprie attività lavorative; chi lo produce vede righe di programma, strutture di dati e documentazione.

Vi è anche da aggiungere che oramai la parola sfare viene sempre più raramente utilizzata.

In realtà il software non è solo ciò che fa funzionar l0hardware ma ha anche la capacità di districarsi tra i vari componenti e la rete: è il prodotto e la sua catena di distribuzione.

Il software ha anche un'altra componente immateriale e l'utilizzo di tecniche e strumenti concepiti richiede adattamenti e forzature, di conseguenza bisogna attendersi qualche risultato  non soddisfacente.

Baetjer individua alcune differenze che si riscontrano tra ciò che viene progettando e producendo il software e quanto accade in altri settori. Fa notare che il software incorpora delle conoscenze umane, ma non sono conoscenze codificare e concentrate, sono in parte tacite implicite, disperse nell'organizzazione e a volte situate all'esterno di essa.

Quindi, quando si parla di sviluppo di SI si fa riferimento soprattutto al software anche se i trascurare gli altri aspetti può essere compromettente.

Cenni sulle metodologie di sviluppo

Dentro ogni sistema, come gia affermato, c'è un intenso lavoro di progettazione del software che si è avvalso di una o più metodologie di sviluppo.

Molti studiosi hanno proposto proprie definizioni di metodologia.

Avison e Fitzgerald che ne hanno fatto di questo tema il loro costante argomento di ricerca, definiscono metodologia di sviluppo come una raccolta di procedure, tecniche, strumenti e supporti alla documentazione i quali aiutano gli sviluppatori del sistema nel loro impegno teso a realizzare un nuovo sistema informativo. Una metodologia consiste di diverse fasi che a loro volta comprndono alcune sottofasi le quali guideranno gli sviluppatori nelle scelta delle tecniche più appropriate in ogni stadio del progetto.

La definizione sembra ricca e completa anche se successivamente viene aggiunto che la metodologia è una raccolta predefinita di fasi, procedure, regole, tecniche, strumenti, documentazione management e addestramento per sviluppare un sistema.

Madison sostiene che una metodologia è un insieme organizzato di concetti, convinzioni, valori e principi normativi supportato da risorse materiali che aiutano i gruppi di sviluppo a percepire, generare, valutare e portare a temine in modo sistematico modifiche ai sistemi in una vasta gamma di contesti.

Boxane sostiene che una metodologia, per essere efficace, deve rivolgersi agli assetti che riguardano lo sviluppo dei SI in un certo ambiente. L'approccio dovrà permettere una visione chiara con un'apertura sufficiente ad accogliere le situazioni di dubbio che l'utente dovrà affrontare.

Analizzando quanto detto anzitutto va tenuto presene l'ambiente in cui si opera perché è dalla complessità di questo che ne deriva la necessita di metodologie.

Il punto di partenza di ogni sviluppo di software sono i requisiti dell'utente. Classificabili in 3 categorie:

espliciti e chiaramente espressi. L'utente ha chiaramente in mente fin dall'inizio ciò che vuole

impliciti. L'utente non esplicita perchè ne da per scontata la conoscenza

obbligatori. Sono requisiti importi dalla normativa.

L'ambiente di produzione comprende le macchine, gli strumenti di sviluppo e i sistemi operativi. A volte una nuova versione di sostare di base può comportare l'insorgere di problemi.

Di importanza centrale è il fattore umano.

E qui si pone un ulteriore problema: c'è una richiesta di regole e procedure operative accanto ad un'esigenza di libertà e creatività. Speso questo porta a rifare parti di sistema gia costruite da qualcun altro perché si ritiene di poterle realizzare meglio.

I vantaggi che si ricercano sono:

riduzione di costi di sviluppo

rispetto dei redentivi di costo e di risazio

riutilizzo di componenti

crescita della produttività

ripetibilità di procedimento

crescita professionale del gruppo di progetto.

Le osservazioni svolte finora sono prevalentemente di natura pratica, ma il tema della ragioni pro e contro il ricordo alle metodologie è centrale anche nel dibattito accademico.

Tra le ragioni a favore si fa notare che lo sviluppo dei SI è un compito complesso e l'approccio riduzionista implicito nelle metodologie può essere vantaggioso. Inoltre tutto il processo viene reso più visibile e trasparente e quindi la gestione del progetto diventa più agevole.

Accanto a queste ragioni ci sono anche pressioni esterne, come l'esigenza di conseguire una certificazione ISO e le commesse degli enti pubblici che spesso richiedono esplicitamente ai fornitori l'adozione di una metodologia riconosciuta.

Tra i fattori contrari all'utilizzo di metodologie, Baskerville indica la rapidità dei mutamenti del mercato la quale richiede tempi brevi di realizzazione. Le metodologia invece portano spesso a tempi di sviluppo prolungati.

I requisiti vengono identificati fin dall'inizio e sulla base della esazione di un determinato manufatto, è possibile prefigurare esattamente come sarà il prodotto finale.

Nella realizzazione dei software i "veri" requisiti sono spesso inespressi ed emergono nella fase di progettazione.

Nel software anche la fare di test richiede creatività. Il decidere quali possibili errori e casi è necessario prendere dipende molto dalla fantasie dall'esperienza del progettista, a differenza del collaudo di manufatti dove invece il test è ben codificato.

Evoluzione delle metodologie di sviluppo

I primi SI sono stati sviluppati senza l'aiuto di metodologie. Ovviante si può sostenere che una metodologia se pur in modo consapevole viene sempre adottata per portare a termine qualsiasi lavoro.

Un modo per esprimere un processo di sviluppo condotto in assenza di metodologie è riassunto nell'espressione code and fix. Che si radice come "scrivi righe di codice e poi correggi in errore".

Numerosi SI sono stati sviluppati in questo modo anche se con rilevanti limiti di funzionalità.

Per illustrare l'evoluzione delle metodologie, si identificano tre ere.

Premethodology era, early methodology era e methodology era

Nella così detta era premetodologica, lo svulippo del SI avveniva in assenza di metodologie predefinite. Le dimensioni e il numero di persone coinvolte e i vincoli di costi obbligano a seguire dei metodi che oggi forse non sono più considerati validi.

Un bravo programmatore era infatti una condizione indispensabile per condurre un progetto al successo.

La fase successiva che inizia negli anni 70, è chiamata early methodology era. Fu l'epoca in cui vennero realizzati progetti di grandi di mansioni che hanno permesso di automatizzare attività complesse come ad esempio le contabilità di grandi aziende.

A partire dalla metà degli anni 80 entriamo nel pieno dell'era delle metodologie. Metodologie di quest'epoca vendono divise secondo sette aree tematiche dette anche approcci. Per esempio quella strutturata, quella a prototipi e quella sistemica.

La metodologia strutturata riproponeva alcuni concetti della programmazione strutturata e li applicava alle fasi di analisi e progetto.

Quella di prototipizzazione che mediante il ricorso a prototipi, semplifica la comunicazione tra utente della procedura e progettista del software.

Infine quella sistemica, che cerca di tener conto delle attività umane nel loro complesso e di adottare una visione ampia.

La fase odierna è denominata era of methodological reassessment ed è caratterizzata dalla valutazione di una serie di esperienze e ragioni dovute anche al fatto che oggi con le metodologie si costruiscono prodotti diversi da quelli di una volta. Si registrano forti critiche nei confronti delle metodologie tradizionali.

Oggi sembra prevalere un ricorso a metodologie ad hoc. Spesso la realtà è più complessa di come la si può interpretare.

LE METODOLOGIE TRADIZIONALI

Modello sequenziale lineare

L'approccio tradizionale da per scontato che i requisiti siano determinabili in maniera univoca e permanente.

Gran parte dei progetti di grandi dimensioni, presuppone un approccio in cui vengano individuate e descritte in dettaglio tutte le funzionalità che il sistema deve possedere.

Tra questi approcci il più noto è il cosiddetto waterfall o a cascata, nel quale si riscontrano molti principi dell'ingegneria industriale.

Si tratta di un modello sequenziale lineare che prende l'avvio da uno studio d fattibilità per poi procedere con l'analisi, la progettazione, la codifica, il collaudo e l'inserimento nel sistema.

Il modello a cascata prevede una serie di fasi.

Il termine implementazione per alcuni significa solo la codifica, cioè la realizzazione del software applicativo necessario, mentre per altri ha un significato più vasto e equivale alla messa in opera del prodotto.

Lo studio di fattibilità viene quasi sempre volto. In realtà quando i opera in un ambiente conosciuto e si automatizzano compiti ben definiti, questa fase può essere effettuata in modo completo, ottenendo risultati attendibili.

Segue la fase di analisi dei requisiti dell'utente il cui risultato è un documento che deve contenere un piano di test di accettazione e descrive in maniera esplicita l'interfaccia con l'utente. Questo documento, dopo essere approvato dall'utente che talvolta però non è in grado di comprendere i contenuti del documento e neppure è nelle condizioni di dichiarare la propria formale approvazione senza aver effettuato un'analisi approfondita.

La fase denominata progettazione prevede la definizione dei requisiti software e del modello logico del sistema, oltre che di un pano di test del software.

La fase di progettazione si suddivide in progettazione logica, in cui si descrivono le finzioni indipendentemente dai supporti, e progettazione fisica in cui si specificano in modo dettagliato le caratteristiche del prodotto.

Segue quindi nell'ambito della stessa fase la definizione delle architetture.

Nella progettazione del software, si possono distinguere quattro tipi di architettura:

funzionale : serve a descrivere i servizi che il sistema mette a disposizione delle diverse categorie di utenti. Ad una persona addentro ai problemi dell'organizzazione in esame, il quadro dell'architettura funzionale è molto indicativo circa i servizi che verranno resi disponibili a fine progetto.

applicativa o esecutiva : in essa si mostrano con quali componendi software vene costruita l'applicazione senza indicare le scelte commerciali e quindi i prodotti ma limitandosi a descrivere le funzionalità.

tecnologica : entra in maggiori dettagli indicando il tipo di prodotti specifici che si intendono usare. Ad esempio, i sceglie un browser, un web server, un application server e dei protocolli per la gestione dei servizi applicativi.

di svulippo: la quale rappresenta il odo in cui si realizza il prodotto; sono indicate le macro-fasi principali e le interrelazioni tra queste e i prodotti dello sviluppo.

La fase di codifica prevede la realizzazione vera e propria del software ovvero la scrittura dei programmi e la progettazione dei caddi test relativi a ciascun modulo applicativo. In questa fase l'impegno principale riguarda gli aspetti tecnici.

Segue la fase di test in cui si possono distinguere quattro tipi principali di verifiche e validazione:

test della singola unità

test di integrazione con il resto del sistema

test di sistema

test di accettazione

Dopo questa fase, si effettua il rilascio. Questa fase vede sempre un notevole coinvolgimento da parte dell'utente, mentre nelle fasi precedenti il grado di partecipazione è può variare in modo sostenibile.

Segue quindi la cosiddetta fase di manutenzione. Secondo De Marco, la manutenzione è tutto ciò che comporta modifiche all'esistente, anche aggiunte di prestazioni e ciò è poco confacente al significato cha attribuiamo in genere al termine manutenzione.

Manutenzione consiste in:

correzione di errori

modifiche richieste all'esterno

modifiche richieste all'interno

aggiunte

nel corso del ciclo di vita del software non deve quindi sorprendere che la manutenzione incide per il 40% sui costi complessivi.

L'approccio a cascata nasce come reazione al "code and fix", si prevede una progressione in cascata e fasi in rigorosa sequenza, non sono previsti i cosiddetti feedback loop, ovvero ricicli.

La sovrapposizione tra le fasi è minima: è necessario aver completato una fase prima di passare alla successiva.

I vantaggi dell'approccio a cascata:

obbligo per chi lavora di seguire in ogni passo dei processi strutturati

Il miglioramento della qualità

Minor rischio di tralasciare qualche funzione importante

Svantaggi:

eccessiva produzione di documentazione

tempi troppo lunghi che trascorrono dalla concezione alla realizzazione del sistema

interazione tra utente e sviluppatore avviene all'inizio e alla fine del progetto. L'utente non ha visibilità delle fasi intermedie e quieto è particolarmente limitativo.

La metodologia waterfall ha dato un grande contributo alla definizione di molti concetti come: fasi, prodotti parziali, portata dell'analisi e del progetto. Anche per questo è facilmente applicabile ed è stata un importante punto di partenza per lo studio del modo si portare avanti progetti software.

Ciclo di vita prototipale

Questo approccio alternativo a quello waterfall, prevede lo svulippo rapido di una serie di prodotti software con l'obiettivo di definire meglio (strada facendo) i requisiti. Scopo del prototipo è spesso quello di identificare i requisiti nascosti che sono quelli che l'utente da per scontati o quelli i cui non ha percezione.

Inoltre, il compito del prototipo può essere quello di verificare la validità di determinare architetture tecnologie.

Le indicazioni all'interno dei blocchi che rappresentano le fasi principali sono chiaramente esplicative.

La raccolta dei requisiti è fondamentale. A questa raccolta segue quello che viene denominato quickdesign, uno svulippo rapido del prototipo: a questo punto fondamentale diventa il cosiddetto feedback, cioè la risposta e la validazione da parte dell'utente che è il perno dell'approccio prototipale.

Uno degli scopi del prototipo è aiutare i cosiddetti requisiti non funzionali.

Requisiti sono:

funzionalità: cosa il software deve poter eseguire per soddisfare i requisiti per i quali è stato progettato

affidabilità: capacità di mantenere un appropriato livello di prestazioni anche in presenza di errori o malfunzionamento di interfacce.

usabilità

efficienza: rapporto tra le prestazioni del prodotto e risorse necessarie per ottenerle

manutentabilità

portabilità: caratteristica per la quale il prodotto può essere trasferito da un ambiente all'altro senza apportare modifiche.

I prototipi possono essere di due tipi:   

non riutilizzabili detti anche throwaway (usa e getta) :tipico di quando si procede in attività di svulippo in ambiente web

costruiti intorno a un nucleo del prodotto che va ampliato detti anche evolutionary

Rapid Application Development

Il RAD è un adattamento del ciclo di cascata, avente lo scopo di permettere un ciclo di sviluppo abbreviato. La sua nascita risale al cosiddetto Rapid Interactive Production Prototyping una metodologia nata nel mondo delle aziende per accorciare i tempi di produzione dei SI.

Per ottenere la rapidità dello svulippo si fa ricorso a tecniche costruttive basate sul riutilizzo di componenti.

Il vantaggio dei tempi brevi, oltre a quello di poter obbligare una partecipazione costante dell'utente, è quello che i requisiti risultano più stabili.

Il ricorso a metodologie RAD avviene secondo alcune fasi:

business modeling : in cui si effettua l'analisi dei processi esistenti e il flusso dei dati tra le varie funzioni aziendali

data modeling: in cui si scrivono le strutture ei dati e le relazioni fra essi

process modeling in cui si indicano le trasformazioni che i dati subiscono per poter ottenere informazioni

application generation: fase in cui il RAD si differenzia in moo netto rispetto alle altre metodologie.

Testing and turnover: in cui i collauda il sistema e lo si mette in funzione.

Il RAD prevede la scomposizione del sistema in sottopostemi di dimensioni ragionevoli per poter rispettare i tempi, quindi a differenza dello sviluppo waterfall dove vi è un unico gruppo di lavoro che progetta e produce l'intero sistema qui operano più team di sviluppo.

Ciclo di vita ad approccio evolutivo

Le tre metodologie esposte sono orientate ciascuna ad un aspetto specifico del problema delle svulippo di un SI. La waterfall segue uno sviluppo lineare con i pro e i contro che si è visto.

I cicli di vita ad approccio evolutivo sono particolarmente adatti a tenere conto della natura mutevole del software. L'approccio evolutivo prevede uno sviluppo iniziale fino alla fase di messa in funzione e continui sviluppi fino a giungere ad un prodotto finale.

Alla fine della prima iterazione si ottiene il prodotto finito il quale è a disposizione dell'utente ed è stato realizzato in tempi rapidi.

Questa è la grande differenza rispetto alle metodologie prototipale che invece prevede un solo rilascio alla fine del processo.

Le metodologie evolutive di caratterizzano per la frequenza di rilasci, ciascuno dei quali viene arricchito di nuove funzionalità ma viene anzitutto provato nell'ambiente tecnologico ed operativo dove dovrà funzionare ed è infatti solo un questo modo che si può avere la certezza della validità di cio che è stato realizzato.

Le metodologie che possono essere inserite in questa categoria sono:

Incrementale :punti di forza di questa metodologia riguardano una maggiore rispondenza del prodotto alle esigenze espresse ed inespresse dell'utente. E la possibilità di iniziare dalle parti più critiche nelle quali la verifica con gli utilizzatori del sistema è maggiormente necessaria. Inoltre il prodotto finale è più facile da ingenierizzare e da documentare, grazie alla documentazione controllabile.

a spirale: ogni incremento è una ripetizione ciclica di alcune task region. Queste includono la comunicazione con l'utente quindi tutte le attività destinate a comprendere i requisiti e le funzionalità. Segue la pianificazione e l'analisi dei rischi. La caratteristica fondamentale di questa metodologia è la flessibilità. Si trovano infatti in essa i principi dello sviluppo a cascata, di quello prototipale e di quello evolutivo e ti quello incrementale. Non è molto diffusa in quanto richiede elevate competenze.

CBM : si basa sul ciclo di vita a spirale on cui però si ricorre all'utilizzo di componenti preconfezionati.

Current engineering: (modello di sviluppo). Muove della costatatone che in un progetto di grandi dimensioni in ogni momento ci possono essere più fasi aperte e che quindi più persone sono attive allo steso tempo nelle attività di analisi, progettazione, test e altro. Presenta un altro tentativo di governare progetti ad alta complessità come lo sviluppo di software.

Processi di sviluppo

Il ciclo di vita comprende tutte le attività necessarie per lo sviluppo di un sistema dall'ideazione alla dismissione.

All'interno del ciclo di vita c'è dunque il ciclo di sviluppo che prevede passi, fasi ed attività per la realizzazione del sistema. Nell'ambito di questo percorso, il processo di svulippo indica i mezzi gli strumenti.

Alcuni processi di svulippo di larga diffusione sono:

Unified Process (UP): è un processo di sviluppo del software. Si basa su alcuni assunti fondamentali. Il ricorso agli USE CASE che descrivono come un attore interagisce con un sistema per ottenere un determinato risultato. Un altro è l'adozione di una serie di tecniche per affrontare e gestire i rischi in tute le fasi dello svulippo. Durante ciascuna iterazione vengono svolti alcuni cicli di attività denominati workflow di cui alcuni principali e alcuni di supporto:

i workflow principali sono:

business modeling

requirements

analysis design

implementazione

test

development

workflow di supporto

configuration and ch'ange management

project management

environment

Enterprise Unified Process (EUP)

COTS (commercial off-the-shelf) : prodotti applicativi pronti all'uso.

Ciclo di vita e processi di sviluppo

I termini ciclo di vita , ciclo di svulippo, metodologie di svulippo, processo di svulippo vengono spesso citati in modo ambiguo e in contesi diversi fino ad apparire intercambiabili tra loro.

I principi di base dello sviluppo software ossono essere messi in pratica in modo diverso a seconda dei requisiti e della piattaforma teologica, di qui nascono le diverse metodologie.

Esistono delle pratiche, estate e verificare le quali sono adottate in dipendenza delle caratteristiche ambientali e delle dimensioni del progetto. Le pratiche e i metodi determinano il processo di sviluppo il quale è sempre molto adatto al progetto in corso.

La dimensione dei progetti incide sul livello di conformità agli standard e questo è ovvio in quanto piccoli sviluppi con scarsa interazione con il resto del sistema possono prescindere dagli standard rigorosi, mentre progetti complessi con gruppi di lavoro numerosi e professionalità diversificate devono seguire gli standard in modo puntuale e preciso.

METODOLOGIE AGILI, OUTSOURCING E METODOLOGIE WEB

Metodologie agili

La nascita delle metodologie "agili" risale tra la fine degli anni 80 e l'inizoi degli anni 90. Quegli anni sono stati particolarmente segnati dalla disponibilità e dalla diffusione di internet con la conseguente crescita del numero di aziende focalizzate sul mondo web.

Mentre fino a quel momento i te mi previsti per la creazione e il rilascio di sistemi erano di mesi, o di anni, con l'aumenti di itnernet si è cominciata a sentire l'esigenza di metodi capaci di far fronte nel giro di poche settimane alle nuove necessità dettate dal mercato.

Lo sforzo di trovare una soluzione che permettesse di rilasciare sistemi in qualità di tempi contenuti, con la minor dipendenza possibile dai singoli programmatori, ha portato alla sviluppo di sistemi di produzione del software definiti "agili".

I principi fondamentali di questo approccio sono stati racchiusi in un manifesto pubblicato da Beedle.

I quattro punti essenziali sono:

gli individui e le loro interazioni sono molto più importanti rispetto ai processi e agli strumenti.

il software che funziona possiede maggior valore di una documentazione completa.

la collaborazione con l'utente è più importante della negoziazione dei contratto.

adattarsi al cambiamento ha più valore del seguire un piano strutturato. L'obiettivo deve essere un sistema che soddisfi le esigenze dell'utente e non si limiti a una formale aderenza al piano iniziale.

L'agile manifesto articola questi punti principali in 12 principi altrettanto fondamentali:

la priorità più alta è soddisfare l'utente attraverso una fornitura in breve tempo e continua di software che abbia valore. (il tempo è diventata una variabile molto importante)

accogliamo le richieste di cambiamento anche in fase avanzata del processo di sviluppo. I processi agili utilizzano il cambiamento per il vantaggio competitivo del cliente.

sforzarci di rilasciare frequentemente (con cadenza quindicinale o bimestrale) del software funzionante, con una preferenza per l'intervallo più breve. (si applica un processo non a cascata ma iterativo, a spirale e con cicli brevi che forniscono ogni volta un software funzionante da integrare con il precedente)

gli utenti e sviluppatori devono lavorare insieme al progetto ogni giorno. (imp. Per fornire i requisiti di partenza, e valutare l'importanza economica della varie funzioni)

costruire progetti attorno ad individui motivati. Dare a loro l'ambiente e il supporto di cui hanno bisogno e fidarsi del fatto che facciano il lavoro.

il metodo più efficace ed efficiente di trasmissione di informazione al team di sviluppo e all'interno di esso è la conversazione faccia a faccia.

il software che funziona è la principale misura di progresso

i processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti, dovrebbero essere in grado di mantenere un passo costante indefinitamente.

l'attenzione continua all'eccellenza tecnica e alla buona progettazione aumenta l'agilità

la semplicità è essenziale

le architetture, le richieste e le modalità di progettazione migliori emergono da team auto-orgnaizzati.

a intervalli regolari, il team riflette su come diventare più efficace, quindi corregge e aggiusta il suo comportamento secondo quanto deciso.

Altri principi fondamentali che vengono applicati dalle metodologie agili, anhce se non citati nel manifesto sono:

conoscenza tacita : stabilire ed aggiornare la conoscenza del progetto nella mente dei partecipanti.

pair programmino : fa riferimento ad uno stile di programmazione del quale 2 programmatori lavorano fianco a fianco collaborando continuamente alla progettazione dello stesso algoritmo, codice o test.

Testing: continua e puntuale verifica automatica del corretto funzionamento.

Non tutte le metodologie che si definiscono agili si basano nella piena aderenza a tutti i principi fondamentali contenuti nel m,manifesto, ma è anche chiaro che una minore attenzione verso la produzione non equivalgono ad applicare una metodologia agile.

Le metodologie agili presentano dei limiti alla loro applicazione. Funzionano in maniera più efficace su piccoli progetti o sotto-progetti, con gruppo di lavoro di 20 persone al massimo. Inoltre sono indicate principalmente in progetti dove le caratteristiche dell'ambiente e i requisiti richiesti dall'utente mutano continuamente e i team di sviluppo sono costretti a seguire l'evoluzione di questi cambiamenti.

Affinché una metodologia agile possa essere applicata proficuamente, si rende poi necessari l'accettazione culturale della razionalità agile nell'organizzazione.

È importante anche che il manager condivida l'idea che due persone che lavorano assieme possono essere più produttive e adattarsi più rapidamente ai cambiamenti rispetto a due persone che lavorano indipendenti.

SCRUM

Scrum è una metodologia basata sul concetto che lo sviluppo del software non è definibile teoricamente, dal moment che si tratta di un processo empirico caratterizzato da complesse trasformazioni input/output che potrebbero ripetersi o meno a fronte di differenti circostante.

Il nome deriva dal gioco del rugby, nel quale ogni squadra deve essere veloce a contrastare le spinta dell'altra squadra.

Scrum concentra in particolare sul management di progetto.

Si basa si un ciclo fondamentale di sviluppo di 30 giorni (sprint) che p preceduto dall'attività pre-sprint e seguito dalla attività post-sprint.

Un breve incontro giornaliero (meno di 30 minuti) permette al gruppo di sviluppo di controllare costantemente lo stato del progetto e di comunicare eventuali problemi.

La pianificazione è basata su in product backlog, che formalizza l'incremento di funzioni e tecnologia previsto da progetto.

Scrum offre un metodo per introdurre le metodologie agili in un ambiente disciplinato secondo criteri tradizionali. Usando questa metodologia per sviluppare uno o più componenti del sistema, il management può rendersi conto della sua efficacia, senza cambiare completamente le consuete modalità di lavoro.

XP (eXtreme Programming)

XP è la metodologia agile più conosciuta.

È basata su quattro valori fondamentali e su un insieme di 12 raccomandazioni pratiche.

1. comunicazione

2. semplicità

3. feedback

4. coraggio

Il lavoro viene eseguito da piccoli gruppi che prevedono la presenza costante di un rappresentante dei clienti.

XP comincia con il planning game in cui il cliente e gli sviluppatori negoziano le richieste nella forma di "storie" scritte su apposite index card.

Il fondamentale ciclo breve non supera le tre settimane. Il processo tecnico è fondato sulla proprietà collettiva del prodotto.

Tutto ciò viene ottenuto attraverso una progettazione semplice, la programmazione a coppie e la progettazione continua del lavoro gia fatto.

Gli standard di codifica vengono stabiliti dal team mentre la qualità è assicurata dall'adozione continua del nuovo codice con quello scritto in precedenza.

Un passo sostenibile dell'avanzamento del progetto è raggiunto impegnando ogni persona in non più di 40 ore lavorative a settimana.

Outsourcing

L'outsourcing è uno dei temi più trattati dagli studiosi di SI.

Ci si propone di esaminare le modalità di acquisizione del software, quindi non si analizza l'outsourcing in generale ma sotto due aspetti:

sotto l'acquisizione del software, escludendo tutte le altre forme di outsourcing

si esamina solo il momento della selezione

Ci sono due aspetti da considerare nella selezione del software:il fornitore e il prodotto. La necessità di analizzare il fornitore nasce dal fatto che è necessario un servizio di supporto e di manutenzione che può protrarsi nel tempo.

Ci sono società di consulenza che aiutano gli utenti a selezionare il software, utilizzando in genere schemi molto simili tra loro per valutare il fornitore. Questi schemi richiedono di raccogliere i dati sul fatturato e sul numero di addetti, quest'ultimo dato è utile per comprendere se il fornitore produce il software oppure lo acquista da terzi e lo rivende.

L'esistenza di join-venture e di partnership con aziende solide è un altro fattore che induce l'ottimismo sull'impegno dell'azienda a continuare a investire sul prodotto.

Vi è poi da comprendere il posizionamento del prodotto nell'ambito della strategia del fornitore.

Una volta ottenute queste informazioni si procede all'esame degli altri aspetti, tra cui le caratteristiche funzionali di affidabilità del fornitore e di prezzo.

Quando si parla di affidabilità del fornitore vanno aggiunte le competenza funzionale e tecnica.

Si procede quindi alla valutazione delle funzionalità del prodotto. L'architettura della soluzione è un fattore molto importante perché può essere coerente o meno con il resto del sistema. C'è poi la copertura funzionale, ovvero quante delle funzioni richieste vengono soddisfatte dal software che ci si appresta ad acquistare.

Quando si parla di outsourcing di un prodotto software si presuppone che esso vada ad inserirsi in un insieme più grande che è costituito dal sistema informativo in essere.

Riguardo agli aspetti contrattuali c'è chi tende a includerli tra le funzionalità del prodotto ecco perché i livelli di servizio, le limitazioni di responsabilità, la durata del contratto e la flessibilità dei termini contrattuali vengono considerati elementi di giudizio del software che si sta per acquisire.

L'eventuale manutenzione evolutiva deve essere prevista per una certa circa per punto funzionale; va anche accettata l'idea di prevedere uno scostamento tra preventivo e consuntivo, in quanto particolari condizioni di difficoltà possono emergere solo in fase di esecuzione del lavoro.

L'assistenza presenta parametri particolari: c'è la stabilità del personale del fornitore che per l'utente è un elemento importante, la disponibilità delle persone per la loro qualifica, l'accessibilità agli specialisti espressa in percentuale rispetto al tempo di funzionamento ed infine il tempo di reperimento medio per figura professionale.

La procedura di selezione appena descritta comporta in se un rischio notevole: l'insufficienza grave relativa ad una delle caratteristiche può non essere compensata da valori elevati su altre.

Per questa ragione la costruzione di una tabella che riposta da un lato l'elenco delle caratteristiche con le metriche per la valutazione e dall'altra i vari prodotti in esame con i relativi punteggi è valida solo se utilizzata con criterio e il giudizio deve essere alla fine complessivo e indipendente dal voto assegnato.

Vantaggi dell'acquisizione di pacchetti software:

software esiste gia pronto e può essere gia provato

si riducono i temi di analisi, progetto e programmazione

un software acquistato è sempre dotato di documentazione e verrà mantenuto.

Svantaggi:

dipendenza da una terza parte che ha i sui interessi e le sue priorità

presenza di limiti funzionali che ostacolano l'operatività dell'acquirente

difficile per un singolo acquirente ottenere degli arricchimenti funzionali e miglioramenti se non sono necessari anche ad altre aziende.

Banche dati e sistemi informativi

Le banche dati e gli altri sistemi informativi statistici sono a carattere tematico e forniscono una visione globale e accurata del fenomeno indagato. L'accesso è libero e gratuito.
Le banche dati sono magazzini in cui l'utente può scegliere in base alle proprie esigenze il tipo di dati e il loro livello di dettaglio e costruire le proprie tabelle in maniera personalizzata.
I sistemi informativi contengono informazioni e dati strutturati in tavole preconfezionate e scaricabili su foglio elettronico.
Ogni banca o collezione di dati è corredata di metainformazioni (metodologie, classificazioni, definizioni) relative all'argomento trattato.