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: dibella@ost.it web: http://www.ost.it

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%

Software come prodotto industriale Caratteristiche Requisiti forniti da terze parti Numero elevato di funzionalità Sviluppo in team Integrazione Rischi Instabilità dei requisiti Dominio del problema Tempi ridotti Evoluzione tecnologica Aree del Project Management Scope Communication Cost Time Human Resources

Il processo di sviluppo a “Cascata” Modelli di processo Il processo di sviluppo a “Cascata” Analysis Design Development Test

Modello a cascata “ricorsivo” (B model - V model) Modelli di processo Modello a cascata “ricorsivo” (B model - V model) La 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

Il processo di sviluppo a “Spirale” Modelli di processo Il processo di sviluppo a “Spirale” Test Analysis Deploy Unit Requirements Test Subsystem Requirement Evaluation System Requirement Evaluation Business Requirements Risk Analysis Proof of Concept Conceptual Design First Build Logical Design Second Build Physical Design Development Design Final Build Final Design

Il processo di sviluppo “Extreme Programming” Modelli di processo Il processo di sviluppo “Extreme Programming” (derivato da Rapid Prototyping [Rad]) Development Analysis Test Design

Il processo di sviluppo “Problem Solving” (Controlled iteration) Modelli di processo Il processo di sviluppo “Problem Solving” (Controlled iteration) Analysis Analysis Analysis Analysis Design Design Development Development Design Test Design Development Test Development Test Test Concept Design Execution Release

Scoping: modello degli attori Analysis Scoping: modello degli attori Sistema da realizzare Acquirente Agente Database Amministrazione Amministratore Sistema Attore: persona o macchina che interagisce con il sistema da realizzare

Scoping: diagramma degli use-case 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 Attore 3 Use Case 1.1 Use Case 2.1 Use Case 3.1 Use Case 1.2 Use Case 2.2 Use Case 2.3

Architettura: Organizzazione MVC (Model-View-Control) Design Architettura: Organizzazione MVC (Model-View-Control) Maschere Interfacce Forms Dialogo con utente Livello delle viste 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

Maschera visualizzazione Diagramma di sequenza di un use-case Design Architettura: Logical View Pannello comandi Carica dati Dato Maschera visualizzazione click beginFunc Attore requestData getData displayData Diagramma di sequenza di un use-case Viste Controlli Use case Attore Modelli di dati Dati

Architettura: Meccanismi chiave Design Architettura: Meccanismi chiave Insieme di funzionalità del sistema non definite dagli use case. Provengono da: Requisiti di sistema Esigenze implicite del sistema Esempi 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 Dati Concorrenza Package 1 Tabella 1 Use Case 1 Use Case 2 Multilingua Package 2 Vista 1 Package 3 Vista 1 Tabella N Vista 2 Vista N

{ Scenari } Test Livelli di testing System test User Test System Test Integration Test Beta Test System test { Scenari } Use case Attore Scenario:possibile implementazione di un use-case

Gestione delle release Test Gestione delle release Regressione Quando durante la correzione di un errore si introducono nuovi errori Nuove Funzionalità System Test Bug Fixing Integration Test Nuova Release Segnalazioni Utente Integration Test Moduli corretti Elenco moduli dipendenti Regression Test Nuova Release Logical View

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 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

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

UML based (Rational Rose) Soluzione 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

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