Quality - A Priority In Service Engagements


Published on

I made this presenation on Quality - in reference to Software Service Engagements - at Interra Bangalore in 2006

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Changed “during design, 1.5;” to “during design, 0.5;”
  • Quality - A Priority In Service Engagements

    1. 1. January 31, 2006 (Bangalore) Quality Priority in Service Engagements Dr. Partha Pratim Das Interra Systems (India) Pvt. Ltd.
    2. 2. Agenda <ul><li>Recap </li></ul><ul><ul><li>Organizational Objectives </li></ul></ul><ul><ul><li>Typical Work Cycle </li></ul></ul><ul><li>Quality </li></ul><ul><ul><li>What is Quality? </li></ul></ul><ul><ul><li>Why is Quality Significant? </li></ul></ul><ul><ul><li>Quality Perspectives </li></ul></ul><ul><ul><li>Interra Quality Plan </li></ul></ul><ul><li>Q & A </li></ul>
    3. 3. Organizational Objectives <ul><li>Increase Efficiency </li></ul><ul><li>Increase Effectiveness </li></ul>
    4. 4. Organizational Objectives <ul><li>Increase Efficiency </li></ul><ul><ul><li>Do things RIGHT </li></ul></ul><ul><ul><li>Lines of ‘quality’ code produced per man-hour </li></ul></ul><ul><ul><li>Instances of ‘quality’ support provided per man-week </li></ul></ul><ul><li>Increase Effectiveness </li></ul><ul><ul><li>Do RIGHT things </li></ul></ul><ul><ul><li>Lines of ‘quality’ code produced per dollar </li></ul></ul><ul><ul><li>Cost for every instance of support </li></ul></ul>
    5. 5. Typical Work Cycle <ul><li>A typical cycle can be </li></ul><ul><ul><li>Need  </li></ul></ul><ul><ul><li>Requirements  </li></ul></ul><ul><ul><li>Design  </li></ul></ul><ul><ul><li>Code / Perform  </li></ul></ul><ul><ul><li>QA  </li></ul></ul><ul><ul><li>QC </li></ul></ul>
    6. 6. What is Quality? <ul><li>A degree or grade of excellence or worth </li></ul><ul><ul><li>Dictionary Meaning </li></ul></ul><ul><li>Meeting and exceeding expectations </li></ul><ul><li>Quality is NOT Grade. Because </li></ul><ul><ul><li>Low Grade / High Quality </li></ul></ul><ul><ul><ul><li>Few features </li></ul></ul></ul><ul><ul><ul><li>No obvious bugs </li></ul></ul></ul><ul><ul><ul><li>Good Documentation </li></ul></ul></ul><ul><ul><li>Low Quality / High Grade </li></ul></ul><ul><ul><ul><li>Many bugs </li></ul></ul></ul><ul><ul><ul><li>Poor Documentation </li></ul></ul></ul><ul><ul><ul><li>Many features </li></ul></ul></ul>
    7. 7. What is Quality? <ul><li>“The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs” </li></ul><ul><ul><li>PMBOK, 2000. </li></ul></ul>“ Somewhere down the line, we need to stop and think what the customer actually wants - and what more we can do which would make a difference to their perception. . ” – Kousik Mukherjee, Dir. Of Engg,, Interractions Vol 4(3).
    8. 8. Why is Quality Significant? <ul><li>To meet specs </li></ul><ul><li>To meet targets </li></ul><ul><li>To pass acceptance tests </li></ul><ul><li>… </li></ul><ul><li>… </li></ul><ul><li>… </li></ul><ul><li>To be “efficient” and “effective” </li></ul>
    9. 9. Why is Quality Significant? <ul><li>Quality is the most important factor that </li></ul><ul><ul><li>determines the value of the product or the engineering solution </li></ul></ul><ul><ul><li>helps engage with a customer at an emotional level </li></ul></ul><ul><ul><ul><li>recommendations </li></ul></ul></ul><ul><ul><ul><li>repeat business </li></ul></ul></ul><ul><ul><li>drives business growth </li></ul></ul><ul><li>Quality is what distinguishes a good company from a great one. </li></ul>
    10. 10. Why is Quality Significant? <ul><li>&quot;Improvements in quality always and automatically result in </li></ul><ul><ul><li>reductions in schedules and costs, </li></ul></ul><ul><ul><li>increases in productivity, </li></ul></ul><ul><ul><li>increases in market share, and consequently </li></ul></ul><ul><ul><li>increases in profits.&quot; </li></ul></ul><ul><ul><ul><li>Out Of The Crisis, Dr. W. Edwards Deming, Cambridge: MIT Center for Advanced Engineering, 1986. </li></ul></ul></ul>
    11. 11. Quality Perspectives <ul><li>Notions in Quality Management </li></ul><ul><ul><li>Quality Planning </li></ul></ul><ul><ul><ul><li>Identifying which quality standards are relevant to the project and determining how to satisfy them </li></ul></ul></ul><ul><ul><li>Quality Assurance </li></ul></ul><ul><ul><ul><li>Evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards </li></ul></ul></ul><ul><ul><li>Quality Control </li></ul></ul><ul><ul><ul><li>Monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance </li></ul></ul></ul>
    12. 12. Quality Perspectives <ul><li>Quality Intervention at Various Stages </li></ul><ul><ul><li>Prevention at Origin </li></ul></ul><ul><ul><ul><li>Requirements / Design </li></ul></ul></ul><ul><ul><li>Containment by Appraisal / Review </li></ul></ul><ul><ul><ul><li>Spec Review, Design Review, Code Review </li></ul></ul></ul><ul><ul><li>Wake up after Internal Failures </li></ul></ul><ul><ul><ul><li>Unit Testing, Developer Testing, Regressions </li></ul></ul></ul><ul><ul><li>Fire Fight on External Failures </li></ul></ul><ul><ul><ul><li>Testing by Customer, At the field – after deployment </li></ul></ul></ul>
    13. 13. Quality Perspectives <ul><li>The Cost Of Fixing Defects </li></ul><ul><ul><li>An unpublished IBM rule of thumb for the relative costs: </li></ul></ul><ul><ul><ul><li>during design, 0.5; </li></ul></ul></ul><ul><ul><ul><li>prior to coding, 1; </li></ul></ul></ul><ul><ul><ul><li>during coding, 1.5; </li></ul></ul></ul><ul><ul><ul><li>prior to test, 10; </li></ul></ul></ul><ul><ul><ul><li>during test, 60; </li></ul></ul></ul><ul><ul><ul><li>in field use, 100. </li></ul></ul></ul>
    14. 14. Quality Perspectives <ul><li>The Cost Of Fixing Defects </li></ul><ul><ul><li>Remove as many defects as early in development as possible. </li></ul></ul><ul><ul><li>Remove as many defects as is reasonably possible before the delivery. </li></ul></ul>“ Bugs squashed early rarely threaten a project's deadline and budget.” – Scientific American, September 1994.
    15. 15. Quality Perspectives <ul><li>Product / Solution / Software Quality </li></ul><ul><ul><li>Usability. </li></ul></ul><ul><ul><ul><li>Is the product easy to learn and use? Does it require training and technical support before any productivity increases occur? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, ZenTime learning loops </li></ul></ul></ul></ul><ul><ul><li>Efficiency. </li></ul></ul><ul><ul><ul><li>Does it utilize the resources (memory, execution time, license etc) conservatively? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, Performance increase in NDM, CDA & TDL Utility </li></ul></ul></ul></ul><ul><ul><li>Reliability. </li></ul></ul><ul><ul><ul><li>Does the software perform the job it's supposed to without crashing or causing errors, even in stressful environmental conditions? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, TDLChecker (limitation on the number of TDL files), TDLGen (limitation on hierarchical path) </li></ul></ul></ul></ul><ul><ul><li>Integrity. </li></ul></ul><ul><ul><ul><li>Does the product prevent unauthorized or improper access to its programs and its data? </li></ul></ul></ul><ul><ul><li>Adaptability. </li></ul></ul><ul><ul><ul><li>Can the software be used, without modification, in applications or environments other than those for which it was specifically designed? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, EDAObjects™ on several platforms. </li></ul></ul></ul></ul>
    16. 16. Quality Perspectives <ul><li>Process Quality </li></ul><ul><ul><li>Maintainability. </li></ul></ul><ul><ul><ul><li>Can the software be easily modified to change or add capabilities, improve performance, or correct defects? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, Plug-and-Play Architecture of Unified Prime and CC-DFTM </li></ul></ul></ul></ul><ul><ul><li>Flexibility. </li></ul></ul><ul><ul><ul><li>Can the product be modified for users or environments other than those for which it was specifically designed? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, Handoff QC – SoC Integration, Library Verification, Test Handoff. </li></ul></ul></ul></ul><ul><ul><li>Portability. </li></ul></ul><ul><ul><ul><li>Does the software easily operate in an environment different from that for which it was specifically designed? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, … </li></ul></ul></ul></ul><ul><ul><li>Reusability. </li></ul></ul><ul><ul><ul><li>To what extent can the components of the software be used to build new products? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, DTIF – Design Test Input Format. Called by Perl Callback. MVV. </li></ul></ul></ul></ul><ul><ul><li>Understandability. </li></ul></ul><ul><ul><ul><li>Is the source code, especially at the detailed-statement level, easy to read? Is the software easy to understand at both the system- organizational and detailed-statement levels? </li></ul></ul></ul><ul><ul><ul><ul><li>Example, For every release one should have – SoW, SRS, WBS, SDD, STP, Release Notes and Metricate Sheet. </li></ul></ul></ul></ul>
    17. 17. Quality Perspectives <ul><li>Quality is about perception </li></ul><ul><ul><li>In most scenarios, “degree of excellence” is not measurable objectively </li></ul></ul><ul><ul><ul><li>Particularly true in services or solutions based businesses like ours </li></ul></ul></ul><ul><ul><ul><ul><li>Sundar’s perception on DFT-TK </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Claudin’s perception on RTL-TK </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Daniel’s perception on DV-TK </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Vaidee’s perception on AutoRTL </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Saby’s perception on PD </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Amit’s perception on Package Analysis </li></ul></ul></ul></ul><ul><ul><li>Quality could be redefined to be the “customer’s perception of the degree of excellence” </li></ul></ul><ul><li>Quality is the Entire Company's Business </li></ul><ul><li>Quality Must Be Built into a Product / Solution </li></ul>
    18. 18. Quality Perspectives <ul><li>How to develop quality perception? </li></ul><ul><ul><li>Not just by the quality of the end product or solution that you deliver </li></ul></ul><ul><ul><li>Quality becomes important at every stage of the project </li></ul></ul><ul><ul><ul><li>Quality of Communication </li></ul></ul></ul><ul><ul><ul><li>Intermediate deliverables </li></ul></ul></ul><ul><ul><ul><li>Processes that are followed </li></ul></ul></ul><ul><ul><ul><li>Conducts in the meetings </li></ul></ul></ul><ul><ul><li>Patience, perseverance and planning </li></ul></ul><ul><ul><li>Damage done when quality is missing at any level </li></ul></ul>
    19. 19. Items in Interra Quality Initiative <ul><li>Programming Guidelines </li></ul><ul><ul><li>Naming Conventions, preferred practices </li></ul></ul><ul><ul><li>Safe Idioms / Unsafe Idioms </li></ul></ul><ul><li>Debugging Methodology </li></ul><ul><ul><li>Built-in Tracer / Profiler </li></ul></ul><ul><ul><li>Assertions </li></ul></ul><ul><ul><li>Maintain a Problems Database </li></ul></ul><ul><li>Code Review Process </li></ul><ul><ul><li>Self / Peer Review (“Code Complete”) </li></ul></ul><ul><ul><li>Review by Manager / PL </li></ul></ul><ul><li>Test plan & Testing Methodology * </li></ul><ul><ul><li>Unit / Directed Tests </li></ul></ul><ul><ul><li>Random Tests </li></ul></ul><ul><ul><li>Performance Tests </li></ul></ul><ul><li>Quality Audit Plan </li></ul><ul><li>Issues Tracking Process </li></ul><ul><ul><li>GNATS / WEBS / Client-specific </li></ul></ul><ul><li>Version Control Process </li></ul><ul><ul><li>CVS / ClearCase / Client-specific </li></ul></ul><ul><li>Performance Metrics * </li></ul><ul><li>Release Process * </li></ul><ul><ul><li>PNB – Project Note Book </li></ul></ul><ul><li>Documentation Plan </li></ul><ul><ul><li>User Guide </li></ul></ul><ul><ul><li>Code Documentation </li></ul></ul><ul><ul><li>README, Checklist </li></ul></ul><ul><li>Confidentiality Guidelines </li></ul><ul><ul><li>Sensitivity to Interra’s IP / Client’s IP </li></ul></ul><ul><li>Build Guidelines * </li></ul><ul><li>Portability Guidelines * </li></ul><ul><li>Environment Standards * </li></ul><ul><li>… </li></ul>
    20. 20. Q & A <ul><ul><li>How could I have prevented this bug? </li></ul></ul><ul><ul><li>How could I have automatically detected this bug? </li></ul></ul>
    21. 21. Thank You