Product reliability is something that most people take for granted . . . until a product fails. Reliability expectations have changed dramatically over the years, and reliability testing has become vastly more important as product complexity has increased.

In its infancy, the computer was a large assembly of electrical and mechanical parts that was expected to fail regularly. In the 1960s, a mainframe was likely to break down several times a month, and service calls were commonplace. Today a modest PC is far more powerful and complex than mainframes of decades past, yet we expect our PC to continue running indefinitely, day after day, month after month. Likewise, we expect consumer electronics — from toaster ovens to TVs, from lawn mowers to exercise machines — to keep working reliably without service calls.

In surveys of customer expectations, reliability continues to be one of the most important product attributes. In fact, many people will spend more money on a brand noted for its reliability rather than take a chance with a less expensive product from a questionable manufacturer.

Manufacturers approach reliability with a broad range of efforts, from "do nothing and hope" to elaborate programs of planning and testing. What is the right reliability program for you? Here are six myths about producing reliable hardware:

1. Lowest price is most important to customers.

Whether we realize it or not, most consumers and businesses carefully consider a product reputation for reliability when making a purchasing decision. There are many sources from which they glean this information including well-known publications such as Consumer Reports, web-based sites and word-of-mouth recommendations (and warnings) from friends and colleagues.

This means that reliability should be one of the top priorities throughout your product development cycle. The good news is that you can often optimize reliability without making a product more expensive. In fact, in the long run, a company with an effective reliability program enjoys lower warranty costs while maintaining a high level of customer satisfaction and loyalty – thus improving its bottom line profitability.

2. You know what's right for your customer, so there is no need to ask.

Although some reliability problems are obvious (like a toaster oven that doesn't heat properly), many issues that disturb customers are more subtle. In order to determine and understand your customers' expectations, you need to ask. And listen. Surveys, focus groups and service records from previous products can shed light on specific matters that bother customers, even when the product basically "works".

3. There's no need to plan ahead for reliability, you can always "test in" reliability later.

Since reliability problems don't usually show up immediately, some firms assume that there is little that can be done about them until after the product is designed. This "build first, test later" approach creates tremendous problems and can cost time, money and ultimately, customers. Obviously, if you have no idea of how to achieve the reliability your customers expect, you have little chance of attaining it. And if you test for reliability after a design is complete, and fail to meet your goals, the expense of redesign may be fatal.

By understanding what is important to customers up front, engineers are able to design and test to meet specific reliability goals — right from the beginning. Design issues and problems caught early on can be resolved quickly and cost-effectively.

4. Good designers should know how to design reliable products.

Unfortunately, many competent engineers are unfamiliar with reliability methodologies and how and when to implement them in the design cycle. Never assume that your engineers understand both the technology they are designing and all of the associated reliability issues. For this reason, it's important to have reliability specialists participate in the design and testing of your product. A competent reliability specialist will help determine and consider reliability requirements before the product design commences, and throughout the stages of the design cycle, thus insuring that your final product will perform as expected by your customers.

5. Reliability is the sole responsibility of the Quality department.

It's not enough to have a competent reliability expert in your Quality department. Unless every department that can affect reliability is aware of the key issues and is involved in resolving them, you will not have an effective reliability assurance program. One of the important roles of a reliability specialist is to help educate others on the importance of using proven reliability methods. If everyone understands the various elements that can negatively affect reliability, they will be less likely to accidentally compromise product reliability through an inappropriate action.

6. If you are careful with your designs and purchase components from reputable suppliers there's no need to test for reliability.

It's always important to purchase parts from reliable sources and take care with design requirements that affect reliability. However, because today's products are so complex, it's impossible to predict exactly how all of the components will interact under every possible operating condition. Testing subassemblies as well as complete products can yield valuable information about reliability and robustness. High stress-level testing quickly identifies design weaknesses that would lead to reliability problems over time. This is a good practice to apply as early as possible in the product development cycle, even to prototype hardware. It is possible to conduct accelerated life tests that will demonstrate the reliability expected over years of actual use, in a small fraction of test time. This requires specialized expertise in reliability testing methods from an in-house reliability engineer or from an experienced third-party test lab.

Stay tuned for the conclusion of this article and the remaining six reliability myths in the next issue of Perceptions…

Back to top

by Bruce Boardman, Executive Editor of Network Computing

At Network Computing, we know firsthand that maintaining a full-blown testing environment and attracting people with the skill sets needed to fully leverage that investment is serious business. Enterprises leery about committing — even on a smaller scale — to testing space, hardware and staff might consider a third-party lab. If you pick the right partner, this approach offers value, either as a replacement for or an extension to your in-house testing.

As with any outsourcing arrangement there are trade-offs, a major one being the loss of control.

But an outsourcer can offer benefits to offset that loss:

• Cost avoidance: Outsourcing means you don't have to buy all the hardware, software and expertise needed to do worthwhile testing.
• On-demand testing: You can use third parties to meet periodic bursts in demand.
• Knowledge base: By using a third-party testing house during product selection, an organization's in-house lab and operations groups can jump-start their learning and pick up best practices.
• Objectivity: Outsourcing testing is sometimes the only way to get an unbiased, customers' eye view of your organization. Outside-the-firewall, testing services such as Gomez and Keynote Systems can monitor and load actual production environments in the same manner as your customers. This insight, which we think is impossible to reproduce in the lab, can put line-of-business and IT managers in your customers' shoes and illustrate overall service-performance levels.

Other perks can go unnoticed. We chatted with a number of third-party testing labs and found that smart enterprise IT managers are using outsourcing services as political heat shields. An unbiased outsourcer can help relieve pressure on in-house staff.

In addition, tight development deadlines can bring significant pressure to release or move new technology to production, often at the expense of adequate testing. Outsourced testing labs can apply the brakes where needed because they're motivated to protect their reputations and business models through careful and accurate testing.

Finally, outsourcing costs can force enterprises to organize and prioritize. When effecting change from within is a nonstarter, an outside perspective might be the push that's needed to reorganize procedures and goals.

To read the complete article, click here.

Back to top

Techie Humor

What Computer Terms Really Mean

Alpha — Software undergoes alpha testing as a first step in getting user feedback. Alpha is Latin for "doesn't work."

Beta — Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."

Computer — Instrument of torture. The first computer was invented by Roger "Duffy" Billingsly, a British
scientist. In a plot to overthrow Adolph Hitler, Duffy disguised himself as a German ally and offered his invention as a gift to the surly dictator. The plot worked. On April 8, 1945, Adolph became so enraged at the "Incompatible File Format" error message that he shot himself. The war ended soon after Hitler's death, and Duffy began working for IBM.

CPU — Central propulsion unit. The CPU is the computer's engine. It consists of a hard drive, an interface card and a tiny spinning wheel that's powered by a running rodent - a gerbil if the machine is a 286, a ferret if it's a 386 and a ferret on speed if it's a 486.

Default Directory — Black hole. Default directory is where all files that you need disappear to.

Error Message — Terse, baffling remark used by programmers to place blame on users for the program's shortcomings.

File — A document that has been saved with an unidentifiable name. It helps to think of a file as something stored in a file cabinet - except when you try to remove the file, the cabinet gives you an electric shock and tells you the file format is unknown.

Hardware — Collective term for any computer-related object that can be kicked or battered.

Help — The feature that assists in generating more questions. When the help feature is used correctly, users are able to navigate through a series of Help screens and end up where they started from without learning anything.

Input / Output — Information is input from the keyboard as intelligible data and output to the printer as unrecognizable junk.

Interim Release — A programmer's feeble attempt at repentance.

Memory — Of computer components, the most generous in terms of variety, and the skimpiest in terms of quantity.

Printer — A joke in poor taste. A printer consists of three main parts:

• the case
• the jammed paper tray
• and the blinking red light.

Programmers — Computer avengers. Once members of that group of high school nerds who wore tape on their glasses, played Dungeons and Dragons, and memorized Star Trek episodes; now millionaires who create"user-friendly" software to get revenge on whoever gave them noogies.

Reference Manual — Object that raises the monitor to eye level. Also used to compensate for that short table leg.

Scheduled Release Date — A carefully calculated date determined by estimating the actual shipping date and subtracting six months from it.

User-Friendly — Of or pertaining to any feature, device or concept that makes perfect sense to a programmer.

Users — Collective term for those who stare vacantly at a monitor. Users are divided into three types: novice, intermediate and expert.

Novice Users — People who are afraid that simply pressing a key might break their computer.

Intermediate Users — People who don't know how to fix their computer after they've just pressed a key that broke it.

Expert Users — People who break other people's computers.

From www.geekhumor.com

Back to top