Software Engineering 1 Rapid Application Development Lesson 10.

Presentazione sul tema: "Software Engineering 1 Rapid Application Development Lesson 10."— Transcript della presentazione:

1 Software Engineering 1 Rapid Application Development Lesson 10

2 Software Engineering 2 RAD Main Goal: develop software as soon as possible

3 Software Engineering 3 RAD Rapid Application Development: an incremental and rapid development a simplified Waterfall (without implementation) reuse of Software the software isnt made but it is customized

4 Software Engineering 4 The four RADs phases: 1.Firm Modeling 2.Data Modeling 3.Process Modeling 4.System Implementation (reusing and customizing) RAD

5 Software Engineering 5 Some Benefits simplified testing rapid realization lower risk of overall project failure RAD

6 Software Engineering 6 Some Disadvantages we must start with well-understood requirements costly can be used only for Standard Applications RAD

7 Software Engineering 7 RAD: Case Study Lesson 9

8 Software Engineering1 RAD: Case Study Human ResourceSystem RAD: Case Study Human Resource System Lesperienza dellUniversità di Trento 19 maggio 2005

9 Software Engineering La rilevanza del dominio, sia in termini gestionali che strategici (voce di bilancio a maggior peso) La frammentarietà e lassenza di integrazione degli strumenti informatici utilizzati (alta manualità, duplicazione dati, disallineamenti, mancanza di una vista multi- dimensionale del dipendente..) Lobsolescenza degli applicativi esistenti e la loro inadeguatezza funzionale (elevata presenza di file personali gestiti con strumenti Office) La nascita di nuovi aspetti funzionali non supportati da strumenti informatici quali formazione, valutazione e sviluppo (massiccio utilizzo di strumenti Office) Il progetto: le motivazioni 1

10 Software Engineering Il progetto: le motivazioni File Excel Inaz Presenze CINECA TermTalk Stop & Go GePTA GePDoc LDAP Sistema Segreteria Studenti Inaz Web Sistema Contabilità File Excel 2

11 Software Engineering Dotare lAteneo di un Sistema di Gestione del personale, integrato con i macro business process dellUniversità Realizzare un Sistema aperto, affidabile, in grado di supportare tutti gli aspetti gestionali e operativi della Direzione Perseguire laccentramento e la definizione di fonti uniche di informazioni e generazione dei dati Ottimizzare i processi operativi, ridurre la manualità e migliorare la qualità del lavoro e delle attività svolte Fornire uno strumento che consenta una vista multidimensionale del dipendente Il progetto: gli obiettivi 3

12 Software Engineering Il progetto: le fasi Definire gli obiettivi Analizzare i fabbisogni informativi Individuare le opportunità di miglioramento Rilevare le criticità e le inefficienze Definire il Modello dei nuovo Sistema Informativo Gestire e manutenere il nuovo sistema Individuare il prodotto più adeguato Progettare e realizzare il nuovo sistema Requirements definition Individuare e analizzare i processi operativi Solution delivery Operate 4

13 Software Engineering Il progetto: le fasi Requirements definition disegnare il nuovo modello funzionale del dominio e i processi operativi che lo supportano definire i macro requisiti funzionali e non del nuovo sistema individuare le integrazioni necessarie stabilire vincoli e condizionamenti. 5

14 Software Engineering Il progetto: le fasi Solution delivery individuare il prodotto più adeguato definire le specifiche (tecniche e funzionali) del nuovo sistema disegnarne larchitettura (dati, funzioni, interfacce, conversioni) coerentemente con le specifiche individuate realizzare il sistema attraverso la customizzazione del prodotto scelto e le eventuali personalizzazioni verificarne il corretto funzionamento attraverso cicli successivi di test formare gli utenti supportare il passaggio in produzione del sistema. 6

15 Software Engineering Il progetto: le fasi Operate fornire il supporto tecnico per la gestione del sistema, con particolare riferimento alla risoluzione dei problemi di gestione ed alla evoluzione delle esigenze degli utenti definire e monitorare gli obiettivi di servizio (es. performance del sistema) verificando quali sono stati raggiunti e quali invece mancati e indagando i motivi di tali scostamenti progettare e realizzare gli interventi necessari per riportare il servizio al livello qualitativo previsto. 7

16 Software Engineering Package altamente personalizzati sviluppati da un rivenditore software 1970 1980 Soluzioni integrate sviluppate da un rivenditore software 1990 1990 Packages interfacciati sviluppati da più rivenditori di software 1980 1990 Sistemi ad hoc sviluppati sul cliente 1970 1970 Levoluzione storica dei sistemi informativi 8 Il progetto: la scelta del prodotto

17 Software Engineering Il progetto: la scelta del prodotto Applicazioni custom Differenti sistemi informativi che supportano diversi processi gestionali Interfacce limitate e costose tra i diversi sistemi Ritardi significativi nella definizione dei dati effettivi, dovuti a esigenze di riconciliazione e consolidamento. SistemaInformativo GestioneAmministrativa del Personale Gestione valutazione e sviluppo delle risorse umane Gestionedellaformazione Gestione rilevazione presenze Applicazioni interfacciate SistemaInformativo GestioneAmministrativa del Personale Gestionerilevazionepresenze Gestione valutazione e sviluppo delle risorse umane Gestione della formazione Un unico sistema informativo Le informazioni sono parzialmente isolate, nel senso che esistono strutture dati diverse per informazioni chiave, che devono essere integrate con uno sforzo significativo Presenza di un numero significativo di processi di elaborazione batch e off-line Sistemi ERP Focalizzazione sulla gestione delle informazioni Un unico sistema informativo Strutture dati condivise tra tutte le applicazioni chiave con conseguente facilità daccesso da parte di tutti gli utenti Tutte le informazioni sono aggiornate in tempo reale, con la virtuale eliminazione delle elaborazioni batch SistemaInformativo Gestione della formazione Gestione valutazione e sviluppo delle risorse umane Gestione rilevazione presenze Gestione amministrativa del Personale t Levoluzione storica dei sistemi informativi 1980 1980 1990 1990 dal 1990 in poi 9

18 Software Engineering Il progetto: la scelta del prodotto I benefici offerti dalladozione di una soluzione ERP FORTE INTEGRAZIONE Le applicazioni sono collegate tra loro in un insieme coordinato. Tutti i moduli lavorano insieme invece di funzionare come applicazioni separate eliminando attività doppie di controllo e verifica. RICCHEZZA DI FUNZIONALITA Le applicazioni sono state sviluppate con riferimento a pratiche e comportamenti operativi consolidati. VISIONE UNITARIA DELLE ATTIVITA OPERATIVE Tutte le applicazioni operano con la stessa base dati eliminando la possibilità di duplicazioni fornendo reporting e analisi coerenti per tutte le attività operative. 10

19 Software Engineering Il progetto: la scelta del prodotto ORIENTAMENTO AL PROCESSO Un software ERP è un software progettato con focalizzazione non sulle sole singole funzioni tradizionali, ma sullintero processo (somma di singole funzioni) che deve svolgersi in modo coordinato ed integrato. ELEVATA CONFIGURABILITA La ricchezza di funzionalità e di infotype (gruppi di informazioni omogenee) contenuti in ciascun modulo ERP è tale da consentire la realizzazione del sistema voluto attraverso semplici operazioni di configurazione guidata (customizing). Tanto più il modello funzionale del nuovo sistema coincide con lo standard ERP, tanto più il customizing consente di fornire risposte adeguate, eliminando la necessità di ricorrere ad attività di implementazione. Rimarranno da sviluppare solo le eventuali interfacce verso i sistemi esterni. 11

20 Software Engineering11 Il progetto: la scelta del prodotto Un esempio di customizzazione: Definizione titoli per il dipendente

21 Software Engineering13 Il progetto: la scelta del prodotto Inserimento titolo per il dipendente

22 Software Engineering14 Il progetto: la scelta del prodotto Elaborazione gruppi contrattuali e livelli retributivi

23 Software Engineering15 Il progetto: la scelta del prodotto Definizione categoria, livello e voci retributive contrattuali

24 Software Engineering Il progetto: la scelta del prodotto I criteri di valutazione adottati nella scelta del prodotto: costo della soluzione affidabilità del fornitore copertura funzionale architettura, configurabilità e integrabilità con gli altri sistemi di Ateneo con i pesi indicati nella griglia seguente Il prodotto che ha ottenuto il maggior peso è stato SAP HR. 16

25 Software Engineering Il progetto: la scelta del prodotto La struttura applicativa di SAP HR Client / Server Sistema di Base Personnel Administration Recruitment Organizational Management Time Employ Self Service Additional Functionality Benefits Payroll La modularità del prodotto ha consentito di progettare una soluzione che consente di mantenere lelaborazione delle retribuzioni sullattuale sistema di Cineca (Consorzio Interuniversitario ) 17

26 Software Engineering Il progetto: la metodologia adottata 18

27 Software Engineering Project Preparation & Business Blueprint Le prime due fasi rappresentano il momento di comprensione di dettaglio del contesto e di pianificazione delle attività di implementazione. Le principali attività sono: Definizione della struttura del team di progetto Definizione degli standard di documentazione Comprensione del contesto tecnico-applicativo Installazione dellambiente di sviluppo e di test del sistema SAP HR Realizzazione delle interviste di analisi dei processi funzionali Condivisione delle criticità gestionali dei processi funzionali Definizione del nuovo modello di funzionamento dei processi funzionali su SAP HR 19 Il progetto: la metodologia adottata

28 Software Engineering Realization La terza fase è il momento della costruzione del nuovo prototipo del Modello di funzionamento definito nelle fasi precedenti e dellanalisi e realizzazione degli interventi necessari per adattare ed integrare il sistema standard SAP HR nel contesto tecnico-applicativo di UNITN. Le principali attività sono: Configurazione di base delle strutture dei dati Configurazione definitiva dei processi funzionali Analisi, realizzazione e test degli sviluppi e dei report Analisi, realizzazione e test delle conversioni (recupero dati gestionali pregressi) Analisi, realizzazione e test delle interfacce da e verso gli altri sistemi e delle procedure collegate 20 Il progetto: la metodologia adottata

29 Software Engineering Final Preparation In questa fase si realizzano tutte le attività complementari necessarie allavvio produttivo del sistema secondo il Modello di Funzionamento definito ed approvato nella fase precedente. Le principali attività sono: Preparazione dei manuali utente Erogazione del training agli utenti finali Setup del sistema di produzione Realizzazione delle conversioni sul sistema di produzione 21 Il progetto: la metodologia adottata

30 Software Engineering Go Live & Support Nellultima fase si attiva il nuovo sistema informativo e si assistono gli utenti finali nella realizzazione dei processi gestionali, controllando al contempo il corretto funzionamento tecnico del sistema. Le principali attività sono: Attivazione del sistema in produzione Attivazione del servizio di help desk per gli utenti finali Risoluzione degli eventuali problemi Controllo sulle performance del sistema e sul volume delle registrazioni effettuate 22 Il progetto: la metodologia adottata

31 Software Engineering La realizzazione del sistema è stata suddivisa in due fasi, la prima a copertura di quanto oggi esistente, la seconda a copertura delle nuove esigenze. Il progetto: la pianificazione Il piano iniziale 23 Supporto Tecnico MGLASONDGFMA 2003 2004 FASE 1: Gestione Anagrafica e Giuridico-Amministrativa dei Dipendenti FASE 2: Rilevazione Presenze & Sviluppo del Personale Project Management Realization Final Preparation and Go Live &Support Business Blueprint Realization Final Preparation and Go Live &Support Business Blueprint

32 Software Engineering Il Piano della Qualità è un documento che, per singola fase della metodologia adottata, definisce: il contenuto della fase gli elementi in input alla fase gli output della fase le caratteristiche qualitative degli output i criteri, i parametri e le modalità di accettazione degli output. Il progetto: il piano della qualità 24

33 Software Engineering Il progetto: la struttura e i ruoli del team di progetto Comitato Guida Controllo Progetto Team Operativi Controllo Qualità Gruppo di Lavoro 3Gruppo di Lavoro 1Gruppo di Lavoro 2 Supporto Tecnico 25

34 Software Engineering Il progetto: la struttura e i ruoli del team di progetto Il Comitato Guida viene istituito per garantire la massima attenzione e partecipazione al progetto. E composto da responsabili di UNITN e da responsabili del fornitore e cura le seguenti attività: sponsorship del progetto gestione del cambiamento (promuovere, facilitare, motivare, guidare) definizione degli obiettivi di medio e lungo termine controllo ed approvazione dellavanzamento lavori e verifica del conseguimento degli obiettivi di progetto verifica e validazione delle scelte effettuate che hanno impatto significativo su organizzazione e processi dellAteneo assegnazione di risorse e priorità, rimozione/soluzione dei problemi che possono impattare su obiettivi, risultati e tempistiche di progetto (gestione del rischio). 26

35 Software Engineering Il progetto: la struttura e i ruoli del team di progetto Il Controllo Qualità è responsabile della definizione del Piano della Qualità e, attraverso il costante collegamento tra il Comitato Guida ed il Controllo Progetto, assicura che il progetto venga condotto nel rispetto degli standard qualitativi previsti e secondo gli obiettivi prefissati. 27

36 Software Engineering Il Controllo Progetto è responsabile della conduzione del progetto. Ha il compito di presidiare le attività di progetto in termini di contenuti e soluzioni proposte, di stabilire priorità e assegnazione delle risorse: pianificazione e coordinamento del progetto stesura, verifica e controllo degli stati avanzamento lavori integrazione con eventuali altri progetti dellAteneo verifica e validazione delle soluzioni progettuali coinvolgimento dei responsabili di funzione per le diverse aree soluzione dei problemi di assegnazione e disponibilità di risorse comunicazione, attivazione e coinvolgimento del Comitato Guida (preparazione documenti da presentare) comunicazione verso i Team operativi verifica ed approvazione di eventuali richieste di modifica. Il progetto: la struttura e i ruoli del team di progetto 28

37 Software Engineering Il Supporto Tecnico è responsabile della definizione, della creazione e del mantenimento di tutto lambiente tecnico di lavoro per il progetto, in termini di: Hardware Software Reti e comunicazioni Standard architetturali e metodologici Gestione ambienti di sviluppo, test, produzione Tuning e performance del sistema. Il progetto: la struttura e i ruoli del team di progetto 29

38 Software Engineering I Team operativi, generalmente specializzati per dominio funzionale, hanno la responsabilità di realizzare quanto definito durante la fase di Business Blueprint. Essi comprendono diversi profili professionali: consulente funzionale esperto del dominio e delle problematiche collegate, in ambiente SAP HR analista tecnico esperto della piattaforma SAP HR programmatore esperto dellambiente di sviluppo SAP key user operativi Il progetto: la struttura e i ruoli del team di progetto 30

39 Software Engineering Il coinvolgimento dei Key User ha lo scopo di garantire: la condivisione dei requisiti funzionali la condivisione delle soluzione applicative la condivisione della priorità di sviluppo e di fare in modo che essi diventino gli Utenti di riferimento per lAteneo nella gestione giornaliera delle funzionalità e dei processi attivati. Il progetto: la struttura e i ruoli del team di progetto 31

40 Software Engineering Le attività a carico dei Key User sono: fungere da collegamento tra il gruppo di lavoro nel quale si trovano ad operare e lufficio competente per ciascuna delle funzionalità da implementare; partecipare alla definizione di dettaglio del nuovo modello operativo e delle soluzioni progettuali definite; partecipare alla definizione delle modalità di conversione dei dati; partecipare attivamente alla impostazione del sistema; collaborare alla stesura della documentazione di progetto; progettare con gli utenti i test di sistema e dare supporto durante la loro effettuazione; stendere, con il supporto delle altre risorse del gruppo di lavoro, il manuale utente; preparare, organizzare ed erogare le attività di training degli utenti; partecipare allavvio del sistema, fornendo assistenza agli utenti. Il progetto: la struttura e i ruoli del team di progetto 32

41 Software Engineering Il progetto: landamento La fase di Blueprint ha permesso di definire nel dettaglio le funzionalità necessarie e il corrispondente impegno per realizzarle che hanno comportato un incremento nelle giornate lavorative previste del 40% e un conseguente ritardo nel passaggio in produzione del sistema di circa 2 mesi sulla pianificazione iniziale della Fase 1. 33 La Fase 1, avviata con 2 mesi di ritardo, sarebbe dovuta terminare con lentrata in produzione a marzo. LASONDGFMA 20032004 Final Preparation and Go live & Supporto Business Blueprint Realization Project Management M FASE 1:

42 Software Engineering Il progetto: landamento Successivamente, dopo quattro mesi di sviluppi (4 sui sei previsti, e il progetto completato all70%) è emersa una nuova particolarità gestionale che ha imposto la revisione del Modello e di quanto già sviluppato fino a quel momento. Lintroduzione della nuova funzionalità è costato un incremento del 65% delle giornate lavorative previste e un ulteriore ritardo nellentrata in produzione di ulteriori 6 mesi. 34 Supporto Tecnico LASONDGFMAMG 2003 2004 FASE 1: Project Management Realization Final Preparation and Go Live &Support Business Blueprint LASO N

43 Software Engineering Il progetto: alcune osservazioni 35 La stima iniziale è tanto più approssimata quanto minori sono le conoscenze del dominio specifico. La fase più critica di un progetto – di qualunque tipo esso sia – è lanalisi dei requisiti di dettaglio: spesso lutente non descrive determinate particolarità perché presuppone che siano note. Per evitare sorprese in fase avanzata del progetto è necessario che gli utenti vengano coinvolti nel progetto fin dallinizio con precise responsabilità. Più si procede nella realizzazione e più pesanti sono le ripercussioni di eventuali modifiche al modello; gg. lavorati e durata del progetto crescono esponenzialmente.

44 Software Engineering Prima verticalizzazione in Italia Mancanza di competenze contemporanee di HR SAP e delle peculiarità del contesto universitario Sottovalutazione dei macrorequisiti funzionali Necessità di personalizzazioni specifiche e conseguente impatto sulla manutenibilità del sistema Aumento sensibile dei costi del progetto. Il progetto: le criticità 36