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”

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)

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

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 – Add people-CMM, later also DMM (data management maturity) – Not only for software but all areas of industry

1.Initial: code and test w/o planning; ad-hoc …Add management control and defined SE processes… 2.Managed: plan with stakeholders, provide resources, monitor execution milestones; no compromising during crisis …Add standards and apply across organization… 3.Defined: common processes tailored for each project’s needs; rigorous definition of processes …Add process measurement and analysis… 4.Quantitatively Managed: based on quantitative process/quality objectives; predictions …Add continuous adjustments across organization… 5.Optimizing: proactively fix performance gaps

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

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

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

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

Defect recording log

Project plan summary

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

Project loop Multi-project self improve- ment loop

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…

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

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

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

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

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

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

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