1. (1) Vito Baggiolini & Laia Mateos Experiences with a Software Process in the CESAR Project Vito Baggiolini, SL/CO Laia Mateos Miret, SL/EA

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

3. (3) Vito Baggiolini & Laia Mateos 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 EA SPS

4. (4) Vito Baggiolini & Laia Mateos 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. (5) Vito Baggiolini & Laia Mateos The Cesar Process Inspired by Unified Software Development Process (USDP) and Extreme Programming (XP) Adapted to “reality” and constraints Goal-Directed Project Management

6. (6) Vito Baggiolini & Laia Mateos (C) Lars Ewe, Webgain Inc 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

7. (7) Vito Baggiolini & Laia Mateos (C) Lars Ewe, Webgain Inc 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. (8) Vito Baggiolini & Laia Mateos 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. (9) Vito Baggiolini & Laia Mateos 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 ;-)

10. (10) Vito Baggiolini & Laia Mateos 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

11. (11) Vito Baggiolini & Laia Mateos 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

12. (12) Vito Baggiolini & Laia Mateos 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

13. (13) Vito Baggiolini & Laia Mateos 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

14. (14) Vito Baggiolini & Laia Mateos 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”)

15. (15) Vito Baggiolini & Laia Mateos 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

16. (16) Vito Baggiolini & Laia Mateos 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.

17. (17) Vito Baggiolini & Laia Mateos 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?

18. (18) Vito Baggiolini & Laia Mateos A developer’s experience... GDPM planning –1 st, it contains a clear picture of the whole project –2 nd, 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

19. (19) Vito Baggiolini & Laia Mateos 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

20. (20) Vito Baggiolini & Laia Mateos 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

21. (21) Vito Baggiolini & Laia Mateos 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

22. (22) Vito Baggiolini & Laia Mateos 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 ;-)

23. (23) Vito Baggiolini & Laia Mateos