Software Verification and Validation: A

Este es un libro eminentemente práctico sobre "Ingeniería del Software". A diferencia de otros libros, excesivamente llenos de ejemplos (normalmente de las malas prácticas), éste se centra en describir las diferentes aproximaciones para todas las etapas de desarrollo del software. Aunque se decanta por el modelo de desarrollo "Waterfall", explica otros modelos de desarrollo. Un elemento a destacar de este libro es la calidad de los apéndices que incluyen numerosas plantillas de ejemplo para cada una de las etapas de desarrollo, y en especial para los procesos de inspección, y seguimiento de los errores. Otro aspectos que se cubren éxito en este libro son los dedicados a la estimación de esfuerzos para la planificación, estimación de riesgo que en casi ningún libro de ingeniería del software ofrece alternativas tan interesantes como en este. A modo de ejemplo, los apéndices que incluye son los siguientes: - Inspection Roles and Responsibilities - A Sample Inspection Process - Inspection Process Forms - Inspection Checklist - Attributes of Good Requirements Specifications - Sample Criteria for Selecting Modules for Code Inspection - Sample Software Development Process Based on the Waterfall Model. - Document Outlines - Test Cases for the Triangle Program (example) - Software Reliability Models. - The Yellow Sticky Method - Software Development Best Practices - Software Quality Best Practices - Project Postmortems - Root-Cause Analysis Finalmente el autor mantiene una página Web asociada al libro: http://www.swqual.com/index.html?Intro. Especialmente interesantes es la newsletter mensual. Carlos Ortega 2006-01-30

Bill Gates is famous for his yearly retreats where he takesa pile of books and reads them. Maybe that's the one thingtoday's managers should emulate. If you do, bring this bookalong on your first sabatical.This all new edition of the book (first published in 1997)was even renamed to include its new, extended charter."Clearly management must take a leadership role in helpingthe organization behave in a more predictable way. It isfor this reason that the title of the book has been changedto include managers. [the book] includes specific actionsthat managers can take to help organizations behave in a more predictable manner." Software development is a difficult disciple to master.Even so, technical acumen is no guarantee of quality. "Asobserved by Dr. Edwards Deming, 'The quality of a productis directly related to the quality of the process used tocreate it.'" Verification ("are we building the productright?") and validation ("are we building the right product?")are the first questions one must ask to begin the pathof process improvement. This book addresses those questionsand more.The book is divided into four large sections. The firstthree sections are brought forward from the previousedition with some noticeable improvements. The new editionis not just a rehash of the old stuff, however. Over 30 new pages of appendices and an entire new section of the book aimed at management with over 70 new pages have been added. Other improvements are also evident including better formatting. For example, the font selection and layout are much easier on the eyes than in the previous edition.If you own the first edition, this is a "must have" update.If you don't own the first edition, consider this work anSQA department "starter kit." It is well organized, wellannotated, and filled with practical artifacts such aschecklists for inspections, suggested document outlines,and the like. This is stuff you can use.Chapter 12 is specifically for the CEO and should be required reading by anyone running a company with asoftware development function. "Managers and executivesneed to understand that having a predictable software development process is vitally important to the long-termsuccess of their business." Rakitin shows how, then showswhat can be done. The prose is crisp and to-the-point.Well done.

I wish I could count the times I've seen second and third rounds of development occur because the first round produced a working version of a product the customer didn't want. With all of the emphasis lately on rapid development, especially now that the web has everyone working on "internet time", there has been a noticeable lack of discussion on ensuring the software produced fits the needs of the customer and is of reasonable quality. Rakitin addresses these issues and more in this book. As the title indicates, he concentrates on Verification ("are we building the product right?") and Validation ("are we building the right product?"). However, the subtitle to the work "A Practitioner's Guide" provides much more insight into the actual scope of this work. In the discussion of software inspection meetings, for example, Rakitin give guidelines regarding not only the mechanics of who should attend and when materials should be distributed but he also provides insight into what to expect as a moderator and how much should be expected to be accomplished in the meetings themselves. There are a number of statements in the book that begin "Experience has shown..." Rakitin's extensive experience has manifested itself throughout the book transforming the dry, checklist-like discussions found in so many other books into discussions about how people work and communicate with each other. This isn't to say there couldn't be more. Although what's presented is very good, there are points in the book where I found myself wishing for additional discussion. Perhaps in future editions Rakitin will be able to expand upon, say, requirements collection or configuration management. There are also things that could be updated if the book were to have a revision. For example, a brief discussion on OO methodologies is provided where Fusion from HP is outlined. This could obviously be expanded to cover the Rational Unified Process, Rational's effort to provide UML with "meat" the modeling language alone could not have. As Deming observed and Rakitin noted, "The quality of a product is directly related to the quality of the process used to create it." To this end, Rakitin attempts to provide the reader with ready-made tools, checklists, outlines, and forms to aid them in the maturation of their software engineering department. These items, which appear in approximately 80 pages of appendices, give the reader a variety of starting places for just such an initiative. Brooks said "no silver bullet" and he was right. Quality software is possible only through a methodical, rational, and scientific approach. Rakitin goes a long way towards that in this work. I highly recommend it.

Software Verification and Validation by Steven R. Rakitin. A practical book by a practical author, presenting the steps required to set up a formal and complete Verification and Validation program for software production. Mr. Rakitin sprinkles pertinent quotations throughout the book to support his case that software quality programs (detection) cost less than simply releasing a "buggy" program to your Customers. The author also teaches the lessons of this book at IEEE lectures; I attended one in March 1998. At these lectures, the author fleshes out and makes more interesting many of the points made in his book. As an ASQ Certified Software Engineer, S. Rakitin has the credentials to expound on many aspects of quality programs set up to deal effectively with the major & crucial issue of the lack of software quality today. There are 169 pages of text, describing a good program, but the author has also included some 87 pages of appendices (from "A" to "H") which give you a cook book or recipe approach to different aspects of software quality. The author gives you good leads to other sources of information on software quality. The book would profit from another good editorial review, reducing the wordiness in some chapters and tying the whole story all together. For example, Rakitin continuously uses "SEI" which (as far as I can see) is not defined in his book. SEI = Software Engineering Institute. In Chapter 4, the author attempts to establish a cost/benefit justification for implementing a software quality program, but misses and then, later, on page 90 (Chapter 7), he DOES lists the pertinent reasons as, "...lower support costs, ... fewer maintenance releases, ... higher customer satisfaction and, as a result, increased sales". An astute editor would have melded all of this together. Overall, this book is directed at the practitioner, whether a hardware quality engineer required to set up a software quality program, or a novice who has the same task. It is a practical book, generally well written,