Agile software Development

Dr. Zaigham Mushtaq

Assistant professor
Department of Computer Science, University of Management & Technology.

The picture can't be display ed.

 Background & Motivation
 How do we build software development methods?
 Whether we are constructing new ones, or integrating them?
 But what are the best practices and principles for
building/integrating methods?
 Based on, e.g., the many examples we have of combining
languages, integrating methods, etc., from the IFM community?
 Is there a process that we can follow?

2 The picture can't be display ed.

 The Reality
 Methods are not static constructs.
 They are usually tailored when development starts.
 Process phases are discarded or added.
 Tool support is developed/bought which has knock-on effects.
 Notations/languages are extended or restricted (e.g., UML).
 Measurement/management tasks are aligned with technical
tasks.
 Our initial requirements for a development method will
not match what is required 10 weeks into the project.
 What developers need to use may change.
 What managers require of developers may also change.
 We should anticipate that our requirements for a method
may change, even while the method is being used.
3 The picture can't be display ed.
 Premise
 A software development method is like a software
product.
 This phrase is deliberately chosen (discussed later).
 It can be built, has quality attributes, and its users have
functional and non-functional requirements for it.
 If we can systematically build software, we can
systematically build a software development method.
 Work on process modelling (e.g., SPEM), process meta-models
and process patterns (e.g., Ambler, Coplien), MDA components
also take this view.
 We take a contrasting, though compatible view:
 You can’t fully anticipate requirements for a method, and even if
you could up front, they’re going to change.
 We need to be agile in constructing software development
methods.

4 The picture can't be display ed.

 What Do We Mean by Agile?
 The Agile Manifesto (www.agilemanifesto.org) is a
set of guiding values and principles that have been
shown to be valuable in software development.
 There is an emphasis on team-work and involving the
customer in development.
 There is an expectation that requirements will change,
and this should influence how we design software.
 There is an emphasis on doing the simplest thing that
will work now, rather than on trying to anticipate the
uncertain future.
 These are principles, not rules - individual and team
judgment must always play a role.

5 The picture can't be display ed.

 Some Example Principles
 Satisfy the customer through early and continuous
delivery of working software.
 Welcome changing requirements, even late in the
development process.
 Deliver working software frequently.
 Business people and developers must work together.
 Simplicity - the art of maximizing the amount of work not
done - is essential.
 Working software is the primary measure of progress.

6 The picture can't be display ed.

 Agile Methods
 Agile methods take these principles and generally try to
implement them using concrete practices.
 Example: Extreme Programming.
 Planning game: quickly determine the scope of the next release
using business priorities and technical estimates.
 Testing: developers write unit tests which must run flawlessly
for development to continue. Customers write tests
demonstrating that features are finished.
 Collective ownership: anyone can change any code anywhere in
the system at any time.
 Pair programming: all production code is written with two
programmers at one machine.
 ...
 Lots of other agile methods exist, e.g., FDD, TDD,
Scrum, Crystal, Agile Modelling...

7 The picture can't be display ed.

 Agile Construction of Methods
 Agile principles & practices can be used to deliver
working methods to customers.
 delivery includes documentation, languages, tools, process.
 Similarities between software and methods:
 Methods have behaviour and can be tailored.
 Methods have descriptions (e.g., a user manual).
 Methods require experts to tailor and extend.
 Differences between software products and methods:
 Software products come with an executable description;
methods generally don’t (though see MDA components)
 We can tell when a software product is well-formed (it compiles
and executes); when is a method well-formed?
 Software has dimensions (e.g., KLOC, MTBF).

8 The picture can't be display ed.

 Using Agile Techniques to Build Methods
 Agile Method Development can happen in parallel with
Software Development.
 Ostensibly it should happen in this way.
We need feedback about how well the method meets its
requirements.
 Thus in Agile Method Development we view the method as
something that evolves from real application.
 How do principles from Agile Manifesto apply to
building methods?
 An agile method for building methods.
 Examples: SCOOP + CSP, MOF Action Semantics.

9 The picture can't be display ed.

 Agile Manifesto of Building Methods
 Many of the principles apply directly:
 “Welcome changing requirements”: we should anticipate that
our methods will change during development
Customers may request “refactorings”, e.g., new process phases,
new notations or languages, to be added.
 “Deliver working methods frequently”: the first version of a new
method should be available quickly - days or a couple of weeks
rather than months - for customers to try it out.
 “Working methods are the only measure of success”: thus the
method must be developed while it is being used by real
software developers.
 “Simplicity is essential”: build the simplest method that works
now.
 ... lots more in the paper
 “Self-organizing teams”: not clear how essential this is
for method developers.
10 The picture can't be display ed.
 Agile Method Development
 So how do we implement these principles?
 Let’s be agile!
 A simple method for method development (cf. TDD, FDD):
1. Construct user stories, i.e., how developers would like to use the new
method.
2. Prioritise the stories.
3. Deliver a method increment that satisfies the highest-priority stories.
 Iterative/incremental.
 A method increment goes some way towards satisfying user
stories.
 How do we describe a method increment? What’s a good method
increment?
 These are domain dependent.
 XP doesn’t say how you should describe your software.
 But XP/TDD do help you to measure success (your tests pass).
 The only analogy of this in method development will be customer
success and positive feedback.
11 The picture can't be display ed.
 Case Study
 Details in the paper.
 Integrating Simple Concurrent Object-Oriented
Programming (SCOOP) extension to Eiffel with CSP.
 Not just a language integration, but process/tools as
well.
 Initial motivation: soundness of SCOOP.
 Theoretically: it’s a complex concurrency model with a precise,
yet informal semantics.
 Practically: industrial interest to get a working compiler.
 Efforts in parallel with development of prototype of
SCOOP and evolution of the standard.

12 The picture can't be display ed.

 First User Story
 Customer: “We want to be able to reason, formally,
about the semantics of SCOOP programs.”
 Lots of uncertainty here:
 What sort of reasoning? Automated? Semi-automated? What
types of properties are interesting?
 All SCOOP programs? Are some more important than others?
 Negotiation with users to refine this initial story.
 Customer: “For any SCOOP program we would like to be
able to extract its concurrent behaviour in isolation, and
reason – ideally with tool support – about the behaviour of
routine calls. In particular, we would like to be able to reason
about the behaviour of routine calls in the presence of
contracts, but also would like to be able to reason about
object reservations and lazy evaluation.”

13 The picture can't be display ed.

 Iterations
2. Object reservations:
1. Subsystem Model
reserving

5. Additional tool 3. Object reservations:

support for simulation. releasing

Customer

Deliverables:
Model
FDR2 program
4. Call queue
refactoring process for going
from SCOOP to
FDR2
design decisions
14 The picture can't be display ed.
 MOF Action Semantics
 Case study not discussed in paper.
 Customer: “Extend Meta-Object Facility (MOF) and its supporting
tools to capture behaviour.”
 Motivation for this was to improve consistency checking of MOF-
based languages, such as UML.
 Initial set of requirements:
 Need to capture actions, and do intra-model consistency checking (eg.,
between class and communication diagrams)
 Iteration 1 produced a partial semantics and a partial
implementation using UML2MOF.
 Refined requirements then asked for coverage of events and object
lifecycles, as well as standalone tool support.
 Iteration 2 produced a semantics, navigation language, and
consistency checking tool, as well as a process to use them.

15 The picture can't be display ed.

 Conclusions
 Build your methods with their intended users in mind.
 Better yet – build your methods in collaboration with your users.
 Ideally in a way that allows detailed feedback to be obtained while the
method is being used in anger.
 You can be agile if your users are a willing participant in the
development of your method (easier said than done).
 The approach is realistic and cost effective.
 We produced the MOF AS to extremely tight deadline (~ 3 weeks)
 Developed the SCOOP-CSP integration within a few weeks as well
(without a Sword of Damocles)
 A key question: ‘success criteria’ for a method – i.e., what are the
equivalents of unit tests in agile method engineering?
 Strawman examples, e.g., in MDD everyone does the Pet Store or
Library?
 User feedback.

16 The picture can't be display ed.

 Method Increments
 The method evolves as new user stories are
implemented in a method description.
 Each method increment may involve adding new
notations, adding process phases, modifying phases,
delivering new tools, etc.
 Change requirements may come from developers as
they use the method.
 Will lead to new user stories and re-prioritisation.
 Not all user stories need be implemented by method developers
in order for users to achieve success.
 Basically, this approach builds the smallest, simplest method
that supports the developers understanding of their
requirements at this moment.

17 The picture can't be display ed.