![NEW BOOKS FOR YOUNG READERS.
To the hosts of young readers who bade Dr. Bronson and his nephews Fred and Frank good-by in Hong-
Kong at the end of Part First of The Boy Travellers in the Far East[1] the announcement that, by the
appearance of Part Second of this fascinating narrative, they may once more journey into strange lands
with their young friends, will be a welcome one. Starting from Hong-Kong, the boys continue their
travels down the coast to Singapore, stopping by the way in Cochin China, Anam, Cambodia, and Siam.
From Singapore they sail through the Malayan Archipelago to Batavia, in doing which they cross the
equator. From Batavia they take long excursions into the interior of the island of Java, and here the
reader has again to leave them for a time while they make preparations for further explorations of the
wonderful lands of the Far East.
The book is filled with tales of adventure by land and sea with pirates and wild animals, curious bits of
history, accurate descriptions of strange people and queer customs, animals, birds, and plants. In it the
author has so artfully blended instruction with amusement that the young reader is taught in spite of
himself, and finds the driest facts interesting when presented in this charming form. The letter-press is
supplemented by copious illustrations that appear upon nearly every page. The binding is very
handsome, and the book bids fair to prove one of the notable attractions of this year's holiday season.
Most books of foreign travel are written with the view of cramming the minds of their readers with the
greatest possible amount of information, and the result is apt to be a fit of mental indigestion from
which the victim does not readily recover. In Harry Ascott Abroad,[2] however, the author has carefully
avoided the text-book plan, and has confined himself to the simple relation of an American boy's every-
day experience during a year's residence in Germany, and while travelling in Switzerland and France.
The story is told in the boy's own language, and is made up of just such facts as will interest other
boys, and at the same time teach them what to expect, and what mistakes to guard against, if they
happen to find themselves in a position similar to that of Harry Ascott.
Mrs. Cochran (Sidney Dayre) has earned so enviable a reputation as a writer of short stories for children
that while the "young readers" feel sure that anything from her pen must be interesting, their parents
are equally confident that the tone of the story will be healthy and pure. The Queer Little Wooden
Captain[3] and The Little Lost Girl, the two stories contained in the present volume, are Christmas tales,
both of which, without moralizing, teach how much greater are the joys of giving than those of
receiving.](https://image.slidesharecdn.com/1241044-250516025127-a8e2f895/85/Mastering-Software-Quality-Assurance-Best-Practices-Tools-And-Technique-For-Software-Developers-Murali-Chemuturi-63-320.jpg)
![MAYING.
Oh! who loves May, so sweet and gay?
A long, long way I've been to-day,
Over the fields and down the lane,
Into the copse, and back again;
Such a ramble, such a scramble,
Catching my dress on a blackberry bramble.
All the merry brown bees were humming,
And all the birdies sang, "Who's coming?"
And the butterflies came to my branch of May,
For I've been Queen of the Woods to-day.
FOOTNOTES:
[1] The Boy Travellers in the Far East. Part Second: Adventures of two Youths in a Journey to Siam
and Java, with Descriptions of Cochin China, Cambodia, Sumatra, and the Malay Archipelago. By
Thomas W. Knox. Illustrated. 8vo, pp. 446. New York: Harper & Brothers.
[2] Harry Ascott Abroad. By Matthew White, Jun. 16mo, pp. 94. New York: The Authors' Publishing
Company.
[3] The Queer Little Wooden Captain. By Sidney Dayre. 16mo, pp. 152. Illustrated. New York: The
Authors' Publishing Company.](https://image.slidesharecdn.com/1241044-250516025127-a8e2f895/85/Mastering-Software-Quality-Assurance-Best-Practices-Tools-And-Technique-For-Software-Developers-Murali-Chemuturi-68-320.jpg)
More Related Content
Similar to Mastering Software Quality Assurance Best Practices Tools And Technique For Software Developers Murali Chemuturi (20)
Mastering Software Quality Assurance Best Practices Tools And Technique For Software Developers Murali Chemuturi
- 1. Mastering Software Quality Assurance Best Practices Tools And Technique For Software Developers Murali Chemuturi download https://ebookbell.com/product/mastering-software-quality- assurance-best-practices-tools-and-technique-for-software- developers-murali-chemuturi-2482088 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Mastering Software Testing With Junit 5 Comprehensive Guide To Develop High Quality Java Applications Boni Garcia https://ebookbell.com/product/mastering-software-testing-with- junit-5-comprehensive-guide-to-develop-high-quality-java-applications- boni-garcia-7192334 Maturing Usability Quality In Software Interaction And Value 1st Edition R Jeffries https://ebookbell.com/product/maturing-usability-quality-in-software- interaction-and-value-1st-edition-r-jeffries-2199786 Mastering Software Project Management Best Practices Tools And Techniques Murali K Chemuturi https://ebookbell.com/product/mastering-software-project-management- best-practices-tools-and-techniques-murali-k-chemuturi-5430834 Mastering Software Project Requirements A Framework For Successful Planning Development Alignment 1st Davis https://ebookbell.com/product/mastering-software-project-requirements- a-framework-for-successful-planning-development-alignment-1st- davis-5430836
- 3. Mastering Software Variability With Featureide 1st Edition Jens Meinicke Et Al https://ebookbell.com/product/mastering-software-variability-with- featureide-1st-edition-jens-meinicke-et-al-6789178 Mastering Software Development In R Roger D Peng Sean Kross https://ebookbell.com/product/mastering-software-development-in-r- roger-d-peng-sean-kross-5857712 Mastering Software Development In R Roger D Peng Sean Kross Brooke Anderson https://ebookbell.com/product/mastering-software-development-in-r- roger-d-peng-sean-kross-brooke-anderson-230360276 Agile Technical Practices Distilled A Journey Toward Mastering Software Design Paperback Pedro Moreira Santos Marco Consolaro Alessandro Di Gioia https://ebookbell.com/product/agile-technical-practices-distilled-a- journey-toward-mastering-software-design-paperback-pedro-moreira- santos-marco-consolaro-alessandro-di-gioia-10653456 Mastering Plc Programming The Software Engineering Survival Guide To Automation Programming 1st Mt White https://ebookbell.com/product/mastering-plc-programming-the-software- engineering-survival-guide-to-automation-programming-1st-mt- white-48290434
- 6. MASTERING SOFTWARE Quality Assurance Best Practices, Tools and Techniques for Software Developers Murali Chemuturi J. Ross Publishing; All Rights Reserved
- 7. Copyright © 2011 by Murali Chemuturi ISBN 978-1-60427-032-7 Printed and bound in the U.S.A. Printed on acid-free paper 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data Chemuturi, Murali, 1950- Mastering software quality assurance : best practices, tools and techniques for software developers / by Murali Chemuturi. p. cm. Includes index. ISBN 978-1-60427-032-7 (hardcover : alk. paper) 1. Computer software—Development. I. Title. QA76.76.Q35C45 2010 005.1′4—dc22 2010019184 This publication contains information obtained from authentic and highly regarded sources. Reprinted material is used with permission, and sources are indicated. Reasonable effort has been made to publish reliable data and information, but the author and the pub- lisher cannot assume responsibility for the validity of all materials or for the consequences of their use. All rights reserved. Neither this publication nor any part thereof may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, me- chanical, photocopying, recording or otherwise, without the prior written permission of the publisher. The copyright owner’s consent does not extend to copying for general distribution for promotion, for creating new works, or for resale. Specific permission must be obtained from J. Ross Publishing for such purposes. Direct all inquiries to J. Ross Publishing, Inc., 5765 N. Andrews Way, Fort Lauderdale, Florida 33309. Phone: (954) 727-9333 Fax: (561) 892-0700 Web: www.jrosspub.com J. Ross Publishing; All Rights Reserved
- 8. TABLE OF CONTENTS Foreword ............................................................................................................. vii Preface .................................................................................................................. ix About the Author ............................................................................................. xiii Acknowledgments ............................................................................................... xv Web Added Value™ ........................................................................................ xvii Chapter 1. Quality Assurance Basics ............................................................... 1 Connotations of the Word Quality ................................................................... 1 What Is Quality? .................................................................................................. 2 Specifications ........................................................................................................ 3 Definition of Quality from the Standpoint of the Provider ........................... 4 Quality and Reliability ........................................................................................ 5 Evolution of the Concepts of Quality ............................................................... 8 Quality Gurus ..................................................................................................... 11 Total Quality Management ............................................................................... 16 Are We Giving Adequate Importance to Quality in Organizations? ........... 17 Organizational Goals and Quality Goals ......................................................... 20 Is a Quality Department in Software Development Organizations Really Needed? ................................................................................................... 22 The Present Scenario in Software Development Organizations ................... 23 Chapter 2. Four Dimensions of Quality ........................................................ 25 Background ......................................................................................................... 25 Specification Quality .......................................................................................... 26 Design Quality .................................................................................................... 27 Development (Software Construction) Quality .............................................. 29 Conformance Quality ........................................................................................ 30 iii J. Ross Publishing; All Rights Reserved
- 9. iv Mastering Software Quality Assurance Ensuring Quality in Specifications ................................................................... 31 Ensuring Quality in Design .............................................................................. 32 Ensuring Quality in Development (Software Construction) ........................ 33 Ensuring Conformance Quality ....................................................................... 33 Chapter 3. Software Product Quality ............................................................ 35 Functionality Standpoint ................................................................................... 35 White Box (Glass Box) Standpoint ................................................................. 38 Presence of Defects in the Product ................................................................. 41 Program Quality ................................................................................................ 44 Measurement of Product Quality .................................................................... 48 Chapter 4. Organizational Environment that Fosters a Quality Culture ................................................................................................................ 61 Quality and Organizational Environment ....................................................... 61 Need for an Independent Quality Assurance Department ........................... 62 The Role of the Quality Assurance Department ............................................ 64 The Position of the Quality Assurance Department in an Organization ... 66 Organization of the Quality Assurance Department ..................................... 68 Organization and Staffing of the Quality Assurance Department ............... 74 A Well-Defined and Institutionalized Software Development Process ....... 76 Explicit System of Rewards and Recognition for Achieving Excellence in Quality ............................................................................................................ 80 Commitment and Involvement of Senior Management in Fostering a Culture of Quality in the Organization .......................................................... 82 Final Words ........................................................................................................ 83 Chapter 5. Software Verification .................................................................... 85 Verification ......................................................................................................... 85 Walkthroughs (Peer Reviews) .......................................................................... 89 Inspections ........................................................................................................ 102 Audits ................................................................................................................ 110 Verification Process ......................................................................................... 124 Implementation of Verification Activities in Projects ................................. 126 Chapter 6. Validation ..................................................................................... 129 Definition of Validation .................................................................................. 129 Validation of Software Designs ...................................................................... 132 Validating the Product Specifications ............................................................ 133 Validating the Software Product .................................................................... 133 J. Ross Publishing; All Rights Reserved
- 10. Table of Contents v Testing Different Types of Software Products ............................................. 135 Testing Basics ................................................................................................... 139 Approaches to Testing ..................................................................................... 143 Test Case Design .............................................................................................. 146 Test Environment ............................................................................................ 161 Testing Scenarios ............................................................................................. 163 Project Testing or Embedded Testing ........................................................... 163 Product Testing ................................................................................................ 169 Best Practices in Testing ................................................................................. 178 Automation of Testing and Use of Testing Tools ....................................... 183 Final Words about Software Testing ............................................................. 186 Chapter 7. Software Product Quality: Reliability ...................................... 187 Software Disasters ............................................................................................ 187 Software Reliability .......................................................................................... 189 Cause of Software Failures ............................................................................. 192 Prediction of Software Reliability .................................................................. 194 Software Reliability Improvement .................................................................. 195 Chapter 8. Process Quality ............................................................................ 197 Process Quality Evolution ............................................................................... 197 Process ............................................................................................................... 199 Process Quality ................................................................................................. 200 Process Definition ............................................................................................ 201 Aligning the Process with a Process Model .................................................. 205 Process Improvement ...................................................................................... 206 Process Stabilization ........................................................................................ 209 Software Development Process ...................................................................... 211 Components of a Process ............................................................................... 211 Process Certification ........................................................................................ 213 Chapter 9. New Paradigm for Software Quality ........................................ 217 Current Certification Paradigms .................................................................... 217 The Fallacy of Certifications ........................................................................... 219 Criticisms of Maturity Models ....................................................................... 221 A New Paradigm for Software Quality Assurance ....................................... 228 Final Words ...................................................................................................... 233 Appendix A. Audit Process ............................................................................ 235 Appendix B. Defect Resolution Methodology ............................................ 247 J. Ross Publishing; All Rights Reserved
- 11. Appendix C. Guidelines for Error Guessing ............................................... 257 Appendix D. Guidelines for Graphical User Interface Quality Conformance ................................................................................................... 263 Appendix E. Guidelines for Stress Testing ................................................. 273 Appendix F. Guidelines for Negative Testing ............................................. 279 Appendix G. Measurement of Quality ......................................................... 287 Appendix H. Quality Assurance of Databases ............................................ 305 Appendix I. Coding Guidelines .................................................................... 309 Appendix J. Sample Review Process ............................................................ 323 Appendix K. Software Quality Assurance Plan ........................................... 337 Appendix L. Abbreviations ............................................................................ 345 Index ................................................................................................................. 347 vi Mastering Software Quality Assurance J. Ross Publishing; All Rights Reserved
- 12. FOREWORD As I sit surrounded by the majestic forests and glacial lakes in the North American state of Maine, I am reminded of how the laws of nature, planet Earth’s natural processes, have carefully constructed, nurtured, and sustained this stun- ning example of natural engineering and process implementation. Strict compliance with this natural process, rather than process experimentation and impro- visation, has allowed these forests to grow and thrive unencumbered by the special cause of variation from destructive forces. Indeed, the natural world has suffered from attempts to circumvent this process with disastrous results, and when left to recover does so with alarming alacrity and efficiency. There is much to be learned from this natural process that can be applied to the software engineering discipline. Granted, software engineering does not have the luxury of unlimited time and resources, and business will not wait eons for change to occur. But the application of and compliance with a basic process architecture—which in- cludes at its foundation software quality assurance—is the key to wringing value from engineering process improvement. A thoughtfully constructed architecture with software quality assurance serv- ing the foundational role of mentor, messenger, and accelerator will lay a foun- dation for flexibility in a process designed to serve and support a wide variety of projects with different objectives. In this sense, we require a “set of standard processes,” not a single standard process, that comply with our process archi- tecture and are supported by a robust and flexible software quality assurance organization. vii J. Ross Publishing; All Rights Reserved
- 13. Like a great concert violinist who spends years embracing and developing the discipline and mechanics of his or her craft before learning his or her first concerto and venturing onto the concert stage, software engineers cannot achieve creative success without embracing an appropriate process architecture and learning to master their craft by first mastering the natural laws that guide them. Too long has software engineering been hampered by cowboy-style coding— a behavior that appears heroic at the time, but that proves to be damaging in so many ways in the long run. It’s high time someone wrote at length about the role of software quality assurance and process compliance in the software en- gineering field. Murali’s book breaks new ground and gives us a glimpse into the promise of disciplined, productive, and efficient software engineering. It paints a picture of a brighter future for an industry that has long been suffering from cost and quality issues and will allow software engineers to reach new levels of performance and creativity. Jeff Dalton President and CEO, Broadsword Solutions Corporation www.broadswordsolutions.com SCAMPI Lead Appraiser www.askTheCMMIAppraiser.com viii Mastering Software Quality Assurance J. Ross Publishing; All Rights Reserved
- 14. PREFACE Gerald M. Weinberg, author of the book The Psychology of Computer Program- ming, is attributed with the quote “If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.” According to an anonymous quote, “Software and cathedrals are much the same; first we build them, then we pray.” And the confidence in software de- velopers continues to grow. If manufacturers controlled and assured quality the way software developers do, I think many accidents and injuries, even fatalities, would be the sad result. Many, many improvements have been made in the way programs are written, but even after nearly 50 years of software development history, the approach to software quality still leaves much to be desired. While manufacturing learned from construction and construction in turn learned from manufacturing, soft- ware development stubbornly refuses to learn from either industry, especially in the matter of quality assurance of deliverables. At the beginning of my career in the 1970s, I was employed at a manufac- turing organization that produced control instrumentation for atomic reactors. In that organization, quality was sacrosanct and very rigorous. The result of such high standards of quality is that in a third-world country (as it was in the 1970s, when the reactors were built), the atomic reactors have been working without accident or mishap for the last 40 years! I attribute that record to the importance that was given to quality assurance. I narrate but one incident from that expe- rience: On the last day of the fiscal year, the quality department held up a shipment that would have added significantly to the financial results, as it found a “tiny scratch” on the painted surface of the back side of one piece of the equipment. Even though the scratched surface would have been facing a wall, rectification was insisted upon, and the shipment was released late in the evening only after the “tiny scratch” was fixed. The paint shop guys worked furiously ix J. Ross Publishing; All Rights Reserved
- 15. to repair that insignificant defect. The boss did not berate the quality depart- ment for pointing out an insignificant defect, but rather educated the handlers on the necessity of careful handling. Contrast this with the software industry, where important software such as an operating system is shipped with so many bugs that it needs a service pack within three months of its release to make it function and another service pack a year later to fix the remaining bugs. Windows 2000 had four service packs, XP had three service packs, and a service pack for Vista has already been re- leased. I have come across a few situations where software is delivered with known defects to be corrected as part of warranty services or product support. When I switched over to the software development industry in the early 1980s, my first surprise was that there was no inspection or testing of the pro- grams developed. The programmer certified the program, and if there were any issues with it, they were due to improper data or usage. The programmer would make the program better, if and when necessary. Never was it said that perhaps the program lacked quality, nor did anybody accept that inferior quality was a possibility. Things did change later on. Peer reviews and testing emerged as standard procedure, followed soon after by independent verification and validation. But even now, I do not find the rigor of software quality assurance to be anywhere near the rigor of quality assurance that I was used to in the manufacturing industry where I was employed in the early 1970s. Most people in the software development industry abhor the terms “inspection” and “testing” and use veri- fication and validation instead. Whereas inspection and testing imply detail and have a ring of authority to them, verification and validation somehow connote cursory actions that lack any true authority. In manufacturing, inspection is carried out by persons specialized in inspection, and testing is carried out by persons specialized in testing. In the software industry, however, the “indepen- dent” in independent verification and validation means someone other than the person who programmed the software; it does not mean a specialist. In manufacturing, there are no agencies that certify the maturity of capabil- ity, such as the Software Engineering Institute (SEI) of Carnegie Mellon Uni- versity, except for the International Organization for Standardization (ISO), which certifies for process quality. While automobiles have been manufactured for over 100 years, an automobile manufacturing capability maturity model does not exist! A quality department is sine qua non in the manufacturing industry even though no certification model requires it. In the software development industry, however, no model suggests that a quality department is necessary. I know of many software development organizations that do not have a quality assurance department. Most of these organizations are ISO certified and x Mastering Software Quality Assurance J. Ross Publishing; All Rights Reserved
- 16. rated at a Capability Maturity Model or Capability Maturity Model Integration maturity level 3 or higher by SEI. The software development industry seems to understand that quality assurance is nothing but testing. You can find many advertisements seeking applications for the position of quality assurance engi- neer—to do software testing. How this misunderstanding came about, I do not know, but nothing could be more wrong than this misconception. There is a lot of room for improvement in quality assurance in the software development industry, and a comprehensive reference on quality assurance is needed that ties together all aspects of quality assurance, not as the software development industry does but in its true spirit. Hence this book. Feel free to e-mail me at [email protected] with your thoughts, ques- tions, or criticisms. I will respond to all e-mails. I look forward to hearing your feedback. Murali Chemuturi Preface xi J. Ross Publishing; All Rights Reserved
- 17. J. Ross Publishing; All Rights Reserved
- 18. ABOUT THE AUTHOR Murali Chemuturi is an information technology and software development subject matter expert, hands- on programmer, author, consultant, and trainer. In 2001, he formed Chemuturi Consultants, an infor- mation technology consulting and software develop- ment firm that helps software development organi- zations achieve their quality and value objectives. The firm provides training in several software engineer- ing and project management areas such as software estimation, test effort estimation, function point analysis, and software project management, to name a few. The firm also offers a number of products to aid project managers and software development pro- fessionals, such as PMPal, a software project management tool, and EstimatorPal, FPAPal, and UCPPal, a set of software estimation tools. Mr. Chemuturi has over 15 years of industrial experience in various engi- neering and manufacturing management positions, as well as more than 23 years of information technology and software development experience. His most recent position prior to forming his own firm was Vice President of Software Development at Vistaar e-Business Pvt., Ltd. Mr. Chemuturi’s undergraduate degrees and diplomas are in electrical and industrial engineering and he holds an MBA and a postgraduate diploma in computer methods and programming. He has several years of academic expe- rience teaching a variety of computer and information technology courses such as COBOL, Fortran, BASIC, computer architecture, and database management systems. xiii J. Ross Publishing; All Rights Reserved
- 19. In addition to being a widely published author in professional journals, Mr. Chemuturi is a member of the Institute of Electrical and Electronics Engineers, a senior member of the Computer Society of India, and a Fellow of the Indian Institute of Industrial Engineering xiv Mastering Software Quality Assurance J. Ross Publishing; All Rights Reserved
- 20. ACKNOWLEDGMENTS When I look back, I find that there are so many people to whom I should be grateful. Be it because of their commissions or omissions, they made me a stronger and a better person and both directly and indirectly helped to make this book possible. It would be difficult to acknowledge everyone’s contributions here, so to those whose names may not appear, I wish to thank you all just the same. I will have failed in my duty if I did not explicitly and gratefully acknowl- edge the following persons: 夹 My parents, Appa Rao and Vijaya Lakshmi, the reason for my very existence. Especially my father, a rustic agrarian, who by personal example taught me the virtue of hard work and how sweet the aroma of sweat from the brow can be. 夹 My family, who stood by me like a rock in difficult times. Especially my wife, Udaya Sundari, who gave me the confidence and the belief that “I can.” And my two sons, Dr. Nagendra and Vijay, who pro- vided me the motive to excel. 夹 My two uncles, Raju and Ramana, who by personal example taught me what integrity and excellence mean. 夹 Drew Gierman, Publisher & Vice President of Sales at J. Ross Pub- lishing, especially for his belief in the content of this book, for his generous allocation of time, and for leading me by the hand through every step of making this book a reality. 夹 Steve Buda, Sandy Pearlman, and the staff of J. Ross Publishing, all of whom were involved in bringing this book to the public. 夹 Ms. Sandra Rychel of Montreal, Canada, who pored over every word of this book to ensure that each is the right one. But for her editing genius, this book would not have been as readable as it is now. xv J. Ross Publishing; All Rights Reserved
- 21. To all of you, I humbly bow my head in respect and salute you in acknowledg- ment of your contribution. Murali Chemuturi xvi Mastering Software Quality Assurance J. Ross Publishing; All Rights Reserved
- 22. xvii Free value-added materials available from the Download Resource Center at www.jrosspub.com At J. Ross Publishing we are committed to providing today’s professional with practical, hands-on tools that enhance the learning experience and give readers an opportunity to apply what they have learned. That is why we offer free ancillary materials available for download on this book and all participating Web Added Value™ publications. These online resources may include interac- tive versions of material that appears in the book or supplemental templates, worksheets, models, plans, case studies, proposals, spreadsheets and assessment tools, among other things. Whenever you see the WAV™ symbol in any of our publications, it means bonus materials accompany the book and are available from the Web Added Value Download Resource Center at www.jrosspub.com. Downloads available for Mastering Software Quality Assurance: Best Practices, Tools and Techniques for Software Developers consist of a comprehensive tool for assistance in software testing (TestPal), a tool for increasing personal effective- ness (PET), and templates illustrated within the text that are adaptable to your own needs. J. Ross Publishing; All Rights Reserved
- 23. J. Ross Publishing; All Rights Reserved
- 24. 1 1 QUALITY ASSURANCE BASICS CHAPTER OVERVIEW 夹 Connotations of the word quality from the standpoint of end users, providers of goods and services, industry associations, and govern- ment bodies 夹 Existing definitions and a proposed comprehensive definition for the term quality 夹 Difference between quality and reliability 夹 Evolution of the concepts of quality 夹 Brief sketches of the quality gurus 夹 Introduction to total quality management 夹 Importance given to quality in software development organizations CONNOTATIONS OF THE WORD QUALITY We often see the word quality used as a stand-alone term, without any adjectives attached to it. People do not normally use the term good quality to express their satisfaction with the products or services they use. To say that a certain product is a quality product implies that the product is of good quality. On the other hand, people certainly use the term bad quality to express their dissatisfaction with the products or services they use. Therefore, the adjective good is implicitly attached to the word quality in the minds of most people. Thus, the word quality connotes good quality to most people, including technical professionals. J. Ross Publishing; All Rights Reserved
- 25. 2 Mastering Software Quality Assurance Before attempting a more elaborate definition of quality, let us consider the various connotations the word invokes, as it means different things in different sections of society: 夹 For a customer or end user of a product, quality connotes defect-free functioning, reliability, ease of use, acceptable levels of fault toler- ance during use, and safety from injury to people or property. 夹 For a customer or end user of a service, quality connotes reliability of performance, ease of obtaining service, expert service, pleasant service, and protection from consequential damage. 夹 For a producer of goods, quality connotes conformance of the prod- uct to specifications, which may be defined by a government body, an industry association or standards body, or by the producer’s own organization. 夹 For a provider of services, quality connotes meeting deadlines and de- livery of service that conforms to customer specifications and standards which may have been set by a government body, an industry association or standards body, or by the provider’s own organization. 夹 For government bodies, quality connotes safety and protection of consumers from fraud. 夹 For an industry association or standards body, quality connotes safeguarding the industry’s reputation, protecting the industry from fraud and lawsuits, and addressing the concerns of consumers, gov- ernment bodies, and the industry itself. Given the above distinctions in the meaning of quality, it is clear that the word has multiple connotations attached to it. WHAT IS QUALITY? Before proceeding further, we first need to define the word quality in a manner that addresses all the connotations noted above. The International Organization for Standardization (ISO 9000, second edition, 2000) defines quality as the degree to which a set of inherent characteristics fulfills requirements. Quality can be used with such adjectives as poor, good, or excellent. Inherent, as opposed to assigned, means existing inside something, as a permanent characteristic. This definition contains three key terms: requirements, characteristics, and degree. Requirements can be stated by a customer in a made-to-order scenario or by prod- J. Ross Publishing; All Rights Reserved
- 26. Quality Assurance Basics 3 uct specifications in a commercial off-the-shelf product scenario. Characteristics refers to the capability of the deliverable or, in other words, the robustness (fitness) of the product. The word degree implies that quality is a continuum, beginning with zero and moving toward, perhaps, infinity. This inference, however, is ambiguous and leads to the wrong perception. What is the level at which quality is called “poor” or “good” or “excellent”? More importantly, who is authorized to define the terms “poor,” “good,” and “excellent”? Another popular definition of quality, as defined by Joseph Moses Juran, is fitness for use, with fitness and use being crucial to proper understanding of quality. Unless we define these two key words, the definition of quality is in- complete. Consumer interpretations and provider interpretations of these two terms often are at loggerheads. SPECIFICATIONS Because fitness and use are crucial terms, they cannot be left open to interpretation. Organizations often define these two terms in their specifications for a product or service they provide. Let us look closely at the attributes of specifications: 夹 Specifications may be explicit or implicit. Explicit means that the provider selects the specifications and makes them available to cus- tomers. Implicit means that the specifications are not defined but are understood to be necessary; examples include safety, security, and fault tolerance requirements. 夹 Specifications may be defined by either the provider or an external body, such as a government organization, an industry association, or a standards body. They are made available to customers, and they are adhered to by the provider. Oftentimes, providers resort to unethical definitions of specifications and provide services or products that can be detrimental to customers and perhaps to the industry. This has resulted in industry organizations coming together to form associations, such as manufacturers associations and service provider as- sociations, which define specifications for their particular industry’s products or services. Governments also step in and form standards bodies, which define specifications for various products and services. Defense departments of various countries often define specifications for the diverse range of products to be used by their armed forces. These specifications stipulate a minimum set of standards J. Ross Publishing; All Rights Reserved
- 27. 4 Mastering Software Quality Assurance to be adhered to by providers of products or services, so that fitness for use is defined and ensured. Such formally defined specifications become industry standards and are re- leased by industry associations to the general public for a nominal fee that covers the cost of production and distribution of these standards. Examples of bodies that release standards on a regular basis include the American National Stan- dards Institute, British Standards Institute, Joint Services Specifications, Deutsches Institut für Normung, ISO, International Electrotechnical Commission, Inter- national Telecommunications Union, National Electrical Manufacturers Asso- ciation, and Institute of Electrical and Electronics Engineers. In recognition of their contributions to quality and general consumer well-being, a day has been set aside every year to celebrate such organizations: World Standards Day is October 14. Standards specify, at a minimum, the following: 1. Attributes of the components that make up a product, which may include the material used and the dimensions and methods of testing the product 2. The intended use of the product or service 3. The limitations of the product that need to be conveyed to customers 4. The process by which the components are made 5. The security and safety parameters that need to be built in Understanding that specifications are at the heart of quality, we can now define the term in a more cogent manner. Moreover, it is important that quality be defined from the standpoint of the provider, as it is the provider that builds quality into products or services, and it is at the provider’s location where quality is ensured. DEFINITION OF QUALITY FROM THE STANDPOINT OF THE PROVIDER Quality is an attribute of a product or service provided to consumers that conforms in toto to or exceeds the best of the available specifications for that product or service. It includes making those specifications avail- able to the end user of the product or service. The specifications that form the basis of the product or service pro- vided may have been defined by a government body, an industry as- J. Ross Publishing; All Rights Reserved
- 28. Quality Assurance Basics 5 sociation, or a standards body. Where such a definition is not available, the provider may define the specifications. This definition of quality mandates that the provider: 夹 Define specifications if they are not already defined by a higher body, such as a government body, an industry association, or a standards organization 夹 Adhere to the best of the available definition of specifications 夹 Ensure conformance is 100% or better—no less 夹 Make available to the customer the specifications to which conform- ance is ensured The result of a product or service that meets the above definition of quality is that the customer is able to effectively use the product for the length of its life or enjoy the service fully. This result further mandates that the provider is responsible for providing any support that is required by the customer for the enjoyment or utilization of the product or service throughout its life. Any product or service that meets the requirements of this definition is rated a “quality product/service,” and any product or service that does not meet the requirements of this definition is rated “poor quality.” QUALITY AND RELIABILITY Quality and reliability are intertwined and are inseparable, but what does reli- ability mean? Reliability of a product is its capability to function at the defined level of performance for the duration of its life. Two phrases are critical in this definition: 1. Defined level of performance—Performance level is defined in the specifications for the product or service. It should be 100% or more of the specifications and no less. Continuous use is also a specifica- tion. For example, a car may be capable of being driven at 100 miles per hour, but how long can a car withstand being driven continuously at that speed? Normally, performance is defined at two levels: normal performance and peak performance. J. Ross Publishing; All Rights Reserved
- 29. 6 Mastering Software Quality Assurance 2. Duration of its life—Duration needs to be specified for normal per- formance as well as peak performance. A product has two lives: 夹 First life or initial life—Initial life, before any repairs become necessary, normally is specified as the warranty or guarantee pe- riod. After expiration of this life, regular maintenance may be required to maintain performance at the level specified for the product. 夹 Operating life—The period of time after the warranty expires, assuming maintenance is performed. After expiration of this life, it may not be economical to maintain the product to operate at the specified level of performance. In other words, quality involves delivering the specified functionality under the specified conditions, and reliability involves delivering the specified functional- ity at a specified level of performance over the duration of the product life, even with slight deviations in the specified conditions. While initial life is specified by manufacturers as the warranty period, the life after the warranty period usually is not specified. If it is, it is specified with such stipulations as “subject to the condition that the product is maintained and serviced by our own expert technicians” or something similar. If product main- tenance is entrusted to the manufacturer or its authorized maintenance shop, the manufacturer specifies two norms: mean time between failures and mean time to repair. Mean time between failures is the average period between two successive failures, assuming that proper maintenance is performed every time and main- tenance conforms to the manufacturer’s stipulations. It is expressed in the num- ber of running hours for the product. Mean time to repair is the average time it takes to restore the product to its original functionality by carrying out the necessary repairs. It is expressed in the number of clock hours it takes to repair the product. Reliability is gauged by these two measures. In terms of software, an observation often made is that software has no moving parts that cause the product to deteriorate through wear and tear. Once a software product functions at its defined level of quality and functionality, there should be no need for maintenance. Therefore, the term reliability should not be applicable to software. However, this reasoning is true only if the con- figuration on which the software product runs remains unaltered. If the hard- ware and software configurations are unchanged, no repairs should be neces- sary, rendering the attribute of reliability inapplicable. These days, however, J. Ross Publishing; All Rights Reserved
- 30. Quality Assurance Basics 7 many other factors play a role in how stable the hardware and software configu- ration remains. The following are a few common situations that can alter the configuration of hardware and software: 1. New operating systems enter the market every three years. 2. New Web browsers or updates to current browsers are released regularly. 3. New viruses and spyware are unleashed on unsuspecting Internet users. 4. Computers often are flooded with a host of new tools, ranging from office suites to antivirus software to downloadable utilities. 5. Changes are introduced to tiers (middleware) in multitier architec- ture software products. 6. Software products may make use of shared libraries that are part of the system software supplied along with the operating system. It is likely that these shared libraries are updated or modified. 7. Software products may make use of third-party code libraries to perform special functions such as rules processing, database inde- pendence, etc. These third-party code libraries may be updated or modified. 8. Installing and uninstalling utilities on a system may result in changes to or removal of the shared libraries used by a software product. All of these activities change the configuration of the system on which a software product is running, and this is where the question of software reliability comes into play. A software product is said to be reliable if it can withstand minor patches to the operating system and to the middleware. As software quality professionals cannot predict what future upgrades will be made to the system software (be it the operating system, database, browser, or middleware), they cannot specify the reliability of software in running hours. They also may not be able to specify the mean time between failures of a soft- ware product in running hours, because a software product does not fail due to use over a number of hours. It can, however, fail due to a change in the system configuration. Such is the case with mean time to repair, because the repair is not to restore the software to as near the original condition as possible but rather to remove the impact of some change in the system configuration. Nonetheless, software quality professionals recognize that the term reliability is applicable to the domain of software. Some hints for building reliable software are offered in this book. J. Ross Publishing; All Rights Reserved
- 31. 8 Mastering Software Quality Assurance EVOLUTION OF THE CONCEPTS OF QUALITY Although quality is an age-old word, its understanding at the organizational level has evolved in recent times, especially since World War II. Initially, it was thought that only the artisan could achieve a “quality” product state. However, as the Industrial Revolution moved manufacturing out of artisans’ shops and into factories, with multiple artisans working on a single product, the supervisor became pivotal in achieving a quality product. If a part was missing or a bolt was loose, it was the supervisor’s fault for not noticing it. As pressure on the supervisor to ensure quality increased, actual supervision took a back seat, which affected productivity and production. It finally dawned on management that appointment of an independent inspector was needed to ensure that every part was mounted properly and every bolt was tightened. Thus came about the profession of inspection, along with the development of a host of inspection tools, techniques, and methods. Inspec- tion became a research area in itself. Examples of tools developed specifically for inspection that are now standard in manufacturing milieus include “go/no-go” gauges and inspection jigs. Inspection, as a link in the manufacturing chain (see Figure 1.1), served well for some time, but became inadequate as the functionality of products became more varied. Ensuring that every part is properly mounted and that every bolt is properly tightened was soon found to be inadequate to ensure proper func- tioning of products. This was especially true for electrical products like motors and machines, as such products required functionality testing in addition to overall inspection. It was realized that inspection alone was not enough to ensure the quality of products and that products leaving the factory should be tested for their functionality as well. Around the same time, subcontracting of the manufacture of parts to spe- cialized manufacturers began to take place, starting in the auto industry. This brought in a new issue: ensuring the quality of inputs. Thus, inward inspection (inspection of parts received from suppliers and subcontractors) and testing also arose. Batch and job manufacturing also began to emerge around the same time, resulting in a new concept: quality control (see Figure 1.2). A host of new lit- Figure 1.1. Inspection Inspection J. Ross Publishing; All Rights Reserved
- 32. Quality Assurance Basics 9 erature on methods of quality control came into being, including sampling inspection, statistical quality control, control charts, and so on. Up to this point, the emphasis in terms of quality was on ensuring the quality of manufacturing. As competition increased among manufacturers and as or- ganizations began to provide similar—and perhaps better—products, it was discovered that products can fail because of design defects, even if the manu- facturing quality was tightly controlled. One example that comes to mind is two brands of two-wheel scooters: Vespa and Lambretta. Both were similar in terms of horsepower and in the specification of being able to accommodate two people, yet they were different in design. The Vespa used a shaft-based power transmis- sion, while the Lambretta used a chain-based power transmission. Lambretta ultimately closed down, while Vespa is still in business today. The lack of popu- larity of the Lambretta scooter was not due to an issue of manufacturing quality. Rather, it was an issue of design, and therefore an issue that affected the very survival of the organization itself. The quality of a product design, which de- pends on the specifications set for that product, is equally, if not more, crucial to the success of the product as is the control of quality during the manufac- turing stage. In order to achieve better design, it became necessary for manufacturers to establish design guidelines, drawing upon the experience and knowledge of organizations in a particular industry, as well as feedback from the field (cus- tomer complaints, maintenance personnel observations, and studying competi- tors’ products). This resulted in the development of standards and guidelines to ensure quality of design and specifications. Design reviews followed to ensure quality in product design. While this aspect of product design surely belonged in the arena of quality, it was beyond the capacity of an organization’s quality control department. This development gave rise to the concept of quality assurance (as depicted in Figure 1.3), an integral part of manufacturing that includes inspection, testing, and standards for design. There is a misconception in the software development industry that quality assurance means testing. I am not sure how this misconception came about. Testing is testing; quality assurance encompasses inspection (verification), test- Figure 1.2. Quality control Inspection Testing J. Ross Publishing; All Rights Reserved
- 33. 10 Mastering Software Quality Assurance ing, and standards. In the glossary of the Capability Maturity Model Integration (CMMI®) model document for development (version 1.2, 2006), quality assur- ance is defined as “a planned and systematic means for assuring management that the defined standards, practices, procedures, and methods of the process are applied.” One occurrence of note that had a significant impact on the evolution of the concepts of quality was the transformation Japanese manufacturing organiza- tions underwent. Japanese manufacturers rose from their reputation as suppliers of cheap, poor-quality goods to become suppliers of high-quality products. It was a phenomenal transformation, and studies conducted on Japanese manu- facturing methods were widely publicized. Some of these methods include quality control circles, zero defects, and right first time. One of the Japanese techniques widely adopted by manufacturers across the world is quality control circles, or simply quality circles, as they popularly be- came known. A quality circle is a voluntary association of workers from the same facility who meet to discuss quality-related issues in their facility and come up with possible solutions to improve quality. If their discussions point out a defect, together they come up with a solution, trying it out on a pilot basis and pre- senting the results to management. If management is satisfied with the proposal, it is implemented, and the members of the quality circle that came up with the suggestion are rewarded. It was reported that the Japanese manufacturing industry benefited greatly from these quality circles, and these benefits were felt all over the world in the form of improved goods from Japan, a nation now known for its high-quality products. While the concept of quality circles was welcomed by other econo- mies, its implementation did not produce such spectacular results elsewhere. India in particular wholeheartedly adopted this concept and spent a consider- able amount of resources to implement it, but did not achieve any tangible or auditable, positive, and commensurate results. However, what the transformation in the quality of Japanese products did result in was the awareness that quality is not just the responsibility of the quality Figure 1.3. Quality assurance Standards and Guidelines Inspection Testing J. Ross Publishing; All Rights Reserved
- 34. Quality Assurance Basics 11 department alone; it is an organizational issue. If quality is neglected, the very survival of the organization may be at stake. This realization led to the devel- opment of the concept of total quality management, which requires the entire organization be involved in achieving quality—not just in terms of deliverables, but in every activity of the organization. The organization is seen as a culture— a culture based on quality—that views quality as a critical ingredient in all of its activities. The development of technology created a new dimension to help achieve quality: robots. Japan again took the lead and extensively deployed robots in its factories. Since the chance of human error was removed from a significant number of operations, the probability of defects was eliminated. Thus, the need for inspection became marginal, although testing remained important. It simply was not possible to inspect everything. Take, for example, a gearbox assembly. Once assembled, the inside cannot be inspected unless the gearbox is opened, but if it is opened, it has to be reassembled. This gave rise to the concept of process quality, which embeds the concept of quality into the manufacturing process itself. QUALITY GURUS No book on quality can be complete without noting the contributions of the pioneers in quality: William Edwards Deming, Joseph Moses Juran, and Philip Bayard Crosby. Very brief sketches of these gurus are given in the following sections. William Edwards Deming Dr. William Edwards Deming is considered by most people to be the father of modern philosophy on quality. Deming was a consultant to Japan in the early 1950s and helped Japanese companies attain worldwide success. The Japanese government recognized his contribution and honored him with the Order of the Sacred Treasure, Second Class in 1960. In the 1970s, Deming’s philosophy was summarized by his Japanese disciples as follows: 夹 When organizations concentrate on quality, quality tends to rise over a period of time, and costs tend to fall. 夹 If organizations focused on costs, costs would rise and quality would decline over a period of time. J. Ross Publishing; All Rights Reserved
- 35. 12 Mastering Software Quality Assurance In short, quality improves productivity. This philosophy was proven by Japanese companies, and they are among the world’s best today. In 1981, after it incurred a loss of $3 billion, Ford Motor Company recruited Deming as a consultant. By 1986, Ford became the most profitable of the Ameri- can automobile manufacturers. The turnaround was credited to Deming. He proposed a new way of looking at management, offering 14 key principles for business success in his book Out of the Crisis, published in 1986. These prin- ciples, now known as the famous “Deming’s 14 Points,” can be summarized as follows: 1. Constancy of purpose—Create constancy of purpose toward im- provement of product and service. The purpose is important, and it needs to be constant over a period of time. 2. Adopt the new philosophy—Conditions change, and the philoso- phy ought to be aligned with the current conditions. 3. Statistical inferencing—Deming advocated the use of statistical tech- niques for quality control in place of 100% inspection of mass- produced components. 4. Price—When making buying decisions, Deming suggested doing away with the practice of awarding contracts on the basis of lowest price. This rationale gave rise to the present-day two-bid (technical bid and financial bid) system for selecting vendors. 5. Improve continuously—Find problems and solve them. 6. On-the-job training—Deming advocated that organizations pro- vide learning opportunities on the job, as well as guided learning. 7. Supervision—Deming advocated leadership in place of supervision in organizations. 8. Fear—Deming strongly felt that fear should not be used as a mo- tivator in organizations. He suggested driving fear out of organiza- tions so that everyone can work effectively. 9. Barriers—Deming scorned watertight walls between departments in organizations. He recommended that people work together so that they can learn from each other. 10. Methods—Deming recommended development and provision of right methods of working to obtain results. He was against exhor- tations and slogans. He stated that targets, without using the right methods to achieve them, are meaningless. He clarified that most of the causes of low quality and low productivity are beyond the people who perform the work. J. Ross Publishing; All Rights Reserved
- 36. Quality Assurance Basics 13 11. Eliminate quotas—Perhaps Deming recognized the unlimited po- tential of human beings to improve productivity. He therefore ar- gued that numerical quotas should be eliminated. He suggested man- agement by objectives and leadership in order to improve output. 12. Pride—Deming argued that workers feel proud of their work-re- lated achievements, and they should not be robbed of this pride by annual performance appraisals. He suggested the removal of any barriers that could stand between workers and their pride in their workmanship. 13. Retraining and education—Deming strongly advocated educating employees as a means of increasing their awareness and improving their sense of responsibility and ownership. 14. Management—Deming suggested a structured management to drive the above 13 points in the organization, to achieve the desired trans- formation in the organization. Deming short-listed the four stumbling blocks to transforming a business into a vibrant organization caused by management: 1. Neglecting long-range planning 2. Relying on technology to solve problems 3. Seeking proven methods rather than developing new solutions 4. Hiding behind the excuse “our problems are different” Deming advocated a four-step cycle for transformation to a successful business: 1. Plan—Plan for the action. 2. Do—Carry out and implement the plan. 3. Check—Check the results of the action and draw inferences. 4. Act—Modify the plan as necessary. Deming’s 14 principles and plan-do-check-act cycle are used outside the manufacturing area, in various fields, with success. Joseph Moses Juran Dr. Joseph Juran led an active working life for about 70 years, and his Quality Control Handbook (first edition, 1951) is still a reference for quality professionals today. Juran started his career at the Hawthorne Works of Western Electric and J. Ross Publishing; All Rights Reserved
- 37. 14 Mastering Software Quality Assurance rose to the position of chief industrial engineer at its headquarters. Later, Juran became chairman of the department of administrative engineering at New York University, where he taught for quite a few years. He was also a consultant and the author of several books. Juran was an active member of the American Management Association, on behalf of which he delivered many lectures internationally. His management philosophies are now embedded in American and Japanese management phi- losophy. He developed a quality trilogy, which can be summarized as follows: 1. Quality planning—Begin by identifying customers and their needs, and then develop a product that meets those needs. Optimize the product so as to meet the organization’s needs as well as the custom- ers’ needs. That is, quality starts with specifications and design. 2. Quality improvement—Define a process that can produce the prod- uct, and then optimize the process. That is, quality depends on the process. 3. Quality control—Test and prove that the process can successfully produce the product, and then implement the proven process in operations. The Union of Japanese Scientists and Engineers invited Juran to Japan to teach the principles of quality management after World War II. His lectures were published as a book titled Managerial Breakthrough (1964). He was awarded the Order of the Sacred Treasure, Second Class by the emperor of Japan. Juran also founded the Juran Institute, a consulting company through which he could propagate his ideas and work; it is one of the leading consultancies in quality management. He was the first to incorporate human aspects into quality management, which helped to shape the concept of total quality management. Joseph Juran also is credited with the popular definition of quality: fitness for use. Philip Bayard Crosby Philip Crosby was a businessman and author who contributed to general man- agement theory and quality management practices. He began his career at ITT Corporation and then opened his own consultancy under the banner Philip Crosby Associates, Inc., which now operates in eight countries. His books Quality Is Free (1979) and Quality without Tears (1984) are still popular today. Crosby defined quality as conformance to certain specifications set forth by management and not to some vague concept of “goodness.” The specifications J. Ross Publishing; All Rights Reserved
- 38. Quality Assurance Basics 15 are not arbitrary either; they must be set according to customer needs and wants. Crosby promoted the popular phrase “do it right the first time,” or DIRFT, and the concept of zero defects. He compiled four principles of quality: 1. The definition of quality is conformance to requirements, not to the concepts of goodness or elegance. 2. The system of quality is prevention, which is preferable to quality inspections. 3. The performance standard for quality is zero defects, not “that’s close enough.” 4. The measurement of quality is the price of nonconformance (poor quality), not indices. This is the precursor to the concept of the cost of poor quality. Crosby defined a 14-step process for management to follow in order to achieve and improve quality: 1. Be committed to quality, and ensure that this commitment is clear to everyone in the organization. 2. Create quality improvement teams, with representatives from all departments. 3. Measure the process to determine the current and potential quality issues. 4. Compute the cost of quality (or poor quality). 5. Raise quality awareness in all employees. 6. Take visible action to correct quality issues. 7. Monitor the progress of quality improvement, and establish mecha- nisms to monitor the zero defects concept. 8. Train supervisors in quality improvement. 9. Hold “zero defects” days. 10. Encourage employees to create their own quality improvement goals (this is perhaps the precursor to the Software Engineering Institute’s Personal Software Process). 11. Encourage employee communication with management about ob- stacles to quality. 12. Recognize the efforts of participants (workers) in achieving and improving quality. 13. Create quality councils. 14. Do it all over again. Quality improvement is endless. J. Ross Publishing; All Rights Reserved
- 39. 16 Mastering Software Quality Assurance Crosby listed five key characteristics of a successful organization: 1. People routinely do things “right the first time.” 2. Change is anticipated and is used to the organization’s advantage. 3. Growth is consistent and profitable. 4. New products and services are developed when necessary. 5. Everyone is happy to work in the organization. Here are some of Crosby’s most popular quotes: 1. “Quality has to be caused, not controlled.” 2. “Quality is the result of a carefully constructed cultural environment. It has to be the fabric of the organization, not part of the fabric.” 3. “Very few of the great leaders ever get through their careers without failing, sometimes dramatically.” 4. “You have to lead people gently toward what they already know is right.” 5. “Change should be a friend. It should happen by plan, not by accident.” 6. “In a true zero defects approach, there are no unimportant items.” Philip Crosby believed that management has the primary responsibility for ensuring quality in the organization. TOTAL QUALITY MANAGEMENT The most popular quality concept in the manufacturing industry today is total quality management (TQM). Almost all professionally managed manufacturing companies have implemented TQM and practice it diligently. The software development industry, knowingly or unknowingly, leapfrogged into TQM through process quality certifications such as ISO and CMMI®. ISO defines TQM as “a management approach for an organization, centered on quality, based on the participation of all its members, and aiming at long-term success through customer satisfaction and benefits to all members of the organization and to society.” TQM is an organization-wide quality initiative, which means it involves the entire organization in the management of quality. One major aim of TQM is to reduce process variation within the organization. In Japan, TQM includes four steps: J. Ross Publishing; All Rights Reserved
- 40. Quality Assurance Basics 17 1. Kaizen—Focus on continuous process improvement, to make every process in the organization visible, repeatable, and measurable. 2. Atarimae hinshitsu—Belief that products will function as they are designed to function. 3. Kansei—Study the way a user uses the product, to facilitate improve- ment of the product. 4. Miryoketuki hinshitsu—Belief that products should have aesthetic value along with usability. For example, a car needs to look attractive in addition to its capability to transport people. TQM advocates quality standards in all aspects of organizational function- ing, as well as the philosophy of “do it right the first time.” It also recommends elimination of waste in all its forms. As it stands today, TQM is adopted to some degree in organizations that have quality assurance at their heart, with inspec- tion, testing, and standards implemented thoroughly and consistently. Although the concept of quality was developed in manufacturing organiza- tions, all of the concepts discussed above are relevant to software development organizations as well. ARE WE GIVING ADEQUATE IMPORTANCE TO QUALITY IN ORGANIZATIONS? The term “we” is used here to mean providers of software development services, because although consumers can demand better quality, they have no control over it. They can raise their voices against poor quality and perhaps abstain from purchasing poor-quality goods and services, but it is providers that can supply goods and services of better quality. The quality function in an organization is akin to the audit function in the finance department of an organization. What is the negative impact of not having an audit function? Management may steal money from the organization. Recognizing this possibility, governments made it mandatory that an external auditor, one approved by a statutory body or certified by a professional asso- ciation of public or chartered accountants, audit a company’s books of accounts and certify that the finances are managed honestly. These external auditors are expected to ensure integrity in an organization’s accounting process. When we see an organization’s audited financial report, we believe that it is an honest statement of the financial position of that organization. The external auditor is J. Ross Publishing; All Rights Reserved
- 41. 18 Mastering Software Quality Assurance viewed as a watchdog over management, to safeguard the interests of the organization’s owners (that is, the shareholders). While the practice of external auditing of an organization’s books, either yearly or quarterly, is mandatory in most countries, it is not mandatory for an organi- zation to include the quality function as one of the departments that regularly undergoes external quality audits. This may be surprising, but the fact of the matter is that many organizations do not have a robust quality department. Some orga- nizations do have a quality department, but in name only; the department does not have any real authority to prevent defective products from reaching customers. Few organizations have a robust quality department that is empowered to exercise authority in stopping shipments to customers if necessary. Why is this? Is it because shareholders’ money needs to be protected, but not the interests of consumers, who are putting trust in a product or service, risking money, safety, and perhaps health? Does this mean that the quality of goods or services is unimportant? Does this imply that the adage “buyer beware” is an adequate safeguard against poor quality? Software now runs almost everything in this world, from financial systems to airplanes to weapon systems and many more applications. The purpose of some software has strategic importance, and perhaps the purpose of other soft- ware is trivial. What is the level of importance being accorded to quality by software development organizations? Most governments are focused on money more than the quality aspects of products or services being offered by organizations. But what is the purpose of safeguarding the accounting process of an organization that is producing poor- quality goods or services and is heading toward failure? While mandatory declarations of financial results make it feasible to com- pute a host of financial ratios (metrics?) that allow us to ascertain the financial health of an organization, there is no way we can compute the quality metrics necessary for us to assess the quality health of an organization. Most organiza- tions never declare what their defect density is. Worse still, most organizations do not even have the wherewithal to derive such metrics. A significant number of organizations, especially in the software development field, do not have a head for their quality department. When we learn that an organization has been appraised by the Software Engineering Institute using CMMI® or that an organization has obtained cer- tification from ISO, we feel confident about the organization’s commitment to quality. Surprisingly, these certifying bodies do not insist that an organization have a quality department, let alone a competent quality department chief. Their methods of certification do not include ensuring that internal quality J. Ross Publishing; All Rights Reserved
- 42. Quality Assurance Basics 19 controls are in place and are doing their job diligently, as is the case in the field of finance. Generally speaking, the quality function is one of the most neglected organs of an organization. Of course, there are exceptions, but for most organizations, quality is a headache, and when there is a conflict, management can—and almost always does—rule against the quality department. Yet management cannot rule against an audit in the field of finance. While it only seems logical to have a similar system in place for the quality function in any industry, including software development, the reality is quite the reverse. Although it is possible for the head of an organization’s internal audit department to become the head of the finance department and for the head of finance to become the CEO, it is a very rare occurrence for the head of the quality department to become CEO of the organization. Activists like Ralph Nader have forced industries to focus on quality. Ini- tially, all guarantees and warranties were against “manufacturing defects,” but activism and lawsuits forced industry to expand guarantees and warranties to cover all defects, including design defects. Unfortunately, however, such activism is absent in the area of software development, and as a result, quality is given scant respect in this industry. Perhaps about 10% of software development organizations may be able to declare their auditable defect density. Most software development organizations do not have full-fledged, full- time, and fully staffed quality departments. This does not mean to say that products are released without any inspection or testing. Although such activities are carried out by the technical department, most software development com- panies do not designate a set of their qualified professionals to tend to the task of the quality function, as is the normal practice in the manufacturing industry. The main function of the quality department in software development organi- zations, where there is one, is to interface with the certifying agencies and ensure that certification is obtained or maintained. The quality department also guides and assists the technical departments in keeping and updating records that are necessary to maintain certification. Championing the organizational quality comes second to certificates. The most popular process model in the software development industry, CMMI® of the Software Engineering Institute of Carnegie Mellon University, does not mandate a full-time quality department. The second most popular issuer of certificates, ISO 9000, which mandates a quality policy and a quality management system for the organization, also does not mandate a quality de- partment. It is as if they are saying, “As long as you manage quality, it is okay. J. Ross Publishing; All Rights Reserved
- 43. 20 Mastering Software Quality Assurance We are not concerned how you do it.” This goes against the very grain of the process quality they evangelize. Processes are important, and who champions those processes should be considered equally important. The above models seem to take umbrage at TQM, in which the CEO is the quality champion. True, the total productive mainte- nance concept also nominates the CEO as the chief production manager. The marketing concept designates the CEO as the chief marketing manager. The CEO may be responsible for every function in the organization, but each de- partment needs a separate head. That way, each department receives due atten- tion besides allowing the CEO to focus equal attention on all functions. Under the marketing concept, the marketing department has a head in addition to the CEO. Under total productive maintenance, the organization has a production manager and perhaps a maintenance manager as well, besides the CEO. It is only the quality department that does not seem to need a professional and knowledgeable department head in many organizations. The general feeling within industry is that the quality department can be managed by the technical head on a part-time basis. Surprising, isn’t it? ORGANIZATIONAL GOALS AND QUALITY GOALS Every organization has goals, mostly financial in nature. The most common organizational goals can be classified as follows: 夹 Strategic (survival, growth) 夹 Financial (revenue, profit) 夹 Marketing (reach, share, customer support) 夹 Product (innovation, quality, reliability, delivery) 夹 Human resources (staff retention, growth, succession) Of the above classes, the ones that attract the attention of senior management are strategic and financial goals. Market forces compel senior management to focus its attention on marketing and product goals, as these have a significant impact on the strategic goals. The remaining goals are delegated to the next line of management to focus on and achieve. Quality goals, which are normally part of product goals, are further relegated downward. It is rather rare to see quality goals distinguished as a separate set of goals. Financial charts frequently are displayed behind the desk of the CEO (and in the lobby of the corporate J. Ross Publishing; All Rights Reserved
- 44. Quality Assurance Basics 21 headquarters) in most organizations, but it is uncommon to find a CEO who has quality charts anywhere in his or her office (or in the lobby, for that matter). Should the CEO be focusing on quality goals? Is it not the function of the development manager to ensure the quality demanded by the customer? The TQM philosophy states that the CEO needs to be the chief quality manager of the organization. Without the focus and support of the CEO, the quality func- tion becomes an appendage of the technical department. Quality goals can either be generic for all software development organiza- tions or specific to an organization. Quality goals can include the following: 夹 Achieve and surpass industry benchmarks for product quality 夹 Achieve and surpass industry benchmarks for product reliability 夹 For productivity goals of quality assurance activities specifically, reduce time spent on inspection, testing, and other related quality assurance activities, by process improvement and usage of better tools 夹 Reduce the cost of quality assurance, meaning the amount of money expended on quality assurance activities, without any reduction in quality levels 夹 Quality improvement goals specific to an organization, such as 夽 Reduction in defect density 夽 Reduction in defect injection rate 夽 Improvement in sigma level The first and second goals focus on quality at the product level, while the rest focus on quality at the organizational level. Also, quality goals dovetail into product goals. Therefore, quality goals ought to be shared by the technical department responsible for delivery and the quality department responsible for monitoring organizational quality. Since the CEO is responsible for achieving the organizational goals with respect to all functions, with the actual responsi- bilities delegated to lower level managers, achievement of quality goals needs to be delegated as well. But is the technical manager in charge of delivery the right choice for delegating the achievement of quality goals? The technical manager’s primary responsibility is to deliver—and deliver on time; quality of deliverables is a close second. When the possibility of having to delay delivery to fix a quality issue arises, most often delivery takes precedence. Therefore, it is necessary to have a quality champion in the organization, whose primary responsibility is achieving the organization’s quality goals. That entity is the quality department. J. Ross Publishing; All Rights Reserved
- 45. 22 Mastering Software Quality Assurance IS A QUALITY DEPARTMENT IN SOFTWARE DEVELOPMENT ORGANIZATIONS REALLY NEEDED? I had occasion to discuss this very topic with the CEO of a medium-sized software development organization, which is preparing itself for CMMI® ap- praisal. I was trying to impress on him the need for a fully staffed quality department with a full-time and knowledgeable quality head. He asked me, “Why do we need a quality department? We are performing peer reviews and independent tests rigorously. What additional value can a quality department add? I do not wish to increase overhead without any benefit to the organiza- tion.” He went on to add that instituting a quality department would directly undermine the commitment of the technical department to quality, in that the technical department would believe that management no longer has confidence in its ability to build in quality. I explained in as much detail as he allowed me, which I offer below, what a quality department can achieve. Here is why software development organizations need a quality department that is fully staffed with competent professionals and with a full-time, competent quality head: 1. The quality viewpoint would be provided unhindered by delivery objectives at any time. 2. Continuous implementation of quality assurance activities would be ensured, without exception. 3. By continuously monitoring the quality achievements of the orga- nization, a quality department would be able to: a. Prevent deterioration of organizational quality before any real damage is caused b. Drive the organization to higher levels of quality and, thus, to- ward excellence 4. Process performance would be measured and analyzed to determine if it is achieving its organizational objectives, as well as to make it feasible to effect necessary improvements to ensure that the pro- cesses perform as designed. 5. Organizational quality achievements would be benchmarked with peer organizations, and industry benchmarks would be applied to the organizational processes, thus raising the bar of quality levels. 6. There would be an in-house expert on matters of quality and analy- sis, who would continuously hone the organization’s leading edge on quality expertise. J. Ross Publishing; All Rights Reserved
- 46. Quality Assurance Basics 23 7. Expert support and training on how to achieve quality objectives would be provided to technical teams. 8. A repository for quality data generated by the organization would be made available to those who need it. 9. Defect analysis would be carried out and elimination of the top causes of defects would be facilitated, pushing the organization toward achieving “right first time.” 10. Continuity of the organization’s initiatives for quality improvement would be championed. 11. A “watchdog,” “in-house customer representative,” and “eyes and ears” of management in matters of product and deliverable quality of the organization would exist, raising its voice when quality trends show a downturn. Thus, the quality department has a vital role to play in the organization. Yet a full-fledged quality department in software development organizations is still not common practice. THE PRESENT SCENARIO IN SOFTWARE DEVELOPMENT ORGANIZATIONS The software development industry has not imported the quality philosophy, techniques, and tools from the manufacturing industry. While independent teams of inspectors and testers are the norm in the manufacturing industry, the software development industry uses project team members to conduct inspec- tions and testing. Some organizations do have an independent testing depart- ment to conduct system testing and coordinate acceptance testing, but this is not a norm across the industry. Insistence on certification by outsourcing organizations such as the U.S. Department of Defense forced software development organizations to seek cer- tifications and maturity level ratings from authorized agencies. Now it is becom- ing normal to see the quality department in a software development organiza- tion coordinate the certification activities under the umbrella of process quality rather than champion product quality. Every software development organization’s brochure contains a statement about its commitment to quality, but this statement is not supported by a strong quality department within the organization. When you question such a com- pany, it asserts that it puts less emphasis on quality conformance activities and J. Ross Publishing; All Rights Reserved
- 47. 24 Mastering Software Quality Assurance places more emphasis on activities that build quality into the product, such as training staff, providing tools, defining processes, conducting audits, and so on. Such companies make it sound as if everybody in the organization is quality conscious and that quality is everybody’s responsibility. Yet the fact remains that quality is an unwanted child in the organization, because “everybody’s respon- sibility” generally means that no one can be held accountable. To sum up, the present scenario in software development organizations is characterized by the following assertions: 1. All companies firmly state their commitment to quality. Most orga- nizations do have one or more certifications/maturity ratings. 2. Very few organizations have a full-fledged quality department, staffed by competent professionals and led by a knowledgeable quality pro- fessional. Most companies either have a quality department in name only or not at all. 3. Where there is a quality department in name only, its role is relegated to interfacing with certifying agencies rather than championing or- ganizational quality. 4. Quality assurance is understood as being equal to testing in most software development organizations. 5. Most software development organizations do not have auditable measurement data for their quality capability. Most do not even attempt it. 6. Most software development organizations do not have objective quality goals. 7. Most software development organizations place the quality function under the technical department, whose primary responsibility is delivery. 8. Most software development organizations do not have independent inspection and testing teams; the development teams perform these activities. This is the quality scenario in the software development industry. Clearly, there is a lot of room for improvement. The focus of this book is how to achieve quality at the product level and how to monitor and improve quality at the organizational level. J. Ross Publishing; All Rights Reserved
- 48. 25 2 FOUR DIMENSIONS OF QUALITY CHAPTER OVERVIEW 夹 Four dimensions essential to achieve quality: specifications, design, construction, and conformance 夹 How to build in quality in each of the four dimensions 夹 How to ensure quality in each of the four dimensions BACKGROUND Quality has four dimensions (as depicted in Figure 2.1): 1. Specification quality 2. Design quality 3. Development (software construction) quality 4. Conformance quality Specifications are the starting point in the journey of providing a product or service, followed by design and then development. Conformance quality is ensuring how well that quality is built into the deliverable at every stage. These dimensions are discussed in detail in this chapter. J. Ross Publishing; All Rights Reserved
- 49. 26 Mastering Software Quality Assurance SPECIFICATION QUALITY Specification quality refers to how well the specifications are defined for the product or service being provided. Specifications have no predecessor activity, and all other activities succeed specifications. Thus, if the specifications are weak, design will be weak, resulting in the development and manufacture of an inferior or incorrect product, and the effort spent on ensuring that quality is built in will have been wasted. Therefore, it is of paramount importance that specifications are comprehensive and well defined and that they take into ac- count all possible aspects that have a bearing on the quality of the product. Specifications normally should include the following six aspects: 1. Functionality aspects—Specify what functions are to be achieved by the product or service. 2. Capacity aspects—Specify the load the product can carry (such as 250 passengers on a plane or 100 concurrent users for a Web appli- cation) or the number of persons to whom a service can cater. Figure 2.1. Four dimensions of quality Specifications Development Quality Design Conformance J. Ross Publishing; All Rights Reserved
- 50. Four Dimensions of Quality 27 3. Intended use aspects—Specify the need or needs the product or ser- vice satisfies. 4. Reliability aspects—Specify how long the product can be enjoyed before it needs maintenance, or the surety of delivering the service and the conformance to the user requirements. 5. Safety aspects—Specify the threshold levels for ensuring safety to persons and property from use of the product or service. 6. Security aspects—Specify any threats for which the product or ser- vice needs to be prepared. How do we make sure that we have comprehensive and correct specifications? The first aspect of ensuring that specifications are drawn up right is to engage qualified persons, such as business analysts or systems analysts, to carry out the job. These professionals must be properly trained to carry out requirements engineer- ing. The second aspect is to either develop in-house standards or adopt the stan- dards of a professional association or a standards body that the analysts are to follow. These standards set minimum levels in drawing up specifications. Initially, specifications should be developed for a product in the usual way. In an internal or external customer-driven project scenario, user requirements are collected. In a commercial off-the-shelf product scenario, requirements are gathered from a market survey exercise. Once requirements have been collected, they need to be developed. This involves separating the requirements into functional requirements, usability requirements, safety and security requirements, reliability requirements, and so on. These requirements also must be checked against organizational standards for usability, safety, and security, and any missing requirements need to be filled in. Then, each class of requirements is analyzed for comprehensiveness against either the backdrop of an existing product or a past project. If neither is avail- able, functional experts should scrutinize and fill in the missing requirements. If access to experts is not available, then a team inside the organization is formed to carry out a brainstorming exercise to ensure that the specifications are com- prehensive in all the classes. In a commercial off-the-shelf product scenario, a second market survey to tap the potential users can be conducted to improve the specifications. DESIGN QUALITY Design quality refers to how well the product or service to be delivered is de- signed. The objectives for design are to fulfill the specifications defined for the J. Ross Publishing; All Rights Reserved
- 51. 28 Mastering Software Quality Assurance product or service being provided. Design determines the shape and strengths of the product or service. Therefore, if the design is weak, the product or service will fail, even if the specifications are very well defined. Although design is a creative activity, it can be split into two phases: conceptual design and engineer- ing. Conceptual design selects the approach to a solution from the myriad ap- proaches available. Engineering uses the approach selected and works out the details to realize the solution. Conceptual design is the creative part of the process, and engineering is the details part. Let’s use the design of a bridge as an example to illustrate the difference between conceptual design and engineering. A bridge can be either a simply supported bridge or a suspension bridge. A simply supported bridge has a number of equally spaced pillars (columns) that support the bridge and the traffic that flows on it. A suspension bridge has a pillar at each end, with cables drawn from these two pillars to support the bridge. For this class of bridge, there are many alternatives for the suspension material, location of the pillars, design of the pillars, design of the suspension cables, and so on. Conceptual design decides these aspects. Engineering design works out details such as the dimensions for each component, selection of materials, methods of jointing, and so on. In terms of software, conceptual design refers to software architecture, navi- gation, number of tiers, approaches to flexibility, portability, maintainability, and so on. Engineering design refers to database design, program specifications, screen design, report design, etc. Software design normally contains the follow- ing elements: 1. Functionality design 2. Software architecture 3. Navigation 4. Database design 5. Development platform 6. Deployment platform 7. User interface design 8. Report design 9. Security 10. Fault tolerance 11. Capacity 12. Reliability 13. Maintainability 14. Efficiency and concurrence 15. Coupling and cohesion J. Ross Publishing; All Rights Reserved
- 52. Four Dimensions of Quality 29 16. Program specifications 17. Test design How do we ensure that the right designs are selected and implemented? As with specification quality, before software design is attempted, it is essential that qualified people, trained in the art and science of software design, are in place. Either software design standards are developed in-house or, alternatively, they are adopted from a professional association or a standards body. These stan- dards assist designers to achieve the best design possible. It is normal to conduct a brainstorming session at the beginning of a soft- ware design project, to select one optimum design alternative and to decide on the overall design aspects, such as the number of tiers, technology platform, software coupling and cohesion, etc. A brainstorming session helps designers arrive at the best possible solution for the project at hand. A prototype of the design may be created and evaluated, which is normal practice specifically in the case of commercial off-the-shelf product development. The final design is then evaluated against the organizational standards to ensure that the design will work for the project. The design is subjected to reviews from peers, experts, and managers as required before carrying out the detailed design of the entire product. DEVELOPMENT (SOFTWARE CONSTRUCTION) QUALITY In certain fields, there is no way quality can be tested without destroying the product itself. For example, the thickness and adherence of paint on a surface cannot be ensured without destroying the paint itself. Various shafts used in automobiles are forged and heat treated to make them stronger, and there is practically no way to test them to ensure that the desired qualities are built in without destroying the shafts. In such cases, in-process inspection is performed to ensure that the process is adhered to diligently and a few samples are sub- jected to destructive testing. Fortunately, when it comes to software, nothing needs to be destroyed during testing, and corrections can be made without any material loss, but testing takes much longer to perform in the software development field than it does in manufacturing. Inspection and testing take only a fraction of the time it takes to fabricate a part or a product in manufacturing, but software testing can sometimes take more time and effort than it takes to develop the software. It is commonly agreed that 100% testing is not practical in the software develop- J. Ross Publishing; All Rights Reserved
- 53. 30 Mastering Software Quality Assurance ment field. Therefore, the way in which software is developed assumes greater importance. Normally, the following activities form part of developing software: 1. Create the database and table structures 2. Develop dynamically linked libraries for common routines 3. Develop screens 4. Develop reports 5. Develop unit test plans 6. Develop associated process routines for all other aspects, such as security, efficiency, fault tolerance, etc. Good-quality construction is achieved by adhering to the coding guidelines of the programming language being used. Normally there is a separate coding guideline for every programming language used in an organization. It is custom- ary to define the coding guidelines before beginning to write programs in a language. Coding guidelines contain naming conventions, code formatting, efficiency guidelines, and defect prevention guidelines that help developers write reliable and defect-free code. Of course, it is very important to have qualified people trained in software development. Construction follows software design, and it should always conform to the design document. In this way, good quality in construction can be achieved. Sample coding guidelines are given in Appen- dix I. CONFORMANCE QUALITY Conformance quality deals with how well an organization ensures that quality is built into a product through the above three dimensions. It is one thing to do a quality job, but it is quite another to unearth any defects lurking in the work product and ensure that a good-quality product is indeed built. Essentially, conformance quality examines how well quality control is carried out in the organization. How do we determine how well an organization conducts the activities that ensure that quality is indeed built into a deliverable? One way to ascertain the efficacy of quality assurance activities is to use a set of quality metrics. These metrics include the defect removal efficiency of each of the quality control activities, product quality, and the defect density. Another way to ascertain the J. Ross Publishing; All Rights Reserved
- 54. Four Dimensions of Quality 31 efficacy of quality assurance activities is to compare industry benchmark data for quality metrics with the organizational metrics. Appendix G covers quality metrics and measurements in greater detail. This book discusses how to build quality into a deliverable and ensure that quality is built into the first three dimensions mentioned (software specifica- tions, design, and construction), as well as ensure the quality of conformance itself through quality measurement and metrics. ENSURING QUALITY IN SPECIFICATIONS This is the first activity in building either a product or a service. Needless to say, it is a creative activity. In the software industry, specifications are referred to as user requirements. That is, end users of a software product perceive them as the requirements for the proposed product. The following are possible scenarios for obtaining user requirements: 1. A business analyst conducts a feasibility study, writes up a report, and draws up the user requirements. The analyst: a. Meets with all the end users and notes their requirements and concerns b. Meets with the function heads and notes their requirements and concerns c. Meets with management personnel and notes their requirements and concerns d. Consolidates the requirements and presents them to select end users, function heads, and management personnel and receives their feedback, if any e. Implements the feedback and finalizes specifications 2. A ready set of user requirements is presented as part of a request for proposal 3. A request for proposal points to a similar product and requests rep- lication with client-specific customization Regardless of the scenario, once the specifications are ready, quality assur- ance steps in. The role of quality assurance in this area is to ensure that the specifications are exhaustive and cover all areas, including functionality, capac- ity, reliability, safety, security, intended use, etc. J. Ross Publishing; All Rights Reserved
- 55. Other documents randomly have different content
- 56. I would like to exchange flower seeds for geranium and fuchsia slips, or ocean curiosities. I have many kinds of seeds which I raised myself. Annie Sidney Duffie, Princeton , Arkansas. I am twelve years old, and have taken Young People since April, when I received a year's subscription for a birthday present. I always look forward with pleasure to its coming. I, too, am making a collection of postage stamps, and would like to exchange with readers of Young People. I have several hundred, among which are Danish, Norwegian, Japanese, and other foreign issues. Nellie Hyde, 162 Third Street, Oakland, California. I am making a collection of stones, one from each State. I will exchange a stone from Iowa or Missouri for one from any other State. If Jessie I. Beal will send me a stone from Michigan, I will gladly exchange with her. Lotta R. Turner, P. O. Box 705, Keokuk, Lee County, Iowa. I received several very satisfactory answers to my request for exchange of stamps. I would now like to get a Chinese and an Italian stamp. I will exchange for them French and German stamps, or morning-glory or double-hollyhock seeds. I will also exchange these seeds or postmarks for new postmarks. Willie D. Vater, Office of the Daily Journal, Lafayette, Indiana. Since my request for exchange was printed in the Post-office Box I have received over one hundred letters, and have gained about four hundred stamps. I have now thirteen hundred. If any other readers of Young People would like to exchange with me, I will be very glad to do so, especially if they have any duplicates of rare stamps.
- 57. Lewis S. Mudge, Princeton , New Jersey. I wish to exchange postmarks with any boy or girl in the United States or Canada. H. L. McIlvain, 120 North Fifth Street, Reading, Pennsylvania. I am studying natural history, and am very fond of it. I would like to exchange specimens of minerals and insects, especially with "Wee Tot." Frances M. Heaton, Flushing, Long Island. I am making a collection of minerals, and would be glad to exchange petrified wood, celestine, satin spar, chalcedony, fossil shells, or concrete sand balls for other minerals, or Indian relics. I am a reader of Young People, and like it very much. Herbert E. Peck, P. O. Box 296, Colorado Springs, Colorado. Mabel C.—We suggest "Agate Club" as a pretty name for your society. In the language of gems agate signifies prosperity. Take each letter of the word as the initial of another gem, and let the sentiments of these gems be the mottoes of your club. You can give the name this interpretation: agate, prosperity; garnet, constancy; amethyst, love and truth; topaz, friendship; emerald, faith. If you wish for a club pin, you can have an agate in a simple setting, which would be a very pretty ornament, and not expensive. Boston, Massachusetts. I would like to know if the story about Captain Cook's goat is true. Willie W.
- 58. We only know of one goat connected with Captain Cook. This travelled beast twice circumnavigated the globe—first in the ship Dolphin, with the early discoverer Captain Wallis: and secondly in the ship Endeavor, with Captain Cook. After the goat arrived in England for the second time, the Lords of the Admiralty granted it the privilege of a residence in Greenwich Hospital, and a silver collar was put around its neck, inscribed with a Latin couplet composed by Dr. Johnson. But the goat, like many other old sailors, did not apparently thrive on dry land, for it died in April, 1772, as it was about to be given to the old seamen at Greenwich for a pet, and less than a year after its return from the long voyage with Captain Cook. C. B. M.—Postage stamps, if they are clean and in good order, will be received in payment for the covers of Harper's Young People. "Bill."—We refer you to the advertisement of toy steam-engine in Harper's Young People No. 53. Ernst H.—Your insect from Colorado answers the description of the caddis-worm. This worm, which is a soft, white creature, lives under water in a movable house which it makes for itself out of bits of stone, pieces of shell, and grains of sand. It feeds on minute particles of water refuse. When its life as a worm is ended it forms a chrysalis, from which issues a fly with hairy wings called the caddis-fly, of which there are many species. The caddis-worm is much used as bait by fishermen. The following communication is longer than those we can, as a rule, admit to the Post-office Box, but as we are sure it will be interesting to other little mothers of doll families, we make an exception in its favor: My family of dolls are unfortunately all orphans. I had the parents of the four girls named French, but my brother Jack sat on the head of the papa, and hopelessly crushed it. The mamma I left too long in a sun bath, and her beautiful wax complexion melted all away. Dora French is the oldest girl, and has auburn hair like the Empress Eugenie. Her hair comes off sometimes, but I use a sticking stuff for tonic, and fasten it on just as the ladies do their puffs. Dora is very graceful, and turns her head beautifully. She wears blue, to suit her hair. Sue French is a brunette with handsome black eyes, long black hair, and bangs. She is very beautiful. My uncle sent her to me as soon as she arrived from France. She is named for my aunty Sue. Lizzie French, the third girl, came over in the same steamer with Sue. She is the sweetest blonde, and is called for my own mamma. Both Sue and Lizzie are very fond of dress. Louise French is the intelligent one of the family. She talks beautifully, and is always calling for mamma and papa; but, poor thing, they never answer her. Perhaps if they were alive, and had the strings in their sides pulled as hard as I pull those of poor Louise, they would answer lively enough. Louise has lovely teeth, but by an accident one was knocked out. The baby is named Minnie. She is an American, and the pet of all the dolls. A lady found her in a doll's orphan asylum, or rather a big store. She is just too lovely for anything, and has lots of long clothes, like a real baby. She has a cradle with sheets, blankets, pillows, and quilts; a pretty baby
- 59. carriage; a baby basket, lined with blue and trimmed with lace, which holds her brush, comb, sponge, soap, towels, nursing bottle, and rattle. She has caps, cloaks, and an afghan for her carriage. I have almost forgotten dear Gretchen. She is not the little Dutch Gretchen who sat in the kitchen eating her cold sour-krout, but is a cousin to the Misses French. Her trousseau came in the box with her; and such queer satin and white Swiss dresses, funny little aprons, quaint slippers, fine stockings, and dear little hats you never saw, unless you have been in Switzerland. Her hair is light, and braided in two long plaits. I tell you she is a beauty; and although she is the youngest of all the dolls, except the baby, she is as tall as any of them. Then there is Ho Shen Chee, the Chinaman. He is the only boy in the whole family. Mamma picked him up at the Centennial. He looked so forlorn and lonesome that mamma felt sorry for him, and brought him home. We do everything to make him happy, but he still has that same sad look, and his head wobbles awfully. His clothes are a great trouble to us, for we can never make any like those he had on when he came. The French girls have everything elegant. Their Saratoga trunk is filled with lovely dresses, shoes, bonnets, fans, stockings, gloves, jewelry, parasols, hats, dressing-cases and travelling bags, writing-paper and desk, watches, perfumery bottles, books, and everything that young ladies need. Their furniture is very handsome, too. Their bedstead was made to order, and has a mattress, pillows, shams, and everything. They have a large bureau, a lounge, tables, chairs, and a cabinet filled with bric-à-brac. They have a small work-basket, with little scissors that open and shut, thimble, needles, and all other work-box necessities. Olive, or Aunt Olive, as the dollies call her, is the very smallest, but the beauty of the family, and the richest. She lives in a large house with her adopted daughter Pussy, and a great many servants. Her house has five rooms—parlor, dining-room, bedroom, kitchen, and bath-room, where real water runs from a faucet. All these rooms are furnished too lovely for anything. The windows have real glass and curtains; the doors have curtains too. We have a large barn (when I say we, I mean my brother Jack and myself, for he loves dolls as well as I do), which has horses and a dog-cart, in which Olive rides. We have a Park phaeton too. We build our farm-yard in one corner of the room, and our fort in another; these are the summer resorts. We move the things on Jack's big dray and cart. We play the figures in the carpet are lakes, rivers, and ponds. The dolls ride on these in our boats, which go on wheels. Away off in another part of the room we put up the tents. We build the railroad, and the dollies go out to the camp. When we want to take them to amusement, we build our theatre, which plays Cinderella. When they get tired of that we take them to the dog show, which is Jack's collection of beautiful china dogs. We have a race track, where the dolls go to the races on the elevated railroad which we set up. When they get hungry we put the cooking stove on the fender, with the pipe up the chimney, and make a fire, and really cook. Of course we do the eating, using our pretty blue and gilt dishes. We only know one other little girl in New York, and she does not care to play with dolls; so Jack and I get in a room all by ourselves, and put up all these things, and I tell you we have a splendid time. When we get tired we put the dollies to bed, and get out their wash-tubs, boards, and irons, which we heat on the little stove, and wash and iron their little clothes. Next to reading Harper's Young People, this is the best fun we have. Bessy Guyton. Favors are acknowledged from Percy Schuchardt, L. P. Wilson, Willie E. Billings, W. L. Bradley, Belle Sisson, Cass K. Shelby, A. G. Norris, John Moody T., Daisy May B., Annie Quinn, Bertha A. F., Frank A. Harmony, Abbie Parkhurst, Jessie De L., Hattie Cohen.
- 60. Correct answers to puzzles are received from Bessie C. Morris, Florence Nightingale, Isabel L. Jacob, Clara B. Kelso, Lizzie, "Freeport, Illinois." The following names are of those who sent answers to Wiggle No. 14 too late for acknowledgment with the others: Maggie and Harvey Crockett, Lucy P. W., Estelle R. Moshberger, Jackson, Bertie, Helen C. Edwards. PUZZLES FROM YOUNG CONTRIBUTORS. No. 1. ST. ANDREW'S CROSS OF COMBINED DIAMONDS. Central.—In Westmoreland. A margin. A despicable person. Bipeds. In Ireland. Upper Right Hand.—In game. Obscure. One of a class of laborers. A sea-fowl. In sport. Upper Left Hand.—In grapes. Devoured. Something dreaded by sailors. To blunder. In melons. Lower Right Hand.—In general. At present. A bird. Humor. In captain. Lower Left Hand.—In amethyst. A tropical vegetable. A nobleman's house and lands. A tumultuous crowd. In emerald. Owlet. No. 2. ENIGMA. My first is in mat, but not in rug. My second in wasp, but not in bug. My third is in red, but not in blue. My fourth is in false, but not in true. My fifth is in wren, but not in owl. My sixth is in bird, but not in fowl. My seventh is in calm, but not in rough. My eighth is in shawl, but not in muff. My ninth is in poem, but not in ditty. My whole is a European city. Mamie.
- 61. No. 3. EASY NUMERICAL CHARADES. 1. My whole is a beautiful sheet of water composed of 13 letters. My 8, 13, 5, 3, 9 is a river in Europe. My 6, 2, 11 is a domestic animal. My 4, 10, 7, 8, 12 often wakes the baby. My 3, 13, 1 is always fresh. Little Sister. 2. My whole is composed of 12 letters, and is always in motion. My 11, 2, 9, 6 can never be trusted. My 4, 7, 12 is a fluid. My 10, 3 is a musical term. My 8, 5, 1 is much used by the Japanese. Julian. ANSWERS TO PUZZLES IN NO. 50. No. 1. W H V I A B A G W I T C H - H A Z E L A C E G E M H L No. 2. J U R A H A N D U R A L A G U E R A A B N U L L A L B A D E L L No. 3. Wood-box. No. 4. 1. Mustard seed. 2. Rhinoceros.
- 62. No. 5. Boston.
- 63. NEW BOOKS FOR YOUNG READERS. To the hosts of young readers who bade Dr. Bronson and his nephews Fred and Frank good-by in Hong- Kong at the end of Part First of The Boy Travellers in the Far East[1] the announcement that, by the appearance of Part Second of this fascinating narrative, they may once more journey into strange lands with their young friends, will be a welcome one. Starting from Hong-Kong, the boys continue their travels down the coast to Singapore, stopping by the way in Cochin China, Anam, Cambodia, and Siam. From Singapore they sail through the Malayan Archipelago to Batavia, in doing which they cross the equator. From Batavia they take long excursions into the interior of the island of Java, and here the reader has again to leave them for a time while they make preparations for further explorations of the wonderful lands of the Far East. The book is filled with tales of adventure by land and sea with pirates and wild animals, curious bits of history, accurate descriptions of strange people and queer customs, animals, birds, and plants. In it the author has so artfully blended instruction with amusement that the young reader is taught in spite of himself, and finds the driest facts interesting when presented in this charming form. The letter-press is supplemented by copious illustrations that appear upon nearly every page. The binding is very handsome, and the book bids fair to prove one of the notable attractions of this year's holiday season. Most books of foreign travel are written with the view of cramming the minds of their readers with the greatest possible amount of information, and the result is apt to be a fit of mental indigestion from which the victim does not readily recover. In Harry Ascott Abroad,[2] however, the author has carefully avoided the text-book plan, and has confined himself to the simple relation of an American boy's every- day experience during a year's residence in Germany, and while travelling in Switzerland and France. The story is told in the boy's own language, and is made up of just such facts as will interest other boys, and at the same time teach them what to expect, and what mistakes to guard against, if they happen to find themselves in a position similar to that of Harry Ascott. Mrs. Cochran (Sidney Dayre) has earned so enviable a reputation as a writer of short stories for children that while the "young readers" feel sure that anything from her pen must be interesting, their parents are equally confident that the tone of the story will be healthy and pure. The Queer Little Wooden Captain[3] and The Little Lost Girl, the two stories contained in the present volume, are Christmas tales, both of which, without moralizing, teach how much greater are the joys of giving than those of receiving.
- 64. HARPER'S YOUNG PEOPLE. Single Copies, 4 cents; One Subscription, one year, $1.50; Five Subscriptions, one year, $7.00—payable in advance, postage free. The Volumes of Harper's Young People commence with the first Number in November of each year. Subscriptions may begin with any Number. When no time is specified, it will be understood that the subscriber desires to commence with the Number issued after the receipt of the order. Remittances should be made by Post-Office Money-Order or Draft, to avoid risk of loss. Volume I., containing the first 52 Numbers, handsomely bound in illuminated cloth, $3.00, postage prepaid: Cover for Volume I., 35 cents; postage, 13 cents additional. HARPER & BROTHERS, Franklin Square, N. Y.
- 65. THE PEG-TOP. Spin away, spin away, round and round— The hum of the top has a merry sound; The peg-top's journey is just beginning, Ever so long it will go on spinning. Up in my hand, or down on the ground, Still the peg-top goes round and round. Baby looks on with eyes so bright— Isn't top spinning a wonderful sight?
- 66. BREAD AND MILK. Bread and milk, bread and milk, fit for a king, Plenty of sugar has been put in; Mix it up well with a silver spoon, Wait till it cools, and don't eat it too soon! Milk and bread, milk and bread, isn't it nice? Why! the whole basinful's gone in a trice! Oh! there is many a poor little boy To whom bread and milk would be a great joy.
- 67. FLYING THE KITE. Fly away, fly away, comical kite, Up in the sky to a terrible height; When you come back, tell us where you have been, Where do the stars live, and what have you seen?
- 68. MAYING. Oh! who loves May, so sweet and gay? A long, long way I've been to-day, Over the fields and down the lane, Into the copse, and back again; Such a ramble, such a scramble, Catching my dress on a blackberry bramble. All the merry brown bees were humming, And all the birdies sang, "Who's coming?" And the butterflies came to my branch of May, For I've been Queen of the Woods to-day. FOOTNOTES: [1] The Boy Travellers in the Far East. Part Second: Adventures of two Youths in a Journey to Siam and Java, with Descriptions of Cochin China, Cambodia, Sumatra, and the Malay Archipelago. By Thomas W. Knox. Illustrated. 8vo, pp. 446. New York: Harper & Brothers. [2] Harry Ascott Abroad. By Matthew White, Jun. 16mo, pp. 94. New York: The Authors' Publishing Company. [3] The Queer Little Wooden Captain. By Sidney Dayre. 16mo, pp. 152. Illustrated. New York: The Authors' Publishing Company.
- 69. *** END OF THE PROJECT GUTENBERG EBOOK HARPER'S YOUNG PEOPLE, NOVEMBER 2, 1880 *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 70. THE FULL PROJECT GUTENBERG LICENSE
- 71. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 72. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project
- 73. Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed: This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files
- 74. containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1 with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty
- 75. payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information about donations to the Project Gutenberg Literary Archive Foundation.” • You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works. • You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. • You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright
- 76. law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund.
- 77. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg™
- 78. Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non- profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact
- 79. Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and
- 80. credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg™ electronic works Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg™ eBooks with only a loose network of volunteer support. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 81. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com