Bill curtis Beyond process - a challenge for SEPGs
•Download as PPTX, PDF•
0 likes•96 views
This document discusses the progression of software engineering approaches over 5 waves from programming languages to automation. It introduces CISQ's work to automate software measurement standards for effort, size, quality, and technical debt. CISQ aims to industrialize measurement to enable Level 4 optimization by identifying quality "hotspots". The document promotes a Trustworthy Systems Manifesto of engineering discipline, quality assurance, traceability, proactive defense, and resilience.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Bill curtis Beyond process - a challenge for SEPGs
Similar to Bill curtis Beyond process - a challenge for SEPGs (20)
More from SPIN Chennai
More from SPIN Chennai (20)
Recently uploaded
Recently uploaded (20)
Bill curtis Beyond process - a challenge for SEPGs
- 1. 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
- 2. © 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
- 3. © 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?
- 4. © 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
- 5. © 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
- 6. © 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
Editor's Notes
- 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.
- 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.
- 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.
- 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.