Thursday, August 12, 2010

Six Sigma Control in Software Development - Software Test Professionals - Testing, Quality Assurance, and People

Controls in Software Code
We can help ourselves by performing a set of behaviors designed to reduce or eliminate the anticipated relapse:

  • Code reviews
  • Code inspections
  • Code walkthroughs
  • Configuration Reviews
  • Static analyzers
  • Dynamic analyzers
  • White-box testing
  • Black-box testing
  • Coding standards
  • Practicing safe coding

The four sub-controls that are part of configuration management are:
  • Configuration identification, wherein we give a name to the components with which we are working
  • Configuration control, sometimes the most intense and expensive part of the process (and most lacking)
  • Configuration status accounting, where we give ourselves regular reports about topics of interest in the system
  • Configuration auditing, where we verify that our software function to requirements (functional configuration audit or FCA) and our documentation is correct (physical configuration audit or PCA)
Software configuration management systems are generally computer-controlled these days with well-known open source tools like Revision Control System (RCS), Concurrent Versions System (CVS), and subversion.

Controls in Software Development
We can improve our process by adding the necessary controls to the stages of the process, for example:

  • Lessons learned data base
  • Failure mode and effects analysis on the process
  • Process control plan
  • Production software approval process
  • Meaningful metrics and periodic presentations
  • Defect density tracking
  • Severity assessments
  • Institutionalization of desired behaviors
  • Regular training/indoctrination
  • Design methodologies
  • Model-based design
  • Functional coding

The Process Control Plan is a tool used in the automotive, food, and pharmaceutical industries as a means for documenting the steps of the process, associated metrics and requirements, key process characteristics, and reaction plans.

Another automotive tool is the Production Part Approval Process (PPAP), which includes a minimum of eighteen documents that support a product release.We recommend the implementation of a software analog called the Production Software Approval Process (PSAP).

The PSAP would provide for collection of softwaresignificant documents.
For example, one approach might include:

  • The original customer specification if one exists
  • The software development plan
  • Software test plans
  • An operational concept description or concept document
  • System/subsystem specifications
  • Software requirements specifications
  • Interface requirements specifications
  • System/subsystem design descriptions
  • Software design descriptions
  • Interface design descriptions
  • Database design descriptions
  • Software test descriptions
  • Software test report
  • Software product specifications, which might include the executable software, the source files, and information to be used for support
  • Software version descriptions for each variant of the software release as it evolves
  • Firmware support manual for embedded software

We use severity assessments as part of a risk mitigation activity. The approach is straightforward: we assess the severity of each function by the amount of damage the function can do if it does not behave correctly.
The malfunctions include:

  • Too much of a given behavior
  • Too little l Static behavior (lockup)
  • Periodic unexpected behavior
  • Aperiodic (random) unexpected behavior
  • No behavior (no startup)

Six Sigma Control in Software Development - Software Test Professionals - Testing, Quality Assurance, and People

No comments: