1. Subject Slide 1 Roundtable on Software Process Input from LHCb

2. Subject Slide 2 Key features of our development process qAn 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 qThe 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” qThe 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 qAll architectural features and design criteria are captured in the Architecture Design document

3. Subject Slide 3 Key features of our development process - 2 qThe 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 qEffective use of object-oriented modeling and coding guidelines qFormal training programme dedicated to LHCb members ãLHCb OO A&D course - ~50 people (+ Paul Kunz’ C++ for Physicists course) qConfiguration 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) qThe application of an iterative and incremental development life-cycle ãFeedback from users at each stage. ãSet priorities for what the following release should contain qReviews 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. Subject Slide 4 What we have still to do... qWe 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, …. qWe anticipate that the development team must have specialists in each of these fields

5. Supplementary slides giving more details

6. Subject Slide 6 Process for Organising Software Development Activities Manage Plan, initiate, track, coordinate Set priorities and schedules, resolve conflicts 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 Build Develop models, Evaluate toolkits Architect components and systems Choose integration standard Engineer reusable components

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

8. Subject Slide 8 Development Cycle - status qSept 98 - architect appointed, design team of 6 people assembled qNov 25 ’98 - 1- day architecture review ãgoals, architecture design document, URD, scenarios ãchair, recorder, architect, external reviewers qFeb 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) qMay 30 ‘99 - GAUDI second release ãsecond software week… ãplan for third release ãexpand GAUDI team to cover new domains (GEANT4 simulation toolkit) qNov ‘ 99 - next GAUDI release and software week planned

9. Subject Slide 9 Development Cycle 1998200420022000 Major project reviews. Possibility of changing the direction Incremental releases Final system

10. Subject Slide 10 Goals of the Architecture Review (26.11.98) qForces us to document the architecture. qEvaluate early before it becomes a blueprint for the software. qPoint out places where it fails to meet requirements and show alternative designs. qValidate de requirements. qDetermine where finer-grain depictions are needed. qEnsure consistency across entire system. qDisseminate ideas on what constitutes a good architecture. qDetermine whether can proceed to next stage of development. qFollow-up.

11. Subject Slide 11 Review Process qWe followed Software Architecture Analysis Method (SAAM) ãdevelop use cases by questioning stakeholders ãclassify use cases ãapply use cases to architecture qSelect the right people to act as reviewers ãexperts (in this case architects) ãexternal to the project (other LHC experiments, IT,..) qProvide 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 qResult of evaluation should be made in a formal report (job of recorder)

12. Subject Slide 12 Support for Implementation qPlatforms: ãWNT, Linux, IBM AIX, HP-UX qTools and Libraries: