Submitted in fulfilment of the requirements for the award of the degree of Bachelor of Technology in COMPUTER ENGINEERINGSubmitted To: Submitted by:MS. Poonam Gera HIMANSHU MUNJALHOD , C.S. VIII SEM , C.S.
INTRODUCTION AGILE METHODOLOGIES EXTREME PROGRAMMING(XP) XP WORKFLOW XP VALUES XP PRACTICES ADVANTAGE & DISADVANTAGE XP PROGRAMMING EXAMPLE
An agile development methodology Created by Kent Beck in the mid 1990’s A set of 12 key practices taken to their ―extremes‖ A mindset for developers and customers
A methodology is a formalized process or set of practices for creating software. An early methodology was the waterfall model. PROBLEMS: ◦ It assumes that there will be no unforeseen difficulties in the software development. ◦ It assumes that the customers know (and can specify) what they want, in extreme detail.
Agile programming methodologies assume: ◦ Customers can best discover what software meets their needs via frequent iterations ◦ Requirements will need to be revised, probably multiple times, during software development.
XP has nothing new, yet it has something new XP is a specific instantiation of an agile process XP combines best practices in a different way XP is a different approach to development which provides- Incremental planning Flexible implementation Automatic tests
Short description of what customer wants the software to do. Written by the customer in the customer terminology without techno-syntax. Used to create time estimates for the release planning meeting. Used instead of a large requirements document.
◦ Pair Programming Teams of two people◦ Test Driven Development Writing lots of tests, and writing them early◦ Continuous Integration Putting code together as you write it, not at the last minute◦ Coding Standards Learn and follow well-established conventions◦ Collective Code Ownership You are responsible for your partner’s code◦ Simple Design
User R P1, P2, P3 Program R and Data manager P2 Senior Pro. Pro 2 Prog1 P3P1 DBA CONVENTIONAL APPROACH Data
P1, P2, P3 R and Data User Pro 2 PROGRAMMING WITH XPProg1 Pro Lead
Built-In Quality Overall Simplicity Programmer Power Customer Power
Hard to do constant involvement of the customer Informal, little, or no documentation Misconception on the cost of change
Light-weight: discipline without bureaucracy Under stress, people do what is easiest ◦ All XP practices have short-term benefits as well as long-term benefits Development as a Conversation The code is the documentation
Not on very large projects Not for embedded software if the hardware is frozen Not with data-driven apps – RAD for these Not with ―Old Economy‖ management
Work as closely as you can with your partner Don’t just ―contribute‖ your share of the code—also review your partner’s code, checking for problems. You can use all the Java you know, if your partner also understands it Don’t: ◦ Depend on your partner to do it all ◦ Take off and do it all yourself