Agile Models Need to be Bottom-up

Adding Productivity to a Late Project Makes it Later

Pietu Pohjalainen

Department of Computer Science, University of Helsinki, Helsinki, Finland

Keywords:

Agile Modeling, Bottom-up Modeling, Productivity.

Abstract:

Model-driven architecture is a top-down approach to software engineering. Due to its heavy emphasis on

tools and process, it has not been considered to be not a good ﬁt for agile time-boxed iterations. Light-

weight models are often a better alternative in agile development. However, we argue that in order to realize

productivity gains, these models can and should be brought as software architecture level entities.

1 INTRODUCTION

Productivity is a key issue in professional software

engineering. In many software businesses, being able

to produce more functionality in a given timeframe is

advantageous: in a productive environment customers

gain more value from software projects, and project

professionals have higher job satisfaction.

Agile process methods currently help projects to

avoid big mistakes of producing the wrong prod-

uct to the wrong customer at wrong time. Im-

proved communication with the customer, learning

effect within agile iterations and time-boxed devel-

opment all contribute as process-level reinforcements

to project work. However, relatively little attention

is given to actual productivity improvements in agile

projects. This is surprising, given the fundamental na-

ture of productivity and productivity improvement in

history of industrialized world.

Model-driven engineering is a recent movement

with an attached promise for improved productivity.

Productivity gains in limited domains, such as com-

piler construction makes the idea of raising the level

of abstraction appealing. However, combining agile

process with engineering approaches that include any

signiﬁcant investment, or up-front planning, before

the engineering discipline can be employed can turn

out to be problematic.

To ﬁx these problems, we propose a ﬂavor of

model-driven engineering that accounts the restric-

tions imposed by agile software development process

models. This bottom-up agile model-driven develop-

ment recognizes smaller sub domains within the soft-

ware that are amenable for lightweight modeling. Th-

ese small models can be used in traditional source-to-

target generative programming or in some cases the

source code itself can be treated as the source model,

thus reducing redundancy. The bottom-up model-

ing approach entails lighter initial investment than

domain-speciﬁc modeling, and thus allows fast ex-

perimentation cycle within the limits of tightly time-

boxed agile iterations.

Tools with higher investment costs, or steeper

learning curve are problematic in the time-boxed de-

velopment models. This causes a paradox: produc-

tivity is deﬁned by the rate of output to effort. When

investing to better productivity, the investment can eat

up all the expected gains, due to the short visibility

time in a cycle-driven process. In the conclusion of

the mythical man month (Brooks, 1995) it was found

out that adding more people to a late project makes

the project later. A similar effect can be seen here:

adding productivity at a late stage of a project makes

the overall effort higher.

The rest of the paper is structured as follows.

Section 2 introduces the basic equations of process

improvement for software development and explains

how they relate to agile processes. Section 3 reviews

modeling related disciplines, namely model-driven

architecture (MDA) and agile model-driven develop-

ment (AMDD) and in the context of agile software

development. In section 4 we propose a lighter ap-

proach, called bottom-up modeling. Bottom-up mod-

eling takes the special characteristics of agile methods

into account, and makes it feasible to realize produc-

tivity gains associated with generative programming

in agile projects. Section 5 shows an example case on

how different modeling formalisms can be combined

395

Pohjalainen P..

Agile Models Need to be Bottom-up - Adding Productivity to a Late Project Makes it Later.

DOI: 10.5220/0004155903950400

In Proceedings of the 14th International Conference on Enterprise Information Systems (MDDIS-2012), pages 395-400

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

to produce meaningful systems. Section 6 sets out the

summarizing words and casts out the future work.

2 ECONOMIC MODEL

When investing in process improvement in software

development, the obvious question is how to esti-

mate the return-on-investment. Return-on-investment

is calculated by dividing the difference of beneﬁts and

costs of a change by the costs of the change, as shown

in formula (1).

(1)ROI =

Gain − Cost

Cost

Being an abstract activity, it is very hard to esti-

mate causes and effects in software development. For

this reason, also giving exact ﬁgures for estimating

whether process improvement is justiﬁable, is prob-

lematic in many cases. However, the general princi-

ples of economic thinking can be used to guide in de-

cision making, although the exact numbers for a given

decision might be impossible to calculate.

When a software development team is given a task

to implement a software product, the total cost for the

project can be calculated to be

(2)OC ∗ OT

Where OC stands for operational cost and OT

stands for operational time.

For example, if the average cost of one man-

month, including the salaries, ofﬁce spaces, cost of

computers and so on, in the project is 10 units, oper-

ating a software development team of ten people costs

100 units per month. If the software development

project takes ﬁve months, the total cost for the devel-

opment project is 500 units. Economic decision cri-

terion for improving total cost, using any given tech-

nology or managerial decision can be expressed as:

(3)OC ∗ OT > Cost + OC ∗ OT

In other words, the initial investment to implement

new practice or employ new techniques within the

project can be justiﬁed if the reduced costs with new

operations amortized over total operational time are

smaller than the alternative of running the operations

without changes.

Let us have a hypothetical development practice

that gives 25% improvement on productivity with no

consequences on schedule or personnel wages. Im-

plementing this practice has a ﬁxed cost of 50 units

and it is immediately implementable whenever the

project chooses to. If available at the beginning of the

project, it clearly should be employed, as the improve-

ment on productivity shortens the required time to im-

plement the project from ﬁve months to four months,

thus enabling a faster time-to-market opportunity and

clear savings on overall expenses.

However, with agile sprints, the productivity im-

provement should return its investment within an on-

going sprint. This is because there is no guarantee that

the project continues after the current iteration. To be

able to justify this investment with a one-month sprint

length, the promised productivity gain should shorten

the required operational time from one month to half,

which equals a productivity gain of 100%. Improve-

ments of this magnitude are likely to be available only

for very poorly performing teams.

In reality, this kind of reasoning for real software

projects is very hard, maybe impossible. The exam-

ple assumes a ﬁxed amount of work, which seldom

is the case. Productivity rates vary between individ-

uals and team mix-up in orders of magnitude, and

the hypothetical instant productivity boon option is

just a project manager’s daydream. However, the ba-

sic principle behind equation (3) is often encountered

in software development organizations: new prac-

tices and technologies are discovered, and a return-

on-investment justiﬁcation needs to be found for em-

ploying the practice in question.

3 MODELING AND AGILITY

Agile process improvement literature focuses mainly

on process-level practices. Less emphasis is given

to the actual software structures that are designable

in an agile process. This section reviews techniques

that have an attached productivity promise: the Ob-

ject Management Group’s Model-Driven Architecture

(Miller and Mukerji, 2003) and the Agile Model-

Driven Development (Ambler, 2004).

We argue that the classical model-driven architec-

ture’s approach is not very suitable for agile process

due to its heavy emphasis on tools and model trans-

formations. Then we propose that agile model-driven

development cannot be justiﬁed from productivity an-

gle, as the lack of formality in agile models prevents

the usage of automated handling. Domain-speciﬁc

modeling is seen as a good trade-off between formal-

ity and agility, but is still staying short of good agility

due to its emphasis on speciﬁc tool usage.

3.1 Model-driven Architecture

Model-driven architecture approaches re-usability by

separating concepts into three layers: platform inde-

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

396

Figure 1: A UML model with transformations to Java and

SQL.

pendent model (PIM), platform-speciﬁc model (PSM)

and program code. Traversal between these layers

is done via transformers: a platform independent

model is translated to a platform-speciﬁc model by

using a transformer, which augments the model with

platform-speciﬁc attributes. A similar transformation

is applied when translating the PSM into program

code.

A typical platform independent model is ex-

pressed as a UML class diagram, which contains only

class attributes, maybe with programming language-

level visibility information and data type annotations.

A transformation creates corresponding programming

language, e.g. Java classes, with accessing methods

for each of the public attributes; or data-deﬁnition

statements for a relational database.

Figure 1 represents a typical case, in which a class

model expressed in UML is transformed to program-

ming language code by one transformation. Another

transformation generates the corresponding database

deﬁnition. These transformations contain platform-

speciﬁc parametrization, as the transformation con-

tains information about the target platform. In the

UML-to-Java transformation, UML standard visibil-

ity rules are followed; but a data type transforma-

tion from UML integer to Java int is performed. In

the UML-to-SQL transformation, similar platform-

speciﬁc knowledge is being encoded. Most notably,

the transformations contain also information about

the system that are not shown in the source model.

For example, the knowledge about different ﬁeld sizes

for Name and Address ﬁelds that have the same data

type in the source model is encoded into the transfor-

mation.

A notable shortcoming in the agile mindset of us-

ing UML class diagrams to express the platform inde-

pendent models is the lack of extensibility. The class

diagram can directly express only a limited set of pa-

rameters, such as visibility, data types, and default

values. Further extensions require using UML pro-

ﬁles, which may or may not be supported by the used

toolset. This is a heavyweight way of producing pro-

ductivity: toolset evaluation takes time. Even through

the after the most rigorous evaluation, a toolset’s suit-

ability to project needs are known up to a certain limit.

Only practice will reveal whether the toolset actually

delivers its promised functionality, as any seasoned

professional can witness.

Another problem is that given the current fast

rate of change in technology choices and architectural

evolution in software engineering, the model transfor-

mations provided by the chosen toolset probably do

not match the current architectural needs of the de-

veloped software. When this occurs, the development

team has two choices: try to ﬁnd an alternative, better

suiting toolset or try to improve the existing toolset.

The ﬁrst option basically stalls development work, as

the focus has changed to ﬁnding the right tool for the

job instead of actually doing the job. The second al-

ternative, if viable at all due to copyright reasons, re-

quires specialized personnel who have the ability to

modify the transformations used by the toolset. Since

the development of the actual software cannot be de-

layed, the software’s architecture evolves in parallel

to transformation development. For this reason there

is a good chance that any given set of model transfor-

mations is already obsolete its completion time.

For these reasons, unconstrained usage of model-

driven architecture cannot be considered to be a good

match for current agile development environment.

However, we do not propose to canonically reject

model-driven architecture. Our critique primarily

bases on the combination of short-lived sprints of ag-

ile development and the uncertainty of toolsets and

practices promised by MDA tool vendors. In cases

where a toolsets abilities and limits are well known

in advance, using the toolset-driven approach can be

beneﬁcial even in tightly time-framed situations.

3.2 Agile Model-driven Development

Agile model-driven development (Ambler, 2004) at-

tacks the problems in model-driven architecture by

relaxing the strong formality and tool support require-

ments. Instead of using complex and extensive mod-

els, the approach emphasizes models that are ”barely

good enough” for a given task. Modeling is mostly

done top-down, although the approach does not dis-

courage a bottom-up approach.

Figure 2: A hand-drawn sketch in agile UML modeling.

AgileModelsNeedtobeBottom-up-AddingProductivitytoaLateProjectMakesitLater

397

According to this philosophy, created models

should not affect the agility principles of a given pro-

cess. As long as a model can be created and exploited

within a production cycle (usually 1-3 weeks), it is

suitable for agile modeling. This is a promising ap-

proach, but it does not state much about the possible

modeling tools - actually, the approach de-emphasizes

the need for tools, and focuses on people. A model is

suitable for the approach as long as it can be exploited

within a production cycle.

Due to this requirement, most modeling is based

on high-level abstract modeling languages with little

formalism. They are easy to learn, simple to use and

ﬁt well within a given time period. However, they of-

fer more to easier problem domain abstraction than

to automatic productivity increase. Under our best

knowledge, no productivity-related empirical valida-

tion has been done for agile model-driven develop-

ment.

4 BOTTOM-UP MODELING

We argue that productivity gains chased with model-

driven engineering should be combined with agile

development models by examining the productivity

problems that are encountered on project level. If

a given productivity problem gives a feeling that its

root cause is associated with the problem of lack of

abstraction, or incorrect level of abstraction, then it

could be a possible candidate for building a higher

level model for that particular part of the software.

We call this approach as bottom-up agile model-

driven development. In this approach bottom-up

models are a way to introduce light-weight modeling

to agile development process.

Instead of applying top-down methods, which re-

cursively decomposes the problem to smaller pieces,

we can alternate to a bottom-up approach. This ap-

proach identiﬁes smaller problems and develops solu-

tions to these. When this bottom-up cycle is repeated,

gradually the solution for the whole emerges. Given a

program domain, a bottom-up approach identiﬁes sub

domains that are amenable to modeling

Agile bottom-up modeling constraints the identi-

ﬁcation process to such tools and techniques that can

be applied in an agile process model. Its application is

thereby limited to a small number of tools, which can

be evaluated and applied within a tightly time-boxed

iteration. Yet, although this search and discover ap-

proach theoretically produces non-optimal solutions,

it guarantees that progress is not stalled while search-

ing for the optimal solution. This way, a bottom-up

approach to modeling dodges the heavy up-front plan-

ning phase.

An essential property of bottom-up modeling in

agile process is that the building of model languages

and models can be decomposed into sprintable form.

We mention both model languages and models be-

cause the essence of bottom-up modeling is to ﬁnd

suitable abstractions to the problem at hand, and of-

ten this means inventing a new language or reusing an

existing language for modeling. This notion is con-

tradictory to common wisdom of using the best exist-

ing tool for the job at hand. However, given the large

number of different tools and techniques available on

the market, it is not possible to do a throughout tool

evaluation within the time frame of an iteration. For

this reason, agile teams often need to build their own

abstractions for modeling.

These abstractions or languages are not neces-

sarily complex, meaning that there is no mandatory

need to building complex modeling languages with

associated tool support. Instead, existing languages

can be piggy-backed and reused as is common with

domain-speciﬁc languages (Mernik et al., 2005). Also

a domain-speciﬁc modeling tool can be employed,

once an initial understanding of the problem at hand

has emerged. However, the obvious downside of this

approach is that repetitive application of ad hoc mod-

eling constructs might gradually erode the overall ar-

chitecture of the software.

Bottom-up modeling does not limit the format of

source models, as long as the model is expressible in

machine-readable form. This means that the model-

ing language does not need to be a graphical boxes-

and-arrows -type tool. Actually, although the tradi-

tional boxes-and-arrows kind of modeling can be ben-

eﬁcial in the drafting board, the lack of exact inter-

pretation for the used symbols hinders productivity

when forwarding these models to any type of auto-

matic code generation or runtime interpretation. Of-

ten used alternatives are external domain-speciﬁc lan-

guages, but an interesting choice is to use the source

code as the source model. This option is interest-

ing for practical programming, as using the source

code as the source model for further transformations

builds increased robustness against modiﬁcations into

the software.

5 A CASE STUDY

In order to illustrate the idea of using the bottom-

up approach to modeling, we show a case of using

bottom-up modeling for implementing a feature mod-

eling (Kang et al., 1990) environment in a bottom-up

way. Feature modeling is a formalized way of build-

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

398

ing option spaces. The formalism allows to deﬁne

structures with mandatory features, optional features

and combinations of them.

An example presented in (Czarnecki and Eise-

necker, 2000) models an option space for a car is

shown in Figure 3. The car needs to have the body,

the transmission, and the engine. The transmisison

can alternatively be automatic or manual. The engine

can be electric or gasoline driven, or both. Optionally,

there can be a trailer pulling hook. Given this option

space, there is 12 distinct conﬁgurations that satisfy

this model.

Figure 3: A feature model of a car.

For our discussion, the interest lies in how to im-

plement functionality to handle these kinds of models.

In model-driven architecture, the standard approach is

to use transformations to bring the source model into

the streamline of standard modeling languages. Thus,

a transformation for translating the feature model into

an UML model is needed. Literature presents vari-

ous ways for doing this. Many researchers (Clau and

Jena, 2001; Griss et al., 1998) have presented differ-

ent ﬂavours of using stereotypes for representing vari-

ability in UML.

These studies contain many ﬁne points for imple-

menting beautiful models of variability using the stan-

dard technologies. However, for practical software

development cases, the variability is just one of the

dozens, hundreds or thousands aspects that a devel-

opment team needs to tackle. It can be impractical to

start discussing about the academically correct way of

implementing this variability, since it can be hard to

demonstrate how this discussion brings value to the

end customer. Due to the economic reasons discussed

in Section 2, it probably never will.

An alternative is to work with this speciﬁc prob-

lem, using the standard tools offered by the imple-

mentation environment. For the variability example,

(Pohjalainen, 2011) have documented a way of us-

ing standard regular expressions for modeling vari-

ability. This approach combines good parts from both

of formal modeling and agile product development.

The approach has the beneﬁt that the customer can

be shown steady progress, since modeling is concen-

trated on small subdomains that are suitable for mod-

eling. On the other hand, since the models are im-

plemented by using the standard implementation en-

vironment structures, the mismatch between model-

ing environments and implementation is kept at mini-

mum.

For the feature model in Figure 3, the bottom-up

modelled deﬁnition could be implemented using reg-

ular expressions as follows:

car body

transmission (automatic | manual)

engine (electric | gasoline)+

pullsTrailer?

This is a very concise way of using higher level

abstraction to bring beneﬁts of modeling into imple-

mentation level.

However, using this kind of modeling language-

speciﬁc translation to the implementation language

raises some questions. Using UML models gives the

possibility to scale the scope of modeling to include

also attributes of modeled entities. For example, if

there is a need to specify the size or power of the en-

gine being modeled. In a class diagram, it is very

straightforward to add the attribute in question to the

class model. But using regular expressions to model

even three to ﬁve different engines would soon prove

to be cumbersome.

Our approach to this problem is to exploit the na-

ture of bottom-up problem solving. The chosen mod-

eling implementation was ﬁne for that speciﬁc prob-

lem, and when given a new problem, we look for

a suitable solution. Re-using the notion of piggy-

backing existing languages, we can choose to use e.g.

XML Schema (Biron and Malhotra, 2004) for data

modeling. For example, a data model for deﬁning

1.4 liter or 1.6 liter gasoline engines in XMLSchema

could be as follows:

<?xml version="1.0" encoding="UTF-8" ?>

</restriction>

</simpleType>

<element name="gasoline"

type="enginesize" />

</schema>

With this approach, the data modeling is done by

deﬁning XML Schema models. The expressive power

of the schema language greatly overpasses the one

offered by standard UML class diagrams (Martens

et al., 2006). Another beneﬁt is that standard XML

tools can be used to validate data transmissions and its

AgileModelsNeedtobeBottom-up-AddingProductivitytoaLateProjectMakesitLater

399

car body transmission

(automatic | manual) engine

(electric | gasoline)+

pullsTrailer?

<?xml version="1.0" encoding="UTF-8" ?>

<element name="gasoline"

type="enginesize" />

</schema>

Variability +

data modeling

Figure 4: Combining two modeling languages.

semantics is well understood. As a formal language,

the source documents can also be used for further

model transformations; the schema language contains

a well-deﬁned variation point holder for deﬁning new

features for the data modeling tool.

This way, bottom-up modeling can use a mix-and-

match approach for selecting the suitable tools for sit-

uations rising in development projects. In this case

study, the developers chose to use regular expressions

to model variability and the XML schema for data

modeling. Combining these two allowed the develop-

ers to use models as ﬁrst-class citizens in their prod-

uct, since both of the used modeling languages were

supported in the programming environment. Equally

important, the developers were able to show steady

progress towards the customer, since no delays were

involved in tool evaluations.

Figure 4 shows a conceptual picture of the idea of

combining two modeling languages into a meaningful

entity.

6 CONCLUSIONS

We have argued that in agile software engineering the

tight timeboxing of sprints creates problems for long-

term planning. The option to change direction after

every two weeks gives added ﬂexibility, but deterio-

rates efﬁciency gains from the usage of models and

model-driven engineering.

We propose that in order to bring the beneﬁts of

model-driven engineering to agile projects, the mod-

eling activities should be placed in bottom-up fashion.

A good choice for tackling the risks of unadequate

tool support and overly optimistic tool vendor claims,

the bottom-up models are chosen from the set of well-

known tools with known implementations at hand.

The beneﬁts of using this kind of reusing of exist-

ing implementation tools and techniques include the

possibility of matching modeling needs with avail-

able technologies. Another beneﬁt is that building

the modeling practices from bottom-up enables a pay-

as-you-go -type investment to modeling technologies:

there is no need to heavily invest in unknown tech-

nologies with no guarantees of payback.

In the case study we showed how to combine vari-

ability modeling, implemented using a regular lan-

guage engine, and data modeling, using the XML

Schema language. This combination of modeling lan-

guages was used in the case study company, where

the developers were able to gain a higher level under-

standing of their system via the use of these modeling

tools.

REFERENCES

Ambler, S. (2004). The Object Primer: Agile Model-Driven

Development with UML 2.0. Cambridge University

Press, 3rd edition.

Biron, P. V. and Malhotra, A., editors (2004). XML Schema

Part 2: Datatypes. W3C Recommendation. W3C,

second edition.

Brooks, Jr., F. P. (1995). The mythical man-month (anniver-

sary ed.). Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA.

Clau, M. and Jena, I. (2001). Modeling variability with

UML. In In GCSE 2001Young Researchers Workshop.

Czarnecki, K. and Eisenecker, U. W. (2000). Gener-

ative programming: methods, tools, and applica-

tions. ACM Press/Addison-Wesley Publishing Co.,

New York, NY, USA.

Griss, M. L., Favaro, J., and Alessandro, M. d. (1998). Inte-

grating feature modeling with the RSEB. In Proceed-

ings of the 5th International Conference on Software

Reuse, ICSR ’98, pages 76–, Washington, DC, USA.

IEEE Computer Society.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E.,

and Peterson, A. S. (1990). Feature-oriented domain

analysis (foda) feasibility study. Technical report,

Carnegie-Mellon University Software Engineering In-

stitute.

Martens, W., Neven, F., Schwentick, T., and Bex, G. J.

(2006). Expressiveness and complexity of xml

schema. ACM Trans. Database Syst., 31(3):770–813.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

Comput. Surv., 37(4):316–344.

Miller, J. and Mukerji, J. (2003). MDA guide version 1.0.1.

Technical report, Object Management Group (OMG).

Pohjalainen, P. (2011). Bottom-up modeling for a software

product line: An experience report on agile modeling

of governmental mobile networks. Software Product

Line Conference, International, pages 323–332.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

400