Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Full Paper


Published on

  • Be the first to comment

  • Be the first to like this

Full Paper

  1. 1. Agile Software Development based on 3 layered filtering Arash Heidarian Multimedia Media University of Malaysia 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. 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. 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. 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. 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