1. Agile Software Development based on
3 layered filtering
Arash Heidarian
Multimedia Media University of Malaysia
arash2001h@yahoo.com
Abstract – Recently the major concern for software developers
and software enterprises is a rapid changing in criteria and
developing systems based on a dynamic platform .In order to
cope with this problem, many agile methodologies and
techniques are developed and proposed. This paper provides a
new idea referred to as the “3 layered filtering” .This idea helps
developers and enterprisers to make changes in short time and at
a low cost using existing Agile methodologies. Thus the first layer
classifies the requirements, the second layer identifies the
architecture layer that is going to be affected by new
requirements and third layer selects the appropriate Agile
methodology taking the information obtained from the last 2
layers in consideration. Each layered is in iteration in regard to
the new emerging requirement and tightly related to its next
Layer. In fact this is a modified and layer-based agile
methodology which facilitates taking proper action when a new
requirement is imposed; focusing on time and cost issue.
Therefore ,using “3 layered filtering”, developers and managers
may have this ability to abstract and distinguish different issues,
related to new requirements whereby less time and money will be
spent and proper human resource will be assigned to each
modification process.
Key words: 3 layered filtering, Agile methodology, Software
Architecture Layers, Iterative updates, Requirement
Classification
I. Introduction:
One of the main concerns in developing and producing
Software are diverse requirements from different prospective
of different users. Explicitly, there are 2 groups of
requirements, affect on design and architecture of
Software .First group of requirements are those which are
gathered before starting the design and development phases.
Second group of requirements are those which are gathered
after Design, Development and delivery phases. Basically, the
proper design and development based on elicited
requirements ,is the key to produce a Software which can
come into market and attract customers .But what keeps
customers satisfied and guarantees the survive of the software
among other softwares in market ,is to imply the second group
of requirements continuously
Into the product in order to keep it up to date, that is what this
paper addresses to. Before accomplishing this task, there are
Several questions around which brings some complexity in
implying changes such as who has proposed this change ?
Why the change is required and what is trigger? Which layer
of software is targeted? Which methodology can be helpful to
imply the change? Imply the change or leave it? Who is/are
required in order to imply this change? (Human Resource
Management). This paper tries to propose a simple way to
cope with this complexity due to mentioned questions and
ambiguous points.
II. Filtering Concept
In software Architecture, Abstraction always is a key to have
classified, controllable, modifiable and maintainable system.
Here the proposed method which is called “Filtering Method”,
helps us to classify the “Requirements for changes” and
abstract the Architecture Layers which are going to be
affected under the different classes of requirements. Finally,
the proper agile methodology is chosen in order to imply the
change. In order to accomplish this task, 3 filters are proposed
here which are tightly interrelated to each other. Figure 1
illustrates all filters and their phases in detail.
Figure 1 . Agile Software Development based on “3 layered filtering”
These 3 filters are explained in detail in continue.
A. First Filter – Change Reason Filter :
In this layer, all change scenarios are evaluated and triggers
are identified. It helps developers to classify changes into five
categories namely Bug, Error and Failure, DB and Library

2. Related, Interface Related, Functional and structural. So the
evaluation team go through all change scenarios and classifies
changes according to these categories. This classification is a
key to go to the next layer and is a clue to pass through the
second filter.
B. Second Filter – Layers of Change in Software
Architecture:
An architectural description of the layers of Change in
software can be proposed using as examples concepts of
computer and software architecture, Software Patterns and
object oriented programming. However the interpretation of
the Layers of Change for software, given here is an open
concept: it is prone to be changed, adapted or modified to
cope with other software development approaches, paradigms
or techniques which are oriented toward building architecture,
it is tried to produce an equivalent version for software
architecture [1].
There are 4 layers of architecture defined here. The classified
change scenarios help us to know which layers of architecture
will be under the effect of what type of changes. Obviously
“Bugs” and “Error and Failure” category of changes possibly
could be addressed to any Software Architecture Layer that is
why we are not going to mention them in each layer. The
layers as follows :
1. Software Site:
The software site layer objective is to provide a stable base on
which we construct software program. It can be represented
simply by the hardware elements of software architecture. It
Covers Hardware elements and Software Environment on
which software will be developed. A computer is constructed
from basic building blocks such as memory system, Processor
and I/O devices. These are first elements that influence the
design and implementation of software program. The major
differences between computers lie in the way the modules are
connected [1]. Regarding to definition of “Software Site”,
there are some change scenarios which are going to effect on
this layer of architecture. Changes which are in “Failure and
Error “and “Functional and structural” categories, are those
which influence on this layer. It is important to know that
changes to this layer are very costly and are implied so rarely.
There for should be very precise evaluation on implying the
changes to this layer. If the change request is related to
“Failure and Error “ , it is worthy to evaluate it and try to
imply it ,but if the change is in “Functional and structural”
category , on that time the cost and time should be taken into
consideration in order to see that does it have time and cost
justification ? For example if in one of the change scenarios it
is mentioned to change the platform of the system or to use
another design pattern to increase the performance, then all
trade-off points should be evaluated. It may affect the whole
system and requires high effort.
2. Software Structure :
The software structure layer is the description of a software
program as a set of defined subsystems, specifying their
responsibilities, and including rules and guidelines for
organizing the relationships between them. Software structure
is concerned with the issues about partitionening a complex
software system [1]. The partition of the system helps to
reduce the complexity and understand the parts and
subsystems easily and clearly [1]. As it was mentioned before,
the issue of abstraction and partitionening helps developers
significantly to understand, maintain and modify the system.
Software Structure can be defined as architectural patterns .
“An Architectural Pattern expresses a fundamental structural
organization or schema for software systems. It provides a set
of predefined subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the relationships
between them”. (Buschmann et al.1996).
Software Structure Changes vary little or not at all during the
lifetime of a software program. An important factor in
determining the success or failure of software program relies
deeply on choosing an appropriate Software Structure that
properly matches with the requirements and resources [1].
There for, mostly those requirements which collected before
design and development are handy to be applied and implied
in this architectural layer. If we want to address the change
reason category to this layer,”functional and structural
“category is the only one.
3. Software Skin:
Software skin or GUI is an appearance of software and
exhibits its functionalities. In the other words, it is represented
by all elements that allow users to interact with a system. This
layer is a root for most important quality attributes of a system
such as underestandability , Usability and being User
Friendly of the system. From structural point of view, it can
be seen that this layer is tightly related to first layer of
architecture. There are some Design Patterns (Gamma) behind
the GUI which enhances the performance of the system such
as Decorator, Abstract Factory and Bridge Patterns. So
changes located in “Interface Related” and “Functional and
structure” categories could be addressed to this layer.
4. Software Service:
This layer is to provide support for common activities during
the use of a software program. From a programming point of
view Software Services can be found in the form of all
prebuilt standards components that provide common
functionality like mathematical, Input/ Output and disk access.
Often Software Services found in libraries should be
customized by the designer or programmer for a particular
software design [1]. Since Software services addresses to
Libraries and I/O of DB and system, Design Pattern (which
Capture and Organize Reusable pieces to Clearly Define
Dependencies) and Idioms(which shows how to use Software
Service & rules and expectations) also help to use and
development of Software Services. Hence, the “DB and
Library” category of change can be addressed to this layer of
Architecture. Because of the existing issues of Design Pattern
and Idioms in Software Service Layer, “Functional and
structural” category also can be addressed to this layer.
C. Third Filter – Agile Methods:
Agile methodology is disciplined Project Management that
yields the iterative, frequent inspection and adoption, relaying
on teamwork. Agile methodology is exactly what is required
to imply frequent, new changes and requirements. Concept of

3. Agile intensively relies on IID (Incremental and Iterative
Development).
The simple ability to revisit the “phases” of development
dramatically improves project efficiency. The idea of
revisiting phases over and over is called “incremental and
iterative Development” (IID). The development lifecycle is
cut up into increments or “iterations” and each iteration
touches on each of the traditional “phases” of development.
With IID, Requirements are in ongoing processes that are
periodically revisited. IID allows for multiple “passes”, or
iterations, over a project lifecycle to properly address
complexities and risk factors. This concept of iterative
development hails from the “lean development” era of the
1980s where Japanese auto makers made tremendous
efficiency and innovation increases simply by removing the
phased, sequential approach and implementing an iterative
approach, where prototypes were developed for short-term
milestones (see Figure 2). Each phase was actually a layer that
continued throughout the entire development lifecycle; the
requirements, design, and implementation cycle was revisited
for each short-term milestone. [2].
Source : Adapted from H. Takeuchi and I. Nonaka, “The new Product
Development Game”, Harvard Business Rev., Jan. 1986, pp. 137-146
Figure 2. IID
What Agile and IID try to focus on, are Iterative Mechanism,
Design-Code-Test Loop, decrease the Cost of Change and
Increase Quality.
There are two most famous and in use methods of Agile,
called XP and Scrum.
A. XP
Extreme Programming evolved from Large Development
Cycle of Traditional Development Model and is composed of
five phases. Figure 3 shows process of XP life cycle:
source: Pekka Abrahamsson, Outi salo, Jussi Ronkainen & Juhani Warsta – Agile
Software Development methods - Figure 3 . XP Process
These Five phases are explained briefly as follows.
In Exploration Phase Customers Write Story Card. Story cards
contains the information about the change category and
Architectural layers which could be affected due to changes.
Project Team looks for proper tools and technology and test
the Technology and finally they try to find Architecture
Possibilities for the system are explored by building a
prototype of the system. The exploration phase takes between
a few weeks to a few months, depending on the change
scenario and largely of technology.
In planning phase, change scenarios are prioritized according
to their impotencies and complexities. Then the estimation of
effort and scheduling is done for each scenario.
The Iteration to release phase includes several iterations of the
system before the first release. The schedule set in the
planning stage is broken down to a number of iterations that
will each take one to four weeks to implement. The first
iteration creates a system with the architecture of the whole
system [2]. This is achieved by selecting the stories that
contain the requirements which are gathered before design and
development phase. These stories enforce the building the
whole system .Stories in next iteration contains more elicited
requirements and changes which are gathered after the
releasing the first edition (or trial edition). This iteration of
gathering stories, prioritizing stories and send them into the
rest of the processes is continuously and should be done in
whole lifecycle of software.
The Production Phase:
This phase requires extra testing, checking of the performance
and evaluation of trade-off points and sensitive points of
quality attributes .At this phase, new changes might be
founded or proposed by evaluation team or other stakeholders
who are involved in Software production. In this phase, the
decision is made to include the new changes in current release
or not. During this phase, the iterations may take one to three
weeks. The postponed ideas and suggestions are documented
for later implementation, during e.g. the maintenance phase.
The death phase is a phase when there is no any other
requirement or story from customers. We will reach this phase
when the system satisfies all customers’ needs with respect of
performance and reliability. Once the new stories are received
from customers, the whole process will be repeated. That is
what guarantees the life of software.
As it was mentioned earlier there are two famous agile
methods .Figure 4 shows second agile method process
lifecycle which is called Scrum.

4. Source : Pekka Abrahamsson, Outi salo, Jussi Ronkainen & Juhani Warsta – Agile
Software Development methods
Figure 4, Scrum Process
B. The scrum
The Scrum has been developed for managing the system
development process, It is an empirical approach applying the
ideas of industrial process control theory to system
development resulting in an approach that reintroduces the
idea of flexibility, adaptability and productivity (Schwaber
and Beedle 2002 ). The scrum focuses on team member
activity to work in way that makes the system flexible in
constantly changing environment. That is why it involves
several environmental and technical variables (e.g.
requirements, time frame, resources and technology) that are
likely to change during the process. This makes the
development process unpredictable and complex, requiring
flexibility of the systems development process for it to be able
to respond to the changes [2].
As a result of the development process, a system is produced
which is useful when delivered.(Schwaber 1995).
The Scrum is consisted of three phases and in concept it is so
similar to XP method. These three phases are explained
briefly as follows.
In Pregame phase there are two steps. The first step is
planning which is consisted of the following activities: Project
team Definition, produce Backlog list (which contains
requirements and changes and continuously is updated and
reviewed by the Scrum Team), Prioritizing requirements in
Backlog list and needed resources are estimated, identify
Tools and other Resources, Risk Assessment, Training need
and Verification Management. The Second step is
architectural phase. In this phase the high level design of the
system including the architecture is planned based on the
current items in Backlog List.
The Second phase which is called the development phase
(also called the game phase) is the agile part of the Scrum
approach. This phase is related as a “Black Box”where the
unpredictable is expected. The different environmental and
technical variables (such as time frame, quality, requirements,
resources, implementation technologies and tools and even
development methods) identified in scrum, which may change
during the process, are observed and controlled through
various Scrum Practices during the Sprints of the development
phase. Scrum aims at controlling the requirements and matters
constantly in order to be able to flexibly adapt to the changes
[2]. The core of the whole Scrum method is its Sprint. Sprint
is iterative cycle which covers all traditional phase of the
development (requirements, analysis, design, evolution and
delivery phases) in cyclic and iterative way. So each time the
Black log list is updated and it is required to imply new
requirements or changes, the selected scenario of new
requirements is sent into the sprint from the previous phase.
As it can be seen in Figure 4 , the Sprint ,black log list and all
phases are interrelated in cyclic way ,so any change or update
in Black log list ,would evolve the whole process.
The final phase is called Post-game phase which contains the
closure of the release. This phase is met when an agreement
has been made that the environmental variables such as the
requirements are completed.
It was just a brief and short explanation about XP and Scrum
methods. As it is evident, implying changes into software is a
process which requires a time and money.
III. Filters Coherence and the main purpose of Filtering
Model:
So it is very important to know what should be done before
starting any agile methods. That is, two prior filters to Agile
method filter, namely “Change Reason Filter” and “Layers of
Architecture Filter”, helps developers and project managers. It
helps project managers to manage the human resource more
precisely. For instance, if most of the problems are related to
Interface and affects “Software Skin layer”, so there is no
need to call a Database expert and hardware expert. Some
times when a problem appears or when a new change or
requirement appears, managers involve a group of experts of
all fields. So using this Filtering method, it is easy to manage
human resource .On the other hand, when manager is aware of
the details of a requirement, he can make more precise
predictions in scheduling and budgeting.
From technical point of view, it helps developers and
designers to decide to choose a proper Agile method. There
are several concerns related to choosing XP or Scrum. In
general Scrum is a project management process and XP is a
programming practice. From time point of view, Scrum teams
typically work in iterations (called sprints) that are from two
weeks to one month long. XP teams typically work in
iterations that are one or two weeks long. Furthermore Scrum
teams do not allow changes into their sprints. Once the sprint
planning meeting is completed and a commitment made to
deliver a set of product backlog items, that set of items
remains unchanged through the end of the sprint. XP teams
are much more amenable to change within their iterations. As
long as the team hasn’t started work on a particular feature, a
new feature of equivalent size can be swapped into the XP
team’s iteration in exchange for the unstarted feature [3].
IV. Conclusion
This paper provides a new and simple idea in order to cope
with complexity and ambiguity of implying new changes and
requirements during the lifecycle of a software, using Agile

5. Methodology. These three layers in this new idea help
manager and developer to classify the requirements and
change requests into four categories and then easily recognize
that which Architectural layers of Software are affected under
different requirement and change scenarios of different
categories. These two steps mostly help managers to have
more precise prediction about timing, scheduling and human
resource management. The third filter helps both manager and
developer to choose a proper method of Agile to imply
changes based on the obtained information from first two
filters.
References
[1] Jorge Luis Ortega Arjo a a d Graham Roberts :The layers
of chnge in Software Architecture
[2] Pekka Abrahamsson, Outi salo, Jussi Ronkainen & Juhani
Warsta – Agile Software Development, 2002
[3] Mike Cohn – Succeeding with Agile, 2007