L’Informatica dal Problema alla
Soluzione
Il Processo di sviluppo del
software
Mario Capurso
http://info.bazarinfo.info
Il Problema
La necessità di risolvere problemi è una
esigenza umana fondamentale
Questa esigenza presume l’esistenza di diverse
categorie di persone:



Coloro che sentono il problema e desiderano
risolverlo (utenti finali)
Coloro che cercano soluzioni per il problema
(ricercatori, analisti, progettisti)
Coloro che costruiscono strumenti e dispositivi che
risolvono i problemi (costruttori)
Il Problema



Intuibile
Formalizzabile
Risolubile
Risolvere il Problema
Per risolvere un problema è necessario




Intuirlo
Esprimerlo con formule
Trovare un metodo di soluzione
Usare il metodo correttamente
E’ sempre possibile tutto ciò ?
Il Problema: risolubile ?
Col computer
Risolubile
Problema formalizzabile
Problema intuibile
Problema non
esprimibile
Il Problema: non risolubile ?
Perché:





Non esprimibile
Esprimibile solo intuitivamente
Formalizzabile ma non risolubile
Formalizzabile, risolubile ma non col
computer
Formalizzabile, risolubile col computer ma
in tempi e costi inaccettabili
Il Ciclo di sviluppo del
Software







Analisi
Progettazione
Programmazione
Test (Ricerca e correzione degli errori)
Documentazione
Installazione
Manutenzione
Il Sistema

Un Sistema è un insieme di Componenti
legate da forme di Interazione
In un Sistema bisogna
osservare…
•Obiettivo
•Strumenti
Ambiente
Componente
•Risorse
•Procedure
•Variabili di Stato
Interazione
•Stati
•Eventi
Un Sistema può essere…





Naturale o Artificiale
Semplice o Complesso
Deterministico o Probabilistico
Aperto o Chiuso
Con o senza Feedback
Notazione di Yourdon-De Marco
Componente
ulteriormente
decomponibile
Ambiente
Interazione
Archivio
Componente
NON
ulteriormente
decomponibile
Esempio: Il nostro Istituto
Chiede libretto
Didattica
Studenti
La nostra
città
Archivio
studenti
Fa Iscrizione
Preside
Genitori
Istituto
U.Tecnico
Fase di Analisi



Obiettivo: Analizzare i termini del problema
Lavora l’Analista di Sistema
Produce un Documento di Analisi





Sintomi e conseguenze del problema
Analisi dell’esistente
Analisi dei Requisiti
NON deve produrre una soluzione
Prepara il terreno per il progettista
Analisi dell’esistente



Descrive il sistema esistente, usando la
notazione di Yourdon-De Marco
Riporta e descrive obiettivo, ambiente,
componenti, interazioni, risorse, strumenti,
procedure, variabili di stato, stati ed eventi
del sistema
Ripete la cosa per le componenti
ulteriormente decomponibili (sottosistemi)
Analisi dei Requisiti





Riporta le caratteristiche che il cliente
desidera siano presenti nella soluzione
Un requisito comincia con la frase “La
soluzione dovrebbe…” e ha una priorità
Priorità alta: deve esserci per forza
Priorità media: meglio se c’è
Priorità bassa: non è importante
Tipi di Requisiti
Secondo la Metodologia ISO (International Standard
Organization) ODP (Open Distributed Processing), i
Requisiti vanno raggruppati in cinque Punti di Vista
(Viewpoints):





Enterprise (Parlano dell’utente, di uso, tempi e costi)
Information (Parlano di Informazioni da gestire)
Computation (Parlano di Funzionalità da eseguire)
Engineering (Parlano di Architettura da possedere)
Technology (Parlano di Tecnologia da utilizzare)
Esempi





Enterprise: La soluzione dovrebbe essere usata…
Information: La soluzione dovrebbe gestire le
seguenti informazioni…
Computation: La soluzione dovrebbe realizzare le
seguenti funzionalità…
Engineering: La soluzione dovrebbe avere la
seguente architettura…
Technology: La soluzione dovrebbe usare la seguente
tecnologia…
Analisi e Costruzione di
Prototipi



L’ingegnere edile mostra al cliente un modellino del
palazzo prima di costruirlo, per capire meglio le sue
esigenze
Così l’informatico potrebbe mostrare al cliente un
prototipo usa e getta del programma prima di
costruirlo, per capire meglio le sue esigenze
(REQUISITI)
Questa tecnica viene chiamata di Quick Prototyping
Fase di Progettazione



Obiettivo: Progettare una o più soluzioni
Lavora il Progettista di Sistema
Produce un Documento di Progettazione






Soluzione 1
Soluzione 2
Soluzione n
Analisi Costi-Benefici
Richiede che il cliente decida quale soluzione
realizzare (oppure che decida di lasciar tutto com’è
adesso)
Prepara il terreno per la realizzazione della soluzione
Soluzioni Possibili





Lascia tutto com’è adesso
Compra invece che costruire
Sostituisci archivi manuali con archivi
informatici e procedure manuali con
procedure informatiche (soluzione di minimo
impatto)
Guarda le soluzioni sul mercato e prendi il
meglio da tutte
Inventati qualcosa, perché non esiste nulla da
cui copiare
Come appare una Soluzione ?



Descrizione della Soluzione
Descrizione del sistema progettato, usando la notazione
di Yourdon-De Marco
Descrizione di obiettivo, ambiente, componenti,
interazioni, procedure, risorse, strumenti, variabili di
stato, stati ed eventi del sistema progettato. Descrivere
le procedure in pseudocodice. Descrivere gli archivi come tabelle


Ripetere la cosa per le componenti ulteriormente
decomponibili (sottosistemi)
Descrizione dei requisiti utente posseduti e non
posseduti dalla soluzione
Suggerimenti per una
Soluzione di Minimo Impatto

Ogni requisito di tipo Information
“La
soluzione dovrebbe gestire le seguenti informazioni
diventa un archivio X ed un
insieme di funzionalità “inserisci, modifica,
sull’entità X…”
cancella, stampa, vai all’inizio, alla fine, avanti,
indietro nell’archivio X” (diverranno form e bottoni in
Visual Basic, moduli e sottoprogrammi in C, classi e
metodi in Java…)
Ulteriori Suggerimenti



Ogni procedura manuale diventa una
procedura informatica
Ogni requisito di tipo computation
diventa una procedura di tipo
informatico
Le procedure informatiche vengono
raggruppate in menù
Analisi Costi-Benefici




Analizza in maniera comparativa costi e
benefici delle varie soluzioni
Cerca di quantificare i benefici di
ciascuna soluzione
Distingue i costi iniziali dai costi
ricorrenti
Serve al cliente per decidere quale
soluzione realizzare