1 / 23

Software Quality Management and Process Improvement

Software Quality Management and Process Improvement. CS 123/CS 231. Software Quality. Quality Management Chapter 30 of Sommerville book Process Improvement Chapter 31 of Sommerville book Chapter 2 of Pressman book. Process vs Product Quality.

camille-stevens
Download Presentation

Software Quality Management and Process Improvement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Quality Managementand Process Improvement CS 123/CS 231

  2. Software Quality • Quality Management • Chapter 30 of Sommerville book • Process Improvement • Chapter 31 of Sommerville book • Chapter 2 of Pressman book

  3. Process vs Product Quality • Process Quality directly affects Product Quality • Should measure both product and process • Standards • define characteristics that all product components should exhibit • define how the software process should be conducted

  4. Product Design review form Document naming Procedure headers Programming style Change request form Process Design review conduct Document submission Version release Change control Test recording Standards (Example)

  5. Metrics • Software metric • type of measurement that relates to a system, process, related documentation • Examples • lines of code • Fog index--readability of a manual • number of reported faults

  6. Process Improvement • Definition • Understanding existing processes and changing these processes to improve quality and/or reduce cost and development time • Process Improvement Process (iterative) • analyze process • identify improvements • introduce change, train personnel, fine-tune

  7. The SEI CMM • Capability Maturity Model (CMM) • defines levels of maturity of software processes • See Section 31.4 • Initiated by the Software Engineering Institute (SEI) • for the US Dept of Defense • goal: assess capability of contractors

  8. Five CMM Levels • Initial Level • no effective formal processes • success dependent on individual capability • Repeatable Level • some formal processes exist • can successfully repeat projects of the same type • no formal process model

  9. CMM Levels, continued • Defined Level • formal process model exists • conscious of process improvement • Managed Level • quantitative measures • process improvement based on metrics • Optimizing Level • deliberate, continuing process improvement

  10. Testing CS 123/CS 231

  11. References • Debugging and Testing • Reiss, Chapter 8 • Verification and Validation • Sommerville, Chapters 22-24

  12. Debugging & Testing: Definitions • Bug • a defect or error in a program • Testing • running a program with the intent of finding bugs (defect testing) • Debugging • determining the exact nature of a bug

  13. Types of Bugs • Syntactic Bugs • syntax errors, typos • Design Bugs • Logic Bugs • Interface Bugs • method invocation versus definition • Memory Bugs

  14. Steps in Debugging • Locating the problem/cause • the more difficult step (in general) • use inductive/deductive reasoning • Repairing the problem • if design bug, consequences are often extensive • note that solution may result in more bugs • regression testing

  15. Defensive Design • Simplicity • in class interfaces • in algorithms • Encapsulation • minimizes coupling; increased correlation between locations of error and cause • Error-handling • design with error in mind

  16. Defensive Coding • Writing code to simplify debugging • What to watch out for: • initialization • method preconditions (check for valid parameter values) and return value cases • complex code / bug “history” • Language support • assertions (in C,C++ - assert.h), exceptions

  17. Reviews • Particularly for large projects with several designers and programmers involved • Design Review • presentation to other developers, stakeholders, and outside consultants • brings out other, external perspectives • Code Review • walk through your code, line by line

  18. Debugging Tools • Controlling execution • breakpoints, tracepoints, watchpoints • single-step execution • Observing execution • watches (displays) • view execution stack, view memory • Alternative: inserting print statements (!)

  19. Testing • May be performed at different levels • Static Testing • testing without program execution • code review, inspection, walkthrough • Dynamic Testing • module testing, integration testing • system/regression testing • black-box vs white-box testing

  20. Stages in the Testing Process • Unit Testing • Module Testing • Sub-System Testing • System/Integration Testing • Acceptance Testing

  21. Testing Strategies • Top-down testing • Bottom-up testing • Thread-testing • Stress testing • Back-to-back testing

  22. How to Test • Devise Test Plan • clear/consistent procedure/standards for testing a system • Identify Test Cases • thorough listing of possible inputs • include boundaries, invalid/unexpected inputs • Implement the Test • write test code (test drivers), use testing tools

  23. Test Cases • Equivalence Partitioning • partition input (& output) into classes that are processed equivalently by the program • Test Case Guidelines • Example: for arrays, consider varying sizes, test for first, middle, and last element • Path Testing • based on possible execution paths; white-box

More Related