1. Software Process Or how to make strength productive Tools Requirements Management Visual Modeling Test coverage and metrics Change Management Requirements Management Visual Modeling Test coverage and metrics Change Management Manage Requirements Develop Iteratively Use Component Architectures Notation for Designing Verify Quality Control Changes Best Practices Best Practices Johannes Peter Wellisch, CERN/EP

2. The Problem Software in HEP: u Increasingly more mission critical u Needs to be of higher quality u Needs to be used while being developed But... “We estimate only 26% of software projects will succeed.” Standish Group CHAOS Report 1998

3. Symptoms of Software Problems  Misinterpreted needs  Hard to maintain and extend  Unable to deal with changing constraints  Modules don’t fit together  Poor design and software quality  Unacceptable performance  Discover design flaws too late  Can’t reconstruct who changed what, when, why  Unreliable build-and-release process

4. Root Causes of Software Problems  Insufficient requirements management  Ambiguous and imprecise communications  Brittle architectures  Overwhelming complexity  Undetected inconsistencies among requirements, designs, and code  Inadequate testing  Inadequate training  Subjective project status assessment  Delayed risk reduction due to waterfall development  Uncontrolled change propagation  Insufficient automation

5. Symptoms needs not met requirements churn modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Treating Symptoms Doesn’t Solve the Problem Diagnose

6. Best Practices Addressing Root Causes Eliminates the Problems Develop Iteratively Manage Requirements Use Component Architectures Common notation Verify Quality Control Changes Best Practices Best Practices Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Symptoms needs not met requirements churn modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release

7. Software is a job for Teams Project Manager/ Physicist Release Engineer Analyst/ Physicist Developer/ Physicist Tester/ Physicist Challenges Large teams and time sharing Need for Specialization Distribution Rapid technology change Process Manager/ Physicist

8. Without continuous improvement and agreed-on processes, parallel development degrades to chaos! The Challenge:  Multiple developers  Multiple teams  Multiple sites  Multiple iterations  Multiple releases  Multiple projects  Multiple platforms

9. Software Processes are An organized and documented set of principles, methods and procedures that aim at increased quality and productivity of software development.

10. Processes Enable Teams:  Result:  On Time  Predictable Resources  We Get What We Need Project Manager Performance Engineer Release Engineer AnalystDeveloperTester Best Practices Best Practices Manage Requirements Develop iteratively Design Notation Use Component Architectures Monitor Quality Control Changes