You are on page 1of 13

EuroSTAR

Software Testing

Community

Smarter Quality Management: The Fast Track to Competitive Advantage

EuroSTAR
Moshe S. Cohen, Market Manager, Rational Quality Management Solutions, IBM Software Group

Copyright IBM Corporation 2011 IBM Corporation Software Group Route 100 Somers, NY 10589 U.S.A. Organizations

that create and deliver softwarewhether for their own IT packaged applications market, or as the core of their final systems spacemust grapple not only with todays tough economic climate, but also with increased complexity in their processes IBM, the IBM logo, Rational and ibm.com are trademarks or registered and supply chains. Many factors serve to complicate software delivery, but trademarks of the International Business Machines Corporation in the competition lies at the heart of this complexity United States, other countries, or both. If these and other IBM trademarked operations, of America Produced in the United States for the June 2011 product, as in the All Rights Reserved
terms are marked on their rst occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at Copyright and trademark information at

Smarter Quality Management: The Fast Track to Competitive Advantage


Organizations that create and deliver softwarewhether fortheir own IT operations, for the packaged applications market,or as the core of their final product, as in the systems spacemust grapple not only with todays tough economic climate, but also with increased complexity in their processes and supply chains. Many factors serve to complicate software delivery, but competition lies at the heart of this complexity. Here are a few examples. In the products arena, customers demand more from the software components designed for thelatest hardware, often with requirements that change rapidly, even as software projects are underway. Keeping track of changes while meeting aggressive (and unaltered!) deadlines is difficult, ifnot impossible. In the IT space, more businesses are focused ontheir operational software for capturing and providing value to their customers and lines of businesses. E-commerce websites compete to improve customer relations and simplify online business; businesses that create highly optimized supply chains supporting a fast, efficient ecosystem of partners quickly rise in the market place. What does this competitive environment mean for businesses seeking to deliver high-quality products and services? Certainly, effective quality management creates opportunities to deliver key business benefits, such as improved market share, higher customer satisfaction, and increased brand equity. But top quality in the completed product cannot serve as the single guiding principle by which products are produced and delivered. Time to market is also key; costs and risk factors must also be part of the balancing act. Get these things wrong, and you may face unsustainable costs, missed windows of opportunity, unhappy customers, even a massive recall or the complete failure of a system at a critical moment. Get these things right, and you can achieve a positive operational return on investment from efficiencies gained in development activities. One of the biggest challenges related to quality management is how to invest intelligently to minimize risk, given economic constraints. However, figuring out a) how to relate quality to business outcome and b) what constitutes the right level of quality for individual products is not always clear. This paper introduces a practical approach to quality management (QM) that helps reduce time to market without sacrificing quality in the outcome. The underlying concepts presented here will be familiar to software project managers, especially those with QM experience, but I will explain some fundamentals as we go along to ensure all readers seeking these benefits can understand the essential processes involved.

1 PAGE

The nature of software development


Heres one way to understand the soft in software: it is relatively easy to change. But for software designed for the commercial space, where the competitive pressures described above govern a software projects success or failure, the softfeature happens to be one of its riskiest attributes. Thats because software projects are seldom designed and manufactured as in traditional engineering projectsa bridge, for example. While a bridge is engineered through traditional planning and architecture based on the laws

Smarter Quality Management: The Fast Track to Competitive Advantage


of physics, then produced according to an organized plan with a division of labor, software is, at its essence, simply information. Its development typically resembles a more creative process than one bound by the laws of nature. Walker Royce, IBM Software Group/Rationals chief software economist, compares software production to movie production: a collaboration involving a team of craftsmen and emerging from the naturally creative process of artistic yet technical people. Over the past two decades, this unique feature of software has been understood and embraced by iterative development practitioners, who now tend to develop software in stages called iterations. Each iteration delivers a working, functional version of the software under development, so it can be reviewed, tested, and vetted by stakeholders and other teams seeking adherence to the original project requirements. This allows project managers to make smaller, incremental course corrections during the project life cycle thus ensuring the final deliverable is close to expectationsas opposed to having separate teams work according to a plan, assemble various components near project end, and discover major failures due to integration or deployment complexities. For testing teams, the iterative development process integrates quality management across the states of the project work flow, as opposed to relegating test activity to the end of the project. I will describe the role of iterative development-based quality management more fully in the next section.

Quality management in the software development life cycle


What is the role of the testing, or QM, team during the iterative life cycle? What do they test for, and how do they know what is supposed to change from one iteration to the next? As noted above, traditional software testing only occurs late in the life cycle, after multiple coding teams have spent much time and effort to deliver their components toward the complete project. Because these traditionally managed projects proceed according to strictly described requirement sets, and various component teams focus on their portions alone, it is up to the testers to discover the discontinuities and malfunctions as these components are assembledthen its the testers who must deliver the bad news that much rework has to be done inorder to get the project back on track. Iterative software development techniques improve on that scenario by introducing test teams to the process much sooner. A relatively modest, first iteration may only address 15 percentof the full set of project requirements, but as a functional module of working code, the completed iteration can be demonstrated, and tested. So any defects discovered by test teams at this early stage have a proportionally small impact on the larger development team, who make the fixes, then proceed to the next iteration where more of the requirements can be incorporated into the working version (iteration) of the software.

2 PAGE

Smarter Quality Management: The Fast Track to Competitive Advantage


The number of iterations required by any software project depends on many factors, of course, such as the complexities of the teams supply chain, the complexity of the software underdevelopment, the physical location of team members (are they geographically distributed, perhaps internationally? or are they co-located under a single roof?), and the competitive demands that determine optimum time to market. During any software delivery process, When do we release? is a key question withno simple answer. You must consider project-specific variables, such as the cost of delays, the opportunity value of early delivery, marketplace quality expectations, and the costs associated with 4 Smarter qualityUltimately, track to competitive advantage defects. management: The fast the delivery strategy will be based on the actual or perceived importance of each variable. The best time to release varies widely based on your software delivery strategy and your target market. Software delivery for both IT (internal business systems) and smart products (products using embedded software, including system-of-systems design) is typically dominated by one of two motivators, depending on the organizations target market: time to market (schedule driven), or quality impact (quality driven). Schedule-driven delivery implies deliver on time, regardless of other factors and is often used in industries where Time to market is king. Consumer electronics is one good example, as well as automotive, segments of the medical industry, and other markets, where product teams try to gain a first mover advantage over their competitors, (almost) regardless of the risk associated with inadequate quality. It should also be noted that schedule-driven delivery is not limited to the systems space (i.e., the many embedded software devices industries). Many IT development teams use scheduledriven delivery when trying to enhance their end typically experienceone of two motivators, depending is user dominated by and increase market on the organizations target market: time to market (schedule share, taking away from their competitors, driven), or quality impact (quality driven). often risking quality in the process. Figure 2factors and is often usedrisks associated to of other represents the in industries where Time with schedule-driven software is one good example, as market is king. Consumer electronics delivery. The well line represents the risks associated green as automotive, segments of the medical industry, and other markets, with the where productof yourto product mover advantage delivery teams try gain a rst being over their competitors, (almost) regardless of the risk associated reduced over time. It should also be noted that schedulewith inadequate quality. The red lines represent the risk delivery is not limitedstealing your market many driven of competitors to the systems space (i.e., the embedded software over industries). well as risks away increasing devices time, as Many IT development teams use schedule-driven delivery associated with opportunity when trying to enhance their costs. The intersection is the point in time where Figure represents the risks associated with schedule-driven the sum2of both lines, i.e. the total risk, is the software delivery. in green line this point risks associated lowest. As seenTheFigure 2,represents the moves with the delivery of your product being reduced over time. The to the left as the environment you are in is red lines represent the risk of competitors stealing your market more competitive time, as well as risks associated with opporaway increasing over in nature. (Notice that the intersection point is moving up as well.) tunity costs.
The intersection is the point in time where the sum of both lines, i.e. the total risk, is the lowest. As seen in Figure 2, this end user experience and increase market share, taking away from their competitors, often risking quality in the process. Schedule-driven delivery implies deliver on time, regardless

3 PAGE

The optimal time to release


The optimal time to release is when the total The optimal time to release risk exposure isminimal, typically around The optimal time to release is when the total risk exposure is the time where the risk associated with minimal, typically around the time where the risk associated competitive threats starts to outweigh the with competitive threats starts to outweigh the risk reduction associated with further quality improvements, as illustrated in risk reduction associated with further quality Figure 1. improvements, as illustrated in Figure 1.
Risk Exposure

Many critical defects

Lowest Overall Risk Exposure

High opportunity cost; Strong competition

Low opportunity cost; Weak competition

Few minor defects Time

Quality risk ( = Probability of defects x loss due to defects) Competition risk ( = Probability of competitors x size of loss to competition) Total risk ( = Sum of all risks)

Figure 1: Minimal risk exposure is when opportunity cost and competitive


threats outweigh risk reduction related to quality improvements.

The best time to release varies widely based on your software

Smarter Quality Example: ConsumerThe Fast Track to Management: Electronics


Risk Exposure Time

Time to Market is king!

Quality-driven delivery can also be costly but for different reasons. As shown in Figure 3, the more critical any defects might be regarding quality, the longer it takes Competitive Advantage to get to an optimum release point.

Quality-driven delivery can also be costly but for different reasons. As shown in Figure 3, the more critical any defects might Quality is king! to Market is king! High Example: Safety Critical applications Example: Consumer Electronics opportunity cost; be regarding quality, the longer it takes to get to an optimum Strong competition release point.

Risk Exposure High opportunity cost; Strong competition

Risk Exposure

Example: Safety Critical applications


Risk Exposure

Quality is king! Defects

Criticality of

Time
Figure 2: The blue dots show possible release points, with points of minimal
risk moving forward as competition intensies (red lines).

Criticality of Defects

Time

4 PAGE

Time Quality issues are often magnied in a schedule-driven life cycle, Figure 3: The more critical the implications of defects are, the more time it given that software contractors frequently get paid on a time and takes to get to the lowest risk point where release is possible. Figure materials basis,show possible release points, with points of minimal 2: The blue dots regardless of the quality of software they deliver. risk moving forward as competition intensies (red lines). In many cases, you may even end up paying extra for the delivTime The release timing for this approach is governed by achieving ery team to x their own defects, so the potential costs of defects the right quality, moving the optimal time to release further to to the end user can add up quickly. Quality issues are often magnied in a And heres an interesting stause. more critical the do you dene that? are, thedefects is practiQuality According to areCarnegie schedule-driven life cycle, a Figure theThe A target based ondefects fixed might issues the often magnified in 3: rightbut how implications of defects Zero more time it Mellon Software Engineering given tistic: that software contractors frequently get paid on a time and takes to get to the lowest risk point where release is possible. no way to detercally impossible to achieve, given that there is Institute, Data indicate that cycle, be more realisticbut its still impossibleto schedule-driven of lifequality 80 softwareof thedeliver. given of materials basis, regardless the 60 - of percent they cost that mine how many defects still exist in a piece of code or the software development is in rework.1 extra for the delivIn many cases, contractors paying number of is governed by defects software you may even end upfrequently get paid The know the for this approachremaining achieving in the release timing ery team to x their own defects, so the potential costs of defects product. on aend user can add up quickly. And heres an interesting statime and materials basis, regardless the right quality, moving the optimal time to release further to to the the rightbut how do you dene that? Zero defects is practiof the quality of softwareSoftware Engineering In tistic: According to the Carnegie Mellon they deliver. cally impossible to achieve, given that there is no way to deterInstitute, Data indicate that 60 - 80 percent of the many cases, you may even end cost of up paying mineRisk-driven stilldelivery of code or the delivering how many defects exist in a piece implies 1 software development is in rework.

extra for the delivery team to fix their own defects, so the potential costs of defects to the end user can add up quickly. And heres an interesting statistic: According to the Carnegie Mellon Software Engineering Institute, Data indicate that 60 - 80 percent of the cost of software development is in rework.

your software when the risk is minimal. But in practice, we always need to release earlyearlier than we can. Which typically implies increasing the risk, right? At least this is a commonly held view, but is it always the case? Within the risk-driven model, the optimal release time is when risks are sufficiently reduced (not completely eliminated) and time to market has not been wasted. In other words, some time is needed to reduce the most significant risks, but the company cannot afford to address every known risk because the opportunity to beat the competition is fleeting. So the question is, how can we get to this point sooner? How do we compress the release date from the optimal intersection (shown as a blue circle in Figure 4) to a point earlier in time?

Quality-driven delivery can also be costly but for different reasons. As shown in Figure 3, the more critical any defects might be regarding quality, the longer it takes to get to an optimum release point. The release timing for this approach is governed by achieving the right quality, moving the optimal time to release further to the rightbut how do you define that? Zero defects is practically impossible to achieve, given that there is no way to determine how many defects still exist in a piece of code or the probability of detecting those defects in

Smarter Quality Management: The Fast Track to Competitive Advantage


We cannot simply cut the time requirement, because as we move left on the green line, the risk goes higher. But what if we could compress the curve described by the green linepush it down, so to speak? Then we could not only deliver sooner but lower the overall risk as well. The intersection point will move down and to the left. This improved scenario is shown in Figure 4.

Understanding quality management: Its more than simply testing


If a faster reduction in risk is the goal, how do you achieve it? The answer is not through testing, which is focused simply on discovering defects. In traditional testing practices, testing is considered a late stage activity, squeezed between an often-late development hand off date and an immovable ship date. Not only does this practice fail to yield the benefits of incremental, iterative development techniques explained earlier; it also minimizes, or at best reduces, the amount of time spent on quality assurance, and makes fixes all the more difficult unless youre willing to compromise the release date. As noted earlier, iterative development techniques greatly improve this situation by having functional units tested incrementally, in stages, throughout the life cycle, rather than leaving the testing phase until project completion. And quality management takes this improvement a step further2.. Quality management, which is the implementation of best practices to proactively reduce risk throughout the whole life cycle, is a risk reduction mechanism in its own right. By choosing quality management practices with the potential to deliver a positive ROI within a relative short amount of time, you can justify risk reduction measures from not only a quality stand point but also a financial standpoint.

get based on ill impossible roduct.

ware when d to release lies increasing ew, but is it

Optimal Time to Release

time is when inated) and ds, some time the company the opportu5

Time to Market

Time

Figure 4: To deliver early, at an improved quality, reduce your risk at an earlier


point in the life cycle.

PAGE

ooner? How intersection ier in time?

use as we move hat if we could push it down, er but lower l move down n Figure 4.

two extremes (i.e. delivery offers a because it Risk-driven schedule driven vs. quality driven) practical more cost-effectively balances quality versus time-to-market improvement over these two extremes (i.e. considerations. A risk-driven strategy is a renement of a schedule driven that optimizes risk exposure because quality-driven approach vs. quality driven) against development cost-effectively balances quality it more cost and time. versus time-to-market considerations. A For the remainder of this discussion, we will assume that the risk-driven strategybased on a risk-driven approach. a software delivery life cycle is is a refinement of We will explore how to bend the green curve shown in Figure 4 quality-driven approach that optimizes risk downward and exposure to the left, fordevelopment cost and against reduced time to market without compromising the risk prole. time.

Risk-driven delivery offers a practical improvement over these

For the remainder of this discussion, we will assume that the software delivery life cycle is based on a risk-driven approach. We will explore how to bend the green curve shown in Figure 4 downward and to the left, for reduced time to market without compromising the risk profile.

Smarter Quality Management: The Fast Track to Competitive Advantage


Approaching quality from a full life cycle perspectiveas opposed to assuming that testing activity will sufficeshould not seem like such a radical idea. After all, testing a product is an engineering task just like development: the requirements need to be analyzed by the test architect, its testing strategy has to be defined, the relevant test benches and test frameworks need to be built (designed and implemented), etc. These engineering development processes are very similar to the ones followed during product development. In fact, product development and quality management can be viewed as two parallel development threads emanating from the same requirements, with many synchronization points between the threads, up to the point of the testing activity itself where a verdict is made based on meeting expectations or not (as expressed in the test cases). This applies to both the traditional development process as well as agile methods (with variants such as testfirst development and test-driven design). The important point is that QM is a thread that must run in parallel to development, especially in agiledevelopment. Although a complete discussion of QM is beyond the scope of this paper, we can show how QM reduces riskand thus allows earlier software delivery without compromising qualityby demonstrating how one of the quality management best practices can improve iterative testing within the software development life cycle. earn their paychecks by testing chunks of completed, compiled software code against the requirements that code is designed to fulfill. Requirements are mapped to test casessets of conditions by which a tester can know whether or not a particular requirement is met. Each requirement demands one or more test cases. Naturally, some requirements are more critical than others, so some test cases represent higher value to the overall project than others. The benefits of traceabilitythat is, tracing test cases back to the requirements are clear. It allows the testing team to measure the testing coverage vis--vis your requirements: How many of the requirements have been covered? Which requirements have not been tested? And how many of the requirements that are associated with test cases pass? And of course you would like these answers to be across subsequent builds rather than a single one. But this is not all. Traceability allows for test execution prioritization, saving money and time in the process. As each iteration proceeds, the number of test cases that may be involved increases as more and more requirements are met. Most test teams feel it is necessary to step through the entire suite of test cases touched by the latest iteration in order to thoroughly assess quality. But is this truly necessary? No. Re-executing all the test cases, either in the agile context or as a growing set of regression tests in a waterfall process, increases the time required to test; it requires further efforts to maintain the test cases, and it becomes a drain on productivity and, ultimately, adds to the projects bottom line cost. To reduce the wasted effort and associated costs, this all-too-typical use of test cases can be replaced with a more results-oriented approach to requirements

6 PAGE

Test cases: Driving testing from requirements


Simply stated, software testing teams

Smarter Quality Management: The Fast Track to Competitive Advantage


coverage, one that maps results to testing activities. The essential principle is this: prioritize testing according to risk. As changes occur to working code during the life cycle, test teams may choose to test for the most critical requirements first, and maybe later test for all critical requirements remaining (for example, in another iteration). In other instances, they may choose to run only the subset of test cases that provide choose to run only the subset of test cases that provide them them highest coverage. This approachcoverage. This with the highest is illustrated in with the approach is illustrated in Figure 5. Figure 5. link the appropriate test artifacts for each requirement, it would take approximately 10 person-months to create the traceability between requirements and test cases. You could potentially reduce this time to one to two minutes per requirementand a total of just 10 to 20 person-daysusing a dedicated quality management solution with support for capturing traceability links between requirements and test cases. At a nominal rate of US$50 per hour, this single change corresponds to a potential saving of around US$75,000. And needless to say, in real life, the numbers are much bigger. There are other best practices that contribute to improved quality at a reduced cost. We are not going to cover them all in this paper, but here are two for you to consider. Improved collaboration between the QA team and other stakeholders: From talking to customers, we learned that on average, a tester spends only about 60 percent of the time performing actual testing, test planning, or test reporting. The other 40 percent is related to activities that are collaborative in nature, such as clearing up the requirements with domain experts or business analysts, or exchanging emails and phonecalls with members of the development team. This gets worse in distributed organizations. If you could track and manage the collaboration, it will not only reduce your risk associated with lack of communications and misunderstandings, but also reduce the time for collaborative tasks by 20 50 percent. Automated reporting: Creating a report, especially one that goes to high level management, requires data collection from many sources, sometimes from teams that are in different time zones, and then formatting this data appropriately. If you could automate this activity, your team will probably use it more often and take the appropriate

ses back to am to meass: How many quirements ements rse you would ther than a

No. of Requirements

High Requirements coverage Most critical Requirements All critical Requirements Low contribution

tion prioritiach iteration olved Most test suite of thoroughly 7

Test Suites

PAGE

ile context process, er efforts to productivity st. To reduce ypical use of ted approach testing activig according he life cycle, equirements nts remaining es, they may

Figure 5: After a change, re-executing all the tests is safe, but expensive and

often unrealistic. By focusing instead on test suites that are the most relevant to the iteration that is being tested, test teams make more efficient use of their time and reduce redundancies along with high testing costs.

Although you you cannot completely remove Although cannot completely remove risk from a development program, you can measure it and manage it by taking risk from mitigation actions. This approach helps ensure a development program, you the appropriate can measure it and manage it by taking that you are optimally using your nite testing resources (your people) to reduce risk as rapidly as possible in the development the appropriate mitigation actions. This cycle. By focusing testing effort on high-value test cases, from approach helps ensurethatcontributionoptimally you are to business either the point of view of coverage or using your finite testing resourcesyou value, you essentially prioritize according to riskand (your worry less to reduce risk as rapidly as issues. people)about test cases that pertain to noncriticalpossible in the development cycle. By focusing testing effort on high-value test cases, from either the point of view of coverage or contribution to business value, you essentially prioritize according to riskand you worry less about test cases that pertain to noncritical issues.

But does creating the traceability links require an expensive investment? No, and here is the basic math. Consider a hypothetical medium-size project with some 5,000 requirements and 10,000 test cases. Assuming it takes 20 minutes to locate and

the overall business in measurable ways. Smarter Quality Management: The Fast Track to Competitive Advantage Using CMMI

decisions in real time,thus reducing your risk. How much would this save you? These are some of the quality management best practices, each of which contributes to risk reduction and therefore increased quality and reduced cost. Now, lets consider the overall impact of quality management on the defects density and the cost of fixing them.

Together, these quality management best practices can benet 3 as a proxy for the maturity of the development process, Figure 6 shows that the overall business impact of quality management is quite compelling. more defects. 3300), or 914

and the by appl to 58 p 1914 (5

Impact of Quality Management on Process Efficiency


100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% QM Impact:
20% 15% 32% 30% 58% 60% 76% 75% 85% 85% 87%

As xin seven ti and ass gration cost by

And th numbe the rs This al as incre of quali


3
40% W/O QM

40%

40%

10% W QM

The overall business impact of quality management


Quality management best practices center on quality synchronization points across the whole development life cycle. We have discussed the benefits of traceability to requirements, and we have briefly noted collaboration between stakeholders and the QA team, as well as automated reporting. Other best practices include: allowing quality professionals to contribute to the team effort from the very beginning of a project; the integration of practitioners doing the testing as part of quality management; and the use of consolidated quality dashboards. Together, these quality management best practices can benefitthe overall business in measurable ways. Using CMMI3 as aproxy for the maturity of the development process, Figure 6 shows that the overall business impact of quality management is quite compelling. Lets assume an organization at CMMI level 2, with 1000 defectsdetected during functional testing. Figure 6 shows that on average, without QM practices, about 30 percent of the defectsare being detected in functional testing (the left, blue bar), and therefore the total number of defects is 3300. However, by applying QM practices, the defect detection rate increases to 58 percent (the right, green bar), therefore detecting 1914 (58 percent of

CMMI Levels

Figure 6: Graphing percentage of defects detected (Y axis) against an


organizations software development maturity level (X axis).

Lets assume an organization at CMMI level 2, with 1000 defects As fixing defects during User Acceptance detected during functional testing. Figure 6 shows that on Testing (UAT) is aboutseven times more average, without QM practices, about 30 percent of the defects are being detected in functional testing (the left, blue bar), test, expensive than during unit/integration

As mos 2 or 3, most of mature 4 and 5 more im of defec improv related as a dif

8 PAGE

and assuming a fix cost of US$120 per defect during unit/integration test, fixing 914 defects in UAT is already increasing the cost by over half a million dollars! And this does not even take into account the reduction in the number of defects that result from applying QM practices in the first place, which makes the savings even more significant. This also does not take into account less tangible savings, such as increased quality, customer retention, and other implications of quality as a differentiating asset. As most software development teams are around CMMI levels 2 or 3, the benefits and the savings described above apply to most of the industry. But as development teams become more mature, apply QM practices, and move up to CMMI levels 4 and 5, the focus shifts into less obviousbut for some, even more importantbenefits, such as reduction in the number of defects that are introduced in the first place, measured improvements around planning and execution of quality related activities, customer retention, and leveraging quality as a differentiating asset.

Smarter Quality Management: The Fast Track to Competitive Advantage

Better quality + lower cost = improved competitiveness


In this paper, I have described several improvements to methods used by software teams in the design, testing, and deployment of software for systems or IT. Teams may use these quality management methods to deploy that software more quickly, while mitigating quality-related risks throughout the life cycle. The multidisciplined practice of quality management is breaking the functional and organizational silos that are so common in todays companies. It encourages an analytical process thats closely integrated with the development life cycle. Analyzing the market and best practices shows that business outcomes can be optimized, and that smart improvements within the realm of proven best practices for requirements management and traceability, collaborative test planning and automated reportinga combination of disciplines that defines quality managementcan help address the need for increased innovation with more competitive products and services to your customers. The IBM Rational organization is ready to demonstrate these techniques to you. With straightforward adjustments to your investments, deployment practices, and tooling, we can help you realize these benefits within a time frame that best suits your businesss needs. We look forward to working with you!

For more information


To learn more about the IBM Rational quality management offerings, please contact your IBM marketing representative or IBM Business Partner, or visit the following website: ibm.com/software/awdtools/rqm/ Additionally, financing solutions from IBM Global Financing can enable effective cash management, protection from technology obsolescence, improved total cost of ownership and return on investment. Also, our Global Asset Recovery Services help address environmental concerns with new, more energy-efficient solutions. For more information on IBM Global Financing, visit: ibm.com/financing

9 PAGE

About the Author


Moshe Cohen is the Market Manager for IBM Rational quality management offerings. In his current role, he works closely with customers, including managers and practitioners, to drive IBM Rational quality management offerings in both the IT and embedded systems spaces. Prior to this, he was with Telelogic, defining and driving its Model Driven Testing solutions. He has extensive hands-on experience in the specification, development, and testing of C3I medical and telecom applications, including technology adoptions and driving process improvement programs. He received his EE and M.Sc in mathematics and computer sciences, both with honors, from Beer-Sheva University in Israel.

ibm.com/legal/copytrade.shtml

Other company, product, or service names may be trademarks or service marks of others.

Smarter Quality Management: The Fast Track to Competitive Advantage The information contained in this document is provided for informational

Copyright IBM Corporation Copyright IBM Corporation 2011

2011 IBM Corporation Software Group Route 100 Somers, NY 10589 U.S.A. IBM Corporation Produced in Software Group the United States of America June 2011 Route 100 Reserved All Rights
Somers, NY 10589 U.S.A. Produced in the United States of America trademarks or registered trademarks of the June 2011 All Rights Reserved Business Machines Corporation in International

purposes only and provided as is without warranty of any kind, express or implied. In addition, this information is based on IBMs current product plans and strategy, which are subject to change by IBM without notice. Without limiting the foregoing, all statements regarding IBM future direction or intent are subject to change or withdrawal without notice and represent goals and objectives only. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of IBM software. See the Carnegie Mellon Software Engineering Institutes CEO and signup.do?source=swg-rtl-spsm-wp&S_ founders message at http://www.sei.cmu.edu/about/message/

www14.software.ibm.com/webapp/iwm/web/ PKG=wp_RQM_VALUEDRVN_071510

IBM, the IBM logo, Rational and ibm.com are

webapp/iwm/web/signup.do?source=swg-rtl-spsm-wp&S_PKG= staged approach to process improvement that defines wp_RQM_VALUEDRVN_071510


3

For a more complete discussion of quality management practices, download the paper Value-driven quality management for complex systems: Six 3 strategies for reducing cost and risk at Integration. CMMI is a Capability Maturity Model http://www14.software.ibm.com/

the the IBM States, other countries, or both. registered IBM, United logo, Rational and ibm.com are trademarks or If these trademarks of theIBM trademarked terms are marked and other International Business Machines Corporation in the website at http://www.sei.cmu.edu/cmmi/ United States, other countries, or both. If these and other IBM trademarked http://www.sei.cmu.edu/cmmi/ on their first on their rst occurrence in this information with a a occurrence in this information with terms are marked trademark symbol ( or ), these), these symbols indicate trademark symbol ( or symbols indicate U.S. registered or Please Recycle common law trademarks owned by IBM at the time this information U.S. registered trademarks may lawbe registered or common by or common also trademarks owned was published. Such law trademarkstime this information wasof IBM trademarks IBM at the in other countries. A current list published. Such is available on the web at Copyright and trademark information at trademarks may also be registered or common law trademarks in other countries. A current list of IBM Other company, product, or service names may be trademarks or service trademarks marks of others. is available on the web at Copyright and trademark information atibm.com/legal/copytrade. The information contained in this document is provided for informational shtml purposes only and provided as is without warranty of any kind, express
ibm.com/legal/copytrade.shtml

Capability Maturity Model Integration. CMMI is a staged approach organizations. For more information levels of maturity to process improvement that denes incremental see the Software in software engineering organizations. For more information see the Engineering Institute (Carnegie Melon University) Software Engineering Institute (Carnegie Melon University) website at

incremental levels of maturity in software engineering

RAW14273-USEN-01

10 PAGE

provided as is without warranty of any kind, is based on IBMs current product plans and strategy, For a more complete discussion of quality management practices, download which Value-driven to change by for complex systems: Six the paperare subjectquality managementIBM without notice. strategies for reducing costthe risk at http://www14.software.ibm.com/ Without limiting and foregoing, all statements webapp/iwm/web/signup.do?source=swg-rtl-spsm-wp&S_PKG= regarding IBM future direction or intent are subject to wp_RQM_VALUEDRVN_071510 change or withdrawal without notice and represent Capability Maturity Model Integration. CMMI is a staged approach goals and objectives only. Nothing levels of maturity to process improvement that denes incrementalcontained in this in software engineering organizations. For more information see the documentation is intended to, nor shall have the Software Engineering Institute (Carnegie Melon University) website at effect of, creating any warranties or representations http://www.sei.cmu.edu/cmmi/ from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license Please Recycle agreement governing the use of IBM software.
See the Carnegie Mellon Software Engineering Institutes CEO and express or implied. In addition, this information founders message at http://www.sei.cmu.edu/about/message/
1

or implied. In addition, this information is based on IBMs current product plans and strategy, which are subject to change by IBM without notice. Other limiting the foregoing, all or service names future Without company, product, statements regarding IBMmay be direction or intent are subject to change orothers. without notice and trademarks or servicemarks of withdrawal represent goals and objectives only. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or The information contained in this document representations from IBM (or its suppliers or licensors), or altering is the terms and conditions of the applicable license agreement governing provided for informational purposes only and the use of IBM software.

See the Carnegie Mellon Software Engineering Institutes CEO andfounders message at http:// www.sei.cmu.edu/about/message/ RAW14273-USEN-01 For a more complete discussion of quality management practices, downloadthe paper Valuedriven quality management for complex systems: Sixstrategies for reducing cost and risk at http://

05 08 November 2012 | RAI Amsterdam The EuroSTAR Conference attracts testers from around the globe who come to learn, network & discuss all things testing. Attendees experience

intensive tutorials, track sessions & inspirational keynote speakers, & can visit Europes largest Software Testing Exhibition. Return to the office inspired, motivated, and full of new ideas!

www.eurostarconferences.com

Join the EuroSTAR Community


Access the latest testing news! Our Community strives to provide test professionals with resources that prove beneficial to their day-to-day roles. These resources include catalogues of free on-demand webinars, ebooks, videos, presentations from past conferences and much more...

Follow us on Twitter @esconfs


Remember to use our hash tag #esconfs when tweeting about EuroSTAR 2012!

Become a fan of EuroSTAR on Facebook Join our LinkedIn Group Contribute to the EuroSTAR Blog Check out our free Webinar Archive Download our latest ebooks

The EuroSTAR Blog


Written by Testers for Testers

w w w. e u r o s t a r c o n f e r e n c e s . c o m

You might also like