This document discusses model-driven development using the Be Informed platform. It makes three key points:
1. With Be Informed, there is no clear distinction between design and development - the design is directly implemented. This impacts traditional function point analysis for estimating.
2. Productivity depends highly on customer maturity and ability to make decisions. Experience of the implementation team also impacts productivity.
3. A "Be Structured" approach is recommended, starting with architecture and business function models to provide structure before detailing and growing applications live. This provides better predictive value for estimating than traditional function points.
3. Be Informed is a direct model-driven
business process platform.
The Be Informed technology and solutions
provide break-through results for administrative processes,
that are becoming more knowledge-intensive.
4. The Be Informed story…
2015 - Realize the dream!
2012 - First Pan European project,
Solutions
2010 – 150 staff
NAF Award Again
2011 - Be Informed USA and UK
Be Informed 4.0
2007 - Be Informed 3.0
2009 - First Million+ Euro deal,
Gartner Cool Vendor,
2004 - Be Informed 1.0 NAF Award
2002 - First toolkit
2006 - Government portal,
Be Informed established
2003 - Thrown away,
too conventional
6. Traditional Model-driven
analyst
data data
Above the line logic
logic Above the line
developer
1010
0110
system 1010
0110
system
integration integration
8. The essential idea: don’t translate, but detail
No clear distinction between design and build
business
process & architecture
requirements functional
design technical
design
code
translate translate translate translate
business
process
develop define
model requirements
detail design
11. • Be Informed estimation general
• Zooming in on fpa
12. Starting points Be Informed estimation
discover
• Combining different estimation techniques
- usage of historic project metrics for model estimation
- analogy estimation based on project archetype and model archetype
define
- model based FPA
• In line with Be Informed implementation method: design
- Estimation at end of Discover, Define and Design phase with
increasing reliability and accuracy
- Use right terminology for applied Be Informed patterns and
characterization of business knowledge domains, business
functions and components.
• Support in project estimation of Be Informed implementation core
- framing and qualifying of scope application
- estimation of scale and scope
- estimation of productivity and cost drivers
• Support in project control of Be Informed implementation
- managing project scope by monitoring characteristics
- tracking of productivity vs. size (and therefore time) detail
12
13. Characteristics and Metrics
• Characteristics describe a project on content properties
unambiguous characterization of project -> estimate based on analogy
enables monitoring on content properties
• Metrics describe a project in quantitative properties
Metrics defined on substantive and statistical grounds -> estimate based on models/formulas
Enables monitoring on quantitative properties possible
• Monitoring of characteristics by :
• Repeated determination: holds the target operating model still the same components ? Is the
number of core taxonomies still the same ? Do we still have the same number of experienced
analysts ?
• Relating to measurements of metrics: e.g. In the second increment we did 20 knowledge models
in six weeks.
Size Productivity
Characteristics Knowledge service / taxonomy Application architecture,
pattern, knowledge domain, teamexperience, projectmonitoring,
products, business functions, Avalability of domain knowledge
registrations
Metrics Number & size core taxonomies Number of knowledge models /
depth of norms, principles and concepts per core taxonomie,
properties, activities, atribuutsets historical metrics, project WBS
Derived metrics Number of knowledge models / Number of hours / knowledge model
concepts or concept
13
14. size-based estimation for each component
Functionaliteit FP MD €
Externe Berichten Simpel Medium Complex
Inkomende berichten 0
Uitgaande berichten 0
Tijdtriggers 0
Registraties #objecten #activiteiten Triggers
Companies 4 79 2 1.600
Applicant Case worker Stationary installations 3 52 17 13.944
Documents & Mail 2 45 12 9.296
Persons 3 52 2 1.600
Aviation 1 38 6 4.648
0
Kernfuncties #objecten #activiteiten Triggers
used by used by used by used by used by used by Permit request & update MP 21 178 122 97.608
Report Annual Emissions 13 122 76 60.424
Verification 3 52 17 13.944
Enforcement 0
0
0
Applicant Welcome Documentation Case worker Serviceprocessen
Authorization
#objecten #activiteiten
3
Triggers
43 4 3.486
E-mail 3 43 4 3.486
Archiving of cases 3 43 4 3.486
offers offers 0
0
Portalen instruments bronnen overzichten
Housing benefit request
Operator 2 5 1 40 9 7.200
Competent Authority 2 5 1 40 9 7.200
Verifier 2 5 1 40 9 7.200
0
lookup 0
creates
Rental Koppelingen Simpel Medium Complex
house creates calculates
Decision XETL Data import 6 3 63 24 19.200
triggers document e-authenticatie
public website CA
1
1
7
7
4
4
3.200
3.200
decides Ogone payment 1 7 4 3.200
0
Output producten Simpel Medium Complex
rtf/pdf generation form 3 21 15 12.000
Amount
XML XETL generation form 3 21 15 12.000
Customer 0
Screening Eligibility
Rapportages Simpel Medium Complex
users & involvements 1 7 2 1.600
Article 21 report 1 7 18 14.400
reports related to fuel 4 28 8 6.400
Excel export MP & EAR 2 14 4 3.200
Quality control reports 3 21 6 4.800
Kenniscomponenten FP MD
kerntaxonomie omvang kerntaxonomie
Tier table 40 7 17 13.200 in
Source stream 20 7 8 6.600 in
Trend analysis 20 7 8 6.600 in
Aviation Monitoring Type 10 7 4 3.300 in
0 0 in
0 0 in
0 0 in
14
16. • Be Informed estimation general
• Zooming in on fpa
17. “ FPA is an implementation
independent measure of the
functional size. So: why
would you need a Be
Informed-specific guideline?
”
17
18. Model = Documentation = Application
• Counting or estimating fp’s must
indeed be performed implementation
independent;
• The system’s design should be used
as input;
• With model based development the
design artifacts can differ greatly
from what the standard NESMA
guideline expects;
• This is also the case with Be Informed
designs.
18
19. Traditional design elements versus model
• Online functions • Events, case
• Selection lists screens, case tabs
• Reports • Knowledge
• Etc. instruments
• Selection lists
• Reports
EI EO EQ EI EO EQ • Etc.
ILF ILF
EIF EIF
External data Internal External data Internal data model, case
model data model model definitions, core taxonomies
20. NESMA prescribed Rationale
• Structure model • Identify data files
• Data model identifying • Determine complexity of data files
record types and
data element types
• Indication of the information • Distinguish between ILF and EIF
system maintaining the data
• Behavioral model of the system • Identify user transactions
• Detailed description of the flow of • Determine complexity of user
data element types and controls transactions
21. NESMA prescribed Be Informed provided
• Identify data files • Case model and case meta model
Knowledge model
Datastores
Service interfaces
• Determine complexity of • n/a
data files
• Distinguish between ILF and EIF • Case (meta) model: ILF
Knowledge models and interfaces: EIF
Datastores: can be both (mostly ILF)
• Identify user transactions • Events: EI, EO or both
Selection lists, reports and documents:
extra EO
Case tabs and case screens are complex
meta functions: EO
• Determine complexity of user • n/a
transactions
22. “ Why count knowledge models
as data files?
”
22
23. • The standard guideline assumes that
a system’s functionality can be
described entirely in the form of
functions and files;
• With Be Informed a system’s
functionality is described in the form
of functions, files and taxonomies;
• There is a parallel between the
structure of data and the structure of
Be Informed knowledge models;
• Data has a principal structure that is
expressed in entities;
• Be Informed knowledge models
have a principal structure that is
expressed in taxonomies.
23
24. Be Informed function point analysis
• Certified guideline
• Accepted method in Dutch
Government domain
• Good method to determine
size of application / solution
• Scope creep detected by
recalculation
24
26. Recap: the essential idea: don’t translate, but detail
No clear distinction between design and build
business
process & architecture
requirements functional
design technical
design
code
translate translate translate translate
business
process
develop define
model requirements
detail design
27. Sizing related to productivity
Wide spread of productivity due to:
• Productivity is measured from ‘design to acceptance’
Be Informed is direct model driven: there is no real distinction
between design and build. The biggest effort however is in the
design and not in the build.
• Productivity strongly depends on the customer organization:
• Maturity of requirements management;
• Ability to take decisions.
• The experience of the team is also an important productivity factor
but this can more easily be taken into consideration
27
28. Function points for sizing Be Informed?
• Good results with estimating and justifying
functional size based on function points with
models as design input
but
• FP are less relevant for estimating effort in
early stages.
Causes:
1. Less design upfront;
2. High impact of design choices on productivity
and scope;
3. Design itself has the most predictive
value for productivity.
april 2009 28
29. Remedy: Be Structured approach
Structure Grow live
Be Informed architecture Detail
Business Function model
Target operating model
Business Ontology
Business design:
Core application
Detail
Detail
Develop
DTAP Continuous integration
Set up and test
Accept and integrate
29