1. Watts Humphrey IBM director of programming and vice-president of technical development Joined CMU Software Engineering Institute in 1986 Initiator and lead developer of CMM, PSP, TSP Recipient of national medal of technology “Father of software quality”

2. Process What to do at each step – Waterfall – Unified Process – Agile (XP, Scrum) How to do it – Capability Maturity Model (CMM) – Personal Software Process (PSP) – Team Software Process (TSP)

3. Measurement-based learning process of self improvement in developing software customized for personal conditions PSP – individual engineer level TSP – team level CMM – management level Measure the process, not the product

4. CMM Originally assessment procedure to allow DoD to screen contractors 1980s—1990s: Developed into a general framework for quality certification – Define 5 maturity levels 2000s: evolved into CMMI – General management processes in development, services, and acquisitions – Not only for software but all areas of industry

5. 1.Initial: code and test w/o planning; hacking …Add basic management control over commitments… 2.Repeatable: record costs and enable estimates; have QA group, regression tests …Add general process definition and SE methodologies… 3.Defined: known procedures used, reviews, training; no compromising during crisis …Add process measurement and save data… 4.Managed: based on cost/benefit analysis, projections, applied to projects …Add process control and continuous adjustments… 5.Optimizing: informed use of resources and new technology to improve process

6. Nuances Measurement is not used for ranking – Goal is good data about project/process – Using it for ranking will lead to bad data Discipline, not regimentation – Prescribe procedures for how things are done – Reduce friction and waste – Don’t dictate what to do, don’t reduce creativity – Creativity ≠ anarchy

7. https://sas.cmmiinstitute.com/pars/pars.aspx

11. PSP Personal perspective of improvement a-la CMM – Can be done by individuals – Not dependent on CMM environment Make the routine work more predictable and efficient Customizable per individual Customizable with time as an individual’s capabilities improve Watts S. Humphrey / A Discipline for Software Engineering, Addison-Wesley 1995

12. PSP0 Use whatever work habits you have Collect data about how you perform “If you don’t know what you are doing, it is hard to improve it” Use detailed predefined forms – Filling form is easier than starting from scratch – Annoying but worth it on the long run – Form structure may be customized later

13. Side effect: discover how much you are interrupted and the benefits of reducing interruptions Time recording log

14. Defect recording log

15. Project plan summary

16. PSP1 Develop personal planning process Size estimation Test report Required basis: – Coding standard – Precise size measurements Outcomes: – Task planning – Schedule planning Understand relationship between size and required time Make commitments you can meet

17. Project loop Multi-project self improve- ment loop

18. Size The basic metric is KLoC But with important consistency constraints – One developer – Same language (or separate counts per language) – Same purpose (or separate counts for project, test, etc.) Well-defined standard of how to count – Braces, empty lines, comments…

19. PROxy-Based Estimation (PROBE) Identify objects based on conceptual design Find proxies for objects in historical database Estimate total object LoC based on these proxies – Use log-normal object size categories Use linear regression to estimate total program LoC and range based on objects LoC

20. Improvement Estimates always fluctuate and have errors – Natural variability and lack of information – Builtin bias By independently estimating small components and summing, variability is reduced  Better precision This makes it easier to identify and correct bias  Better accuracy

21. Schedule Use regression of historical data on estimated size and actual time – This is productivity = LoC / hour – Regression allows for better prediction than average, plus expected range Distinguish productivity on new code, modified code, and reused code Track actual productivity and adjust prediction – Alert management of change

22. PSP2 Develop personal quality management process Code reviews Design reviews Including personal reviews More effective than testing – When faced with a bug, need to find logical cause – In reviews you start with the logic

23. PSP3 Previous stages used small programs for learning – Linear waterfall-like phases Not suitable for large programs Final stage is to develop a personal cyclic development process Basic idea: partition into iterations that can be handled using PSP2

24. TSP PSP is a personal process Maximal project size is limited Need a team process to build larger projects TSP designed for engineers with PSP training Basically an iterative process – Cycle of 3-4 months – Structured launch (re-launch) to plan the cycle – Tracking and monitoring to ensure plan is followed

25. Summary PSP is hard work – Tedious monitoring and filling forms – Requires significant self-discipline – Takes long time to show returns on investment Provides professional confidence “Takes the creative fun out of software development”???  Humphrey: on the contrary! Makes the routine part efficient leaving more time for creative fun