Metodologia IDEF1/9 I diagrammi sono composti da box e vettori. Tutti i vettori del diagramma padre sono ereditati dai diagrammi figli. Utilizza schema codice ICOM Input Controlli Output Meccanismi

Pianificazione e programmazione: WBS 4 Macrovoci: Analisi preliminare del progetto Progettazione del sistema valutazione del progetto Sviluppo del sistema

Pianificazione e programmazione: Diagramma di Gantt1/2 Figure principali: Studente Politecnico Project Manager (analista funzionale) Dipendente Programmatore Dipendente operativo Dipendente Amministrativo

Pianificazione e programmazione: Diagramma di Gantt2/2

Pianificazione e programmazione: Reticolo La rappresentazione attraverso il reticolo del diagramma di Gantt mostra il cammino critico della programmazione del progetto.

Pianificazione e programmazione: Diagramma Pert Principali obiettivi: Stabilire un ordinamento sulle attività Determinare il minor tempo totale necessario Individuare le operazioni critiche Per ogni attività si individuano: Durata ottimistica a: tempo minimo richiesto per l’esecuzione Durata pessimistica b: tempo massimo richiesto per l’esecuzione Durata modale m: tempo verificato con la massima frequenza per l’esecuzione

Pianificazione e programmazione: Diagramma Pert – Distribuzione β Motivazioni per la scelta della distribuzione β : Unimodalità: presenza di un solo massimo in corrispondenza della durata più frequente. Bassa probabilità di realizzazione di a e di b. Continuità tra i punti a e b Massima flessibilità: Consente la rappresentazione di un’elevata quantità di situazioni

Waterfall model Il modello a cascata o ciclo di vita a cascata è un modello di ciclo di vita del software secondo cui la realizzazione di un prodotto software consta di una sequenza di fasi strutturata.

Metodologia IDEF 2/9  Un vettore può comparire tra parentesi nei diagrammi:  Parentesi sulla Parte connessa al box: vettore non ripetuto nei diagrammi figli in quanto sempre presente.  Parentesi sulla parte libera: vettore visibile solo ad un determinato livello di dettaglio e non visibile dai livelli superiori.

Metodologia IDEF3/9  Nodo A0

Metodologia IDEF4/9  Nodo A0 - Dettaglio

Metodologia IDEF5/9  Nodo A1 – Analisi dei requisiti

Metodologia IDEF6/9  Nodo A2 – Disegno e progettazione

Metodologia IDEF7/9  Nodo A3 - Sviluppo

Metodologia IDEF8/9  Nodo A4 – Implementazione e testing

Metodologia IDEF9/9  Nodo A5 – Post implementazione e aggiornamento

COCOMO II  La formula standard per il calcolo dell’Effort è:  Dove:  A: Fattore costante  Size: Stima delle funzionalità espressa in punti funzione o righe di codice  B: Fattore assegnato in funzione della dimensione calcolato valorizzando degli scale factors  M: Fattore moltiplicativo calcolato in base alla valorizzazione di alcuni costs driver

COCOMO II: Stima del fattore Size 1/4

COCOMO II: Stima del fattore Size 2/4  Il valore UFC deve essere corretto mediante l’applicazione di un fattore di complessità VFC

COCOMO II: Stima del fattore Size 3/4  Con i fattori a disposizione è ora possibile calcolare il fattore Size:  VFC = 0,65 + 0,01 * 32 = 0,97  FP = 209 * 0,97 = 202,73  203

COCOMO II: Stima del fattore Size 4/4  I punti funzione subiscono l’influenza del linguaggio di programmazione utilizzato.  Il linguaggio di programmazione utilizzato è ABAP/4, con SLOC pari a 16 LOC = 203 * 16 = 3248  3,248 KLOC

COCOMO II: Coefficiente B Dove W i è rappresentato dai valori assegnati ai valori di scala riportati in tabella. B = 1,01 + 0,01 * 11 = 1,02

COCOMO II: Coefficiente M Valorizzazione dei Costs driver opportuni: M = RCPX * RUSE * PDIF * PERS * PREX M = 1 * 1 * 1 * 0,83 * 0, 87 = 0, 7221

COCOMO II: Implementazione finale EFFORT [PM] = 2,94 * 3,248 ^ 1,02 * 0,7221 = 7,059 mesi / uomo Calcolo del tempo di sviluppo di progetto: TDEV = 3 * 7,059 ^ ( 0,33 + 0,2 * ( B – 1,01 )) = 5,74 mesi

Costi sviluppo IN HOUSE Si assume che al progetto vengano assegnati un analista funzionale e un programmatore. I costi giornalieri riportati in tabella sono riferiti al costo interno per la DNC di un analista funzionale senior e di un programmatore senior. Essendo il sistema sviluppato in house i costi di manutenzione si suppongono nulli. Il personale interessato sarà formato in orario extra-lavorativo ai normali costi di servizio.

Costi sviluppo OUTSOURCING 1/2 Si assume che al progetto vengano assegnati un analista funzionale e tre programmatori. I costi riportati in tabella sono stati presi da listini online relativi ai costi giornalieri di un programmatore senior e di un analista funzionale senior. Essendo il sistema sviluppato in outsourcing, si sono stimati i costi di manutenzione in una cifra pari a 4000 € annui. La tariffa media di un formatore è di 200 €/giorno, necessario per un periodo di una settimana  1000 € di costi di formazione personale

Costi Sviluppo OUTSOURCING 2/2 Essendo il sistema sviluppato in outsourcing, si sono stimati i costi di manutenzione in una cifra pari a 4000 € annui. La tariffa media di un formatore è di 200 €/giorno, necessario per un periodo di una settimana  1000 € di costi di formazione personale. Costo complessivo: Costo sviluppo sistema: € Costo di manutenzione: € Costo di formazione: € Totale: €

Analisi Benefici Ottimizzazione dei tempi di gestione degli skill Affidabilità dei dati Scalabilità Facilità di apprendimento e di utilizzo

La DNC: Data Network Consulting S.r.l.  Ambito: Soluzioni gestionale ERP.  Piattaforma Utilizzata: SAP/R3.  Servizi Offerti:  Di consulenza  Progetti chiavi in mano  Di formazione

Mercato di Riferimento  Mercato di riferimento: ICT  Operatori Dominanti:  Accenture  KPMG  Andamento del Mercato:  Percentuale di rendimento in calo  Ripresa prevista fine 2010

Oranizzazione Aziendale Amministratore unico Commerciale Amministrazione e segreteria Responsabile personaleResponsabile formazione Aiuto-commerciale Dipendenti operativi (senior/junior)

Obiettivi dello studio  Studio di fattibilità sull’informatizzazione e la gestione dei dati riguardanti i seguenti aspetti di un dipendente:  Skill  Anagrafica base  Attività svolte  Obiettivi  Corsi seguiti  Corsi tenuti

AS-IS  Gestione dati: manuale  Inserimento dati: manuale  Classificazione dati: cartelle di windows  Operatore: dipendente amministrativo  Nomenclatura del file:  CodiceSkill + NomeAziendaCliente + NomeRiferimento + dd/mm/yyyy della spedizione  Aggiornamento Skill: all’evenienza

Problematiche Riscontrate nel Sistema Attuale  Perdita di tempo  Maggiori spese di gestione  Ridondanza o assenza del lavoro  Comunicazioni inaffidabili  Mancanza di copie di backup

TO-BE Gestione dati: automatica Inserimento dati: manuale con procedura guidata Classificazione dati: database Operatore: dipendente amministrativo + operativo (per attività limitata) Nomenclatura del file: assente (tutto indicizzato nel database) Aggiornamento Skill: al termine di ogni attività svolta

Ottimizzazione nel Sistema Futuro 1/2  Perdita di tempo  riduzione sostanziale tempi morti  Maggiori spese  dopo costi implementazione, un amministrativo si può occupare di tutto  Ridondanza o assenza del lavoro  automaticamente gestito da SAP

Ottimizzazione nel Sistema Futuro 2/2  Comunicazioni inaffidabili  possibilità di automatizzare i messaggi tra operatori e sistema  Mancanza di copie di backup  create in automatico ogni volta che si modificano i dati (più backup)

QFD: definizione  Strumento integrato che consente l’impostazione strutturata di progetti preliminarmente all’attività di progettazione, sviluppo e produzione di nuovi prodotti e servizi.

Approccio del QFD Specifiche di progetto Caratteristiche dei sottosistemi componenti Specifiche del processo di fabbricazione Specifiche per la “qualità” Esigenze del cliente

Casa della Qualità Matrice delle Correlazioni Caratteristiche tecniche (come) Matrice delle relazioni (cosa con come) Requisiti e bisogni (cosa) Importanza caratteristica Benchmarking e pianificazione della qualità Valutazioni Peso requisi ti

Requisiti e bisogni: il cosa  I requisiti rappresentano le richieste di base del cliente.  Sono rappresentati come righe della matrice  Vi è un’ulteriore distinzione tra livelli:  Top level requirement  Detailed requirement

Requisiti e bisogni: applicazione ClientiCod.Top level requirementCod. Requisiti clienti Dipendenti 1Rapidità 1.1 Consultazione dei dati 1.2 Modificazione dei dati 1.3 Creazione dei curriculum 2Compatibilità2.1 Compatibilità con gli altri SW dell’azienda 3 Userfriendly 3.1 Facilità di uso 3.2 Visualizzazione semplice 3.3 Aiuto all’apprendimento 4 Affidabilità 4.1 Consistenza dei dati 4.2 Integrità/accuratezza dei dati 5Qualità 5.1 Limitazione degli errori di battiture 5.2 Limitazione nella duplicazione dei dati 5.3 Standardizzazione del formato dei curriculum Top management 6Economicità 6.1 Basso costo del sviluppo del sistema 6.2 Basso costo di formazione personale 6.3 Bassa manutenzione 7Sicurezza 7.1 Back-up dati 7.2 Protezione da agenti esterni 7.3 Trasferimento dati sicuro 8Affidabilità 8.1 Integrità della memorizzazione dei dati 8.2 Consistenza dei dati 8.3 Robustezza fisica del sistema 9Qualità 9.1 Chiarezza sul processo di creazione/modificazione dei CV ed obiettivi 9.2 Miglioramento della gestione dei documenti Clienti dell’azienda 10Compatibilità10.1 Compatibilità con i SW del cliente 11Rapidità11.1 Consultazione dei dati 12Qualità12.1 Integrità/accuratezza dei dati

Peso relativo dei Requisiti  Dopo aver scomposto i Top level requiremenet in Detailed requiremenet, è necessario assegnare a ciascun requisito del cliente un peso (valori da 1 a 5) che rispecchi l’importanza dello stesso agli occhi del cliente

Peso relativo dei requisiti: applicazione

Caratteristiche tecniche: il come  Rappresentano le risposte tecniche ai requisiti richiesti dal cliente  Sono le colonne della matrice  Vengono indicate le unità di misura delle varie caratteristiche o la presenza/assenza

Caratteristiche tecniche: applicazione Provided Function ABCDEFGHIJKLMNOPQRSTUVWXYZ Tempo consultazione dati Tempo modificazione dati Tempo creazione dati Tempo trasferimento dati ai clienti Numero di errori di battiture Numero di duplicazione dati Numero di errori / numeri totali dati formato standard dei curriculum Sistemi di intercompatibilità tra i SW Sistemi di controllo di errore dei dati inseriti Crittaggio dati Costo del sviluppo del sistema Costo di manutenzione Costo di formazione personale Assegnazione automatica dell'area di archiviazione Database per stoccaggio dati inseriti Numero ore di formazione collettiva utilizzazione istintiva interfaccia piacevole Chiarezza dell'interfaccia Esistenza di un "help" Tempo di progettazione del sistema compatibile alle esigenze aziendale Tempo di Sviluppo SW compatibile con le esigenze aziendale Back-up in caso di black-out grazie stampaggio skills Tempo Formazione personale Indice di affidabilità ore N° % Si/No €€€ Ore Si/No ore Si/No ore %

Matrice delle relazioni: cosa con come  Evidenzia il legame tra i bisogni del cliente e le caratteristiche tecniche del prodotto.  In ogni cella è indicato quanto una determinata caratteristica contribuisce a soddisfare un certo Detailed requirement  Scala di valutazione:   vuoto

Matrice delle relazioni: applicazione

Importanza caratteristica  Calcolo necessario per riconoscere le caratteristiche tecniche più importanti:

Importanza caratteristica: applicazione importanza assoluta della caratteristica Importanza relativa8,0%5,5%7,8%7,4%2,9%4,3%3,5%5,9% 0,8%0,7%4,7%2,3%3,5%2,7%0,8%3,5%7,0%1,2%7,8%2,7%0,5%1,6%2,0%0,4%6,6%100%

Matrice delle correlazioni 1/3  Partendo dalla matrice delle relazioni:  Si sostituisce un 1 nelle celle valorizzate, 0 nelle altre  Si usa la formula seguente per la normalizzazione:  Si sostituiscono gli 1 con i valori ottenuti dalla formula e si ottiene la matrice N.

Matrice delle correlazioni 2/3  Si può determinare la matrice Q delle dipendenze tra le caratteristiche tecniche utilizzando la seguente formula:  A partire da questa matrice si può stabilire il livello di correlazione  È necessario stabilire una soglia K  0 < K < 0,3 correlazione negativa forte  0,3 < K < 0,5 correlazione negativa  0,5 < K < 0,7 correlazione positiva  0,7 < K < 1 correlazione positiva forte

Matrice delle correlazioni 3/3  Nella matrice Q si identificano i gradi di correlazione come:  ++  correlazione positiva forte  +  correlazione positiva  -  correlazione negativa  --  correlazione negativa forte

Matrice delle correlazioni: applicazione

Benchmarking 1/2  Calcolato sulla qualità percepita (livello di soddisfazione dei bisogni)  Nel nostro caso è calcolato tra i valori del modello attuale e i valori obiettivo del nuovo modello  Grado di miglioramento = C/B  C = obiettivi modello nuovo  B = obiettivi modello attuale

Benchmarking 2/2  Calcolo del peso assoluto del bisogno  Peso = P*D*E  P = peso del requisito  D = grado di miglioramento  E = valore immagine di marca (se valorizzato)

Benchmarking: applicazione

Valutazioni  Confronto tra prestazioni modello attuale, prestazioni concorrenti (nel nostro caso assenti) e prestazioni obiettivo nuovo modello

Valutazione: applicazione

UML 2.0  Definizione: unified modeling language  È un linguaggio di progettazione e non di programmazione  Per progettare o modificare sistemiù  Definisce una notazione standard

Diagrammi  Diagrammi analizzati:  Dei casi d’uso  Delle attività  Delle classi  Di sequenza  Di stato

Diagramma dei casi d’uso  Specificano cosa dovrà fare il sistema, cioè il comportamento o i requisiti funzionali, senza definire come lo farà  compito svolto in fase di progettazione.  Obiettivi:  Scegliere i confini del sistema  Identificare gli attori e i loro obiettivi  Definire i casi d’uso

Componenti  Attori: qualcuno o qualcosa che scambia informazioni con il sistema, fornisce input e/o riceve output  Casi: unità funzionale parte del sistema  Relazioni:  Interazioni: relazioni tra attori e casi  Uses/include: caso d’uso che utilizza una certa funzionalità non sua  Extend: definisce una funzionalità per estensione di una già esistente

Diagramma delle attività

Diagramma delle classi

Diagramma di sequenza

Diagramma di stato

Metodologia IDEF 1/3  Metodologia sviluppata per modellare decisioni, azioni e attività di un’organizzazione o di un sistema.  Basata su una serie gerarchica di diagrammi che spiegano i processi in livello di dettaglio crescente.

Metodologia IDEF 2/3 I diagrammi sono composti da box e vettori. Tutti i vettori del diagramma padre sono ereditati dai diagrammi figli. Utilizza schema codice ICOM Input Controlli Output Meccanismi

Metodologia IDEF 3/3  Un vettore può comparire tra parentesi nei diagrammi:  Parentesi sulla Parte connessa al box: vettore non ripetuto nei diagrammi figli in quanto sempre presente.  Parentesi sulla parte libera: vettore visibile solo ad un determinato livello di dettaglio e non visibile dai livelli superiori.

COCOMO II  COCOMO: COnstructive COst Model  Si assumeva che il processo di sviluppo seguisse un tradizionale ciclo a cascata.  COCOMO II: Evoluzione di COCOMO  Modello per la stima dei tempi e dei costi adeguati alle pratiche di sviluppo software corrente.

COCOMO II: Calcolo dell’effort  Basato sulla seguente formula:  EFFORT [PM] = A * SIZE^B * M Dove:  A = fattore costante dipendente dalle routine organizzative  SIZE = Valutazione delle dimensioni del codice oppure una stima delle funzionalità espressa in punti funzione  B = Fattore moltiplicativo calcolato in base al valore di 5 scale factor  M = Effort multiplier cost driver