BASI DI DATI TEORIA PDF

# 1. INTRODUZIONE La progettazione ed il successivo utilizzo di una base di dati, costituisce soltanto una delle componenti del processo di sviluppo di un sistema informativo complesso e va quindi inquadrata in un contesto più ampio. Per comprendere le basi di dati e l'utilizzo moderno dei linguagg...

# 1. INTRODUZIONE La progettazione ed il successivo utilizzo di una base di dati, costituisce soltanto una delle componenti del processo di sviluppo di un sistema informativo complesso e va quindi inquadrata in un contesto più ampio. Per comprendere le basi di dati e l'utilizzo moderno dei linguaggi che ne permettono l'accesso e la gestione, facciamo una breve introduzione di alcuni concetti fondamentali. ## Algoritmo L'algoritmo è una rappresentazione di una strategia risolutiva per un problema. Si inizia da un problema (esigenza) e si identificano i passaggi che effettuati conducono alla soluzione. ## Programma Il programma è la codifica dell'algoritmo in un linguaggio di programmazione, eseguibile su un computer. ## Linguaggi di programmazione I linguaggi di programmazione sono la base dello sviluppo software. Servono a comunicare in modo semplice le istruzioni ai computer e di conseguenza, sviluppare l'algoritmo. Un linguaggio di programmazione è una lingua formale pensata per realizzare set di istruzioni (input) con cui si producono dati in uscita (output). Convertono i concetti astratti dell'uomo in codice macchina, ovvero la lingua con cui opera il computer. Tutti i sistemi informatici moderni lavorano tramite una serie di direttive comunemente chiamate codice binario. ## Software Un *software* è un programma informatico (insieme di algoritmi, implementati in uno o più linguaggi di programmazione) in grado di eseguire una sequenza logica di comandi in un computer o in un qualsiasi macchina e dispositivo elettronico programmabile. Qualsiasi computer (device) è composto da due parti: l'hardware e il software. Il software è la parte non materiale, cioè la struttura logica o meglio, le istruzioni che consentono al computer o ad un programma di funzionare. Qualsiasi dispositivo programmabile ha un software all'interno. Il *sistema operativo* di un device permette: - gestione delle risorse di sistema (utilizzo della CPU e della memoria) - gestione dei componenti hardware (CPU, RAM, hard disk, periferiche) - gestione dei programmi in esecuzione (detti *processi*) - accesso ai file (la parte del sistema operativo che si occupa di ciò è detta *file system*). ## Firmware Il firmware è un software integrato nei dispositivi elettronici da parte del produttore del componente hardware. Viene caricato in memoria all'accensione del dispositivo (periferica, computer, ecc.) e normalmente non è modificabile dall'utente. ## Driver I *driver* sono procedure che consentono di far funzionare un determinato componente hardware o periferica ( es. stampante, scanner, ecc. ). Senza la presenza del driver il sistema operativo non sarebbe in grado di comandare il corretto funzionamento del dispositivo. ## Videogiochi I videogiochi sono programmi e applicazioni sviluppati a finalità ludiche. Sono considerati a tutti gli effetti applicativi perché sono programmati sviluppati per una particolare funzione (scrittura di testi, elaborazione di immagini, creazione di video, elaborazione di audio, etc.). Esempi di software applicativo sono programmi come Word, OpenOffice, PhotoShop, Firefox, Google Chrome, etc. ## Sistemi informativi *Sistemi informativi* (software). L'uso del termine "sistema" enfatizza i prodotti software complessi. Sono costruiti o studiati in termini di macro-componenti, della loro organizzazione e delle loro interazioni. Il software viene creato da tecnici specializzati chiamati *programmatori* o *sviluppatori* (in inglese developer). Il termine *programmatore* è abbastanza intuitivo in quanto il software è composto da uno o più programmi. Il termine sviluppatore lo è un po' meno. In informatica con il termine "sviluppo software" si intende tutta una serie di attività (analisi del problema, scrittura delle specifiche, scrittura del codice, correzione degli errori, collaudo dei programmi, ampliamento delle funzionalità) necessarie per la creazione di uno o più programmi. I sistemi software complessi in realtà hanno bisogno di più tipi di sviluppatori che programmano una determinata porzione di applicativo. I programmatori scrivono il codice dettando le modalità di comportamento al software ma anche definendo la veste grafica del programma. Ma tali indicazioni per progetti complessi non possono essere immaginate dai programmatori stessi. Per un prodotto di SUCCESSO non sono più necessari ESCLUSIVAMENTE programmatori, ma serve anche tanto altro. Per un'azienda, una startup o un libero professionista, per effettuare le proprie attività in modo corretto ed efficace sono essenziali: - la disponibilità delle informazioni - la capacità di gestione di tali informazioni. Da sempre è stato necessario in base all'esigenza un proprio *sistema informativo* (non necessariamente software). ## ESEMPIO: Archivi bibliotecari. Un **sistema informativo**: organizza e gestisce le informazioni necessarie per perseguire gli scopi dell'organizzazione stessa. Più alta è la sistematizzazione dei processi maggiore è stata l'individuazione di opportune forme di organizzazione e codifica delle informazioni. Il sistema informativo di un'organizzazione è una combinazione di risorse, umane e materiali, e di procedure organizzate per la raccolta, l'archiviazione, l'elaborazione e lo scambio delle informazioni necessarie alle attività operative (informazioni di servizio), alle attività di programmazione e controllo (informazioni di gestione), e alle attività di pianificazione strategica (informazioni di governo). ## Sistema **Sistema**: esiste un insieme organizzato di elementi, di natura diversa, che interagiscono in modo coordinato. ## Informativo **Informativo**: si precisa che tutto ciò è finalizzato alla gestione delle informazioni e quindi le interazioni che preme evidenziare sono quelle dovute a scambi di informazioni (flussi informativi). All'interno di un'azienda è auspicabile che sia possibile individuare il sistema informativo in forma esplicita. In questo caso, il sistema informativo aziendale risulta composto dai seguenti elementi: - un patrimonio di dati, con cui produrre le informazioni - un insieme di procedure (automatiche o meno) - un insieme di strumenti (automatici o meno) - un insieme di persone (risorse umane) che gestiscono le procedure - un insieme di regole organizzative e gestionali. Se ci focalizziamo su un sistema-azienda, dunque, possiamo fornire la definizione di *sistema informativo aziendale*, come l'insieme di persone, risorse, macchine che trattano dati allo scopo di produrre informazioni a supporto delle operazioni e delle decisioni aziendali. È possibile distinguere all'interno di un'azienda: ## Sistema informativo operativo *Sistema informativo operativo*: riguarda l'insieme delle operazioni che fluiscono all'interno dell'azienda tra più processi e/o tra processi interni ed ambiente operativo esterno; ## Sistema informativo decisionale *sistema informativo decisionale*: riguarda l'insieme di informazioni necessarie per guidare i singoli processi operativi nel loro divenire. # 2. CICLO DI VITA DI UN SOFTWARE Il ciclo di vita di un software è il periodo di tempo che: - inizia quando un prodotto software viene concepito - termina quando il prodotto software non viene più usato. Lo sviluppo software è un processo complesso. - Implica l'interazione tra cliente e produttore - devono essere definiti i requisiti del prodotto - deve essere realizzato il prodotto richiesto con le tecnologie, il tempo e le risorse economiche a loro disposizione. Di seguito alcune delle principali categorie di metodologie per lo sviluppo del software: ## Modello a cascata (Waterfall) Progetto suddiviso in fasi sequenziali (analisi requisiti, disegno applicazione, codifica applicativo, test funzionale, rilascio in produzione) ## Modello a cascata ibrido (Hybrid Waterfall) Progetto suddiviso in fasi che possono essere sovrapposte. ## Modello incrementale Consegna ciclica di insiemi ridotti di funzionalità. ## Modello iterativo Progetto costituito da tanti brevi cicli sottoposti all'approvazione del cliente. ## Agile Insieme di metodologie incrementali ed iterative. Il ciclo di vita software comprende generalmente le seguenti attività: ## Studio di fattibilità Serve a definire, in maniera per quanto possibile precisa, i costi delle varie alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del sistema. ## Raccolta e analisi dei requisiti Consiste nell'individuazione e nello studio delle proprietà e delle funzionalità che il sistema informativo dovrà avere. Questa fase richiede un'interazione con gli utenti del sistema e produce una descrizione completa, ma generalmente informale dei dati coinvolti e delle operazioni su di essi. Definiti requisiti software e hardware. ## Progettazione Si divide generalmente in progettazione dei dati e progettazione delle applicazioni. La prima ha lo scopo di individuare la struttura e l'organizzazione che i dati dovranno avere. Nell'altra si definiscono le caratteristiche dei programmi applicativi. Le due attività sono complementari e possono procedere in parallelo o in cascata. Le descrizioni dei dati e delle applicazioni prodotte in questa fase sono formali e fanno riferimento a specifici modelli. ## Implementazione Consiste nella realizzazione del sistema informativo secondo la struttura e le caratteristiche definite in fase di progettazione. Viene costruita e popolata la base di dati e viene prodotto il codice dei programmi. ## Validazione e collaudo Serve a verificare il corretto funzionamento e la qualità del sistema informativo. La sperimentazione deve prevedere, per quanto possibile, tutte le condizioni operative. ## Funzionamento In questa fase il sistema informativo diventa operativo ed esegue i compiti per i quali era stato originariamente progettato. Se non si verificano malfunzionamenti o revisioni delle funzionalità del sistema, questa attività richiede solo operazioni di gestione e manutenzione. In questa metodologia, il processo scorre sempre dall'alto verso il basso, in un'unica direzione e prevede una successione di fasi consecutive. Da qui il nome Waterfall (cascata). Ciascuna fase produce dei semilavorati (deliverables), cioè documenti relativi al processo, oppure documentazione del prodotto e codice sorgente o compilato, che vengono ulteriormente elaborati dalle fasi successive. ## FASI Ogni fase: - ha un obiettivo definito - si basa sui risultati della fase precedente. Le fasi corrispondono ad attività che trasformano i loro ingressi in uscite - presuppongono la verifica ai milestones. ## MILESTONE È un evento predefinito che serve a misurare il progredire dello sviluppo. Prevede: - normalmente la consegna dei prodotti (intermedi) detti deliverable - un esame (review) formale. ### Il modello a cascata: - Presume che sia possibile definire esattamente quali sono i requisiti del sistema - Presume che i requisiti siano stabili (MA I REQUISITI NON SONO STABILI). ## La problematica nasce dalle traduzioni in tale contesto dei processi manifatturieri tradizionali. ## Problemi del ciclo a cascata. Tende a sposare in avanti le verifiche, con il conseguente ritardo nell'accorgersi troppo tardi di errate concezioni o di errori. Produce disallineamento tra ciò che viene "fatto" e ciò che era “desiderato". Il prodotto risultate finisce per soddisfare le esigenze degli sviluppatori, anziché quelli del cliente. Perché investire tanto nella fase iniziale, che è quella parte del progetto, dove non si conosce bene il progetto e non si ha piena consapevolezza di dove andrà a finire? Perché investire su cose che possono rivelarsi del tutto inutili? Tende a creare schemi molto rigidi, una rigorosa disciplina, organizzare entro schemi rigidi e autoritari. Non si adatta allo spirito del programmatore (progettista/inventore piuttosto che produttore). OCCORRONO MODELLI MENO RIGIDI E PIU' FLESSIBILI CHE ACCOLGONO IL CAMBIAMENTO ANCHE DURANTE LO SVILUPPO STESSO. ## Modello Iterativo-Incrementale. Successivi ampliamenti e rifiniture attraverso iterazioni (multiple). Sistema cresce incrementalmente. Iniziando ad operare e facendo gli errori presto, si arriva più in fretta al risultato finale. Il nostro cervello inizia a pensare alla soluzione del problema. Spesso non ci si chiede davvero perchè e qual è esattamente il problema perché esposto in maniera generica e per i vari problemi di comunicazione. Comunque arriviamo razionalmente e con molto assunzioni non verificate alla soluzione. Si deve iterare sulla soluzione, non sui componenti. L'Approccio Agile Iterativo e Incrementale non assume di sapere qual è la soluzione, ma pensiamo a quale sia l'incremento più piccolo e più semplice possibile per risolvere il problema. Non faccio nessuna assunzione su quale potrebbe essere la soluzione del problema e mi concentro a validare il problema presentando al cliente qualche cosa di pronto, un prototipo o versione iniziale che risolve parzialmente o totalmente il problema spostando la conversazione sul piano del problema. Chi sviluppa ed il cliente sono in generale su due domini di conoscenza completamente differenti e questo approccio permette di avere una conversazione allo stesso livello con un confronto in maniera empirica. Approccio agile, riduciamo il rischio del progetto in maniera rapida. I modelli AGILI sono nati in opposizione (estrema) ai metodi tradizionali. I metodi tradizionali sono inadeguati specialmente quando: - i requisiti sono incerti o variabili - si richiede una rapida risposta ai cambiamenti di mercato. ## Il modello Agile Il modello Agile è stato introdotto come risposta alle carenze del modello Waterfall. Gli sviluppatori si sono resi conto che, per stare al passo con un'industria del software in continua evoluzione, avevano bisogno di qualcosa di diverso da un approccio rigido e sequenziale. Hanno, quindi, creato la metodologia Agile, che è un approccio di sviluppo software collaborativo e iterativo. Questa metodologia prevede diverse fasi brevi chiamate "sprint". Dettagliate specifiche formali, approfondite analisi e puntigliosa documentazione sono considerate attività troppo costose rispetto ai benefici apportati. Limitano la flessibilità del processo che deve poter modificare i propri obiettivi in ogni momento. Se l'elenco dei deliverable, pianificato all'inizio di ogni sprint, non viene completato in tempo, gli sviluppatori possono ridefinire le priorità delle attività per cercare di produrre sempre risultati di alta qualità. Il metodo Agile si concentra sullo sviluppo iterativo piuttosto che su un approccio lineare. Dipende in larga misura dagli input continui dei clienti in ogni fase di sviluppo. Ciò incoraggia la flessibilità e migliora la soddisfazione del cliente. Le quattro fasi in cui si divide ogni iterazione nell'approccio Agile sono: - pianificazione - progettazione - sviluppo - test e rilascio. Nel 2001 Sutherland e altri 16 esperti di sviluppo software diedero vita al “MANIFESTO PER LO SVILUPPO AGILE”. DARE MAGGIORE IMPORTANZA A: - gli individui e le loro interazioni RISPETTO a processi e strumenti - la disponibilità di sw funzionamento RISPETTO a un'ampia documentazione - la collaborazione col cliente RISPETTO alla negoziazione dei contratti - la pronta risposta ai cambiamenti RISPETTO all'esecuzione di un piano. In senso lato il termine "agile" indica tutte quelle metodologie di sviluppo leggere e flessibili. Esempi di metodologie e framework agili: Scrum, Sviluppo software snello (Lean), Kanban, Extreme Programming (XP), Crystal, Metodo di sviluppo dei sistemi dinamici (DSDM), Feature Driven Development (FDD). Ciascuno di questi metodi ha le sue caratteristiche, pro e contro. Non si tratta davvero di decidere quale sia il "migliore” in generale. Si tratta di decidere quale è il più adatto per l'ambito del tuo progetto, in modo che il tuo team possa adottare gli strumenti giusti e i processi più corretti. ## PRO - Waterfall - Struttura chiara - Documentazione solida - misurazione dei progressi e approccio hands-off. ## CONTRO - Waterfall - Poco spazio per la creatività - test dell'ultimo minuto - minor coinvolgimento del cliente. ## PRO – Agile - Coinvolgimento degli stakeholders - adattabilità - deliverable flessibili - time to market più rapido - lavoro di squadra. ## CONTRO – Agile - Impegno totale - rilavorazione inevitabile - documentazione troppo ridotta. Mentre il metodo Waterfall è adatto per progetti ben definiti e con budget fissi, l'approccio Agile è ottimo per progetti che richiedono frequenti revisioni e feedback continui da parte del cliente. # 3. RACCOLTA E GESTIONE DEI REQUISITI Durante la fase di progettazione occorre produrre una descrizione completa formalizzata lato utente, con il giusto livello di dettaglio, di: - tutto ciò che il sistema deve fare (requisiti funzionali) - dell'ambiente in cui dovrà operare (requisiti non funzionali) - dei vincoli che dovrà rispettare. - usando diagrammi UML (modalità tradizionale). UML è una “Famiglia di notazioni grafiche che si basano su un singolo meta-modello e servono a supportare la descrizione e il progetto dei sistemi software". L'UML descrive un sistema con tre modelli: - Modello funzionale (punto di vista utente, comportamento visto da fuori) → Analisi dei requisiti → Use Case Diagram - Modello ad oggetti (struttura sistema) → Analisi del dominio → Class Diagram, Object Diagram, Deployment Diagram - Modello dinamico (comportamento oggetti del sistema) → Sequence Diagram, Activity Diagram, Statechart Diagram. Nella documentazione di progetto c'è: - Raccolta informale dei requisiti, comprensiva di tutti i requisiti funzionali e non - Definizione dei criteri di accettazione - Stesura dell'analisi funzionale formalizzata con gli UseCase - Definizione della cronologia delle interazioni (Activity Diagram), design delle interfacce utente e Diagramma di Navigazione (Mock-up) - Definizione delle entità, delle relazioni che tra esse intercorrono e formalizzazione con il Class Diagram di analisi e la sua descrizione - Design della base di dati (Modello E-R) e sua costruzione (e generazione degli script di creazione tabelle). La raccolta dei requisiti, quella tradizionale, ha in genere lo scopo di produrre un documento informale, scritto in linguaggio naturale, che spieghi molto brevemente gli obiettivi del cliente. Questo documento dovrebbe avere le seguenti caratteristiche: - Indicare chi è il cliente finale; - Indicare i requisiti che il cliente richiede (situazione attuale e obiettivo atteso); - Definire di che tipo di lavoro si tratta; - Indicare (se esistono) vincoli imposti da altri software o sistemi o ambienti esistenti con cui si debba interoperare; - Indicare requisiti non funzionali (es. numero di accessi simultanei, dimensioni della base dati, prestazioni attese, ...); - Descrivere "informalmente" e a grandi linee il lavoro da svolgere. - Riportare le fonti informative - Descrivere a grandi linee requisiti e prime iterazioni previste. I requisiti non funzionali sono tutti quei requisiti che non riguardano le funzionalità del sistema, ma ne permettono o caratterizzano il funzionamento: - Scalabilità - Performance - Supporto di Sistemi Operativi – Supporto di browser (se necessario) - Localizzazione - Usabilità - Supporto al cliente. Una specifica è una descrizione precisa dei requisiti (proprietà o comportamenti richiesti) di un sistema o di una sua parte. Una specifica descrive una certa entità “dall'esterno”, cioè, dice quali servizi devono essere forniti o quali proprietà devono essere esibite da tale entità. Per raccolta dei requisiti si intende la completa individuazione dei problemi che l'applicazione da realizzare deve risolvere e le caratteristiche che tale applicazione dovrà avere. ## Caratteristiche: - aspetti statici (dati) - aspetti dinamici (le operazioni sui dati) I requisiti vengono inizialmente raccolti in specifiche espresse generalmente in linguaggio naturale e, per questo motivo, spesso sono ambigui e disorganizzati. Il grado di precisione richiesto per una specifica dipende in generale dallo scopo della specifica. Anche nell'industria del software è necessario, in generale, produrre delle specifiche con diversi livelli di dettaglio e di formalità, a seconda dell'uso e delle persone a cui sono destinate. Una specifica descrive che cosa deve fare un sistema, o quali proprietà deve avere, ma non come deve essere costruito per esibire quel comportamento o quelle proprietà. La specifica di un palazzo non dice come è fatta la sua struttura, di quanti piloni e travi è composto, di quali dimensioni, e via dicendo, non dice, cioè, qual è la realizzazione di un palazzo che soddisfi i requisiti specificati. Un palazzo è la realizzazione di una specifica, ma naturalmente la costruzione del palazzo deve essere preceduta da un progetto. Un progetto è un insieme di documenti che descrivono come deve essere realizzato un sistema. Per esempio, il progetto di un palazzo dirà che in un certo punto ci deve essere una trave di una certa forma con certe dimensioni. Questa descrizione della trave è, a sua volta, una specifica dei requisiti (proprietà fisiche richieste) della trave stessa. Infine, la trave “vera”, fatta di cemento, è la realizzazione di tale specifica. Possiamo quindi vedere il “processo di sviluppo" di un palazzo come una serie di passaggi: si produce una prima specifica orientata alle esigenze del committente, poi una specifica orientata ai requisiti del sistema, poi un progetto che da una parte `e un'implementazione delle specifiche, e dall'altra `e esso stesso una specifica per il costruttore. I requisiti Agile 1) Sono espressi ad alto livello, con frasi brevi che contengono solo le informazioni più importanti, 2) Nessuna forma di documentazione cerimoniosa, formale e voluminosa. La massima interazione 1) Permette agli sviluppatori di capire i dettagli di cosa il cliente vuole veramente 2) Nel caso migliore: il cliente è disponibile durante tutto il processo di sviluppo (coinvolgimento reale del cliente, real customer involvement) 3) In alternativa: si una un proxy del cliente on-site, cioè una persona che conosce il problema, ed agisce per conto del cliente. Le metodologie agili si basano sull'osservazione che né il cliente né lo sviluppatore hanno una conoscenza completa del sistema nelle prime fasi del processo di sviluppo. Essi imparano man mano che il sistema evolve. E' fondamentale adottare delle pratiche che permettano ad entrambi di poter sfruttare la propria crescente competenza durante il processo di sviluppo. Il Product Backlog è stato definito come un elenco ordinato di funzionalità che si intende sviluppare. Le User Story sono le specifiche da condividere con il team per stabilire cosa deve essere sviluppato. Il concetto più interessante introdotto dalle User Story è quello di mettere l'utilizzatore del nostro prodotto (lo User) al centro dell'attenzione durante il processo di sviluppo. Pari importanza è data anche all'identificazione del bisogno che ogni funzionalità promette di soddisfare (la storia). Questo approccio si differenzia dai metodi di sviluppi più tradizionali nei quali il responsabile di prodotto condivide con il team un elenco di requisiti tecnici o funzionali. Quello che spesso succede è che la motivazione per cui una funzionalità viene richiesta si perde nella catena di comando o, ancora peggio le specifiche vengono travisate. - I requisiti sono descrizioni delle esigenze del prodotto - descrivere il problema I requisiti vengono trasformati in più User Story, dove ogni User Story è una proposta per soddisfare parzialmente il Requisito User Story: rappresentano una descrizione di una "soluzione" - da un punto funzionale di vista - normalmente descritta dal punto di vista dell'utente - Le User Story sono soluzioni proposte dal punto di vista di un utente Le User Story hanno criteri di accettazione o condizioni di soddisfazione Una User Story deve contenere anche Criteri di Accettazione che descrivano come l'utente della storia accetterebbe la funzionalità implementata - I criteri di accettazione possono essere discusso e negoziato con il Team di Sviluppo Requisito: rappresenta un bisogno. Deve rispondere alle domande: - Cosa? - Perché? Cerca di identificare con una frase chiara qual è il problema da risolvere. User Stories, le 3 'c': CARD, CONVERSATION, CONFIRMATION. Struttura della user story: “as a <type of a user> I want to <do something> so that <I can achieve some business value>". WHO = l'utente a cui ci rivolgiamo, WHAT = il bisogno che vogliamo soddisfare, WHY = il motivo per cui vogliamo soddisfarlo. Scenario-Given-When-Then: è un formato utile per esprimere criteri di accettazione verificabili. La storia viene quindi focalizzata con uno o più scenari, ad indicare il comportamento complessivo che si vuole descrivere. Scenario: descrive l'ambito della storia. Given: descrive il contesto di un comportamento di business del cliente o dell'applicazione. When: descrive l'azione richiesta per produrre l'output descritto. Then: descrive l'output atteso. ESEMPIO: 1. Nome Storia: Pagamento con PayPal As a Paypal User I want to use account Paypal For paying my purchases. 2. Scenario: Paypal User use the own Paypal account for paying Given I am a Paypal User When I pay with my Paypal account Then the transaction is confirmed essere: • Independent: È più facile lavorare con le storie se sono indipendenti • Negotiable: Una buona storia è negoziabile. Non è un contratto esplicito per le funzionalità Valuable: Una storia deve dare valore al cliente • Estimable: Una buona storia può essere stimata • Small or Sized appropriately: Piccolo o dimensionato in modo appropriato • Testable:"Capisco quello che voglio abbastanza bene da poterci scrivere un test". In un processo Agile, i requisiti si raccolgono durante tutta la durata del progetto. Nella prima fase i requisiti sono raccolti attraverso una serie di riunioni, alle quali partecipano sia il cliente che gli sviluppatori. Un tema è un insieme di User Stories correlate tra loro. Una serie di storie che presentano una affinità può essere raggruppata in uno stesso tema: ad esempio amministrazione, piuttosto che produzione. Si tratta quindi di un modo per catalogare le storie in categorie più o meno grandi. Infine, le epiche rappresentano il livello più alto di espressione del bisogno di un utente. Sono gli elementi che descrivono la big picture, le macro-componenti del progetto. Si tratta di storie di grandi o grandissime dimensioni che permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l'elevato livello di astrazione. Per questo motivo, se possibile, può essere opportuno articolarle in storie più piccole. Le "Epiche" sono simili ai “Temi” nel senso che possono rappresentare più storie, ma al contrario dei “Temi” una Epica comprende un unico workflow per un utente; perciò, è più corretto assimilarla ad una grande storia. La raccolta dei requisiti avviene tramite INTERVISTA, QUESTIONARIO, OSSERVAZIONE WORKSHOP. Interviste 1 to 1. Si tratta di incontri faccia-a-faccia con ciascun stakeholder per raccogliere le aspettative e i requisiti funzionali di ciò che dovrà essere realizzato dal progetto dal punto di vista di ciascun stakeholder. Sono spesso incontri informali in cui ogni stakeholder deve sentirsi libero di esprimere ogni valutazione senza correre il rischio di sentirsi esposto e vulnerabile al giudizio altrui. E' importante che vengano raccolte indicazioni rilevanti per gli obiettivi del progetto e che le questioni di contorno non costituiscano l'oggetto di tali incontri. E' quindi opportuno che l'intervista sia preceduta dalla precisazione degli obiettivi del progetto e dell'incontro stesso chiarendo, in particolare, che per il momento lo scopo è solo la raccolta delle aspettative dell'interlocutore e non l'analisi dei requisiti che avverrà in una fase successiva. L'intervista può essere strutturata sulla base di check list o di un questionario preparati preventivamente. In questo caso è opportuno che la checklist sia inviata all'intervistato prima dell'incontro in modo che possa raccogliere le idee e predisporre le informazioni necessarie. Focus group. Questa modalità prevede un incontro con un gruppo di stakeholder che sono invitati a partecipare per confrontare idee e selezionare le opzioni migliori. Dato l'elevato livello di interattività di queste situazioni, è opportuno che il gruppo sia composto da un minimo di 6 ad un massimo di 12 persone. In questa situazione i partecipanti sono stimolati tutti a portare un contributo e quindi sono maggiormente sotto pressione rispetto all'intervista in quanto possono scattare timori reciproci. E' compito di chi dirige la sessione, coinvolgere tutti e strutturare l'incontro in modo informale utilizzando la tecnica del brainstorming. E' importante che le persone non inseguano idee preconcette e che ci sia apertura a valutare opzioni diverse senza che questo produca conflitti interpersonali. Workshop. Il workshop è un incontro di lavoro cui partecipa il team di progetto, il Project Manager e gli stakeholders del progetto. Rispetto al focus group ha la particolarità di non essere finalizzato alla sola raccolta delle informazioni, ma include anche una fase di individuazione di soluzioni. Questo fatto porta ad un maggior coinvolgimento degli stakeholders in quanto risulta meno asettico del focus group e si entra maggiormente sulle questioni di dettaglio. Il rischio è che risulti dispersivo; per cui sarebbe opportuno farlo precedere da un focus group finalizzato alla raccolta delle informazioni per poi dedicare il workshop all'analisi dei requisiti e all'individuazione delle soluzioni. Questionari. In questo caso la raccolta avviene sulla base di questionari inviati agli stakeholders perché rispondano autonomamente, salvo, una volta raccolte le risposte, procedere con un workshop per valutare quanto emerso dall'indagine. In tal senso, è opportuno comunicare a ciascun stakeholder un tempo limite entro il quale far pervenire le risposte. Laddove necessario e nei casi di progetti particolarmente innovativi, può essere opportuno inviare il questionario anche ad un panel di esperti (anche interni all'azienda), in modo da raccogliere pareri anche da parte di chi ha avuto esperienze similari in passato. Questa modalità di raccolta è particolarmente utile quando è possibile formulare quesiti a risposta chiusa. Nei casi di risposte aperte è preferibile utilizzare il focus group oppure un workshop. Osservazione. Questa modalità implica un sopralluogo in situazioni in cui è possibile prendere visione diretta o sperimentare gli utilizzi di quanto richiesto. Ciò è particolarmente utile quando un progetto deve correggere alcune anomalie di prodotti o processi oppure quando uno stakeholder ha difficoltà a rappresentare ciò che vuole ma può mostrare ciò che non vuole. E' anche utile quando le informazioni da raccogliere riguardano tempi e metodi di lavoro. In questo caso è importante che le persone osservate non siano a conoscenza della rilevazione. # 4. DATABASE MANAGEMENT SYSTEM ## I SISTEMI PER LE BASI DI DATI L'approccio passato alla gestione dei dati sfruttava la presenza di file e cartelle per memorizzare i dati in modo persistente sulle memorie di massa. Un file consente di memorizzare e ricercare dati, ma fornisce solo semplici meccanismi di accesso e di condivisione. Con tale approccio le procedure scritte nei linguaggi di programmazione sono completamente autonome; ciascuna di esse definisce e utilizza uno o più file privati. Dati di interesse per più programmi sono replicati tante volte quanti sono i programmi che li utilizzano, con evidente ridondanza e possibile di incoerenza. In caso di gestione SEPARATA delle informazioni da parte di tali soggetti, ci sarebbero molte duplicazioni ed a lungo andare ci sarebbero molti dati con le varie informazioni non aggiornate in modo coerente. Le basi di dati sono state concepite per superare tali tipi di inconvenienti, gestendo in modo integrato e flessibile le informazioni di interesse per diversi soggetti, limitando i rischi di ridondanza e incoerenza. ## Definizione generale: una base di dati è una collezione di dati che rappresenta le informazioni di interesse per un sistema informativo ## Definizione tecnica: una base di dati è una collezione di dati gestita da un DBMS. ## Come vengono gestite le basi di dati? - Tramite un *sistema di gestione di basi di dati* (DBMS). Ovvero un sistema software in grado di gestire collezione di dati che siano grandi, condivise, persistenti, assicurando la loro affidabilità e privatezza. - Ε' progettato per consentire la creazione, la manipolazione e l'interrogazione efficiente di database, per questo detto anche "gestore o motore del database", è ospitato su architettura hardware dedicata oppure su semplice computer. - Una base di dati è una collezione di dati gestita da un DBMS. ## Le basi di dati SONO GRANDI: database spesso contengono una grande quantità di dati. Il DBMS è progettato per gestire in modo efficiente anche insiemi di dati molto ampi, rendendo l'accesso e la manipolazione dei dati rapida e scalabile. ## CONDIVISE: I dati gestiti da un DBMS possono essere condivisi tra più utenti o applicazioni. Il DBMS si occupa di gestire le richieste simultanee in modo sicuro e coordinato, evitando conflitti e garantendo la consistenza dei dati. ## PERSISTENTI: La persistenza si riferisce al fatto che i dati rimangono memorizzati nel database anche dopo che il sistema viene spento o riavviato. Il DBMS assicura che i dati siano conservati in modo permanente, nonostante eventuali malfunzionamenti o crash del sistema. Il DBMS deve garantire che i dati sensibili siano accessibili solo agli utenti autorizzati, proteggendoli da accessi non autorizzati. Per farlo, implementa meccanismi di controllo degli accessi (basati su ruoli, utenti e permessi), crittografia dei dati e audit dei log per monitorare chi accede ai dati e quando. La privacy è particolarmente importante in settori come quello sanitario, finanziario o legale, dove la protezione dei dati personali è fondamentale. L'efficacia si riferisce alla capacità del DBMS di svolgere il proprio compito nel soddisfare i requisiti degli utenti e dell'organizzazione. Un DBMS efficace risponde alle esigenze aziendali, supportando un ampio set di funzionalità (come l'elaborazione di transazioni, l'analisi dei dati, e la gestione di database complessi) e offrendo strumenti per la gestione e la manipolazione dei dati. Inoltre, deve essere in grado di adattarsi ai cambiamenti nelle esigenze, mantenendo la flessibilità e la facilità d'uso, permettendo agli utenti di ottenere i risultati desiderati con il minor sforzo possibile. La capacità del DBMS di garantire che i dati siano sempre accurati, consistenti e disponibili, anche in caso di malfunzionamenti hardware o software (*affidabilità*). Questo è ottenuto attraverso meccanismi come le transazioni, che assicurano che ogni operazione sui dati sia completata correttamente, oppure annullata se qualcosa va storto (concetto di atomicità nelle transazioni). Inoltre, backup regolari e sistemi di recupero (recovery) permettono di ripristinare i dati in caso di perdita o corruzione. Un DBMS deve essere efficiente nell'utilizzo delle risorse di sistema (come CPU, memoria e disco) per gestire grandi quantità di dati e numerose richieste contemporanee. L'efficienza riguarda sia la velocità con cui il DBMS risponde alle query degli utenti, sia l'ottimizzazione dell'uso delle risorse per ridurre al minimo i tempi di risposta e i costi operativi. I sistemi DBMS utilizzano tecniche come l'ottimizzazione delle query, la gestione degli indici e la memorizzazione in cache per migliorare l'efficienza. I DBMS devono disporre di meccanismi per proteggere i dati da malfunzionamenti hardware o software e da interferenze indesiderate dovute ad accessi concorrenti ai dati da parte di più utenti (*affidabilità*). A tal fine, un DBMS prevede che le interazioni con la base di dati avvengano per mezzo di transazioni, cioè con un meccanismo che: - esclude effetti parziali dovuti all'interruzione delle applicazioni per una qualsiasi ragione - garantisce l'assenza di interferenze nel caso di accessi concorrenti ai dati. Una transazione è una sequenza di azioni di lettura e scrittura della base di dati e di elaborazioni di dati che il DBMS esegue garantendo le seguenti proprietà: ## Atomicità. Solo le transazioni che terminano normalmente (committed transactions) fanno transitare la base di dati in un nuovo stato. Le transazioni che terminano prematuramente (aborted transactions) sono trattate dal sistema come se non fossero mai iniziate; pertanto eventuali loro effetti parziali sulla base di dati sono annullati. ## Serializzabilità. L'effetto sulla base di dati dell'esecuzione concorrente di più transazioni e equivalente ad un'esecuzione seriale delle transazioni, cioè ad una esecuzione in cui le transazioni vengono eseguite una dopo l'altra in un qualche ordine. ## Persistenza. Le modifiche sulla base di dati di una transazione terminata normalmente sono permanenti, cioè non sono alterabili da eventuali malfunzionamenti successivi alla terminazione. Collezioni di dati grandi e persistenti sono possibili anche per mezzo di strumenti meno sofisticati, come ad esempio i file utilizzati e presenti nei sistemi operativi. I file sono stati introdotti pero per essere utilizzati 'localmente' e per singole applicazioni e con