Software Quality Management and Process Improvement
-
Upload
camille-stevens -
Category
Documents
-
view
23 -
download
5
description
Transcript of Software Quality Management and Process Improvement
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