A. Description of the topic
There is nothing mysterious about the basic concept of a walkthrough: It is simply a peer group review of any product. Throughout this paper, we will assume that the product has something to do with a computer program or system: thus, we will referring to walkthroughs of program listings, structure charts, dataflow diagrams, entity-relationship diagrams, and other models that are associated with the development of information systems. Alternatively, a walkthrough might be concerned with operational prototypes of a system in order to review the functionality, performance or user interface.
B. Importance of the topic
To a typical programmer or systems analyst, the notion of spending an hour reading through someone else's program listing or dataflow diagram makes no sense. Moreover, the thought of letting someone else look at his/her work strikes him/her as a waste of time, if not an invasion of privacy. This is even more true today in the world of microcomputers, where the industry extols the feats of lone "cowboy" programmers who write dazzling new programs — all by themselves — on the IBM PC or Macintosh computer.
Indeed, why would any rational programmer want someone else to look at his program listing? What is the point of a structured walkthrough? The answer is very simple: Walkthroughs are an effective way to improve the quality of the source code of a computer program and the documents that describe the design, architecture, performance, user interface, or functionality requirements of a system.
Other, complimentary approaches to software quality exist. There are software engineering techniques, testing techniques, and techniques for developing rigorous mathematical proofs of correctness of computer programs. All these methods should be used whenever possible. Any approach that concentrates on introducing quality before the fact certainly is compatible with the idea of walkthroughs, and is preferable to many of the techniques for removing defects after the fact.
Indeed, may after-the-fact techniques — the whole range of static testing and dynamic testing techniques used by MIS organizations, for example — now are widely recognized as failures. These is no such thing as exhaustive testing of a computer program (a fact that is not yet known to a generation of end users building expert systems on their own personal computers!). And frequently tests that are performed merely reflect the same logical errors as the computer program itself, because they reflect the logical misunderstandings of the programmer.
In contrast, walkthroughs have been found highly successful in helping to produce reliable, bug-free programs. Programming groups using walkthroughs report that they have been able to reduce the number of errors in production programs by as much as a factor of ten. In a typical organization, it is usual to find an average of three to five bugs in every hundred lines of code during the five- to-ten-year lifetime of a normal system. But in the systems development with modern software engineering methods, combined with diligent walkthroughs and other testing techniques, it is not uncommon to see as few as three to five bugs per ten thousand lines of code.
Not only does the walkthrough approach find more errors than classical development techniques, but it also finds the errors more quickly and more economically. As a result, organizations find that walkthroughs increase the productivity of their development staff. This increase is not surprising, considering that roughly 50 percent of the time spent on most development projects is spent on testing. In addition, diligent walkthroughs can help drastically reduce the effort required to maintain the system. After all, if there are no errors in the system, much less effort is required to keep the system running! Since maintenance occupies approximately 50-75 percent of the overall MIS budget in most organizations a reduction in the maintenance effort indirectly, but significantly, improves the MIS organization's ability top produce new systems.
Two major variables determine the nature of the walkthrough. The first of these is formality: How organized, how "structured" should the walkthrough be? The second major variable is timing: At what stage in the development of a product should a walkthrough take place? Walkthroughs can occur after the user requirements have been developed, after the design has been completed, after the code has been written, or after the test data has been developed. In many organizations, walkthroughs are conducted at each of these milestones in the systems development life cycle.
Walkthroughs can also be used before and during the development of user requirements, design, code, and test data. In addition to verifying the correctness and the quality of the finished product, walkthroughs can also be used profitably to help develop the product.
Historically speaking, the inventor of walkthroughs is considered an IBM fellow, named Michael Fagan. Mr. Fagan while at IBM and dealing with development of very large software packages to run the famous IBM mainframes, tried to find a way to reduce the probability of errors. He invented a whole process, called Formal Inspections or Structured Walkthroughs. His ideas were embraced by a number of large, government sponsored organizations as well as other notable figures in the software industry, most notable being Edward Yourdon and Larry Constantine. Some large organizations, like Jet Propulsion Laboratory in Pasadena, California, took these ideas and developed their own walkthrough methodology, or customized Michael Fagan's Formal Inspecitions, and made them success stories on couple of large NASA sponsored projects.
D. Current state of the art
As stated above and below, in describing the concept of walkthroughs, its methods and techniques, a team is usually set up to conduct a walkthrough for a given phase of the software development life cycle (SDLC). Each member of this team has a given role, as follows:
• The presenter, who usually is the person or entity (organization) that "puts on the table" the product they built and is to be reviewed.
• The coordinator, who usually is a designed team leader for the process.
• The secretary / scribe, who usually records the discussed facts, issues, etc., takes and distributed minutes.
• The maintenance oracle, who is a person that will review the product from the future maintenance standpoint
• The standards bearer, who makes sure that the pre-established process or standards are being followed.
• The user representative, user as the names says a person representing the user community for who the product is being built.
• Other reviewers, or walkthrough team members that participate in the review process, have a good technical understanding of the particular product that is presented for review.
• Time keeper, who as title says keeps the time, in the sense that he/she makes sure that the pre-established allotted time frames for each step in the process, is spent accordingly. This is very important task, that there is a tendency to debate too long issues that will result in an unproductive use of all team members' time and productivity.
Before the review commences, each of the above team members have to "get ready", i.e., prepare for the review. This usually consists in pre-reviewing an advanced copy distributed to all team members, prior to formal review activity.
During the review process, special designed forms and procedures are being used. These forms and procedures, also known as checklists are each designed to meet the requirements of a particular stage of the SDLC.
After the review ended, a list of documentation (forms) are being prepared, analyzed, and recommendation are being made to the walkthrough team members. Usually one of the three outcomes are possible: the product is fully accepted and it's recommended to be taken to the next stage, or the product is rejected, and therefore a series of recommendation are given to the development team, or the product is (partially) accepted but with a series of minor recommendation to be implemented before, passing to the next stage.
As mentioned thus far, the application of walkthrough, in this paper's context, is the software development life cycle (SDLC).
While it may not be entirely fair to generalize, many formal reviews (walkthroughs) are characterized by the following, prioritized in decreasing order of importance:
• Slow feedback.
• A general absence on the part of the reviewers of a sense of responsibility for the correctness and quality of the product being reviewed.
• Critique whose quality is highly variable.
• Relatively complete documentation.
There are well defined general guidelines on when a walkthrough should be help. For instance a code walkthrough could easily take place at any one of the following six stages:
• before the source code has been entered into the computer
• after the source code has been entered, but before it has been compiled
• after the first compilation
• after the first "clean" compilation, free of syntax errors
• after the first test case has been executed successfully
• after the developer thinks that all test cases have been executed successfully.
There are a number of types of walkthroughs:
• Specification walkthroughs are, as the name implies, a review of the user requirements, or specifications, of an information system. This type of walkthrough is concerned with the functionality of the system.
• Design walkthroughs assume that the functional requirements and user implementation model of the system are correct.
• Code walkthroughs often attract the most attention in organizations simply because code used to be private, and because code is the final tangible product of the development project.
• Test walkthroughs are conducted to ensure the adequacy of the test data for the system, not to examine the output from the test run.
Another application of walkthrough was pioneered by Gerald Weinberg in 1971 in his classical book, The Psychology of Computer Programming. He uses the concept of walkthrough as a Programming Team approach to developing software. The objectives of a programming team and the concept of walkthrough have very many thinks in common.
F. Future directions
Most of the criticism walkthrough encountered from very beginning, was from, surprising management. In particular, top management has been very difficult to convince to allocate and spend the resources required by walkthroughs. This is why, I believe that as far as future directions, a better job needs to be done to convince (top) management of the usefulness of this type of activity, the walkthroughs.
Major steps in this direction have already being made, by building more and more success stories, particularly on large, mission critical projects, like those in aerospace and defense. The other side of the future direction is the development of software tools that will help to proceed through this people intensive process, the walkthrough.
The important component of a successful walkthrough, is to be able to build better teams, sometimes a difficult task in our culture compared to Far East or European cultures. Her are some hints toward building better teams:
• Let the team evolve naturally.
• Don't disband the team at the end of the project.
• Encourage fresh blood in the team.
• Respect and trust the team.
• Reward and punish the team equally.
• Protect the team from outside pressures.
Other future directions of walkthroughs include:
• Walkthroughs will become more specialized, in the sense that specialized tools, techniques and people will be allocated to various types of products.
• The economics of walkthroughs will be explored more fully, by collecting specific data sand building "metrics" that will be more convincing to management that allocated resources to this process.
• The boundary between product development and product walkthrough will blur, i.e., the walkthrough will be natural part of the development process, rather than a (desired) addition to the development process.
• High tech support tolls will facilitate the development of groupware, in some organizations, this being already a fact, due to a more and more widely used of computer networks and products (tools) that facilitate working in groups on the network, sharing the same techniques and methods, rather than an individual, separate approach.
• The "Cowboy Programmer" paradigm will develop its own walkthrough techniques, i.e., the individual PC programmer will learn and apply his own techniques, similar to those recommended by walkthroughs, to improve his/her product, therefore no need to have a formalized walkthrough, per say.
Walkthroughs, as a process comprising a variety of methods, techniques and lately tools, have evolved from the need to develop better products, especially, software products. The walkthroughs have built over the past 20 or 25 years many success stories. Unfortunately these stories are not widely known. The walkthroughs are rarely thought in schools, and unfortunately not applied on a large scale. With the exception of large organization or development of large complex products, the use of walkthroughs is very limited or known. But as presented in the above not using these techniques are too expensive in many cases. As the above paragraphs outlined, future direction will make the use of walkthroughs much more popular than today, and the outcome of that will results in better software products for all of us.