e-Talk Radio: Magee, Stan, and Peter Voldner, 22 March 2001

TEXT TRANSCRIPT: 22 March 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus E-Talk with Carol Dekkers, brought to you by StickyMinds.com, the online resource for building better software. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now let's join your host, Carol Dekkers.

Carol Dekkers: Good morning. Good afternoon. Welcome to Quality Plus e-Talk with Carol Dekkers. I'm Carol Dekkers, and I'd like to welcome you to show number 12 of our season on "Building Better Software." I'd like to thank our sponsor, StickyMinds.com, who continues to run our show. And they have done something very special for us. They have actually taken the last, what will be 25, 26 shows by the end of next week and the week after. They've taken all of the shows and transcribed them into paper, actually written word, as well as streaming audio. So if people went to the StickyMinds.com e-talk radio page, from their home page, and you take a look at the schedule of the people that we've had on the show, anybody who's underlined, you can click on that and you will actually be able to have streaming archive audio of any of the shows that we've had. And we've had some very illustrious guests. And this week is no exception. It gives me great honor to introduce you to two of my ISO colleagues, Mr. Stan Magee and Mr. Peter Voldner, who I'll introduce in a moment. They're two of the preeminent authorities in the area of the world's most popular ISO standard, ISO 12207, Software Lifecycle Process Standard. It's even actually more popular than ISO 9000, and I'd like to welcome both of you to the show. And I'll introduce you in just a moment. Welcome, Stan.

Stan Magee: Thank you very much.

Carol: And welcome, Peter.

Peter Voldner: Hi. Thank you, Carol.

Carol: Good. The sound levels are great today. That's wonderful. Before I introduce my two honorable guests, I'd like to just tell you a little bit, and extend the offer that I've extended for the past several weeks. My company and myself and my team of experts go out and help companies to build better software by using measurement. You can measure something and find out how well you're doing. Then you can improve upon it. If you don't know what you're measuring, if you have no idea how to measure, that's what we really teach you. And we've come up with a calendar that shows the Capability Maturity Model Integration, together with Function Point Analysis and where they fit together through each of the five steps. So again, I'd like to offer that to anyone. I'd also like to let you know that we have some training coming up in Maclean, Virginia, and also in Chicago, Illinois, with major discounts if you register early. You can find all of those on our Web site, at www.qualityplustech.com. And if you send me an email, [email protected], I'd be happy to send you a calendar, if you send me your mailing address. So without further ado, I'm really excited about this show. It's Taming Your Process with Standards, Choosing the Right Standard for Your Company. And that can often be daunting when you get into the world of ISO standards. So two of my experts, who I've got on today…Stan Magee is President of the Software Engineering Process Technology Company, a firm specializing in the implementation of software process technology for U.S. and international corporations and organizations. He is the convener of the working group 7 within ISO on lifecycle management for, and here's a long acronym, ISOIECJTC1ST7WG7, which is the software engineering standards group. He's been a U.S. delegate to the international plenary meeting since 1986. In 1995, Stan was elected to the IEEE computer society's Golden Core of 500 people who have significantly served the IEEE society in standards development over its 50-year history. He has written several books, one which is a guide to standards and specifications for designing Web software. And also one called Software Engineering Standards and Specifications, which are available through amazon.com and most notably, through Stan's Web site, which is www.12207.com, and we'll mention more about that after. Stan's got a lot of history. He's got just an incredible amount of expertise. And you'll be very interested to hear what he's got to tell us about standards today. So welcome, Stan.

Stan: Thank you very much, Carol.

Carol: Peter, who is our other colleague who's on the line, is President of Peregrine Software, a firm whose goal is to help its clients reach higher productivity and quality, using the latest in industry best practices, including preparation for ISO 9001. Tools include things like software engineering standards from ISO, IEEE, the IT infrastructure library, and various other software process assessment models reflecting the latest industry best software practices. Over the past 28 years, he's been involved in all phases of software lifecycle, including planning, development, QA, methods development, field support, and marketing. He's an IEEE recognized lecturer in several software engineering courses. He's been the chair of the Canadian ISO committee on software engineering, and he also participates in working group 7 on the software lifecycle process standards. So joining us from Ottawa, Ontario, is Peter Voldner. Welcome to the show, Peter.

Peter: Thanks, Carol. It's actually Toronto. But we're delighted to be here.

Carol: Oh, you're in Toronto. I didn't realize you were in Toronto. And for anybody who is not Canadian listening to this show, Toronto and Ottawa are two completely different cities. Correct, Peter?

Peter: Right.

Carol: And Stan joins us from Seattle, Washington. And I'm joining you from Florida. So we've got pretty much the North American continent covered today. I'd like to get right into the questions. I guess my question and that of many of our listeners is really what's this whole thing about software standards about? People have heard about ISO 9000. Any time I tell anyone that I'm associated with ISO, they say, "Oh, you know all about ISO 9000." And that's not really the case. There's many ISO standards, isn't that correct, Stan?

Stan: Yes, Carol. Thank you for that question. When most people hear the word "standard," it has about as much appeal to them as having to go to the dentist for a root canal. And so, a lot of times, people have a bad connotation about standards. Standards came about in the late 1800s, when fire companies would go to various other areas and they could not hook their hoses to the fire hydrants. So the world said we need to have a standard for fire hydrants, so we can hook the hoses up. Today, we have standards from everything from animal traps to dentistry equipment. And standards are produced at the international level, the national level, by professional bodies, and by trade groups. Today, we will be talking about software engineering process standards. There are 17 core software engineering process standards, such as quality, test, and documentation. There are also product standards that define the languages that you will use for writing software. We will not be addressing those today. We will just be addressing process standards. So I hope that gives you a little bit of an overview on what standards are, and what we'll be talking about today, which is software engineering process standards.

Carol: And I think you have a good assessment. I think that truly, people do say, "Standards?" And it's almost like you've come to do an audit on their expense account. "Isn't there anything else we can talk about? Standards? Excuse me?" So I think…And I find it interesting that fire hydrants were really the first ones. Was that the first international standard, or the first national standard?

Stan: I think it came about the same time. In Europe, they experienced this problem. And also we experienced this problem in the United States. Once we started to move out from the territory that people were comfortable in, this problem occurred, and the world felt that we had to solve it. And it came up both at the national level and at the international level.

Carol: And I never really even thought about it. But most things in our life fit together, but why do they fit together? There had to have been standards. Peter, let me ask you. Why are standards important for regular companies? For companies that are in the United States, in Canada, and throughout the world?

Peter: Well, Carol, as you know, the software industry's a young one. And the challenge of building quality products, it's now widely agreed that to do that, you need a good process. A disciplined series of steps for its development, and subsequently, its support.

Carol: Right.

Peter: Now, we feel that software standards, because it's a young industry, form a very important source of information about the software processes and procedures. And we're talking here about a process, right from the beginning, right to the end, of a product. Right from concept through retirement. And we all know that we continue to have challenges in producing quality products on time and within budget. And the competitive challenge remains in our industry, because it's a young one. So problems are continuing, Carol. And let's just take a look at an example. For example, recently a major chocolate maker whose sales for the third quarter of 1999, which was the company's peak shipping period, dropped than $150 million from the previous year. And what was the reason? A software glitch prevented the Halloween candy from being shipped. Now I'm sure that was not the intent of anyone, but here it was an innocent little programming problem that prevented a shipment. The result, of course, was that the candy maker's net income from the same period was down 19% from 1998. So our industry is being hit by software problems. And quality continues to be a challenge. So as I said, standards, or software engineering standards in particular, which is what we're talking about, enable an organization to adopt practices proven by others. Now, if it's a standard, and if you're going to use a market consensus standard, there has to be an assumption that problems are similar. And in fact, they are. I think worldwide there's a recognition now that we all share the same problems, and therefore the option for the solution is also shareable. So in a company's case, most companies are in the production of cars, in chocolates, soap powder, what have you, and using standards and the information there, and leveraging it in, frees up the corporate resources to focus on the core business. So in that sense, we feel that standards are not only a way for companies to pick up on this new technology and share what other people have already learned, and use that effectively. But the standards prevsnt a process, which is what we're focusing on, and I hope that overall process encourages prevention. Which of course is a cost-effective way to deal with software. And as you know, making a correction early can be almost 1/50 or 1/100 of the cost of fixing a problem later. So those are some of the reasons.

Carol: Right. For anyone that's not, in our listening audience, who is not right involved with ISO standards, I think it's important that they know that…You mentioned that's a world standard, that this is a world standard. And there are, as I recall, 25 voting countries and 16 non-voting countries who actually participate in the software engineering standards. Do either of you know…I think that's a correct number, is it not?

Peter: Pretty close.

Carol: Okay. So we have really the world's expertise from Britain and from all over Europe, and from Eastern Bloc countries, and from Australia, and all over the world, bringing in their best practices, to put in this software process standard. Correct?

Peter: Yes.

Carol: Stan, what do you think? Are standards important for a small company of 15 people, as well as large companies or 2,000+ people? What do you think?

Stan: Yes, I believe they are. And because everybody has this same desire to be able to produce quality software at the lowest possible cost. Now, when you apply a standard, or the best of practices, in a small firm, you need to modify it so it meets the needs of your organization. All…Most process standards says we're going to have a review on this document, on this design, etc. In large companies, you can have casts of thousands. But in small companies, you've got to be able to address this process with one or two people. And you can do it. You can have two people sitting down at a desk, or one person, as long as it is not the same person that designed the product or did the plan. So what you have to do is modify the standards to fit your business needs. And I believe that you can achieve high quality software at a reasonable price.

Carol: And we will be back with more of Stan Magee and Peter Voldner after these short messages. I will give you the toll-free number: 866-277-5369, if you'd like to call in. And we'll be back with more of Quality Plus e-Talk after these short messages.

Welcome back. We're talking about process standards, choosing the right software engineering process standards, the best ones for your company. And we've been talking in layperson's terms. One of the things that happens a lot with ISO standards is that people start talking in acronyms. And I think that's part of the root canal type of stigma associated with standards, is that as soon as you start talking about ISOIECJTC1SC7WG7, people's eyes glaze over and they've lost it right after the "ISO." So we've been talking to Stan Magee, who's an expert within the United States, and Peter Voldner, who's an expert within Canada, who are collaborating on a new book on software process standards. Stan, what is the book going to be called?

Stan: This book is the handbook to be used with the process improvement model called SPICE. And we have written one chapter in there, "How to Select the Right Set of Standards to Help You Improve Your Software." And so that's…I believe that's the title of the book now. And the chapter that we wrote.

Carol: Oh, good. And it's forthcoming in…later 2001?

Stan: It's going to be out the third quarter of this year.

Carol: Okay, that's exciting. That'll be your third book, and Peter's first?

Peter: That's right.

Carol: The first of many, I'm sure. Before we went into break, Stan was talking a little bit about why standards are important for a small company. And then we pretty much got cut off when we went into break. So I'd like you to finish your thought there, Stan, if you would.

Stan: Well, standards are important for a small company, just as well as a large company, because they are trying to produce quality software at the lowest possible price. In order to do this, they have to be innovative, and they have to meet their customer needs. And the one way to meet their customer needs is to follow the best of practices that the world, or the national bodies, have set down. But they need to modify the standards, or the best of practices, to meet their business needs. Because you don't need as rigorous process if you're producing game software as you are for producing software for an elevator. So it is very important for small companies to follow the best of practices, but modify them, modify the best of practices, to fit the company needs. So that you can produce software at the lowest possible cost and satisfy your customer needs. Thank you.

Carol: That's a really important thing. I think that a lot of companies have been burned by going and buying methodologies, huge shelfware methodologies, and being a small company, where they've said, "Some of this just doesn't apply." And I think that's a very powerful message you're sending out, which is take the pieces that really matter for a small company. You don't have to do everything that a monolithic, 2,000 or 5,000 developer company would have to do. But pick the pieces and gain benefit for even a small company. Would you agree, Stan?

Stan: I certainly would. You know, pick the 17 software…Out of the 17 software engineering practices, pick the ones that are the most important for your company and concentrate on them. And that is my message, that…Pick the ones that are important to your company, concentrate on them, and increase the quality of your software and reduce your costs.

Carol: That's great. That's great advice. Because I think a lot of people have been…have kind of stayed away from standards, because they figure that it's all overhead. Now, Peter, I know you've got some great ideas about selecting the right software engineering standards for a company or organization. I know that you've developed an approach, between you and Stan, that will help a lot of companies who might have been kind of shying away from using standards in the past. So, how do you select the right software engineering standards for a company?

Peter: Well, Carol, you're quite right. And as Stan said, it's important to choose the right set, because the number of possible software standards is an overwhelming amount. And it may be worth repeating, Carol, that we've got standards from ISO, from IEEE, there are national standards, there are trade group standards, standards initially set. So, selecting the right one presents a challenge. No question about it. And certainly, using 12207.com will give you some insight into the spectrum and the quantity of these standards. Now, Stan and I, to deal with this challenge, developed a simple way to do the selection. And it consists of six simple steps. Now, the essence of this approach is to choose the standard on the basis of a process area that the corporation is interested in. Now, typically when you are tackling a process improvement problem, you're not tackling all of it at once. You will select either requirements or perhaps software testing, perhaps problem resolution, even documentation. Just to name some of the process areas. On the basis of that process area, it sort of cuts down on the number of possible standards and it helps a corporation to focus on those that are most appropriate. Now, you may say, well, how do we choose the process areas? Well, we've chosen them based on the 12207 document, as well as other process standards that are becoming relatively well recognized. So we feel that the process basis is solid and well established as a foundation to build an understanding of what's available. So, that's in essence the principles that we have adopted, Carol.

Carol: And we're going to take a short break for weather, and a couple of other things, messages from our sponsors, and we'll be back to talk more with Stan Magee and Peter Voldner about what are the six steps that you can use to choose the right process standard for your company? And we'll be back shortly.

Welcome back to Quality Plus e-Talk with Carol Dekkers. I'm Carol Dekkers. And we've been talking this week about software process standards. And as one of our guests, Stan Magee, mentioned, when you mention software process standards, people's eyes glaze over. And it's almost like you're inviting them to come to a root canal. I think that's a great analogy. We've been talking to Stan Magee, who's President of the Software Engineering Process Technology Company based in Seattle, Washington. He's also the convener of working group 7, which is the software lifecycle management standards, within the ISO software engineering group. And our other guest is Peter Voldner, who comes to us from Toronto, Canada, who is President of Peregrine Software, whose firm has a goal of helping clients reach higher productivity and quality using the latest in industry best practices, including preparation for ISO 9001. And we've been talking about all these software process standards. And there are hundreds. If anyone does their research, goes onto the Web, and takes a look at the number of software engineering standards that are out there, it's just an absolute quagmire. And the Software Productivity Consortium, out of Maclean, Virginia, has actually come up with a mapping on their Web site of all of these different types of standards. IEEE standards, ISO standards, SPICE standards, you name it. It seems like every time you turn around, another standards group is popping up. So I'd like to commend Stan and Peter for really talking the bull by the horns and creating a pathway that companies can use to kind of wade through this quagmire, this swamp of software engineering standards. Now, along that line, I think a lot of people who are listening know about ISO 9000, or they've read about ISO 9000, and they think that it applies just to manufacturing. They might have heard of the Capability Maturity Model. They've heard mention right now on the show of 12207, and they've heard mention of SPICE, the Software Process Improvement Capability Determination model, which is 15504, but I don't think anyone really has an idea of how these all kind of fit together. Peter, do you have any advice as to how they fit together, or how people can kind of wade through those?

Peter: Yes, Carol. It's a big subject. But let's try to tackle it in a minute or so.

Carol: Okay, I'll start the clock.

Peter: The really interesting part is that they actually do fit together. And the people that have worked on all of them actually are cognizant of their relationships. Now, we all know, ISO 9000 is pretty popular. Lots of software companies are being registered to 9000. It's kind of a pass or fail type of exam, which is based on a set of quality criteria. And ISO 9001 is applicable to the software company as well. Now, guidance on ISO 9000 in the software industry can be handled by an ISO document, 9000 document, and it also can use the 12207 process definitions, and in fact, the new version, the 2000 version of ISO 9000, which is coming out, which has come out, I gather, in fact references 12207. So there is a good match here between 9000 and 12207. So they're really becoming a major force in 12207 in terms of software. Now, 12207 provides a set of definitions around the basic software processes, Carol. And it talks about purpose and requirements for these processes. But for a company that, in an improvement activity, one of the significant tools in the industry has been around for several years. It's a very powerful tool. It's the CMM, or Capability Maturity Model, that was developed by the Software Engineering Institute in the United States. This is used worldwide, because it's widely recognized, has been very effective, and is widely written up. It talks about processes and the characteristics of processes, but it actually is a means by which a company by itself can improve, or in its relationship to a supplier, or can establish criteria for being selected to do a certain contract. Now, there are several…I don't know if that helps, but CMM is actually one of several schemes worldwide. There are schemes in Britain and in Europe, and what ISO did is they decided that it was necessary to have a worldwide consistency in the way in which we measure improvement in the software process. In the way in which we measure the capability or the maturity of a process. So this is where the 15504 standard, which is related to the book that Stan and I are contributing to, and it provides a uniform scheme for CMM and other systems for assessing to be consistently referenced to each other.

Carol: Okay, that definitely helps.

Stan: I also might add, Carol, on my company's Web page, www.12207.com, in the news section, there is a button that says The 3 Major Standards. And it shows the relationship between the quality standard 9000, 9000-3, and the lifecycle process standard 12207, which defines all the processes and tasks for developing and maintaining software from the time you have a gleam in your eye until you retire the software, and the process improvement model recognized at the international level, which is 15504, or referred to sometimes as SPICE.

Carol: I think when people go out to that Web site, they'll see the mapping. I've been out there myself, and I've taken some of your information, Stan, and I've used it in some of my courses. And it very clearly and visually allows you to map the different standards to each other. And I think that's a very powerful thing for companies to be able to use. Now, before we went into the break, Peter was talking about the six steps in choosing a new, a software engineering standard for your company, a process standard. And Stan, could you elaborate? Just tell us briefly, what are these six steps? What are they all about?

Stan: These six steps is a common-sense approach for selecting the right set of standards for your organization. The first step is, make sure that everybody understands the business objectives and the type of software that your company is producing at all levels. Then, determine what processes of the 17 that you use today. Then do a quick assessment of those. You certainly can get in consultants that will charge you $20,000 to spend a week and say, "You're at this level, etc." But probably two or three smart people in your organization can say, you know, the configuration management process is good, or is excellent, or we don't have one. Once you've done this quick assessment, then determine where you're at in the processes that you think are critical to your organization. If you feel that your key processes are out of control and you do not have a good set of processes, then select some rudimentary standards, such as for configuration management, IEEE 828, or quality control. Install these standards. It'll take you anywhere from six months to eighteen months to have the rudimentary standards installed, and you can start to see some improvement in your key processes. Next, select the framework standards that we've been talking about. We recommend the three international ones, but any other standards that are akin to this are okay. Number one, you need one for your lifecycle processes. We recommend IEC ISO 12207. For your quality, ISO 9000. For your process improvement, ISO 15504. Once you've installed these standards, which will take you anywhere from 18 to 24 months, then determine which are the unique process standards for your business. You may need standards for safety plans, you may need, I'm certain that you will need standards for metrics. But put this as the last step. First, install your rudimentary standards if you do not have any. Then put in your framework standards, then select and put in the unique ones that will make your company a world-class developer and maintainer of software. Thank you.

Carol: And those are great steps. I think that it clarifies some of those things that people were wondering about. Where do they start? And by determining the business objectives and the type of software I think is very, very powerful. And we'll be back to take a look at some of the mistakes that people make in implementing standards and benefits of standards when we return from these short messages.

And welcome back to the show. We've been talking about software lifecycle processes. And software processes that you can use to improve your own way of developing better software, on time, on budget, better quality, and in the timeframe that you need to develop it. And we were talking about the six steps to choosing a process standard and implementing a process standard. And just before we went to break, I was mentioning that I think the number one thing that a lot of companies mistake is something that Peter and Stan have been advocating, which is determine the business objective and the type of software you're building. This sounds like it's absolutely fundamental, but yet I know people who say, "We're implementing 12207, or we're implementing 15504," and you say, "Well, what are your objectives?" And they look at you like you're from Mars. "Objectives? You need to have goals?" So I think that's a powerful piece there. Peter, do you…Tell us, where can we get more information on these six steps?

Peter: Good question, Carol. The steps that Stan outlined, he may have gone through and you may not have picked all of it up, so we have prepared a presentation that we've given to some groups. And it abbreviates the discussion of the six steps, Carol. And it's a PowerPoint presentation, and we'll be glad to send it to anyone who will send a request to Stan. His email is [email protected]. That's one way of getting more information. And of course, as we've already mentioned, the new handbook is being published in third quarter 2001, which will refer to what Stan has mentioned that's called SPICE, which is an interesting name, but more importantly, it's the 15504 standard.

Carol: Okay.

Peter: So those are two areas.

Carol: Now, if people go out to the 12207.com Web site, can they email you there, Stan, as well?

Stan: Yes, they can. Just click on my email address there, and just send it in, and we'll send out to you a copy of this PowerPoint presentation. And use it however you like.

Carol: And all they need to do is put in the subject line "six steps…"

Peter: "Six steps" is all you need to say - subject line "six steps" and it's on its way.

Carol: Great. Well, that's very generous of you. Stan, I know that you and Peter have found a lot of mistakes in going around the country and around the world, talking about standards, implementing standards, you see mistakes that companies commonly make. Can you just kind of highlight those for us?

Stan: Yes, the most common one is that the companies try to eat what I call the elephant in one big bite. They think that they're going to go out and buy 85 standards, pour a little bit of water on them, and they'll be installed within 48 hours.

Carol: Wouldn't that be nice?

Stan: You cannot do this. You have to have a well-disciplined plan, and you have to have a reasonable schedule. And it takes anywhere from 18 months to 24 months in order to install a good software engineering process standards program. The other common mistake, as you alluded to, that the companies do not have a clear business objective for implementing standards. Such as reducing cost, improving quality, etc. The companies…A lot of them find that they do not have the support of top management. And every time that the company gets into a budget squeeze, unless they have the support of top management, this is one of the first programs that will go. Companies a lot of times do not report the progress they are making in installing software engineering standards. And this is an important thing, important piece of information that must get to everybody in the company, from the CEO down to the receptionist at the desk. The other important thing is to have adequate training. This is one of the major problems, that unless you have adequate training for all people that are involved in using standards, you will have failure. You've got to train, train, train.

Carol: That means that I can't go out and buy a book of standards, and maybe just buy 20 copies, pass them around the office, and expect people to just start doing it.

Stan: No, you can't, Carol. Because first of all, the words in there are probably words, in some instances, that are not in tune with the culture of your company. You may call requirements documentation, you may call it requirements specification. So you've got to make sure that you have a bridge from the terminology that you use in your company to the standards that you are going to install. So you have to make sure you have training, have to make sure that people thoroughly understand the standards and how to use the best of practices. And this is a continuing process, that you are going to be continually upgrading your standards as long as you're producing and maintaining software. This is not a one-shot program. Thank you.

Carol: And we will be back to sum up after these short messages, with some ideas, some Web sites, and more information on process standards for software.

And we're back. And this hour, as typical, has gone just like the wind. We've been talking about software engineering standards. And for those of you who are still with us, I'm sure you'll agree that this was not a boring subject by any means. It may have surprised you that it wasn't like sitting through a one-hour root canal by any means. And I'd like to very much thank my guests, Peter Voldner and Stan Magee, and say thank you for sharing your hour, your expertise with us. This has been a great time for me to learn a lot more about software engineering standards. So thank you for being part of the show.

Peter: We're delighted, Carol.


Stan: Thank you very much.

Carol: And if people would like to hear more, one of the things that I'm really impressed with is that you haven't used any high-falutin' acronyms. I don't think that you've used any terms that people in software engineering wouldn't be able to understand. And if they'd like to hear more, if they'd like to bring you in to talk to their management, to talk to their CIOs, their Vice Presidents about how easy it is to actually install, and the benefits of software engineering standards, you two are available for hire?

Stan: That's a true statement, Carol.

Carol: Okay, and the best place to reach you both would be at the www.12207.com Web site, is that correct?

Stan: Right.

Peter: That's correct.

Carol: Okay. And I'll give you both about a 30-second sound bite as soon as I introduce next week's show. And then we're going to be having to say we'll e-talk to you next week shortly. So next week's show, we are actually having a rebroadcast. The station had errantly, on March 15, rebroadcast half of Bret Pettichord's presentation on software designers and software testers and why they think differently, and halfway through, it may have appeared that we were schizophrenic and started the Elisabeth Hendrickson show. Well, for those of you who have been actively and on the edge of your seats waiting for the Elisabeth Hendrickson show on how to evaluate software tools, the six-step process, how to go about it, based on Elisabeth Hendrickson's award-winning article, I'd like to invite you to tune in next week when we'll be talking to Elisabeth Hendrickson. And it will be a pre-taped show, but you'll be able to listen and hear what steps you should go through to effectively evaluate software tools, to buy, evaluate, and choose for your company. The week after, we're going to have on April 4, a bonus show. We've got Steven Splaine, who has written a book on Web testing. How do you do testing of Web applications? And he's just written a book which is absolutely phenomenal, layperson's terms, a lot of examples, and he's going to be with us on April 4 to sum up our season before we get into our next season and talk about Web testing. So please join us for that. Again, I'll give you my Web site address, www.qualityplustech.com. We've got courses, a lot of information, a lot of free information, articles, downloads, and we'd love to hear from you about what you think of the show. Stan and Peter, this has been great. We can go out to 12207 and get the best testing standards, the best function point standards, the best of many different types of standards. And I think that a lot of people have gained a lot from listening to this show. Stan, in summary, what would you like to leave our audience with?

Stan: Number one, have clear business objectives for implementing standards. Do it in a well-disciplined, orderly manner, and you should be able to increase the quality of your product and reduce costs. That's my message. Make sure you have a clear business objective for implementing standards.

Carol: Good. Excellent. And Peter, do you have anything you'd like to send away to our audience?

Peter: Well, I hope people are becoming a little more, or a little less frightened of standards. And I'd like people to consider them as documented best practices that have been proven. And also, we haven't mentioned it, but in fact, many companies have excellent internal procedures, and these standards can be adapted to suit you. So we'd like people to give them a try.

Carol: And I think you've just demystified standards geeks. You're not standards weenies, you're not standards geeks, you are down to earth people who are building better software. And I appreciate you being on the show. Until next week, when we come back with Elisabeth Hendrickson and how to evaluate software tools, this is Carol Dekkers saying we'll e-talk to you next week.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.