Extreme Programming (XP)
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
computer science crazy
Super Moderator

Posts: 3,048
Joined: Dec 2008
24-02-2009, 01:01 AM

Extreme Programming (or XP) is a software engineering methodology (and a form of agile software development) prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below). Proponents believe that exercising these practices”traditional software engineering practices taken to so-called "extreme" levels”leads to a development process that is more responsive to customer needs ("agile") than traditional methods, while creating software of better quality. Proponents of Extreme programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development project and implimentations; they believe that adaptability to changing requirements at any point during the project and implimentation life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and implimentation and then expending effort to control changes to the requirements. However, XP has been noted for several potential drawbacks, as compared to more document-based methodologies, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document (see below: Controversial aspects).
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
electronics seminars
Active In SP

Posts: 694
Joined: Nov 2009
16-12-2009, 07:13 PM

.doc   Extreme Programming-XP-report.DOC (Size: 127.5 KB / Downloads: 54)

Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. About six years old, it has already been proven at many companies of all different sizes and industries worldwide. XP is successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customer needs when it is needed. XP empowers software developers to confidently respond to changing customer requirements, even late in the life cycle. This methodology also emphasizes teamwork. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.

XP improves a software project and implimentation in four essential ways; communication, simplicity feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology. XP is different. It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. This is a significant departure from traditional software development methods and ushers in a change in the way we program.

If one or two developers have become bottlenecks because they own the core classes in the system and must make all the changes, then try collective code ownership. You will also need unit tests. Let everyone make changes to the core classes whenever they need to. You could continue this way until no problems are left. Then just add the remaining practices as you can. The first practice you add will seem easy. You are solving a large problem with a little extra effort. The second might seem easy too. But at some point between having a few XP rules and all of the XP rules it will take some persistence to make it work. Your problems will have been solved and your project and implimentation is under control. It might seem good to abandon the new methodology and go back to what is familiar and comfortable, but continuing does pay off in the end. Your development team will become much more efficient than you thought possible. At some point you will find that the XP rules no longer seem like rules at all. There is a synergy between the rules that is hard to understand until you have been fully immersed. This up hill climb is especially true with pair programming, but the pay off of this technique is very large. Also, unit tests will take time to collect, but unit tests are the foundation for many of the other XP practices so the pay off is very great.

XP project and implimentations are not quiet; there always seems to be someone talking about problems and solutions. People move about, asking each other questions and trading partners for programming. People spontaneously meet to solve tough problems, and then disperse again. Encourage this interaction, provide a meeting area and set up workspaces such that two people can easily work together. The entire work area should be open space to encourage team communication. The most obvious way to start extreme programming (XP) is with a new project and implimentation. Start out collecting user stories and conducting spike solutions for things that seem risky. Spend only a few weeks doing this. Then schedule a release planning meeting. Invite customers, developers, and managers to create a schedule that everyone agrees on. Begin your iterative development with an iteration planning meeting. Now you're started.

Usually project and implimentations come looking for a new methodology like XP only after the project and implimentation is in trouble. In this case the best way to start XP is to take a good long look at your current software methodology and figure out what is slowing you down. Add XP to this problem first. For example, if you find that 25% of the way through your development process your requirements specification becomes completely useless, then get together with your customers and write user stories instead.

If you are having a chronic problem with changing requirements causing you to frequently recreate your schedule, then try a simpler and easier release planning meeting every few iterations. (You will need user stories first though.) Try an iterative style of development and the just in time style of planning of programming tasks. If your biggest problem is the number of bugs in production, then try automated acceptance tests. Use this test suite for regression and validation testing. If your biggest problem is integration bugs then try automated unit tests. Require all unit tests to pass (100%) before any new code is released into the code repository.


Extreme programming implements several software development practices. But not all of them are exclusive to XP. These practices work well and contribute significantly to the project and implimentationâ„¢s overall success. There are 12 practices in XP.

1. Planning Game
2. Small releases
3. Metaphor
4. Simple design
5. Test Driven Development
6. Refactoring
7. Pair programming
8. Collective ownership
9. Continuous development
10. Sustainable pace
11. On-site customer
12. Coding standards


User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customersâ„¢ terminology without techno-syntax.

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the Developers estimate how long the stories might take to implement. Each story will get a 1, 2 or 3-week estimate in "ideal development time". This ideal development time is how long it would take to implement the story in code if there were no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.

Another difference between stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology, data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed to specifying GUI layouts.


Acceptance tests are created from user stories. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.

Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.

A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created each iteration or the development team will report zero progress. Quality assurance (QA) is an essential part of the XP process. On some project and implimentations QA is done by a separate group, while on others QA will be integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.

Acceptance tests should be automated so they can be run often. The acceptance test score is published to the team. It is the team's responsibility to schedule time to each iteration to fix any failed tests. The name acceptance test was changed from functional tests. This better reflects the intent, which is to guarantee that customerâ„¢s requirements have been met and the system is acceptable.
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
seminar paper
Active In SP

Posts: 6,455
Joined: Feb 2012
14-03-2012, 11:57 AM

to get information about the topic "extreme programming" full report ppt and related topic refer the link bellow



topicideashow-to-extreme-programming-seminar and presentation-report?pid=74160#pid74160


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  CGI PROGRAMMING LABORATORY seminar ideas 1 597 08-10-2014, 08:16 AM
Last Post: OtlBY
  Object Oriented Programming with Java seminar paper 2 1,079 18-09-2014, 03:24 PM
Last Post: Radhika.m
  Fundamental Programming Structures in C pdf seminar projects maker 0 396 26-09-2013, 12:36 PM
Last Post: seminar projects maker
  DATA STRUCTURES USED IN NETWORK PROGRAMMING seminar projects maker 0 572 25-09-2013, 04:27 PM
Last Post: seminar projects maker
  Programming Language Theory ICS313 seminar projects maker 0 321 24-09-2013, 02:03 PM
Last Post: seminar projects maker
  Tutorial On Introduction to 8085 Architecture and Programming seminar projects maker 0 390 20-09-2013, 03:52 PM
Last Post: seminar projects maker
  UNIX SYSTEM PROGRAMMING pdf seminar projects maker 0 422 11-09-2013, 03:42 PM
Last Post: seminar projects maker
  Introduction to Microsoft Kinect Sensor Programming PPT study tips 0 412 10-09-2013, 12:02 PM
Last Post: study tips
  Socket Programming - UDP study tips 0 299 20-07-2013, 01:04 PM
Last Post: study tips
  Object-Oriented Programming with Java Report study tips 0 395 02-07-2013, 01:09 PM
Last Post: study tips