Many of the early projects I have been involved in had problems at delivery. Over the last twenty years of my career, I have developed a set of techniques to address those problems, keying on the hidden variable that is the primary cause of failures - Communications.
There are three main problems in developing custom software:
The essential tools for quality software are clear communications and good organization. Most of the problems that arise in a project are caused by misunderstood or missing information as the result of faulty communications. This ocurrs in each step of the project and studies have shown that the earlier in the project that an error happens, the more costly the cure. As Brooks has said "The sooner you start, the longer it takes". _The Mythical Man-Month_by Brooks should be required reading for any quality conscious software development. He wrote the best early advice on what to avoid, but advice on how to properly develop software has been harder find.
So what is quality software and how do we get there? The technique I propose puts a flexible structure around the whole software development process. Quality is the result of a process that starts at the first blush of a new or upgraded product and continues in parallel with the development of that product. It is based on communicating through a Formal Requirements Document (FRD) and building tests, documentation and programs in a parallel process.
Quality is not merely the removal of all bugs. From a former manager, I have the saying "There are always three bugs left". This was known as LaCrosse's Theorem , and has proven true enough through the years. If quality is not the absence of bugs, we can then infer that it is the presence of something else. That presence is agreement between the Formal Requirements Document (FRD) and program function as verified by Quality Assurance (QA) testing. The FRD is the basis for solving the first problem - documenting what the customer really wants.
The FRD contains four parts:
These four documents comprise the FRD, which defines the project. The FRD is the genesis of the approach to quality that I propose. It contains the information that makes it possible to build a quality product. The FRD by itself does not assure quality - that is done by following the Parallel Development Process (PDP) outlined later.
Creating the FRD should start by building an understanding with the customer that the first FRD may not represent exactly what they need. It is often the case that they don't know until they see the first product. This leads to the classic programmer joke:
"How do you tell a real customer?" "A real customer always knows what he wants until you deliver it, and then says 'I know that's what I told you, but it's not what I want!'"
Start by understanding that the FRD will evolve and you both will be able to proceed with the knowledge that changes will happen. The next step is to clarify for the customer the necessity to avoid changes after a specific 'freeze date'. If you explain that scheduling changes as revisions after a delivery is faster, less expensive and better quality than trying to work them in, most will agree. For the exceptions, take their changes and work them as revisions anyway. :-}
How is an FRD developed? Once you have understanding with the customer, there is a process to identify, develop and encapsulate the customer's desires in a written document. This should be in English and yet structured so that it leads to separable parts based on functionality. I call this part of the FRD technique Requirements, Specifications and Design (RSD). RSD defines the working documents that flow through and control the PDP.
The RSD is an accurate description of how the desired system should behave and what it does. But that document itself is a representation of what the customer wants, and all programmers know how difficult it is to discover that and then get agreement. This specific set of problems, of capturing what the customer really needs, is the bete noir of real software quality and it is the first problem that must be solved.
An essential concept of the RSD is to avoid details until the appropriate stage. It is analogous to the concept of 'Late Binding' in computer execution, but it has a far stronger reason. What I can call 'Late Specification' maintains an orientation to What must be done as long as possible before detailing How it is to be done. The reason for this is to maintain design and implementation flexability. Early specification is like premature optimization, both a waste of effort and a high probability that it will lead you into dead ends, bad designs or both. At the Requirements stage, the design is not even begun, so any detail that limits design options is to be avoided.
When the RSD is done, or a version frozen, it should be duplicated for three groups. They are the programming group, the documentation group and the QA group. Each group uses that document to develop their part of the work that results in a quality system. The RSD must be kept in sync for these groups through some publication mechanism, either electronic or paper based.
The common practice of waiting to develop documentation and tests until programming is almost done is a major cause of project problems. PDP avoids this trap by developing on three paths in parallel - programming, documentation and quality assurance. This parallel process is essential for getting the best results.
Programming uses the RSD as the authoratative source of information for design and implementation. Documentation uses the RSD as the basis for help files, formal manuals and training materials. Quality Assurance uses the RSD as the source for developing QA tests.
It is the process of developing tests and documentation that lead to questions and clarifications of the RSD that are crucial to getting the programming done right the first time. Because each group has different objectives, they will read the RSD and discover unique sets of issues to be clarified. Clarifying those issues and sharing the answers as early in the programming process as possible is the key to getting the code right. The PDP is what leads to an accurate RSD which in turn guides the programming team. This PDP is what solves the second problem - developing software that meets those needs.
The QA testing starts when the programs are far enough along to run through basic functional testing by the programmers. QA operates in parallel with both programming and documentation, resolving differences and providing details of where the product does not meet the RSD. Cycles of QA tests and programming fixes continue until an agreed on level of quality is reached. This separation of test development and execution provides more thorough test coverage and objective evaluation. It is a good idea to base shipment on passing the QA test with no significant problems unresolved. It is the QA testing that solves the problem of delivering a quality product.
Another major benefit of the PDP is that documentation and thorough QA testing does not burden the programming staff, which will result in faster delivery. Having complete manuals and training available when the software ships also speeds assimilation of the new programs by the users, benefiting both user attitude and company ROI. This leads to meeting time and budget constraints.
Finally, understanding that the various objectives need different skill sets leads to more productive people and effective products. A programmer is the wrong tool for developing documentation - and writers shouldn't run QA tests.