Il processo di sviluppo
del software
Dr. Dario Di Bella
OST S.r.l. Organizzazione Sistemi Tecnologie
Via T. Aspetti 157 - 35134 Padova
Tel.
049-609078
e-mail: [email protected]
web:
http://www.ost.it
 OST
Ingegneria del software
 Che
cos’è il software?
 Una
creazione artistica?
 Un prodotto industriale
 Alcuni
attributi del software
 pervasività
 immaterialità
 complessità
 La
crescita della domanda del software
 incremento
annuale (a livello mondiale) 12%
 incremento annuale del numero degli addetti 4%
 OST
Software come prodotto industriale
 Caratteristiche




Requisiti forniti da terze parti
Numero elevato di funzionalità
Sviluppo in team
Integrazione
Aree del Project Management
Scope
Communication
Cost
 Rischi




 OST
Instabilità dei requisiti
Dominio del problema
Tempi ridotti
Evoluzione tecnologica
Time
Human Resources
Modelli di processo
 Il
processo di sviluppo a “Cascata”
Analysis
Design
Development
Test
 OST
Modelli di processo
 Modello
 La
a cascata “ricorsivo” (B model - V model)
ricorsività è spesso imposta dagli eventi:
in particolare dall’instabilità dei requisiti
 dagli errori e dalle omissioni
 da una precisa scelta metodologica

Analysis
Design
Development
Test
 OST
Modelli di processo
 Il
processo di sviluppo a “Spirale”
Test
Analysis
Deploy
Unit
Requirements
Test
Subsystem
Requirement
Evaluation
Evaluation
Risk
Analysis
Proof of
Concept
First
Build
Second
Build
Development
Final
Build
 OST
System
Requirement
Business
Requirements
Conceptual
Design
Logical
Design
Physical
Design
Design
Final
Design
Modelli di processo
 Il processo di sviluppo “Extreme Programming”
(derivato da Rapid Prototyping [Rad])
 OST
Development
Analysis
Test
Design
Modelli di processo
 Il
processo di sviluppo “Problem Solving” (Controlled iteration)
Analysis
Analysis
Analysis
Design
Design
Analysis
Development
Design
Development
Design
Test
Development
Development
 OST
Test
Test
Test
Concept
Design
Execution
Release
Analysis
 Scoping:
modello degli attori
Acquirente
Sistema da realizzare
Agente
Database Amministrazione
Amministratore Sistema
Attore: persona o macchina che interagisce con il sistema da realizzare
 OST
Analysis
 Scoping:
diagramma degli use-case
Attore
Use case
Use case: sequenza di interazioni tra attore e sistema al fine di realizzare
un obiettivo funzionale (funzionalità)
Sistema da
realizzare
Attore 1
Attore 2
Use Case 1.1
Use Case 2.1
Use Case 1.2
Use Case 2.2
Use Case 2.3
 OST
Attore 3
Use Case 3.1
Design
 Architettura:
Organizzazione MVC (Model-View-Control)
Livello delle viste
 OST
Maschere
Interfacce
Forms
Dialogo con utente
Livello dei controlli
Moduli comunicazione viste-dati
Utilità di calcolo
Livello del modello dei dati
Moduli per il trasporto dei dati
Livello dei dati
Tabelle
File
Design
 Architettura:
Logical View
Pannello comandi
click
Attore
beginFunc
Carica dati
Dato
Maschera visualizzazione
requestData
getData
displayData
Diagramma di sequenza di un use-case
Viste
Controlli
Attore
Use case
Modelli di dati
Dati
 OST
Design
 Architettura:
Meccanismi chiave
Insieme di funzionalità del sistema non definite dagli use case.
Provengono da:


Requisiti di sistema
Esigenze implicite del sistema
Esempi






 OST
Meccanismo di identificazione
Stile dell’interfaccia grafica
Gestione della concorrenza
Multilinguaggio
Organizzazione della comunicazione
Gestione degli errori
Design
 Architettura:
WBS
Architettura
Meccanismi
chiave
Viste
Controlli
Concorrenza
Multilingua
Package 1
Use Case 1
Vista 1
Use Case 2
Vista 1
Tabella 1
Package 2
Package 3
Tabella N
Vista 2
Vista N
 OST
Dati
Test
 Livelli




di testing
User Test
System Test
Integration Test
Beta Test
 System
Attore
test
Use case
{ Scenari }
Scenario:possibile implementazione di un use-case
 OST
Test
 Gestione
delle release
Nuove
Funzionalità
System Test
Bug Fixing
Integration
Test
Nuova
Release
Segnalazioni
Utente
 Regressione

Quando durante la correzione di un errore si introducono nuovi errori
Moduli
corretti
Logical View
 OST
Integration
Test
Elenco
moduli
dipendenti
Regression
Test
Nuova
Release
Gestione delle modifiche
 Un prodotto software è il tipo prodotto più soggetto alle richieste
di modifica
Motivazioni:




Immaterialità del software
Scarsa conoscenza del dominio del problema
Finché non vedo non credo, non so
Nuove idee fornite proprio dalla soluzione software
Trattamento delle richieste di modifica




 OST
Metodo preventivo: ottenere il maggior numero di agreement sul prodotto durante la fase
iniziale di analisi
Valutare sia il costo di realizzazione che il costo di impatto sul già fatto durante le
successive fasi
Valutare l’impatto sui tempi di progetto e sulle risorse di progetto
Durante la fase di sviluppo, rinviare ad un altro progetto di realizzazione tutte le richieste
di modifica che hanno impatto sull’architettura
Documentazione del software
Tipi di documentazione
 Documentazione di analisi
Destinata al committente e all’architetto software
Utilizzare strumenti e notazioni con forte impatto visivo e significato chiaro anche per un
non esperto del software
Deve descrivere lo scope di progetto chiaramente e completamente
Base degli accordi contrattuali
 Documentazione
di design e realizzazione
Destinata al team di progetto
Utilizzare strumenti e notazioni tecniche precise e non ambigue
Riferire sempre i documenti di analisi
Documentare il più possibile
Automatizzare
Divulgare la documentazione
 OST
Motivi di insuccesso
Principali motivi di insuccesso di un progetto software:
 Scarsa conoscenza del dominio del problema
 Accordi contrattuali non chiari
 Analisi non eseguita
 Completare l’analisi prima di iniziare
 Tempi di realizzazione eccessivamente ridotti
 Non attenta valutazione dei tempi e dei sovraccarichi sulle risorse
 Scarsa comunicazione nel team di progetto
 Inadeguatezza tecnologica
 Isteresi tecnologica
 Documentazione insufficiente
 Impossibilità di assicurare la manutenzione del prodotto realizzato
 Inadeguatezza del prodotto al dominio del problema
 OST
Strumenti
 Microsoft
Project
 UML based (Rational Rose)
 Soluzione OST:
 Pianificazione
e schedulazione
 Gestione risorse di progetto
 Gestione margini a partire dai
rischi di progetto
 Comunicazione tra gli
stakeholder
 Gestione documenti e workflow
Disponibilità in OST per tesi e stage post laurea su:
 Project Management
 Process Management
 Documentation Management
 Strumenti software per il Project Management e per il Documentation Management
 OST
Bibliografia
Software Engineer:
 M.R. Cantor, “Object-Oriented Project Management with UML”, Wiley Computer
Publishing, 1998
Extreme Programming:
 http://www.extremeprogramming.org
 K. Beck, “Extreme Programming Explained: Embrace Change”, Addison-Wesley, 1999
OO e UML:
 G. Booch, “Object-Oriented Analysis and Design”, Addison-Wesley, 1994
 M. Fowler, K. Scott, “UML Distilled, Second Edition”, Addison-Wesley, 2000
Modello MVC:
 http://ootips.org/mvc-pattern.html
 E. Gamma et al., “Design Patterns”, Addison-Wesley, 1995
 F. Bushmann, “Pattern Oriented Software Architecture”, Wiley Computer Publishing, 1996
 OST