Important: Use custom search function to get better results from our thousands of pages

Use " " for compulsory search eg:"electronics seminar" , use -" " for filter something eg: "electronics seminar" -"/tag/" (used for exclude results from tag pages)


Tags: extreme programmi, extreme programming conference, extreme programming cookbook, extreme programming case study, extreme programming certification, extreme programming characteristics, extreme programming cons, extreme programming community describing, extreme programming cost, extreme programming chart, extreme programming book, extreme programming benefits, extreme programming best practices, extreme programming beck, extreme programming basics, extreme programming by kent beck, extreme programming background,
 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Extreme Programming (XP)
Post: #1
Thumbs Down 

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 projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project 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).
Post: #2

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

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 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 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 projects 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. 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 projects come looking for a new methodology like XP only after the project 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.















THE XP PRACTICES

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â„¢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

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

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 projects 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.
Post: #3
to get information about the topic "extreme programming" full report ppt and related topic refer the link bellow

https://seminarsprojects.net/Thread-extr...ramming-xp

https://seminarsprojects.net/Thread-extr...4#pid32284

https://seminarsprojects.net/Thread-extr...0#pid74160

https://seminarsprojects.net/Thread-extr...g-xp--1683
 

Marked Categories : xp seminar topic in pdf, xp extreme programming report doc, extreme programming doc, extremeprogramming documentation, extreme programmng,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Image Verification
(case insensitive)
Please enter the text within the image on the left in to the text box below. This process is used to prevent automated posts.

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Programming of IPFC using NR method in MATLAB Guest 1 155 12-10-2017 02:50 PM
Last Post: jaseela123
  Programming of IPFC using NR method in MATLAB Guest 1 231 12-10-2017 10:04 AM
Last Post: jaseela123
  JAVA PROGRAMMING CONSTRUCTS seminar flower 1 1,708 21-09-2017 04:14 PM
Last Post: jaseela123
  Extreme Ultra-Violet Lithography study tips 1 508 20-09-2017 02:24 PM
Last Post: jaseela123
  ASSEMBLY LANGUAGE PROGRAMMING EXAMPLES seminar tips 1 366 15-09-2017 11:35 AM
Last Post: jaseela123
  Programming Paradigm ppt seminar paper 1 1,098 15-09-2017 11:13 AM
Last Post: jaseela123
Sad what type of computer programming used for airline ticket reservations system Guest 1 133 14-09-2017 12:47 PM
Last Post: jaseela123
  Linear and Integer Programming Models project maker 1 261 11-09-2017 12:25 PM
Last Post: jaseela123
  applet programming in java pdf Guest 1 891 09-09-2017 10:48 AM
Last Post: jaseela123
  A PROBLEM-ORIENTED PROGRAMMING AND TESTING APPROACH FOR NOVICE STUDENTS REPORT study tips 1 473 31-08-2017 01:00 PM
Last Post: jaseela123
This Page May Contain What is Extreme Programming (XP) And Latest Information/News About Extreme Programming (XP),If Not ...Use Search to get more info about Extreme Programming (XP) Or Ask Here

Options: