Software EngineeringSoftware Engineering

Methodology (Extreme Programming)James Gain

(jgain@cs.uct.ac.za)

http://people.cs.uct.ac.za/~jgain/courses/SoftEng/

Course Roadmap: 1Course Roadmap: 1stst Semester Semester

Introduction• Product• Process

Analysis• Principles• Use Cases• CRC Cards• Class Diagrams• Interaction Diagrams• State Diagrams

4 Lectures

Pressman ch. 1&2

6 Lectures

Pressman ch. 11&21

JUNE EXAMS & VAC

Course Roadmap: 2Course Roadmap: 2ndnd Semester Semester

Extreme Programming

Design

Testing

Management• Scheduling• Risk• Configuration

2 Lectures; ch. 13&22

Metrics

Teams

1 Lecture

2 Lectures; ch. 17,18,23

1 Lecture; ch. 3

2 Lectures; ch. 4, 19, 24

CASE 1 Lecture; ch. 31

3 Lectures;

ch. 5-7, 9

ObjectivesObjectives

1. Describe the history and principles of the Extreme Programming Methodology (XP) Pair Programming

Collective Code Ownership

Continuous Integration

Emphasis on Testing

2. Differentiate XP from other methodologies

3. Specify the Software Engineering component of the CS2 project

Extreme Programming in a NutshellExtreme Programming in a Nutshell

Extreme Programming: Lightweight: little documentation or administration overhead Agile: able to adapt quickly to changes in user requirements Best for small scale projects with uncertain or evolving

requirements

Style: Iterative development (about a dozen iterations of 1-3 weeks each)

of a complete system on each iteration Just in time planning (does not plan much beyond the current

iteration) Emphasis on testing (unit tests are written before functionality) Carefully considers people issues (stand-up meetings, pair

programming, no overtime)

http://www.extremeprogramming.org

History of XPHistory of XP

Approximately 5 years old. Started by Kent Beck at DaimlerChrysler in 1996.

The pendulum swings: A response to the heavyweight non-agile methodologies of the 80’s

Used successfully in many companies: Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First

Union National Bank and Ford Motor Company

Ranging from a small 9 Person-Month tariff calculation system to a medium 100 Person-Year cost analysis system

But there is still not enough evidence to determine if XP is the holy grail of SE

An Algorithm for XPAn Algorithm for XP

1. Develop Use Cases If there are technical uncertainties create an architectural spike

2. Do release planning (with project velocity input) If there are scheduling uncertainties create a spike

3. Iteratea) Do iteration planning (select use cases for the current iteration)

b) Development OO Analysis OO Design Create automated unit tests Code with pair programming Execute unit and acceptance tests

c) Integrate partial release

Pair ProgrammingPair Programming

The Idea: All code is created by two people working together at a single

computer Driver-Navigator process. Driver writes the code while the

Navigator suggests alternatives Roles and pairings must be rotated frequently

Proponents claim: It increases software quality without impacting delivery (coding

takes longer but debugging is much shorter) Less experienced member acquires skills from the more experienced

member Prevents, knowledge being held by only a single person, which is

disastrous if that person leaves

Opponents claim: Much slower coding

Collective Code OwnershipCollective Code Ownership

The Idea: Everyone owns and has access to all of the code Every person has the right to view, change and improve any part of

the system’s code But An initial programming task is assigned to a specific pair and

“you break it - you fix it” applies Promotes ego-less programming

Proponents Claim: Improves quality because code is subject to peer review Developers better understand the overall system

Opponents Claim: Developers no longer receive personal credit for their efforts

Continuous IntegrationContinuous Integration

The Idea: Integrate code into the repository on a daily (preferably hourly)

basis after unit testing

Team continuously maintains a working system and incrementally adds features

Proponents Claim: Avoids compatibility problems since changes are not made to

obsolete code

Source of failure during integration are immediately obvious

Avoids weeks of integration at the end of the project

Opponents Claim: Wastes time

Emphasis on TestingEmphasis on Testing

The Idea: Unit Tests: programmers create automated unit tests first and then

write just enough code to pass these tests

Acceptance Tests: developed for each use case by the customer to test if overall system requirements are met

Proponents Claim: Helps the developer focus on exactly what needs to be done

Stops scope creep since the developer knows when the unit is finished

Opponents Claim: Difficult to build in quality

Other Notable FeaturesOther Notable Features

The computers of an XP team are set up in the center of a large room lined with cubicles

A client representative works with the XP team at all times

No individual can work overtime for two successive weeks

There is no specialization. All members work on specifications, design, coding and testing

There is no overall design phase. The design is modified as the product is being built

XP ProjectXP Project

User stories: Focused on user needs Equivalent to use cases Only need enough detail to create an estimate of implementation time (1-3 ideal

programming weeks per story) An ideal week is how long you imagine it would take to implement that story if you had

absolutely nothing else to do. No dependencies, no extra work, but do include tests

Project DetailsProject Details

Architectural Spike: Explore a tough technical problem by prototyping it in isolation. Useful if estimates are uncertain

System Metaphor: Binding metaphor for whole system which allows consistent naming

Release Planning: Specify which use cases will be implemented in each iteration. All parties (technical, business, users) must agree

Project Velocity: The number of use cases finished in the last iteration. Employed as a measure of work rate

Acceptance Tests: Automated black box tests extracted from the use cases

Small Releases: A version of the system given to the user for testing

IterationIteration

Iteration Planning: Used at the beginning of an iteration to decide what will be implemented. Just in time planning

Bugs: If an acceptance test fails, then unit tests can be used to hone in on the error

DevelopmentDevelopment

Stand up Meeting: Everyone meets daily for a short time (ensured by having team members stand in a circle). Avoids long unnecessary meetings.

Unit Tests: Automated tests created before coding to test individual classes

Rules of XP DevelopmentRules of XP Development

Pair Programming All code is created by two people working together at a single

computer

Refactor Mercilessly Do not hold onto obsolete designs and code.

Refactor to remove needless clutter and complexity.

Move People Around Avoids serious knowledge loss and coding bottlenecks by cross

training developers on all aspects of the system

CRC Cards Class Responsibility Collaborator Cards are a good way of

designing an object-oriented system

CS2 ProjectsCS2 Projects

Apply Extreme Programming

Adhere to UML Notation

Tools: Need to discuss and show evidence of automated testing,

configuration management and project planning tools

Distribution of programming: Each team members must act as lead programmer for

half the work (assuming a 2 person team) and be able to answer detailed questions on their sections

The load distribution must appear in the project plan

Intermediate SE SubmissionsIntermediate SE Submissions

Initial Project Specification 12h00 Friday 8 August

Weighting 5%

Hierarchical Use-Case Scenarios

Project plan for 2 * 3 week iterations

First XP Iteration 12h00 Friday 22 August

Weighting 20%

Includes Use-Cases and Planning for the entire system

BUT CRC, Object-Relationship and Object-Behavioural models for ONLY those Use-Cases developed in the first iteration

Final SE SubmissionFinal SE Submission

Second Iteration and Project Completion 9h00 Monday 22 September Weighting 75% Includes a complete hand-in for the entire implemented system There are additional non Software Engineering requirements (e.g.

a user manual) Analysis: Use-Cases, CRC Cards, Conceptual Class Diagram,

Interaction Diagram(s), State Diagram(s) Design: Package Diagram, Specification Class Diagram Planning: Release Plan, Iteration Plan, Project Velocity Testing: Unit Tests, Acceptance Tests, System Tests

Software Engineering counts half of the final project mark.