Software Quality 101

1
Software Quality 101

• Mark Carroll
• President
• Software Quality New Zealand

2
About todays talk

• What is Software Quality ?
• What are some of the cornerstones of Software
  Quality and related disciplines Requirements,
  Process, Supporting Technologies
• How can you learn more about software quality

3
What is Software Quality
From Carnegie Mellon Software Engineering
Institute

• The principal focus of any software quality
  definition should be the users' needs. Crosby
  defines quality as "conformance to requirements."
  Crosby While one can debate the distinction
  between requirements, needs, and wants, quality
  definitions must consider the users'
  perspectives. The key questions then are who are
  the users, what is important to them, and how do
  their priorities relate to the way you build,
  package, and support your products?

4
Requirements
Requirements
Functional Requirements
Non Functional Requirements
Requirements Management
Usability
Requirements analysis Requirements
definition Requirements Acceptance
Supportability
Performance
Supportability
Testing
Variance Remediation Conformance
5
Requirements
These requirements need just as much managing as
User requirements do !
A major challenge not to be under-estimated a
specialised discipline !
Requirements
Functional Requirements
Non Functional Requirements
Requirements Management
Usability
Requirements analysis Requirements
definition Requirements Acceptance
Supportability
Need to be surfaced with the Sponsor EARLY !
Performance
Supportability
Testing
Variance Remediation Conformance
Note this link ! Ignore at your peril
6
Requirements Some thoughts

• Requirements are only a temporary proxy for the
  real world problem
• Requirements are specifications Executables are
  implementations
• Requirements can either be a description of the
  problem or a description of the solution
  both viewpoints are valid

7
Non-Functional requirements

• Usability
• Measure of how well the software supports the
  execution of user tasks
• Affordance
• Cost of learning to be productive with a user
  interface
• Accessibility
• Measure of how broad a pool of users can interact
  effectively with the user interface

8
Non-Functional requirements

• Reliability
• Measure of the frequency and severity of defects
  encountered in normal operation
• Fault tolerance
• How well the system can maintain normal operation
  when defects are encountered
• Robustness
• How well the system avoids failures when
  confronted with invalid data or incorrect usage
• Security
• How well the system avoids unauthorised exposure
  of the processes and entities manipulated by the
  system

9
Non-Functional requirements

• Performance
• How quickly does the system respond to stimuli
  and how well does it utilize resources when
  responding
• Latency
• Amount of time that elapses in performing a given
  operation under a given operating load
• Throughput
• How many operations can be performed in a given
  amount of time under a given operating load
• Efficiency
• Measure of how many resources must be consumed to
  provide acceptable latency throughput
• Scalability
• Measure of how many additional resources must be
  consumed to provide acceptable latency
  throughput with increasing load

10
Non-Functional requirements

• Supportability - Structural
• Cost of supporting structural integrity and
  implementing change
• Maintainability
• How easy is it to correct defects in the software
  often determined by cohesion and
  localisation of features
• Malleability
• How easy is it to modify the software to
  accommodate changes in requirements cohesion
  and localisation once again play a part in this
• Extensibility
• Ease of replacing existing parts of Software and
  ease of adding new functionality often
  determined primarily by degree of coupling
  among the components

11
Non-Functional requirements

• Supportability Interaction platform
• Cost of supporting structural integrity and
  implementing change
• Portability
• How easy is it to adapt the software to run on
  different platforms
• Interoperability
• How easy is it to compose the software with
  other systems
• Testability
• How easy is it to design and implement tests that
  exercise features of the software

12
Process
Booch a formal process prescribes

• Activities generally performed in the course of
  developing software
• Skills generally required to perform them
• Order in which they must generally be performed
• The artifacts they consume and produce
• The criteria for measuring and evaluating the way
  they are performed

13
Process Formal less-Formal

• But there are recognised processes that are not
  so formal and that have produced good results
  for some
• Agile Development
• Iterative Development
• Between Formal processes (e.g. UP) and the more
  informal (e.g. Agile) there is a continuum which
  we describe in terms of formalism
• There are many views as to which is the most
  appropriate to given situations care should be
  taken when evaluating these processes and their
  suitability for adoption as both reference
  standards and for use by each individual project

14
Process - Teams

• When models and source code are edited
  independently by multiple developers complex
  synchronisation issues can arise
• This is independent of the degree of formality
  of your process basis
• The problem is exponential based on the number of
  developers involved the number of potential
  developer based conflicts can be expressed as
  BUT use the same formula again to
  factor what is being worked on and the number
  increases exponentially again. Turnaround has a
  major impact !

n2 n 2
15
Process Standards developments

• ISO/IEC 15504 is an emerging international
  standard for process assessment that has been
  under development since June 1993 under the
  auspices of the International Organization for
  Standardization and the International
  Electrotechnical Commission (ISO/IEC).
• ISO/IEC 15504 is an independent effort by
  ISO/IEC. It was inspired by the Software CMM and
  ISO 9001, but the purpose of 15504 is to
  harmonize a number of different models (including
  the Software CMM, CMMI, ISO 9001, ISO 12207,
  Trillium, Software Technology Diagnostic, and
  Bootstrap) and assessment methods (including CBA
  IPI, SCE 3.0, Bootstrap, and SCAMPI).
• Expected 2006

Source Carnegie Mellon Software Engineering
Institute
16
Technologies

• The technologies that support requirements
  management and process including testing
• There is an array of offerings from a number of
  vendors
• Varying degrees of automation and integration
  when servicing requirements through build through
  test through implementation
• Debate over standards and approaches creates
  variety in technology offerings

17
Technology - Directions

• Change Is in the Air
• In looking across the many companies developing
  tools and products for application developers,
  one thing is clear. Change is in the air. The
  focus is turning from building tools for the
  various tasks in the application life cycle and
  is now moving towards providing tools for the
  different roles for building business solutions.
  It is a subtle difference, but a difference
  nonetheless.

Source Developer.com http//www.developer.com/db/
article.php/34661
18
Key Drivers for technology and related
architecturedecision making
Tangible Costs
Life Expectancy
Skills Availability
Third Party Product Services availability
Timeliness
Standards Methodology fit
User Functionality requirements
Customer requirements
19
Tangible Costs
Life Expectancy
Skills Availability
Third Party Product Services availability
Timeliness
Standards Methodology fit
User Functionality requirements
Customer requirements
20
To sum up .

• Frog and fly

21
To sum up .

• The brain behind all this is your professional
  skill and judgement

Requirements
Process
Technology
22
How can you learn more about Software Quality

• www.sqnz.org.nz
• Zahran Software Process Improvement
  Addison-Wesley
• Software Factories Greenfield, Short, Cook,
  Kent Wiley
• Requirements Analysis David C Hay Prentice Hall
• Keep track of SQNZ sessions, join SQNZ as an
  individual or as a corporate member

23
Call to action

• Check out one or more of the sources I discussed
  on the previous slide
• Learn to articulate why Software Quality is
  important
• Consider an audit that benchmarks against a given
  set of criteria for example CMM