(1)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

Experiences with a Software Process in the CESAR Project

Vito Baggiolini, SL/CO

Laia Mateos Miret, SL/EA

(2)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

Outline• The Cesar Project• Our Software process• What is good, what must become better• A developers’ view (Laia Mateos)• Lessons learned• Conclusions

(3)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

The Cesar Project• Cesar = Cern EA SoftwAre Renovation

– Build a new control system for the SPS Exp. Areas– Beginning 2000 - End 2003– 8 Team members

• Technology in Cesar – Standard & open– Java 2 Enterprise Edition

1km

• SPS Experimental Areas~ 6.3 km of Beam lines

~ 1000 Physics Equipment

~ 2000 Users

EAEA

SPS

(4)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

The Beginning of Cesar• Everything was new

– OO, Java, Development environment (before: C/Motif)– Process

• Developers in the Team– Most are domain experts and users– Had been programming for years with non-OO languages– Almost all had to learn OO/Java– Not used to a software process– Very motivated and collaborative

• Developers had to learn (too) many new things– OO, UML, Java, Design Patterns, EJB, Swing, GDPM,…– Rose, JBuilder, Razor, JUnit,…

• We had to organize everyting– Training, process and tools

• We took some shortcuts…

(5)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

The Cesar Process• Inspired by Unified Software Development

Process (USDP) and Extreme Programming (XP)

• Adapted to “reality” and constraints• Goal-Directed Project Management

(C) Lars Ewe, Webgain Inc

(6)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

USDP – At a Glance• Uses four phases

– Inception, Elaboration, Construction, and Transition

• Allows for Iteration within phases and across phases

• Defines the following workflows– Core process workflows:

Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment

– Core supporting workflows:Configuration & Change Mgmt., Project Mgmt.

• Architecture-centric, Use-case based, Iterative, Incremental

(C) Lars Ewe, Webgain Inc

(7)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

XP – At a Glance• eXtreme Programming, developed by Kent

Beck, 1996• XP uses very iterative approach• Based upon four values:

– Communication, simplicity, feedback, and courage

• Twelve XP practices support the four values:– Release & iteration planning, small releases,

metaphor (architecture), simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40 hour week, on-site customer, coding standards

(8)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

What we’ve taken from USDP• Project Phases

– Inception => before Cesar Project started– Elaboration => at Machine Start-Up 2001– Now in Construction phase

• Architecture centric– Candidate architecture was ready from the start

• Use cases & GUI sketches– Use cases (partly) written by users– GUI sketches

• Incremental and iterative– Intermediate prototypes– Not always easy to validate (if machine is down)

• Configuration management

(9)

Vito

Ba

gg

iolin

i & L

aia

Ma

teo

s

How we’re inspired by XP• “Prominent” Testing (but not testing first)• Code reviews (but not peer programming)• Close contact with users (“on-site customer”)• Courageous Refactoring (esp. one developer)• Communication• Simplicity(?)• Coding standards• 40 hour week ;-)

(1

0) V

ito B

ag

gio

lini &

La

ia M

ate

os

Goal Directed Project Management

• What is GDPM?– A light-weight method for project

management, supported by a software tool– Two-level planning:

• Milestone planning = what results to achieve when• Activity planning = how to achieve results

– Clear deadlines, goals and responsibilities– Adaptive planning

• Course on GDPM by Bernard Denis

(1

1) V

ito B

ag

gio

lini &

La

ia M

ate

os

Planning in GDPM• Milestones planning (“what results”)

– Milestones must be controllable, unambiguous, easy to understand, and include an anticipated date

– Typical milestone represents a state: • a goal has been reached, a decision has been taken, a product

has been delivered,...

• Activity planning (“how to reach milestones”)– identify activities to reach a milestone– attribute responsible persons and deadlines

• Mapping USDP onto GDPM – USDP phases map to GDPM Milestone plans– USDP workers map to GDPM roles– Iterations difficult to map (GDPM is linear)– Both are adaptive

(1

2) V

ito B

ag

gio

lini &

La

ia M

ate

os

What is good in Cesar• We try to use a process that favours teamwork

– Use cases and GUI sketches– UML Analysis & Design as group activity– Common UML Model – Architecture with clear subsystem dependencies– Team work also on UML model (not only code)– All shared things are under Configuration Control

• Good team– Ready to make compromises– Easily adopted common tools & conventions

• Goal Directed Project Management => Laia

(1

3) V

ito B

ag

gio

lini &

La

ia M

ate

os

What we should do better• More thorough risk management

– Especially the use of J2EE bears risks

• Better Quality Assurance– More thorough testing (but not “testing first” a la XP)

– Test case management– Tools for automation

• More active GDPM feedback from team members

(1

4) V

ito B

ag

gio

lini &

La

ia M

ate

os

Things I Insist On• Project management

– Weekly progress meetings (with “tour de table”)– Regular progress review using GDPM every 2 or 3 weeks

• UML– Maintaining the Architecture in UML (regular checks)– Design discussions only with UML (not code)– Everyone does at least reverse engineering

• Coding– Coding conventions– Code reviews– Testing (partly with simulated classes)– Use of Design Patterns

• Configuration control (“It only exists if it’s in Razor”)

(1

5) V

ito B

ag

gio

lini &

La

ia M

ate

os

Things I don’t insist on (yet)• I have given up on:

– Trying to force people to do UML first– Direct GDPM feedback using the tool

• I would still like to…– Use Rational Rose more thoroughly

• Synchronized round-trip engineering with code generation• Track dependencies from Use Cases to deliverables• Test management

– Tailor the process with the RUP tool from Rational– Try out Design by Contract

(1

6) V

ito B

ag

gio

lini &

La

ia M

ate

os

A developer’s experience• Having…

– A physicist background – Little knowledge in OO language (Java)– No experience about UML at all

• …a lot of effort and time has been invested on learning both methods and tools.

(1

7) V

ito B

ag

gio

lini &

La

ia M

ate

os

A developer’s experience…• But, what has been really useful and valuable

for the project:– GDPM planning– Basic knowledge of UML– Learning how to work in a team– Doing code reviews

• Why?

(1

8) V

ito B

ag

gio

lini &

La

ia M

ate

os

A developer’s experience...• GDPM planning

– 1st, it contains a clear picture of the whole project– 2nd, it gives a detailed list of the activities where

each team member is involved in

• UML– Even a small set of elements in UML is sufficient – Class diagrams and sequence diagrams– Few notational elements (inheritance, aggregation,

interface implementation) allow you to describe your system in terms of relationships and dependencies

(1

9) V

ito B

ag

gio

lini &

La

ia M

ate

os

A developer’s experience…• Working in a team

– It doesn’t come for free– But a good atmosphere among team members helps

a lot– It requires team members commitment and

agreement on working procedures

• Code reviews– Are useful and enriching for everybody– Give you new points of view as well as different ways

of doing the same thing– Important to keep in mind that you are not going to

be judged

(2

0) V

ito B

ag

gio

lini &

La

ia M

ate

os

Lessons learned • Design process doesn’t come for free

– Continuous effort from all team members needed– You need one person who feels responsible

• Decide early on common rules and shared design– E.g. coding conventions, tools, common base classes– Doing it later requires changing habits and design/code

• Be architecture-centric, risk-aware and iterative – First the skeleton, then the muscles – Developers like to completely finish each layer first

• Difficult to give the right dose of information to the team– Too much info overwhelms them – Too little (or to late) info causes later deficiencies Daily contact with developers Always available for questions and discussions

(2

1) V

ito B

ag

gio

lini &

La

ia M

ate

os

Bringing the Process to the Team• It takes a lot of “preaching”…

…and you end up preaching to the already converted• Sometimes you’d like to force people to their own good

– Its not out of bad will – they don’t want to “loose time”– But of course patiently convincing them is better

• Conviction can come from– UML: Productive Design discussions – Mixing people with different attitudes– Giving the good example– “Let’s quickly do this together”

• Different processes for different sub-systems is OK

(2

2) V

ito B

ag

gio

lini &

La

ia M

ate

os

Conclusions• We have something like a software process• Inspired by USDP and XP, adapted to reality

and “interpreted” by individuals• A software process requires continuous effort• Some team members like to follow a process

… the rest has to be convinced with patience ;-)

(2

3) V

ito B

ag

gio

lini &

La

ia M

ate

os