MDA_WS

Agile Model Driven WorkshopAgile Model Driven Workshop
Dr. Pierfranco Ferronato
Is the Chief Architect and Soluta.Net's founder.
He has over 20 years of experience in all aspects of distributed
systems development and is internationally recognized as an expert
in large-scale distributed architectures, modelling and meta-
modelling technologies since 1994.
Dr. Ferronato has provided technical and architectural leadership for
several European projects using advanced Internet-related
technologies, component-based development, SOA, and webservices
in a number of domains, including teleco, pharmaceutical, ERP,
CRM, EAI and tourism.
He is a senior consultant at the Cutter Consortium.
He's an OMG member, and Open Group Member.
He is an invited speaker at conferences worldwide

Organizzazione dei Workshop
1) Agile Model Driven Development
̵ Un'analisi pratica
̵ Sfide, pro e contro
--- Coffe Break
3) MD Enterprise Architectures
̵ Ecosistemi di modelli
̵ Il ruolo di un repository di modelli

Agenda
» Soluta.Net
» Il peso della manutenzione in ICT
» La progettazione non Model Driven
» Il valore dei modelli
» Linguaggi formali di modellazione
» Agile Modeling Architecture
» Mario Scettico chiede...
» Model Driven Application Lifecycle Management
» Ostacoli e Conclusioni
» Il caso Selex Communications
» Demo of a MDA Tool

ICT, una storia di astrazione
(*
» Logical cablata, linguaggio macchina, assembler...
» Nel 1968 Edsger Dijkstra scrisse la famosa lettera “GOTO Statement
Considered Harmful”.
» Fortran, C, C++,...
» Allontanarsi dall'hardware ed andare verso il problema applicativo
» Si astrae ancora oggi
» Allontanarsi dalle API dell'application server
» ...del database (SQL)
» ...del presentation layer (xForm)
» ...dei protocolli (REST)
» …delle tecnoologie di implementazione (SOA)
» ...

ICT, una storia di complessità
» Funzionalità
̵ Domini, interoperabilità, processi di business, processi dinamici, on-demand...
» Caratteristiche extra funzionali
̵ Multilingua, tempo reale, immagini, icone, colori,...
» Dispositivi di interfaccia uomo-macchina
̵ PC, mobile, palm, telefoni, web...
» Hardware
» Sistemi Operativi
» Architetture
̵ Un livello, due livelli, n livelli, thin-client, SOA, grid, cloud,...
» Qual'è la prossima tecnologia?
» Qual'è la prossima architettura?
» E non ci si può permettere di buttare via nulla...

Ingegneria classica
» “Nell'ingegneria classica un
cambiamento in corso d'opera
ha spesso conseguenze nefaste
̵ Si distrugge e si rifà
» Il costo di modificare è almeno
un'ordine di grandezza del
costo di fare”
» Non c'è spazio per cambiare
» Il progettare è fondamentale
per rispettare requisiti, vincoli,
tempi e costi
̵ Da sempre l'uomo lo sa

Un problema culturale in ICT
» Il progettare prima di scrivere software non viene d'istintivo come per costruire
una casa
» In informatica il costo di modificare è una frazione del costo di fare
̵ Non ci sono materiali da ri-comprare, scarti da rottamare
̵ Un attributo si aggiunge al volo, una tabella si crea in un istante
̵ Spesso un copia/incolla risolve un'esigenza immediata
̵ Copiare una riga o un'intera classe ha lo stesso costo
̵ “Prima scrivo, poi documento”
» Fattore rischio:
̵ Ingegneria: supporta da sempre vite umane
̵ ICT basso: fino a pochi anni fa solo contabilità e poco più
» Strumenti:
̵ Ingegneria: complessi, voluminosi, pericolosi, costosi
̵ ICT: Delirio di onnipotenza, troppi strumenti, troppo potenti, troppo
economici
Apparentemente!!

Certo, c'è necessità di progettare
» Sì, “costa meno modificare che fare”, e sarebbe perfetto se l'ICT
non fosse così dinamico di natura.
» In ingegneria:
̵ Un ponte non si sposta, non si allunga
̵ Un grattacelo non si alza a “run-time”
̵ Un motore non si cambia in “hot-plug”
» ICT cambia tutto rapidamente, obsolescenza è rapida:
̵ Requisiti funzionali, standard, regole normative, di mercato, di business
̵ Requisiti tecnologici, protocolli, hardware, legacy
» Si deve finalizzare la progettazione software alla manutenibilità:
scalabile, estensibile, modificabile,...

Manutenibilità
» In ingegneria i costi sono principalmente:
̵ Operativi: illuminazione, pulizia, riscaldamento, affitti
̵ Manutentivi: tinteggiatura, riparazioni
» Ovviamente si progetta per la costruzione:
̵ (in 10 anni) i costi operativi pesano 10%, il 90% è dovuto alla costruzione
» In ICT i costi sono principalmente evolutivi:
̵ →Supporta il business dinamico
̵ Un progetto è come un organismo, il suo ciclo di vita non si esaurisce con la
messa in produzione
» In ICT il costo della costruzione è una frazione del costo della manutenzione,
dovremmo preoccuparci di progettare per facilitarne la manutenzione (da dove
viene il ROI)
̵ Troppo spesso si pensa solo ad andare in produzione in tempi brevi e valutare
il costo solo in ottica del 'chiavi in mano'

Costi nella manutenzione
Impatto della complessità nel
costo della manutenzione
» Studi hanno dimostrato che
circa il 50% del tempo è
usato per capire il codice
che deve essere manutenuto
(Fjeldstad & Hamlen, 1983;
Standish, 1984)
Year Definition Reference
1979 67,00%
1981 >50%
1984 65-75% McKee (1984)
1988 60-70% Port (1988)
1990 60-70% Huff (1990)
1990 >90% Moad (1990)
1993 75,00% Eastwood (1993)
2000 >90% Erlikh (2000)
Proportion of
software
maintenance costs
Maintenance costs / total software
costs
Zelkowitz et al.
(1979)
Staff time spent on maintenance / total
time (in 487 organizations)
Lientz &
Swanson (1981)
Effort spent on software maintenance /
total available software engineering
effort.
Software maintenance / total
management information systems (MIS)
operating budgets
Software maintenance / total
management information systems (MIS)
operating budgets
Software cost devoted to system
maintenance & evolution / total
software costs
Software maintenance / information
system budget
(in Fortune 1000 companies)
Software cost devoted to system
maintenance & evolution / total
software costs
Software Maintenance Costs, Jussi Koskinen, Information Technology Research Institute, ELTIS-
project, University of Jyväskylä

SOA e la legge “80-20”
» Il codice strutturale con le tecnologie SOA
̵ è circa l'80% del totale
– Middleware, SOAP, WS, MOM, marshalling, database, ORM, GUI, logging, transactions, batch,
security, X<something>, manifest files, SQL, Jar,...
̵ è invariante, ripetitivo, facile agli errori (error prone)
» Il codice funzionale con le tecnologie SOA
̵ è il 20% del totale (come rappresentare il proprio business)
̵ Non è ripetibile!
» Il 20% funzionale vale l'80% dell'applicazione
» L'80% strutturale vale economicamente il 20% dell'applicazione
» ma le aziende spendono l'80% del budget per sviluppare il codice
strutturale!

Difficoltà
» I programmatori debbono eseguire un pattern preciso
̵ Test oneroso, gli errori di test sono principalmente legati all'uso
improprio della tecnologia
̵ Programmazione ripetitiva e manuale porta ad errori, codice
disomogeneo, spreco di tempo, stress..
» Le APIs del linguaggio di piattaforma sono comunque disponibili
̵ Le regole possono essere infrante
» Se cambiano le APIs del framework deve essere fatto un cospicuo
refactory di tutto il codice
̵ Ma funziona solo se è stato rispettato il pattern da tutti
» Come garantire la ripetizione delle scelte tecnologiche standard?

Criteri per controllare i rischi/costi
» Si è scoperto da tempo che è utile separare gli
aspetti funzionali da quelli tecnologici
» Analisi funzionale ed implementazione tecnica
» E' necessario separare il
̵ “cosa” dal “come”
̵ “obiettivo” dal “mezzo”
» Hanno cicli di vita diversi
̵ rapidi i cambiamenti funzionali, lenti quelli
tecnologici
» Specializzazione delle competenze

Software engineering anni '90
» Ingegnerizzazione dei processi di sviluppo
software OOAD:
̵ Analisi & Disegno ed Implementazione.
» Per mantenere il controllo, i processi di
ingegnerizzazione del software sono diventati ferrei:
̵ Complessi, Costosi, Rischiosi;
̵ Controllo di Qualità;
̵ Creano un falso senso di sicurezza: la colpa è poi di chi non ha
saputo seguire il processo.
» Il passaggio tra analisi ed implementazione resta comunque
manuale:
̵ L'analisi è “solo” documentazione storica.
» Un cambio o una modifica della tecnologia diviene una rivoluzione €
€!!!

Il processo non normato
» Analisi leggera ed informale con analisti programmatori
factotum:
̵ Gli analisti-programmatori divengono risorse “pregiate” (e quindi
costose) non facilmente rimpiazzabili
» L'azienda si “congela” su una tecnologia (DB) e non riesce a
migrare se non rifacendo l'intero
sistema informativo:
̵ Nuovo personale
̵ Rifare l'analisi
̵ Nessuna capitalizzazione delle
conoscenze
» Solo soluzioni tampone “a macchia di leopardo”

Definizioni
» UML è un linguaggio espressivo
» Un tool UML è un editor per scrivere
espressioni in UML
» Una metodologia definisce come usare UML
per descrivere un problema
̵ Quali semantiche di UML usare per ogni viewpoint
̵ Come relazionare le varie semantiche UML
» Ve ne sono tante:
̵ CBD, EDOC, Posix, Chorus, <mettete la vostra>

Cammino evolutivo
» Nato come pura notazione simbolico/grafica, semantica debole
» →Da una notazione una semantica
̵ Boxes & lines a codifiche formali, algebra
» Interoperabilità
̵ XMI, modelli interscambiabili tra tool
» →Da una visione Strutturale visione Comportamentale
̵ Semantiche comportamentali: xUML
» →Modelli formali modelli computabili
̵ Processabili e trasformabili
» Meccanismi di estensibilità
̵ Non solo UML: MOF, profili UML
» Architetturare i modelli
̵ MDA
» Integrare i modelli, Enterprise Architecture

UML, meccanismi di estensione
» UML è nato generico, è stato messo sotto pressione per
supportare altre semantiche
ma
» E' stato modellato con un altro linguaggio: MOF
» UML non è il solo linguaggio di modellazione di OMG
̵ CWM, BMM, SBVR,
̵ RuleML, BPMN, BPDM...

UML non è una metodologia
» Se UML è un 'linguaggio', 'come scrivere un libro' è una metodologia
̵ XP, Agile, SSADM, RUP, Posix,
» Metodologia in IT comprende:
̵ Ciclo di vita del software (PLM: project life cycle management)
• Iterativo-Incrementale, Water-fall, Spirale...
̵ ↔Mapping Architetture UML
• Che diagrammi UML usare?
• Come relazionare le entità?
• Come relazionare i modelli?
• Tracciare requisiti
̵ Approccio alla modellazione
• Ad oggetti: Fowler...
• A componenti: Sims...
̵ Model management

Approccio orientato ai modelli
» Concepito nel 2000
» Oltre 50 aziende
impegnate in MDA OMG
» Oltre 30 “success stories”
descritte
» 20 circa i principali MDA
tool vendor nel mercato
» 5 circa i principali prodotti
open source
MDA Success Stories(*)
* OMG Web Site, 2006
●
ABB Research Center
●
Austrian Railways
●
BankHOST
●
Bauspar AG
●
Carter Ground Fueling Ltd.
●
CGI
●
Credit Suisse
●
DaimlerChrysler
●
Danzas Group
●
Deutsche Bank
●
E-SoftSys
●
ff-eCommerce Swedish Parliament
●
Gothaer Versicherungen
●
Lockheed Martin
●
M1 Global Solutions
●
Magnet Communications, Inc.
●
National Services Industries
●
Postgirot Bank AB
●
Project Swisslog Software AG
●
Selex Communications
●
Thalse Gruop
●
The Open System Architecture for
Condition Based Monitoring (OSA-CBM)
●
U.S. Government Intelligence Agency
●
UNext

Un nuovo stile architetturale
» Lo sviluppo ICT non deve riadattare metodologie da domini incompatibili
» Sfruttare quello che sembra essere la debolezza dell'IT
̵ La volatilità, la dinamicità, la computabilità
» E' un approccio organico allo sviluppo del software che è basato sui modelli, vuole
ottenere:
1) separazione degli aspetti funzionali da quelli strutturali/tecnologici
2) semplificazione nella definizione delle funzionalità
3) capitalizzazione della conoscenza come modelli
4) riuso di modelli indipendentemente dalla tecnologia
5) riuso di modelli indipendentemente dalle funzionalità
6) semplificare i processi di manutenzione
7) modello che assume il valore di codice, ma senza averne gli svantaggi
8) la capacità di trasformare modelli in sistemi funzionanti.

Cosa non è
» Non è uno strumento
̵ Anche se ne fa uso
» Non è un processo
̵ Anche se ne fa uso
» Non è una magia 
̵ È un'evoluzione di decenni di ingegneria del software

Il codice è modello
» “Repeat until” oppure “JNE x00ef, x003F” ?
̵ Un modello può rappresentare una struttura logica a più alto livello:
» ..nasconde i dettagli irrilevanti
̵ Che processore c'è sotto?
̵ Il codice è solamente la rappresentazione di altro codice
» Il codice è sempre stato un'astrazione:
̵ Codice macchina -> Assembly -> 3GL -> OO -> Java
» Noi stiamo astraendo ancora oggi
» Il codice di oggi rappresenta altro codice:
̵ WSDL, XML, XSD, e così via

Codice - Modello, macchina a stati

Codice vs Modello
[omissis]
try{
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
} catch {/*tech Error handling*/}
try {
PowerService service = (PowerService) Naming.lookup("rmi://" +
serverIp+ "/PowerService");
} catch {/*tech Error handling*/}
try {
System.transactionMon(IN, context);
context=service.doSomething(contex, 123);
System.transactionMon(OUT, context);
} catch {/* tech and behavioral error handling*/}
[omissis]
sd Class Model
Service:PowerServiceReqType:MyRequester
doSom ething(context, 123)

Quindi il modello è codice!
» I servizi possono essere rappresentati dai modelli
̵ WSDL, classi di linguaggio..
» Le applicazioni possono essere rappresentate da modelli
̵ UI, servizi, componenti, data model, object model, deployment...
» Un modello può essere eseguito
̵ Action semantics, BPMN, OCL
̵ OCL è codice .. o è un modello?
̵ Ci sono molti tool commerciali sul mercato che hanno questa capacità
» I modelli possono essere validati e trasformati...come il codice
» I modelli possono essere testati e debuggati... come il codice
» I modelli possono essere eseguiti!

I modelli computabili
» La chiave di volta sono i modelli computabili
» Non immagini, ma descrizioni precise e complete
» Ogni entità UML grafica ha un corrispondente entità in XML, leggibile, processabile
e trasformabile
̵ ↔UML XMI
» I modelli assumono il valore del codice
» L'attività di modellazione è diversa, non 'solo' per comunicare
→human human, ma un modo per istruire una 'macchina'
class class
Order
- id: float =

Definizioni: “Piattaforma”
» Insieme di tecnologie che supportano
l'esecuzione di un'applicazione
» Negli anni 80 c'era una relazione 1:1 tra
tecnologia e piattaforma
» Oggi:
̵ Web service, Java EJB, .Net, CORBA, AS400,
CICS OS390...
̵ Presentazione UI, messaggi, persistenza,
application server...

Definizioni: “CIM”
» Computational Independent Model, CIM
» Esempi:
̵ Motivazioni e Strategie
̵ Processi
̵ Diagramma di contesto
̵ Elenco requisiti
̵ Funzionalità, Use Case

Definizioni: “PIM”
» Platform Independent Model, PIM
̵ Rappresenta un modello funzionale tramite elementi che non
dipendono da alcuna piattaforma specifica
̵ Es: descrivere un modello dei dati in SQL standard
̵ Es: descrivere un circuito tramite gli schemi logici
̵ Es: esporre un 'servizio'
̵ ES: definire 'classi' di business

Definizioni: “PSM”
» Platform Specific Model, PSM
̵ Rappresenta un modello funzionale tramite elementi che dipendono da
una piattaforma
̵ Es: descrivere una scheda elettronica indicando il produttore del chip
̵ Es: lanciare un servizio WS, .Net, Corba...
̵ Es: class RefObject, EJB HomeObject, ...
Attenzione: il concetto di “Indipendente” è relativo:
e.g. : CORBA è nato per essere PIM, adesso è un tipo middleware, indi è PSM
e.g. : WebService sono PIM rispetto all'implementazione, ma PSM rispetto a SOA

Vantaggi
» Team specializzati:
̵ Uno per la specifica funzionale (architettura funzionale) ed uno per quella tecnica
(architettura tecnologia)
» Rapida capacità di adattamento ai cambiamenti del business:
̵ Il cambiamento in un modello funzionale consiste già in un cambiamento
dell'applicazione: nessuna impedenza tecnica
̵ Da 3 mesi (nostra esperienza) a 3-4 settimane (quasi solo test)
» Rapidissima capacità di adattamento ai cambiamenti dell'infrastruttura tecnologica
• Es: da HTML a AJAX semplicemente ri-generando
» Gestione dei rischi
̵ “Sviluppo a fasi”, prima un cartridge semplice poi uno complesso, l'aspetto tecnologico
non impatta quello funzionale
» Capitalizzazione degli investimenti
» Test
̵ Solo funzionale
̵ Più rapido, esempio F16, esempio Selex Comm.

Interoperabilità
» I “modelli funzionali UML” indipendenti dalla piattaforma diventano il
riferimento “inter-societario” per lo scambio di informazioni tra aziende,
partner e consociate
̵ Meno enfasi sulle tecnologie d'interscambio ed implementazione
̵ Master Data Management
̵ Indipendenti dalle tecnologie adottate per i sistemi esterni
» Convenire tra team sui modelli comuni indipendenti dalla piattaforma e
demandare alle trasformazioni MDA la conversione in un modello
computabile
» Outsourcing:
̵ i fornitori possono lavorare a partire da modelli UML
̵ Modelli come specifiche “Design by Contract”
» Interoperabilità parte dalla semantica:
̵ Glossario, tassonomia

Difficoltà
» È dovuto ad una forma-mentis mentale dei professionisti IT, è una
questione di:
̵ Differenti punti di vista nello sviluppo
̵ Differenti abitudini
̵ Scarsa maturità
̵ Poca confidenza
̵ Non c'è ancora abbastanza esperienza
̵ Approccio inusuale che richiede di smantellare anni di classico approccio
alla sviluppo del software
» Bruciature anni '90: i CASE Tool hanno fatto male all'ICT
» Si tratta di un cambiamento, una sterzata nel modo di fare le cose, si deve
vincere una inerzia aziendale culturale, da non sottovalutare
» Non c'è un'offerta di mercato ben definita

Codice Legacy
» Se lo scopo è fare del Modernization:
̵ Reverse da codice legacy per ottenere modelli PIM da cui
generare modelli PSM in tecnologie diverse
» Se lo scopo è riusare codice legacy:
̵ Generare dei modelli-Façade che facciano da wrapper al
codice legacy
» DB legacy:
̵ Reverse dal DDL (o altro), mapping con Business Object
Models
̵ Generare dei wrapper, persistency layers
» Sono tutte tecniche consolidate

Demistificazione
» I modelli non possono essere eseguiti!
̵ Falso, esistono diverse soluzioni.
» I modelli generano codice lento!
̵ Falso: dipende solo dalla qualità delle
trasformazioni.
» E' un approccio oneroso!
̵ Falso, dipende dal processo di
sviluppo: adottare cicli brevi;
̵ Falso: ”Divide et impera” verticale
(componenti funzionali), orizzontale
(tiers), cross cutting concerns.
» Il codice generato è confuso e difficile da
capire!
̵ Falso: dipende dai trasformatori;
̵ Senza senso: non c'è necessità di
guardare il codice.
» Non ci sono progetti MDA in produzione!
̵ Falso: ce ne sono molti, per
informazioni guardare la pagina di
OMG.
» Non ci sono tool MDA disponibili per lo
sviluppo!
̵ Falso: per informazioni guardare la
pagina di OMG.
» L' MDA è rivolto solamente a sistemi
embedded!
̵ Falso: per informazioni sulle storie di
successo guardare il sito OMG.
» UML è troppo ampio!
̵ Vero: ma non è necessario utilizzare
tutta la semantica. Ci sono altri
linguaggi.

Iterative-Incremental Development
CIM Analysis PIM Design PIM Development
Test
Execution
Deploy
Component Driven
Project
Coordination
• Component Analysis
• Component Model
• Feature Catalogue
Iteration n-1
Test Cases creation
Stakeholders
Development
(PS)
Technical
Architecture
Functional
Architecture
Domain Experts
Iteration n
Use Case Driven
Requirements
Tracing

Ciclo di vita basato sui modelli
» Ciclo di vita basato sui modelli
̵ I modelli debbono guidare lo sviluppo
̵ Dai requisiti al codice passando per i modelli,
senza soluzione di continuità
» Deve essere definito come i modelli debbano
essere usati:
̵ Una mappatura tra la semantica del linguaggio
e la struttura applicativa: come descrivere
l'applicazione in UML
̵ Spesso i tool MDA hanno già fatto questa
scelta
̵ Conoscere UML non implica sapere descrivere
bene un'applicazione: parallelismo con i
linguaggi
» I modelli sono IL capitale aziendale
̵ Abbiatene cura! Vanno persistiti, gestiti,
manutenuti...
» Ma c'è un prezzo da pagare...

Non solo “Tool”
» In passato i Case Tool UML erano
percepiti come una “pallottola d'argento”
̵ non deve essere considerato una
“pallottola d'argento”
non facciamo lo stesso errore
» Tool Open Source richiedono molta manutenzione
» Deve essere gestito accuratamente il ciclo di vita del software
̵ Interoperabilità al 100% tra tool MDA tools è ancora lunga da ottenere
̵ Non si può sostituire facilmente

Model Driven Agile? “Si può”
» Concentrarsi nel catturare e soddisfare i requisiti
funzionali come applicazione eseguibile
̵ In MDA, l'architettura tecnologica può essere raffinata successivamente
̵ Non spendere risorse per l'architettura tecnologica ottimale dall'inizio,
accettare compromessi: "L'ottimo è peggio del buono"
» I feedback devono essere incorporati rapidamente nel modello
̵ Cicli di vita brevi
̵ Suggerimento: tre settimane ad iterazione
̵ I nuovi requisiti sono benvenuti, ma vanno tracciati
» →L'obiettivo non è generare il 100% del codice dipende!
̵ Generativo: Solo l'80% strutturale
̵ Trasformativo: 100% PIM->PSM->Codice
» ↔No round-trip “codice modello”, mette a serio rischio l'agilità
̵ KISS; “Keep it Simply Simple”

DTR100
» Multi-mode integrated transmitter/receiver DTR100.
» MDA test process and tool evaluation for the “real” world
» SC filed a RFI to OMG (September 2005), won by Soluta.Net,
which provided support and expertise in partnership with the
tool vendor Kennedy Carter (UK)

Requirements
» Increase Selex Communications productivity keeping code
quality high, which means:
» Improve the adaptation process of the code to changing
requirements
» Manage the technology-related impacts on developed code
(multiple platform deployments, hardware, core libraries
and programming language independency)
(All companies developing software for tecnological
devices share these requirements)

Code and Platform#include <string.h>
#ifdef MSIC_ENVIRONMENT
#include "vxWorks.h"
#include "../OEM/msicDefs.h"
#include "timers.h"
#else
#include "IMCDefines.h"
#include "..commonRS232.h"
#include <stdio.h> /* for sprintf */
#ifdef H8S_SIMULATOR
#ifdef __cplusplus
#include "..H8SEmuioh82655.hpp"
#else
#include "..H8SEmuioh82655.h"
#endif
#else
#ifdef IMC_3V
#include "..commonioh_micro.h" /* ioh 82655/82328 definit
#else
#include "ioh82655.h"
#endif
#endif
#ifdef IMC_3V
#include "..commondiag485_sap.h"
#include "IMCreg_fpga.h"
#else
#include "diag485_sap.h"
#endif
#include "..commontimers.h"
#include "IMC_io.h"
#include "typedefs.h"
#endif
Hardware PlatformHardware Platform
Language PlatformLanguage Platform
Platform VersionPlatform Version
Adapted and used with permission
by Selex Communications

100% Generated code
Manage
“C” Module
Manage
“C” Module
Command
“C” Module
Command
“C” Module
I/O
“C” Module
I/O
“C” Module
...
“C” Module
...
“C” Module
Startup
“C” Module
Startup
“C” Module
RequirementsRequirements
DefinitionDefinition
Executable UMLExecutable UML
ModelingModeling
Platform SpecificPlatform Specific
MappingMapping
100%

POC Timeline
MDAPROC
May June July August September
Tutoring
10 dd
Development
35 m/d SC +
20 m/d cons/supp
Optimisation
10 m/d
100 %
0 %
Assessment
10 m/d
April
Legenda: dd = elapsed days m/d = man days

BlueAge from Netfective

MDA_WS

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to MDA_WS

Similar to MDA_WS (20)

MDA_WS