Dr.P.M.MANOHAR, DEPT.

OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM

AGILE SOFTWARE DEVELOPMENT – MODULE-1

19ECS451: Agile Software Development

Module I: Introduction: The Agile manifesto, Agile methods, XP: Extreme Programming, DSDM,
SCRUM, feature- Driven Development, Test Driven Development, modelling misconceptions,
agile modelling, tools of misconceptions, updating agile models.
Learning Outcomes:
After completion of this unit, the student will be able to:
1. Understand Agile concepts (L1)
2. Distinguish different agile methods for software development(L2)
3. Describe the origins and motivations of the Agile Manifesto(L3)
4. Analyse requirements to prepare features and user stories (L4)
5. Construct different agile models(L6)

Introduction
Agile
• Dictionary meaning - quick moving, nimble
• In terms of Computing – it is a group of various methods that aim to nimble and quick moving
in response to
o changes in requirements
o the people that comprise the development teams
o issues that arise during the software development process
• The agile software development process primary goal is to be
o Effective - producing working, detect-free software
o Sufficient - meeting requirements both in the short-term and in the long-term
• Agile Methodology is a method
o tries to be responsive to the needs of the software development process
o based on practise and experience
o focuses on being effective and sufficient
• Agile is a project management methodology that breaks down larger projects into smaller,
manageable chunks known as iterations.
• At the end of every iteration (which typically takes places over a consistent time interval),
something of value is produced.
• The product that’s produced during every iteration should be able to be placed into the
world to receive feedback from stakeholders or users.
Agile Manifesto
The manifesto proposed the following values to produce better software
• Individuals and interactions over processes and tools
o the people involved and how they communicate that typically leads on the success
(or failure) of a software project.
o the best people and group interactions are encouraged

1
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

• Working software over comprehensive documentation

o Importance should be given for working software
o documentation should not be a major goal in and of itself. Instead, it should be a
supporting medium for the actual product – the software.
• Customer collaboration over contract negotiation
o time should be spent on working with customers and in getting them involved in the
software development rather than on detailed contract negotiations
• Responding to change over following a plan
o agile software development embraces change rather than saying “it’s not in the
requirements or the plan, so we can’t do it.”
o Planning is also important but the project adapts itself to its environment
Principles of Agile methodologies
• Based on these value statements, a set of 12 principles have been identified.
• The aim of these principles is twofold. First, they are intended to help people gain
a better understanding of what agile software development is all about.
• Second, they can be used to help to determine whether you as a developer are following
an agile methodology or not.
1. Highest priority is to satisfy the customer
2, Welcome change
3. Deliver working software frequently
4. Business people and developers must work together daily
5. Build projects around motivated individuals
6. Face-to-face communication is best
7. Working software is the primary measure of progress
8. Promote sustainable development
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity – the art of maximising the amount of work not done – is essential
11. The best architectures, requirements and design emerge form self-organising teams
12. Introspection – teams should regularly review itself and its processes to try and
improve
• From this, agile methodologists have tried to devise methods that move from
o heavyweight to lightweight processes,
o document-oriented to code-oriented objectives,
o predictive to adaptive methods,
o process-oriented to people-oriented activities.

2
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Agile Methods
• Dissatisfaction with the overheads involved in software design methods of the
1980s and 1990s led to the creation of agile methods
These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly to meet
changing requirements.
• The aim of agile methods is to reduce overheads in the software process (e.g. by
limiting documentation) and to be able to respond quickly to changing
requirements without excessive rework.

• Main theme - to produce a working solution and be able to respond to changing user/client
requirements.
• Difference between agile methods compared to more traditional methods
o Traditional methods - considered the functionality to be fixed, but the time
available and the number of resources that can be applied are variable
o Agile methods - the time available and the resources available considered to be
fixed, while the functionality is considered more flexible

Fig1. Difference between Traditional methods and Agile methods

• Five core methods under the umbrella of the term Agile being worked on and with at the
present time
1. Agile Modelling
2. eXtreme Programming (or XP)
3. Dynamic Systems Development Method (or DSDM),
4. SCRUM and
5. Feature-Driven Development (or FDD)

3
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Agile Modelling
• At design stage, it tries to find an appropriate balance between too little modelling, and
too much modelling.
• Agile Modelling provides guidelines how to create effective models and how to be an
efficient modeller
• The three main goals
o The definition and promotion of a set of values, principles and practices that help
to produce the appropriate models
o Guidance on how to apply modelling to an agile software development
o Guidance on how to apply agile modelling to other software processes (such as
RUP)

• Criteria of Agile Models to meet

1. Agile models provide positive value
• is there a real need for the model,
• will it help in the general aim of producing the final deliverable software?
• If not, then within the Agile Modelling philosophy it is not required.
2. Agile models fulfil their purpose
• Use light-weight tools - a drawing on a white board may be good enough to serve
its purpose
• don’t use a heavyweight tool such as Rational Rose
3. Agile models are understandable
• Understandable to their intended audience but not necessarily to everyone.
4. Agile models are sufficiently accurate
• General understanding of what our software was doing is required
5. Agile models are sufficiently consistent
• If one model has more detail in than another, it does not matter as long as they
are both understandable by their target audiences
6. Agile models are sufficiently detailed
• it may be sufficient merely to get the general concepts across
7. Agile models are as simple as possible
• The less information within a model, the easier it is for the reader to absorb.
Advantages of Agile Model
• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.

4
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

• Working software is delivered frequently (weeks rather than months).

• Face-to-face conversation is the best form of communication.
• Close, daily cooperation between business people and developers.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed.
Disadvantages of Agile Model
• In case of some software deliverables, especially the large ones, it is difficult to assess
the effort required at the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
• Only senior programmers are capable of taking the kind of decisions required during
the development process. Hence it has no place for newbie programmers, unless
combined with experienced resources.
XP: eXtreme Programming
• It is a way of supporting small development teams working within uncertain and
changing requirements
• focussed on the timely delivery of software that meets users’ requirements
• react immediately to changing customer requirements, even late in the development
life cycle
• designed as an approach based on software engineering principles, but focussed
on the timely delivery of software that meets users’ requirements
Four basic principles
Communication: it is good to talk (particularly, between users and developers
Simplicity: keep it simple and grow the system as and when required
Feedback: let users provide feedback early and often
Courage: to go with such an approach
These four basic principles have led to the following Key Ideas
Code in pairs
o The idea is that all software is developed in pairs (i.e., with two programmers at
one screen).
o The concept is that if code reviews are good, because they force at least one other
person to consider your code, then constantly working in pairs results in constant
reviewing of code and feedback between the two developers.
Stay in contact with the customer
o Meet regularly with the customer to give information and receive feedback.

5
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

o For example, place a customer representative in the team, so that you have access
to them all of the time.
Create tests before coding then test heavily
o Developers should write the unit tests before the code to be tested.
o You should then automate testing so that you can regularly re-run the tests to make
sure that nothing that has been done breaks earlier results.
Short iterations
o Each iteration should be relatively short allowing for rapid and frequent feedback.
o Thus, a minimal system may be produced and possibly even put into production
quickly and the system will grow in whatever directions prove most valuable.
Keep it simple
o Start projects with a simple design that can evolve later as required by future
iterations.
o This removes unnecessary complexity from early iterations.
o It also removes the need to code in additional functionalities believed to be required
by future iterations, but which may actually never be needed.
Don’t anticipate: code for current needs
o Don’t over-engineer solutions based on what they may one day need to do, rather
focus on what they need to do now and leave tomorrow’s functionality to tomorrow
Collective ownership
o Everyone within the team owns the software and has responsibility for it.
o When something goes wrong, no one should ever consider it not to be his or her
problem
o In turn, XP does not support a culture of blame and recrimination – everyone is
responsible for all the code.
o As a result of this, everyone is responsible for fixing a problem when they find it
rather than ignoring it.
The XP Project Lifecycle
• XP provides a software development lifecycle model as well as guidelines on the
organisation of a software development team

6
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

XP Lifecycle

Fig. 2 XP lifecycle
User Stories
• User stories are similar in some respects to Use Cases
• aim to capture how the user will use the system
• they are written by the users themselves and not by the development team
• User Stories are not detailed requirements
• should be short - should use the terminology of the user and not the terminology of the
software development team
Architectural Spike
Spike
• Spike is an attempt to reduce the risk associated with an unknown area of the system,
technology or application domain
• Research and analysis of the architecture to use should be carried out and fed into the
release planning meeting
Release Planning
• A release-planning meeting is used to create the release plan, which lays out the overall
project.
• The release plan indicates which user stories will be implemented and in which release
this will happen
• Also indicates how many iterations are planned and when each iteration will be
delivered
• This is done by negotiation between the interested parties using estimates derived from
the user stories.
• The estimates are produced by the technical members of the team potentially with input
from the users.
• The users priorities the user stories possibly with input from the technical team members.

7
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Iterations
• Each iteration within the project adds to the agility of the development team.
• development team at each iteration adds - changes can be made to what will be done
and when it will be done.
• The shorter the iteration, the quicker the development team can respond to changes
• At the beginning of each iteration, an Iteration Planning meeting is held to determine
exactly what will happen within that iteration
• further iteration planning meetings should be called during the iteration for the
unachieved
• to concentrate on completing the most important tasks as chosen by your users
Acceptance Testing
• The acceptance tests are created from the user stories, written at the start of the project.
• Each iteration implements one or more user stories; these stories will be translated into
a series of acceptance tests during the iteration.
• the users assess the results of the acceptance tests and reviewing test scores to decide
which failed tests are of highest priority
• in each iteration, all previous Acceptance tests should be run to ensure that nothing has
been broken
Release

• XP promotes the concept of “small releases” and “release often.”

• allow early and frequent feedback from the users

The Dynamic Systems Development Method (DSDM)

• Provides a framework of controls and best practice for Rapid Application Development
(RAD)
• suitable for application development projects that need to develop complex business
solutions within tight timeframes
• time is fixed for the life of a project, and resources are fixed as far as possible
Nine overriding principles
1. Active user involvement is imperative.
2. The team must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance of deliverables.
5. Iterative and incremental development is necessary to converge on an accurate business
solution.
6. All changes during development are reversible.
7. Requirements are base lined at a high level.

8
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

8. Testing is integrated throughout the life cycle.

9. Collaboration and cooperation between all stakeholders is essential.
Ambassador Users
• they have an ambassadorial role between the project team and the actual end users
• promote two-way communication and compromise between the end user community and
the project development team
• Facilitated Workshops - cannot provide the sort of direct and rapid feedback at the
early iteration of the tool can produce
DSDM lifecycle
• Seven different phases : Pre-Project Phase, Feasibility Study, Business Case Study, the
Functional Model Iteration (FMI), the Design and Build Iteration (DBI), the Implementation
Phase and the Post-Project Phase

Fig. 3. DSDM lifecycle

• The first three phases (namely, the Pre-Project, Feasibility and Business Studies phases)
are done sequentially in order - provides ground rules
• The Feasibility Study phase outputs feasibility report to assesses whether or not to use
DSDM for the project
• The Business Study phase of the project should have three outputs; the Business Area
Definition (BAD), the System Architecture Definition (SAD) and the Outline Prototyping
plan
Business Area Definition. Identifies the high-level requirements and provides
a process description of the end product.
System Architecture Definition. Sketches out the architecture of end system.

9
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Outline Prototyping Plan. This states the prototyping strategy to be adopted

for the development of the end product.
• Core phases of the DSDM are the FMI, the DBI and the Implementation Phase.
Functional Model Iteration (FMI) Phase

• Analysis of the features to be designed and implemented.

• The production of the Functional Model - This is the primary output of this
phase. It may include prototype code as well as analysis models.
• Coding and prototyping – Prototypes may be used to help improve the analysis
or understanding of the system.
Design and Build Iteration (DBI) Phase
• Designing and Building the features to be implemented
• This involves reviewing the designs produced so far, the functional prototypes, as well
as the creation of code to implement the required functionality.
• The primary output of this state is the tested system. This system must meet all the
requirements selected as essential in the particular iteration being implemented.
Implementation Phase
• The transfer of the completed system from the development environment to the
production environment
• The provision of other deliverables such as User training, the creation of the User Manual
and the Project Review Report
• The core three phases, the FMI, the DBI and the Implementation Phase are expected to
be iterative and incremental.

• After the project has delivered the end product, the project team can be disbanded and
the Post-Project activities initiated.
• This phase may cover such diverse activities as providing a help desk for users to ensure
that the product operates effectively and checking that the expected business benefits
have been achieved.
• DSDM refines the concept of timeboxing by nesting shorter timeboxes of 2–6 weeks
within the overall time frame.
• Each timebox will typically pass through three phases.
o Investigation – a quick pass to see whether the team is taking the right direction.
o Refinement – to build on the comments resulting from the review at the end of
investigation.
o Consolidation – the final part of the timebox to tie up any loose ends.

10
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

SCRUM
• SCRUM aims to manage and control the production of software using iterative,
incremental and lightweight processes
Benefits
1. The management and control of development work in an agile manner
2. It explicitly acknowledges that requirements may be changing rapidly within its iterative
and incremental approach to product development
3. It can still use existing engineering practices within SCRUM
4. team-based approach and helps to improve communications and co-operation
5. scales from small projects up to very large projects
6. helps to identify and then remove any obstacle to the smooth development of the end
product

• SCRUM is a set of rules, procedures, and practices that are all interrelated and that
work together to improve the development environment, reduce organisational
overheads and ensure that iterative deliverables match the end users requirements.

Fig.4. SCRUM

Feature-Driven Development
Feature-Driven Development
• potential for managing an agile project
• for handling the uncertainties that an agile approach introduces

11
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

• for getting to grips with monitoring and reporting on the project

• A feature is a schedulable requirement associated with the activity used to realise it
• These requirements may be user related requirements (i.e., be able to open a bank
account), application behaviour requirements (make a backup every 10 min) or internal
requirements (provide the ability to turn on debugging for system support).
Features should have the following attributes
1. Features should be small and useful in the eyes of system stakeholders.
2. Features can be grouped into business-related groupings (called variously feature sets or
work packages).
3. Features focus developers on producing elements within the system that are of tangible
benefits to system stakeholders.
4. Features are prioritised.
5. Features are schedulable.
6. Features have an associated (estimated) cost.
7. Can be grouped together into short iterations (possibly as short as two weeks)
A five-step process that outlines how a feature-centric approach works, these five processes
are
Process 1: Develop an overall model of the domain and create an initial feature list.
First identify a prioritised feature list. This can be done by considering the systems’
requirements. These can be produced in whatever manner is appropriate.
Process 2: Build a detailed, prioritised feature list.
Process 3: Plan by feature.
Process 4: Design by feature.
Process 5: Build by feature.
In the diagram below, the flow illustrates the following steps:
1. First identify a prioritised feature list. This can be done by considering the systems’
requirements. For example, through use cases, a formal requirements specification or user
stories. What is required is that they are elaborated sufficiently to allow prioritisation and an
initial cost estimate to be associated with them.
2. This initial feature list is then used to create a plan of the iterations to be undertaken. Each
iteration should have one or more features associated with it and should not be too long. Each
iteration should have a timebox associated with it that specifies when it starts and when it
finishes.
3. Before each iteration starts, the iteration should be planned in detail. This involves determining
which features are still relevant for that iteration, any revised priorities and an ordering to the
features.

12
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

4. Once an iteration starts, each iteration is addressed in turn based on their priorities. At any
one time, one or more features will be worked on depending on the size of the feature and the
resources available.
5. The iteration stops when the timebox finishes. At the end of the iteration, the current version
of the software is tested to ensure it does what it should.
6. If this is the final iteration, then the final version of the system is delivered (if it is not the final
iteration, then the current system may still be delivered to end users for early and frequent
feedback).
Thus, being feature-centric allows control to be regained over the agile development process
as: features combine requirements with planning, timeboxes provide a structure to the plan and
define how much time is available to implement the features, each iteration identified the
features to be implemented based on the timebox and the current set of features and their
priorities.

Fig.5. Iterative feature based lifecycle

13
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Test-driven development (TDD)

• Test-driven development (TDD), also called test-driven design, is a method of implementing
software programming that interlaces unit testing, programming and refactoring on source
code.
• Test-driven development was introduced as part of a larger software design paradigm
known as Extreme Programming (XP), which is part of the Agile software development
methodology.
Steps for Test-driven development approach
• Before any new code is written, the programmer must first create a failing unit test. Then,
the programmer or pair, or mob creates just enough code to satisfy that requirement.
• Once the test is passing, the programmer may refactor the design, making improvements
without changing the behavior.
• While TDD focuses on the programmer interactions at the unit level, there are other popular
methods, such as acceptance-test-driven development (ATDD) or behavior-driven
development (BDD), which focus on tests that can be understood by customers.
• These methods involve creating concrete examples as tests in collaboration between the
technical staff and customer before the code is created, and then running the tests after the
code is created to demonstrate the code is implemented.
• Having the tests known upfront improves first-time quality. ATDD and BDD require
developers, testers and the business side to collaborate to imagine and discuss the software
and its implications before the code is created.
Advantages of TDD
• Test-driven development can produce applications of high quality in less time than is possible
with older methods. Proper implementation of TDD requires the developers and testers to
accurately anticipate how the application and its features will be used in the real world.
• TDD creates a regression-test suite as a side effect that can minimize human manual testing,
while finding problems earlier, leading to quicker fixes.
• The methodical nature of TDD ensures much higher coverage and first-time quality than
classic phased code > test > fix > retest cycles. Because tests are conducted from the very
beginning of the design cycle, time and money spent in debugging at later stages is
minimized.
Disadvantages of TDD
• TDD requires considerable skill to be successful, especially at the unit level. Many legacy
systems are simply not created with unit testing in mind, making isolation of components in
order to test impossible.
• Further, many programmers lack the skills to isolate and create clean code. Everyone on the
team needs to create and maintain the unit tests, or else they will quickly get out of date.
And an organization looking at TDD will need to invest time -- to slow down a bit now in
order to go faster later.
• Finally, as with any method, the final results of TDD are only as good as the tests that have
been used, the thoroughness with which they have been done and the extent to which they
mimic conditions encountered by users of the final product

14
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

Modelling Misconceptions
Models equal documentation
• A model is part of the documentation, but it is by no means sufficient as documentation.
• That is, a (UML) model, as good as it may be, cannot adequately represent all the
information needed to describe how the requirements (functional and nonfunctional),
behavioral and structural of a software system are to be implemented.
Modelling implies a heavyweight software process
• Again this is not true. The fact that you are using some form of modelling to describe your
system does not mean that you must be using a formal software development process.
• It may well be that placing the modelling task within the context of a development
methodology may well help, but modelling does not equate to a software process.
You must “freeze” the requirements
• The point here is that many people believe that you must be able to freeze the requirements
before you start to model. In theory this would be great. If you had all the requirements
presented to you before you start modelling, then all the questions about what the system
should do would be answered at the start.
• It would also make deciding on what should be in the model easier. However, that is
theoretical, in reality requirements change (even in the smallest projects). This can be for a
variety of reasons.
Your design is carved in stone
• This is a leftover from the more traditional waterfall-based approaches to software
development. In an ideal world, you would like to remove as many unknowns and variable
elements from software development as possible.
• Therefore, to have the design “fixed” and never changing would be great. Again this does
not work in reality. This is for a variety of reasons, including changing requirements, but also
the fact that designs are an abstraction of the implementation. This means that as an
implementation is progressing some elements of the design may be found to be
unimplementable, inefficient or fatally flawed.
• Thus, during the implementation some changes may be required to the design to ensure a
working system, etc. In addition, there may be some situations in which it is difficult to define
more than a highly abstract model, as not enough is known at that point about how the
system should work.
• Thus, the model will need refinement at a later date when some missing information or
understanding becomes available. You may be thinking that you should not move on from
the modelling phase until you have this information, but in the real world there are times
when you don’t have a choice.
You must use a CASE tool

• This means that if you are going to do some modelling you must use some form of
Computer Aided Software Engineering tool such as Together Soft's Together Control
Centre or Rational’s Rose.
• Of course, these tools may well make things easier, but they are not mandatory.

15
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

All developers know how to model:

• Generating appropriate, correct, well-formed, understandable models is not trivial. It
takes time to get familiar with whatever tools, notation and approaches are being
used.
• Just as with programming itself, the more modelling you do, the better you get. In
addition, the more you study the models generated by yourself or your colleagues, the
more you will learn.
• Thus, just taking a developer and asking him/her to start creating a sound robust
model of sufficient clarity and abstraction is generally a flawed approach.
You can think of everything from the start:
• One problem with UML style models is that they are static – that is, you cannot execute
them. So, it is hard to determine whether they cover “enough” or whether you have missed
out some critical areas.
• Therefore, believing that you can think of everything and cover all eventualities at the
start of modelling is wrong for all but the simplest systems.
Modelling is a waste of time.
• This myth represents the extreme opposite of that promoted by the waterfall boys – that is,
designing models has no benefit, just get on with the coding – that’s what you are delivering
after all.
The world revolves around the data model.
• The data model describing, for example, the information in the database, is the centre of
the universe and the object-oriented model is based on this. This is a view that is prevalent
in organisations with a very strong database culture or in those that have migrated from a
more data-oriented language.
• It is also not true that either is less important than the other. Almost every commercial system
that worked on had a database at its heart. Therefore, the data model used with the
database is very important.
• However, the database was only one part of these systems and the other parts were just as
important.
Tool Misconceptions
• Considering some misconceptions and myths relating to the use of tools, modelling and
UML.
UML requires CASE tools
• This is certainly not true – I can draw a UML diagram freehand on paper, use a simple
drawing package such as Paint or indeed with a tool such as Together.
• It may well be true that to strictly adhere to the UML notation it is easier to use something
that knows about UML (and Visio might be such a tool).
• It may also be true that if you want to generate code from the UML diagrams, using a CASE
tool such as Rose or Together makes life easier. But it is not a pre-requisite.
Modelling requires the use of CASE tools
16
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

• An extension of the last point is that if you are going to create models as part of your design
you need a CASE tool that can manage, manipulate, cross reference, etc., your models.
• While these features may well be useful, they are not necessary. I can (and indeed have)
used simpler tools such as Visio to perform all the modelling necessary for the design of a
system. Obviously, the larger the system and the larger the amount of modelling performed,
the better a CASE tool may be.
Agile modellers don’t use CASE tools
• This is a common misconception by those starting with Agile Modelling. This is partly due to
the emphasis of Agile Modelling on using the simplest appropriate tool and if that tool is a
white board or a piece of paper, use it.
• The key word here is appropriate. If I need to work something through with one of my
colleagues, we might well use a white board or a piece of paper and not worry too much
about the accuracy of the UML notation being used.
• If however, I am trying to describe a complex structure that will need to be referenced by
a variety of developers, possibly in multiple locations, then a CASE tool might well be the
most appropriate.
UML is all you need!
• Some take the view that UML is all you need in terms of notation – if you can’t do it in UML
(aka the design tool you are using), then it is either not relevant to an object-oriented system
or not important enough to document.
• This is not true. There are many aspects of a software project that you may wish to document,
but do not fit within the remit of a UML diagram, for example, GUI storyboarding, data
modelling, etc.
The CASE tool is master
• This is more a perception than a misconception. It is a perception because users often feel
that they are battling with the CASE tool and that they have to work in the way prescribed
by the CASE tool.
• The important thing is that the CASE tool should not be the master but the servant. It should
help you with your work and not hinder it.
• Thus, finding an appropriate tool (or tools) is important. For example, in one case Together
proved to be particularly well suited to the organisations way of working and to the
developers experience and background.
Updating Agile Models
Update Only When It Hurts
• You should update a model only when you absolutely need to, when not having the model
updated is more painful than the effort of updating it.
• With this approach you discover that you update a smaller number of models than you
would have in the past because the reality is that your models don't have to be perfect to
provide value.
• Example: The street map that I have to my town is over five years old, I know this because
my own street doesn't appear on it and it's been in place for a little over five years, yet

17
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-1

the map is still useful to me. Yes, I could purchase an updated map, one comes out every
year, but why bother? Missing a few streets isn't painful enough to warrant this investment,
it simply doesn't make sense to spend the money to purchase a new map every year when
the one that I have is good enough. Too much time and money is wasted trying to keep
models and documents in sync with source code, an impossible task to begin with, time and
money that could be better spent developing new software. This practice is particularly
important for agile documentation.

18