• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Quality - A Priority In Service Engagements
 

Quality - A Priority In Service Engagements

on

  • 522 views

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

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

Statistics

Views

Total Views
522
Views on SlideShare
518
Embed Views
4

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Changed “during design, 1.5;” to “during design, 0.5;”

Quality - A Priority In Service Engagements Quality - A Priority In Service Engagements Presentation Transcript

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