PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA...
Transcript of PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA...
1
PIANIFICAZIONE E REALIZZAZIONE DI
UN SISTEMA INFORMATIVO
147 6/001.0
2
PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO
6/002.0147
o ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI
o ELABORAZIONE DI UN MODELLO DEI PROCESSI
o MODELLI DESCRITTIVI PER LA PROGETTAZIONE DEI SISTEMI INFORMATIVI
o MODELLI DI ARCHITETTURE EDP
o PIANIFICAZIONE GESTIONE E CONTROLLO NELLO SVILUPPO DEI SISTEMI INFORMATIVI
o SCELTA E INTEGRAZIONE DEL SOFTWARE STANDARD
o LA QUALITÀ DEL SOFTWARE E DEI SISTEMI
3
SVILUPPO DEL SOFTWARE
6/003.0147
o È UNA DELLE FASI PRINCIPALI NELLA REALIZZAZIONE
DEL SISTEMA INFORMATIVO: PUÒ ESSERE ANALIZZATO
SOTTO DUE DIFFERENTI PROSPETTIVE
l QUELLA DELL’UTENTE FINALE
l QUELLA DI CHI CREA LA PROCEDURA DEL LAVORO
4
6/004.0147
RUOLO DI UTENTI E ANALISTI
o UTENTI:
l DEVONO SPECIFICARE LE CARATTERISTICHE DEI
PROCESSI AZIENDALI CHE VANNO SUPPORTATI
DALL’EDP (ANALISI DEI REQUISITI)
o ANALISTI E PROGRAMMATORI
l HANNO IL COMPITO DI VERIFICARE LA FATTIBILITÀ
TECNICA DELLE SPECIFICHE RICHIESTE E
CONCRETIZZARLA IN APPLICATIVI EFFICIENTI
5
6/005.0147
DIMENSIONI DELLO SVILUPPO
o SVILUPPO ARTIGIANALE IN PRESENZA DI
APPLICAZIONI DI MODESTE DIMENSIONI, SENZA
ATTENERSI A METODI E STANDARD. PUÒ ANCHE
PRODURRE RISULTATI SODDISFACENTI
o LO SVILUPPO DI UN SISTEMA INFORMATIVO DI
GRANDI DIMENSIONI, ESEMPIO:l CONTABILITÀ GENERALE
l GESTIONE ORDINI
l CONTI CORRENTI BANCARIRICHIEDE IL RICORSO ALLA SOFTWARE ENGENEERING
6
6/006.0147
SOFTWARE ENGENEERING 1
o SOFTWARE ENGENEERING O INFORMATICA AZIENDALE
l SETTORE DELL’INFORMATICA AZIENDALE DEDICATO
ALLO STUDIO DELLE METODOLOGIE, DELLE
TECNICHE E DEGLI STRUMENTI UTILIZZATI NELLA
PRODUZIONE INDUSTRIALE DEL SOFTWARE, VISTO
COME PROCESSO DI COLLABORAZIONE TRA:
− ANALISTI− PROGRAMMATORI− UTENTI FINALI
7
6/007.0147
SOFTWARE ENGENEERING 2
o L’INGEGNERIA DEL SOFTWARE AFFRONTA LE PROBLEMATICHE DI TIPO
l MANAGERIALE
l ORGANIZZATIVO
l METODOLOGICO
PER CONSENTIRE CHE IL LAVORO DEI PROGETTISTI POSSA ESSERE CONDOTTO CON LA MAGGIORE EFFICACIA, AVVALENDOSI DI TECNICHE E MODI DI PROCEDERE SPERIMENTATI IN CONTESTI ETEROGENEI
8
ELEMENTI FONDAMENTALI PER LO SVILUPPO DEI SISTEMI INFORMATIVI
6/008.0148
o SVILUPPO DEL SOFTWARE IN FASI
o IL PROTOTYPING COME METODOLOGIA PER LO
SVILUPPO DEL SOFTWARE
9
6/009.0148
ELEMENTI FONDAMENTALI PER LO SVILUPPO DEL SOFTWARE
o LA PROGETTAZIONE DEI SISTEMI SOFTWARE ÈUNA DISCIPLINA GIOVANE. ESISTONO, A GRANDI LINEE, DUE APPROCCI:
l SUDDIVISIONE IN FASI. PRESUPPONE ESATTA
DEFINIZIONE DEL PROBLEMA, SPECIFICHE
PRECISE, CREAZIONE DEI PROGRAMMI SOLO IN
FASI CONCLUSIVA
l REALIZZAZIONE DI UN PROTOTIPO PER IL QUALE
NON È FONDAMENTALE UN’ANALISI PRECISA DEI
REQUISITI
10
6/010.0148
SVILUPPO DEL SOFTWARE IN FASI 1
o QUESTA METODOLOGIA È CHIAMATA ANCHE “IN CASCATA” O “WATERFALL” PERCHÈ DA UNA FASE SI PASSA A QUELLA SUCCESSIVA SENZA TORNARE INDIETRO
o LO SVILUPPO IN FASI PREVEDE LA SUDDIVISIONE DEL PROCESSO DI SVILUPPO DI UN SISTEMA INFORMATIVO IN UNA SEQUENZA DI FASI
o OGNI FASE DEVE ESSERE TERMINATA PRIMA DI PASSARE ALLA SUCCESSIVA E L’OUTPUT DA ESSA GENERATO ANDRÀ A COSTITUIRE L’INPUT DELLA FASE SEGUENTE
o LO SVILUPPO IN FASI CONSENTE DI EFFETTUARE CONTROLLI DI QUALITÀ SUI SINGOLI RISULTATI PARZIALI
11
6/011.0149
SVILUPPO DEL SOFTWARE IN FASI 2
o MODELLO A SEI LIVELLI DI BALZERT
l FASE DI PIANIFICAZIONE (O STUDIO DI FATTIBILITÀ)
l FASE DI ANALISI (O DEFINIZIONE)
l FASE DI PROGETTAZIONE
l FASE DI IMPLEMENTAZIONE (O PROGRAMMAZIONE)
l FASE DI COLLAUDO E DI INSTALLAZIONE
l FASE DI MANUTENZIONE
12
6/012.0149
FASE DI PIANIFICAZIONEo SI STABILISCONO GLI OBIETTIVI DEL SISTEMA
INFORMATIVO
o SI ANALIZZA LA FATTIBILITÀ DEL PROGETTO SOTTO IL PROFILO TECNICO ED ECONOMICO
o SI ESAMINA SE:l È POSSIBILE UTILIZZARE HARDWARE / SOFTWARE
ESISTENTIl È NECESSARIO INTRODURRE UN NUOVO MODELLO
DI ORGANIZZAZIONE DEI DATIl IL SOFTWARE CHE S’INTENDE REALIZZARE PUÒ
ESSERE ADEGUATAMENTE SUPPORTATO DALLA PIATTAFORMA HARDWARE ESISTENTE
13
FASE DI ANALISI
6/013.0149
o SI INDIVIDUANO LE ASPETTATIVE DELL’UTENTE FINALE IN RELAZIONE AL PRODOTTO DA REALIZZARE ATTRAVERSO LA COSIDDETTA ANALISI DEI REQUISITI
o LA FASE DI ANALISI È UTILE PER STUDIARE I PROCESSI AZIENDALI E LE AREE DI CRITICITÀ
o ALLA FINE SI ELABORA UN PROGETTO DI MASSIMA DEL SOFTWARE
o LE SPECIFICHE COSÌ DETERMINATE POSSONO ESSERE CLASSIFICATE SECONDO ASPETTI:l FUNZIONALIl QUALITATIVIl ECONOMICI
14
6/014.0150
FASE DI ANALISI - ASPETTI FUNZIONALI
o GLI ASPETTI FUNZIONALI SONO
l AREA FUNZIONALE CHE IL NUOVO SISTEMA DEVE
SUPPORTARE
l MODALITÀ CON CUI IL SISTEMA INFORMATIVO DEVE
ESEGUIRE LE FUNZIONALITÀ PER CUI È PREDISPOSTO
l I MODELLI DI ORGANIZZAZIONE DEI DATI CUI LE
DIVERSE PROCEDURE DOVRANNO AVERE ACCESSO
l GLI INPUT E GLI OUTPUT DEL SISTEMA
15
6/015.0150
FASE DI ANALISI - ASPETTI QUALITATIVI
o LE SPECIFICHE QUALITATIVE RIGUARDANO
INDICAZIONI PER:
l LA CONFIGURAZIONE DELL’INTERFACCIA UTENTE
l ASPETTATIVE RELATIVE AI TEMPI DI RISPOSTA
l AFFIDABILITÀ DEL SISTEMA
16
6/016.0150
FASE DI ANALISI - ASPETTI ECONOMICI
o LE SPECIFICHE DI TIPO ECONOMICO RIGUARDANO:
l COSTI DI ESERCIZIO
l COSTI DI MANUTENZIONE
17
SPECIFICHE DI PROGRAMMA
6/017.0150
o DOCUMENTO UTILIZZATO PER DESCRIVERE AL SOFTWARE LE ASPETTATIVE INERENTI L’UTILIZZO
CONCRETO
o LE SPECIFICHE DI PROGRAMMA SINTETIZZANO LE
ESIGENZE DELL’UTENTE IN MODO CHIARO E
UNIVOCO
18
6/018.0150
CONTENUTO DELLE SPECIFICHE DI PROGRAMMA
o LE SPECIFICHE DI PROGRAMMA CONTENGONO:
l FUNZIONALITÀ DEL SISTEMA
l PRESTAZIONI
l AMBIENTE DI UTILIZZO
l INTERFACCE ESTERNE
l EVENTUALI VINCOLI
l REQUISITI DI QUALITÀ
19
6/019.0150
SPECIFICHE RELATIVE AL PROCESSO DI SVILUPPO
o SI FOCALIZZA L’ATTENZIONE SU:
l NECESSITÀ DI COLLABORAZIONE TRA LE
DIVERSE AREE AZIENDALI
l IMPATTI ORGANIZZATIVI
l DOCUMENTAZIONE DEL PROGRAMMA E TEST DA
REALIZZARE SUL SOFTWARE
l COSTI DI SVILUPPO, DURATA DELLO SVILUPPO,
RISORSE NECESSARIE
l STIMA DEI BENEFICI
20
LA PROGETTAZIONE DEL SISTEMA INFORMATIVO
6/020.0150
o OBIETTIVO
l INDIVIDUARE LE FUNZIONI CHE COSTITUISCONO UN PROCESSO, LE LORO RELAZIONI E I DATI NECESSARI ALLA LORO REALIZZAZIONE
l STUDIO DELLE MODALITÀ DI:
− PRODUZIONE
− UTILIZZAZIONE
− AGGIORNAMENTO
− SCAMBIO DI DATI
…RILEVANTI NELL’AMBITO DELLE SINGOLE FUNZIONI
21
6/021.0150
APPROCCI ALLA PROGETTAZIONE
o ESISTONO DUE POSSIBILI APPROCCI ALLA
PROGETTAZIONE
l PROGETTAZIONE TRADIZIONALE O STRUTTURATA
l PROGETTAZIONE ORIENTATA AGLI OGGETTI
22
6/022.0150
PROGETTAZIONE TRADIZIONALE O STRUTTURATA
o LA REALTÀ AZIENDALE VIENE REALIZZATA
ATTRAVERSO DUE MODELLI:
l DATI
l FUNZIONI
23
6/023.0151
PROGETTAZIONE ORIENTATA AGLI OGGETTI
o OOD, OBJECT ORIENTED DESIGN
o IN ENTRAMBI I CASI (PROGETTAZIONE TRADIZIONALE E OOD), LE SPECIFICHE DI PROGRAMMA
COSTITUISCONO IL PUNTO DI PARTENZA DELLA FASE DI PROGETTAZIONE
l LE “PROSPETTIVE” DELLA REALTÀ AZIENDALE
VENGONO RIUNITE IN UN UNICO MODELLO
OGGETTO
24
6/024.0151
MODULI 1
o L’INTERO SISTEMA INFORMATIVO È COSTITUITO DA
UNA GERARCHIA DI SOTTOSISTEMI (MODULI) CHE
POSSONO ESSERE SVILUPPATI E RIUTILIZZATI IN
MODO INDIPENDENTE TRA LORO
o UN MODULO È UNA COMPONENTE DEDICATA A
SVOLGERE UNA SPECIFICA FUNZIONE
o UN MODULO È COSTITUITO DA DUE PARTI:l INTERFACCIA (LA PARTE VISIBILE ALL’ESTERNO)
l IMPLEMENTAZIONE (LA PARTE INTERNA DEL
MODULO, L’INSIEME DEGLI ELEMENTI CHE GLI
PERMETTONO DI SVOLGERE LE SUE FUNZIONI)
25
6/025.0151
MODULI 2
o NEL PROGETTO LOGICO VENGONO IDENTIFICATE LE
COMPONENTI (MODULI) DEL SISTEMA E LE
CONNESSIONI FRA ESSE
o UN SISTEMA È QUINDI COMPOSTO DA VARI MODULI
CHE INTERAGISCONO TRA LORO
o I MODULI E LE LORO INTERAZIONI COSTITUISCONO
L’ARCHITETTURA DI UN SISTEMA SOFTWARE
26
6/026.0151
PRODOTTO DEL PROGETTO LOGICO
o DESCRIZIONE DETTAGLIATA
l DEI COMPITI CHE CIASCUN MODULO DEVE SVOLGERE
l DEL MODO IN CUI I VARI MODULI COMUNICANO TRA
LORO
o NULLA VIENE DETTO SU COME I VARI MODULI
COMUNICANO TRA LORO
27
6/027.0151
PROGETTO FISICO
o IL PROGETTO FISICO
l È ORIENTATO A DEFINIRE LE CARATTERISTICHE
DELL’AMBIENTE HARDWARE E SOFTWARE DEL
NUOVO SISTEMA
l ESEMPIO
− I DATI POSSONO ESSERE ORGANIZZATI IN UN
MODELLO DI DATABASE RELAZIONALE
− UN INSIEME DI MODULI DI FUNZIONI PUÒ ESSERE
DESTINATO A UN UNICO APPLICATIVO,
ASSOCIANDOLO ANCHE A ELEMENTI STRUTTURALI IN
GRADO DI ESEGUIRE COMPITI GENERICI (PER ES.
ACCESSO AI DATI E TRATTAMENTO DEGLI ERRORI)
28
6/028.0151
RISULTATI DEL PROGETTO FISICO 1
o STRUTTURA GENERALE (COMPONENTI) DEL
SISTEMA INFORMATIVO
o MODULI DI PROGRAMMA, CON I QUALI VENGONO
ESEGUITE LE PROCEDURE AZIENDALI
o SEQUENZA CON LA QUALE I SINGOLI MODULI DI
PROGRAMMA DOVRANNO ESSERE ELABORATI
29
6/029.0151
RISULTATI DEL PROGETTO FISICO 2
o STRUTTURA LOGICA DEI DATI DELL’APPLICAZIONE
o STRUTTURA FISICA DEI DATI E DEI FILE DI DATI
o I PRIMI TEST DI PROVA
30
6/030.0152
FASE DI IMPLEMENTAZIONE O DI PROGRAMMAZIONE 1
o SPECIFICA NEI MINIMI DETTAGLI IL PROGETTO DEL
SISTEMA FINO A:
l DEFINIRE I SINGOLI COMANDI
l TRADURLI NEL LINGUAGGIO DI PROGRAMMAZIONE
PRESCELTO
31
6/031.0152
FASE DI IMPLEMENTAZIONE O DI PROGRAMMAZIONE 2
o VENGONO ANCHE DEFINITI:
l SCHEMI DEI DATI (DESCRIZIONE DELLA STRUTTURA
DEI DATI, DEI FILE O DEI DATABASE)
l CICLI DI PROGRAMMA O FUNZIONI
l INTERFACCE USATE
32
6/032.0152
FASE DI IMPLEMENTAZIONE O DI PROGRAMMAZIONE 3
o INTERFACCIA UTENTE
l SI DEVONO PRENDERE IN CONSIDERAZIONE PRINCIPI DI ERGONOMIA DELL’HARDWARE E DEL SOFTWARE
l SI DEVE VALUTARE L’IMPATTO DEI NUOVI PROGRAMMI SULL’UTENTE FINALE
l SI DEVE ANALIZZARE QUALI SUPPORTI DI DOCUMENTAZIONE IN LINEA SIANO NECESSARI
l LO STANDARD ISO 9001 DEFINISCE
− I PARAMETRI DI USABILITÀ
− LE MISURAZIONI DEL LIVELLO DI SODDISFAZIONE
33
6/033.0152
FASE DI IMPLEMENTAZIONE O DI PROGRAMMAZIONE 4
o SYSTEM TEST (TEST DI SISTEMA)
l RIENTRA NELLA FASE DI IMPLEMENTAZIONE
l NEL SUO CORSO VENGONO VERIFICATI L’INTERA
APPLICAZIONE E I SINGOLI SOTTOSISTEMI CHE LA
COMPONGONO
34
6/034.0152
FASE DI COLLAUDO E INSTALLAZIONE
o DOPO AVER VERIFICATO L’ADERENZA A TUTTI I REQUISITI RICHIESTI SOTTO IL PROFILO TECNICO FUNZIONALE, IL SOFTWARE VIENE INTRODOTTO IN
AZIENDAo IL COLLAUDO PUÒ DIMOSTRARE LA PRESENZA DI
ERRORI, NON L’ASSENZA (A MENO DI NON FARE
TUTTE LE PROVE POSSIBILI)o UN COLLAUDO CHE PROVASSE IL SISTEMA IN
TUTTE LE CONDIZIONI SAREBBE INSOSTENIBILE ECONOMICAMENTE
35
6/035.0152
FASE DI MANUTENZIONE 1
o SI ESTENDE PER TUTTA LA VITA DEL SISTEMA
o SI PRODUCONO MODIFICHE E ADATTAMENTI
o SI PROVVEDE A ELIMINARE GLI ERRORI SFUGGITI IN FASE DI COLLAUDO
36
6/036.0153
FASE DI MANUTENZIONE 2
o LA MANUTENZIONE È RESA NECESSARIA DA:
l CAMBIAMENTI NELLE ESIGENZE DELL’UTENTE
l AGGIORNAMENTI LEGISLATIVI
l VARIAZIONI NELL’ARCHITETTURA DEL SISTEMA
(NUOVO HARDWARE, NUOVO SOFTWARE,
NUOVI COMPONENTI DI RETE)
o COSTO MANUTENZIONE
l OLTRE IL 50% DEI COSTI DI SVILUPPO
37
6/037.0153
CRITICHE ALLO SVILUPPO A CASCATA
o FORTEMENTE INCENTRATO SULLA DEFINIZIONE DELLE SPECIFICHE NELLA FASE DI ANALISI
l QUESTO APPROCCIO È EFFICACE SOLO QUANDO IL
COMMITTENTE È IN GRADO DI FORNIRE I REQUISITI IN
MODO CHIARO E COMPLETO ALL’INIZIO DEL
PROGETTO
l SPESSO LA COMUNICAZIONE FRA L’EDP E LE
SPECIFICHE AREE AZIENDALI INTERESSATE AL
SISTEMA NON È SODDISFACENTE E GLI UTENTI
VENGONO COINVOLTI NEL PROGETTO SOLO IN FASE
MARGINALE
38
6/038.0153
CASE 1
o CASE (COMPUTER AIDED SOFTWARE
ENGENEERING)
l CONSENTE AD ANALISTI E PROGRAMMATORI DI
DISPORRE DI STRUMENTI PER CONTROLLARE E
GESTIRE, DA UN PUNTO DI VISTA TECNICO E
ORGANIZZATIVO, LA PRODUZIONE DEL
SOFTWARE
39
6/039.0153
CASE 2
o STRUMENTI CASE
l LINGUAGGI DESCRITTIVI PER LE FUNZIONI, PER I DATI
E PER LE STRUTTURE DI CONTROLLO
o L’EFFETTIVA PROGRAMMAZIONE VIENE COADIUVATA DA
l COMPILATORI
l INTERPRETI
l LINKER
l GENERATORI DI MASCHERE
l GENERATORI DI CODICE
40
6/040.0153
CLASSIFICAZIONE DEGLI STRUMENTI CASE
o GLI STRUMENTI CASE POSSONO ESSERE
CLASSIFICATI IN FUNZIONE:
l DELLE FASI DI SVILUPPO CHE SUPPORTANO
l DEL TIPO DI APPROCCIO CUI SONO ORIENTATI
− FUNZIONI
− DATI
− OGGETTI
41
6/041.0153
PROTOTYPING COME METODOLOGIA PER LO SVILUPPO DEL SOFTWARE
o OBIETTIVO
l SVILUPPARE IL PIÙ RAPIDAMENTE POSSIBILE UNA
VERSIONE ESEGUIBILE DEL SISTEMA INFORMATIVO
(O DI UN SOTTOSISTEMA)
l EVITARE UN’ANALISI DETTAGLIATA DEL PROGETTO
l COINVOLGERE IL PIÙ POSSIBILE L’UTENTE FINALE
42
6/042.0153
COLLABORAZIONE FRA SVILUPPATORI E UTENTI
o GLI SVILUPPATORI POSSIEDONO SOLTANTO
RISTRETTE CONOSCENZE RELATIVE AL SETTORE DOVE IL SISTEMA DOVRÀ ESSERE IMPLEMENTATO
o GLI UTENTI FINALI VEDONO L’EDP COME UN
SEMPLICE STRUMENTO PER LA SODDISFAZIONE IMMEDIATA DI TUTTE LE LORO ESIGENZE
o DALLA COLLABORAZIONE FRA SVILUPPATORI E
UTENTI NASCE IL PROTOTIPO, CHE NELLA SUA PRIMA VERSIONE SIMULA SOLTANTO DETERMINATE FUNZIONI DEL SISTEMA
43
6/043.0153
SVILUPPO EVOLUTIVO DEL SOFTWARE
o PARTENDO DALLA PRIMA VERSIONE, ATTRAVERSO LA COLLABORAZIONE FRA UTENTI E SPECIALISTI, SI PERFEZIONA E COMPLETA IL PRODOTTO
o L’UTENTE HA LA POSSIBILITÀ DI ESPRIMERE PROPRI DESIDERI SULLA SCORTA DEL PROTOTIPO ESISTENTE
o QUESTO PROCESSO VIENE CHIAMATO:
l SVILUPPO EVOLUTIVO DEL SOFTWARE
44
6/044.0154
PRO E CONTRO DELLO SVILUPPO EVOLUTIVO DEL SOFTWARE
☺ SI OTTIENE UN MAGGIOR LIVELLO DI
ACCETTAZIONE NELLE SUCCESSIVA FASE DI INTRODUZIONE DEL SISTEMA
☺ I COSTI DI MANUTENZIONE SONO MINORI
☺ È POSSIBILE COMBINARE LA CONVENZIONALE SUDDIVISIONE IN FASI CON IL PROTOTYPING CHE VIENE UTILIZZATO IN SEDE DI PROGETTAZIONE
L VENGONO TRASCURATE ESIGENZE DI
STRUTTURAZIONE SOTTO IL PROFILO INGEGNERISTICO
45
6/045.0154
ELABORAZIONE DI UN MODELLO DEI PROCESSI
o PROCESSO:
l SEQUENZA DI FUNZIONI CHE POSSONO ESSERE
ESEGUITE IN SUCCESSIONE, O ANCHE, A VOLTE, IN
PARALLELO
o SISTEMI INFORMATIVI E PROCESSI
l PRIMA DI SCEGLIERE SE SVILUPPARE UN NUOVO
SISTEMA INFORMATIVO SI DEVONO DEFINIRE I
PROCESSI AZIENDALI COINVOLTI
46
6/046.0154
MODELLO DEI PROCESSI
o PER ELABORARE UN MODELLO DEI PROCESSI:
l SI ANALIZZANO GLI OBIETTIVI CHE LE SINGOLE
FUNZIONI DEVONO REALIZZARE
l SI CONSIDERA LA SEQUENZA DELLE FUNZIONI DA
ESEGUIRE
l SI CONSIDERANO LE INTERFACCE CHE DEVONO
ESSERE UTILIZZATE E IL LORO RUOLO RISPETTO ALLE
DIVERSE UNITÀ ORGANIZZATIVE
47
6/047.0154
DESCRIZIONE DEI MODELLI DEI PROCESSI
o PER DESCRIVERE I PROCESSI SI USANO:
l CATENE DI PROCESSI ORIENTATE AGLI EVENTI
o ELEMENTI FONDAMENTALI DELLA CATENA DEI PROCESSI SONO GLI EVENTI
o GLI EVENTI:l AVVIANO IL PROCESSO
l POSSONO MODIFICARE IL CORSO DELLE FUNZIONI
l CONCLUDONO IL PROCESSO
l SONO A LORO VOLTA IL RISULTATO DI PROCESSI
48
6/048.0155
Figura 6.1 Esempio dello schema di una catena di processi orientata agli eventi
49
6/049.0155
MODELLI DESCRITTIVI PER LA PROGETTAZIONE DI SISTEMI
INFORMATIVI
o ELABORAZIONE DI UN MODELLO DEI DATI
o ELABORAZIONE DI UN MODELLO DELLE FUNZIONI
o ELABORAZIONE DI UN MODELLO DI PROGETTAZIONE
ORIENTATA AGLI OGGETTI
o CONCEZIONE DELL’ESECUZIONE DEL PROGRAMMA
50
6/050.0156
ELABORAZIONE DI UN MODELLO DEI DATI
o LA PROGETTAZIONE DEI DATI SI BASSA SULLA
SEPARAZIONE (TEMPORALE E LOGICA) DI DUE ASPETTI MOLTO DIVERSI:
l MODELLO CONCETTUALE DEI DATI
l IMPLEMENTAZIONE DEL MODELLO CONCETTUALE IN UNA SPECIFICA TECNOLOGIA DBMS
51
6/051.0156
MODELLO CONCETTUALE
o IL MODELLO CONCETTUALE VIENE DEFINITO DESUMENDO DALLA REALTÀ AZIENDALE,
MEDIANTE UN PROCESSO DI ASTRAZIONE
l LE UNITÀ LOGICO - OGGETTIVE
l LE RELAZIONI CHE INTERCORRONO FRA ESSE
52
6/052.0156
ENTITY - RELATIONSHIP MODEL
o ENTITY - RELATIONSHIP MODEL (ERM)
l SI È AFFERMATO COME UNO STANDARD NELLA
DEFINIZIONE DEL MODELLO CONCETTUALE
o ERM CONSENTE DI DESCRIVERE LE STRUTTURE
DELLE ENTITÀ DEI DATI E I LORO RAPPORTI, SEGUENDO PRECISE DEFINIZIONI E UNA CHIARA NOTAZIONE GRAFICA
53
6/053.0156
ELEMENTI FONDAMENTALI DEL MODELLO ERM
o ELEMENTI FONDAMENTALI DEL MODELLO ERM SONO:
l ENTITÀ
l TIPOLOGIE DI ENTITÀ CON LE LORO PROPRIETÀ
(ATTRIBUTI)
l RAPPORTI (RELAZIONI) FRA LE SINGOLE ENTITÀ
l TIPOLOGIE DI RAPPORTI (TIPOLOGIE DI
RELAZIONI) FRA LE SINGOLE ENTITÀ
54
6/054.0156
ENTITÀ
o ENTITÀ
l INFORMAZIONI REALI O ASTRATTE AVENTI UN SIGNIFICATO PROPRIO
l UNA QUALSIASI COSA CHE PUÒ ESSERE DISTINTAMENTE IDENTIFICATA
l UN QUALSISASI OGGETTO CHE ABBIA UNA PROPRIA INDIVIDUALITÀ, CHE SIA DISTINGUIBILE DA OGGETTI SIMILI E CHE ABBIA RILEVANZA PER IL SOGGETTO CONSIDERATO
o ESEMPIO
l IN UN SISTEMA DI FATTURAZIONE OGNI FATTURA È
UN’ENTITÀ DISTINTA
55
6/055.0157
TIPOLOGIE DI ENTITÀ
o TUTTE LE ENTITÀ DELLO STESSO TIPO COSTITUISCONO UNA TIPOLOGIA DI ENTITÀ
o ESEMPIO
l UN CLIENTE È UNA ENTITÀ
l L’INTERA CLASSE “CLIENTE” COSTITUISCE LA
TIPOLOGIA DI ENTITÀ
o UNA ENTITÀ VISTA COME SINGOLA CONCRETA ESPRESSIONE DI UNA TIPOLOGIA VIENE DEFINITA OCCORRENZA
56
6/056.0157
ATTRIBUTI
o ATTRIBUTI
l PROPRIETÀ DELLE TIPOLOGIE DI ENTITÀl I VALORI ATTRIBUTO DEFINISCONO PIÙ
DETTAGLIATAMENTE LE SINGOLE ENTITÀ
o ESEMPIO
l LA TIPOLOGIA DI ENTITÀ “DIPENDENTE” PUÒ ESSERE CARATTERIZZATA FRA L’ALTRO DAGLI ATTRIBUTI:
− CODICE DIPENDENTE− INDIRIZZO− NOME− ETÀ− REPARTO
57
6/057.0157
VALORI DEGLI ATTRIBUTI
o IN OGNI SPECIFICA OCCORRENZA CIASCUN ATTRIBUTO ASSUMERÀ UN VALORE
PARTICOLAREo I VALORI CHE GLI ATTRIBUTI POSSONO
ASSUMERE NELLA REALTÀ DEVONO ESSERE
COMPRESI IN UN DETERMINATO INTERVALLO CHIAMATO ANCHE DOMINIO
o ESEMPIO
l 10/08/2000 VALORE ATTRIBUTO DATAl 300.000 VALORE ATTRIBUTO IMPORTO
58
6/058.0157
IDENTIFICATORE
o IDENTIFICATORE
l CONSENTE DI IDENTIFICARE UNIVOCAMENTE
CIASCUNA OCCORRENZA, GARANTENDO CHE
NON ESISTANO OCCORRENZE DUPLICATE
o L’IDENTIFICATORE PUÒ ESSERE COSTITUITO DA
l ATTRIBUTO
l INSIEME DI ATTRIBUTI
l INSIEME DI ATTRIBUTI E ASSOCIAZIONI
59
6/059.0158
RELAZIONI
o ASSOCIAZIONI SEMANTICHE FRA LE ENTITÀ
o TIPOLOGIE DI RELAZIONI
l 1 : 1
l 1 : M
l M: N
60
6/060.0157
Figura 6.2 Tipologie di relazioni nell’ambito dell ’Entity - Relationship Model
61
6/061.0158
RELAZIONE 1 : 1
o AD OGNI OCCORRENZA DELLA PRIMA
TIPOLOGIA DI ENTITÀ NE CORRISPONDE UNA
DELLA SECONDA E VICEVERSA
o ESEMPIO:
l PER OGNI DIPENDENTE DELL’AZIENDA ESISTE
UN SOLO NUMERO DI MATRICOLA E VICEVERSA
62
6/062.0158
RELAZIONE 1 : Mo AD OGNI ENTITÀ DI OGNI INSIEME POSSONO
ESSERE ASSOCIATE:
l UNAl NESSUNAl PIÙ
…ENTITÀ DEL SECONDO INSIEME
MENTRE A QUESTE PUÒ CORRISPONDERE UN SOLO ELEMENTO DEL PRIMO GRUPPO
o ESEMPIO:
l A UNA CATEGORIA DI ARTICOLO POSSONO
APPARTENERE PIÙ ARTICOLI
l OGNI ARTICOLO APPARTIENE A UNA CATEGORIA
63
6/063.0158
RELAZIONE M : N
o OGNI ELEMENTO DEL PRIMO INSIEME È
CORRELATO A UNO, NESSUNO, MOLTI
ELEMENTI DEL SECONDO E VICEVERSA
o ESEMPIO:
l UN CLIENTE PUÒ ORDINARE NESSUNO, UNO, PIÙ
ARTICOLI
l OGNI ARTICOLO PUÒ ESSERE ORDINATO DA
NESSUNO, UNO, PIÙ CLIENTI
64
6/064.0158
Figura 6.3 Esempio di un semplice Entity - Relationship Model
65
6/065.0158
ERM E DBMS
o UN ERM PUÒ ESSERE TRADOTTO FACILMENTE
IN UN DBMS RELAZIONALE
l DEFINENDO PER CIASCUNA TIPOLOGIA UNA
TABELLA
l I CAMPI DELLA TABELLA CORRISPONDONO AGLI
ATTRIBUTI DEL MODELLO ERM
l I RECORD IDENTIFICHERANNO LE DIFFERENTI
OCCORRENZE
66
6/066.0159
ELABORAZIONE DI UN MODELLO FUNZIONALE
o IL MODELLO FUNZIONALE RACCOGLIE E
STRUTTURA
l LE FUNZIONI PRINCIPALI DI UN SISTEMA
INFORMATIVO
l I CONTENUTI DI ESSE
l LE RISPETTIVE RELAZIONE TRA ESSE
...COSÌ DA FORNIRE UNA VISIONE UNITARIA DEL
SISTEMA STESSO
67
6/067.0159
Figura 6.4 Modello funzionale di un sistema per il calcolo dei costi
68
6/068.0159
METODOLOGIA TOP - DOWN
o LA METODOLOGIA TOP - DOWN PERMETTE DI
IDENTIFICARE LE SINGOLE COMPONENTI CHE
COSTITUISCONO IL SISTEMA
o QUESTA METODOLOGIA ESAURISCE IL PROPRO
COMPITO QUANDO TUTTE LE FUNZIONI
AZIENDALI SONO STATE INDIVIDUATE E
RAPPRESENTATE
o LA SCOMPOSIZIONE IN COMPONENTI PUÒ
GIUNGERE FINO ALLA PSEUDOCODIFICA
69
6/069.0159
METODOLOGIA BOTTOM - UP
o SI PARTE DALLO SVILUPPO DEI MODULI DI
LIVELLO INFERIORE
o QUESTI MODULI VENGONO COMBINATI FINO A
FORMARE UN SISTEMA UNITARIO
o SI UTILIZZA QUANDO IL SOFTWARE STANDARD
DEVE ESSERE INSERITO IN UN COMPLESSO EDP
INTEGRATO
70
6/070.0160
DIAGRAMMI DI FLUSSO DEI DATI
o I DIAGRAMMI DI FLUSSO OFFRONO UNA RAPPRESENTAZIONE GRAFICA DEI FLUSSI DI INFORMAZIONI DI UNA APPLICAZIONE EDP O DI UN MODELLO FUNZIONALE
o MEDIANTE SIMBOLI STANDARDIZZATI RAPPRESENTANO:l QUALI DATI VENGONO LETTI, ELABORATI E
RESTITUITI DA UNA FUNZIONE DI ELABORAZIONEl QUALI SONO I SUPPORTI DI MEMORIA IMPIEGATIl LA DIREZIONE DEL FLUSSO DI INFORMAZIONI TRA
I PROGRAMMI DI ELABORAZIONE E I SUPPORTI DI MEMORIA
l IL TIPO DI DATI
71
6/071.0160Figura 6.5 Esempio di diagramma di flusso dei dati
72
6/072.0161
ELABORAZIONE DI UN MODELLO DI PROGETTAZIONE ORIENTATO AGLI
OGGETTIo L’APPROCCIO OO SI È DIFFUSO NON SOLO
NELLA FASE DI PROGRAMMAZIONE (C++, JAVA)
MA ANCHE NELLA FASE DI PROGETTO, OODOBJECT ORIENTED DESIGN
o FONDAMENTO DELL’APPROCCIO
l I DATI E LE MODALITÀ DI TRATTAMENTO DEGLI
STESSI VENGONO RACCOLTI IN UNA UNICA UNITÀ
DI PROGRAMMA CHIUSA DENOMINATA “OGGETTO”
73
6/073.0161
OGGETTI, CLASSI, RELAZIONI DI EREDITARIETÀ
o GLI OGGETTI AVENTI LE STESSE PROPRIETÀ
l STESSE PROCEDURE
l STESSI ATTRIBUTI
…COSTITUISCONO UNA CLASSE
o LE RELAZIONI DI EREDITARIETÀ TRA OGGETTI PERMETTONO DI ASSOCIARE AUTOMATICAMENTE
l PROCEDURE E ATTRIBUTI APPARTENENTI A UNA
CLASSE GENERALE (CLASSE SUPERIORE) A CLASSI
PARTICOLARI (CLASSI INFERIORI)
74
6/074.0161Figura 6.6 Esempio di un complesso di classi
75
6/075.0161
MESSAGGI
o L’ESECUZIONE DI UN PROGRAMMA È GENERATA DALLO SCAMBIO DI COMUNICAZIONI (MESSAGGI) TRA GLI OGGETTI
o I MESSAGGI AZIONANO L’ESECUZIONE DI UNA PROCEDURA NELL’OGGETTO RICEVENTE, LA PROCEDURA VIENE APPLICATA AGLI ATTRIBUTI DELL’OGGETTO
o IL MITTENTE DEVE SAPERE SOLO QUALI MESSAGGI INVIARE PER OTTENERE L’EFFETTO DESIDERATO
o NON SONO NECESSARIE NOZIONI RIGUARDO AL MODO IN CUI L’OGGETTO OPERA AL PROPRIO INTERNO
76
6/076.0161
DEFINIZIONE DI UN MESSAGGIO
o UN MESSAGGIO VIENE DEFINITO MEDIANTE:
l NOME
l IMMISSIONE DEI PARAMETRI PER L’ELABORAZIONE
DELL’OGGETTO RICEVENTE
o POLIMORFISMO
l QUANDO LO STESSO MESSAGGIO VIENE INVIATO AI
VARI OGGETTI RICEVENTI APPARTENENTI A UNA
MEDESIMA CLASSE E, UNA VOLTA RICEVUTO, DA
AVVIO A DIVERSE PROCEDURE
77
6/077.0161
PROGETTAZIONE LOGICA E FISICA NELLO SVILUPPO SOFTWARE
ORIENTATO AGLI OGGETTIo PROGETTAZIONE LOGICA
l STRUTTURE DI DATI, PROCEDURE E MESSAGGI
TRA LE CLASSI DI OGGETTI VENGONO DESCRITTI
INDIPENDENTEMENTE DAGLI ASPETTI TECNICI
o PROGETTAZIONE FISICA
l VENGONO CONFIGURATE.
− STRUTTURA DELLA PROCEDURA AUTOMATIZZATA
− LOGICA DI ELABORAZIONE
− INTERFACCIA UTENTE
78
6/078.0162
PROGRAMMAZIONE LOGICA E FISICACONFRONTO FRA SVILUPPO
CONVENZIONALE E SVILUPPO OOo NELLO SVILUPPO OO:
l I RISULTATI DELLA PROGETTAZIONE LOGICA
VENGONO AMPIAMENTE ASSUNTI NELLA
PROGETTAZIONE FISICA
l NON AVVIENE LA TRASFORMAZIONE, COME AVVIENE
NELL’APPROCCIO TRADIZIONALE, MA SOLTANTO IL
COMPLETAMENTO
l LA RIDUZIONE DELLA FRATTURA STRUTTURALE TRA
PROGRAMMAZIONE LOGICA E FISICA FACILITA
NOTEVOLMENTE LA MANUTENZIONE DEL SISTEMA
79
6/079.0163
CRITICHE ALL’APPROCCIO OOo NON ESISTONO METODI STABILI NELLA
ELABORAZIONE DELLO SVILUPPO ORIENTATO AGLI OGGETTI
o L’INTEGRAZIONE CON SOFTWARE GIÀESISTENTE PUÒ COMPORTARE NUOVI FATTORI DI COMPLESSITÀ
o NON SEMPRE L’APPROCCIO OO ÈVANTAGGIOSO
o AFFINCHÉ GLI OGGETTI POSSANO ESSERE EFFETTIVAMENTE RIUTILIZZATI OCCORRONO BIBLIOTECHE DI CLASSI BEN DOCUMENTATE E CIÒ RICHIEDE UN GROSSO SFORZO ORGANIZZATIVO
80
6/080.0163
CONCEZIONE DELL’ESECUZIONE DI PROGRAMMA
o LA STRUTTURA DI UN PROGRAMMA PUÒ ESSERE RAPPRESENTATA ATTRAVERSO I DIAGRAMMI STRUTTURALI
o ELEMENTI FONDAMENTALI DELLA RAPPRESENTAZIONE MEDIANTE I DIAGRAMMI STRUTTURALI SONO I BLOCCHI STRUTTURALI
o CIASCUN BLOCCO STRUTTURALE INCORPORA UNA PRECISA FUNZIONE DEL PROGRAMMA E PUÒ ESSERE AUTONOMO O INCLUSO IN UN ALTRO BLOCCO
81
6/081.0163
PROGRAMMAZIONE STRUTTURATA
o PROGRAMMAZIONE STRUTTURATA
l SI HA QUANDO LO SVILUPPO DEL CODICE SI BASA SUI DIAGRAMMI STRUTTURALI
o NELLA PROGRAMMAZIONME STRUTTURATA LA LOGICA DI ESECUZIONE DI UN PROGRAMMA
VIENE DEFINITA UTILIZZANDO SOLO TRE ELEMENTI DESCRITTIVI ELEMENTARI
l SEQUENZA
l SELEZIONE (SCELTA)
l RIPETIZIONE
82
6/082.0164
Figura 6.7 Esempio di diagramma strutturale
83
6/083.0165
MODELLI DI ARCHITETTURE EDP
o MODELLO AZIENDALE È COSTITUITO DA:
o IL MODELLO DEI DATI AZIENDALI È COSTITUITO DA STRUTTURE DI DATI CONCETTUALI PROGETTATE A LIVELLO AZIENDALE
o IL MODELLO DEFINISCE LE RELAZIONI TRA DATI E AREE AZIENDALI CHE NE NECESSITANO
o IL MODELLO DELLE FUNZIONI AZIENDALI OFFRE UNA PANORAMICA DELLE FUNZIONI CHE DEVONO ESSERE SVOLTE DALL’IMPRESA
l MODELLO DEI DATI AZIENDALIl MODELLO DELLE FUNZIONI AZIENDALI
84
6/084.0165
Figura 6.8a Prospettive di differenti strumenti descrittivi: Grafici gerarchici
85
6/085.0165Figura 6.8b Prospettive di differenti strumenti descrittivi:Entity Relationship Model
86
6/086.0165
Figura 6.8c Prospettive di differenti strumenti descrittivi: Diagramma di flusso dei dati
87
6/087.0166
MODELLI DI FUNZIONI E MODELLI DI PROCESSI GESTIONALI
o IL MODELLO DI FUNZIONI SI LIMITA ALLA
DEFINIZIONE DEI BLOCCHI DI GRANDI DIMENSIONI E ALLA DESCRIZIONE DEGLI INPUT E OUTPUT CORRELATI
o I MODELLI DEI PROCESSI GESTIONALI
STABILISCONO LE REGOLE SECONDO LE QUALI VENGONO RICHIAMATI I BLOCCHI FUNZIONALI E DESCRIVONO L’INTERAZIONE TRA LE CATENE DI
PROCESSI
88
6/088.0166
SCELTA DEGLI STRUMENTI DESCRITTIVI
o MODELLI DI DATI AZIENDALI
o MODELLI ORIENTATI ALLE FUNZIONI
l CONVIENE L’ERM
l DIAGRAMMI GERARCHICI + PROSPETTI TABULARI
l DIAGRAMMI DI FLUSSO
89
6/089.0166
ARCHITETTURA INFORMATIVA AZIENDALE
o L’ARCHITETTURA INFORMATIVA AZIENDALE è
COSTITUITA DA:
l ARCHITETTURA APPLICATIVA
l ARCHITETTURA DELLA TECNOLOGIA DELLE
INFORMAZIONI
− DESCRIZIONE CONGIUNTA DI PROGRAMMI E
PROCESSI
− RAPPRESENTAZIONE DEGLI ELEMENTI
STRUTTURALI DELL’HARDWARE
90
6/090.0166
PIANIFICAZIONE, GESTIONE E CONTROLLO NELLO SVILUPPO DEI
SISTEMI INFORMATIVI
o CONFIGURAZIONE DEI PROGETTI DI SVILUPPO
o STIMA DEI COSTI DEI PROGETTI DI SVILUPPO
91
6/091.0167
PIANIFICAZIONE DEL PROGETTO
o LA PIANIFICAZIONE DEL PROGETTO CONSISTE IN:l IDENTIFICAZIONE DELLE AREE AZIENDALI
COINVOLTEl SCELTA DELL’AMBIENTE DI SVILUPPO DEL
SOFTWAREl DEFINIZIONE DELLA SEQUENZA DI ATTIVITÀ PER
LO SVILUPPO DELLA PROCEDURA AUTOMATIZZATA
l COORDINAMENTO DELLE RISORSEl DETERMINAZIONE DELLA RESPONSABILITÀ DEL
PERSONALE COINVOLTOl INDIVIDUAZIONE DELLE SCADENZE CHE
CONSENTANO DI VERIFICARE IL PROGETTO DI SVILUPPO DEL SOFTWARE IN TERMINI DI− RISULTATI FINALI E PARZIALI RAGGIUNTI− RISPETTO DEI TEMPI E DEI COSTI PREVISTI
92
6/092.0169
CONFIGURAZIONE DEI PROGETTI DI SVILUPPO
o PIANO STRUTTURALE DEL PROGETTO
o LA CONCLUSIONE DI UN MODULO DI PROGETTO ASSOCIATO A UN PACCHETO DI ATTIVITÀ SI CHIAMA MILESTONE
o SUPPORTO PER LA PIANIFICAZIONE DEI TEMPI E DELLE SCADENZE SONO I DIAGRAMMI A BARRE (GANTT) E LE TECNICHE RETICOLARI
l SUDDIVIDE I PACCHETTI DI ATTIVITÀSTRUTTURATI GERARCHICAMENTE IN COMPITI INDIVIDUATI IN FASE DI ANALISI E PIANIFICAZIONE
93
6/093.0168
STIMA DEI COSTI DEI PROGETTI DI SVILUPPO
o I COSTI DEI PROGETTI DI SVILUPPO SOFTWARE
SONO CARATTERIZZATI DA:
l DIMENSIONI DEL SISTEMA
l REQUISITI DI QUALITÀ DELLA SOLUZIONE DA
SVILUPPARE
l DURATA DEL PROGETTO E AMBIENTE ADOTTATO
PER LO SVILUPPO DEL SOFTWARE
94
6/094.0168
METODI PER LA STIMA DEI COSTI
o METODO PER ANALOGIA
l LA STIMA DELLE RISORSE NECESSARIE VIENE
EFFETTUATA ATTRAVERSO UN CONFRONTO PER
SINGOLI FATTORI TRA
− UN INTERO PROCESSO DI SVILUPPO
− ALTRI PROGETTI GIÀ CONCLUSI PER CUI ESISTA
UN VALORE DEFINITO DEI COSTI SOSTENUTI
o METODO DEI FUNCTION POINT
95
6/095.0168
METODO DEI FUNCTION POINT 1
o QUESTA TECNICA DI MISURAZIONE PREVEDE DI CONTEGGIARE IL NUMERO DI FUNZIONI FORNITE ALL’UTENTE DALL’APPLICAZIONE DA MISURARE
o 5 TIPI DI FUNZIONIl INPUT ESTERNI
l OUTPUT ESTERNI
l INTERROGAZIONI ESTERNE
l FILE LOGICI INTERNI
l FILE ESTERNI DI INTERFACCIA
96
6/096.0168
METODO DEI FUNCTION POINT 2
o AD OGNI FUNCTION POINT INDIVIDUATO VIENE
ASSEGNATO UN PESO IN BASE:
l REQUISITI DI PERFORMANCEl COMPLESSITÀ ALGORITMICHEl ESIGENZE DI RIUSO
l ALLA COMPLESSITÀ (BASATA SUL NUMERO DI DATI ELEMENTARI GESTITI)
o AD OGNI APPLICAZIONE VIENE ASSEGNATO UN
PESO SULLA BASE DI:
97
6/097.0169
METODO DEI FUNCTION POINT 3
o IL RISULTATO DEL METODO DEI FUNCTION
POINT È:
l UN NUMERO ADIMENSIONALE CHE
RAPPRESENTA LA QUANTITÀ DI FUNZIONI
OFFERTE ALL’UTENTE
l DAL NUMERO DI FUNCTION POINT È POSSIBILE
DEDURRE L’IMPEGNO DI RISORSE
98
6/098.0169
Figura 6.9 Function Point
99
6/099.0170
SCELTA E INTEGRAZIONE DEL SOFTWARE STANDARD
o SOFTWARE STANDARD O PACKAGE APPLICATIVO
o PRESUPPOSTO PER L’USO DI SOFTWARE STANDARD È CHE LE ESIGENZE DELL’AZIENDA COINCIDANO CON LE FUNZIONALITÀ OFFERTE DAL SOFTWARE STANDARD DISPONIBILE SUL MERCATO
l PROCEDURA GIÀ ANALIZZATA, PROGETTATA E
DOCUMENTATA CHE VIENE OFFERTA A UNA
AZIENDA
100
6/100.0170
VANTAGGI DEL SOFTWARE STANDARD 1
☺ COSTI DI ACQUISTO E DI PERSONALIZZAZIONE INFERIORI A QUELLI PER LA REALIZZAZIONE DI SOFTWARE DEDICATO
☺ TEMPI DI IMPLEMENTAZIONE MOLTO INFERIORI RISPETTO AL SOFTWARE DEDICATO
☺ IL SOFTWARE STANDARD È UN PRODOTTO MATURO E QUINDI HA MENO ERRORI RISPETTO AL SOFTWARE DEDICATO
101
6/101.0170
VANTAGGI DEL SOFTWARE STANDARD 2
☺ È POSSIBILE ACQUISIRE KNOW HOW GESTIONALE E ORGANIZZATIVO NON DISPONIBILE ALL’INTERNO DELL’AZIENDA
☺ I PACKAGE APPLICATIVI PIÙ DIFFUSI FACILITANO L’INTEGRAZIONE INTERAZIENDALE
☺ LE RISORSE EDP POSSONO ESSERE RIALLOCATE SU COMPITI DI PARTICOLARE RILEVANZA STRATEGICA
102
6/102.0170
SVANTAGGI DEL SOFTWARE STANDARD
L SUSSISTONO SPESSO DISCREPANZE NOTEVOLI TRA I REQUISITI AZIENDALI E IL SOFTWARE STANDARD
L LA PIATTAFORMA HARDWARE AZIENDALE PUÒ RISULTARE INCOMPATIBILE CON UN PRODOTTO SOFTWARE PRECISO
L ALL’INTERNO DELL’AZIENDA VI È UN LIMITATO KNOW HOW EDP
L RISCHIO DI DIPENDENZA DAL FORNITORE
103
6/103.0170
Figura 6.10 Fasi per l ’Installazione di software standard
104
6/104.0171
LA QUALITÀ DEL SOFTWARE E DEI SISTEMI
o ALCUNI ASPETTI DELLA QUALITÀ DEL SOFTWARE
l FACILITÀ D’USO
l AMBITO FUNZIONALE ADEGUATO E OPPORTUNI
PROCESSI PER LA RISOLUZIONE DEI PROBLEMI
l POSSIBILITÀ DI VALUTAZIONE DEL SISTEMA
INFORMATIVO
l CONFIGURAZIONE MINIMA DELL’HARDWARE
o LA NORMATIVA ISO9000 PRESENTA LINEE GUIDA SPECIALI PER LO SVILUPPO DEL SOFTWARE