Roundtable on Software Process

1. Roundtable on Software Process Input from LHCb

2. Key features of our development process • An organisational structure that aims to minimise unnecessary duplication and encourages communication • organisational structure chart shows common support for on/offline • A small development team meeting regularly • first few weeks 8 people met every day • The existence of a strong architectural vision describing the logical and physical structure of the system • The appointment of an architect to lead this effort is essential (first team member) • Our process is “architecture driven” • The collection of use cases that define the behaviour of the system • one member of the development team is assigned to this task • he conducts personal interviews with all end users (stakeholders) • essential for capturing requirements • All architectural features and design criteria are captured in the Architecture Design document

3. Key features of our development process - 2 • The construction of frameworks that respect architecture • comprises all services needed by data processing applications • leads to a common vocabulary between framework builders, client developers and end-users to create a shared understanding of the problem • Effective use of object-oriented modeling and coding guidelines • Formal training programme dedicated to LHCb members • LHCb OO A&D course - ~50 people (+ Paul Kunz’ C++ for Physicists course) • Configuration management there from the beginning • librarian is a member of the design team from the beginning • librarian sets up the code repository (CVS) and manages releases (CMT) • The application of an iterative and incremental development life-cycle • Feedback from users at each stage. • Set priorities for what the following release should contain • Reviews conducted at all critical stages • Strategic decisions taken following thorough review (anticipate ~1 /year) • Major project reviews at major milestones eg technology change (~ every 2 years)

4. What we have still to do... • We have not yet developed procedures for handling : • quality control / testing (walkthroughs, code checking, monitoring of correctness and performance etc.) • documentation ( expand on templates, automatic doc of code, …. • We anticipate that the development team must have specialists in each of these fields

5. Supplementary slides giving more details

6. Process for Organising Software Development Activities Manage Plan, initiate, track, coordinate Set priorities and schedules, resolve conflicts Build Develop models, Evaluate toolkits Architect components and systems Choose integration standard Engineer reusable components Support Support development processes Manage and maintain components Certify, classify, distribute Document, give feedback Assemble Design application Find and specialise components Develop missing components Integrate components Requirements Existing software systems

7. LHCb ComputingProject Organisation Technical Review Steering Group M E M M C A Arch. Review ... M A E C Coordinator A Architect Reconstruction M DAQ M M Project Manager E Project Engineer Simulation M Controls M Analysis M Control Room M Frameworks Architecture, Components, Integration technology, Libraries and toolkits A Manage ... ... Assemble Support Support M M Software SDE Process Quality Librarian Training Webmaster Facilities CPU farms Desktop Storage Network System Man. Build Vendors IT-IPT .. Vendors IT-PDP Vendors, IT-ASD

8. Development Cycle - status • Sept 98 - architect appointed, design team of 6 people assembled • Nov 25 ’98 - 1- day architecture review • goals, architecture design document, URD, scenarios • chair, recorder, architect, external reviewers • Feb 8 ’99 - GAUDI first release • first software week with presentations and tutorial sessions • plan for second release • expand GAUDI team to cover new domains (e.g. analysis toolkits, visualisation) • May 30 ‘99 - GAUDI second release • second software week… • plan for third release • expand GAUDI team to cover new domains (GEANT4 simulation toolkit) • Nov ‘ 99 - next GAUDI release and software week planned

9. Development Cycle Final system Incremental releases Major project reviews. Possibility of changing the direction 1998 2000 2002 2004

10. Goals of the Architecture Review (26.11.98) • Forces us to document the architecture. • Evaluate early before it becomes a blueprint for the software. • Point out places where it fails to meet requirements and show alternative designs. • Validate de requirements. • Determine where finer-grain depictions are needed. • Ensure consistency across entire system. • Disseminate ideas on what constitutes a good architecture. • Determine whether can proceed to next stage of development. • Follow-up.

11. Review Process • We followed Software Architecture Analysis Method (SAAM) • develop use cases by questioning stakeholders • classify use cases • apply use cases to architecture • Select the right people to act as reviewers • experts (in this case architects) • external to the project (other LHC experiments, IT,..) • Provide documents to be reviewed • Materials that describe the architecture (component model, interface definition) • Rational behind key architectural decisions (e.g. transient/persistent, converters) • A ranking of the 5-10 most important requirements of the system • List of use cases • Project Plan • Result of evaluation should be made in a formal report (job of recorder)

12. Support for Implementation • Platforms: • WNT, Linux, IBM AIX, HP-UX • Tools and Libraries: