F. P. Brooks, “No Silver Bullet - Essence and Accidents of Software Engineering”,

1. F. P. Brooks, “No Silver Bullet - Essence and Accidents of Software Engineering”, IEEE Computer 20(4):10-19, April, 1987 As we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. ... Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any - no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years. ... Although we see no startling breakthroughs - and indeed, I believe such to be inconsistent with the nature of software - many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road.

2. Experience with Software Process in Physics Experiments S. Guatelli, B. Mascialino, L. Moneta, I. Papadopoulos, A. Pfeiffer, M.G. Pia, M. Piergentili CERN - INFN Genova Monte Carlo 2005 Topical Meeting Chattanooga, April 2005

3. Challenges Mission critical applications Complexity of physics and experiments Geographically distributed teams and computing resources Quality and reliability for sensitive applications

4. Trends in software engineering Shift attention from computing technology to software process as the way to achieve quality, lower costs Develop a discipline for software engineering Define quantitative standards to evaluate software capability maturity: SEI’s Software Capability Maturity Model ISO 15504 • The culture of software process is not widely spread in the physics research environment yet • Software is still perceived as “writing code” • The success of software projects is mainly left to individual efforts (CMM: “heroic”, level 1) Widely used in software industry

5. Process framework Based on the Unified Process(Booch, Jacobson and Rumbaugh) Rational Unified Process: UP + practical guidance and tools Equivalent to CMM / ISO 15504 Level 3 at least An incrementaland iterative software life-cycle Customized to the specific development environment

6. Projects adopting the RUP • Pilot project: Anaphe (Data Analysis Tools project, CERN/IT Division) • a playground to learn the RUP and to adapt it to the physics research environment RUP in projects • Geant4 Low Energy Electromagnetic Physics • Geant4 Electromagnetic Physics Validation Project • Statistical Toolkit • Brachytherapy Simulation & Dosimetry • IMRT Geant4-based Dosimetry System • REMSIM Simulation (radioprotection, Aurora Programme) • Bepi Colombo Simulation (planetary astrophysics) • Solar System Radiation Environment Generator RUP in an organization (encompassing several projects) • Geant4 Advanced Examples (in progress)

7. Guidelines for process tailoring • Retain all the best practices suggested by the RUP • Iterative development • Management of the requirements • Component-based architecture • Visual modeling with UML • Continuously verify quality • Change management • Identify essential activities, artifacts and key roles • for every RUP activity: is it justified in our environment? What are the benefits? How much does it cost? • Justify all artifacts to be produced in relation to the project objectives

8. A minimal subset identified within the large set of RUP artifacts Essential artifacts Vision Risk List Development Plan Development Case CVS repository User Requirements Architecture Model Design Model Test Plan Test Suite Prototype Tools Guidelines The system Documentation The product Release Notes Training Material + refinement of artifacts from previous phases + refinement of artifacts from previous phases Other optional artifacts may be produced in some projects + refinement of artifacts from previous phase …much more than just the code!

9. Quantitative process control Objective evaluations are the key to software process improvement Metrics

10. Some metrics • 95% projects delivered on time, on budget and with all the features originally planned • CHAOS Report 2000 (Standish Group): • 28% software projects failed • 49% challenged • 23% successful • 5% failure due to neglect of applying the process • no way to enforce the application of the process onto independent researchers

11. A case study • Development of simulation + analysis of a dosimetric system for IMRT • Software requirements: functionality + high quality for medical application • Master thesis work, duration: 1 year • Manpower: 1 developer + 1 process specialist • Developer: no prior software knowledge • Results • on-time delivery of code, documentation, physics results • all high and medium priority requirements satisfied • ~30 billion simulation events produced and analysed • high quality physics results from the software (paper in IEEE-NSS 2004) • 355 page MSc. thesis • fraction of code discarded during the development period: 0 D = 0.005; p-value = 1

12. Conclusion • A rigorous software process is the key technology enabling development teams to achieve success • The RUP can be effectively adapted to the peculiar physics research environment • a powerful, but flexible process framework • A RUP-based software process has been adopted by several physics projects in may research fields (fundamental physics, space science, astrophysics, medical physics, statistics) • Success rate is 95% (to be compared to CHAOS 23%)