OO Methodology

UP verses XP

Two Software Processes:Rational Unified Process and Extreme

Programming

3

Two ends of the spectrum

• RUP

– Heavyweight

– Tool support

– Big methodology for big systems

• XP

– Lightweight

– No real tool support – more a philosophy

– Small methodology for small systems

4

Why right at the end?

• Avoid confusing you with the sophistication and complexity of RUP

• To avoid subverting you with the simplicity of the temptations of XP

Rational Unified Process

6

Rational Unified Process

• www.rational.com• Grown up around the three amigos

– Booch, Rumbaugh, Jacobsen

• Linked to the UML and OO• A heavyweight process• Defines many roles and the artifacts and interactions

(many dozens of roles in the full RUP)• Spiral model

7

Flexible

• The RUP is designed to be modified

• The basics are set but the particular roles and artifacts can be varied to suit the project

• Not so flexible within a project

• Project management focused

8

Tool Support

• RUP Builder• ProcessWorkbench• AnalystStudio• Requisite pro• ROSE• Purify• ClearCase• XDE• RapidDeveloper• QualityArchitect

9

When to use RUP

• Large projects (or perhaps small ones)

• Complex software with many requirements

• Specialised roles

• If you wish to improve software quality processes over time (CMM)

10

Rational’s 6 practices of SE

• Develop Iteratively

• Manage Requirements

• Use Component Architectures

• Model Visually

• Continuously Verify Quality

• Manage Change

http://www.rational.com/corpinfo/practices.jsp

11

Develop Iteratively

One of the core Rational best practices is the notion of Developing Iteratively. With the iterative approach, a project has a lifecycle consisting of several iterations. Each iteration is time – constrained, and ends with a specific progress milestone. Unlike a waterfall or linear method, the iterative approach helps you address and mitigate risk early and continuously, through demonstrable progress and frequent executable releases.

12

Manage Requirements

Requirements management is a systematic approach to finding, documenting, organizing, and tracking a system's changing requirements. Keys to effective requirements management include maintaining a clear statement of the requirements and ensuring traceability to other requirements and other project artifacts. Managing requirements helps to ensure that the final system will fulfil user needs and provide resilience in the face of inevitable change.

13

Use Component Architectures

Components are non-trivial modules – groups of code or subsystems that fulfil a clear function. Architectures based around components tend to reduce the effective size and complexity of the solution, and so are more robust and resilient. Implementing component architectures early in the project, mitigateskey risks, reducing overall development costs.

14

Model Visually

Visual modeling is the use of semantically rich, graphical and textual design notations, like the industry-standard Unified Modeling Language (UML), to capture software designs. Visual modeling allows you to hide details and write code using graphical building blocks that are concise and easily understood by stakeholders.

15

Continuously Verify Quality

Poor performance and poor reliability are common results of an inadequate focus on software quality. Rational places an emphasis on quality throughout the project lifecycle, with testing conducted in each iteration. This is in contrast to a more traditional approach that leaves the testing of integrated software until late in the project's lifecycle.

16

Manage Change

A key challenge when developing software-intensive systems is coordinating the work of multiple developers organized into different teams – sometimes located at different sites – working on multiple iterations, releases, products, and platforms. By establishing repeatable procedures for managing changes to software and other development artifacts, you minimize chaos, maximize efficient allocation of resources, and ensuring your freedom to change.

17

18http://www.therationaledge.com/content/feb_03/f_managementMaturity_jh.jsp

19

The Ten Essentials of RUP

• Develop a Vision • Manage to the Plan • Identify and Mitigate Risks • Assign and Track Issues • Examine the Business Case • Design a Component Architecture • Incrementally Build and Test the Product • Verify and Evaluate Results • Manage and Control Changes • Provide User Support

http://www.therationaledge.com/content/dec_00/f_rup.html

20

What do people think of the RUP

• Can be big and cumbersome

• Can be prescriptive and constraining

• Very large experience base

• Often used to ensure uniformity across an organisation

– If you have 1000 developers and 30 projects there are advantages in having them use a consistent set of processes and tools

21

What does Clint think?

• Well thought out

• Developed over many years

• Big advantage is the tool support

• RUP is more flexible than people think– Although not so flexible within the life of a project

• Can be a little imposing– It seems large and heavy and it takes experience to simplify it

22

Resources

• http://www.rational.com/media/whitepapers/tp151.pdf

• http://www.rational.com/products/rup/faq.jsp?SMSESSION=NO#q1

• http://www.dcs.ed.ac.uk/teaching/cs2/online/Lectures/CS2Ah/SoftEng/se02-slides.PDF

Extreme Programming

24

Extreme Programming

• www.extremeprogramming.org• Cool name• Looks suspiciously like what you would do

if you were put in charge of a project at the end of second year– Start programming– Release often (daily)– Unit test everything– Do not worry about requirements– Have a client on site and use their stories and

their feedback as the basis for development

25

26

Values sought by XP programmers

• Communication– Within team (client is part of the team)

• Simplicity– Keep the processes as simple as possible

• Feedback– Seek feedback from the client at every iteration

• Courage

27

When to use XP

• Unknown/uncertain requirements

• High risk

• Small groups (2 - 12)

• Client can be involved

• Testability

28

Agile Processes

• SCRUM – Kevin Chan’s game lecture

• XP

• Crystal

• Xbreed

• Feature Driven Development

29

The 12 practices

• The Planning Process, sometimes called the Planning Game. – The XP planning process allows the XP

"customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success.

• Small Releases. – XP teams put a simple system into production

early, and update it frequently on a very short cycle.

• Metaphor. – XP teams use a common "system of names" and

a common system description that guides development and communication.

• Simple Design.   – A program built with XP should be the simplest

program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring“.

http://www.xprogramming.com/what_is_xp.htm

30

The 12 practices

• Testing. – XP teams focus on validation of the software at

all times. Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided.

• Refactoring.   – XP teams improve the design of the system

throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete.

• Pair Programming. – XP programmers write all production code in

pairs, two programmers working together at one machine. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone.

• Collective Ownership. – All the code belongs to all the programmers.

This lets the team go at full speed, because when something needs changing, it can be changed without delay.

31

The 12 practices

• Continuous Integration. – XP teams integrate and build the software

system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.

• 40-hour Week.   – Tired programmers make more mistakes. XP

teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

• On-site Customer. – An XP project is steered by a dedicated

individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project.

• Coding Standard. – For a team to work effectively in pairs, and to

share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly.

32

XP Rules

• User stories are written• Release planning creates the schedule• Make frequent small releases• The Project Velocity is measured• The project is divided into iterations• Iteration planning starts each iteration• Move people around• A stand-up meeting starts each day• Fix XP when it breaks

33

Designing

• Simplicity• Choose a system metaphor• Use CRC cards for design sessions• Create spike solutions to reduce risk• No functionality is added early• Refactor whenever and wherever possible

34

Coding

• The customer is always available• Code must be written to agreed standards• Code the unit test first• All production code is pair programmed• Only one pair integrates code at a time• Integrate often• Use collective code ownership• Leave optimization till last• No overtime

35

Testing

• All code must have unit tests• All code must pass all unit tests before it

can be released• When a bug is found tests are created• Acceptance tests are run often and the score

is published

36

What do others think of XP

“XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way.” Matt Stephens

“It’s all just a bunch of daft crap”

http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp

37

What does Clint think?

• Agile processes are valuable and should be explored, used, adopted and adapted

• No one methodology will provide all of the answers

• In the range of possible agile processes XP looks like it has some problems that I find difficult to ignore

38

What does Clint think?

• OK, perhaps not problems – let’s call them limitations

• When do I think that XP will work– Small projects that are self contained– When the client is always available (better still if

you are your own client)– When the project involves no interfaces with

other systems that are also under development– When the programming team is highly skilled –

particularly with design– When the programming team is highly

disciplined – XP is not easy to follow

39

Where do I see problems

• Design - no one ever really tests the quality of the design

• Architecture – there never really is an architecture – it just emerges over time

• Reuse – it is not clear to me how any of the software developed under XP can be reused. The philosophy of XP tends to mitigate against reuse so this is probably just my prejudice

• Pairs programming – I believe that you need highly disciplined and experience programmers to make XP work – I don’t believe that these types of programmers always work most productively in pairs (I do believe that less experienced programmers may be more productive in pairs)

• The customer is in the critical path for the entire life of the XP program – that’s scary

40

What tha?

“Figure 1 is a digital pho-to of a Thangka painting on the wall of my office. Depicted on this painting is an evocative model of Tibetan Buddhist cosmology and philosophy. … I propose that this kind of painting be the foundation for an XP architectural model.”

http://www.agilealliance.org/articles/articles/DavidWest--MetaphorArchitectureandXP.pdf

41

Either this is a joke

• or it is serious• Either way it is indicative of some of the

advocates of XP• At its core XP offers some interesting ideas

and some useful concepts but it has been hyped out of all proportion

• At best it seems to me to be a possible solution for a small range of applications

• Every time XP is modified by someone to address its shortfalls it winds up looking more like RUP

42

Conclusions

• Both processes have their place• RUP is about

– Management, quality, requirements, and process– All projects but is better suited to big systems– Many specialised roles

• XP is focused on– Change, rapid deployment, customer

involvement, and regular releases– Small systems– Based on programmers

43

Resources

– Using Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming (http://www.rational.com/products/whitepapers/tp183.jsp)