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
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
