Software Engineering

1. Software Engineering Methodology (Extreme Programming) James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain/courses/SoftEng/

2. Course Roadmap: 1st Semester • Introduction • Product • Process 4 Lectures Pressman ch. 1&2 • Analysis • Principles • Use Cases • CRC Cards • Class Diagrams • Interaction Diagrams • State Diagrams 6 Lectures Pressman ch. 11&21 JUNE EXAMS & VAC

3. Course Roadmap: 2nd Semester 1 Lecture Extreme Programming Design 2 Lectures; ch. 13&22 Testing 2 Lectures; ch. 17,18,23 Teams 1 Lecture; ch. 3 Metrics 2 Lectures; ch. 4, 19, 24 • Management • Scheduling • Risk • Configuration 3 Lectures; ch. 5-7, 9 CASE 1 Lecture; ch. 31

4. Objectives • Describe the history and principles of the Extreme Programming Methodology (XP) • Pair Programming • Collective Code Ownership • Continuous Integration • Emphasis on Testing • Differentiate XP from other methodologies • Specify the Software Engineering component of the CS2 project

5. Extreme 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

6. History 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

7. An Algorithm for XP • Develop Use Cases • If there are technical uncertainties create an architectural spike • Do release planning (with project velocity input) • If there are scheduling uncertainties create a spike • Iterate • Do iteration planning (select use cases for the current iteration) • Development • OO Analysis • OO Design • Create automated unit tests • Code with pair programming • Execute unit and acceptance tests • Integrate partial release

8. Pair 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

9. Collective 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

10. Continuous 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

11. Emphasis 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

12. Other 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

13. XP 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

14. Project 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

15. Iteration • 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

16. Development • 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

17. Rules 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

18. CS2 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

19. Intermediate 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

20. Final 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.