Post on 31-Jan-2020
transcript
•1
Redazione e Presentazione di P tti I f ti idi Progetti Informatici
Corso di Laurea in InformaticaFacoltà di Scienze Matematiche, Fisiche e Naturali
Massimo Ruffolo
E-mail: ruffolo@icar.cnr.itWeb: http://staff.icar.cnr.it/ruffolo
Massimo Ruffolo – RPPI 2007/2008 1
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
Ingegneria del Software
Cenni sulle metodologie:
Zachman Framework
Feature Driven Development
Extreme Programming
COSM
2
La metodologia Exeura
•2
Ingegneria del Software: Zachman Framework
3
Ingegneria del Software
Il valore di una metodologia sta nell’Approccio strutturatoalla realizzazione di un servizio/prodotto, ciò consente di:
identificare al meglio gli obiettivi intermedi e finaliottimizzare l’impiego di risorse (risparmiare tempo edanaro)controllore i risultati intermedi e finali (non perdere di
4
controllore i risultati intermedi e finali (non perdere divista li obiettivi)…
•3
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model Business Process Model
Business LogisticsSystem
Work Flow Model Master Schedule Business Plan
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model Business Process Model
Business LogisticsSystem
Work Flow Model Master Schedule Business Plan
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Zachman Framework
( )
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
( )
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
Ent = Business Entity Rel = Business Relationship
Proc = Business Process I/O = Business Resources
Node = Business Location Link = Business Linkage
People = Organization Unit Work = Work Product
Time = Business Event Cycle = Business Cycle
End = Business Objectiv e Means = Business Strategy
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
( )
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
( )
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
Ent = Business Entity Rel = Business Relationship
Proc = Business Process I/O = Business Resources
Node = Business Location Link = Business Linkage
People = Organization Unit Work = Work Product
Time = Business Event Cycle = Business Cycle
End = Business Objectiv e Means = Business Strategy
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
Massimo Ruffolo – RPPI 2007/2008 5
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
Zachman Framework
Row 1 – ScopeExternal Requirements and DriversBusiness Function ModelingBusiness Function Modeling
Row 2 – Enterprise ModelBusiness Process Models
Row 3 – System ModelLogical ModelsRequirements Definition
Row 4 – Technology ModelPhysical ModelsSolution Definition and Development
12345
Contextual
Conceptual
Logical
Physical
As Built
Contextual
Conceptual
Logical
Physical
As Built
WhyWho WhenWhereWhat How
6
Row 5 – As BuiltAs BuiltDeployment
Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation
6 Functioning Functioning
WhyWho WhenWhereWhat How
•4
Framework Rules
Rule 1:Columns have no order
Basic Model = Entities and Relationships
EntityRelationshipEntityColumns have no order
Contextual
Conceptual
Logical
Contextual
Conceptual
Logical
WhyWho WhenWhereWhat How
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:
7
Physical
As Built
Functioning
Physical
As Built
Functioning
WhyWho WhenWhereWhat How
Rule 5:Each cell is unique
Rule 6:Combining the cells in one row forms a complete description from that view
Zachman Framework – Row 1Scope/Planner’s View
• External Requirements and Drivers• Business Function Modeling
• Motivation/WhyBusiness goals, objectives and performancemeasures related to each function
Function/HowHigh-level business functions
Data/WhatHigh-level data classes related to
each function
People/WhoStakeholders related to each function
1 Contextual
Conceptual
Logical
Physical
Contextual
Conceptual
Logical
Physical
WhyWho WhenWhereWhat How
8
Network/WhereVA locations related to each function
Time/WhenCycles and events related to eachfunction
As Built
Functioning
As Built
Functioning
WhyWho WhenWhereWhat How
•5
Zachman Framework – Row 2Enterprise Model/Designer’s View
• Business Process Models• Business Function Allocation• Elimination of Function Overlap and
Ambiguity
• Motivation/WhyPolicies, procedures and standards for eachprocess
Function/HowBusiness processes
Data/WhatBusiness data
People/WhoVA roles and responsibilities in eachprocess
2
Contextual
Conceptual
Logical
Physical
Contextual
Conceptual
Logical
Physical
WhyWho WhenWhereWhat How
9
Network/WhereVA locations related to each process
Time/WhenEvents for each process and sequencingof integration and process improvements
As Built
Functioning
As Built
Functioning
WhyWho WhenWhereWhat How
Zachman Framework – Row 3System Model/Designer’s View
• Logical Models• Project Management• Requirements Definition
• Motivation/WhyVA policies, standards and proceduresassociated with a business rule model
F ti /HFunction/HowLogical representation of informationsystems and their relationships
Data/WhatLogical data models of data and datarelationships underlying VA information
People/WhoLogical representation of access privilegesconstrained by roles and responsibilities
N t k/Wh
3
Contextual
Conceptual
Logical
Physical
Contextual
Conceptual
Logical
Physical
WhyWho WhenWhereWhat How
10
Network/WhereLogical representation of the distributedsystem architecture for VA locations
Time/WhenLogical events and their triggered responses constrained by business events and their responses
As Built
Functioning
As Built
Functioning
WhyWho WhenWhereWhat How
•6
Zachman Framework – Row 4Technology Model/Builder’s View
• Physical Models• Technology Management• Solution Definition and Development• Motivation/Why
VA business rules constrained by informationsystems standards
Function/HowSpecifications of applications that operateon particular technology platforms
Data/WhatDatabase management system (DBMS) typerequirements constrained by logical data models
People/WhoSpecification of access privileges tospecific platforms and technologies 4
Contextual
Conceptual
Logical
Physical
As Built
Contextual
Conceptual
Logical
Physical
As Built
WhyWho WhenWhereWhat How
11
Network/WhereSpecification of network devices and theirrelationships within physical boundaries
Time/WhenSpecification of triggers to respond to systemevents on specific platforms and technologies
As Built
Functioning
As Built
Functioning
WhyWho WhenWhereWhat How
Zachman Framework – Row 5As Built/Integrator’s View
• As Built• Configuration Management• Deployment
• Motivation/WhyVA business rules constrained by specific technology standards
F ti /HFunction/HowPrograms coded to operate on specific technology platforms
Data/WhatData definitions constrained by physical data models
People/WhoAccess privileges coded to control access to specific platforms and technologies
N t k/Wh 5
Contextual
Conceptual
Logical
Physical
As Built
Contextual
Conceptual
Logical
Physical
As Built
WhyWho WhenWhereWhat How
12
Network/WhereNetwork devices configured to conform to node specifications
Time/WhenTiming definitions coded to sequence activities on specific platforms and technologies
5Functioning Functioning
WhyWho WhenWhereWhat How
•7
Zachman Framework – Row 6Functioning Enterprise/User’s View
• Functioning Enterprise• Operations Management• Evaluation
Motivation/WhyOperating characteristics of specific technologies constrained by standards
Function/HowFunctioning computer instructions
Data/WhatData values stored in actual databases
People/WhoVA personnel and key stakeholders working within their roles and responsibilities
N t k/Wh
Contextual
Conceptual
Logical
Physical
Contextual
Conceptual
Logical
Physical
WhyWho WhenWhereWhat How
13
Network/WhereSending and receiving messages
Time/WhenTiming definitions operating to sequence activities
6
Integrated
Functioning
Integrated
Functioning
WhyWho WhenWhereWhat How
VA Zachman Framework Portal
Massimo Ruffolo – RPPI 2007/2008 14
•8
Ingegneria del Software: Feature Driven Development (FDD)
15
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
FDD
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
16
•9
FDD
17
FDD
Ideata da Jeff De Luca e Peter Coad. E’ una via di mezzof t d l i l i t di i lfra metodologia leggera e approccio tradizionale.Propone una robusta fase di analisi e progettazione,integrata con un modello di sviluppo agileE’ una forma di sviluppo “guidata” dalle funzionalità darealizzareE’ strettamente basata sull’utilizzo di UML e in particolaresulla versione “colorata” di UML ideata dagli autori
18
gSono disponibili diversi strumenti di supporto free, alcunianche open sourceEsiste una community molto attiva che si occupa di questametodologia e dei sui strumenti
•10
FDD
Pur essendo molto meno conosciuta di ExtremeProgramming è forse il miglior approccio metodologico allosviluppo del software
Dal confronto diretto emerge sorprendentemente cheFeature Driven Development è addirittura più flessibile di
19
Extreme Programming anche se la prima ha una fase diprogettazione “classica” che la seconda elimina proprio perguadagnarne in flessibilità
FDDI dettagli delle fasi di sviluppo sono pochi e semplici. Unprogetto è diviso in cinque fasi, dette processi:sviluppare un modello generale
criteri d’ingresso: avere scelto gli esperti del problema, i capi-programmatori ed il capo-architettoattività: il project manager deve formare il team di modellazione;il team di modellazione deve offrire una panoramica del dominiodel problema, preparare i documenti funzionali e, diviso in piccoligruppi, sviluppare il modello; il capo-architetto deve rifinire ilmodello generale ad oggetti insieme al team di modellazione escrivere le note al modello insieme ai capi-programmatori;
ifi il t di d ll i d ff tt t t
20
verifica: il team di modellazione deve effettuare un accertamentointerno ed esterno con riferimento agli esperti di business ed aifuturi utenticriteri d’uscita: avere definito il modello ad oggetti avendo quindia disposizione i diagrammi delle classi, i metodi e gli attributidelle classi, la sequenza delle classi (se esiste), le note almodello
•11
FDD
costruire una lista di funzionalitàcriteri d’ingresso: avere scelto gli esperti del problema il capocriteri d’ingresso: avere scelto gli esperti del problema, il capo-programmatore ed i capi-architettiattività: il project manager deve formare il team della lista dellefunzionalità che deve comprendere i capi-programmatori del team dimodellazione; il team della lista delle funzionalità deve definire lalista delle funzionalità in termini di azione-risultato-oggettoverifica: il team della lista delle funzionalità deve effettuare unaccertamento interno ed esterno con riferimento agli esperti dibusiness ed ai futuri utenti
21
business ed ai futuri utenticriteri d’uscita: avere definito la lista delle funzionalità avendoquindi a disposizione la lista delle aree oggetto, la lista delleattività di business per ogni area oggetto, la lista delle funzionalitàche soddisfino tutti i punti di ogni lista delle attività;
FDD
Pianificare per funzionalitàcriteri d’ingresso: è stato portato a termine il processo “costruireg p puna lista di funzionalità”attività: il project manager deve formare il team diprogettazione che comprende capi-programmatori e manager dellosviluppo; il team di progettazione deve definire la sequenza disviluppo, assegnare le attività di business ai capi-programmatoried assegnare le classi agli sviluppatoriverifica: il team di progettazione deve effettuare un’autoverificasul lavoro svolto
22
criteri d’uscita: avere definito un piano di sviluppo comprendentele attività di business con le date di completamento ed i capi-programmatori responsabili assegnati, la date di completamentodelle aree oggetto (derivate da quelle delle attività di business), lalista delle classi con relativi sviluppatori
•12
FDDProgettare per funzionalità
criteri d’ingresso: è stato portato a termine il processo “pianificare perfunzionalità”attività: ogni capo-programmatore forma il team delle funzionalità; ogniesperto del problema definisce la strada per affrontare il problema erisolverlo; il team delle funzionalità studia i documenti dei requisiti delleproprie funzionalità; il team di progettazione sviluppa i diagrammi disequenza; il capo-programmatore raffina il modello ad oggetti per definirese scrivere o modificare classi, metodi, attributi; il team delle funzionalitàscrive le classi e gli header dei metodiverifica: il team delle funzionalità ispeziona il progetto in tutti i suoiaspetti funzionali e temporali
23
criteri d’uscita: avere definito un pacchetto di progettazionecompleto che comprenda un documento esplicativo dell’interoprogetto con le specifiche referenziate (se esistono riferimenti), idiagrammi di sequenza, le alternative di progetto (se esistono), ilmodello ad oggetti completo di classi, metodi e attributi, gli headerdi classi e metodi, una todo list con un calendario delle scadenze per ogniattività ed ogni membro del team
FDD
Sviluppare per funzionalitàcriteri d’ingresso: è stato portato a termine il processo “pianificareg p p pper funzionalità” ed è stato ispezionato con successo il progetto intutti i suoi aspetti funzionali e temporaliattività: 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 dellefunzionalità quali classi siano “promuovibili” come utili allacostruzione del progetto in riguardo alle funzionalità richiesteverifica: il capo-programmatore sovrintende affinché siano
24
completate effettivamente in tutti i punti dal team delle funzionalitàl’ispezione dei codici ed la soddisfazione dei test unitaricriteri d’uscita: avere ottenuto classi e metodi che siano statiispezionati e testati con successo, infine promossi all’integrazione nelprogetto (ovviamente a copertura di tutte le funzionalità previste
•13
FDDFeature Driven Development non richiede esplicitamentela stesura di documentazione, ma obbliga all’utilizzodei diagrammi UML. Questo per avere una basedecisionale che sia stabile durante tutto il processo disviluppo, solo in seconda battuta sarà utile per scrivere unadocumentazione formale, se richiestaNel corso del progetto ci sono molti documenti che devonoessere disponibili per i diversi attori, quindi la migliorsoluzione è organizzare un sito web interno checontenga tutte le informazioni sul progetto: la lista di
Massimo Ruffolo – RPPI 2007/2008 25
contenga tutte le informazioni sul progetto: la lista disviluppatori ed esperti del problema, il modello UML con icommenti, i forum di discussione, le convenzioni di scritturadel codice, la lista degli strumenti e delle librerie usate, ireport dei test unitari, lo status del progetto, la timelinecomprensiva della pianificazione futura, ecc...
FDD
Durante lo sviluppo, organizzato in iterazioni brevi, siforma una struttura gerarchica con figure a metà stradafra il project manager e gli sviluppatori: i capi-programmatori. Questi sono a capo di ogni singolaiterazione, che quindi possono essere numerose eprocedere parallelamente, scegliendo anche il team(composto da 3-5 persone) che se ne occuperàL’esperienza dei capi-programmatori e la frammentazionedel lavoro in iterazioni sono i meccanismi di controllo e
Massimo Ruffolo – RPPI 2007/2008 26
del lavoro in iterazioni, sono i meccanismi di controllo eregolazione di Feature Driven Development. All’inizio diogni iterazione si organizzano delle riunioni diprogettazione che servono a far confrontare i membridel team e ad ottenere la documentazione del codice
•14
FDDLa stesura del codice prevede l’utilizzo rigoroso di unostandard comune di scrittura e il ricorso ad i test unitari,che possono essere organizzati a discrezione dei capi-programmatoriDate le numerose riunioni effettuate prima di cominciare ascrivere il codice, questa attività diventa qualcosa di meccanico,infatti Feature Driven Development scoraggia l’uso di pratichetipo il Refactoring mentre incoraggia la condivisione delcodice prodotto (in maniera particolare della documentazionerelativa) fra i diversi programmatoriPer la revisione del codice si va oltre il Pair Programming visto
Massimo Ruffolo – RPPI 2007/2008 27
Per la revisione del codice si va oltre il Pair Programming vistoche la condivisione all’interno del team dell’iterazionepermette una verifica molto più ampia. In ogni caso è proprioper permettere la miglior revisione possibile del codice che i teamdi sviluppo devono essere poco numerosi e che le iterazionidevono essere brevi, fra 1 e 3 settimane
FDD
Il rilascio delle versioni è previsto per la fine di ogniiterazione raramente di più iterazioni ma ciò permette diiterazione, raramente di più iterazioni, ma ciò permette dicoinvolgere molto di meno il cliente rispetto a quantofacciano le altre metodologie leggere. E permette anche dinon consegnare alcune versioni intermedie quando lecondizioni al contorno non lo rendano possibile, ad esempioin caso di software medici embeddedTenere una traccia dello status del progetto è un compito
Massimo Ruffolo – RPPI 2007/2008 28
reso semplice da Feature Driven Development in quanto siha a disposizione sin dall’inizio la lista delle funzionalità daimplementare ed ogni iterazione ha dei pesi ben definiti perogni passo
•15
FDD
FDD usa Colored UML. Per UML colorato si intende un UMLstandard con le classi divise in quattro categorie individuateda quattro colori diversi:da quattro colori diversi:
giallo (indica un ruolo, ricoperto da persona o daorganizzazione, come ad esempio i differenti tipi di utente diun servizio)blu (indica una descrizione modello-catalogo, ad esempio iltipo di oggetto in un database ma non il singolo oggetto)verde (indica un luogo o un Oggetto, ad esempio il singolooggetto del database di prima)
Massimo Ruffolo – RPPI 2007/2008 29
oggetto del database di prima)rosa (indica i Tempi, un momento o un intervallo associati adun processo, ad esempio ad un azione su di un oggetto deldatabase)Le classi ausiliari e le interfacce restano standard e non sonocolorate
FDD
30
•16
Ingegneria del Software: Extreme Programming (XP)
31
XP
È un insieme di regole di sviluppo software sviluppateoriginariamente dal lavoro congiunto di Kent Beck,fondatore del Three Rivers Institute, e Ward Cunningham
La chiave della metodologia è lavorare fianco a fianco con ilcliente per anticipare i frequenti cambiamenti alle specifiche
32
e di sviluppare in contemporanea con la scrittura del codicei test unitari atti a verificare la correttezza dei risultatirestituiti dal codice stesso
•17
XPSi possono individuare dodici regole base di ExtremeProgramming:
Progettare con il clienteTest funzionali e unitariTest funzionali e unitariRefactoring (riscrivere il codice senza alterarne le funzionalitàesterne)Progettare al minimoDescrivere il sistema con una metafora, anche per la descrizioneformaleProprietà del codice collettiva (contribuisce alla stesura chiunque siacoinvolto nel progetto)Scegliere ed utilizzare un preciso standard di scrittura del codice
Massimo Ruffolo – RPPI 2007/2008 33
Scegliere ed utilizzare un preciso standard di scrittura del codiceIntegrare continuamente i cambiamenti al codiceIl cliente deve essere presente e disponibile a verificare (sono consigliateriunioni settimanali)Open Workspace40 ore di lavoro settimanaliPair Programming (due programmatori lavorano insieme su un solo computer)
XP
James Donovan Wells mantiene una delle risorse più ricchesull’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 descrizioneformale il più semplice e chiara possibile)
34
Feedback (sin dal primo giorno si testa il codice)Coraggio (si dà in uso il sistema il prima possibile e siimplementano i cambiamenti richiesti man mano)
•18
XP
Quattro sono le fasi del progetto, ognuna delle quali con lesue regole interne:
Pianificazione (User Stories, Release Planning, SmallReleases, Project Velocity, Load Factor, IterativeDevelopment, Iteration Planning, Move People Around, DailyStand Up Meeting, Fix XP)Progettazione (Simplicity, System Metaphor, CRC Cards,Spike Solution, Never Add Early, Refactoring)Sviluppo (Customer Always Available, Standards, Unit TestFi t P i P i S ti l I t ti I t t
35
First, Pair Programming, Sequential Integration, IntegrateOften, Collective Code Ownership, Optimize Last, NoOvertime)Testing (Unit Test Framework, Bug’s found, Functional Test oAcceptance Tests).
XP
Massimo Ruffolo – RPPI 2007/2008 36
•19
Ingegneria del Software: COSM
37
COSM
E’ soggetta a copyrightIntegra il framework di Zachman e la FDD conconsiderazioni provenienti dal mondo del PM e del BPMPrevede la stesura di una corposa documentazioneE’ centrata sulla realizzazione di architetture SOA
38
(component based architecture)
•20
Ingegneria del Software: La Metodologia Exeura
39
L’output UML è costituito da un package chiamato ModelloProgettuale contenente:
La modellazione UML
• Schema processi (Package processi)
• Schema funzioni (Package funzioni)
• Schema attori (Package attori)
• Schema archivi (Package archivi)( g )
• Schema architettura (Package architettura)
• Schema interfacce (Package interfacce)
•21
Le funzioni vengono rappresentate mediante package innestati di
Lo schema funzioni/1
mediante package innestati di Usecase diagramUsecase diagram nei quali vengono espressi i legami con attori e dati
Lo schema funzioni/2
41
Gli aspetti dinamici delle funzioni vengono modellati mediante una serie di Activity diagramActivity diagram nei quali si rappresenta la sequenza di esecuzione degli usecase
Lo schema funzioni/2
Le figure che interagiscono con il sistema vengono definite in uno UseUse
Lo schema attori
sistema vengono definite in uno Use Use case diagramcase diagram che modella anche le tassonomie dei ruoli
Lo schema architettura
42
La struttura architetturale del sistema da implementare viene modellata mediante Deployment diagramDeployment diagram nei quali si modellano nodi, componenti e relative interazioni
Lo schema architettura
•22
La struttura del database sul quale viene sviluppato il sistema è
Lo schema dati
viene sviluppato il sistema è modellata in un class diagramclass diagram che rappresenta gli attributi, le tabelle e le relative relazioni
43
Utilizzando lo stereotipo di viste, specifiche porzioni di dati vengono messe a disposizione delle funzioni che ne faranno uso
Il sotto-schema viste
La costruzione del modello progettuale avviene in maniera i l
La modalità di applicazione
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
44
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