T.S.RAMYA KRISHNA* et al.

[IJESAT] INTERNATIONAL JOURNAL OF ENGINEERING SCIENCE & ADVANCED TECHNOLOGY

ISSN: 22503676
Volume - 2, Special Issue - 1, 76 80

SOFTWARE QUALITY ASSURANCE IN EXTREME PROGRAMMING

T.S.Ramya Krishna1, R. Nagendra Babu2, Ch.Phani Kanth3, Ch.V.Phani Krishna4
M.tech, CSE , K L University, Andhra Pradesh, India,ramyakrishna.cse@gmail.com. 2 M.tech, CSE , K L University, Andhra Pradesh, India, nrajaboina@yahoo.com. 3 M.tech, CSE , K L University, Andhra Pradesh, India ,phanikanth.ch@gmail.com 4 Associate Professor, CSE , K L University, Andhra Pradesh, India ,phanik16@yahoo.co.in.
1

Abstract
Software quality is one of our most important software concerns. Agile methods may produce software faster but we also need to know how they meet our quality requirements. And in this paper we give a brief introduction about the software quality and quality assurance techniques and also about extreme programming and its practices, and also about software quality in extreme programming.

Index Terms: Software quality, software quality assurance, extreme programming, xp, waterfall model. ---------------------------------------------------------------------- *** ----------------------------------------------------------------------1. INTRODUCTION
Since the late 60s, different software development methods (such as waterfall model, evolutionary development method, spiral development model etc.) have been developed and widely used by the software engineering community. Over the years, the developers and users of these methods have invested significant amounts of time and energy to improve and refine them. Owning to continuous improvement efforts and being practiced for such a long time, most of the above mentioned methods have become quite mature and stable level. That is why they are usually referred as traditional software development methods .Each of the traditional development methods attempts to address quite different development issues and implementation conditions. Among the traditional development approaches, the waterfall model is the oldest the software development process model. (Royce 1970). Waterfall model has been widely used in both large and small software intensive projects. It has been reported as a successful development approach especially for large and complex engineering projects. The waterfall model divides the software development life cycle into five distinct and linear stages. Because the waterfall model is the oldest and the most mature software development model we have chosen it to investigate its QA process. Despite the success of Waterfall model with large and complex systems, it has number drawbacks, like linearity, inflexibility in the face of changing requirements, highly ceremonious processes irrespective of the nature and size of the project etc. Such drawbacks can also be found in other traditional development approaches. However, agile methods were developed to address a number of the drawbacks inherent in the Waterfall model. Agile methods deal with unstable and volatile requirements by using a number of techniques of which most notable are: 1) simple planning, 2) short iteration, 3) earlier release, and 4) frequent customer feedback. These characteristics enable agile methods to deliver product releases in a much short period of time compared to the waterfall approach.

2. QUALITY ASSURANCE TECHNIQUES

Since we are concerned with the quality of the software produced with both the Waterfall model and the agile approach, we investigate quality-centric supporting processes in software development. We concentrate on two of the most widely used general quality-focused processes, Software Quality Assurance (SQA) and Verification and Validation (V&V) to examine software product quality. SQA governs the procedures meant to build the desired quality into the products and V&V is aimed more directly at product quality including intermediate products. These two supporting processes are normally used to support the waterfall model in order to provide a full complete process model. Quality assurance techniques can be categorized into two types, static and dynamic. Static and dynamic techniques are both used in SQA processes. The selection, objectives, and organization of a particular technique depend on the

requirements and nature of the project. A Waterfall

IJESAT | Jan-Feb 2012

Available online @ http://www.ijesat.org 76

T.S.RAMYA KRISHNA* et al. [IJESAT] INTERNATIONAL JOURNAL OF ENGINEERING SCIENCE & ADVANCED TECHNOLOGY

ISSN: 22503676
Volume - 2, Special Issue - 1, 76 80

development method selects these techniques

according to very different criteria, such as some peopleintensive techniques chosen in waterfall model. Unlike dynamic techniques, Static techniques do not involve the execution of code. Static techniques involve examination of documentation by individuals or groups, this examination maybe be assisted by software tools, for example, inspection of the requirements specification and technical reviews of the code. Testing and simulation are dynamic techniques. Sometimes static techniques are used to support dynamic techniques and vice versa. The waterfall model uses both static and dynamic techniques. However, agile methods mostly use dynamic techniques.

Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. Small releases Put a simple system into production quickly, then release new versions on a very short cycle. Metaphor Guide all development with a simple shared story of how the whole system works. Simple design The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered. Testing Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating the features are finished. Refactoring Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. Pair programming All production code is written with two programmers at one machine. Collective ownership Anyone can change any code anywhere in the system at any time. Continuous integration Integrate and build the system many times a day, every time a task is completed. 40-hour week Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.

3. EXTREME PROGRAMMING
Extreme Programming (XP) is a methodology for building software based on longstanding industry best practices. These practices include evolutionary prototyping, short release cycles, and active end-user involvement in requirements definition and acceptance testing. XP is based on the work of Kent Beck, Ward Cunningham, Ron Jeffries and others, and was used initially in 1996 at the Chrysler Corp. (now DaimlerChrysler) for a project to re-engineer their compensation system. The specific practices were chosen based on the belief that they are mutually supportive.

Four Variables of Project Management

Variable Scope Time Cost Quality

Traditional Projects Fixed Fixed Fixed Variable

XP Projects Variable Fixed Fixed Fixed

3.1 The Practices

XP's practices embody the values described in the previous sections. In his book Extreme Programming Explained Kent Beck defines the 12 practices as follows (quoted verbatim): The Planning Game

On-site customer Include a real, live user on the team, available fulltime to answer questions.

Coding standards Programmers write all code in accordance with rules emphasizing communication through the code.

IJESAT | Jan-Feb 2012

Available online @ http://www.ijesat.org 77

T.S.RAMYA KRISHNA* et al. [IJESAT] INTERNATIONAL JOURNAL OF ENGINEERING SCIENCE & ADVANCED TECHNOLOGY

ISSN: 22503676
Volume - 2, Special Issue - 1, 76 80

3.2 XP Values
The XP life cycle has four basic activities: Coding, testing, listening, and designing. Dynamism is demonstrated through four values: continual communication with the customer and within the team;

only a small slice of new functionality to be tested, and any problems discovered will be focused in the new functionality. Testing in small increments such as this also helps to identify any issues with regards to the system actually delivering the functionality that the Customer needs, as opposed to what was specified. In XP, there must be at least one Acceptance Test for each Story. Typically, there will be a test for each scenario within a Story.

simplicity, achieved by a constant focus on minimalist solutions;

rapid feedback through mechanisms such as unit and functional testing; and The courage to deal with problems proactively.

4.2.2 Unit Testing

Although Unit Testing has always been espoused as important, XP follows its name and takes Unit Testing to the extreme. Unit tests are written by the Programmers, and are automated such that they can provide immediate feedback. These frameworks allow the creation of hierarchical test suites that grow over time as a system is developed. Pressing a single button can run all of the Unit Tests for a system, and the results displayed as the tests are run. These test suites support the practice of Refactoring by allowing the Programmers to confidently make changes to the implementation of the code and quickly determining the changes caused any regressions. Under XP, no code is ever delivered to production unless all of its Unit Tests are passing.

EXTREME PROGRAMMING AND SOFTWARE QUALITY

There are a number of aspects of XP that have a direct impact on quality:

4.1 The On-site Customer

Extreme Programming doesnt just advocate a close relationship with the Customer, it insists upon as much face to face contact with that Customer as possible. Indeed, the Customer is involved on a constant basis. This provides feedback to both the Programmers and Customer very quickly, and effectively communicates what is going right and what is going wrong. If there are problems, steps can then be taken immediately to resolve them. Similarly, if things are going well and the Programmers are ahead of schedule, the Customer can then add more stories to iteration.

4.2.3 Test-Driven Development

One of the most unique aspects of XP is the concept of TestDriven Development (TDD). Typically, a Programmer will write code, then writes tests after the fact to determine if the code works as advertised. Under TDD, a test is written first, and then the code is written to make the test pass. While this may seem counterintuitive, it forces the Programmer to determine the intent of the code up-front, which is expressed in the unit test the code ends up being simpler, since it is being written solely for the purpose to make the test pass, and the code grows organically, i.e. only as needed. TDD also ensures that the unit tests are indeed written, which isnt always the case with traditional methodologies. Test-Driven Development is an example of the high level of discipline that is required to properly use Extreme Programming. It is not an easy practice to use, but once mastered it results in a dramatic increase in code quality.

4.2 Focus on Testing

The image that the name Extreme Programming invokes is generally not one of rigorous, disciplined development. However, few other methodologies make testing as high a priority as XP.

4.2.1 Acceptance Testing

Acceptance or Functional Testing is traditionally performed at the end of a development cycle, just prior to releasing a system into production. This typically results in a mad rush to fix any problems, which often introduces even more bugs. In XP, Acceptance Testing is performed as often as possible, ideally as soon as a Story has been implemented. Normally, though, Acceptance Testing is performed at the end of Iteration. Since Iteration is only 1-2 weeks in length, there is

4.2.4 Pair Programming

Code reviews have long been considered a good practice for improving software quality. Again, XP takes the practice to the extreme in the use of Pair Programming.

IJESAT | Jan-Feb 2012

Available online @ http://www.ijesat.org 78

T.S.RAMYA KRISHNA* et al. [IJESAT] INTERNATIONAL JOURNAL OF ENGINEERING SCIENCE & ADVANCED TECHNOLOGY Pair Programming isnt simply one person typing while the other is day-dreaming, but rather both people are fully engaged in the development process. The person on the keyboard is typically thinking tactically, i.e. working within the current method or function. The person not typing is thinking strategically, i.e. within the current class or even at a higher level looking for opportunities for Refactoring or reuse. Additionally, both are actively ensuring that coding standards are followed, and unit tests are written and are passing.

ISSN: 22503676
Volume - 2, Special Issue - 1, 76 80

ACKNOWLEDGEMENT
We like to express our gratitude to all those who gave us the possibility to carry out the paper. We would like to thank Mr.K.Satyanarayana, chancellor of K L University, Dr.K.Raja Sekhara Rao, Dean, and K L University for stimulating suggestions and encouragement. We have further more to thank Prof.S.Venkateswarlu, Dr.K.Subrahmanyam, and Dr.CH.V.Phani Krishna, who encouraged us to go ahead with this paper.

4.3 Iterative Development

Iterative development is an extension of Barry Boehms Spiral Model (Boehm88). It provides benefits such as the identification of risks early in development. Compared to the traditional waterfall process, iterative development provides the following benefits: Serious misunderstandings are made evident early in the lifecycle, when it's possible to react to them. It enables and encourages user feedback, so as to elicit the system's real requirements. The development team is forced to focus on those issues that are most critical to the project, and team members are shielded from those issues that distract them from the project's real risks. Continuous, iterative testing enables an objective assessment of the project's status. Inconsistencies among requirements, designs, and implementations are detected early. The workload of the team, especially the testing team, is spread out more evenly throughout the lifecycle. This approach enables the team to leverage lessons learned, and therefore to continuously improve the process. Stakeholders in the project can be given concrete evidence of the project's status throughout the lifecycle.

REFERENCE
1. K. Beck, extreme programming eXplained : embrace change. Reading, MA: Addison-Wesley, 2000. 2. James NewKirk, Introduction to Agile Processes and Extreme Programming, ICSE 02, IEEE 2002. 3. B. Pettichord, Agile Testing Challenges, Proc. Pacific Northwest Software Quality Conf., 2004; www.io.com/ ~wazmo/papers/agile_testing_challenges.pdf. 4. L. Crispin, Extreme Rules of the Road: How an XP Tester Can Steer the Project toward Success, STQE/Better Software Magazine, July/Aug. 2001, pp. 2429; www.testing.com/agile/crispin-xp-article.pdf. 5. R. Turner. Agile Development: Good Process or Bad Attitude? In PROFES, pages 134144,2002. 6. M. C. Paulk. Using the Software CMM With Good Judgment. ASQ Software Quality Professional, 1(3), 1999. 7. D. Kane and S. Ornburn. Agile Development: Weed or Wildflower? CrossTalk: The Journal on Defense Software Engineering, 2002. 8. J. D. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. C. Paulk. Software Quality and the Capability Maturity Model. Commun. ACM, 40(6):3040, 1997. 9. Sven Heiberg, ,Methods for Improving Software Quality:a Case Study, Masters Thesis, University of Tartu,2002. 10. Pressman, Roger S.,Product Metrics Engineering, McGraw Hill;6/e, 2005. for Software

5. CONCLUSION
Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the Presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

IJESAT | Jan-Feb 2012

Available online @ http://www.ijesat.org 79

T.S.RAMYA KRISHNA* et al. [IJESAT] INTERNATIONAL JOURNAL OF ENGINEERING SCIENCE & ADVANCED TECHNOLOGY

ISSN: 22503676
Volume - 2, Special Issue - 1, 76 80

BIOGRAPHIES
T.S.Ramyakrishna, She received her B.Tech degree in computer science and engineering in Nagarjuna University and M.tech in K L University.

Nagendra Babu Rajaboina ,he received her B.Tech degree in Information Technology in AndhraUniversity and M.tech in K L University

CH.Phani Kanth, He received his B.E degree in computer science and engineering in University of Madras and M.Tech degree in K L University. And having work experience of 3 years as software engineer.

CH.V.Phani Krishna, He is an Associate.professor in computer science and engineering in K L University.He is a life member in CSI & ISTE and having 10 years of experience in engineering discipline. His interests as a researcher in Software Engineering, and covers a varirty of overlapping areas.

IJESAT | Jan-Feb 2012

Available online @ http://www.ijesat.org 80