Redazione e Presentazione di Progetti Informatici Corso di Laurea in Informatica Facoltà di Scienze Matematiche, Fisiche e Naturali Massimo Ruffolo E-mail: ruffolo@icar.cnr.it Web: http://www.icar.cnr.it/ruffolo Istituto di CAlcolo e Reti ad alte prestazioni del Consiglio Nazionale delle Ricerche (ICAR-CNR) Exeura s.r.l. Spin-off dell Università della Calabria Massimo Ruffolo RPPI 2006/2007 1 Ingegneria del Software Cenni sulle metodologie: Zachman Framework Feature Driven Development Extreme Programming COSM La metodologia Exeura Massimo Ruffolo RPPI 2006/2007 2 1
Ingegneria del Software: Zachman Framework Massimo Ruffolo RPPI 2006/2007 3 Ingegneria del Software Il valore di una metodologia sta nell Approccio strutturato alla realizzazione di un servizio/prodotto, ciò consente di: identificare al meglio gli obiettivi intermedi e finali ottimizzare l impiego di risorse (risparmiare tempo e danaro) controllore i risultati intermedi e finali (non perdere di vista li obiettivi) Massimo Ruffolo RPPI 2006/2007 4 2
Zachman Framework VA Enterprise Architectu re DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Based on work by John A. Zachman SCOPE (CONTEXTUAL) Things Important to the Business Processes Performed Business locations Important Organizations Ev ents Significant to the Business Business Goals and Strategy SCOPE (CONTEXTUAL) Planner Entity = C lass of Business Thing F unc tion = C lass of Business Process Node = Major Business Locations People = Major Organizations Time = Major Business Event Ends/Means = Major Business Goals Planner ENTERPRISE MODEL (CONCEPTU AL) Semantic Model Business Process Model Business Logistics System Work Flow Model Master Schedule Business Plan ENTERPRISE MODEL (CONCEPTU AL) Owner Ent = Business Entity Proc = Business Process Rel = Business Relationship I/O = Business Resources Node = Business Location People = Organization Unit T ime = Business Event Link = Business Linkage Work = Work Product Cycle = Business Cycle End = Business Objectiv e Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) Data Model Application Architecture Distributed System Architecture Human Interface Architecture Processing Structure Business Rule Model SYSTEM MODEL (LOGICAL) Designer Ent = Data Entity R el = Data Relationship Proc = Application Function Node = IS Function People = Role I/O = U ser View s Link = Line Characteristics Work = Deliv erable Time = System Event Cycle = Processing Cycle End = Structural Assertion Means = Action Assertion Designer TECHNOLO GY MODEL (PHYSICAL) Data Model System Design Technology Architecture Presentation Architecture Control Structure Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder Ent = Segm ent/t able Rel = Pointer/Key Proc = Computer Function Node = Hardware/Softw are People = User I/O = Data Elements/Sets Link = Line Specifications Work = Screen Form at Time = Ex ecute Cycle = Component Cycle End = Condition Means = Action Builder DETAILED Data REPRESENTATIONS Definition (OUT-OF-CONTEXT) Program Network Architecture Security Architecture Timing Definition Rule Design DETAILED REPRESENTATIONS (OUT-OF-CONTEXT) Sub-Contractor Ent = Field Rel = Address Proc = Language Statement Node = Addresses I/O = C ontrol Block Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-Condition Means = Step Sub-Contractor FUNCTIONING ENTERPRISE Data Function Network Organization Schedule Strategy FUNCTIONING ENTERPRISE Ent = Proc = Node = People = Time = End = Rel = I/O = Link = Work = Cycle = Means = DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Massimo Ruffolo RPPI 2006/2007 5 Zachman Framework Row 1 Scope External Requirements and Drivers Business Function Modeling Row 2 Enterprise Model Business Process Models 1 Row 3 System Model Models Requirements Definition Row 4 Technology Model Models Solution Definition and Development Row 5 Deployment Row 6 Enterprise Enterprise Evaluation 2 3 4 5 6 Massimo Ruffolo RPPI 2006/2007 6 3
Framework Rules Basic Model = Entities and Relationships Rule 1: Columns have no order Entity Relationship Entity Rule 2: Each column has a simple, basic model Rule 3: Basic model of each column is unique Rule 4: Each row represents a distinct view Rule 5: Each cell is unique Rule 6: Combining the cells in one row forms a complete description from that view Massimo Ruffolo RPPI 2006/2007 7 Zachman Framework Row 1 Scope/Planner s View Motivation/ Business goals, objectives and performance measures related to each function Function/ High-level business functions External Requirements and Drivers Business Function Modeling Data/ High-level data classes related to each function 1 People/ Stakeholders related to each function Network/ VA locations related to each function Time/ Cycles and events related to each function Massimo Ruffolo RPPI 2006/2007 8 4
Zachman Framework Row 2 Enterprise Model/Designer s View Motivation/ Policies, procedures and standards for each process Function/ Business processes Business Process Models Business Function Allocation Elimination of Function Overlap and Ambiguity Data/ Business data People/ VA roles and responsibilities in each process 2 Network/ VA locations related to each process Time/ Events for each process and sequencing of integration and process improvements Massimo Ruffolo RPPI 2006/2007 9 Zachman Framework Row 3 System Model/Designer s View Motivation/ VA policies, standards and procedures associated with a business rule model Function/ representation of information systems and their relationships Models Project Management Requirements Definition Data/ data models of data and data relationships underlying VA information People/ representation of access privileges constrained by roles and responsibilities Network/ representation of the distributed system architecture for VA locations Time/ events and their triggered responses constrained by business events and their responses 3 Massimo Ruffolo RPPI 2006/2007 10 5
Zachman Framework Row 4 Technology Model/Builder s View Motivation/ VA business rules constrained by information systems standards Models Technology Management Solution Definition and Development Function/ Specifications of applications that operate on particular technology platforms Data/ Database management system (DBMS) type requirements constrained by logical data models People/ Specification of access privileges to specific platforms and technologies 4 Network/ Specification of network devices and their relationships within physical boundaries Time/ Specification of triggers to respond to system events on specific platforms and technologies Massimo Ruffolo RPPI 2006/2007 11 Motivation/ VA business rules constrained by specific technology standards Zachman Framework Row 5 /Integrator s View Configuration Management Deployment Function/ Programs coded to operate on specific technology platforms Data/ Data definitions constrained by physical data models People/ Access privileges coded to control access to specific platforms and technologies Network/ Network devices configured to conform to node specifications Time/ Timing definitions coded to sequence activities on specific platforms and technologies 5 Massimo Ruffolo RPPI 2006/2007 12 6
Zachman Framework Row 6 Enterprise/User s View Motivation/ Operating characteristics of specific technologies constrained by standards Enterprise Operations Management Evaluation Function/ computer instructions Data/ Data values stored in actual databases People/ VA personnel and key stakeholders working within their roles and responsibilities Network/ Sending and receiving messages 6 Integrated Integrated Time/ Timing definitions operating to sequence activities Massimo Ruffolo RPPI 2006/2007 13 VA Zachman Framework Portal Massimo Ruffolo RPPI 2006/2007 14 7
Ingegneria del Software: Feature Driven Development (FDD) Massimo Ruffolo RPPI 2006/2007 15 FDD E una via di mezzo fra metodologia leggera e approccio tradizionale Propone una robusta fase di analisi e progettazione, integrata con un modello di sviluppo agile Si focalizza sullo sviluppo di funzionalità "tangibili" per il cliente; di fatto la Feature è una funzionalità che deve avere un valore per il committente e che "guida" il ciclo di sviluppo Massimo Ruffolo RPPI 2006/2007 16 8
FDD Massimo Ruffolo RPPI 2006/2007 17 FDD Ideata da Jeff De Luca e Peter Coad. E una via di mezzo fra metodologia leggera e approccio tradizionale. Propone una robusta fase di analisi e progettazione, integrata con un modello di sviluppo agile E una forma di sviluppo guidata dalle funzionalità da realizzare E strettamente basata sull utilizzo di UML e in particolare sulla versione colorata di UML ideata dagli autori Sono disponibili diversi strumenti di supporto free, alcuni anche open source Esiste una community molto attiva che si occupa di questa metodologia e dei sui strumenti Massimo Ruffolo RPPI 2006/2007 18 9
FDD Pur essendo molto meno conosciuta di Extreme Programming è forse il miglior approccio metodologico allo sviluppo del software Dal confronto diretto emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di Extreme Programming anche se la prima ha una fase di progettazione classica che la seconda elimina proprio per guadagnarne in flessibilità Massimo Ruffolo RPPI 2006/2007 19 FDD I dettagli delle fasi di sviluppo sono pochi e semplici. Un progetto è diviso in cinque fasi, dette processi: sviluppare un modello generale criteri d ingresso: avere scelto gli esperti del problema, i capiprogrammatori ed il capo-architetto attività: il project manager deve formare il team di modellazione; il team di modellazione deve offrire una panoramica del dominio del problema, preparare i documenti funzionali e, diviso in piccoli gruppi, sviluppare il modello; il capo-architetto deve rifinire il modello generale ad oggetti insieme al team di modellazione e scrivere le note al modello insieme ai capi-programmatori; verifica: il team di modellazione deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti criteri d uscita: avere definito il modello ad oggetti avendo quindi a disposizione i diagrammi delle classi, i metodi e gli attributi delle classi, la sequenza delle classi (se esiste), le note al modello Massimo Ruffolo RPPI 2006/2007 20 10
FDD costruire una lista di funzionalità criteri d ingresso: avere scelto gli esperti del problema, il capoprogrammatore ed i capi-architetti attività: il project manager deve formare il team della lista delle funzionalità che deve comprendere i capi-programmatori del team di modellazione; il team della lista delle funzionalità deve definire la lista delle funzionalità in termini di azione-risultato-oggetto verifica: il team della lista delle funzionalità deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti criteri d uscita: avere definito la lista delle funzionalità avendo quindi a disposizione la lista delle aree oggetto, la lista delle attività di business per ogni area oggetto, la lista delle funzionalità che soddisfino tutti i punti di ogni lista delle attività; Massimo Ruffolo RPPI 2006/2007 21 FDD Pianificare per funzionalità criteri d ingresso: è stato portato a termine il processo costruire una lista di funzionalità attività: il project manager deve formare il team di progettazione che comprende capi-programmatori e manager dello sviluppo; il team di progettazione deve definire la sequenza di sviluppo, assegnare le attività di business ai capi-programmatori ed assegnare le classi agli sviluppatori verifica: il team di progettazione deve effettuare un autoverifica sul lavoro svolto criteri d uscita: avere definito un piano di sviluppo comprendente le attività di business con le date di completamento ed i capiprogrammatori responsabili assegnati, la date di completamento delle aree oggetto (derivate da quelle delle attività di business), la lista delle classi con relativi sviluppatori Massimo Ruffolo RPPI 2006/2007 22 11
FDD Progettare per funzionalità criteri d ingresso: è stato portato a termine il processo pianificare per funzionalità attività: ogni capo-programmatore forma il team delle funzionalità; ogni esperto del problema definisce la strada per affrontare il problema e risolverlo; il team delle funzionalità studia i documenti dei requisiti delle proprie funzionalità; il team di progettazione sviluppa i diagrammi di sequenza; il capo-programmatore raffina il modello ad oggetti per definire se scrivere o modificare classi, metodi, attributi; il team delle funzionalità scrive le classi e gli header dei metodi verifica: il team delle funzionalità ispeziona il progetto in tutti i suoi aspetti funzionali e temporali criteri d uscita: avere definito un pacchetto di progettazione completo che comprenda un documento esplicativo dell intero progetto con le specifiche referenziate (se esistono riferimenti), i diagrammi di sequenza, le alternative di progetto (se esistono), il modello ad oggetti completo di classi, metodi e attributi, gli header di classi e metodi, una todo list con un calendario delle scadenze per ogni attività ed ogni membro del team Massimo Ruffolo RPPI 2006/2007 23 FDD Sviluppare per funzionalità criteri d ingresso: è stato portato a termine il processo pianificare per funzionalità ed è stato ispezionato con successo il progetto in tutti i suoi aspetti funzionali e temporali attività: il team delle funzionalità implementa classi e metodi, ispeziona il codice ed effettua i test unitari; il capo-programmatore decide (dopo i test unitari) insieme al team delle funzionalità quali classi siano promuovibili come utili alla costruzione del progetto in riguardo alle funzionalità richieste verifica: il capo-programmatore sovrintende affinché siano completate effettivamente in tutti i punti dal team delle funzionalità l ispezione dei codici ed la soddisfazione dei test unitari criteri d uscita: avere ottenuto classi e metodi che siano stati ispezionati e testati con successo, infine promossi all integrazione nel progetto (ovviamente a copertura di tutte le funzionalità previste Massimo Ruffolo RPPI 2006/2007 24 12
FDD Feature Driven Development non richiede esplicitamente la stesura di documentazione, ma obbliga all utilizzo dei diagrammi UML. Questo per avere una base decisionale che sia stabile durante tutto il processo di sviluppo, solo in seconda battuta sarà utile per scrivere una documentazione formale, se richiesta Nel corso del progetto ci sono molti documenti che devono essere disponibili per i diversi attori, quindi la miglior soluzione è organizzare un sito web interno che contenga tutte le informazioni sul progetto: la lista di sviluppatori ed esperti del problema, il modello UML con i commenti, i forum di discussione, le convenzioni di scrittura del codice, la lista degli strumenti e delle librerie usate, i report dei test unitari, lo status del progetto, la timeline comprensiva della pianificazione futura, ecc... Massimo Ruffolo RPPI 2006/2007 25 FDD Durante lo sviluppo, organizzato in iterazioni brevi, si forma una struttura gerarchica con figure a metà strada fra il project manager e gli sviluppatori: i capiprogrammatori. Questi sono a capo di ogni singola iterazione, che quindi possono essere numerose e procedere parallelamente, scegliendo anche il team (composto da 3-5 persone) che se ne occuperà L esperienza dei capi-programmatori e la frammentazione del lavoro in iterazioni, sono i meccanismi di controllo e regolazione di Feature Driven Development. All inizio di ogni iterazione si organizzano delle riunioni di progettazione che servono a far confrontare i membri del team e ad ottenere la documentazione del codice Massimo Ruffolo RPPI 2006/2007 26 13
FDD La stesura del codice prevede l utilizzo rigoroso di uno standard comune di scrittura e il ricorso ad i test unitari, che possono essere organizzati a discrezione dei capiprogrammatori Date le numerose riunioni effettuate prima di cominciare a scrivere il codice, questa attività diventa qualcosa di meccanico, infatti Feature Driven Development scoraggia l uso di pratiche tipo il Refactoring mentre incoraggia la condivisione del codice prodotto (in maniera particolare della documentazione relativa) fra i diversi programmatori Per la revisione del codice si va oltre il Pair Programming visto che la condivisione all interno del team dell iterazione permette una verifica molto più ampia. In ogni caso è proprio per permettere la miglior revisione possibile del codice che i team di sviluppo devono essere poco numerosi e che le iterazioni devono essere brevi, fra 1 e 3 settimane Massimo Ruffolo RPPI 2006/2007 27 FDD Il rilascio delle versioni è previsto per la fine di ogni iterazione, raramente di più iterazioni, ma ciò permette di coinvolgere molto di meno il cliente rispetto a quanto facciano le altre metodologie leggere. E permette anche di non consegnare alcune versioni intermedie quando le condizioni al contorno non lo rendano possibile, ad esempio in caso di software medici embedded Tenere una traccia dello status del progetto è un compito reso semplice da Feature Driven Development in quanto si ha a disposizione sin dall inizio la lista delle funzionalità da implementare ed ogni iterazione ha dei pesi ben definiti per ogni passo Massimo Ruffolo RPPI 2006/2007 28 14
FDD FDD usa Colored UML. Per UML colorato si intende un UML standard con le classi divise in quattro categorie individuate da quattro colori diversi: giallo (indica un Ruolo, ricoperto da persona o da organizzazione, come ad esempio i differenti tipi di utente di un servizio) blu (indica una Descrizione modello-catalogo, ad esempio il tipo di oggetto in un database ma non il singolo oggetto) verde (indica un Luogo o un Oggetto, ad esempio il singolo oggetto del database di prima) rosa (indica i Tempi, un momento o un intervallo associati ad un processo, ad esempio ad un azione su di un oggetto del database) Le classi ausiliari e le interfacce restano standard e non sono colorate Massimo Ruffolo RPPI 2006/2007 29 FDD Massimo Ruffolo RPPI 2006/2007 30 15
Ingegneria del Software: Extreme Programming (XP) Massimo Ruffolo RPPI 2006/2007 31 XP È un insieme di regole di sviluppo software sviluppate originariamente dal lavoro congiunto di Kent Beck, fondatore del Three Rivers Institute, e Ward Cunningham La chiave della metodologia è lavorare fianco a fianco con il cliente per anticipare i frequenti cambiamenti alle specifiche e di sviluppare in contemporanea con la scrittura del codice i test unitari atti a verificare la correttezza dei risultati restituiti dal codice stesso Massimo Ruffolo RPPI 2006/2007 32 16
Si possono individuare dodici regole base di Extreme Programming: Progettare con il cliente Test funzionali e unitari Refactoring (riscrivere il codice senza alterarne le funzionalità esterne) Progettare al minimo Descrivere il sistema con una metafora, anche per la descrizione formale Proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto) Scegliere ed utilizzare un preciso standard di scrittura del codice Integrare continuamente i cambiamenti al codice Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali) Open Workspace 40 ore di lavoro settimanali Pair Programming (due programmatori lavorano insieme su un solo computer) XP Massimo Ruffolo RPPI 2006/2007 33 XP James Donovan Wells mantiene una delle risorse più ricche sull argomento. Indica in particolare quattro linee guida: Comunicazione (tutti possono parlare con tutti, persino l ultimo dei programmatori con il cliente) Semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile) Feedback (sin dal primo giorno si testa il codice) Coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano). Massimo Ruffolo RPPI 2006/2007 34 17
XP Quattro sono le fasi del progetto, ognuna delle quali con le sue regole interne: Pianificazione (User Stories, Release Planning, Small Releases, Project Velocity, Load Factor, Iterative Development, Iteration Planning, Move People Around, Daily Stand Up Meeting, Fix XP) Progettazione (Simplicity, System Metaphor, CRC Cards, Spike Solution, Never Add Early, Refactoring) Sviluppo (Customer Always Available, Standards, Unit Test First, Pair Programming, Sequential Integration, Integrate Often, Collective Code Ownership, Optimize Last, No Overtime) Testing (Unit Test Framework, Bug s found, Functional Test o Acceptance Tests). Massimo Ruffolo RPPI 2006/2007 35 XP Massimo Ruffolo RPPI 2006/2007 36 18
Ingegneria del Software: COSM Massimo Ruffolo RPPI 2006/2007 37 COSM E soggetta a copyright Integra il framework di Zachman e la FDD con considerazioni provenienti dal mondo del PM e del BPM Prevede la stesura di una corposa documentazione E centrata sulla realizzazione di architetture SOA (component based architecture) Massimo Ruffolo RPPI 2006/2007 38 19
Ingegneria del Software: La Metodologia Exeura Massimo Ruffolo RPPI 2006/2007 39 La modellazione UML L output UML è costituito da un package chiamato Modello Progettuale contenente: un analisi fisica rappresentata mediante un package denominato Schema Architettura. un analisi dinamica rappresentata mediante un package denominato Schema Funzioni e un package denominato Schema Attori. un analisi statica rappresentata mediante un package denominato Schema Dati e un package denominato Schema Viste. 20
Lo schema funzioni/1 Le funzioni vengono rappresentate mediante package innestati di Usecase diagram nei quali vengono espressi i legami con attori e dati Lo schema funzioni/2 Gli aspetti dinamici delle funzioni vengono modellati mediante una serie di Activity diagram nei quali si rappresenta la sequenza di esecuzione degli usecase Massimo Ruffolo RPPI 2006/2007 41 Lo schema attori Le figure che interagiscono con il sistema vengono definite in uno Usecase diagram che modella anche le tassonomie dei ruoli Lo schema architettura La struttura architetturale del sistema da implementare viene modellata mediante Deployment diagram nei quali si modellano nodi, componenti e relative interazioni Massimo Ruffolo RPPI 2006/2007 42 21
Lo schema dati La struttura del database sul quale viene sviluppato il sistema è modellata in un Class diagram che rappresenta gli attributi, le tabelle e le relative relazioni Lo schema viste Utilizzando lo stereotipo di viste, specifiche porzioni di dati vengono messe a disposizione delle funzioni che ne faranno uso Massimo Ruffolo RPPI 2006/2007 43 La modalità di applicazione La costruzione del modello progettuale avviene in maniera incrementale. Si può iniziare considerando le aree funzionali richieste per il sistema analizzando le tipologie di utenti che dovranno essere supportate con l implementazione delle nuove funzionalità. Anche la progettazione dell area dei dati e viste è incrementale e parte da una descrizione a livello abbozzato, per poi passare a uno scheletro di schema globale in cui si dettagliano le viste che costituiscono il contatto con l area funzionale Massimo Ruffolo RPPI 2006/2007 44 22
L ambiente di lavoro La modellazione UML può essere supportata utilizzando la piattaforma ENTERPRISE ARCHITECT fornita dalla Sparxsystems www.sparxsystems.com Massimo Ruffolo RPPI 2006/2007 45 23