System Analysis & Design Methods V Extreme Programming XP/dX.

Slides:



Advertisements
Similar presentations
© University of Glamorgan1 Extreme Programming and its effect on project management Second Computing Project Management Workshop 13 September 02, University.
Advertisements

A little Software Engineering: Agile Software Development C Sc 335 Rick Mercer.
Alternate Software Development Methodologies
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall B.1.
Agile development By Sam Chamberlain. First a bit of history..
1 March Extreme programming. Presentations Tuesday Campus Tour Sami Says Hawks Thursday Read2Me UNCSET Oral Lab NetVis If helpful, invite your client.
Agile Requirements Methods CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 26, 2004.
Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer.
Extreme Programming Collaboration in Software Development Process.
Chapter 6 Prototyping, RAD, and Extreme Programming
EXtreme Programming By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)
EXtreme Programming Quick Introduction Daniel Arraes Pereira Eduardo Lourenço Apolinário Ricardo de Oliveira Cavalcanti.
Extreme Programming Mark Steverson. What Is Extreme Programming? ● Extreme Programming (XP) is a lightweight, agile methodology developed by Kent Beck.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
An Agile View of Process
Introduction to Continuous Integration Mike Roberts.
 Definitions  Background/History  Continuous Delivery › How to practice Continuous Delivery  Continuous Integration  Continuous Integration Tools.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Software Engineering Modern Approaches
Chapter 4 Agile Development
Copyright David Churchville - XP and Agile Planning David Churchville ExtremePlanner Software XP Fishbowl.
Extreme Programming(XP)
Extreme programming overview Agenda  Extreme programming goals  Extreme programming values  Extreme programming practices  The Extreme programming.
Extreme Programming Daniel Baranowski 3/29/06. What is Extreme Programming? An agile development methodology Created by Kent Beck in the mid 1990’s A.
Embracing change with Extreme Programming Method Engineering Erik ten Brinke
Unified Process versus Extreme Programming. Outline Compare and contrast UP and XP  Processes / Disciplines  Management  Artefacts Risk management.
R ELEASE P LANNING. H ELPFUL R ESOURCES Planning Extreme Programming, Kent Beck and Martin Fowler Extreme Programming Installed, Ron Jeffries, Ann Anderson.
1 e X treme P rogramming D. Dranidis September 2000 CITY College.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
XP (not Microsoft) e X treme P rogramming Can KOMAR
XP – Extreme Programming
Implementing XP at PUT Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
CS3100 Software Project Management Agile Approaches.
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
CS5103 Software Engineering Lecture 02 More on Software Process Models.
Extreme Programming Based on and
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Extreme programming (XP) Variant of agile Takes commonsense practices to extreme levels © 2012 by Václav Rajlich1.
UHCS 2005, slide 1 About Continuous Integration. UHCS 2005, slide 2 Why do you write Unit Test ? Improve quality/robustness of your code Quick feedback.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix B Agile Methodologies B.1.
Extreme Programming. Extreme Programming (XP) Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries Agile software development methodology.
Meeting Practices Yan Wei Foundation Extreme programming is used Meeting practices are based on extreme programming technology with.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
1 Introduction to eXtreme Programming Remko Popma Azzurri Ltd.
Extreme Software Engineering A Hands-On Approach From Extreme Software Engineering: A Hands-On Approach Daniel H. Steinberg Daniel W. Palmer.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
Industrial Software Development Process Bashar Ahmad RISC Software GmbH.
Testing under the Agile Method CSCI 521 Software Project Management based on the book Testing Extreme Programming by Lisa Crispin and Tip House.
Chapter 3 Agile software development 1 Chapter 3 – Agile Software Development.
AGILE METHODS Curtis Cook CS 569 Spring 2003.
Embedded Systems Software Engineering
CS223: Software Engineering
Requirements Engineering Lecture 4
Appendix B Agile Methodologies
Extreme Programming.
Extreme Programming.
روش‌های سريع الانتقال (چابک) توسعه نرم افزار
What do you need to know about XP?
Chapter 3: Agile Software Processes
Extreme Programming.
Presentation transcript:

System Analysis & Design Methods V Extreme Programming XP/dX

2V Extreme Programming XP/dX A process: Extreme Programming (Kent Beck) and dX We describe the dX version of XP by Robert C. Martin © Copyright 2003.

3V Extreme Programming XP/dX Extreme Programming (Kent Beck) and dX Structure Iterative development in general Iterative development in general Initial exploration (1st iteration) Initial exploration (1st iteration) Estimating features Estimating features Calibrating estimates Calibrating estimates Planning (2nd and after) Planning (2nd and after) Planning Releases Planning Releases Planning Iterations Planning Iterations Middle (adapting ambitions) Middle (adapting ambitions) Day 10: Feedback about speed: Day 10: Feedback about speed:

4V Extreme Programming XP/dX Extreme Programming (Kent Beck) and dX Structure (continued): What happens in one iteration What happens in one iteration In general In general Practices or habits Practices or habits Pair Programming Pair Programming Acceptation stests Acceptation stests Unit Tests Unit Tests Refactoring Refactoring Open Office Open Office Continuous Integration Continuous Integration

5V Extreme Programming XP/dX Iterative development Iterative development, in general Iterative development, in general Doing everything in 2 weeks : requirements, analysis, design, implementation, testing, documentation. Every 2 weeks end in executable code 1 exception: the first iteration is shorter ( maybe 3 days) and does not need to entail code. Initial exploration (3 days) Initial exploration (3 days) Determine requirements and priorities with the client. Determine user stories (=1 way to use the system) These activities will be repeated in every iteration

6V Extreme Programming XP/dX Iterative development (continued) Initial exploration (continued) Initial exploration (continued) Estimating features Estimating features Every story is assigned an estimate in ‘points’, representing the work needed to implement the story. Every story is assigned an estimate in ‘points’, representing the work needed to implement the story. Dimensionless (unitless) number: you might use ‘perfect programming days’ Dimensionless (unitless) number: you might use ‘perfect programming days’ 1 to 2 team days per story 1 to 2 team days per story Calibrating estimates Calibrating estimates Initial exploration may or may not end in executable code Initial exploration may or may not end in executable code Goal: Determining how many days go into one point. Goal: Determining how many days go into one point.

7V Extreme Programming XP/dX What happens in one iteration 1 iteration = 2 weeks In general In general Run through all phases: requirements, analysis, design & implementation Run through all phases: requirements, analysis, design & implementation ONLY for the user stories, selected by the client. ONLY for the user stories, selected by the client. This way, the most important stories get to be implemented first. This way, the most important stories get to be implemented first.

8V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits: Practices or habits: Pair-programming Pair-programming 2 programmers per workstation 2 programmers per workstation 1 programmer stays with his task 1 programmer stays with his task change partners every day change partners every day Advantages: automatic code reviews, one person programs, the other one judges, enhances communication. It might reduce the amount of stupid mistakes. Advantages: automatic code reviews, one person programs, the other one judges, enhances communication. It might reduce the amount of stupid mistakes.

9V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Acceptation tests: Acceptation tests: Tests to find out whether the code meets the specifications. Acceptation tests are about the bigger picture (stories) Tests to find out whether the code meets the specifications. Acceptation tests are about the bigger picture (stories) Halfway through 1 iteration (after 1 week) they have to be available. Halfway through 1 iteration (after 1 week) they have to be available.

10V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Unit tests: Unit tests: Tests that run say every 5 minus, while you are programming. Tests that run say every 5 minus, while you are programming. They are automated. You don’t have to go through tens of screens; compare & report happen automatically. They are automated. You don’t have to go through tens of screens; compare & report happen automatically. You write these tests before you write the tested code. You write these tests before you write the tested code. They are a kind of specification documentation and an indication that the specs are met. The test code should have meaningful identifiers, e.g. not xy_132. They are a kind of specification documentation and an indication that the specs are met. The test code should have meaningful identifiers, e.g. not xy_132.

11V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Refactoring Refactoring =Enhancing the design of code without changing its behavior. ( Martin Fowler ) =Enhancing the design of code without changing its behavior. ( Martin Fowler ) Without automated tests, refactoring is risky. Without automated tests, refactoring is risky.

12V Extreme Programming XP/dX What happens in one iteration (continued) Practices or habits (continued): Open Office Open Office Everybody works in the same office. The client too ! This enhances communication. Everybody works in the same office. The client too ! This enhances communication. Continuous integration (controversial) Continuous integration (controversial) No one can block source files. (Version Control) -> This forces every programmer to check in their work quickly, otherwise merges become too difficult. BTW: this issue is controversial but needed for the next point: No one can block source files. (Version Control) -> This forces every programmer to check in their work quickly, otherwise merges become too difficult. BTW: this issue is controversial but needed for the next point: Every programmer regularly runs all unit and acceptance tests. This is pointless if the work of other members is weeks old because they are blocking their source file for weeks. Every programmer regularly runs all unit and acceptance tests. This is pointless if the work of other members is weeks old because they are blocking their source file for weeks.