Il processo di sviluppo

Presentazione sul tema: "Il processo di sviluppo"— Transcript della presentazione:

1 Il processo di sviluppo
del software Dr. Dario Di Bella OST S.r.l. Organizzazione Sistemi Tecnologie Via T. Aspetti Padova Tel web:

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

3 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

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

5 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

6 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

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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

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

16 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

17 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

18 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

19 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

20 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

21 Bibliografia Software Engineer:
M.R. Cantor, “Object-Oriented Project Management with UML”, Wiley Computer Publishing, 1998 Extreme Programming: 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: E. Gamma et al., “Design Patterns”, Addison-Wesley, 1995 F. Bushmann, “Pattern Oriented Software Architecture”, Wiley Computer Publishing, 1996