software quality management and process improvement cs 123/cs 231

Software Quality Managementand Process Improvement

CS 123/CS 231

Software Quality

Quality ManagementChapter 30 of Sommerville book

Process ImprovementChapter 31 of Sommerville bookChapter 2 of Pressman book

Process vs Product Quality

Process Quality directly affects Product Quality

Should measure both product and process

Standardsdefine characteristics that all product

components should exhibitdefine how the software process should be

conducted

Standards (Example)

Product

Design review formDocument namingProcedure headersProgramming styleChange request

form

Process

Design review conduct

Document submission

Version releaseChange controlTest recording

Metrics

Software metrictype of measurement that relates to a

system, process, related documentationExamples

lines of codeFog index--readability of a manualnumber of reported faults

Process Improvement

DefinitionUnderstanding existing processes and

changing these processes to improve quality and/or reduce cost and development time

Process Improvement Process (iterative)analyze processidentify improvementsintroduce change, train personnel, fine-tune

The SEI CMM

Capability Maturity Model (CMM)defines levels of maturity of software

processesSee Section 31.4Initiated by the Software Engineering

Institute (SEI)for the US Dept of Defensegoal: assess capability of contractors

Five CMM Levels

Initial Levelno effective formal processessuccess dependent on individual capability

Repeatable Levelsome formal processes existcan successfully repeat projects of the

same typeno formal process model

CMM Levels, continued

Defined Levelformal process model existsconscious of process improvement

Managed Levelquantitative measuresprocess improvement based on metrics

Optimizing Leveldeliberate, continuing process improvement

Testing

CS 123/CS 231

References

Debugging and TestingReiss, Chapter 8

Verification and ValidationSommerville, Chapters 22-24

Debugging & Testing: Definitions

Buga defect or error in a program

Testingrunning a program with the intent of

finding bugs (defect testing)Debugging

determining the exact nature of a bug

Types of Bugs

Syntactic Bugssyntax errors, typos

Design BugsLogic BugsInterface Bugs

method invocation versus definitionMemory Bugs

Steps in Debugging

Locating the problem/causethe more difficult step (in general)use inductive/deductive reasoning

Repairing the problemif design bug, consequences are often

extensivenote that solution may result in more bugsregression testing

Defensive Design

Simplicityin class interfacesin algorithms

Encapsulationminimizes coupling; increased correlation

between locations of error and causeError-handling

design with error in mind

Defensive Coding

Writing code to simplify debuggingWhat to watch out for:

initializationmethod preconditions (check for valid

parameter values) and return value casescomplex code / bug “history”

Language supportassertions (in C,C++ - assert.h), exceptions

Reviews

Particularly for large projects with several designers and programmers involved

Design Reviewpresentation to other developers,

stakeholders, and outside consultantsbrings out other, external perspectives

Code Reviewwalk through your code, line by line

Debugging Tools

Controlling executionbreakpoints, tracepoints, watchpointssingle-step execution

Observing executionwatches (displays)view execution stack, view memory

Alternative: inserting print statements (!)

Testing

May be performed at different levelsStatic Testing

testing without program executioncode review, inspection, walkthrough

Dynamic Testingmodule testing, integration testingsystem/regression testingblack-box vs white-box testing

Stages in the Testing Process

Unit TestingModule TestingSub-System TestingSystem/Integration TestingAcceptance Testing

Testing Strategies

Top-down testingBottom-up testingThread-testingStress testingBack-to-back testing

How to Test

Devise Test Planclear/consistent procedure/standards for

testing a systemIdentify Test Cases

thorough listing of possible inputsinclude boundaries, invalid/unexpected inputs

Implement the Testwrite test code (test drivers), use testing tools

Test Cases

Equivalence Partitioningpartition input (& output) into classes that

are processed equivalently by the programTest Case Guidelines

Example: for arrays, consider varying sizes, test for first, middle, and last element

Path Testingbased on possible execution paths; white-

box