Ingegneria del Software. MINR a.a. 2009-2010. Prof. Giuseppe Santucci. 01- Introduzione



Documenti analoghi
Ciclo di vita del software

Norme per l organizzazione - ISO serie 9000

Cos è. Insieme di: struttura organizzativa (equipe di qualità + capo progetto) responsabilità. procedure. procedimenti. risorse

PROGETTO TECNICO SISTEMA DI GESTIONE QUALITA IN CONFORMITÀ ALLA NORMA. UNI EN ISO 9001 (ed. 2008) n. 03 del 31/01/09 Salvatore Ragusa

Concetti di base di ingegneria del software

Manuale della qualità. Procedure. Istruzioni operative

Piano di gestione della qualità

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

La normativa UNI EN ISO serie Introduzione alla Vision 2000 Lezione 6 marzo 2001

Applicazione della norma ISO 9001:2008 al Sistema Gestione per la Qualità del Gruppo Ricerca Fusione. Claudio Nardi Frascati 24 novembre 2009

ISO/IEC : 2005 per i Laboratori di Prova

La gestione della qualità nelle aziende aerospaziali

Norma ISO appunti alle lezioni - a.a prof. V. Vaccari 68

I SISTEMI DI GESTIONE DELLA SICUREZZA

I modelli normativi. I modelli per l eccellenza. I modelli di gestione per la qualità. ! I modelli normativi. ! I modelli per l eccellenza

Qualità è il grado in cui un insieme di caratteristiche intrinseche soddisfa i requisiti (UNI EN ISO 9000:2005)

Allegato 2 Modello offerta tecnica

SISTEMA INFORMATIVO INPDAP SERVIZI E PROGETTI PER L'INTEGRAZIONE DEL SISTEMA STANDARD DI PRODOTTO PIANO DI QUALITA' DI PROGETTO

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA

ISO/IEC 2700:2013. Principali modifiche e piano di transizione alla nuova edizione. DNV Business Assurance. All rights reserved.

03. Il Modello Gestionale per Processi

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi

MANUALE DELLA QUALITÀ SEZIONE 5.1: FUNZIONAMENTO DEL SISTEMA DI GESTIONE PER LA QUALITÀ

Diventa fondamentale che si verifichi una vera e propria rivoluzione copernicana, al fine di porre al centro il cliente e la sua piena soddisfazione.

SVILUPPO, CERTIFICAZIONE E MIGLIORAMENTO DEL SISTEMA DI GESTIONE PER LA SICUREZZA SECONDO LA NORMA BS OHSAS 18001:2007

SISTEMA DI GESTIONE AMBIENTALE

PLUS. Syllabus rev. 1.04

Ing Omar Morales Qualità del Software

PASSAGGIO ALLA ISO 9000:2000 LA GESTIONE DELLE PICCOLE AZIENDE IN OTTICA VISION

LA CERTIFICAZIONE. Dr.ssa Eletta Cavedoni Responsabile Qualità Cosmolab srl Tortona

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

MANUALE DELLA QUALITÀ DI

14 giugno 2013 COMPETENZE E QUALIFICHE DELL INSTALLATORE DI SISTEMI DI SICUREZZA. Ing. Antonio Avolio Consigliere AIPS All right reserved

Sistemi di gestione per la qualità Requisiti

ISO 9001:2015 e ISO 14001:2015

Gli 8 principi della Qualità

Specifiche dello sviluppo di un progetto software e indicazioni sulla documentazione e sulle modalità di esercizio delle prestazioni

IL PROGETTO FORMATIVO PER L ABILITAZIONE PROFESSIONALE A QUALITY MANAGER

Manuale CAP 1. SISTEMA QUALITA

Ciclo di vita del progetto

figure professionali software

Ciclo di vita dimensionale

TENUTA SOTTO CONTROLLO DELLE REGISTRAZIONI

Automazione Industriale (scheduling+mms) scheduling+mms.

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

INGEGNERIA DEL SOFTWARE

Qualità ed organizzazione: l orientamento al cliente. Le forme della qualità e gli strumenti per gestire la qualità di un organizzazione

EVOLUZIONE DELLE INIZIATIVE PER LA QUALITA : L APPROCCIO SIX SIGMA

AUDITOR D.Lgs 231/01. Seminario ACIQ SICEV Sessione di Aggiornamento Dedicata ai Registri SICEV SICEP. Milano 28 Settembre 2012.

4.5 CONTROLLO DEI DOCUMENTI E DEI DATI

Governare il processo della sicurezza

L integrazione dei sistemi qualità, sicurezza, ambiente

La Metodologia adottata nel Corso

7. Esigenze informative e FAQ. 8. Allegati. Repository documentale.

Appendice III. Competenza e definizione della competenza

EA 03 Prospetto economico degli oneri complessivi 1

IL SISTEMA DI GESTIONE AMBIENTALE PER UN COMUNE

Sistemi Qualità e normativa

SCHEDA REQUISITI PER LA CERTIFICAZIONE DEGLI ITSMS (IT SERVICE MANAGEMENT SYSTEMS) AUDITOR/RESPONSABILI GRUPPO DI AUDIT

UNI EN ISO 9001:2008 Sistemi di Gestione per la Qualità: requisiti e guida per l uso

DM.9 agosto 2000 LINEE GUIDA PER L ATTUAZIONE DEL SISTEMA DI GESTIONE DELLA SICUREZZA TITOLO I POLITICA DI PREVENZIONE DEGLI INCIDENTI RILEVANTI

Management e Certificazione della Qualità

AZIENDA SANITARIA LOCALE TO1 - SC MEDICINA LEGALE - OBITORIO CIVICO

Il Modello 231 e l integrazione con gli altri sistemi di gestione aziendali

Il modello veneto di Bilancio Sociale Avis

1 La politica aziendale

Allegato A al CCNL 2006/2009 comparto Ministeri

Configuration Management

Database. Si ringrazia Marco Bertini per le slides

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ

I Sistemi di Gestione Integrata Qualità, Ambiente e Sicurezza alla luce delle novità delle nuove edizioni delle norme ISO 9001 e 14001

MANUALE DELLA QUALITÀ Pag. 1 di 6

PLUS Syllabus rev. 1.03

MANUALE DELLA QUALITÀ SIF CAPITOLO 08 (ED. 01) MISURAZIONI, ANALISI E MIGLIORAMENTO

Presidenza della Giunta Ufficio Società dell'informazione. ALLEGATO IV Capitolato tecnico

Corso di Valutazione Economica dei Progetti e dei Piani. Marta Berni AA

La norma ISO 9001:08 ha apportato modifiche alla normativa precedente in

Progettaz. e sviluppo Data Base

LA NORMA OHSAS E IL TESTO UNICO SULLA SICUREZZA 81/2008: IMPATTO SUL SISTEMA SANZIONATORIO

Sviluppo Sistemi Qualit à nella Cooperazione di Abitazione

Il modello di ottimizzazione SAM

PROCEDURA OPERATIVA PER LA GESTIONE DELLO SVILUPPO DEL SOFTWARE BM-33T

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale

11. Evoluzione del Software

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: Pag. 1

APPROVVIGIONARE APPROVVIGIONARE. Rev. Data Causale Redazione Verifica Approvazione. 00 xx/xx/xxxx Prima emissione

Generazione Automatica di Asserzioni da Modelli di Specifica

PROCEDURA DI SISTEMA GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE

INTRODUZIONE AL MANUALE DELLA QUALITA

Linee Guida per la stesura del Documento Tecnico

Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive

Politica per la Sicurezza

12. Evoluzione del Software

LE NORME DELLA SERIE EN 45000

TECNICO SUPERIORE DEI TRASPORTI E DELL INTERMODALITÀ

GESTIONE DELLA FORMAZIONE E

GESTIONE DELLA PRODUZIONE

Guida Compilazione Piani di Studio on-line

Le possibili sinergie della Direzione e della AQ orientate alla Buona Gestione del C.d.S.

LINEE GUIDA PER L EROGAZIONE DELLA FORMAZIONE INTERNA

Transcript:

Ingegneria del Software MINR a.a. 2009-2010 Prof. Giuseppe Santucci 01- Introduzione 01Intro.1 Informazioni generali sul corso Sommario Cenni storici, problemi dello sviluppo del software, concetti generali e definizioni (prodotto / processo) Standard per la qualità Modelli per il ciclo di vita del software 01Intro.2

Ingegneria del Software a.a. 09-10 Orario - Aula 5 - Via Ariosto 25 martedì 10.10-13.30 giovedì 10.10-11.50 N.B. : Nel secondo semestre si svolgerà una edizione analoga del corso in inglese Il programma e le modalità d'esame dei due corsi sono IDENTICI Per entrambi i corsi è prevista una prova da 5 e da 6 crediti 01Intro.3 Appelli d'esame Date appelli: Due appelli ordinari a gennaio-febbraio Due appelli di recupero giugno-luglio Un appello di recupero a settembre N.B. I due appelli ordinari sono mutuamente esclusivi 01Intro.4

Testi di riferimento Roger S. Pressman : Software Engineering A Practitioner s approach 4th ed. Mc Graw Hill (European adaption ISBN 007 7094115) (o analoga edizione italiana) N.B. Non è il testo del corso Lucidi e/o dispense www.dis.uniroma1.it\~santucci\didattica.html www.dis.uniroma1.it\%7esantucci\didattica.html N.B. %7E corrisponde alla tilde ~ 01Intro.5 Forme di comunicazione Ricevimento : mercoledì 14.30-16.30 Via Ariosto 25 secondo piano stanza B218 santucci@dis.uniroma1.it telefono? Solo durante l orario di ricevimento MTBF: lezioni >= 2300 g ricevimento studenti >=30 g Consultare SEMPRE la sezione AVVISI Martedì 6 ottobre NON ci sarà lezione 01Intro.6

Modalità di esame Prova scritta Esercizi e domande a risposta multipla (NEW!) Sul sito saranno resi disponibili alcuni esempi di compiti di esame Saranno erogate e verbalizzate due prove scritte distinte: 5 crediti 6 crediti 01Intro.7 Programma di massima (5 & 6 crediti) Il processo di produzione del software Introduzione e definizioni preliminari Modelli per il ciclo di vita del software Qualità del prodotto e del processo Standard per la qualità Project management (esercizi di esame) Metodologie di test Test a scatola bianca(esercizi di esame) Test a scatola nera (esercizi di esame) Economia del software Metriche e metodologie di stima delle risorse Il metodo COCOMO II e dei punti funzione (esercizi di esame) Analisi e specifica dei requisiti Definizioni preliminari: fase di analisi ed attività di specifica Tipologie di applicazioni e tipologie di linguaggi di specifica Tipologie di modelli Richiami di UML (Unified Modeling Language) Fondamenti della teoria della misura (esercizi di esame) Solo per 6 crediti Definizioni e richiami di concetti statistici di base Qualita' di una misura ed errori sistematici ed errori casuali Statistica inferenzialeanalisi della varianza (ANOVA) Esercitazioni 01Intro.8

IL PRODOTTO 01Intro.9 Prospettiva storica della produzione del software 1950-1965 prima era (Paleozoico) batch, distribuzione limitata, software ad hoc 1965-1975 seconda era (Mesozoico) multiuser, Real-Time, Database, software prodotto 1975-1985 terza era (Cenozoico) sistemi distribuiti, hardware low-cost (PC IBM), mercato di massa 1985-1995 quarta era (Terziario) OO technologies, sistemi user friendly, Powerful PC 1995-... quinta era (Quaternario) Internet, distributed computing CORBA-DCOM, component-ware, J2EE, web services,... 01Intro.10

Prospettiva storica del costo del software 100 80 60 sviluppo 40 20 manutenzione 1955 1965 1975 1985 Andamento esponenziale della spesa per il SW 01Intro.11 Prospettiva storica del costo del sw 100 80 60 40 20 1950 costo sw / costo hw 2000 01Intro.12

Ripartizione del costo del software 15% 80% manutenzione sviluppo 20% 46% verifica e validazione manutenzione e modifiche prog. e analisi codifica documentazione 20% 9% 10% % costo totale % costo di sviluppo Ripartizione dei costi totali tra manutenzione (dopo la consegna) e sviluppo Ripartizione dei costi di sviluppo tra: analisi, progetto, codifica, documentazione, verifica e manutenzione (interna) 01Intro.13 Software? Software: Creazione dell intelletto che include programmi, strutture dati, documentazione. L esecuzione dei programmi realizza (sperabilmente) le funzionalità previste Prodotto Software: Insieme completo di programmi, procedure e relativa documentazione rilasciato ad un utente Componente Software: Ogni parte identificabile di un prodotto software, sia in uno stadio intermedio del processo di sviluppo, che al termine di esso 01Intro.14

Caratteristiche del software Il SW e sviluppato e non costruito come un qualsiasi prodotto industriale (e.g., un monitor) Il SW non si consuma Il SW non è (era) realizzato utilizzando componenti preesistenti 01Intro.15 Prodotto industriale vs. prodotto software Prodotto Industriale Definito il progetto e il processo di produzione del bene si può delegare la produzione a strutture esterne senza influenzarne il risultato I parametri e le tecniche usate per descrivere un prodotto sono consolidate, affidabili ed efficaci Prodotto Software A partire da una specifica comune delegare la realizzazione a diversi soggetti porta alla realizzazione di prodotti totalmente diversi La descrizione delle caratteristiche funzionali, e di qualità del prodotto software rimane un problema aperto 01Intro.16

Prodotto industriale vs. prodotto software (2) Prodotto Industriale Sono possibili economie di scala e processi di produzione e distribuzione diversificati in funzione delle dimensioni del mercato a cui il prodotto si rivolge Prodotto Software Non è distinguibile la produzione su piccola scala da quella su larga scala. Esiste una attività di revisione ed aggiornamento non comparabile con quella dei prodotti tradizionali. 01Intro.17 Deterioramento e guasti hw e sw % guasti hw % guasti sw (teoria) tempo tempo % guasti sw Cambiamenti sw tempo 01Intro.18

Componenti sw e riusabilità Il concetto di componente software riusabile è apparso da poco all orizzonte È strettamente collegato ai linguaggi Object Oriented (OO) (Java, C++) Alto riuso di componenti per la costruzione di interfacce grafiche (Graphical User Interface o GUI) 01Intro.19 Macroclassificazione delle applicazioni sw Sistemi operativi e software di sistema sw di servizio Real time software vincoli precisi sui tempi di risposta Sistemi informativi dati, dati, dati Software scientifico numeri, numeri, numeri Software nascosto ascensori, lavatrici, telefoni, automobili, ecc.. PC software 01Intro.20

Crisi o affezione cronica? La disponibilità di hw potente e a basso costo spinge verso la produzione di sistemi software sempre più complessi, la cui gestione diventa sempre più difficile Nel 1985 Dave Parnas, uno dei massimi esperti di ingegneria del software mondiali, membro di una commissione istituita dal ministero della difesa degli Stati Uniti (presidenza Regan) per l analisi della parte informatica del programma noto come guerre stellari si dimette. Nella motivazione pubblica delle sue dimissioni afferma che le odierne conoscenze e tecnologie non sono in grado (e non lo saranno in breve tempo) in grado di affrontare problemi così complessi 01Intro.21 Ingegneria del software Il termine nasce nel 1968 in una conferenza NATO È la disciplina il cui scopo è dare un approccio sistematico alla produzione, alla manutenzione ed alla evoluzione del prodotto del software L ingegneria del software comprende: modelli astratti e teorie di base metriche metodi e processi di produzione e di test tecnologie e strumenti sensibilità pratica obbiettivi da raggiungere (e.g., qualità del sw, standard ISO 9126) 01Intro.22

IL PROCESSO 01Intro.23 Ciclo di vita del software Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si è compreso che il processo andava formalizzato attraverso: un insieme di fasi in cui decomporlo, un insieme di prodotti delle varie fasi, un insieme di metodi da adottare nelle varie fasi, un insieme di tecniche e/o modelli con cui descrivere i prodotti delle fasi 01Intro.24

Attività trasversali Controllo/gestione del progetto Revisioni tecniche del progetto Controllo di qualità Gestione della configurazione Versioni, locazione dei file, iter di modifica, approvazioni... Gestione della documentazione Template, iter di approvazione, lista di distribuzione... Gestione della riusabilità Usare sw prodotto da altri Individuare sw prodotto in casa potenzialmente riutilizzabile Misure Gestione dei rischi 01Intro.25 Fasi essenziali del processo di produzione sw Progetto Sviluppo Manutenzione correttiva (20%): risoluzione di errori adattativa (20%): cambiamenti/aggiunte di specifiche perfettiva (50%) migliorativa: req. non funzionali (spazio, tempo) evolutiva: req. funzionali secondari preventiva(10%) rendere più semplice la individuazione di errori tramite miglioramenti del codice (ristrutturazione, pulizia, ecc.) 01Intro.26

Standardizzazione del processo CMMI origine accademica voluto dal ministero della difesa americano (Department Of Defense DOD) valuta le capacità di chi sviluppa ISO 12207 prodotto da una organizzazione internazionale razionalizza le attività coinvolte è piuttosto datato ISO 9000 pensato per un qualunque processo produttivo aggiornato nel 2000 (Vision 2000) 01Intro.27 Capability maturity model integration (CMMI) Nel 1987 il Software Engineering Institute (SEI) della Carnegie Mellon University, ha sviluppato un modello per valutare i potenziali fornitori di Sistemi Software (CMM) Revisionato nel 2001 CMMI (versione attuale 1.2, 1.3 a breve) Basato su cinque possibili valori, in grado di fornire al committente un indicatore della capacità e grado di maturità di una organizzazione Ad ogni livello successivo al primo sono associate le aree di processo chiave su cui l'organizzazione deve insistere per attestarsi su quel livello 01Intro.28

Livello 1 - Iniziale Il sw prodotto è caratterizzato dall'essere costruito "ad hoc", seguendo strategie occasionali e caotiche Solo alcuni processi produttivi sono ben definiti ed i successi dipendono solo da sforzi individuali Solo alcuni processi produttivi sono stabili 01Intro.29 Livello 2 - Ripetibile I processi di gestione (project management) dei progetti più importanti sono definiti in modo da: Permettere la loro pianificazione Tenere traccia dei costi (tempo e denaro) L'obbiettivo principale è poter riprodurre le stesse condizioni che hanno portato al successo in applicazioni precedenti Aree di processo chiave: Gestione dei requisiti Pianificazione dei progetti sw Tracciabilità e visibilità dei progetti Gestione dei subappalti Assicurazione della qualità del sw Gestione della configurazione del sw 01Intro.30

Livello 3 - Definito Il processo di produzione del SW segue standard ben precisi ed è documentato ed integrato in una visione aziendale unica Tutti i progetti utilizzano una versione approvata e documentata di processi organizzativi per lo sviluppo e la manutenzione del software Aree di processo chiave: Definizione e standardizzazione dei processi organizzativi Coordinamento intergruppo Confronti e verifiche Programmi di formazione 01Intro.31 Livello 4 - Gestito Collezione di misure dettagliate sui processi di produzione e sui prodotti Aree di processo chiave: Misure ed analisi di processo Gestione della qualità 01Intro.32

Livello 5 - Ottimizzante Miglioramento continuo del processo tramite: feed-back quantitativi introduzione di tecnologie innovative (sviluppo, test, documentazione, ecc.) Aree di processo chiave: Prevenzione dei difetti Innovazioni tecnologiche Gestione del processo di cambiamento 01Intro.33 CMM: Punti da ricordare + La metrica del livello di maturità è molto istruttiva: spiega come un organizzazione dovrebbe muoversi verso l alto + La metrica è riconosciuta come standard industriale e permette confronti - Il processo di valutazione (assessment) per determinare il livello di maturità misura l esistenza di certi standard e non la qualità o l efficacia di tali standard - Non è previsto un piano implementativo per ottimizzare il passaggio a livelli più alti - La qualità è definita dal SEI, non dalla componente dell organizzazione dedita allo sviluppo del sw - Il 70% delle software house è a livello 1 -- O sotto... 01Intro.34

CAPABILITY IMMATURITY MODEL - CIM 0. Negligent (Indifference) Failure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. Reliance on silver pellets. -1. Obstructive (Counter Productive) Counterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Ritualistic ceremonies abound. Collective management precludes assigning responsibility. -2. Contemptuous (Arrogance) Disregard for good software engineering institutionalized. Complete schism between software development activities and software process improvement activities. Complete lack of a training program. -3. Undermining (Sabotage) Total neglect of own charter, conscious discrediting of peer organizations software process improvement efforts. Rewarding failure and poor performance. http://www.stsc.hill.af.mil/ 01Intro.35 ISO 12207 Le idee SEI hanno influenzato lo sviluppo di alcuni standard ISO tra cui l' ISO/IEC 12207 definisce e sistematizza tutte le attività convolte nel processo di produzione sw. è basato su di un approccio funzionale ai processi produttivi: insieme di attività coordinate che trasformano un ingresso in una uscita 5 processi primari che riguardano i 5 agenti primari ovvero acquirente, fornitore, sviluppatore sw, gestore, manutentore; 8 processi di supporto agli altri processi (documentazione, configurazione, qualità, ecc.) 4 processi organizzativi, usati per stabilire e implementare una struttura costituita da processi e personale e migliorare in modo continuo sia la struttura che i processi 01Intro.36

5. Processi primari del ciclo di vita 5.1 Acquisizione 5.2 Fornitura I processi ISO 12207 6. Processi di supporto 6.1 Documentazione 6.2 Gestione della Configurazione 6.3 Assicurazione di qualità 6.4 Verifiche 5.3 Sviluppo 5.4 Esercizio 5.5 Manutenzione 6.5 Validazioni 6.6 Riesami congiunti 6.7 Ispezioni 6.8 Risoluzione dei problemi 7. Processi organizzativi del ciclo di vita 7.1 Management 7.2 Infrastrutture 7.3 Miglioramenti 7.4 Addestramento 01Intro.37 Le 13 attivita` dello sviluppo SW 5. Processi primari del ciclo di vita 5.3 Sviluppo Implementazione del processo Analisi dei requisiti del S.I. Progettazione dell architettura del S.I. Analisi dei requisiti del sw Progettazione dell architettura del sw Progettazione di dettaglio del sw Codifica e testing del sw Integrazione del sw Test sulla qualità del sw Integrazione del sistema(hw + sw) Test sulla qualità del sistema Installazione del sw Supporto per il collaudo di accettazione del sw 01Intro.38

Lo standard ISO 9000 (2000) 01Intro.39 Motivazioni per la stesura della normativa ISO 9000 La famiglia di norme ISO 9000 fornisce le regole manageriali/organizzative e di processo che le organizzazioni operanti nel settore manifatturiero e/o dei servizi dovrebbero seguire per rendere razionali, efficienti, efficaci ed affidabili le attività del loro ciclo produttivo La ISO 9000 è stata emessa dallo International Organization for Standardization (ISO) (www.iso.ch) fin dalla metà degli 80 (nella sua prima versione). L ultima versione è del 2000, la precedente era del 1994 01Intro.40

Obbiettivi principali della ISO 9000 Tecnico-organizzativo: fornire un insieme di regole (concettuali) per migliorare e razionalizzare i processi produttivi Diffondere una cultura della qualità Marketing: creare nei clienti fiducia nei confronti delle organizzazioni che dimostrano di applicare bene queste regole Quest ultimo obbiettivo si raggiunge attraverso la certificazione di conformità alle regole ISO 9000 rilasciata da terze parti abilitate a farlo 01Intro.41 Livello di astrazione della ISO 9000 I requisiti ISO 9000 sono ad un livello di astrazione piuttosto alto, in quanto pensati per essere applicabili da qualsiasi organizzazione, indipendentemente dal settore merceologico o di servizi in cui opera Perciò, la ISO 9000 non entra nel merito di come vanno svolte, dal punto di vista tecnico, le attività previste dai vari processi lavorativi, ma definisce per ogni processo preso in considerazione quegli accorgimenti di natura manageriale/organizzativa che hanno maggiore influenza sul risultato finale del processo 01Intro.42

Dalla ISO 9001:1994 alla Vision 2000 Il sistema attuale della famiglia ISO 9000 è stato ridefinito nel dicembre 2000, attraverso il progetto denominato Vision 2000 Obiettivi della revisione: passare dalla cultura della conformità e delle evidenze a quella del continuo miglioramento, reale e misurabile dal cliente La revisione rientra nel programma quinquennale di revisione periodica delle norme emesse che la ISO persegue come politica di gestione della normativa Procedure di valutazione strettamente collegate al marchio europeo CE 01Intro.43 Le norme di assicurazione qualità Prima della versione 2000 della ISO 9001, la norma era tripartita Requisiti del cliente Sviluppo del prodotto Produzione Ispezione e test Installazione Manutenzione Assistenza ISO 9003 ISO 9002 ISO 9001 01Intro.44

Modello dei requisiti ISO 9001: 1994 4.1 Responsabilità della direzione 4.2 Sistema Qualità 4.3 Riesame del contratto 4.4 Controllo della progettazione 4.5 Controllo dei documenti e dei dati 4.6 Approvvigionamento 4.7 Controllo del prodotto fornito dal cliente 4.8 Identificazione e rintracciabilità del prodotto 4.9 Controllo del processo 4.10 Prove, controlli, collaudi 4.11 Controllo delle apparecchiature per prove, misurazione e collaudo 4.12 Stato delle prove, controlli e collaudi 4.13 Controllo delle prove non conforme 4.14 Azioni preventive e correttive 4.15 Movimentazione, immagazzinamento, imballaggio, conservazione e consegna 4.16 Controllo delle registrazioni della qualità 4.17 Verifiche ispettive interne della qualità 4.18 Addestramento 4.19 Assistenza 4.20 Tecniche statistiche 01Intro.45 Il sistema Vision 2000 E' composto da circa 10 documenti (erano 20 nel 1994) e le norme chiave sono: 1. ISO 9000 "Sistemi di gestione per la qualità - Fondamenti e terminologia" che descrive i concetti e i fondamenti dei sistemi di gestione per la qualità e la terminologia. Sostituisce la norma ISO 8402, il vocabolario della qualità 2. ISO 9001 "Sistemi di gestione per la qualità - Requisiti" che specifica i requisiti dei sistemi di gestione per la qualità che un'azienda/organizzazione deve soddisfare per dimostrare la sua capacità di fornire prodotti che soddisfino i requisiti del cliente e di ambiti regolamentati 3. ISO 9004 "Sistemi di gestione per la qualità - Linee guida per il miglioramento delle prestazioni" che fornisce una guida sui sistemi di gestione per la qualità, inclusi i processi per il miglioramento continuativo, ai fini della soddisfazione dei clienti dell'azienda/organizzazione e delle altre parti interessate. NON è oggetto di certificazione. Sostituisce la ISO 9004-1 Tutte le rimanenti norme diventano dei rapporti tecnici 01Intro.46

Principali elementi innovativi Vision 2000 (1) 1. Impostazione della qualità aziendale orientata ai processi 2. ritagliabilità (tailoring) ovvero la possibilità di personalizzazione dei requisiti in funzione di specifici obbiettivi aziendali, o la non applicazione se non trovano riscontro nelle attività reali dell'azienda/organizzazione (n.b., la nuova normativa dice chiaramente cosa si può e cosa NON si può escludere relativamente alle attività svolte dalla organizzazione) 3. maggiore facilità d uso del modello, in modo da estendere la possibilità di valutazione del grado di applicazione dei requisiti della norma oltre gli addetti ai lavori 01Intro.47 Principali elementi innovativi Vision 2000 (2) 4. allargamento delle linee aziendali interessate al Sistema Qualità, con particolare riferimento a chi gestisce gli aspetti finanziari, manageriali, amministrativi, commerciali, di relazione con la clientela, l impatto sull ambiente etc. 5. valutazione del Sistema Qualità legata a risultati di efficacia oltre che di efficienza 6. specifici punti del modello dedicati alla rilevazione e gestione della soddisfazione del cliente 7. orientamento ai fatti ed ai dati come fattori di pianificazione degli interventi 01Intro.48

Come cambia la ISO 9001 (1) 1. Riduzione dei modelli di sistemi qualità da tre (ISO 9001, ISO 9002, ISO 9003) ad uno solo 2. La struttura prevede solo quattro elementi fondamentali di sistema (punti da 5, 6, 7 ed 8) rispetto ai venti elementi di sistema di gestione (punti da 4.1 a 4.20) dell'edizione 1994 3. Maggiore enfasi alla gestione per processi, alle esigenze e alla soddisfazione dei clienti 4. Minore enfasi alle procedure documentate 5. Maggiori prescrizioni per il miglioramento continuativo 6. Maggiore chiarezza sul ruolo dell'alta direzione o dei vertici dell'organizzazione 01Intro.49 Come cambia la ISO 9001 (2) 7. Inserimento di considerazioni sui requisiti legislativi e regolamentari 8. È richiesta la definizione di obbiettivi misurabili 9. È previsto il monitoraggio delle informazioni sulla soddisfazione del cliente 10. Maggiori indicazioni sulla gestione delle risorse 11. Indicazioni sulla determinazione dell'efficacia dell'addestramento 12. Misurazioni estese al sistema di gestione, ai processi e al prodotto e/o servizio 01Intro.50

I 4 processi base 1. Responsabilità della direzione, in 6 punti, tra cui attenzione focalizzata al cliente 2. Gestione delle risorse. Tra le novità: Formazione e Qualificazione 3. Realizzazione del prodotto e/o del servizio, attenzione alla qualità dei processi 4. Misure, analisi, miglioramenti. Anche qui una novità rilevante è misura della soddisfazione utente 01Intro.51 I requisiti vanno adattati I requisiti di processo definiti nella ISO 9000 devono essere adattati e personalizzati ai diversi contesti in cui operano Questa contestualizzazione produce un insieme di requisiti di processo e di risorse propri di ogni organizzazione, che ne definiscono, nel loro insieme, il sistema di gestione per la qualità (sistema qualità) Il sistema qualità di una organizzazione definisce la politica per la qualità che essa persegue, in termini di struttura organizzativa, attività, controlli, risorse, a prescindere dalle esigenze di specifiche commesse o richieste di clienti. 01Intro.52

ISO 9001: certificazione e documentazione Le organizzazioni possono richiedere a organismi specializzati di rilasciare una certificazione di conformità al sistema ISO 9001 Nella visione 2000 della norma, si prevede che le verifiche debbano riguardare anche la efficacia dei processi, eventualmente a fronte di specifici obbiettivi aziendali e di settore La ISO 9000 prevede che i processi svolti vengano descritti in documenti specifici, dei quali vengono forniti indice e sommario dei contenuti, nonché guide alla loro compilazione in vari contesti Questi documenti sono: Manuale della qualità Piano della qualità 01Intro.53 Il manuale della qualità Le organizzazioni devono descrivere il proprio sistema qualità nel documento chiamato manuale della qualità Il manuale della qualità, secondo la ISO9000/ISO 8402, è il documento che enuncia la politica per la qualità e descrive il sistema qualità di una organizzazione La ISO ha emesso a supporto della stesura del manuale della qualità una guida, contenuta nella norma ISO 10013 01Intro.54

Il piano della qualità Non sempre la qualità potenzialmente raggiungibile è quella effettivamente necessaria L adattamento della politica generale per la qualità a specifiche esigenze viene descritta, di volta in volta, in dei piani della qualità, dove vengono definiti, in termini quantitativi, gli obbiettivi da raggiungere, i controlli previsti, le risorse impiegate, le responsabilità, la pianificazione delle attività, la documentazione di riscontro che verrà prodotta ad uso del cliente Il Piano della qualità, secondo la ISO 9000/ISO 8402, è il documento che precisa le particolari modalità operative, le risorse e le sequenze delle attività relative alla qualità di un determinato prodotto, progetto o contratto 01Intro.55 Flusso della documentazione Contesto Lavorativo ISO 9000 Risorse MdQ ISO 10005 ISO 10013 PdQ Cliente Obbiettivi progetto 01Intro.56

MODELLI per il ciclo di vita del sw 01Intro.57 Modelli per processo di produzione del sw Sequenziale (cascata, classico) oppure (iterazione/parallelismo) Prototipale Rapid Application Development (RAD) Incrementale Spirale Sviluppo concorrente Modelli basati su metodi formali 01Intro.58

Processo a cascata (waterfall) ANALISI DESIGN CODIFICA TEST MANUTEN. 01Intro.59 Fasi e prodotti del modello a cascata analisi descrizione di cosa si vuole realizzare definizione dei requisiti progetto progettazione del sistema (come si vuole realizzarlo) architettura e moduli codifica realizzazione in un linguaggio di programmazione sorgenti test verifica di aderenza, test di modulo e di integrazione documenti di test manutenzione gestione cambiamenti 01Intro.60

Problemi del modello a cascata i progetti reali raramente seguono il flusso sequenziale proposto dal modello, spesso si verificano iterazioni è spesso difficile per il cliente dichiarare tutti i requisiti in modo esplicito. Il modello ha difficoltà a gestire la naturale incertezza che esiste all inizio di nuovi progetti il cliente deve avere pazienza, una versione funzionante del sistema non potrà essere disponibile se non nelle ultime fasi del ciclo di vita (scoprire un errore in questa fase può avere conseguenze disastrose) il lavoro degli sviluppatori è inutilmente ritardato (il tempo di attesa complessiva può superare il tempo di lavoro!!!) 01Intro.61 Modello prototipale Interazione con l utente Realizz. modifica prototipo (mockup) Test del prototipo (con l utente) la prototipazione rapida ha come obiettivo la raccolta dei requisiti del prodotto software attraverso successive realizzazioni di prototipi: paper protoype o prototipo freddo working prototype: implementa solo alcune funzioni (interfaccia) 01Intro.62

Modello prototipale (2) se il prototipo è working lo si trasforma nel programma finale lo si butta vantaggi molto attraente, coinvolge maggiormente il cliente nella definizione delle specifiche, evita/riduce le incomprensioni svantaggi può evolvere in un sistema senza un progetto solido possibile spreco di risorse nel caso usa e getta tentazione di riutilizzare le scelte prototipali (o, addirittura il prototipo stesso) 01Intro.63 Modello RAD (Rapid Application Development) Obbiettivo: rapida codifica (riuso/parallelismo) Ipotesi fondamentale (e limite dell`approccio): requisiti chiari complessita` limitata (e.g., semplice sistema informativo) 5 fasi Analisi dell`azienda Analisi dei dati Analisi dei processi Codifica (4GT (4th generation techniques) e riuso) Test Decomposizione dell`applicazione in macrofunzioni realizzate da gruppi di lavoro diversi in parallelo 01Intro.64

Modello incrementale analisi progetto codifica test versione 1... analisi progetto codifica test Simile al prototipale ma: - i prodotti intermedi sono funzionanti - permette una più accurata progettazione versione n Prodotti Funzionanti 01Intro.65 raccolta dei requisiti iniziale Modello a spirale (6 regioni) 2) Planning 3) Risk analysis 1) Interazione con l`utente 4) Progetto 6) valutazione da parte del cliente 5) Realizzazione primo prototipo 01Intro.66

Considerazioni sul modello a spirale Rappresenta una razionalizzazione del modello prototipale Si presta alla gestione di progetti complessi Puo` essere significativo prevedere il numero delle iterazioni Sta acquistando sempre maggiore popolarita` Alcuni CASE tool lo supportano L utente e spesso scettico (converge?) 01Intro.67 Metodi formali Formalismi rigorosi (logici/algebrici) per le fasi di specifica, sviluppo e verifica Non si basano sul linguaggio naturale (inerentemente ambiguo) Affrontano i problemi di ambiguità, vaghezza, incompletezza e inconsistenza delle specifiche Esistono linguaggi formali funzionanti (ad es. `Z, Z++, ) Riportiamo un esempio con una sintassi inventata 01Intro.68

Metodi formali: esempio void Ordina(int a[], int n) // commento: ordina il vettore a, che ha n componenti tutte diverse tra loro, in maniera crescente pre: i J (i 0 i n-1 J 0 J n-1 i J) a[i] a[j] post: ( i (i > 0 i n-1 ) a[i] > a[i-1]) //1. gli elementi del vettore risultante sono ordinati ( K (K 0 K n-1 ) L (L 0 L n-1 a[k] = old(a[l]))) //2. gli elementi nel vettore risultante sono presenti nel vett. Originario ( R (R >= 0 && R n-1 ) S (S 0 S n-1 old(a[r]) = a[s])) //3.gli elementi del vettore originario sono presenti nel vett.risultante. 01Intro.69 Metodi formali (2) Vantaggi: Permettono controlli formali sulle specifiche Permettono la verifica automatica di ambiguità, incompletezze, inconsistenze Permettono la generazione automatica del codice Potenziali svantaggi: Difficili ad usarsi, richiedono personale estrememente specializzato Lenti nell utilizzo Non validi come forma di comunicazione con l utente 01Intro.70

Tecniche e linguaggi di quarta generazione (4GT/4GL) Strumenti e linguaggi caratterizzati da un elevato livello di astrazione Linguaggi dichiarativi Formalismi/linguaggi grafici Generazione automatica del codice maggiore produttività 01Intro.71 Un esempio Open Source: ArgoUML http://argouml.tigris.org/ 01Intro.72

Tecniche e linguaggi di quarta generazione (2) Potenziali svantaggi: Strumenti difficili da usare (difficoltà paragonabile ai linguaggi di programmazione convenzionali) Il codice generato potrebbe essere inefficiente La manutenzione è difficile L approccio sembra essere indicato per applicazioni di piccole dimensioni Non si risparmia tempo nell analisi, progetto e test 01Intro.73 Extreme Programming (XP) Approccio recente (1996) Obiettivi: Maggiore coinvolgimento del cliente (customer satisfaction) Rispondere ragionevolmente ai cambiamenti nei requisiti (anche quelli tardivi) Enfasi sul lavoro di gruppo (che può coinvolgere anche il cliente) Ridurre il numero di regole e di procedure (lightweight methodology) Forte enfasi sul test 01Intro.74

Ciclo di vita: modello XP 01Intro.75 Alcune regole di XP: codifica L'utente è sempre disponibile Il codice è scritto usando standard concordati Progettare subito i test Si programma in coppia Si integra spesso Il codice è visibile a tutti L'ottimizzazione è lasciata alla fine Niente straordinari Riunioni in piedi 01Intro.76

Prodotto e processo: riassunto Il prodotto SW ed il relativo processo di produzione differiscono notevolmente da quelli di altri prodotti industriali Le tecnologie e le metodologie si evolvono rapidamente È necessaria una (auto) formazione continua, per restare aggiornati! 01Intro.77