Beyond Process
A Challenge for SPINs
Dr. Bill Curtis
Executive Director Emeritus, CISQ
International Standards for
Automating Software Size and
Structural Quality Measurement
SPINCON
April 20, 2019
© 2018 Consortium for IT Software Quality (CISQ) www.it-cisq.org 2
5th Wave in Software Engineering
What: 3rd & 4th generation languages, structured programming
When: 1965-1980
Why: Give developers greater power for expressing programsLanguage
1
What: Design methods, CASE tools
When: 1980-1990
Why: Give developers better aids to construct systemsMethod
2
What: CMM, ITIL, PMBOK, Agile
When: 1990-2002
Why: Improve software management and disciplineProcess
3
What: Architecture, Structural measures, Reuse
When: 2002
Why: Improve engineering of software productsProduct
4
What: Industrialize, DevOps, Value chain
When: 2015
Why: Increase efficiency, speed of deliveryAutomation
5
© 2018 Consortium for IT Software Quality (CISQ) www.it-cisq.org 3
Six Sigma’s Progression
Process focus – process improvement – Six Sigma
Product focus – product improvement – Design for
6
Six Sigma projects must have significant benefits
Huge benefits
Large benefits
Good benefits
Okay benefits
Small benefits
Now what?
Ultimately we run out of projects
with enough benefits to continue
the program….
How do we continue
improvement?
© 2018 Consortium for IT Software Quality (CISQ) www.it-cisq.org 4
CISQ Automates Measurement of the Software
CISQ Sponsors
CISQ Partners
CISQ
Co-founders
Dr. Paul
Nielsen, CEO
Dr. Richard
Soley, CEO
Develop software product measurement standards
approved by OMG, some fast-tracked to ISO
EffortStructural QualitySize
Technical DebtAutomated
Function
Points
Automated
Enhancement
Points
Security
Reliability
Performance Efficiency
Maintainability
© 2018 Consortium for IT Software Quality (CISQ) www.it-cisq.org 5
Y = a1x1 = a2x2 + 

DPMO Hotspots
Y = a1x1 = a2x2 + 

DPMO Hotspots
Y = a1x1 = a2x2 + 

DPMO Hotspots
Y = a1x1 = a2x2 + 

DPMO Hotspots
Structural Quality Measures  Level 4 Optimization
CISQ Structural Quality Measures
Security
• SQL injection
• Cross-site scripting
• Buffer overflow
Reliability
• Empty exception block
• Unreleased resources
• Circular dependency
Performance
Efficiency
• Expensive loop operation
• Un-indexed data access
• Unreleased memory
Maintainability
• Excessive coupling
• Dead code
• Hard-coded literals
© 2018 Consortium for IT Software Quality (CISQ) www.it-cisq.org 6
Trustworthy Systems Manifesto
1. Engineering discipline in product and
process
2. Quality assurance to risk tolerance
thresholds
3. Traceable properties of system
components
4. Proactive defense of the system and its
data
5. Resilient and safe operations
www.it-cisq.org
Free membership

Bill curtis Beyond process - a challenge for SEPGs

  • 1.
    Beyond Process A Challengefor SPINs Dr. Bill Curtis Executive Director Emeritus, CISQ International Standards for Automating Software Size and Structural Quality Measurement SPINCON April 20, 2019
  • 2.
    © 2018 Consortiumfor IT Software Quality (CISQ) www.it-cisq.org 2 5th Wave in Software Engineering What: 3rd & 4th generation languages, structured programming When: 1965-1980 Why: Give developers greater power for expressing programsLanguage 1 What: Design methods, CASE tools When: 1980-1990 Why: Give developers better aids to construct systemsMethod 2 What: CMM, ITIL, PMBOK, Agile When: 1990-2002 Why: Improve software management and disciplineProcess 3 What: Architecture, Structural measures, Reuse When: 2002 Why: Improve engineering of software productsProduct 4 What: Industrialize, DevOps, Value chain When: 2015 Why: Increase efficiency, speed of deliveryAutomation 5
  • 3.
    © 2018 Consortiumfor IT Software Quality (CISQ) www.it-cisq.org 3 Six Sigma’s Progression Process focus – process improvement – Six Sigma Product focus – product improvement – Design for 6 Six Sigma projects must have significant benefits Huge benefits Large benefits Good benefits Okay benefits Small benefits Now what? Ultimately we run out of projects with enough benefits to continue the program…. How do we continue improvement?
  • 4.
    © 2018 Consortiumfor IT Software Quality (CISQ) www.it-cisq.org 4 CISQ Automates Measurement of the Software CISQ Sponsors CISQ Partners CISQ Co-founders Dr. Paul Nielsen, CEO Dr. Richard Soley, CEO Develop software product measurement standards approved by OMG, some fast-tracked to ISO EffortStructural QualitySize Technical DebtAutomated Function Points Automated Enhancement Points Security Reliability Performance Efficiency Maintainability
  • 5.
    © 2018 Consortiumfor IT Software Quality (CISQ) www.it-cisq.org 5 Y = a1x1 = a2x2 +   DPMO Hotspots Y = a1x1 = a2x2 +   DPMO Hotspots Y = a1x1 = a2x2 +   DPMO Hotspots Y = a1x1 = a2x2 +   DPMO Hotspots Structural Quality Measures  Level 4 Optimization CISQ Structural Quality Measures Security • SQL injection • Cross-site scripting • Buffer overflow Reliability • Empty exception block • Unreleased resources • Circular dependency Performance Efficiency • Expensive loop operation • Un-indexed data access • Unreleased memory Maintainability • Excessive coupling • Dead code • Hard-coded literals
  • 6.
    © 2018 Consortiumfor IT Software Quality (CISQ) www.it-cisq.org 6 Trustworthy Systems Manifesto 1. Engineering discipline in product and process 2. Quality assurance to risk tolerance thresholds 3. Traceable properties of system components 4. Proactive defense of the system and its data 5. Resilient and safe operations www.it-cisq.org Free membership

Editor's Notes

  • #2 Over the next half hour I will give you an overview of the automated size and structural quality measures developed by the Consortium for IT Software Quality (CISQ). These measures have been approved as international standards by the Object Management Group (OMG). CISQ fills a critical void since there are no other standards bodies developing standards for automating the measurement of size and quality from the source code of a software system. The CISQ standards provide a strong infrastructure of measures for assessing productivity and structural quality.
  • #5 CISQ was formed in 2010 when both the Software Engineering Institute at Carnegie Mellon University and OMG were approached by system integrators and asked to develop standards for measuring software attributes such as reliability and security. These attributes were appearing in contracts, but every customer had a different definition of how they were to be measured. SEI and OMG co-founded CISQ and asked Dr. Bill Curtis who had led development of the Capability Maturity Model (CMM) to lead it. Twenty-four companies joined to create the first round of measurement standards. CISQ is now a special interest group managed by OMG with 7 companies sponsoring CISQ’s activities. Membership in CISQ is free for individuals, and I will show you how to become involved later. CISQ also has 8 partners with which we cooperate.
  • #6 CISQ’s four structural quality characteristic measures are based on quantifying violations of good architectural and coding practice within a software system that can be detected through static analysis. Violations were included in each measure only if they were considered severe enough that they should be eliminated. Shown here are the number of violations included in each measure and three example violations. For instance, the Reliability measure consists of 29 violations that can cause outages or erratic behavior. Examples include empty exception blocks, unreleased resources, and circular dependencies. Most measures of Reliability assess system availability or downtime which are behavioral measures. The CISQ measures assess actual flaws in the software that can cause operational problems. Thus, the CISQ measures provide pre-release indicators operational or cost of ownership risks.
  • #7 CISQ developed a Trustworthy Systems Manifesto to initiate a conversation between those who own the responsibility for managing risks to the enterprise, and those who are developing, deploying, and operating one of, if not the largest source of risk, software-intensive systems. Since corporate executives and risk officers are rarely experts in software, the manifesto states 5 principles that the enterprise should expect software development and maintenance staff to embrace. Each principle is elaborated with guidance written to aid non-IT executives in communicating their expectations. If executives track how IT is implementing these principles, they have evidence that they are addressing a critical source of risk and thereby executing their governance responsibilities. CISQ is encouraging executives to sign the manifesto and use it discuss risk management with those responsible for corporate software-intensive systems regardless of whether they are IT applications or product software.